Multimap API error

Question

I'm an happy user since a while of the Multimap API but I've seen this morning an incorrect behaviour on my site, and this problem occurs with the sample "Options" too...

If you double-click on the displayed map, the clicked point is correctly centered afterwards. But if you create a zoom-box, the center of the zoom-box is shifted to East after the map updating !

I don't know since when this problem occurs, it could be a lot of time... A few months ago, this problem was inexistent and I don't have changed the related coding since then.

Thanks in advance for your awaited fix and congrats for this powerful API,
Germain

PS: no way to create this thread using the French interface because the Multimap API forum isn't listed at all !!!

Answer 1

I'm an happy user since a while of the Multimap API but I've seen this morning an incorrect behaviour on my site, and this problem occurs with the sample "Options" too...

'Options' example seems okay to me ; cant comment on yours.

I'd guess you're using IE8, which has trouble with click coordinates in every brand of maps.
Try IE-7 compatibility mode?
<meta http-equiv="X-UA-Compatible" content="IE=7" />

Answer 2

Hi Ross and thank you for your answer,

I know for IE8, but I have the problem with several browsers (FF, Chrome, Safari, etc.)...

You may check by yourself with the JavaScript "Options" example: at the maximum zoom level (18), double-click on a small icon (as a church, gas station, etc.). in this case, the map is centered on it. Then, after the proper setting, create a zoom-box having the same icon as center: the icon is no more centered afterwards !

Cheers,
Germain

Answer 3

You may check by yourself with the JavaScript "Options" example: at the maximum zoom level (18), double-click on a small icon (as a church, gas station, etc.).

Perhaps we are not looking at the same example.  I see no churches, gas station etc icons on the 'options' example at maximum zoom.   Of course there are transit stop icons and intersections to experiment with.

 in this case, the map is centered on it. Then, after the proper setting, create a zoom-box having the same icon as center: the icon is no more centered afterwards !

Can't reproduce the problem, assuming 'proper settings' means to select 'drag' as 'create zoom box' and then press 'Change option'.   It all seems to work as expected for me.

Answer 4

Many thanks again for your appreciated feedback Ross !

I've just checked again using Opera 10 and different bus station icons: using the default setting for the zoom box (Alt-drag): the map is never centered as it is done correctly with a double click on the same icon...

The positioning in both cases was OK when I coded my page months ago !

Very strange because I experiment the different behaviours on two totally different computers...

Anyone having the same problem please ?

Answer 5

Hello Germain,

I think I see the same thing.

If I go to the options example, select maximum zoom and double click the "28" (a route number?) the map centers exactly on the "28".

I then select drag:alt, create zoom-box and change options.

I then create a small zoom-box just around the "28".

I would expect the map to stay centered on the "28" but instead it moves.

Regards,
Paul

Answer 6

Okay, I had to go back and have a closer look !  You're right, using the zoombox on a previously centred place causes an apparent small 'drift' to top and left in that 'options' example.

Here's what I think is going on:
Doubleclick to centre does just that - centres the chosen point in the overall map frame.
The zoombox is a bit more subtle.  I thought about what it is supposed to do - it's NOT "centre here", it's more like "show me all this area as large as you can".
It's a bit complicated because we can only zoom to integer levels, and the zoombox size is arbritary.  But imagine if the zoombox was going to end up as the whole map width - part of the area will be obscured behind any map controls and logos.
So zoombox seems to minimise this effect by setting its centre to the centre of an imaginary rectangle, which is the clear area without logos and controls.  It's a bit like the way Infoboxes pan to avoid the controls.  It's quite clever really, and only noticeably odd when the map can't actually zoom in any further.   Even when it looks odd, it is still acheiving the desired aim - everything that was in the zoom box is visible.  Not a bug, I think.

To test this effect see the Advanced Widgets example.
http://www.multimap.com/openapidocs/1.2/demos/advancedwidgets.htm
Try it with the large widgets in various positions and the "target centre" of a zoombox will move around, but always be in the middle of the clear map.

cheers, Ross K

Answer 7

Thank you Paul for your feedback !

Ross, you are totally right about your assumptions and in this case the behaviour is quite smart.

But my concerned Web page doesn't use controls on the map itself. Only a zoom level list exists and it is located outside the map area.

So before the zoom box was perfectly centered on vehicall.com !

Maybe this is due, in my case, to the properties of new "Bing" logo on the bottom left corner, the last noticed change since a while ?

Any comment from the Multimap team will be appreciated...

Cheers,
Germain

Answer 8

Hi,

When the zoombox is used it's the equivalent of a call to getAutoScaleLocation with the bounds of the box. The auto scale calculates a location in the visible area of the map control taking into account the surrounding widgets & logos as Rossko suggested. The inner dimensions of the map may have changed slightly with the logo update as we previously had two logos, one in the upper left corner and another in the bottom left.

Answer 9

Hi John,

Many thanks for your explanation.

I guess it is a matter of minutes for the Multimap team to correct the code to take into account the changed dimensions of the new logo at the bottom left corner, isn't ?

Afterwards the map positionning will be fully OK, as before, in our current applications !

Because I don't see any other way to correct that inconvenience on our side...

Cheers,
Germain

Answer 10

I guess it is a matter of minutes for the Multimap team to correct the code to take into account the changed dimensions of the new logo at the bottom left corner, isn't ?

I don't think there's anything to correct, it is working as intended.

John has given a hint as to how you could make it work differently if you wanted ... put a dummy "logo" at the top of the map, using an widget styled to be invisible, and the centre of the clear area will move down.

Answer 11

If at zoom level 18 you select a zoombox with its width and height equal to the currently displayed map area, you get a less detailed (and shifted) map because afterwards we are back at zoom level 17... What a feature !

I would expect no change in this case, the zoombox being already contained in the previously displayed map.

It seems logical to draw AT FIRST the correctly positionned map according to the occured controls and AFTERWARDS to draw the logo(s) and the widget(s) at their absolute locations.

IMHO is a totally unlogical and incorrect behaviour right now !

Furthermore I guess nobody was complaining, since the release of the Multimap API, about the previous behaviour.

Last but not least, I was using the two corners coordinates of the zoombox to calculate the centre of the resulting displayed map: this simple procedure doesn't work anymore now !

I retain that the change around the logos was not accompanied by the required coding change due to the now different dimensions (and perhaps location).

So John, that is the reason I am kindly asking for a simple coding correction...

Answer 12

It seems logical to draw AT FIRST the correctly positionned map according to the occured controls and AFTERWARDS to draw the logo(s) and the widget(s) at their absolute locations.

It doesn't work like that, it's not supposed to work like that.  It is giving you a clear, unobstructed view of whatever was in the zoombox - the zoom18/17 example you give is a perfect illustration of that.

It's unfortunate that your application was based on an wrong assumption about this, it was just a fluke that it apparently worked before the logo was changed.  If the logo hadn't changed and you'd added some widget to the map - a new pan or zoom control perhaps - it would have failed in the same way.   If you'd happened to have different widgets on your map to begin with, your methods wouldn't have worked in the first place.  My guess is that may well have been a little inaccurate even then, just not so noticeable as it is with the taller 'bing' logo.

There is no correction to make, there is no changed behaviour.  There is at least one workaround already offered, or of course you could disable the zoombox and write your own, or you can change the methods you use to determine whichever 'centre' it is you are interested in.   I don't know if there is any formal bug-reporting or enhancement request mechanism for the API?? if you want to persist with this.

cheers, Ross K

Answer 13

Ross, the behaviour is now different and you cannot write "there is no changed behaviour" as above...

To proove you that change, simply go to http://www.bing.com/maps/ (yes, it is the Bing main site) and zoom at the maximal level on Paris or London. Then double-click a metropolitan station marker: the map will be centered on it...

Then draw a zoombox using Alt-left button centered on it: the map DOESN'T move, bingo !

Finally draw a zoombox, starting from the lower-right corner, covering all the map area by including the controls at the top-left corner: the map DOESN'T move neither, bingo bis !!!

So I still request politely and kindly a coding change to have the previous and logical behaviour: the map SHOULD BE centered on the selected zoombox centre, IMHO...

Any moderator or other user opinion, please ?

Cheers,
Germain

Answer 14

To proove you that change, simply go to http://www.bing.com/maps/ (yes, it is the Bing main site) and zoom at the maximal level on Paris or London. Then double-click a metropolitan station marker: the map will be centered on it...

Then draw a zoombox using Alt-left button centered on it: the map DOESN'T move, bingo !

Errm its a different API ... go look at http://www.multimap.com/
It appears to work quite well as you want it ... because it has widgets on all sides.  But I can even reproduce the zoom18-17 behaviour on that.

You're quite right, I cannot answer for MM/Bing/MS (whatever they are these days!)

Answer 15

On multimap.com and at the maximum zoom level, if your draw a zoombox being close (a few dozen pixels) from the top and bottom limits of the displayed map, but not a wide one, we go back at the previous zoom level despite no widget was included in the defined zoombox.  Doing the same on bing.com/maps, we stay logically at the maximum zoom level !

I retain some situationss/cases are wrongly handled by the zoombox API code within the Multimap API currently.

So I will really appreciate a feedback from the Multimap API development team about the awaited correction of those related bugs, fully described in the above postings...

Thanks in advance,
Germain

Answer 16

On multimap.com and at the maximum zoom level, if your draw a zoombox being close (a few dozen pixels) from the top and bottom limits of the displayed map, but not a wide one, we go back at the previous zoom level despite no widget was included in the defined zoombox.

That's exactly what I'd expect, and completely consistent with what John described.

It has nothing to do with any widgets included in your zoombox.
It has to do with widgets being present on the map.
The process;
You draw a zoombox, defining an area you'd like to see all of in full detail.
The API works out the "clear area" of the map, the inner rectangle that has no widgets impinging on it.
It adjusts centre of the "clear area" to be the centre of the area you asked for.
It adjusts the zoom until your chosen area fits completely within the "clear area".

Answer 17

Ross, you wrote: "You draw a zoom box, defining an area you'd like to see all in full detail"...

But if I draw a zoombox as explained above (like this || not like that ==) when I'm ALREADY in full detail at zoom level 18,  going back to zoom level 17 as result reduces the details: not what we want at all ! Do you understand this simple fact ?
 
I'm sorry but for me this behaviour is a total non sense: why the map is zoomed out if the selected zoombox is already completely included in the current map view and if it doesn't include any widget or control when displayed at zoom level 18 ?

Fortunately bing.com/maps and other sites work as expected IN THIS CASE, among others !

Answer 18

not what we want at all ! Do you understand this simple fact ?
 

Yes, I know what you want, but that's not what it does.   That doesn't make it an error.  Nor does other APIs behaving differently.   Let's see what MM thinks.

You've been suggested workarounds to deal with your problem. Do you need help with that?

Answer 19

OK Ross, we will wait and see ;-)

Thank your for your proposal, I know personally that you were always helpful :-)

Answer 20

Please we are still WAITING for a detailed answer from the Multimap team since one week !!!

Answer 21

Please we are still WAITING for a detailed answer from the Multimap team since one week !!!

Hi Vehicall
Regarding your original issue, this is not a bug with the Open API, the map is scaled to fit the visible area of the viewport.  There hasn’t been any functional change to the way the zoombox works which is based on our autoscaling methods.  The reason the Open API uses the viewable area of the map is to avoid route polylines or other overlays being partially obscured by widgets and logos in the map control.  The only way to get around this would be to build your own zoom box and auto scale tools.

It is unlikely this issue is due to the removal of the Multimap logo.  When both Multimap and Bing logos were displayed, both needed to be exactly the same height for the zoom box tool to center on the map viewport without any movement.

There our solutions suggested in this post that may help you, and if you provide us with your requirements or details of what you are trying to achieve, we are more than happy to provide suggestions.

Thanks, John.

Answer 22

I'm sorry but for me this behaviour is a total non sense: why the map is zoomed out if the selected zoombox is already completely included in the current map view and if it doesn't include any widget or control when displayed at zoom level 18 ?

Fortunately bing.com/maps and other sites work as expected IN THIS CASE, among others !

Hi John and sorry for my long silence,

So, if I understand fully your last answer, do you mean that the behaviour with the quoted scenario just here above is CORRECT on Multimap Open API and INCORRECT on bing.com ?

And do you think that the English and French versions of my Multimap Open API Web pages, with the zoombox facility implemented precisely on December 2nd, 2008, are suddendly giving wrong shifted results, without any code modification on my side AND ON MULTIMAP SIDE TOO since that date ?

Please be more serious and check your source of information !

Cheers,
Germain

Answer 23

Hi Vehicall,

The mapping API used by Bing maps is different to the MultiMap API and the functionality and behaviour differ between the two.

The intended function of the zoom box is to scale the selected area to an optimal zoom factor where by the entire selection can be viewed within the unobstructed area of the map control. The unobstructed area of the map is the largest space within the map that can be achieved without intersecting with any visible logos or widgets - you can find out what this area is by calling the MultimapViewer's getInnerDimensions method which will return an MMDimensions object. If you try adding/removing widgets you'll see that the dimensions returned by this method change accordingly as more or less of the map control become obstructed.

In your case the only elements obstructing a complete view are the multimap branding assets which, as mentioned in a previous post, were updated a few months ago. As a result of the icon updates the returned value from the API's inner dimensions calculation has changed and therefore the area that the zoombox has to scale to has also changed.

This is the intended functionality of this API feature and as this area is dynamic and reacts to aesthetic changes within the control you should not be relying on the results for calculations. If you provide us with details of what your code is trying to achieve we are happy to help suggest how you may be able to do it using future proof methods.

Thanks,
John

Answer 24

Hi John,

Many thanks for your detailed answer !

I just want to get the resulting map centered on screen according to the previously created zoombox center...

Please have a check by yourself, on http://www.vehicall.com, by selecting the "Find goods to rent now" button in the main menu, then choose for example "United Kingdom" and zoom rapidly using the zoombox feature as explained in the instructions till the 18 level.

As you could see, the expected centered point displayed after a zoombox creation is now a lot shifted to East and a little to North !

Of course I can add two offset values to the calculus to have it centered afterwards. But I will prefer another permanent solution, just in case of another branding change, for example ;-)

You will find hereafter the PERL code for the mapping section of the above related Web page.

Thank in advance for your appreciated attention and time,
Germain 


#!/usr/bin/perl

 

$nav=$ENV{'HTTP_USER_AGENT'};
read(STDIN,$s,$ENV{'CONTENT_LENGTH'});
$s=~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C",hex($1))/eg;
$s=~ tr/+/ /;
if(substr($s,0,4) ne "cod="){
$pay=substr($s,8);
%pcm=();
open(IN,'<pcm_uk.txt');
while(<IN>) {
$s=$_;
chomp($s);
($k, $v)=split(/\t/,$s,2);
chop($k);
$k=substr($k,1);
$pcm{$k}=$v;
}
close(IN);
$new=$pcm{$pay};
$cod=substr($new,0,2);
chdir("co");
open(IN,'<'.$cod);
$s=<IN>;
chomp($s);
close(IN);
chdir("..");
}
else{
$cod=substr($s,4,2);
}
$zoo=substr($s,rindex($s,",")+1);
$s=substr($s,0,rindex($s,","));
$lon=substr($s,rindex($s,",")+1);
$lat=substr($s,0,rindex($s,","));
$src="../ster_uk.htm";
$|=1;
print "Content-type: text/html\n\n";
print '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head><meta http-equiv="content-type" content="text/html;charset=UTF-8"><meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"><script type="text/javascript" src="http://developer.multimap.com/API/maps/1.2/xxxxxxxxxxxxxxxxxxx?locale=en-US"></script><script type="text/javascript" src="http://www.vehicall.com/wz_jsgraphics.js"></script><script type="text/javascript">';
print "var mapviewer;
var jg = new jsGraphics('c');
var button;
var message;
function onLoad(){
mapviewer=new MMFactory.createViewer(document.getElementById('mapviewer'));
mapviewer.goToPosition(new MMLatLon(".$lat.",".$lon."),".$zoo.");
mapviewer.setOption('doubleclick:alt','');
mapviewer.setOption('doubleclick:shift','');
mapviewer.setOption('doubleclick:ctrl','');
mapviewer.setOption('drag:alt','');
mapviewer.setOption('drag:ctrl','');
mapviewer.setOption('drag:rightbutton','zoombox');
mapviewer.setOption('contextmenu','false');
mapviewer.setOption('units','miles');
mapviewer.setAllowedZoomFactors(".$zoo.",18);
populateZoomFactors();
mapviewer.addEventHandler('changeZoom',alertBounce);
mapviewer.addEventHandler('endPan',displayCurrentPosition);
message=document.getElementById('message');
button=document.getElementById('button');
displayCurrentPosition();
}

function populateZoomFactors(){
var zfs=document.getElementById('zfs');
while(zfs.options.length>0)
zfs.removeChild(zfs.options[0]);
var factors=mapviewer.getAvailableZoomFactors();
var zf=mapviewer.getZoomFactor();
for(var i=0;i<factors.length;++i){
var option=document.createElement('option');
option.value=factors[i];
option.appendChild(document.createTextNode('Zoom Level '+factors[i]+' '));
if(factors[i]==zf){
option.selected=true;
}
zfs.appendChild(option);
}
document.button.style.visibility='hidden';
mapviewer.addEventHandler('changeZoom',onChangeZoom);
}

function onChangeZoom(type,target,old_zoom,new_zoom){
var zfs=document.getElementById('zfs');
for(var i=0,l=zfs.options.length;i<l;++i){
if(zfs.options[i].value==new_zoom){
zfs.selectedIndex=i;
if(i==l){
document.button.style.visibility='hidden';
}else{
document.button.style.visibility='visible';
}
}
}
displayCurrentPosition();
}

function displayCurrentPosition(){
message.innerHTML=mapviewer.getDimensions();
p=message.innerHTML.indexOf('x');
xx=parseInt(message.innerHTML.substring(1,p))+1;
yy=parseInt(message.innerHTML.substring(p+1,message.innerHTML.length-1))+28;
message.innerHTML=mapviewer.getCurrentPosition();
virgule=message.innerHTML.indexOf(',');
document.button.lat.value=message.innerHTML.substring(1,virgule);
document.button.lon.value=message.innerHTML.substring(virgule+1,message.innerHTML.length-1);
jg.clear();
drawAxes();
}

function alertBounce(type,target,old_zoom,new_zoom,reason){
if(reason=='nocoverage'){
xam=mapviewer.getZoomFactor();
mapviewer.setAllowedZoomFactors(".$zoo.",xam);
populateZoomFactors();
}
}

function drawAxes()
{
jg=new jsGraphics('c');
jg.setColor('#0000FF');
jg.setStroke(Stroke.DOTTED);
x=(xx/2)-1;
y=(yy/2)+28;
jg.drawLine(0,y,x-21,y);
jg.drawLine(x+22,y,xx-2,y);
jg.drawLine(x,43,x,y-20);
jg.drawLine(x,y+22,x,yy);
jg.drawEllipse(x-20,y-20,40,40);
jg.paint();
}

MMAttachEvent(window,'load',onLoad);
</script>";
print '</head><body bgcolor="#DDDDFF" topmargin="0" marginheight="0"><style type="text/css">html, body, table, div { cursor: crosshair; height: 50px; margin: 0; padding: 0; font-family: Arial, Helvetica, sans-serif; font-size: 13px; height:';
if (index($nav,"MSIE")>-1){print "91%"}
elsif (index($nav,"Opera")>-1){print "95%"}
elsif (index($nav,"Meleon")>-1){print "95%"}
else {print "100%"}
print '; width:100%;}.content{height:100%; width:100%; z-index:0} .dummy{height: 1px; width: 1px; z-index:0}</style><TABLE background="#DDDDFF" bordercolor="#000000" border="0" cellpadding="0" cellspacing="0"><tr><td colspan="3"><iframe src='.$src.' width="100%" height="42" scrolling="no" frameborder="0" frameborder="no" marginheight="0" marginwidth="0" noresize></iframe></td></tr><tr><td colspan="3" width="100%" height="100%"><div id="mapviewer" class="content"></div><div id="c" class="dummy"></div></td></tr><tr align="center" valign="baseline"><td align="right" width=33% id=message>(Latitude,Longitude)</td><td width=33%><form name="button" method="POST" action="s_uk.pl"><input type="submit" value="NEXT" name="but"><input type="hidden" name="lat"><input type="hidden" name="lon"><input type="hidden" name="cod" value="';
print $cod;
print '"></td></form><td align="left" width=33%><SELECT id=zfs onchange="mapviewer.setZoomFactor(Number(this.options[this.selectedIndex].value))" size=1></SELECT></td></tr></TABLE></body></html>';

Answer 25

I tried following the instructions as given in the yellow box above the map, but shift-rightbutton-drag didn't seem to do anything.

I think you are making something out of nothing here.  What's the purpose of the website, it appears to be to find nearby rentals?   Who is going to zoom in to 18 and get annoyed if the centre is 50m away from where they wanted, won't they be searching for miles around anyway?

Just put a dummy, invisible MMCustomWidget in the opposite corner to the 'bing' logo and of similar dimensions.

Answer 26

Hi Ross,

Sorry for the mistake, I've just changed on October 21st the activation for the zoombox due to problems with the new version of the Opera browser with the right click and the change wasn't reported in the instructions: now the ctrl key and the left button should be used instead !

Nope, we can search within a 50m radius from the clicked point which is accurate to 8m (for example a precise beach location) and in this case 50m matters...

As written above to John Millington, I'm looking for a permanent solution, independantly of the logo size and position whose values may change in the future.

Cheers,
Germain

Answer 27

Nope, we can search within a 50m radius from the clicked point which is accurate to 8m (for example a precise beach location) and in this case 50m matters...

I don't get it at all, the maps themselves aren't accurate to 8m.

I can think of an approach here, but you're going to have to do quite a bit of work.

You could examine mapviewer events ; because you've removed most of the map controls they can only come from a few sources.    Build a test version of http://www.multimap.com/openapidocs/1.2/demos/events.htm with the events display, but with controls like your map, for example the external zoom dropdown.  (As a complete aside, people are used to slippy-map webpages and are quite capable of using pan and zoom controls, I think its a mistake to remove them)
You could experiment intercepting the startmousedrag and endmousedrag events.   I think these should give you the coordinates of the zoombox, in pixels, which you can then convert to lat/long and do whatever with.  You're probably going to have to detect the shift key somehow.

An alternative is to disable the built-in dragzoom, and use the same events to trigger your own code that can zoom and centre to where you like.

Answer 28

Hi,

The simplest way to do this is to add one of the MM widgets, ideally the MMPanZoomWidget as the other widgets have associated data requests which will have a negative performance impact on your implementation, and hide it using css. You can then set the dimensions of the widget in your JS so that it can take into account any elements within the map control, for example:

CSS:

.mmtestwidget {
    position: absolute;
    visibility: hidden;
    height: 0;
    width: 100%;
}

JS:

var widget = new MMPanZoomWidget( undefined, 'mmtestwidget' );
mapviewer.addWidget( widget );

setInterval(function() {
    var map_dim = mapviewer.getDimensions();
    var inner_dim = mapviewer.getInnerDimensions();
    var top_pos = map_dim.height - inner_dim.bottom;

    var container = widget.getContainer();
    if (container) {
        container.style.top = top_pos;
        container.style.left = 0;
        container.style.right = 0;
    }
}, 10);

You may need to make some changes to that to take into account any widgets/logos that could be at the top of the control as well and also if you want it to work for elements at the left and right sides but that isn't neccessary at the moment.

Alternatively you could create your own zoom box tool but that will require a more significant amount of coding.

Cheers,
John

Answer 29

Hi again,

Sorry but I was away during a full week from my beloved computer...

I will try your solution and let you know about the result !

Many thanks for your appreciated help,
Germain