Hi Andrea, Thank you for look at it ! Here are some answers to your questions and concerns:
> Looked at the proposal and the patch, a few questions: > * the proposal should tell how are you addressing the dicotomy between > CoordinateReferenceSystem and the SRS string which is required by the > BBOX interface (the CRS might not have a way to be represented as an SRS) How is this different than creating a BBOX filter from a non-3D ReferencedEnvelope. I notice the following method is used: CRS.toSRS( bounds.getCoordinateReferenceSystem() ) I could do this for ReferencedEnvelope3D 's too. At the moment, I am not even implementing the getSRS method because I partially based myself on the FastBBOX implementation who doesn't either. The method is deprecated anyway. In any case, this is not an issue that is specific of using a ReferencedEnvelope3D instead of a ReferencedEnvelope to represent the bounding box and crs. What do you think? > * ReferencedEnvelope3D extends ReferenceEnvelope (not > ReferenceEnvelope3D)... this is just a typo anyways > * It would be nice to have > ReferencedEnvelope.reference(org.opengis.geometry.Envelope) method > building the proper > ReferencedEnvelope object based on the number of dimensions of the > provided Envelope Sure, can be done. > * for the trasform method imho a better, but simple implementation > would be to reproject the x,y and leave the Z > unaltered (but preserve it). This is what JTS.tarnsform(Geometry, > MathTransform) does today, so it would also preserve > consistency within the library Okay, I can do that. > * About the usage of the CRS to determine if the dimensions are 3 I > have my doubts... the support for 3D CRS is > not very good in GeoTools, I believe the common usage would be 2d+1 > with a 2d crs with 3 ordinates I am not really sure I know what you mean here. I think only in the app-schema test code I take the dimensions from the CRS, but this seems to work fine, it seems to be in line with the official descriptions of the CRS's. Geoserver does accepts a third coordinate even when you use for example EPSG:4283, which is strictly a 2D CRS, but the correct way to do this is use the newer EPSG:4979 instead which does officially support 3 coordinates. I think the correct behaviour is used for testing and proven to past. > * I see BBOX3D is a new type of filter that the stores need to > implement support for. Which means right now we're > going to have full in memory evaluation of these 3d bboxes for all > stores, which is going to be tremendously slow. This is true. But I think in any case, the post-filter must initially be supported as a fallback at all times. Support on SQL level needs to be programmed for each DBMS type individually. I left this option open, but the changes do not include this. I think they should best be implemented afterwards to improve performance, once we have the core functionality implemented. > * I see no support for building a BBOX3D filter by parsing XML or CQL, > which means there is no real way to use it besides > building it programmatically, how is this going to be handled? > I am not sure if I understand you question completely, but is it possible the above answer apply to this also? Niels ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
