Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3


This proposal attempts to bring some 3D support into GeoTools, to the extent that is already covered by various other software.
In particular, the geometry coordinates will be allowed three (or more) dimensions, whilst the coordinate reference system used will still be two dimensional. This approach is already followed by various software around:

  • PostGIS, which only handles two dimensional SRS but has an explicit coord_dimension column to declare the actual dimension of the coordinates
  • GML3 posList element, which has at the same time a srsName and a srsDimension attribute, allowing the two to be out of synch. Various CityGML examples do in fact sport a 2D SRS (or no SRS at all) but explicitly set srsDimension="3"
  • shapefiles generated by ESRI sofware typically have a 2D WKT definition in the shapefile.prj file whilst the shapefile nature is pointz or arcz
  • Oracle Spatial previous to 11G, and even 11G without explicit settings, allow 3D data to be handled whilst the spatial reference system used is by dimensional.

All the above systems make no different between a Z and a M (measure), basically handling every dimension past the first two as sort of out of band information that does not get transformed when the first two dimensions are.
In particular, coordinate system transformations do change the planar part whilst the extra dimensions are carried over unaltered.

The proposed changes to the GeoTools code base are relatively small:

  • allow data sources that happen to have non flat data to return it as is, unless the existing Hints.FEATURE_2D is passed down (in which case, the geometries will be flattened as today)
  • keep the current flat CoordinateReferenceSystem in the GeometryDescriptor, and add a well known COORDINATE_DIMENSION entry in its userData map so that the coordinate dimensionality is explicit even in absence of data (for code that needs to deal with metadata only)
  • leverage the CoordianteSequence.getDimension() when only the geometry is available (this might mean we'll need to subclass the default JTS coordinate sequence, CoordinateArraySequence, as that has a hard coded dimension of 3, so that we can report the actual dimension, or else, to check the Z of all cordinates in it and decide the real dimensionality based on the values of the Z, 2d if the Z is always a NaN, 3d if there is at least one non NaN value)
  • extend RefencedEnvelope to support more than 2 dimensions
  • modify the geometry and envelope transformation code so that only the first two dimensions are transformed, whilst the other dimensions are carried along unaltered

Previous discussion

The topic has already been publicly discussed on the mailing list in this thread: