Hi Martin, Justin, So I understand then, that ReferencedEnvelope should be used only in 2D case, and in the case of uDig it is acceptable, as it displays geometries in 2D, and only JTS geometries (afaik).
But at org.geotools.feature.FeatureImpl.getBounds() it seems a bit more problematic to me. It uses ReferencedEnvelope too, so any datastore, that provides non-2D CRS-es is forced to extend this default implementation, and override getBounds(). Is it intentional? Also strange to me, that getBounds() tries to add all the geometry attributtes to the returned envelope, but I don't see why should all the geometries be given in the same CRS. (So a feature with two geometries given in different CRS-es will generate an exception.) Peter Martin Desruisseaux wrote: > Bolla Péter a écrit : >> So my question is if there was any considerations about non-2D CRS-es >> when these classes (ReferencedEnvelope, JTS, and I guess some others) >> were designed, or not. > > The referencing module is designated for n-dimensional CRS. As Justin point > out, > you can use GeneralEnvelope. Many (but not all) transformation methods should > work with 3-D envelopes. > > ReferencedEnvelope is basically a "JTS-GeoAPI" bridge. While GeoAPI is n-D, > the > JTS library is restricted to 2-D. Most of the GeoTools library is build on top > of JTS, and consequently inherit the 2-D restriction from JTS. > > We could relax the ReferencedEnvelope constructor. But doing so is likely to > just delay the exceptions rather than elimitating then, because Referenced > Envelope is a JTS-GeoAPI bridge and JTS do not handle true 3D. The current > behavior come from the rational that sooner an error occurs, easier and less > costly it is to fix. If you pass a 3D CRS to a library that do not support 3D, > it will be easier to identify the problem if the exception occurs right at the > CRS setting time rather than later in a deep calculation loop. > > There is a new geometry module in GeoTools, which is a partial implementation > of > ISO 19107. The later cover both 2D and 3D cases, and may be used as a > replacement for JTS in a future GeoTools version (actually our ISO 19107 > implementation would be backed by JTS for the 2-D case under the hood, but the > 3-D case will requires a brand new set of implementation classes). > > > 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
