Changes between Version 7 and Version 8 of MapGuideRfc98


Ignore:
Timestamp:
06/21/10 14:23:47 (15 years ago)
Author:
brucedechant
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • MapGuideRfc98

    v7 v8  
    1414||Implementation Status||pending||
    1515||Proposed Milestone||2.3||
    16 ||Assigned PSC guide(s)||(when determined)||
     16||Assigned PSC guide(s)||Bruce Dechant||
    1717||'''Voting History'''||(vote date)||
    1818||+1|| ||
    … …  
    2424== Overview ==
    2525
    26 CS-MAP RFC 3 proposes to add three items to the coordinate system dictionary, and one item each to the Datums and Ellipsoid dictionaries.  (The format doesn't change, we'll be using currently unused holes in the structures.)  This RFC proposes to expose these new data values through the MgCoordinateSystem interface.  The items being added are EPSG code, Oracle SRID code, and the EPSG Quadrant code.
     26CS-MAP RFC 3 proposes to add three items to the coordinate system dictionary, and one item each to the Datums and Ellipsoid dictionaries.  (The format doesn't change, we'll be using currently unused holes in the structures.)  This RFC proposes to expose these new data values through the !MgCoordinateSystem interface.  The items being added are EPSG code, Oracle SRID code, and the EPSG Quadrant code.
    2727
    2828== Motivation ==
    2929
    30 The EPSG code and the Oracle SRID code are becomming frequently desired/referenced data items.  Conversion between CS-MAP key name and EPSG code is currently possible, but requires the use of the NameMapper which can be painfully slow if one intends to map large segments of the EPSG code set.  While supported in the NameMapper, mapping between CS-MAP key names and Oracle SRID codes is not expsed through the MgCoordinateSystem interface.  Implementation of this RFC would, in conjunction with CS-MAP RFC 3, enable direct access to both codes using the MgCoordinateSystem interface.
     30The EPSG code and the Oracle SRID code are becomming frequently desired/referenced data items.  Conversion between CS-MAP key name and EPSG code is currently possible, but requires the use of the !NameMapper which can be painfully slow if one intends to map large segments of the EPSG code set.  While supported in the !NameMapper, mapping between CS-MAP key names and Oracle SRID codes is not expsed through the !MgCoordinateSystem interface.  Implementation of this RFC would, in conjunction with CS-MAP RFC 3, enable direct access to both codes using the !MgCoordinateSystem interface.
    3131
    32 There exists a problem encountered when using the latest version of WMS specification.  This new specification now requires strict adherence to the axis specifications in Coordinate Reference System (CRS) definitions.  CS-MAP RFC 3 calls for the addition to the coordinate system dictionary an quadrant value (using the same values as the standard CS-MAP quad parameter) which indicates what the EPSG definition indicates the axis specification to be.  Implementation of this RFC will expose this value through the MgCoordinateSystem interface.
     32There exists a problem encountered when using the latest version of WMS specification.  This new specification now requires strict adherence to the axis specifications in Coordinate Reference System (CRS) definitions.  CS-MAP RFC 3 calls for the addition to the coordinate system dictionary an quadrant value (using the same values as the standard CS-MAP quad parameter) which indicates what the EPSG definition indicates the axis specification to be.  Implementation of this RFC will expose this value through the !MgCoordinateSystem interface.
    3333
    3434== Proposed Solution ==
    3535
    36 Implementation of this RFC would be achieved by adding three new methods to the MgCoordinateSystem interface, and one new method to each of the MgCoordinateSystemDatum and MgCoordinateSystemEllipsoid interfaces as follows:
     36Implementation of this RFC would be achieved by adding three new methods to the !MgCoordinateSystem interface, and one new method to each of the !MgCoordinateSystemDatum and !MgCoordinateSystemEllipsoid interfaces as follows:
    3737
    38 INT32 MgCoordinateSystem::GetEpsgCode (void);[[BR]]
    39 INT32 MgCoordinateSystem::GetSridCode (void);[[BR]]
    40 INT16 MgCoordinateSystem::GetEpsgQuadrant (void);[[BR]]
    41 INT32 MgCoordinateSystemDatum::GetEpsgCode (void);[[BR]]
    42 INT32 MgCoordinateSystemEllipsoid::GetEpsgCode (void);[[BR]]
     38{{{
     39INT32 MgCoordinateSystem::GetEpsgCode (void);
     40INT32 MgCoordinateSystem::GetSridCode (void);
     41INT16 MgCoordinateSystem::GetEpsgQuadrant (void);
     42INT32 MgCoordinateSystemDatum::GetEpsgCode (void);
     43INT32 MgCoordinateSystemEllipsoid::GetEpsgCode (void);
     44}}}
    4345
    4446All methods will return a zero if the information is unknown; no exceptions will be thrown.
    … …  
    6365== Test Plan ==
    6466
    65 A test function will be written which will cycle through the three dictionaries affected and the results of these new methods compared to the current contents of the NameMapper.  This effort will be done at the CS-MAP level.  As these methods are simple one liners, no special test module is being planned at the MgCoordinateSystem level.
     67A test function will be written which will cycle through the three dictionaries affected and the results of these new methods compared to the current contents of the !NameMapper.  This effort will be done at the CS-MAP level.  As these methods are simple one liners, no special test module is being planned at the !MgCoordinateSystem level.
    6668
    67 == Funding/Resources ==
     69== !Funding/Resources ==
    6870
    6971Software developement resources and funding to be provided by Autodesk.