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.
In addition, the CRS dimension must match the value returned by
ReferencedEnvelope.getDimension(), which is 2 (hard-coded if I remember right).
A possible path may be to:
- Rename "ReferencedEnvelope" as "ReferencedEnvelope2D".
- Make sure that all existing GeoTools and GeoServer methods
use ReferencedEnvelope2D
- Create a new "ReferencedEnvelope" class, which is basically the same
than "ReferencedEnvelope2D" but doesn't implement BoundingBox.
- Ensure that ReferencedEnvelope.getDimension() returns the right value
(I'm not sure how).
- Set ReferencedEnvelope2D as a subclass (specialization) of
ReferencedEnvelope. Remove duplicated code.
- If there is some piece of code in Geotools that doesn't require a
2D envelope, we could relax the argument type from ReferencedEnvelope2D
to ReferencedEnvelope for those methods.
> Then I hit a point where I couldn't get through. uDig for some reason
> wanted to create a transfromation from a 2d CRS to the 4d one. (I guess
> for calculating featureset coordinates from map coordinates) But that is
> something that GeoTools is not prepared for. (I guess because it is not
> fully defined, how to generate the two missing ordinates.)
Yes. There is no way Geotools can guess what to do with the 2 new ordinates.
> I don't know what the ISO standard says about this, maybe nothing. What
> I could imagine as a solution is that every axle could have a "not-set"
> value, e.g. Double.NaN, and such transformations (2d->4d) could fill the
> undefined ordinates with this value.
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.
Martin
-------------------------------------------------------------------------
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
