Changes between Version 1 and Version 2 of MapGuide


Ignore:
Timestamp:
Jun 17, 2010, 3:14:34 PM (14 years ago)
Author:
NormOlsen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MapGuide

    v1 v2  
    1 See the [WikiStart main page].
     1= !MapGuide RFC 98 - EPSG Code Upgrade =
     2
     3This page contains an change request (RFC) for the !MapGuide Open Source project.
     4More !MapGuide RFCs can be found on the [wiki:MapGuideRfcs RFCs] page.
     5
     6
     7== Status ==
     8
     9||RFC Template Version||(1.0)||
     10||Submission Date||(Date/Time submitted)||
     11||Last Modified||(your name here) (modification date here)||
     12||Author||(your name here)||
     13||RFC Status||(draft, proposed, frozen for vote, adopted, retracted, or rejected)||
     14||Implementation Status||(pending, under development, completed)||
     15||Proposed Milestone||(e.g. 1.1, 1.3, 2.1)||
     16||Assigned PSC guide(s)||(when determined)||
     17||'''Voting History'''||(vote date)||
     18||+1||Bob, Andy, Haris||
     19||+0||Paul||
     20||-0||Tom, Bruce||
     21||-1||Jason (troublemaker)||
     22||no vote|| ||
     23
     24== Overview ==
     25
     26CS-MAP RFC 2 will add to the content of the coordinate system dictionary the EPSG code, SRID code, and the EPSG quadrant code for all systems for which this information is known.  It is proposed thatthe coordinate system API be expanded to expose this new information to the MapGuide community.
     27
     28Also, it is proposed that an overload to the MgCoordinateSystemCatalog constructor be added such that the path to the dictionary folder can be specified upon construction of the catalog (in addition to the current constructor which uses an environmental variable).
     29
     30== Motivation ==
     31
     32EPSG and Oracle SRID codes are becoming essential meta data associated with system definitions.  The CS-MAP RFC 2, upon approval, will populate currently unused elements of the Coordinate System Dictionary record with EPSG and Oracle SRID codes.  Additionally, the Datums dictionary and the Ellipsoid Dictionary will have unused elements populated with EPSG codes (there are no Oracle SRID codes for datusm and ellipsoids).  Implementation of this RFC will simply expose this data to the MapGuide community.
     33
     34There exists an axis swap problem when dealing with several data repositories.  Essentially, the problem stems from the official definition requiring that the northing be the first ordinate of a coordinate.  Since this produces a rotated image in most graphic systems this distinction is ignored in many CS-MAP definitions.  CS-MAP RFC #2 proposes to include the "officially blessed" (read EPSG) ordinate order in the coordinate system definition and this RFC proposes to simply expose this information to the MapGuide community.  Having access to this information, an application can compare the CS-MAP quad value to the EPSG quad value and chose an appropriate action baded on this comparison.
     35
     36== Proposed Solution ==
     37
     38Implementation is rather simple.  Four additional intface functions will be added as follows.  No exceptions are thrown, the API's simply return zeros if the information is not available.
     39
     40    * INT32 MgCoordinateSystem::GetEpsgCode()
     41    * INT32 MgCoordinateSystem::GetEpsgQuadrant()
     42    * INT32 MgCoordinateSystem::GetSridCode ()
     43
     44The return value of the GHetEpsgQuadrant is a value with the same meaning as the MgCoordinateSystem::GetQuadrant() member which is (X == first ordinate, Y == second ordinate):
     45
     46    1   X increases to the East,  Y increases to the North
     47    2   X increases to the West,  Y increases to the North
     48    3   X increases to the West,  Y increases to the South
     49    4   X increases to the East,  Y increases to the South
     50   -1   X increases to the North, Y increases to the East
     51   -2   X increases to the North, Y increases to the West
     52   -3   X increases to the South, Y increases to the West
     53   -4   X increases to the South, Y increases to the East
     54
     55== Implications ==
     56
     57No existing interface is changed.  Three new interface functions are added to expose new inofrmation.  The new interfaces will not throw exceptions.
     58
     59== Test Plan ==
     60
     61A test porogram which compares the results returned by the new interfaces to the values obtained from the current NameMapper will be implemented.
     62
     63== Funding/Resources ==
     64
     65Developement resources and funding to be provided by Autodesk.