Ciao Andrea, please, see below... ------------------------------------------------------- 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 3:30 PM, Andrea Aime<[email protected]> wrote: > Simone Giannecchini ha scritto: >> >> 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. > > Yeah, I definitely don't have time nor the will to push for yet > another API change (FeatureSource.getBouds() returns a > ReferencedEnvelope explicitly). > > Yet, for my deadline I don't need a 3d envelope at all, what > I need is to be able to go from postgis to a 3d KML on 2.5.x/1.7.x > That does not require any envelope computation. > > I tried to add the envelope bit to the proposal to improve it, > but I can remove it too. I guess the dilemma is, should the envelope > represent the coordinates, and thus the compromise proposed on > the coordinates (nd, but you don't see if you don't want to) > or should it follow the CRS instead? > > The main driver, to me, for having a ND envelope is to have, one day, > the ability to encode a 3D envelope in GML responses that carry > 2d+1 geometries. But I don't need that today. > So if this part of the proposal is creating troubles I can simply > drop it, it will just be less work for me :) As I said above, I don't want to cause a sterile discussion and waste your time, but if you don't care about what the dimensions beyond 2D really are, it would be probably better to not touch ReferencedEnvelope right now, at least IMHO. If this is feasible then I am +1, if not then I am 0. 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
