[mapguide-internals] MapGuide RFC 55 - Switch fromPROJ4toCS-Mapcoordinate system library

[Hugues Wisniewski]

Hi Jason,

When I am mentioning a custom system that doesn't mean there is any kind of manual process involved.
That just means that internally, CS-Map managed to generate a valid definition that it can work with but did not find an equivalent into its dictionary.

I am providing the results from a test. I did not investigate on the reasons of the results.

If we take for instance the PROJ4 system EPSG:26901 the test says it is not mapped to an actual dictionary entry in CS-Map but it is a valid system and MapGuide can work with it.

Here is how the general WKT mapping code works:
- read the WKT and try to detect the flavor
- decode the WKT sub elements: system, datum, ellipsoid, unit, ...
- generate a complete CS-Map definition based on all the gathered sub elements.
- validate the definition. At this stage if we succeed, we could stop because we have a valid system we can work with
- use this valid definition and with the help of the WKT mapping file try to map each sub element with a CS-Map element from its dictionary files: ellipsoid name, datum name, coordinate system name
- return either the definition generated from the WKT or the CS-Map definition with the names from the CS-Map dictionaries

If we fail in the extraction of the sub-elements we stop and return a failure.
If the system is not valid, same thing.

When I look up the EPSG code 26901 in CS-Map I find the system UTM83-1 but the test did not manage to map the PROJ4 WKT to that name.
That doesn't mean the system generated from the WKT is wrong or needs manual steps to work with it.
The WKT mapping API is one of the trickiest pieces of code that gets constantly improved.
The CS-Map UTM83-1 uses the UTM projection while the PROJ4 WKT indicates the PROJECTION["Transverse_Mercator"] and its actual parameters.
I am almost sure the two definitions are the same but maybe the mapper did not concluded that the PROJ4 EPSG:26901 is the CS-Map UTM83-1 because of that. If that is the case it must be fairly easy to fix the algorithm. Such fix would be transparent to the end user as MapGuide already succeeds to work with that WKT.

The real information about that test is that out of the 3217 tested systems, only 84 failed.

> are there multiple matches
No, if there is at least one match it is returned

For those 84 that failed, it can be the syntax of the WKT, a unit that CS-Map doesn't know about ...
If I randomly pick up a failed system like CH1903 which WKT is:

PROJCS["unnamed",
        GEOGCS["Bessel 1841",
                DATUM["unknown",
                        SPHEROID["bessel",6377397.155,299.1528128]],
                PRIMEM["Greenwich",0],
                UNIT["degree",0.0174532925199433]],
        PROJECTION["Hotine_Oblique_Mercator"],
        PARAMETER["latitude_of_center",46.9524055555767],
        PARAMETER["longitude_of_center",7.4395833333842],
        PARAMETER["azimuth",90],
        PARAMETER["rectified_grid_angle",90],
        PARAMETER["scale_factor",1],
        PARAMETER["false_easting",600000],
        PARAMETER["false_northing",200000]]

unless I am mistaken, there is no unit for the PROJCS system. That must be why CS-Map fails to just decode the string.
And we would not even be at the stage of trying to generate a full definition or even to map it to a CS-Map name.
Another random system "panama" shows the same problem, no unit is available in the WKT.
So, it looks like the syntax of the failed WKTs is the reason of the failure.

Hugues

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Tuesday, August 12, 2008 8:59 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] MapGuide RFC 55 - Switch fromPROJ4toCS-Mapcoordinate system library

Hi Hugues,

I'm a bit concerned by the number of systems that require custom entries
(this will mean a manual process, right?).  Of course, there isn't an
even distribution of users among the coordinate systems, but it looks
like the majority of the UTM zones (at least EPSG2690x, EPSG3260x,
EPSG3270x) are not being mapped.

I understand that this is probably a manual process, but I would be
interested in knowing why the systems are not matching.  Is there
something about the PROJ.4 WKT (I'm assuming that MapGuide isn't
generating the WKT on its own) that CS-Map isn't recognizing, are there
multiple matches, or is there something more specifically wrong like a
mismatch between the ellipsoid definitions or even a difference in
precision that the numbers are stored in?

Regardless of this exercise, am I wrong to assume that MGOS users will
likely want to define coordinate system overrides and alter their map CS
definitions so that they don't run into on-the-fly "projection"
penalties?

Jason

-----Original Message-----
From: Hugues Wisniewski
Subject: RE: [mapguide-internals] MapGuide RFC 55 - Switch
fromPROJ4toCS-Mapcoordinate system library

Hi Jason,

I have executed the tests
Out of the 3217 tested systems using their WKT expressions, 84 of the
WKTs generated from those systems failed to be mapped to a CS-Map system
I have posted the results here:
http://trac.osgeo.org/mapguide/wiki/PROJ4toCS-MAP
and I added the link to the RFC

Hugues
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals