[mapguide-internals] MapGuide RFC 55 - Switch from PROJ4 toCS-Map coordinate system library

[Hugues Wisniewski]

Hi Jason,

> I guess the original intention of having a compile-time switch so that users can choose one or the other has gone out the window?

Yes, the plan is to support only CS-Map
PROJ4 has not been updated or maintained to the same level as CS-MAp
We do not have the resources to maintain both libraries. However, if some from the community want to step up and maintain the Proj.4 version, we can add their names to the Funding/Resources part of the RFC and let them do that.
Note that this also means that they need to create a Proj.4 version of the binaries and installers.
The move to CS-Map is also motivated by the need to have MapGuide open source use the same coordinate system library that are used in commercial products. This would remove all the discrepancies that exist between them right now.

> Will this affect sites that are running MapGuide alongside other open source PROJ.4-based applications that do on-the-fly
> projections on the same data; is it possible that users see large differences from one application to the next?

This may indeed impact MapGuide because of the differences between Proj4 and CSMap. Ie: supported projections, the way transformations are calculated, or slightly different coefficient precision in the coordinate system definitions, etc...
Any of the well known and highly used systems in CS-Map is unit tested with a list of test points that should be transformed to an expected target point within a certain tolerance. This test points in this list typically come from official sources. We can expect slightly different results between the two libraries depending on the reasons listed above but if there is a large difference between the two products, and we have valid test points for a given transformation to test what is expected, I guess that the resulting defect we would be facing in that case in the algorithm or in the system definition will have to be fixed.

>What are the implications for existing installs?
Some coordinate systems may not work with the new CSMAP. Though the number should be very low. Resources would need to be updated to use the CS-MAP equivalent CS if there are failing CS.
If a definition is missing, the creation of a custom system is possible via the fully implemented MgCoodinateSystem API that will be provided.
If a projection or datum technique is missing, a source code update would be needed inside CS-Map after approval of the corresponding RFC that would need to be written against that project.

>Is there a potential that spatial contexts have been recorded to the repository (in SC overrides, native map projections, etc) or
>FDO data stores that are incompatible with CS-Map?
That is the same as above. I guess those spatial contexts are holding the WKT string of the system in use.
If a system is missing we can always create a custom system
If there a problem in the WKT mapping like a missing entry this can be done
Some manual work would have to done as a quick workaround to chose the system the user is expecting in the SC override
The WKT mapping in CS-Map is in constant evolution as new definitions become available or are needed.

>If so, how will we support users running into this problem?
The first step would be to look up the list fo available systems and find the one that is expected
If the system does not exist is can be created as a custom system
A suggestion might also be made to add the new definition directly into the CS-Map coordinate system dictionaries
If the WKT mapping is a problem, this can be updated manually. As for a new system, this change can also be suggested directly into the CS-Map project
I suppose this mailing list or the CS-Map mailing list would also be good source to ask for advice to understand why a specific system is not understood.

>Is there a potential for a utility application that scans the repository and tests whether CS-Map can
>recognize the WKT so that users can identify and resolve any problems before upgrading?
Technically yes, such tool would have to be written though
A good thing would be to generate the complete list of all the WKTs generated with PROJ4 and run the CS-Map unit tests against those strings
That would be very easy to do. That way we could generate the list of the ones that fail and publish that list and investigate on the reason of these failures and depending on the resources, fix the failures.

> using SVN Externals (http://svnbook.red-bean.com/en/1.0/ch07s03.html)
I am not familiar with that. Would that make the whole code download from several SVN sources in a single click?

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: Thursday, August 07, 2008 9:27 PM
To: MapGuide Internals Mail List; MapGuide Internals Mail List; mapguide-internals at lists.osgeo.org
Subject: RE: [mapguide-internals] MapGuide RFC 55 - Switch from PROJ4 toCS-Map coordinate system library

Oh...

And I was wondering if this would be a good time to start using SVN Externals (http://svnbook.red-bean.com/en/1.0/ch07s03.html) to reference a given tag of CS-Map from within the MapGuide SVN repository.  This will allow MapGuide developers to use CS-Map without having to worry about separate downloads, making sure they have the right version for the branch they are working on, etc.  Both of these projects are using OSGeo infrastructure, so there is little risk of this "third party" library going away.

Jason

________________________________

From: Jason Birch
Subject: RE: [mapguide-internals] MapGuide RFC 55 - Switch from PROJ4 toCS-Map coordinate system library

Hi Hugues!

Wow, that was quick; maybe GDAL won't beat MapGuide in using CS-Map after all :)

I guess the original intention of having a compile-time switch so that users can choose one or the other has gone out the window?  I'm not necessarily against this--it's more overhead to maintain both--just surprised at the change.

Will this affect sites that are running MapGuide alongside other open source PROJ.4-based applications that do on-the-fly projections on the same data; is it possible that users see large differences from one application to the next?

What are the implications for existing installs?  Is there a potential that spatial contexts have been recorded to the repository (in SC overrides, native map projections, etc) or FDO data stores that are incompatible with CS-Map?  If so, how will we support users running into this problem?  Is there a potential for a utility application that scans the repository and tests whether CS-Map can recognize the WKT so that users can identify and resolve any problems before upgrading?

Jason


________________________________

From: Hugues Wisniewski
Subject: [mapguide-internals] MapGuide RFC 55 - Switch from PROJ4 to CS-Map coordinate system library

Hi,

I would like to submit "MapGuide RFC 55 - Switch from PROJ4 to CS-Map coordinate system library" for review and comment.



http://trac.osgeo.org/mapguide/wiki/MapGuideRfc55



Thanks,



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

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