I think we may have to bump up the abilities of ReferencedEnvelope to handle more axis; at the end of the day it is looking like a default implementation of BoundingBox that happens to implement JTS Envelope in order to facilitate migration. Note: BoundingBox interface *is* a GeneralEnvelope with a couple of helper methods.
As GeoServer and uDig take on the "t" dimension I expect we will need BoundingBox interface to have a couple more helper methods allowing us to ask for the temporal extent. Jody > Hi Péter, > > So yeah.. I definitely dont think ReferencedEnvelope will cut it for you > if you are interested in 3D. What might work for you "GeneralEnvelope", > which you can find in the referencing module. I have never really used > this class before so i cant really comment but it appears to be just > what you need. A referenced envelope that does not make a 2D assumption. > > -Justin > > Bolla Péter wrote: > >> Hi again, >> >> I worked on this a little... >> After changing the condition, I could create the ReferencedEnvelope. But >> the CRS of the envelope was still the 3D CRS, so now the >> JTS.transform(...) fails, which checks for exactly 2 dimensions too. >> >> 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. >> If there were, then there should be a particular way to handle non-2D >> CRS-es properly, I guess, and only I don't know it. In this case I >> should learn about that. >> However, if there were no considerations, then it would be nice, if >> there would be :) >> >> >> Thank you, >> Peter >> >> >> Bolla Péter wrote: >> >>> Hi all, >>> >>> While I was working on a plugin for uDig, it occured to me, that the >>> org.geotools.geometry.jts.ReferencedEnvelope throws an exception from >>> the constructor, if I try to set the CRS to a CRS with not exactly 2 >>> dimensions. I guess there is a reason for this, but I don't see it :) >>> What would be the problem if I would set a 3 dimensional CRS? As I saw >>> every method works with the firs two coordinates hardcodedly, so there >>> should be no problems, if it would only check for 2 <= dimensions. >>> >>> With the current implmentation of the Default* classes, even a >>> SimpleFeature.getBounds() fails with the same error. >>> >>> Now I change the test for <=, and check if it works or not. >>> >>> Thanks, >>> Peter >>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> >> ------------------------------------------------------------------------- >> 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 >> >> !DSPAM:4007,471eb9f9214501431913854! >> >> > > > ------------------------------------------------------------------------- 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
