Motivation:

Stepping up from a pure 2d world to partial 3d support, the OGR,PostGIS,MapServer way

Contact:

Andrea Aime

Tracker:

http://jira.codehaus.org/browse/GEOT-2537

Tagline:

Handling 3d data in a 2d world

This page represents the current plan; for discussion please check the tracker link above.

Description

At the time of writing GeoTools is aggressively making sure only 2 dimensional data enters feature geometries. In particular, in most data sources that might have a 3D component the code is flattening the coordinates so that only the horizontal component is provided.
Coordinate reference systems are always 2 dimensional, too. Finally, only 2 dimensional geometry types are handled (JTS types).

On the other side of the 3D support spectrum there are 3 or more dimensional coordinate reference systems (fully 3D, or compound), 3D coordinates and solid geometries (such as spheres, cones, boxes).

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:

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:

Previous discussion

The topic has already been publicly discussed on the mailing list in this thread: http://n2.nabble.com/Handling-2D%2B1-data-in-GeoTools-td2739186.html#a2739186

Status

This proposal is under construction.

Voting has not started yet:

Tasks

This section is used to make sure your proposal is complete (did you remember documentation?) and has enough paid or volunteer time lined up to be a success

 

no progress

(tick)

done

(error)

impeded

(warning)

lack mandate/funds/time

(question)

volunteer needed

  1. declare the COORDINATE_DIMENSION hint in Hints (aaime)
  2. modify the PostGIS datastore to add the hint in the feature types built, avoid flattening data while reading by using EWKB format, and add support for the FEATURE_2D parameter (aaime)
  3. change the rendering code to force 2D coordinates when reading (aaime)
  4. change the geometry transformation code to carry on the third dimension (aaime)
  5. update the docs
  6. upgrade the shapefile datastore (question)
  7. upgrade the jdbc-ng datastores (question)

Updating the datastores to allow returning the third dimension is an activity that can be performed in time, a datastore that keeps behaving as before won't be broken by the changes and won't affect client code either (it will just miss the ability to return multidimensional data).

API Changes

Since access to coordinate dimensions is explicit and JTS always offered a Z in the Coordinate class, no real change in the user code is needed. Only, if certain code absolutely needs 2D data, it will have to pass down the FEATURE_2D hint, like this:

   FeatureSource fs = ...;
   DefaultQuery q = new DefaultQuery("my3dType");
   q.setHints(new Hints(Hints.FEATURE_2D, true));
   FeatureCollection coll = fs.getFeatures(q);

Also, it is expected ReferencedEnvelope to gain support for further dimensions. The interface is already n-dimensional capable, but fields will need to be added to support dimensions over the first two.

Documentation Changes