[mapguide-internals] MapGuide RFC 55 - Switch
fromPROJ4toCS-Mapcoordinate system library
Traian Stanev
traian.stanev at autodesk.com
Tue Aug 12 17:34:57 EDT 2008
One fun statistic that one could try is to do the reverse -- see how many CSMap-supported coordinate systems fail with PROJ.4.
Also, everyone should remember that if you are using Mapguide Studio, you are using CSMap/Mentor already.
Traian
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-
> internals-bounces at lists.osgeo.org] On Behalf Of Hugues Wisniewski
> Sent: Tuesday, August 12, 2008 5:26 PM
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] MapGuide RFC 55 - Switch
> fromPROJ4toCS-Mapcoordinate system library
>
> 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
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
More information about the mapguide-internals
mailing list