------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Owner - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy
phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://simboss.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini ------------------------------------------------------- On Wed, Jun 10, 2009 at 2:30 PM, Andrea Aime<[email protected]> wrote: > Simone Giannecchini ha scritto: >>> >>> The main reason to have a 3d envelope class is to be able >>> and return the 3d envelope of 3d data sets as well. >>> As an alternative I guess I could sublcass ReferencedEnvelope, >>> but that would create even more confusion... >> >> >> It would probably make sense. Would it add a lot of load on you >> shoulders? > > Simone, > the whole point of the proposal, as is, is that you can safely ignore > the extra ordinates if you don't want/don't know how to use them. > Unless you pass down the FEATURE_2D hits to a 3d enabled data store > with 3d coordiantes stored in it, you'll get CoordinateSequence with > 3 or more ordinates. > Yet, if you don't care or don't know, you won't even notice. > cool. > With ReferencedEnvelope it should be the same, if you don't know/don't > care about the extra ordinates, you simply do not see them. > My suggestion above was a joke, as making a subclass would not change > anything, code that does not know will keep on just reading the > basic two dimensions, code that does care will take advantage of > the extra ordinates. > The difference having a subclass around will just be that the > code that cares will be riddled with instanceof checks. > > Can you better qualify how having extra ordinates (mind, it might > not be a Z, it might be a M) is going to create problems? > Besides what I wrote in the other email, I have been looking at referenced envelope as an implementation of bbox, because that' what really is. It also implements envelope for interoperability, but it is 2D only. Right now we are talking about changing the semantic of ReferencedEnvelope so that it will be able to handle nD data. IMHO if we had enough time it would be better to remove the usage of referenced envelope and use Envelope implementations (Envelope2D and GeneralEnvelope) because making ReferencedEnvelope able to handle nD data would add more duplication with what we already have and probably also some confusion (see change of semantic above). Conclusion is, yeah, I am not against this change since I know that you have deadlines to meet, but still, I am a bit concerned about the implications, therefore I would at least leave this point open for the future so that we can resolve duplications between the geometry pacakge in referencing and the JTS envelope sublcasses which is a child of the dicotomy between coverage and feature. Ciao, Simone. > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
