Tiles and maps are not displayed in MapGuide Arbitrary XY-M maps

[trevorwekel]

The attached MapGuide mgp package contains a tiled map based on an Arbitrary XY meters coordinate system Library://TestData/ArbitraryXY/Maps/PlanTiled.MapDefinition. The tiles are not displayed.

A non-tiled map of the same data is Library://TestData/ArbitraryXY/Maps/Plan.MapDefinition is only marginally useful due to scale range issues. The map starts out smaller than a pixel and cannot be zoomed in sufficiently to adequately display the map detail.

Two patches for MapGuide.js are attached to the defect which seem to correct the issue. The first patch ArbitraryXYMUnits.patch is a workaround to keep the units at meters instead of switching to degrees. By default EPSG:4326 is used when no EPSG code is given. This switches the units to degrees which is incorrect for a map with meters as a unit.

Alternatively, custom EPSG codes for the various LOCAL_CS variants could be defined in PROJ4js and then used by Fusion when no EPSG code is specified. This would be a better workaround. As far as I know, there are no official EPSG codes designated for LOCAL_CS.

The second patch EnableTiles.patch turns off "single tile" behaviour when a base map layer is found during parsing. The "bSingleTile" tile variable does not seem to be set based on map content anywhere else in the code.

Shopping mall tenant plans and office floor plans will typically use LOCAL_CS coordinate systems. This defect represents a fairly serious use case limitation for MapGuide/Fusion. The defect seems to occur in the 2.0 branch and trunk.

This ticket may be related to #310 and #394

[trevorwekel]

After further investigation, the second patch EnableTiles.patch is not required. Tiling must be set up in both the application definition and the map definition. This is a little different than the ajax viewer.

[madair]

fixed at rev 2184 and 2185

I used a different approach to solve this issue: LoadMap.php is returning correct WKT and units for the projection so MapGuide.js should use those. I would like to put WKT parsing into Proj4js at some point but for now we can parse the WKT to get a projection name and set some fake Proj4js.defs values and projection type of 'identity' so that forward/inverse projections are the identity transform. The main point of doing this is so that the layer doesn't end up with the default EPSG:4326 projection.

This still leaves the issue of valid coordinate transformations in widgets like Measure. To get the measure widget to report correct values, I've added a 'Geodesic' extension element that takes true/false (default true) to indicate if the measurement should be done geodesically. In the case of the map included with this ticket, if should be set to false because it is a Local coord system and doesn't have true geographic coordinates. There may be other widgets that need this option as well.

[madair]

in testing the above fix I found another issue although I don't recall the details (brain is still in vacation mode) it meant that we did have to do WKT parsing after all. I added that to Proj4js and it works for the limited set of WKT strings I tested against, so I'm reluctant to commit it to any branch just yet so I have added here as a patch if there is any issues that come up from the 2185 revision

[madair]

moving this to the 2.2 release so we can release 2.0. The way to handle different projection codes in 2.0 is to set <ProjectionCode>EPSG:4326</ProjectionCode> in the <Extension> element. In 2.2, WKT parsing will be added to Proj4js so that projections can be better handled for MapGuide layers.

[madair]

cloased at rev [2199]

This includes parsing of MapGuide WKT in the Proj4js library.

This works welll for the lmited set of WKT strings tested. It is also quite likely that not all variations of the the text labels in the WKT projection definition are being handled in Proj4js; in that case, add new case statements in the parseWKT method around line 725-795 of Proj4js-combined.js (note that fusion uses Proj4js-compressed.js by default so you may also need to change the file that gets included ion fusion.js) (and for a full list of all the name variations that may occur, see C:\Program Files\OSGeo\MapGuide2.2\CS-Map\Dictionaries\NameMapper.csv which is why not all of them will implemented in Proj4js)

see also #401, this changeset keeps the default of a LOCAL_CS if not supplied by MG but moves the parsing of WKT into Proj4js