On 08/03/2012 03:55 PM, Andrea Aime wrote:
On Fri, Aug 3, 2012 at 3:09 PM, Niels Charlier <ni...@scitus.be
<mailto: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.
Okay, no problem, but is the above suggested solution good for you? This
is how it happens for ReferencedEnvelope3D's.
* 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 am actually currently working on 3D reprojection atm, but it is a
whole other feature. I am surprised you say this because I though a few
months ago somebody on the list said that 3D reprojection should already
work, and my tests seem to suggest this is in fact the case (with some
minor changes).
In any case, I am not really clear how this is in the way of the changes
I am proposing here.
Or, what is it exactly that you want me to change or improve here in my
proposal or patch?
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 do need to clarify: I am not saying : we are going to implement
something a bad way now, and make it better later. That would be indeed
a bad line of reasoning. What I am doing here is absolutely *necessary*
work for 3d bbox filters, and there is nothing programmed in a bad
quality there. The post-filter is the first requirement, so it is the
first thing that needs to happen. It it better to have a post-filter
implementation than no implementation at all (There are other things in
geotools that only work with post-filters, functions like concat.) It
cannot possibly hurt anyone to have this feature.
I think we need to take it one step at a time, otherwise I need to
make a patch so big that it is too big to review and if it doesn't get
approved a lot of work is lost. The bounding box will need to be
implemented for every possible dbms differently, and yes it will not be
so easy at all.
I think the post-filter implementation proves that it can work, and lays
the foundations for further development in this direction. But we can't
do and support everything at once.
* 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
There is no 3d bbox in WMS as of yet, this is only the implementation of
a WFS 3d bbox.
Again, we need to take it one step at a time. But in WFS, the 3d bbox
works as proven in the unit tests included in the patch.
Regards
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
