Opened 12 years ago

Closed 12 years ago

#486 closed defect (fixed)

Base map layers show in wrong places working with Bing Maps

Reported by: christinebao Owned by: madair
Priority: P2 Milestone: 2.3
Component: MapGuide Version: 2.0
Severity: Critical Keywords:
Cc: mars.wu@…, jng Browser: All
External ID: 1432080 Operating System: All
state: New

Description

Report from Autodesk QA:
Step:

  1. Create SDF layer and add both dynamic and base layer into the map
  2. Create FWL and set Bing map as commerial layer
  3. Preview FWL

Result:
Dynamic layer and Base map does not match with each other (see attached dismatch.png)

Expectation:
The base map layer should be the same as the Dynamic layers when displaying in Bing map.

Comments:
It shows OK for other commerial layers.

Attachments (10)

dismatch.png (196.9 KB ) - added by christinebao 12 years ago.
dismatch2.png (136.0 KB ) - added by christinebao 12 years ago.
1432080.mgp (327.0 KB ) - added by christinebao 12 years ago.
1432080_2.2.mgp (3.6 MB ) - added by christinebao 12 years ago.
1432080_LD1.3.mgp (324.8 KB ) - added by christinebao 12 years ago.
CENTLINES.FeatureSource_DATA_CENTLINES.sdf (1.1 MB ) - added by christinebao 12 years ago.
FiniteScale.PNG (320.9 KB ) - added by jng 12 years ago.
486_Fixed.mgp (325.9 KB ) - added by jng 12 years ago.
486.patch (5.6 KB ) - added by jng 12 years ago.
Proposed patch
Fix1.zip (15.7 KB ) - added by Christinebao 12 years ago.

Change History (40)

by christinebao, 12 years ago

Attachment: dismatch.png added

by christinebao, 12 years ago

Attachment: dismatch2.png added

comment:1 by christinebao, 12 years ago

Hi Michael,

This ticket is nominated to Beta 1 and need to be fixed before November 18 (this Friday). It's appreciated that you can check it as soon as possible. Thanks!

Regards, Christine

comment:2 by madair, 12 years ago

Milestone: Future2.3
Owner: changed from Michael Adair <madair@…> to madair
Status: newassigned

I am unable to reproduce this using the Sheboygan dataset and Bing layers (they line up perfectly for me).

Make sure the the map you are trying to overlay uses the World spherical Mercator coordinate system.

Can you please attach a MapGuide package for the SDF layers you are overlaying, the only MapGuide data I have to test with is the sheboygan dataset.

by christinebao, 12 years ago

Attachment: 1432080.mgp added

comment:4 by madair, 12 years ago

when I try to load that package in MapGuide I get the following error:

An exception occurred in DB XML component. Error: The specified schema file is not found: C:\Program Files\OSGeo\MapGuide\Server\Schema\LayerDefinition-2.3.0.xsd File: c:\builds\mg22win32\mgdev\server\src\services\resource\XmlSchemaResolver.cpp Line: 118

Seems like this was created with more recent software perhaps?

comment:5 by christinebao, 12 years ago

The package is made in latest MapGuide code. Please upgrade. Thanks.

comment:6 by madair, 12 years ago

I'm not sure what I can upgrade to? I'm currently running v2.2.0.5703

by christinebao, 12 years ago

Attachment: 1432080_2.2.mgp added

comment:8 by madair, 12 years ago

I'm still getting an error:

An exception occurred in DB XML component. Error: The specified schema file is not found: C:\Program Files\OSGeo\MapGuide\Server\Schema\LayerDefinition-2.3.0.xsd File: c:\builds\mg22win32\mgdev\server\src\services\resource\XmlSchemaResolver.cpp Line: 118

The highest version number in that directory for LayerDefinition.xsd that I have is 1.3.0.

However, I was able to unzip the package and import the data and create a layer from it using MG Maestro3.5 and add it to a sheboygan mercator map and the streets all line up perfectly. I'm guessing there is somethign wrong with you layer and/or map definition in terms of coordinate systems

by christinebao, 12 years ago

Attachment: 1432080_LD1.3.mgp added

by christinebao, 12 years ago

comment:9 by christinebao, 12 years ago

Hi Mike,

LayerDefinition-2.3.0.xsd is added by r5168 on September 21, 2010, and actually it's not the latest one now. The latest LayerDefinition-2.4.0.xsd is in the repository also. If you sync http://svn.osgeo.org/mapguide/trunk/MgDev you will be able to load the packages. In this case we are on the same page.

Anyway, I tried to modify layer definition in the package and made one with LayerDefinition 1.3. Please see attached http://trac.osgeo.org/fusion/attachment/ticket/486/1432080_LD1.3.mgp. It can still reproduce the problem.

The detail steps of reproducing the problem if you want to load data by yourself:

  1. Load the attached http://trac.osgeo.org/fusion/attachment/ticket/486/CENTLINES.FeatureSource_DATA_CENTLINES.sdf.
  2. Create map, set coordinate system to WGS84.PseudoMercator (WGS84 based Mercator (spherical formulation))
  3. Add both normal layer and base layer to this map. Base layer scale list is:

1128.497220, 2256.994440, 4513.988880, 9027.977761, 18055.955520, 36111.911040, 72223.822090, 144447.644200, 288895.288400, 577790.576700, 1155581.153000, 2311162.307000, 4622324.614000, 9244649.227000, 18489298.450000, 36978596.910000, 73957193.820000, 147914387.600000, 295828775.300000, 591657550.500000,

  1. Create flexible web layout, add commercial layer of Bing Map.
  2. Preview and you can see the problem.

Please contact me if you have any question.

Regards, Christine

comment:10 by madair, 12 years ago

Christine,

Sorry but I still can't reproduce this error. I updated the schema directory from svn and then I was able to load all the attached packages, and preview the flexible web layouts and they show perfect alignment with the Bing layer.

Looking at your screen captures, the scale for each of the layers looks completely different as if the map draw was interrupted and you were left with the layer as it was shown in a previous zoom. Are there any errors shown in the console?

comment:11 by christinebao, 12 years ago

Hi Mike,

I checked the server log and no error happens. You are using branch http://svn.osgeo.org/mapguide/branches/2.2/MgDev, do you? Our team is working on trunk http://svn.osgeo.org/mapguide/trunk/MgDev, and it is different from your branch. It's appreciated that you can sync to trunk and keep us on the same page, as we need to make it fixed in the trunk not branch.

Thanks & regards, Christine

comment:12 by madair, 12 years ago

No, I only ever work with http://svn.osgeo.org/fusion/trunk for Fusion work. Synchronizing the that with the MapGuide SVN is up to you guys.

I did some work on #468, did you get revision [2439] applied (from fusion svn)?

comment:13 by christinebao, 12 years ago

Hi Mike,

Yes, our build is based on http://svn.osgeo.org/fusion/trunk and we have r2439 already, which is to support commercial layers with tiled map. Without this submission other commercial layers except bing maps cannot work with tiled map.

So we have the same fusion and for unknown reason the Bing map does not work. You only work with fusion reminds me something. How do you use MapGuide? Install open source or build by yourself? Do you use standard template, can you test MapGuide template such as Slate?

Do you have any suggestion to make us closer in this problem?

Thanks & regards, Christine

comment:14 by madair, 12 years ago

Christine,

I typically load fusion pages on their own pointing to an AppDef, however I also tested this using the 'preview' button of Maestro 3.5

I think the options at this point are:

  • you can set up a web site that I can see that demonstrates the problem,
  • and/or attach the tempalte and AppDef file that you are using (I already have the mgp package for the map)

One thing to check since it's Bing maps only, are you including the bing script tag in the template? i.e.

<script src='http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.1'></script>

update Fusions copy of the Openlayers lib perhaps?

comment:15 by jng, 12 years ago

Cc: jng added

by jng, 12 years ago

Attachment: FiniteScale.PNG added

comment:16 by jng, 12 years ago

Just to add a data point here.

I can see the same problem, but I found an interesting observation. The scale of the map for some reason is off by a bit, so the mismatched layer is probably a rendering request for the finite scale range below it.

See attached image

comment:17 by christinebao, 12 years ago

Update from Christine:

  1. I tried to add <script src=' http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.1'></script> into template but still have the problem.
  2. I am setting up a public server which you can visit and see the problem. It will take some time, and I will notice you when it's ready.

comment:18 by jng, 12 years ago

How was this finite scale list generated? Was it a manually entered list, or one generated by Studio?

Because I noticed the bing OL resolution list is one item less than the MapGuide one, possibly explaining why tile requests seem to be offset by 1.

Case in point. Modify the OpenLayers.Layer.MapGuide class in OpenLayers.js to have zoomOffset of -1. The tiled layers in the attached package lines up with the Bing layer.

comment:19 by jng, 12 years ago

Alternatively, you can also fix this by deleting the topmost finite display scale from the Map Definition.

Again, I'd be interested to know how this list was created?

Attached is a "fixed" package. The only change as already mentioned, was deleting the topmost finite display scale from the Map Definition.

by jng, 12 years ago

Attachment: 486_Fixed.mgp added

comment:20 by christinebao, 12 years ago

Hi Jng,

Thank you very much to find out the problem of this ticket. Yes, the offset is caused by scale 591657550.500000. The scales are set by Studio automatically. We use the full set scale, which is Google layer scale:

1128.497220, 2256.994440, 4513.988880, 9027.977761, 18055.955520, 36111.911040, 72223.822090, 144447.644200, 288895.288400, 577790.576700, 1155581.153000, 2311162.307000, 4622324.614000, 9244649.227000, 18489298.450000, 36978596.910000, 73957193.820000, 147914387.600000, 295828775.300000, 591657550.500000.

There are total 20 scale in Google layer, and Bing map/Yahoo map/Open street map are subset of Google layer, so we use the full set.

As I remember MapGuide tiled map is treated as overlay on commercial layers. So I think MapGuide tiled map should find out which is current commercial layers scale and show the one matches. If MapGuide titled map has more than the commercial layers have, it should ignore those cannot find matching scale. However the behavior of Bing map seems that it's hard coded by offset, not decided by scale value, is it?

Anyway, it's glad to know the reason of this ticket. Let's find out a solution to fix it.

Thanks & regards, Christine

comment:21 by Christinebao, 12 years ago

Hello Jng & Mike,

Any update about this?

Thanks & regards, Christine

comment:22 by jng, 12 years ago

I don't know what else can be done from the Fusion side. If the scale list is created by studio, then it should probably also include additional information into the Application Definition so that Fusion knows that this map is using the Google Layer scale list (maybe a <UsesCommercialLayerScaleList> extension element?).

That way, widgets like the base map switcher can then know what zoom index offsets to apply based on what commerical layer needs to be shown. So:

If Bing, offset by -1 If Google, don't offset If Yahoo, offset by ??? If OSM, offset by ???

comment:23 by Christinebao, 12 years ago

Hi Jng,

Fusion should be able to know which is the current active commercial layer. When opening an Application Definition it has several layers, type is MapGuide, MapServer or general, and general type knows it's Google or Yahoo or Bing. Mike maybe knows more about it. Adding a type inside Application definition is not a good idea, as one Application Definition can have several commercial layers enabled, but only one is active at run time. So it depends on Fusion to know which is the active one.

Thanks & regards, Christine

comment:24 by jng, 12 years ago

My concern is more along the lines of: How does fusion know the current map is using a Google layer scale list? Should we just say: If current map's scale list has exactly the above set of zoom scales, it is subject to zoom index offsetting?

comment:25 by Christinebao, 12 years ago

The map set up by Studio uses Google layer scales. However not sure about other maps which user may manually change the scale list. It was expected that the overlay can dynamically match to the base layer, but it seems not work in this way. The overlay is hard coded to use a scale at certain index. For now we need to fix this issue quickly. You can assume the scale list is Google layers, and make sure all the commercial layers work.

by jng, 12 years ago

Attachment: 486.patch added

Proposed patch

comment:26 by jng, 12 years ago

Attached is a patch to make fusion check if a given OpenLayers.Layer.MapGuide object has a scale list equivalent to the Google Layer Scale list, if so it tacks on a bUsesCommercialLayerScaleList property to indicate this.

The basemap switcher widget has been modified to include a list of offsets to apply based on the given layer selected. When a commerical layer switches, any OpenLayers.Layer.MapGuide objects whose bUsesCommercialLayerScaleList flag is set will have their zoomOffset set to the associated offset in this list.

This makes the given map line up correctly for all supported base layers. I could not confirm Yahoo map support due to lack of API key.

This patch is not 100% perfect, there is some minor visual artifacts as a layer gets switched, there may be excessive redraw() calls as part of initialising the basemap switcher. But it produces the intended results: your MG tiled layers lining up with your MG untiled layers and the commerical layer if (and only if) your tiled maps are using the Google Commerical Layer scale list

Please review (especially if this changes also work with Yahoo layers)

in reply to:  25 comment:27 by jng, 12 years ago

Just to comment on this particular bit:

Replying to Christinebao:

The map set up by Studio uses Google layer scales. However not sure about other maps which user may manually change the scale list. It was expected that the overlay can dynamically match to the base layer, but it seems not work in this way. The overlay is hard coded to use a scale at certain index. For now we need to fix this issue quickly. You can assume the scale list is Google layers, and make sure all the commercial layers work.

The layer that's displaced is not the MG dynamic overlay, it's the MG tiled layer(s)

If you look at a mixed tiled/dynamic map in the basic AJAX viewer the dynamic overlay layers are constrained to the scales in the finite scale list.

With fusion it's pretty much similar except that now MG tiled layers are constrained to the scales of the Google Commercial scale list (being fixed scales, these tiled layers must either be at the same scales as the Google scale list or approximately close to it). The MG dynamic overlays will still be constrained to whatever the MG tiled layers are constrained at.

by Christinebao, 12 years ago

Attachment: Fix1.zip added

comment:28 by Christinebao, 12 years ago

Hi Jng,

You patch changed 2 files, and I have integrated them into fusion, the modified files are attached in Fix1.zip. However it did not fix the problem. Bing map still offset, and other commercial layers work. Same as before. Would you please check why?

Thanks & regards, Christine

comment:29 by Christinebao, 12 years ago

Hi Jng,

Please ignore the previous message. It works after I cleared my cache. After testing it turned out all the commercial layers work now. Thank you for the fixing.

Thanks & regards, Christine

comment:30 by jng, 12 years ago

Resolution: fixed
Status: assignedclosed

Fixed with r2479

Note: See TracTickets for help on using tickets.