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-solut
Andrea Aime wrote:
> Ben Caradoc-Davies ha scritto:
>> In 2D+1, is the main difference that the third dimension ignored by some
>> operations, such as coordinate transforms? I suspect 2D+1 will be OK for
>> line-strings, except when you try to change datum.
>
> Indeed. However there is no guaran
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
---
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.co
Simone Giannecchini ha scritto:
>> The main reason to have a 3d envelope class is to be able
>> and return the 3d envelope of 3d data sets as well.
>> As an alternative I guess I could sublcass ReferencedEnvelope,
>> but that would create even more confusion...
>
>
> It would probably make sense
---
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.co
Ben Caradoc-Davies ha scritto:
> Andrea Aime wrote:
>> Ben Caradoc-Davies ha scritto:
>>> In 2D+1, is the main difference that the third dimension ignored by
>>> some operations, such as coordinate transforms? I suspect 2D+1 will
>>> be OK for line-strings, except when you try to change datum.
>>
Ben Caradoc-Davies ha scritto:
> Andrea Aime wrote:
>> Ben Caradoc-Davies ha scritto:
>>> Consulting with a knowledgeable stakeholder yielded these examples of
>>> interesting 3D geospatial data:
>>> - 3-D line-string (wells and boreholes, atmospheric and ocean soundings)
>> This is 2d+1, will be
Andrea Aime wrote:
> Ben Caradoc-Davies ha scritto:
>> Consulting with a knowledgeable stakeholder yielded these examples of
>> interesting 3D geospatial data:
>> - 3-D line-string (wells and boreholes, atmospheric and ocean soundings)
> This is 2d+1, will be handled by the proposal
>> - TIN (geol
Christian Müller ha scritto:
> I want to be careful here. I think we should check first if all our
> jdbc-ng and the shape file datastore are capable of handling such
> coordinates.
> Some time ago, I tried to implement the JDBC3DTest for DB2 and was NOT
> successful. At the moment, there is onl
I want to be careful here. I think we should check first if all our jdbc-ng
and the shape file datastore are capable of handling such coordinates.
Some time ago, I tried to implement the JDBC3DTest for DB2 and was NOT
successful. At the moment, there is only an Oracle3DTest, so we should make
Nice dose of caution; but it should be fine - we kind of thought this
one through when we introduced ReferencedEnvelope.
Interfaces:
- ReferencedEnvelope <- BoundingBox <- Envelope (GeoAPI)
Classes:
- ReferencedEnvelope <- Envelope (JTS)
The Envelope (GeoAPI) is very generic and allows for multi
+1, but i am more or less in Micheals shoes, not really qualified to
make any in depth feedback. I looked it over and the general approach
looks good to me.
-Justin
Andrea Aime wrote:
> Hi all,
> following previous discussions on the mailing list
> I've put togheter the following proposal:
> ht
Simone Giannecchini ha scritto:
> I have a few doubts about the update of ReferencedEnvelope. Are you
> sure it is already capable of doing 3D semantic-wise?
> It implementes BoundingBox which is purely 2D and that's why it is
> used almost everywhere in the feature code. If we start to put 3d
> en
I have a few doubts about the update of ReferencedEnvelope. Are you
sure it is already capable of doing 3D semantic-wise?
It implementes BoundingBox which is purely 2D and that's why it is
used almost everywhere in the feature code. If we start to put 3d
envelopes in it, we would be clearly violati
First of all - a solid +1
I really like how you have used the facilities of the feature model to
store the extra information about Z or M handling.
I am tempted to provide a Types.getDimension( GeometryAttribiute )
implementation that:
- consults the hint
- looks at the CRS dimension if the hint
Ben Caradoc-Davies ha scritto:
> Andrea Aime wrote:
>> following previous discussions on the mailing list
>> I've put togheter the following proposal:
>> http://docs.codehaus.org/display/GEOTOOLS/Partial+3D+data+support
>>
>> Feedbacks and votes welcomed. Please review at your earlies
>> convenienc
Andrea Aime wrote:
> following previous discussions on the mailing list
> I've put togheter the following proposal:
> http://docs.codehaus.org/display/GEOTOOLS/Partial+3D+data+support
>
> Feedbacks and votes welcomed. Please review at your earlies
> convenience.
+1. This looks like a definite imp
Many thanks for this Andrea.
+0 from me: I wholeheartedly support the intention of the proposal but
I don't feel sufficiently qualified to assess the technical issues
that you and Jody discussed
Michael
--
Crystal Report
Hi all,
following previous discussions on the mailing list
I've put togheter the following proposal:
http://docs.codehaus.org/display/GEOTOOLS/Partial+3D+data+support
Feedbacks and votes welcomed. Please review at your earlies
convenience.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.o
20 matches
Mail list logo
