Hi, Martin Desruisseaux wrote: > Bolla Péter a écrit : >> I'm still working on using n-dimension CRS-es. My goal was to let >> uDig display the 4d geometries of the gpx datastore (x,y,z,t). As >> JTS is fine with working only with the first two ordinates, and >> just storing the other two, I started to relax GeoTools classes >> wherever I hit a check for 2d CRS. So relaxed the check in >> ReferencedEnvelope, and modified the JTS utility class, where it >> had a method for transforming a ReferencedEnvelope. > > At this time, the GeoAPI BoundingBox interface states explicitly that > an Envelope that implements BoundingBox (like current > ReferencedEnvelope) must be 2 dimensional. We could decide to relax > the BoundingBox contract. I'm not sure if it would be a good thing or > not. Maybe Jody as an opinion? > > Relaxing the check in ReferenceEnvelope would allows violation of > this contract. Methods that expect an ReferencedEnvelope in argument > (for example because the implementor intented to restrict the > envelope to 2D case because of limitation in his algorithm, and > wanted this check to be performed at compile-time) may break, because > the method could now receive 3D or 4D envelopes that the code is not > prepared to handle. >
There is a hibrid way, if I'm right, that might be only a partial solution, but a first step: I don't really need right now an envelope class, that takes each axle into account when doing the topologic operations. That is, an envelope around a geometry may remain 2D, but it should acceppt Nd CRS-es, and the appropriate geometries, and use only the first two ordinates. The question is, wether the standards say anything about ordinate order, so that we can count on lat/lon or x/y being the first two. But we may assume that silently. > I'm not aware of any direction given by ISO or OGC, but yes filling > the new ordinates with NaN is probably the best thing to do. Some > other users requested exactly the same thing recently on the mailing > list. Actually I would like to make in an option, with the exception > thrown by default (because trying to go from 2D to 3D is often an > error that we want to detect) but give the user the ability to > specify instead a fill value (NaN, or maybe some user will want 0). > However it would require a little bit of work in the referencing > module. Sounds good :) So I'm not the only one working with similar things :) Do you think you'll have time for this soon, or if I'd like to have something like that, then I'll better start to learn the referencing module, and do it myself? (At least try to do it :) ) btw: in DefaultGeographicCRS WGS84 and WGS84_3D have different lat/lon order. I guess it's not intentional, is it? Peter (btw, Jody, Bolla is my last name, I only write it in eastern order, as I'm from Hungary :) ) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
