Changes between Version 1 and Version 2 of MapGuideRfc127
- Timestamp:
- 09/06/12 12:14:36 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapGuideRfc127
v1 v2 1 1 ---- 2 = !MapGuide RFC # - Change Coordinate System API (MgGeometry) to adopt changes proposed by CS-Map RFC6 =2 = !MapGuide RFC 127 - Change Coordinate System API (!MgGeometry) to adopt changes proposed by CS-Map RFC6 = 3 3 4 4 This page contains a change request (RFC) for the !MapGuide Open Source project. … … 21 21 == Overview == 22 22 23 RFC6 for CS-Map - MapGuide's geospatial coordinate system engine - proposes to split the geospatial coordinate system dictionary (*.CSD) files it is using into "system" (read-only) and "user-defined" (read/write) files. 24 In order to be able to benefit from these enhancements, the MgCoordinateSystem API will have to be updated. 23 The CS-Map team (MapGuide's geospatial coordinate system engine) recently approved the RFC6. It proposes to split the geospatial coordinate system dictionary (*.CSD) files it is using into "system" (read-only) and "user-defined" (read/write) files. In order to be able to benefit from these enhancements, the !MgCoordinateSystem API will have to be updated. 25 24 26 25 == Motivation == 27 26 28 The rational behind changing the MgCoordinateSystem API is the same as for CS-Map's RFC6. Adding user-defined coordinate systems to CS-Map - which is possible through the MgCoordinateSystem API already today - would no longer rewrite entire *.CSD files which have been potentially installed as read-only files. Also, having any custom geospatial coordinate system information separated from the default system files allows for much easier sharing, distribution and "installing" of these.27 The rationale behind changing the !MgCoordinateSystem API is the same as for CS-Map's RFC6. Adding user-defined coordinate systems to CS-Map - which is possible through the !MgCoordinateSystem API already today - would no longer rewrite entire *.CSD files. The installed CSD files could thus remain read-only. Also, having any custom geospatial coordinate system information separated from the default system files allows for much easier sharing, distribution and "installing" of these. 29 28 30 29 See [http://trac.osgeo.org/csmap/wiki/CsMapRfc6]'s 'Motivation' section for additional details. … … 32 31 == Proposed Solution == 33 32 34 This RFC proposes to implement the following changes to the MgCoordinateSystem API in principle and initialization routines in general:33 This RFC proposes to implement the following changes to the !MgCoordinateSystem API in principle and initialization routines in general: 35 34 36 * Modify the initialization sequence of the MgCoordinateSystemCatalog class so it by default initializes the system dictionary path and also the user's coordinate system path. The latter defaults to [<current user>\Autodesk\User Geospatial Coordinate Systems] which is analog to the default dictionary path already implemented in the CCoordinateSystemCatalog class. This can be dynamically overridden by the MENTOR_USER_DICTIONARY_PATH variable. If, in either case, the targeted directory doesn't exist or is invalid in any way, entire MgCoordinateSystem API behaves as oftoday. That is, any dictionary updates initiated through MapGuide's Coordinate System API will directly modify the root CSD files.35 * Modify the initialization sequence of the !MgCoordinateSystemCatalog class so it by default initializes the system dictionary path and also the user's coordinate system path. The latter defaults to [<current user>\Autodesk\User Geospatial Coordinate Systems] which is analog to the default dictionary path already implemented in the CCoordinateSystemCatalog class. This can be dynamically overridden by the MENTOR_USER_DICTIONARY_PATH variable. In either case, if the targeted directory doesn't exist or is invalid in any way, the entire !MgCoordinateSystem API would behave as it does today. That is, any dictionary updates initiated through MapGuide's Coordinate System API will directly modify the root CSD files. 37 36 * Adapt the changes made due the implementation of RFC122 (http://trac.osgeo.org/mapguide/wiki/MapGuideRfc122) so that the user's dictionary path can be configured through the serverconfig.ini/webconfig.ini file 38 37 39 38 New API to be added: 40 39 41 * CoordinateSystemCatalog:: GetDefaultUserDictionaryDir(): Returns the default dictionary directory where user-defined geospatial coordinate system information is stored.42 * CoordinateSystemCatalog:: GetUserDictionaryDir(): Returns the current, if so configured or initialized, dictionary directory where user-defined geospatial coordinate system information is stored43 * CoordinateSystemCatalog:: SetUserDictionaryDir(): Sets the current dictionary directory where user-defined geospatial coordinate system information will be stored40 * CoordinateSystemCatalog::!GetDefaultUserDictionaryDir(): Returns the default dictionary directory where user-defined geospatial coordinate system information is stored. 41 * CoordinateSystemCatalog::!GetUserDictionaryDir(): Returns the current, if so configured or initialized, dictionary directory where user-defined geospatial coordinate system information is stored 42 * CoordinateSystemCatalog::!SetUserDictionaryDir(): Sets the current dictionary directory where user-defined geospatial coordinate system information will be stored 44 43 45 44 Additional modifications: 46 45 47 46 * With RFC6 being implemented in CS-Map, the category API will be finalized, too. Currently, MapGuide uses its own code to access, i.e. read '''and''' write, the Category.CSD file. That should be changed so it uses - like all other CS-Map dictionary related implementation in MapGuide - the API provided by CS-Map directly. 48 * The various MgCoordinateSystem...Dictionary classes have to be changed, where appropriate, so they call into new CS-Map API. All these changes are internal only, however.47 * The various !MgCoordinateSystem...Dictionary classes have to be changed, where appropriate, so they call into new CS-Map API. Note, that all these changes are internal only. 49 48 50 49 == Implications == … … 54 53 * setting the MENTOR_USER_DICTIONARY_PATH variable - OR - 55 54 * setting up the correct configuration in the appropriate ini file - OR - 56 * call the new SetUserDictionaryDir() API in an appropriate way55 * call the new !SetUserDictionaryDir() API in an appropriate way 57 56 58 where none of the aforementioned is proposed to be implemented by this RFC , e.g. through updating the installer.57 where none of the aforementioned is proposed to be implemented by this RFC. In particular, updating the installer is not covered by the changes proposed by this RFC. 59 58 60 59 == Test Plan == 61 60 62 The proposed changes will tested at unit level, i.e. by enhancing existing CPPUnitTests or new CPPUnit tests where appropriate. Existing unit tests, specifically those related to the coordinate system, should naturally not be affected by this RFC though.61 The proposed changes will be tested at unit level, i.e. by enhancing existing (!CPPUnit)tests or new tests where appropriate. Existing unit tests, specifically those related to the coordinate system, should naturally not be negatively affected by the changes implemented by this RFC. 63 62 64 63 In addition, the tests that have been run for RFC122 will have to be re-executed. See the Test Plan section for RFC 122.