Jody Garnett ha scritto: >> 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.
Yeah, it might be a good idea. If we look into the CityGML samples, the bbox is 3d even if the SRS is missing or declared as 2D. On the other side, if we look at OGR output, the output has 3d coords and a 2d envelope. Just not sure if I can find funding to do this part of the work as well (heck, I don't know if I can get funding to do even part of it...) >> - 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. Nah, this is not possible. Transformation do handle a whole array of points, we need some meta information available when the transformation is setup and the to be transformed arrays are created in order to decide what to do. Because, if we want to preserve the z untransformed, we have to copy the xy into the transformation array, transform, and then create back a sequence of xyz taking the transformed xy but the old z (or the old m, or zm). >> 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? Althought we have to lie somewhere, the idea of lying inside the coordinate system itself (CoordinateSystem interface) is not appealing for a simple reason: we are building the cooordinate systems using the CRS facade, and the internal do pick directly on the EPSG database, which is consistent. In order to go out with such a lie we would have to replace the CoordinateSystem contained inside the CoordinateReferenceSystem, and thus rebuild it (these objects are immutable). Plus, we'd break the CoordinateSystem interface, where there are two methods, a getDimension() and a getAxis(dimensionIndex)... what do you return for the third axis that is not really there? Long story short, lying in the CRS breaks common interfaces, puts us at odds with GeoApi, and does not get any further than putting the dimensions in any other position I proposed. The coordinate sequence position is the most promising imho, as the transformation code has to deal with it anyways, and it can compare the cs dimension with the srs one and learn it has to play the "copy coordinates beyond the first two over" trick. The day we have a real 3d system and real 3d coordinates we just skip the trick and nothing else is required. Smallish change, most of the benefit out. All is required is that code willing to deal with ordinates other than x and y pays attention to the CoordinateSequence dimension (this is, rendering, xml and kml encoding, geometry transformation). Everything else can just go on assuming the CRS and the coordinate dimensions are consistent, and will just skip the extra ordinates embedded in the geometry. I have a slight chance of finding funding for the above. For a fuller change, no luck. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ 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
