[mapguide-internals] MapGuide RFC 55 -
SwitchfromPROJ4toCS-Mapcoordinate system library
Hugues Wisniewski
hugues.wisniewski at autodesk.com
Tue Aug 12 19:40:09 EDT 2008
Hi Jason,
> users will be working with CS-Map generated WKT anyway--which
> I assume CS-Map can read
CS-Map roundtrips 100% of the OGC WKTs it generates
> Given that CS-Map is being used in production by Autodesk MapGuide
> Enterprise, I think that the risk of problems other than unsupported CRS
> is low.
If this RFC goes through, Autodesk MapGuide Enterprise and MGOS will use the same CS-Map code and the same coordinate system dictionaries
If one uses a system, the other one does too. If one fails, the other one too.
Fixing one will fix the other in case a system is not supported.
> adding the list of unsupported coordinate systems and
> instructions on what users would need to do to fix it to the release
> notes.
This is now public at http://trac.osgeo.org/mapguide/wiki/PROJ4toCS-MAP
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 3:50 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] MapGuide RFC 55 - SwitchfromPROJ4toCS-Mapcoordinate system library
Wow.
Thanks for all the detailed information Hugues. As long as MapGuide is
able to work with the custom mappings without user intervention, then
these are good results indeed.
Between this high degree of mapping, and the (to me) revelation that
most users will be working with CS-Map generated WKT anyway--which I
assume CS-Map can read--it seems that this will be a relatively
pain-free upgrade for most users.
Given that CS-Map is being used in production by Autodesk MapGuide
Enterprise, I think that the risk of problems other than unsupported CRS
is low. Personally, I would be happy going ahead without an additional
PROJ.4 build but adding the list of unsupported coordinate systems and
instructions on what users would need to do to fix it to the release
notes.
I certainly wouldn't complain if a 2.0.2 build with at least the
Firefox3 fix applied was made available, but I understand that the
resources to do this are scarce, and haven't had time to work on an open
source installer myself yet.
It would probably be worth MetaCRS looking into why the failed WKT are
either not being generated correctly by PROJ.4 or interpreted properly
by CS-Map, but I don't think that has much bearing on the MapGuide
transition to CS-Map.
Jason
-----Original Message-----
From: Hugues Wisniewski
Subject: RE: [mapguide-internals] MapGuide RFC 55 -
SwitchfromPROJ4toCS-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
_______________________________________________
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