> So, the basic idea was to use a real 3D CRS and > have everything else learn how to handle it.
Yep that was my plan; I like data structures to be accurate and a single point of truth :-) > Unfortunately I've stumbled into a number of issues: > - all of our code uses ReferencedEnvelope, which is > limited to 2D data. Basically, every time there is > code trying to build one we should take care of > using CRS.getHorizontalCRS to extract only the > 2D part of it before building or transforming > a ReferencedEnvelope (this means, many, many places, > not only datastores, but also wrappers, rendering, and > in GeoServer, UI and configuration). Can we expand the ReferencedEnvelope to support 2.5D? There are several implementations around that support this so we can steal some code; the only magic thing about ReferencedEnvelope is that it is also a JTS Envelope. > Either that, or stop using ReferencedEnvelope altogheter and use a > n-dimensional > ready alternative instead I would rather all referenced envelope to do more. > - a few parts of our code try to invert MathTransform > objects. This is usually related to computing the > source bounds to be queries given the destination > bounds. Too bad a 3d -> 2d transformation (the > common case in rendering) is not invertible (due > to information loss). I cannot think of a way around this at all; I wish we could use NaN to indicate "don't care" or infinite bounds for the Z range. > So, it seems the rest of the world is doing 3D by > declaring 2D srs and just using 3d coordinates... > can't we do the same? ;-) Okay I see the approach. > How do we do the same, thought? > A few ideas to store the dimensions: > - JTS CoordinateSequence does have a getDimension > method. We can use custom coordinate sequences > that allow us to specify the dimensionality > there > - GeometryDescriptor could contain a "well known" > COORDINATE_DIMENSION hint inside its userData > section Let me add one to that list: - Can we provided a hint to CoordianteReferenceSystem data structure? Or even just declare a larger dimension them the number of axis defined? The other suggestions are fine as well; I am not sure if the Hint or GeometryDescriptor are available when a lot of the coordinate manipulation occurs. > As for geometry transformations are concerned, we > should rewrite the transformation code so that it > transforms the flat part but preserves the z and > m if available (the current code will wipe them > out instead). Okay I understand. > Opinions? Thanks for assembling the background of the problem in a clear fashion. I would like to see if we can extend CoordinateReferenceSystem so we maintain a single point of truth describing how ordinates are being maintained. Is this a good idea? Jody ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
