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

[Jason Birch]

> Yes, the plan is to support only CS-Map [...] We do not have the resources to maintain both libraries.
 
Fair enough.
 
> This may indeed impact MapGuide because of the differences between Proj4 and CS-Map.
 
Can you please note this in the RFC?  I'm OK with this, but it should be documented, and probably mentioned in the release notes.
 
> Some coordinate systems may not work with the new CSMAP.
 
And all of these implications as well?  I think the benefit of switching to CS-Map is worth it, but users need to be going into the upgrade to MapGuide 2.1 with an understanding of possible implications.
 
> 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.

> 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.

Is this (the testing, publishing part, not necessarily the fixing as long as users can manually address the problems) something that you would be willing to add as part of the work for this RFC?  With the intention that any differences identified would hopefully be added to a CS-Map RFC for fixes to the mapping system?  I believe that some of this matching exercise was already done for MapGuide (or Studio?) in an earlier release when there were a lot of issues between PROJ.4 and CS-Map, but could be wrong.

>> 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?

That's the intention.  Single click or single command :)  It allows you to specify the URL (specific revision, etc) of an external repository, and make that part of your project without actually storing it locally.  There are some implications (I don't think you can check changes to externalled code into the external repository), but I think it's a good fit in general.  It also means that when we move to new versions there isn't huge bloat in our repository as the old thirdparty library is deleted and the new version re-added.

Jason