Hi Andrea,
Thank you for your time!
On 08/12/2012 04:09 PM, Andrea Aime wrote:
There is a mix of things that confuse me a bit here:
* the method in the transformation is purely 2D anyways, you won't get
a 3D envelope out of it (it samples the 2D perimeter of the original
bounds
to make
On Wed, Aug 8, 2012 at 3:43 PM, Niels Charlier ni...@scitus.be wrote:
Okay,
The proposal has been updated and a new patch has been uploaded :)
Thanks Niels,
looked at the patch, seems like a solid improvement.
One part that still makes me wonder is this one:
diff --git
Okay,
The proposal has been updated and a new patch has been uploaded :)
Regards
Niels
On 08/07/2012 10:57 AM, Andrea Aime wrote:
On Mon, Aug 6, 2012 at 2:08 PM, Niels Charlier ni...@scitus.be wrote:
Update
Patch:
+ Implement
On Mon, Aug 6, 2012 at 1:06 PM, Niels Charlier ni...@scitus.be wrote:
On 08/06/2012 12:23 PM, Niels Charlier wrote:
Afaik this works the way I explained before, that is, the Z dimension is
left
unaltered during the reprojection.
Which is not true reprojection, but what we can afford given
On Mon, Aug 6, 2012 at 2:08 PM, Niels Charlier ni...@scitus.be wrote:
Update
Patch:
+ Implement
ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method
+ Implement better Transform method
+ Use CRS.toSRS( bounds.getCoordinateReferenceSystem() ) to return SRS
Hi,
I'm not saying that you have to do everything at once, can you answer
the simple question above though?
Restating it: 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 am sorry, I
Andrea,
I am trying to make an overview of all the changes that require me to do
to the patch and proposal to get them passed.
This is what I have so far:
Patch:
Implement
ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method
Implement better Transform method
Use
On Mon, Aug 6, 2012 at 10:45 AM, Niels Charlier ni...@scitus.be wrote:
The current patch and proposal does not include these features. However, I'd
understand that WFS post requests need to at least support the same features
as wfs get requests. Please let me know the minimum requirements with
Afaik this works the way I explained before, that is, the Z dimension is left
unaltered during the reprojection.
Which is not true reprojection, but what we can afford given that the vertical
transformation module is not working
I reprojected from WGS84 to WGS66 which only differ in their Z
On 08/06/2012 12:23 PM, Niels Charlier wrote:
Afaik this works the way I explained before, that is, the Z dimension is left
unaltered during the reprojection.
Which is not true reprojection, but what we can afford given that the
vertical
transformation module is not working
I reprojected
* 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
Actually, the
On 08/06/2012 01:56 PM, Niels Charlier wrote:
* 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
Update
Patch:
+ Implement
ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method
+ Implement better Transform method
+ Use CRS.toSRS( bounds.getCoordinateReferenceSystem() ) to return
SRS string in filter class
+ Remove filtervisitor hack and update
On Fri, Aug 3, 2012 at 11:55 PM, Andrea Aime
andrea.a...@geo-solutions.itwrote:
Take also into consideration the data sources, that has implication as
well.
In PostGIS you can declare a 2D CRS and then specify the number of
dimensions
is 3 or 4, that's perfectly fine with the database, and I
On Mon, Jul 30, 2012 at 11:11 AM, Niels Charlier ni...@scitus.be wrote:
http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters
Okay, so I decided to remove the Envelope3D class, and merge it with
ReferencedEvelope3D, and make
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
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
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
On Fri, Aug 3, 2012 at 9:11 PM, Niels Charlier ni...@scitus.be wrote:
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.
On Fri, Aug 3, 2012 at 9:11 PM, Niels Charlier ni...@scitus.be wrote:
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
On Tue, Jul 31, 2012 at 5:44 PM, Niels Charlier ni...@scitus.be wrote:
Oops it seems some new files are missing in the patch. My apologies,
will upload complete patch in a minute.
Looked at the proposal and the patch, a few questions:
* the proposal should tell how are you addressing the
Thanks Niels
+1 For me now, and yes I was slack as I was supposed to help you fix up the
proposal after voting -1 :(
--
Jody Garnett
On Monday, 30 July 2012 at 7:11 PM, Niels Charlier wrote:
+1 from me.
On 30/07/12 17:11, Niels Charlier wrote:
http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters
Okay, so I decided to remove the Envelope3D class, and merge it with
ReferencedEvelope3D, and make ReferencedEvelope3D derived from
I still don't see the new BBOX3D interface... looking at the latest patch
here:
http://jira.codehaus.org/browse/GEOS-5148
But all i wanted to see was if it extends the existing BBOX one which you
confirmed. So I would say I am +1 on this.
On Mon, Jul 30, 2012 at 11:13 PM, Ben Caradoc-Davies
Oops it seems some new files are missing in the patch. My apologies,
will upload complete patch in a minute.
On 07/31/2012 04:38 PM, Justin Deoliveira wrote:
I still don't see the new BBOX3D interface... looking at the latest
patch here:
http://jira.codehaus.org/browse/GEOS-5148
But all i
http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters
Okay, so I decided to remove the Envelope3D class, and merge it with
ReferencedEvelope3D, and make ReferencedEvelope3D derived from
ReferencedEnvelope.
I hope this addresses the previously
Looking much better Niels, i think this will slot in much cleaner.
Is BBOX3D a new interface? I was just looking through the patch and not
seeing it defined there although i do see the BBOX3DImpl class defined.
On Mon, Jul 30, 2012 at 2:11 AM, Niels Charlier ni...@scitus.be wrote:
Yeah it should definitely be in there. BBOX3D is the filter interface,
which extends BBOX.
On 07/30/2012 05:04 PM, Justin Deoliveira wrote:
Looking much better Niels, i think this will slot in much cleaner.
Is BBOX3D a new interface? I was just looking through the patch and
not seeing it
28 matches
Mail list logo
