[gdal-dev] Motion: adopt RFC 64: Triangle, Polyhedral surface and TIN

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gdal-dev] Motion: adopt RFC 64: Triangle, Polyhedral surface and TIN

Even Rouault-2

Hi,

 

There have been some good remarks, one regarding integration with GEOS that I've taken into account in the implementation, another one regarding the possibility to get indexed TIN that I think can be later added if needed.

 

So I move to adopt RFC 64: Triangle, Polyhedral surface and TIN

 

https://trac.osgeo.org/gdal/wiki/rfc64_triangle_polyhedralsurface_tin

 

Starting with my +1,

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gdal-dev] Motion: adopt RFC 64: Triangle, Polyhedral surface and TIN

jratike80
Even Rouault-2 wrote
Hi,

There have been some good remarks, one regarding integration with GEOS that I've
taken into account in the implementation, another one regarding the possibility to
get indexed TIN that I think can be later added if needed.

So I move to adopt RFC 64: Triangle, Polyhedral surface and TIN

    https://trac.osgeo.org/gdal/wiki/rfc64_triangle_polyhedralsurface_tin

Starting with my +1,
+1

-Jukka Rahkonen-
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Motion: adopt RFC 64: Triangle, Polyhedral surface and TIN

Even Rouault-2
In reply to this post by Even Rouault-2

On vendredi 9 décembre 2016 12:10:25 CET Even Rouault wrote:

> Hi,

>

> There have been some good remarks, one regarding integration with GEOS that

> I've taken into account in the implementation, another one regarding the

> possibility to get indexed TIN that I think can be later added if needed.

>

> So I move to adopt RFC 64: Triangle, Polyhedral surface and TIN

>

> https://trac.osgeo.org/gdal/wiki/rfc64_triangle_polyhedralsurface_tin

>

> Starting with my +1,

 

Friendly remainder that this motion is under vote.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Motion: adopt RFC 64: Triangle, Polyhedral surface and TIN

Daniel Morissette
+0 as I'm wondering if there could be a better way to handle this, i.e.
it's not clear to me how useful it is to read/write those new geometry
types without maintaining the (topological?) relationships between the
objects. I am no expert with that type of data structures so my concerns
may be completely invalid too and I have no alternative to offer, hence
my +0.

Daniel

On 2016-12-13 1:13 PM, Even Rouault wrote:

> On vendredi 9 décembre 2016 12:10:25 CET Even Rouault wrote:
>
>> Hi,
>
>>
>
>> There have been some good remarks, one regarding integration with GEOS
> that
>
>> I've taken into account in the implementation, another one regarding the
>
>> possibility to get indexed TIN that I think can be later added if needed.
>
>>
>
>> So I move to adopt RFC 64: Triangle, Polyhedral surface and TIN
>
>>
>
>> https://trac.osgeo.org/gdal/wiki/rfc64_triangle_polyhedralsurface_tin
>
>>
>
>> Starting with my +1,
>
>
>
> Friendly remainder that this motion is under vote.
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
>
>
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>


--
Daniel Morissette
http://www.mapgears.com/
T: +1 418-696-5056 #201

http://evouala.com/ - Location Intelligence Made Easy
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Motion: adopt RFC 64: Triangle, Polyhedral surface and TIN

Even Rouault-2

On mercredi 14 décembre 2016 10:05:46 CET Daniel Morissette wrote:

> +0 as I'm wondering if there could be a better way to handle this, i.e.

> it's not clear to me how useful it is to read/write those new geometry

> types without maintaining the (topological?) relationships between the

> objects. I am no expert with that type of data structures so my concerns

> may be completely invalid too and I have no alternative to offer, hence

> my +0.

 

The Simple Feature model clearly doesn't maintain topological relationships. Topological consistency must be checked in a later stage with a IsValid() call for example (this also holds true for already handled geometry types). And if you look at some drivers that implement TIN currenlty like PostGIS or GML, they are based on the Simple Feature model as well. Only shapefile/filegdb has something a bit stronger with shared nodes.

 

I think that support for topological geometries would be a completely different concept to be added in OGR. Would require management of nodes, edges and faces, and conversions between simple feature geometries and topogeometries. I had some preliminary discussions about that with an interested party in the past but they didn't go further.

 

In the current state of things, the TIN support should be hopefully good enough for conversions between PostGIS, GML, DXF and shapefile/filegdb.

 

Even

 

>

> Daniel

>

> On 2016-12-13 1:13 PM, Even Rouault wrote:

> > On vendredi 9 décembre 2016 12:10:25 CET Even Rouault wrote:

> >> Hi,

> >>

> >>

> >>

> >> There have been some good remarks, one regarding integration with GEOS

> >

> > that

> >

> >> I've taken into account in the implementation, another one regarding the

> >>

> >> possibility to get indexed TIN that I think can be later added if needed.

> >>

> >>

> >>

> >> So I move to adopt RFC 64: Triangle, Polyhedral surface and TIN

> >>

> >>

> >>

> >> https://trac.osgeo.org/gdal/wiki/rfc64_triangle_polyhedralsurface_tin

> >>

> >>

> >>

> >> Starting with my +1,

> >

> > Friendly remainder that this motion is under vote.

> >

> >

> >

> > Even

> >

> >

> >

> > --

> >

> > Spatialys - Geospatial professional services

> >

> > http://www.spatialys.com

> >

> >

> >

> > _______________________________________________

> > gdal-dev mailing list

> > [hidden email]

> > http://lists.osgeo.org/mailman/listinfo/gdal-dev

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Motion: adopt RFC 64: Triangle, Polyhedral surface and TIN

Daniel Morissette
Thank you for the clarification. Since those changes are useful by
themselves then I change my vote to +1

Daniel


On 2016-12-14 10:19 AM, Even Rouault wrote:

> On mercredi 14 décembre 2016 10:05:46 CET Daniel Morissette wrote:
>
>> +0 as I'm wondering if there could be a better way to handle this, i.e.
>
>> it's not clear to me how useful it is to read/write those new geometry
>
>> types without maintaining the (topological?) relationships between the
>
>> objects. I am no expert with that type of data structures so my concerns
>
>> may be completely invalid too and I have no alternative to offer, hence
>
>> my +0.
>
>
>
> The Simple Feature model clearly doesn't maintain topological
> relationships. Topological consistency must be checked in a later stage
> with a IsValid() call for example (this also holds true for already
> handled geometry types). And if you look at some drivers that implement
> TIN currenlty like PostGIS or GML, they are based on the Simple Feature
> model as well. Only shapefile/filegdb has something a bit stronger with
> shared nodes.
>
>
>
> I think that support for topological geometries would be a completely
> different concept to be added in OGR. Would require management of nodes,
> edges and faces, and conversions between simple feature geometries and
> topogeometries. I had some preliminary discussions about that with an
> interested party in the past but they didn't go further.
>
>
>
> In the current state of things, the TIN support should be hopefully good
> enough for conversions between PostGIS, GML, DXF and shapefile/filegdb.
>
>
>
> Even
>
>
>
>>
>
>> Daniel
>
>>
>
>> On 2016-12-13 1:13 PM, Even Rouault wrote:
>
>> > On vendredi 9 décembre 2016 12:10:25 CET Even Rouault wrote:
>
>> >> Hi,
>
>> >>
>
>> >>
>
>> >>
>
>> >> There have been some good remarks, one regarding integration with GEOS
>
>> >
>
>> > that
>
>> >
>
>> >> I've taken into account in the implementation, another one
> regarding the
>
>> >>
>
>> >> possibility to get indexed TIN that I think can be later added if
> needed.
>
>> >>
>
>> >>
>
>> >>
>
>> >> So I move to adopt RFC 64: Triangle, Polyhedral surface and TIN
>
>> >>
>
>> >>
>
>> >>
>
>> >> https://trac.osgeo.org/gdal/wiki/rfc64_triangle_polyhedralsurface_tin
>
>> >>
>
>> >>
>
>> >>
>
>> >> Starting with my +1,
>
>> >
>
>> > Friendly remainder that this motion is under vote.
>
>> >
>
>> >
>
>> >
>
>> > Even
>
>> >
>
>> >
>
>> >
>
>> > --
>
>> >
>
>> > Spatialys - Geospatial professional services
>
>> >
>
>> > http://www.spatialys.com
>
>> >
>
>> >
>
>> >
>
>> > _______________________________________________
>
>> > gdal-dev mailing list
>
>> > [hidden email]
>
>> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
>
>
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>


--
Daniel Morissette
http://www.mapgears.com/
T: +1 418-696-5056 #201

http://evouala.com/ - Location Intelligence Made Easy
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Motion: adopt RFC 64: Triangle, Polyhedral surface and TIN

Howard Butler-3
In reply to this post by Even Rouault-2

> On Dec 9, 2016, at 5:10 AM, Even Rouault <[hidden email]> wrote:
>
> Hi,
>  
> There have been some good remarks, one regarding integration with GEOS that I've taken into account in the implementation, another one regarding the possibility to get indexed TIN that I think can be later added if needed.
>  
> So I move to adopt RFC 64: Triangle, Polyhedral surface and TIN
>  
>     https://trac.osgeo.org/gdal/wiki/rfc64_triangle_polyhedralsurface_tin
>  
> Starting with my +1,

+1

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Motion: adopt RFC 64: Triangle, Polyhedral surface and TIN

Even Rouault-2
In reply to this post by Even Rouault-2

On vendredi 9 décembre 2016 12:10:25 CET Even Rouault wrote:

> Hi,

>

> There have been some good remarks, one regarding integration with GEOS that

> I've taken into account in the implementation, another one regarding the

> possibility to get indexed TIN that I think can be later added if needed.

>

> So I move to adopt RFC 64: Triangle, Polyhedral surface and TIN

>

> https://trac.osgeo.org/gdal/wiki/rfc64_triangle_polyhedralsurface_tin

>

 

I declare this motion passed with +1 from JukkaR, DanielM, HowardB and myself.

 

I will proceed to merge into trunk.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Loading...