Changes between Version 1 and Version 2 of MapGuideRfc127


Ignore:
Timestamp:
Sep 6, 2012 12:14:36 PM (6 years ago)
Author:
baertelchen
Comment:

changed some wording; no substantial changes

Legend:

Unmodified
Added
Removed
Modified
  • MapGuideRfc127

    v1 v2  
    11----
    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 =
    33
    44This page contains a change request (RFC) for the !MapGuide Open Source project.
     
    2121== Overview ==
    2222
    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.
     23The 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.
    2524
    2625== Motivation ==
    2726
    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.
     27The 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.
    2928
    3029See [http://trac.osgeo.org/csmap/wiki/CsMapRfc6]'s 'Motivation' section for additional details.
     
    3231== Proposed Solution ==
    3332
    34 This RFC proposes to implement the following changes to the MgCoordinateSystem API in principle and initialization routines in general:
     33This RFC proposes to implement the following changes to the !MgCoordinateSystem API in principle and initialization routines in general:
    3534
    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 of today. 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.
    3736 * 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
    3837
    3938New API to be added:
    4039
    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 stored
    43  * CoordinateSystemCatalog::SetUserDictionaryDir(): Sets the current dictionary directory where user-defined geospatial coordinate system information will be stored
     40 * 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
    4443
    4544Additional modifications:
    4645
    4746 * 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.
    4948
    5049== Implications ==
     
    5453 * setting the MENTOR_USER_DICTIONARY_PATH variable - OR -
    5554 * setting up the correct configuration in the appropriate ini file - OR -
    56  * call the new SetUserDictionaryDir() API in an appropriate way
     55 * call the new !SetUserDictionaryDir() API in an appropriate way
    5756
    58 where none of the aforementioned is proposed to be implemented by this RFC, e.g. through updating the installer.
     57where 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.
    5958
    6059== Test Plan ==
    6160
    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.
     61The 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.
    6362
    6463In addition, the tests that have been run for RFC122 will have to be re-executed. See the Test Plan section for RFC 122.