Most data values that we use in our models are defined at some (x,y,z) locations. For the time being we will focus on the horizontal coordinates only. These coordinates are always specified in some coordinate system, such as WGS84, Rijksdriehoek, some UTM projection, etc. At this moment our software systems do not know about these different coordinate systems in general, only Delft3D distinguishes between spherical and cartesian coordinates. Where the former is generally asumed to be equivalent to WGS84 (coordinates specified in degrees longitude and latitude) while the latter is a general projection on some local coordinate space with perpendicular x and y directions (coordinates measured along these axes in metres). In several cases one would like to perform coordinate transformations on sets of coordinates:

  1. dataset was provided in coordinate system A, but needs to be used in conjunction with a model in system B
  2. dataset is given in coordinate system A whereas visualisation is using system B
  3. dataset is given in (cartesian) coordinate system A whereas file format requires storage in system B (e.g. WGS84 in case of NetCDF CF-conventions)
  4. a schematisation in coordinate system A needs to be coupled to a schematisation in coordinate system B

In all cases it is important to have more information about the coordinate systems than it being spheric or cartesian. This information needs to be stored in a standardised way for automated use by the software components that will process or display the data. For this purpose we need to store for each georeferenced dataset which coordinate system it uses as reference. For all numerical schematisations this starts by storing the coordinate system of the initial network, grid or mesh.

So, let's start with the source of a Delft3D simulation, the RGFGRID file *.grd.

How do we project the grid data to the screen?

Currently the RGFGRID file format contains information about the kind of the data.
This can be either cartesian or spheric. The spheric option implies that the WGS84 is used (R=6378137.0). WGS84 is only valid until 2010.
The cartesian implies that a local x y is used, so the distance betweeen two points can be determined with Pythagoras (ds^2 = dx^2 + dy^2). The center is not specified. If the ArcGIS frontend is used the source reference system for a new grid is given by ArcGIS.

The (display) target can be specified as spheric or cartesian. The display projection is not relevant for the Delft3D model and is a transient property of the visualisation only. In other cases (as indicated above) the conversion of the data is more persistent (e.g. file storage).

We're trying to improve this part of the software by

  • Using gdal/ogr for doing the reprojection calculation
  • Using the EPSG for standardization of the projections
  • Using WKT as exchange format for projection information
  • Making a udig like projection selection dialog.

This will allow users to explicitly define which information is or is not available about the coordinate system and more easily select which coordinate system to use.

The sources are set up under http://svn/repos/gis-plugins.
Relevant utils:
http://fwtools.maptools.org/ compiled binary under windows
http://www.gdal.org source for gdal information (get package gdal-dev to develop under linux)

3 Comments

  1. Unknown User (don)

    Thanks for posting it!

    Experience with WKT/WKB and libraries like OGR/GDAL will be very useful indeed.

    For more options You may also check these libraries:

    One question: is it necessary for tools like RGFGRID to work with those coordinate systems or should such functions be provided only by higher-level environment, for example map front-end / map control like ArcMap? In most practical examples algorithm is not interested in processing data in different projections.

    1. Fedor Baart AUTHOR

      I think the algorithms as in for example the flow model should not know about coordinate systems. The grid editing tool could know.

      The example of a grid editing tool where it is usefull to have the coordinate system known was shown by Maarten van Ormondt.

      1. Unknown User (don)

        Map control should certainly know it in order to do reprojection when data are sent from different components working in different coordinate systems. But grid editor logic most probably should not since we're not creating grids which are defined on 2 CRS. However it may be useful to have CRS definition as attribute together with grid.