On Fri, Aug 3, 2012 at 3:09 PM, Niels Charlier <ni...@scitus.be> wrote:
> 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?
That you need to implement that method, otherwise encoding filters in
CQL/XML will be impossible.
>
> * 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.
Have you tried to do any reprojection, or use compound CRSs, and/or try to
switch from
a compound one to a fully 3d one? Afaik none of these work.
Reprojection in WMS and WFS is bread and butter,
not being able to support it is going to be a serious issue.
>
>
> * 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 can never related to this line of reasoning where "we'll make it faster
later" due to two reasons:
* performance can always be improved, high performance cannot be
retrofitted though, it has to be designed
* temporary solutions have the bad habit of becoming permanent, the risk of
going out and releasing something
that may kill a production system because the funds to "make it faster"
dried up worries me quite a bit
How sure you are that you're going to implement proper encoding of 3D
bboxes at the very least for JDBC
stores (and possibly for shapefiles as well?)
>
>
> * 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?
Same concern here, if you cannot parse a 3D bbox how are you going to make
WFS queries possible?
WMS wise, how are you going to deal with the 3D bbox? What about CQL
filtering, or in SLD filtering?
All of these will need some way for 3D bboxes to be parsed and encoded back
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
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
