The Exchange Coordinate System

The SDM provides an Exchange Coordinate System.  All coordinates:

are referred to this system. In addition, all coordinates provided by the client as arguments to API methods must be referred to this system.  It is the developer's responsibility to ensure that this is the case.

The Exchange Coordinate System may be either geodetic or projected, i.e. LLDG or NEMR (See Map Types).  If the Exchange Coordinate System is geodetic, all coordinates returned by SDM services and supplied as arguments to clients are in CARIS standard format (See Standard Geodetic Strings), and all coordinates supplied as arguments to SDM services must be in this format. If the Exchange Coordinate System is projected, all coordinates returned by SDM services and supplied as arguments to clients are alphanumberic decimals, and all coordinates supplied as arguments to SDM services must be in this format.

The default Exchange Coordinate System is geodetic, i.e. latitude and longitude, consistent with the WGS 84 datum.  To change the datum while retaining geodetic coordinates, use overrideExchangeDatum.  To change to the coordinate system of an open map, use setExchCoordSysFromMapInView.  To change to the coordinate system of a map anywhere on your file system, use setExchCoordSysFromMap.  In either of the last two cases, if the chosen map uses projected coordinates (e.g. UTM), the SDM will immediately begin to return coordinates in the units of the projection (e.g. Northing and Easting), and expect to receive coordinates in those same units. 

The developer need only be concerned with supplying coordinates in the Exchange Coordinate System. If a view has a map that is using a different coordinate system, the incoming coordinates are automatically transformed from the Exchange Coordinate System to that of the target map.  In this way, the same coordinates can be supplied as arguments to maps in all views, regardless of the particular coordinate systems those maps may be using. If the Exchange Coordinate System happens to be the same as that of one of the maps, no transformation occurs.  Similarly, outgoing coordinates are transformed from the coordinate system of the originating map to the Exchange Coordinate System, before being made available to the client.  

There is one exception to the above rules.  If a view has a map of type NRMR (a non-registered map), no transformations are possible and therefore no transformations are performed.  Thus, it is the developer's responsibility to supply incoming coordinates in the map's own coordinate system and expect outgoing coordinates in that coordinate system. (See discussion of map types.)

Notes for SICOM v2.5 developers migrating to v3.2:

  1. In SDM v2.5, the concept of an exchange coordinate system does not exist, i.e. it is the developerís responsibility to worry about coordinate transformations.

  2. In SDM v2.5, by default, incoming coordinates must be in the coordinate system of the target map.  It is an error to use these same coordinates on a map with a different coordinate system.  Note that even a map with the same datum and projection, but with different parameterization (e.g. different origin or different false easting) would result in the features being placed incorrectly.  Similarly, outgoing data is by default in the coordinate system of the originating map.

  3. In SDMv2.5, the client has the option to exchange geodetic coordinates instead of projected coordinates, by calling SvcManager.setForGeodeticPositions.  However, incoming coordinates (latitudes and longitudes) are still assumed to be based on the datum of the target map. If geodetic coordinates are obtained from one map and then used to place a feature on another map with a coordinate system based on a different datum, the feature would be placed incorrectly.

  4. In SDM v2.5, a client which maintains an external database of transient features, where the coordinates stored in that database are projected coordinates corresponding to a particular map, would ensure that that map was opened and then immediately begin to place features on the map.  To migrate such a client to v3.2, after opening the map, but before placing any features, use setExchCoordSysFromMapInView.