Re: [gdal-dev] ISO WKB
Le jeudi 19 décembre 2013 00:50:06, Paul Ramsey a écrit :
> I've updated my working branch to match your intent more closely, I hope
>
> https://github.com/pramsey/gdal/tree/isowkb
>
> the iso enumeration is no longer there, and access to iso geometry
> types is via a protected method only.
Yes, looks good (except some generated files that accidently were committed).
>
> The reason I asked about GDAL2 is that some of the stuff in OGR seemed
> new to me (multiple geometry columns, e.g.) and I thought that those
> kinds of changes might be leading to a GDAL2 release.
There are a lot of possible ideas for a GDAL 2 (
http://trac.osgeo.org/gdal/wiki/GDAL20Changes ).
Multiple geometry columns is indeed a recent addition (
http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields ), but it
doesn't break the C API.
To tag a GDAL 2, we would probably need something more disruptive (although
hopefully not too disruptive !) since GDAL 2 will sound to people's hears :
"ah, maybe I have to adapt my code that has worked for the last past 10 years"
Not sure when this will happen...
>
> P.
>
> On Wed, Dec 18, 2013 at 1:20 AM, Even Rouault
>
> wrote:
> > Le mercredi 18 décembre 2013 06:28:16, Paul Ramsey a écrit :
> >> I don't think we should expose the ISO geometry types to the world,
> >> they're just for WKB really, so I'll keep that part hidden away. It's
> >> a shame we can't get rid of the 25d type variants for gdal2... if not
> >> then, when?
> >
> > Ah, I didn't perceive you wanted to go that far. Well, that's certainly
> > something that could be done for a GDAL 2. It would require a RFC to draw
> > the battle plan and analyze the impacts.
> >
> >> Incidentally, is there going to be a GDAL 1.11?
> >
> > Technically, at that point, no breaking changes have been done in trunk,
> > so 1.11 would make sense as a version number.
> >
> > Even
> >
> >> P.
> >>
> >> On Tue, Dec 17, 2013 at 1:50 PM, Even Rouault
> >>
> >> wrote:
> >> > Le mardi 17 décembre 2013 22:38:26, Paul Ramsey a écrit :
> >> >> OK, so hide the ISO types from the outside world. No problem.
> >> >>
> >> >> Is it OK to have getGeometryType and exportToWkb accept wkbVariant
> >> >> optional parameters?
> >> >
> >> > For exportToWkb(), it is just a matter of taste whether to add an
> >> > optional parameter or to have a dedicated method.
> >> >
> >> > For getGeometryType(), as it returns a OGRwkbGeometryType, you can't
> >> > add an optional parameter to return values other than
> >> > OGRwkbGeometryType. My latest proposal was to have a - protected -
> >> > "int
> >> > getGeometryType(wkbVariant) { return
> >> > (eVariant == wkbVariantOgc) ? getGeometryType() :
> >> > getIsoGeometryType(); }" and a public OGRwkbIsoGeometryType
> >> > getIsoGeometryType().
> >> >
> >> >> P.
> >> >>
> >> >> On Tue, Dec 17, 2013 at 1:03 AM, Even Rouault
> >> >>
> >> >> wrote:
> >> >> > Selon Paul Ramsey :
> >> >> >> Back to this, is it OK?
> >> >> >
> >> >> > As said in
> >> >> > http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html
> >> >> > , I feel a bit unconfortable with the extension of the
> >> >> > OGRwkbGeometryType enumeration that has possible impacts on other
> >> >> > parts of OGR. There's perhaps a time where we will touch it, but
> >> >> > I'd expect it to ideally embrace Z, M, ZM, circular geometries at
> >> >> > once. And that would deserve a RFC.
> >> >> >
> >> >> > What do you think of keeping it an internal enumeration of OGR,
> >> >> > since that's probably all you need for now ?
> >> >> >
> >> >> > "Or have a separate OGRwkbIsoGeometryType enumeration {
> >> >> > wkbPointIso, ... wkbGeometryCollectionIso, wkbPointIsoZ, ...
> >> >> > wkbGeometryCollectionIsoZ }, a getIsoGeometryType() method that
> >> >> > returns it, and the exportToWkb() methods that calls int
> >> >> > getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
> >> >> > wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }"
> >> >> >
> >> >> > I'd be happy to hear about other GDAL developers opinion on this.
> >> >> >
> >> >> >> How are we patching back to SVN? I can convert
> >> >> >> it into a patch and attach to a ticket, if that's the path.
> >> >> >
> >> >> > git-svn can be used to bridge the 2 worlds, but in my recent
> >> >> > experience it has been painful to use. So generating a patch and
> >> >> > applying it is probably easier.
> >> >> >
> >> >> > Even
> >> >> >
> >> >> > --
> >> >> > Geospatial professional services
> >> >> > http://even.rouault.free.fr/services.html
> >> >
> >> > --
> >> > Geospatial professional services
> >> > http://even.rouault.free.fr/services.html
> >
> > --
> > Geospatial professional services
> > http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
I've updated my working branch to match your intent more closely, I hope
https://github.com/pramsey/gdal/tree/isowkb
the iso enumeration is no longer there, and access to iso geometry
types is via a protected method only.
The reason I asked about GDAL2 is that some of the stuff in OGR seemed
new to me (multiple geometry columns, e.g.) and I thought that those
kinds of changes might be leading to a GDAL2 release.
P.
On Wed, Dec 18, 2013 at 1:20 AM, Even Rouault
wrote:
> Le mercredi 18 décembre 2013 06:28:16, Paul Ramsey a écrit :
>> I don't think we should expose the ISO geometry types to the world,
>> they're just for WKB really, so I'll keep that part hidden away. It's
>> a shame we can't get rid of the 25d type variants for gdal2... if not
>> then, when?
>
> Ah, I didn't perceive you wanted to go that far. Well, that's certainly
> something that could be done for a GDAL 2. It would require a RFC to draw the
> battle plan and analyze the impacts.
>
>>
>> Incidentally, is there going to be a GDAL 1.11?
>
> Technically, at that point, no breaking changes have been done in trunk, so
> 1.11 would make sense as a version number.
>
> Even
>
>>
>> P.
>>
>> On Tue, Dec 17, 2013 at 1:50 PM, Even Rouault
>>
>> wrote:
>> > Le mardi 17 décembre 2013 22:38:26, Paul Ramsey a écrit :
>> >> OK, so hide the ISO types from the outside world. No problem.
>> >>
>> >> Is it OK to have getGeometryType and exportToWkb accept wkbVariant
>> >> optional parameters?
>> >
>> > For exportToWkb(), it is just a matter of taste whether to add an
>> > optional parameter or to have a dedicated method.
>> >
>> > For getGeometryType(), as it returns a OGRwkbGeometryType, you can't add
>> > an optional parameter to return values other than OGRwkbGeometryType. My
>> > latest proposal was to have a - protected - "int
>> > getGeometryType(wkbVariant) { return
>> > (eVariant == wkbVariantOgc) ? getGeometryType() :
>> > getIsoGeometryType(); }" and a public OGRwkbIsoGeometryType
>> > getIsoGeometryType().
>> >
>> >> P.
>> >>
>> >> On Tue, Dec 17, 2013 at 1:03 AM, Even Rouault
>> >>
>> >> wrote:
>> >> > Selon Paul Ramsey :
>> >> >> Back to this, is it OK?
>> >> >
>> >> > As said in
>> >> > http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
>> >> > feel a bit unconfortable with the extension of the OGRwkbGeometryType
>> >> > enumeration that has possible impacts on other parts of OGR. There's
>> >> > perhaps a time where we will touch it, but I'd expect it to ideally
>> >> > embrace Z, M, ZM, circular geometries at once. And that would deserve
>> >> > a RFC.
>> >> >
>> >> > What do you think of keeping it an internal enumeration of OGR, since
>> >> > that's probably all you need for now ?
>> >> >
>> >> > "Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso,
>> >> > ... wkbGeometryCollectionIso, wkbPointIsoZ, ...
>> >> > wkbGeometryCollectionIsoZ }, a getIsoGeometryType() method that
>> >> > returns it, and the exportToWkb() methods that calls int
>> >> > getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
>> >> > wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }"
>> >> >
>> >> > I'd be happy to hear about other GDAL developers opinion on this.
>> >> >
>> >> >> How are we patching back to SVN? I can convert
>> >> >> it into a patch and attach to a ticket, if that's the path.
>> >> >
>> >> > git-svn can be used to bridge the 2 worlds, but in my recent
>> >> > experience it has been painful to use. So generating a patch and
>> >> > applying it is probably easier.
>> >> >
>> >> > Even
>> >> >
>> >> > --
>> >> > Geospatial professional services
>> >> > http://even.rouault.free.fr/services.html
>> >
>> > --
>> > Geospatial professional services
>> > http://even.rouault.free.fr/services.html
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Le mercredi 18 décembre 2013 06:28:16, Paul Ramsey a écrit :
> I don't think we should expose the ISO geometry types to the world,
> they're just for WKB really, so I'll keep that part hidden away. It's
> a shame we can't get rid of the 25d type variants for gdal2... if not
> then, when?
Ah, I didn't perceive you wanted to go that far. Well, that's certainly
something that could be done for a GDAL 2. It would require a RFC to draw the
battle plan and analyze the impacts.
>
> Incidentally, is there going to be a GDAL 1.11?
Technically, at that point, no breaking changes have been done in trunk, so
1.11 would make sense as a version number.
Even
>
> P.
>
> On Tue, Dec 17, 2013 at 1:50 PM, Even Rouault
>
> wrote:
> > Le mardi 17 décembre 2013 22:38:26, Paul Ramsey a écrit :
> >> OK, so hide the ISO types from the outside world. No problem.
> >>
> >> Is it OK to have getGeometryType and exportToWkb accept wkbVariant
> >> optional parameters?
> >
> > For exportToWkb(), it is just a matter of taste whether to add an
> > optional parameter or to have a dedicated method.
> >
> > For getGeometryType(), as it returns a OGRwkbGeometryType, you can't add
> > an optional parameter to return values other than OGRwkbGeometryType. My
> > latest proposal was to have a - protected - "int
> > getGeometryType(wkbVariant) { return
> > (eVariant == wkbVariantOgc) ? getGeometryType() :
> > getIsoGeometryType(); }" and a public OGRwkbIsoGeometryType
> > getIsoGeometryType().
> >
> >> P.
> >>
> >> On Tue, Dec 17, 2013 at 1:03 AM, Even Rouault
> >>
> >> wrote:
> >> > Selon Paul Ramsey :
> >> >> Back to this, is it OK?
> >> >
> >> > As said in
> >> > http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
> >> > feel a bit unconfortable with the extension of the OGRwkbGeometryType
> >> > enumeration that has possible impacts on other parts of OGR. There's
> >> > perhaps a time where we will touch it, but I'd expect it to ideally
> >> > embrace Z, M, ZM, circular geometries at once. And that would deserve
> >> > a RFC.
> >> >
> >> > What do you think of keeping it an internal enumeration of OGR, since
> >> > that's probably all you need for now ?
> >> >
> >> > "Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso,
> >> > ... wkbGeometryCollectionIso, wkbPointIsoZ, ...
> >> > wkbGeometryCollectionIsoZ }, a getIsoGeometryType() method that
> >> > returns it, and the exportToWkb() methods that calls int
> >> > getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
> >> > wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }"
> >> >
> >> > I'd be happy to hear about other GDAL developers opinion on this.
> >> >
> >> >> How are we patching back to SVN? I can convert
> >> >> it into a patch and attach to a ticket, if that's the path.
> >> >
> >> > git-svn can be used to bridge the 2 worlds, but in my recent
> >> > experience it has been painful to use. So generating a patch and
> >> > applying it is probably easier.
> >> >
> >> > Even
> >> >
> >> > --
> >> > Geospatial professional services
> >> > http://even.rouault.free.fr/services.html
> >
> > --
> > Geospatial professional services
> > http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
I don't think we should expose the ISO geometry types to the world,
they're just for WKB really, so I'll keep that part hidden away. It's
a shame we can't get rid of the 25d type variants for gdal2... if not
then, when?
Incidentally, is there going to be a GDAL 1.11?
P.
On Tue, Dec 17, 2013 at 1:50 PM, Even Rouault
wrote:
> Le mardi 17 décembre 2013 22:38:26, Paul Ramsey a écrit :
>> OK, so hide the ISO types from the outside world. No problem.
>>
>> Is it OK to have getGeometryType and exportToWkb accept wkbVariant
>> optional parameters?
>
> For exportToWkb(), it is just a matter of taste whether to add an optional
> parameter or to have a dedicated method.
>
> For getGeometryType(), as it returns a OGRwkbGeometryType, you can't add an
> optional parameter to return values other than OGRwkbGeometryType.
> My latest proposal was to have a - protected - "int
> getGeometryType(wkbVariant) { return
> (eVariant == wkbVariantOgc) ? getGeometryType() :
> getIsoGeometryType(); }" and a public OGRwkbIsoGeometryType
> getIsoGeometryType().
>
>>
>> P.
>>
>> On Tue, Dec 17, 2013 at 1:03 AM, Even Rouault
>>
>> wrote:
>> > Selon Paul Ramsey :
>> >> Back to this, is it OK?
>> >
>> > As said in
>> > http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
>> > feel a bit unconfortable with the extension of the OGRwkbGeometryType
>> > enumeration that has possible impacts on other parts of OGR. There's
>> > perhaps a time where we will touch it, but I'd expect it to ideally
>> > embrace Z, M, ZM, circular geometries at once. And that would deserve a
>> > RFC.
>> >
>> > What do you think of keeping it an internal enumeration of OGR, since
>> > that's probably all you need for now ?
>> >
>> > "Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
>> > wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ },
>> > a getIsoGeometryType() method that returns it, and the exportToWkb()
>> > methods that calls int getGeometryType(OGRwkbVariant eVariant) { return
>> > (eVariant == wkbVariantOgc) ? getGeometryType() : getIsoGeometryType();
>> > }"
>> >
>> > I'd be happy to hear about other GDAL developers opinion on this.
>> >
>> >> How are we patching back to SVN? I can convert
>> >> it into a patch and attach to a ticket, if that's the path.
>> >
>> > git-svn can be used to bridge the 2 worlds, but in my recent experience
>> > it has been painful to use. So generating a patch and applying it is
>> > probably easier.
>> >
>> > Even
>> >
>> > --
>> > Geospatial professional services
>> > http://even.rouault.free.fr/services.html
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
On 17 December 2013 20:16, Dmitriy Baryshnikov wrote: > Hi, > > I afraid that we come to situation where: > > getGeometryType() > getIsoGeometryType() > getRFCGeometryType() > ... > getBlahBlahGeometryType() > > Why not have only one method and only one enum (as GDAL origin - single > abstract data model to the calling application for all supported formats). > I think all ISO specific things should be internal and driver specific. So, > we will get single GDAL enum of geom types. I agree with you, in principle, that it's best if abstraction layer actually makes a common denominator, but it is in this particular case it is too late (AFAIU what Even says) and single enumeration would gather plain codes as well as bit flags, leading to further confusion in interpretation. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Le mardi 17 décembre 2013 22:38:26, Paul Ramsey a écrit :
> OK, so hide the ISO types from the outside world. No problem.
>
> Is it OK to have getGeometryType and exportToWkb accept wkbVariant
> optional parameters?
For exportToWkb(), it is just a matter of taste whether to add an optional
parameter or to have a dedicated method.
For getGeometryType(), as it returns a OGRwkbGeometryType, you can't add an
optional parameter to return values other than OGRwkbGeometryType.
My latest proposal was to have a - protected - "int
getGeometryType(wkbVariant) { return
(eVariant == wkbVariantOgc) ? getGeometryType() :
getIsoGeometryType(); }" and a public OGRwkbIsoGeometryType
getIsoGeometryType().
>
> P.
>
> On Tue, Dec 17, 2013 at 1:03 AM, Even Rouault
>
> wrote:
> > Selon Paul Ramsey :
> >> Back to this, is it OK?
> >
> > As said in
> > http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
> > feel a bit unconfortable with the extension of the OGRwkbGeometryType
> > enumeration that has possible impacts on other parts of OGR. There's
> > perhaps a time where we will touch it, but I'd expect it to ideally
> > embrace Z, M, ZM, circular geometries at once. And that would deserve a
> > RFC.
> >
> > What do you think of keeping it an internal enumeration of OGR, since
> > that's probably all you need for now ?
> >
> > "Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
> > wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ },
> > a getIsoGeometryType() method that returns it, and the exportToWkb()
> > methods that calls int getGeometryType(OGRwkbVariant eVariant) { return
> > (eVariant == wkbVariantOgc) ? getGeometryType() : getIsoGeometryType();
> > }"
> >
> > I'd be happy to hear about other GDAL developers opinion on this.
> >
> >> How are we patching back to SVN? I can convert
> >> it into a patch and attach to a ticket, if that's the path.
> >
> > git-svn can be used to bridge the 2 worlds, but in my recent experience
> > it has been painful to use. So generating a patch and applying it is
> > probably easier.
> >
> > Even
> >
> > --
> > Geospatial professional services
> > http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
OK, so hide the ISO types from the outside world. No problem.
Is it OK to have getGeometryType and exportToWkb accept wkbVariant
optional parameters?
P.
On Tue, Dec 17, 2013 at 1:03 AM, Even Rouault
wrote:
> Selon Paul Ramsey :
>
>> Back to this, is it OK?
>
> As said in
> http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html,
> I feel a bit unconfortable with the extension of the OGRwkbGeometryType
> enumeration that has possible impacts on other parts of OGR. There's perhaps a
> time where we will touch it, but I'd expect it to ideally embrace Z, M, ZM,
> circular geometries at once. And that would deserve a RFC.
>
> What do you think of keeping it an internal enumeration of OGR, since that's
> probably all you need for now ?
>
> "Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
> wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ }, a
> getIsoGeometryType() method that returns it, and the exportToWkb() methods
> that calls int getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
> wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }"
>
> I'd be happy to hear about other GDAL developers opinion on this.
>
>> How are we patching back to SVN? I can convert
>> it into a patch and attach to a ticket, if that's the path.
>
> git-svn can be used to bridge the 2 worlds, but in my recent experience it has
> been painful to use. So generating a patch and applying it is probably easier.
>
> Even
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Hi,
I afraid that we come to situation where:
getGeometryType()
getIsoGeometryType()
getRFCGeometryType()
...
getBlahBlahGeometryType()
Why not have only one method and only one enum (as GDAL origin - single
abstract data model to the calling application for all supported formats).
I think all ISO specific things should be internal and driver specific.
So, we will get single GDAL enum of geom types.
Best regards,
Dmitry
17.12.2013 18:09, Mateusz Loskot пишет:
On 17 December 2013 09:03, Even Rouault wrote:
Selon Paul Ramsey :
Back to this, is it OK?
As said in http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html,
I feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's perhaps a
time where we will touch it, but I'd expect it to ideally embrace Z, M, ZM,
circular geometries at once. And that would deserve a RFC.
What do you think of keeping it an internal enumeration of OGR, since that's
probably all you need for now ?
"Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ }, a
getIsoGeometryType() method that returns it, and the exportToWkb() methods
that calls int getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }"
I'd be happy to hear about other GDAL developers opinion on this.
IMHO, each format based on a particular spec/standard should be
supported with a separate interface (enum + functions)
per format/standard.
Best regards,
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Le mardi 17 décembre 2013 21:38:44, Dmitriy Baryshnikov a écrit :
> In this case, the
>
> getXXXGeometryType()
>
> is more logic, than
>
> int getGeometryType(OGRwkbVariant eVariant) { return
> (eVariant == wkbVariantOgc) ? getGeometryType() :
> getIsoGeometryType(); }
ah ok, I see your point. The idea was just a proposal to offer an helper method
to avoid typing in the exportToWkb() of each geometry subclass :
(eVariant == wkbVariantOgc) ? getGeometryType() : getIsoGeometryType();
That getGeometryType(OGRwkbVariant eVariant) could be a protected method of
OGRGeometry class, so that it remains an internal implementation detail.
>
> Best regards,
> Dmitry
>
> 18.12.2013 0:32, Even Rouault пишет:
> > Le mardi 17 décembre 2013 21:16:25, Dmitriy Baryshnikov a écrit :
> >> Hi,
> >>
> >> I afraid that we come to situation where:
> >>
> >> getGeometryType()
> >> getIsoGeometryType()
> >> getRFCGeometryType()
> >> ...
> >> getBlahBlahGeometryType()
> >>
> >> Why not have only one method and only one enum (as GDAL origin - single
> >> abstract data model to the calling application for all supported
> >> formats). I think all ISO specific things should be internal and driver
> >> specific. So, we will get single GDAL enum of geom types.
> >
> > I don't see it a problem if we have different getXXXGeometryType() or
> > exportTo() methods in OGRGeometry, provided that they document well
> > the standard/document they implement. The ISO WKB encoding is a
> > standard, so it can be a legitimate interface of OGRGeometry, and could
> > potentially be used in several drivers ( actually if you look at
> > OGRSpatialReference class it has a lot of import / export methods to
> > various exotic formats, only used by one driver ).
> >
> >> Best regards,
> >>
> >> Dmitry
> >>
> >> 17.12.2013 18:09, Mateusz Loskot пишет:
> >>> On 17 December 2013 09:03, Even Rouault
> >
> > wrote:
> Selon Paul Ramsey :
> > Back to this, is it OK?
>
> As said in
> http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
> feel a bit unconfortable with the extension of the OGRwkbGeometryType
> enumeration that has possible impacts on other parts of OGR. There's
> perhaps a time where we will touch it, but I'd expect it to ideally
> embrace Z, M, ZM, circular geometries at once. And that would deserve
> a RFC.
>
> What do you think of keeping it an internal enumeration of OGR, since
> that's probably all you need for now ?
>
> "Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso,
> ... wkbGeometryCollectionIso, wkbPointIsoZ, ...
> wkbGeometryCollectionIsoZ }, a getIsoGeometryType() method that
> returns it, and the exportToWkb() methods that calls int
> getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
> wkbVariantOgc) ? getGeometryType() :
> getIsoGeometryType(); }"
>
> I'd be happy to hear about other GDAL developers opinion on this.
> >>>
> >>> IMHO, each format based on a particular spec/standard should be
> >>> supported with a separate interface (enum + functions)
> >>> per format/standard.
> >>>
> >>> Best regards,
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Le mardi 17 décembre 2013 21:16:25, Dmitriy Baryshnikov a écrit :
> Hi,
>
> I afraid that we come to situation where:
>
> getGeometryType()
> getIsoGeometryType()
> getRFCGeometryType()
> ...
> getBlahBlahGeometryType()
>
> Why not have only one method and only one enum (as GDAL origin - single
> abstract data model to the calling application for all supported formats).
> I think all ISO specific things should be internal and driver specific.
> So, we will get single GDAL enum of geom types.
I don't see it a problem if we have different getXXXGeometryType() or
exportTo() methods in OGRGeometry, provided that they document well the
standard/document they implement. The ISO WKB encoding is a standard, so it
can be a legitimate interface of OGRGeometry, and could potentially be used in
several drivers ( actually if you look at OGRSpatialReference class it has a
lot of import / export methods to various exotic formats, only used by one
driver ).
>
> Best regards,
> Dmitry
>
> 17.12.2013 18:09, Mateusz Loskot пишет:
> > On 17 December 2013 09:03, Even Rouault
wrote:
> >> Selon Paul Ramsey :
> >>> Back to this, is it OK?
> >>
> >> As said in
> >> http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
> >> feel a bit unconfortable with the extension of the OGRwkbGeometryType
> >> enumeration that has possible impacts on other parts of OGR. There's
> >> perhaps a time where we will touch it, but I'd expect it to ideally
> >> embrace Z, M, ZM, circular geometries at once. And that would deserve a
> >> RFC.
> >>
> >> What do you think of keeping it an internal enumeration of OGR, since
> >> that's probably all you need for now ?
> >>
> >> "Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
> >> wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ },
> >> a getIsoGeometryType() method that returns it, and the exportToWkb()
> >> methods that calls int getGeometryType(OGRwkbVariant eVariant) { return
> >> (eVariant == wkbVariantOgc) ? getGeometryType() :
> >> getIsoGeometryType(); }"
> >>
> >> I'd be happy to hear about other GDAL developers opinion on this.
> >
> > IMHO, each format based on a particular spec/standard should be
> > supported with a separate interface (enum + functions)
> > per format/standard.
> >
> > Best regards,
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
In this case, the
getXXXGeometryType()
is more logic, than
int getGeometryType(OGRwkbVariant eVariant) { return
(eVariant == wkbVariantOgc) ? getGeometryType() :
getIsoGeometryType(); }
Best regards,
Dmitry
18.12.2013 0:32, Even Rouault пишет:
Le mardi 17 décembre 2013 21:16:25, Dmitriy Baryshnikov a écrit :
Hi,
I afraid that we come to situation where:
getGeometryType()
getIsoGeometryType()
getRFCGeometryType()
...
getBlahBlahGeometryType()
Why not have only one method and only one enum (as GDAL origin - single
abstract data model to the calling application for all supported formats).
I think all ISO specific things should be internal and driver specific.
So, we will get single GDAL enum of geom types.
I don't see it a problem if we have different getXXXGeometryType() or
exportTo() methods in OGRGeometry, provided that they document well the
standard/document they implement. The ISO WKB encoding is a standard, so it
can be a legitimate interface of OGRGeometry, and could potentially be used in
several drivers ( actually if you look at OGRSpatialReference class it has a
lot of import / export methods to various exotic formats, only used by one
driver ).
Best regards,
Dmitry
17.12.2013 18:09, Mateusz Loskot пишет:
On 17 December 2013 09:03, Even Rouault
wrote:
Selon Paul Ramsey :
Back to this, is it OK?
As said in
http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's
perhaps a time where we will touch it, but I'd expect it to ideally
embrace Z, M, ZM, circular geometries at once. And that would deserve a
RFC.
What do you think of keeping it an internal enumeration of OGR, since
that's probably all you need for now ?
"Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ },
a getIsoGeometryType() method that returns it, and the exportToWkb()
methods that calls int getGeometryType(OGRwkbVariant eVariant) { return
(eVariant == wkbVariantOgc) ? getGeometryType() :
getIsoGeometryType(); }"
I'd be happy to hear about other GDAL developers opinion on this.
IMHO, each format based on a particular spec/standard should be
supported with a separate interface (enum + functions)
per format/standard.
Best regards,
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
On 17 December 2013 09:03, Even Rouault wrote:
> Selon Paul Ramsey :
>
>> Back to this, is it OK?
>
> As said in
> http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html,
> I feel a bit unconfortable with the extension of the OGRwkbGeometryType
> enumeration that has possible impacts on other parts of OGR. There's perhaps a
> time where we will touch it, but I'd expect it to ideally embrace Z, M, ZM,
> circular geometries at once. And that would deserve a RFC.
>
> What do you think of keeping it an internal enumeration of OGR, since that's
> probably all you need for now ?
>
> "Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
> wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ }, a
> getIsoGeometryType() method that returns it, and the exportToWkb() methods
> that calls int getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
> wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }"
>
> I'd be happy to hear about other GDAL developers opinion on this.
IMHO, each format based on a particular spec/standard should be
supported with a separate interface (enum + functions)
per format/standard.
Best regards,
--
Mateusz Łoskot, http://mateusz.loskot.net
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Selon Paul Ramsey :
> Back to this, is it OK?
As said in http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html,
I feel a bit unconfortable with the extension of the OGRwkbGeometryType
enumeration that has possible impacts on other parts of OGR. There's perhaps a
time where we will touch it, but I'd expect it to ideally embrace Z, M, ZM,
circular geometries at once. And that would deserve a RFC.
What do you think of keeping it an internal enumeration of OGR, since that's
probably all you need for now ?
"Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ }, a
getIsoGeometryType() method that returns it, and the exportToWkb() methods
that calls int getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }"
I'd be happy to hear about other GDAL developers opinion on this.
> How are we patching back to SVN? I can convert
> it into a patch and attach to a ticket, if that's the path.
git-svn can be used to bridge the 2 worlds, but in my recent experience it has
been painful to use. So generating a patch and applying it is probably easier.
Even
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Back to this, is it OK? How are we patching back to SVN? I can convert
it into a patch and attach to a ticket, if that's the path.
P.
On Fri, Dec 13, 2013 at 12:00 PM, Paul Ramsey wrote:
> I’ve pushed up some work to do this
>
> https://github.com/pramsey/gdal/tree/isowkb
>
> I had to change *two* method signatures, which I don’t really like, both
> exportToWkb and getGeometryType needed a variant parameter added. The
> problem is that getGeometryType returns the full WKB type, with
> dimensionality encoded, which makes it somewhat duplicative of
> getCoordinateDimension. In an ideal world, getGeometryType would only return
> the type number, and dimensionally information would be inferred from
> getCoordinateDimension.
>
> Then only the exportToWkb signature would need a variant parameter.
>
> importFromWkb also was changed to ingest the ISO variant if that’s what it’s
> fed. No changes to signature required there.
>
> P.
>
> --
> Paul Ramsey
> http://cleverelephant.ca
> http://postgis.net
>
> On December 12, 2013 at 2:58:05 PM, Even Rouault
> (even.roua...@mines-paris.org) wrote:
>
> Le jeudi 12 décembre 2013 23:39:25, Paul Ramsey a écrit :
>> I’ve been looking over the code, and I think I can make importFromWkb
>> consume ISO inputs with relatively minor changes. (during the geometry
>> type determination in the concrete types, it looks easy enough to add a
>> little logic to deal with ISO type numbers) For exportToWkb, I’m wondering
>> if maybe an optional parameter (wkbVariant?) that defaults to
>> wkbVariantOGC would be sufficient?
>
> Sounds good to me. Is "wkbVariantOGC" the variant currently implemented ? Is
> our 3D support really compliant with an OGC standard ?
>
>>
>> It also seems the wkb reader/writer have little handling for empty
>> geometry
>> types. I’d like to add some in, if that’s OK.
>
> Are you sure about that ?
>
> See :
>
from osgeo import ogr
ogr.CreateGeometryFromWkb(g.ExportToWkb()).ExportToWkt()
> 'LINESTRING EMPTY'
ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
> EMPTY').ExportToWkb()).ExportToWkt()
> 'LINESTRING EMPTY'
ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
> EMPTY').ExportToWkb()).ExportToWkt()
> 'LINESTRING EMPTY'
ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POLYGON
> EMPTY').ExportToWkb()).ExportToWkt()
> 'POLYGON EMPTY'
ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTILINESTRING
> EMPTY').ExportToWkb()).ExportToWkt()
> 'MULTILINESTRING EMPTY'
ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTIPOLYGON
> EMPTY').ExportToWkb()).ExportToWkt()
> 'MULTIPOLYGON EMPTY'
ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('GEOMETRYCOLLECTION
> EMPTY').ExportToWkb()).ExportToWkt()
> 'GEOMETRYCOLLECTION EMPTY'
>
> The only exception is POINT EMPTY due to the lack of wkb representation for
> it
> :
ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POINT
> EMPTY').ExportToWkb()).ExportToWkt()
> 'POINT (0 0)'
>
>
>>
>> Fortunately the only substantial difference for ISO WKB is the type
>> number.
>>
>> I’m starting an isowkb branch on my git repo to hold this piece of work, I
>> don’t think it’ll be very big.
>>
>> Then I’ll start asking about ‘m’ dimensions :)
>
> That's a fresh new land to explore...
>
>>
>> P.
>>
>> --
>> Paul Ramsey
>> http://cleverelephant.ca
>> http://postgis.net
>>
>> On December 12, 2013 at 2:33:41 PM, Even Rouault
>> (even.roua...@mines-paris.org) wrote:
>>
>> Le jeudi 12 décembre 2013 21:36:42, Paul Ramsey a écrit :
>> > Hey all,
>> > Is there already a facility for writing out ISO-standard WKB in GDAL?
>> > The
>> > biggest difference is the wkbGeometryType number for the case of 3d
>> > features. OGR currently uses the old extended SFSQL adopted by PostGIS.
>> > ISO (naturally) did their own thing. As far as I can see, there’s no
>> > support there now, or is there? P.
>>
>> Hi Paul,
>>
>> no, there's no support for ISO WKB yet. We still stick to
>> http://home.gdal.org/projects/opengis/twohalfdsf.html
>>
>> I can imagine we could have exportToISOWkb() method in OGRGeometry*. Or we
>> could add an extra boolean argument bISOWkb to the existing exportToWkb().
>> Not sure about WkbSize() : does the size of ISO WKB blobs differ from the
>> unofficial WKB ?
>>
>> Even
>>
>> --
>> Geospatial professional services
>> http://even.rouault.free.fr/services.html
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Ah, right, it’s exposed.
Unfortunate, because it means that the OGC/ISO variant problem leaks into more
external things than just WKB.
I wonder how many people test dimensionality with getCoordinateDimension and
how many do it with (wkb25DBit & getGeometryType()), no way to know
unfortunately
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On December 13, 2013 at 1:21:40 PM, Even Rouault (even.roua...@mines-paris.org)
wrote:
Le vendredi 13 décembre 2013 21:51:57, Paul Ramsey a écrit :
> Actually, I think changing the contract on getGeometryType to only ever
> returning the basic (non-3d) type would clean up driver implementation
> code a bit. Grepping for it in the drivers, you see a lot of
>
> CPLAssert(wkbFlatten(poGeom->getGeometryType()) == wkbPoint)
>
> and
>
> || (poLine->getGeometryType() != wkbLineString
> && poLine->getGeometryType() != wkbLineString25D) )
>
> and very few unqualified calls to it.
This would have impacts on drivers, but also on external code since
OGR_G_GetGeometryType() is the C mapping of OGRGeometry::getGeometryType()
There are also OGRGeomField::GetType(), OGRFeatureDefn::GetGeomType() and
OGRLayer::GetGeomType() (and their C equivalents) that return wkbGeometryType.
I imagine that if we change the contract of OGRGeometry::getGeometryType(),
they should also behave similarly, for consistency.
So we have a backward compatibility issue here, which must be carefully
weighted in.
>
> P.
>
> --
> Paul Ramsey
> http://cleverelephant.ca
> http://postgis.net
>
> On December 13, 2013 at 12:00:34 PM, Paul Ramsey
> (pram...@cleverelephant.ca) wrote:
>
> I’ve pushed up some work to do this
>
> https://github.com/pramsey/gdal/tree/isowkb
>
> I had to change *two* method signatures, which I don’t really like, both
> exportToWkb and getGeometryType needed a variant parameter added. The
> problem is that getGeometryType returns the full WKB type, with
> dimensionality encoded, which makes it somewhat duplicative of
> getCoordinateDimension. In an ideal world, getGeometryType would only
> return the type number, and dimensionally information would be inferred
> from getCoordinateDimension.
>
> Then only the exportToWkb signature would need a variant parameter.
>
> importFromWkb also was changed to ingest the ISO variant if that’s what
> it’s fed. No changes to signature required there.
>
> P.
>
> --
> Paul Ramsey
> http://cleverelephant.ca
> http://postgis.net
>
> On December 12, 2013 at 2:58:05 PM, Even Rouault
> (even.roua...@mines-paris.org) wrote:
>
> Le jeudi 12 décembre 2013 23:39:25, Paul Ramsey a écrit :
> > I’ve been looking over the code, and I think I can make importFromWkb
> > consume ISO inputs with relatively minor changes. (during the geometry
> > type determination in the concrete types, it looks easy enough to add a
> > little logic to deal with ISO type numbers) For exportToWkb, I’m
> > wondering if maybe an optional parameter (wkbVariant?) that defaults to
> > wkbVariantOGC would be sufficient?
>
> Sounds good to me. Is "wkbVariantOGC" the variant currently implemented ?
> Is our 3D support really compliant with an OGC standard ?
>
> > It also seems the wkb reader/writer have little handling for empty
> > geometry types. I’d like to add some in, if that’s OK.
>
> Are you sure about that ?
>
> See :
> >>> from osgeo import ogr
> >>> ogr.CreateGeometryFromWkb(g.ExportToWkb()).ExportToWkt()
>
> 'LINESTRING EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'LINESTRING EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'LINESTRING EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POLYGON
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'POLYGON EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTILINESTRING
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'MULTILINESTRING EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTIPOLYGON
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'MULTIPOLYGON EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('GEOMETRYCOLLECTION
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'GEOMETRYCOLLECTION EMPTY'
>
> The only exception is POINT EMPTY due to the lack of wkb representation for
> it
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POINT
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'POINT (0 0)'
>
> > Fortunately the only substantial difference for ISO WKB is the type
> > number.
> >
> > I’m starting an isowkb branch on my git repo to hold this piece of work,
> > I don’t think it’ll be very big.
> >
> > Then I’ll start asking about ‘m’ dimensions :)
>
> That's a fre
Re: [gdal-dev] ISO WKB
Le vendredi 13 décembre 2013 21:51:57, Paul Ramsey a écrit :
> Actually, I think changing the contract on getGeometryType to only ever
> returning the basic (non-3d) type would clean up driver implementation
> code a bit. Grepping for it in the drivers, you see a lot of
>
> CPLAssert(wkbFlatten(poGeom->getGeometryType()) == wkbPoint)
>
> and
>
>|| (poLine->getGeometryType() != wkbLineString
> && poLine->getGeometryType() != wkbLineString25D) )
>
> and very few unqualified calls to it.
This would have impacts on drivers, but also on external code since
OGR_G_GetGeometryType() is the C mapping of OGRGeometry::getGeometryType()
There are also OGRGeomField::GetType(), OGRFeatureDefn::GetGeomType() and
OGRLayer::GetGeomType() (and their C equivalents) that return wkbGeometryType.
I imagine that if we change the contract of OGRGeometry::getGeometryType(),
they should also behave similarly, for consistency.
So we have a backward compatibility issue here, which must be carefully
weighted in.
>
> P.
>
> --
> Paul Ramsey
> http://cleverelephant.ca
> http://postgis.net
>
> On December 13, 2013 at 12:00:34 PM, Paul Ramsey
> (pram...@cleverelephant.ca) wrote:
>
> I’ve pushed up some work to do this
>
> https://github.com/pramsey/gdal/tree/isowkb
>
> I had to change *two* method signatures, which I don’t really like, both
> exportToWkb and getGeometryType needed a variant parameter added. The
> problem is that getGeometryType returns the full WKB type, with
> dimensionality encoded, which makes it somewhat duplicative of
> getCoordinateDimension. In an ideal world, getGeometryType would only
> return the type number, and dimensionally information would be inferred
> from getCoordinateDimension.
>
> Then only the exportToWkb signature would need a variant parameter.
>
> importFromWkb also was changed to ingest the ISO variant if that’s what
> it’s fed. No changes to signature required there.
>
> P.
>
> --
> Paul Ramsey
> http://cleverelephant.ca
> http://postgis.net
>
> On December 12, 2013 at 2:58:05 PM, Even Rouault
> (even.roua...@mines-paris.org) wrote:
>
> Le jeudi 12 décembre 2013 23:39:25, Paul Ramsey a écrit :
> > I’ve been looking over the code, and I think I can make importFromWkb
> > consume ISO inputs with relatively minor changes. (during the geometry
> > type determination in the concrete types, it looks easy enough to add a
> > little logic to deal with ISO type numbers) For exportToWkb, I’m
> > wondering if maybe an optional parameter (wkbVariant?) that defaults to
> > wkbVariantOGC would be sufficient?
>
> Sounds good to me. Is "wkbVariantOGC" the variant currently implemented ?
> Is our 3D support really compliant with an OGC standard ?
>
> > It also seems the wkb reader/writer have little handling for empty
> > geometry types. I’d like to add some in, if that’s OK.
>
> Are you sure about that ?
>
> See :
> >>> from osgeo import ogr
> >>> ogr.CreateGeometryFromWkb(g.ExportToWkb()).ExportToWkt()
>
> 'LINESTRING EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'LINESTRING EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'LINESTRING EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POLYGON
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'POLYGON EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTILINESTRING
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'MULTILINESTRING EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTIPOLYGON
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'MULTIPOLYGON EMPTY'
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('GEOMETRYCOLLECTION
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'GEOMETRYCOLLECTION EMPTY'
>
> The only exception is POINT EMPTY due to the lack of wkb representation for
> it
>
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POINT
>
> EMPTY').ExportToWkb()).ExportToWkt()
> 'POINT (0 0)'
>
> > Fortunately the only substantial difference for ISO WKB is the type
> > number.
> >
> > I’m starting an isowkb branch on my git repo to hold this piece of work,
> > I don’t think it’ll be very big.
> >
> > Then I’ll start asking about ‘m’ dimensions :)
>
> That's a fresh new land to explore...
>
> > P.
> >
> > --
> > Paul Ramsey
> > http://cleverelephant.ca
> > http://postgis.net
> >
> > On December 12, 2013 at 2:33:41 PM, Even Rouault
> > (even.roua...@mines-paris.org) wrote:
> >
> > Le jeudi 12 décembre 2013 21:36:42, Paul Ramsey a écrit :
> > > Hey all,
> > > Is there already a facility for writing out ISO-standard WKB in GDAL?
> > > The biggest difference is the wkbGeometryType number for the case of
> > > 3d features. OGR currently uses the old extended SFSQL adopted by
> > > PostGIS. ISO (naturally) did their own thing. As far as I can see,
> > > there’s no support there now, or is there? P.
> >
> >
Re: [gdal-dev] ISO WKB
Le vendredi 13 décembre 2013 21:00:33, Paul Ramsey a écrit :
> I’ve pushed up some work to do this
>
> https://github.com/pramsey/gdal/tree/isowkb
>
> I had to change *two* method signatures, which I don’t really like, both
> exportToWkb and getGeometryType needed a variant parameter added. The
> problem is that getGeometryType returns the full WKB type, with
> dimensionality encoded, which makes it somewhat duplicative of
> getCoordinateDimension. In an ideal world, getGeometryType would only
> return the type number, and dimensionally information would be inferred
> from getCoordinateDimension.
>
> Then only the exportToWkb signature would need a variant parameter.
>
> importFromWkb also was changed to ingest the ISO variant if that’s what
> it’s fed. No changes to signature required there.
The fact that getGeometryType() returns type + dimensionality is actually not
new to your proposal.
The main issue I see is that, now, the OGRwkbGeometryType enumeration contains
different ways of encoding the same information. For mortals, a wkbPoint25D is
the same as a wkbPointIsoZ. As OGRwkbGeometryType belongs to the OGR public C
API, we must be careful when touching it. The direct consequence of
introducing new values is that all code that currently accepts
OGRwkbGeometryType as an argument will not know what to do with it if it is
fed with a wkb*IsoZ value. Such code is for example the implementation of
the CreateLayer() method of all existing OGR drivers that have creation
capabilities. The wkbFlatten() macro will not work on IsoZ constants.
Perhaps a documentation note saying that the wkbIsoZ values are only
returned by getGeometryType(OGRwkbVariant = wkbVariantIso), and should not be
used as values of parameters of any method should be sufficient ?
Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso, ...
wkbGeometryCollectionIso, wkbPointIsoZ, ... wkbGeometryCollectionIsoZ }, a
getIsoGeometryType() method that returns it, and the exportToWkb() methods
that calls int getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
wkbVariantOgc) ? getGeometryType() : getIsoGeometryType(); }
I'm not sure what's the best way of addressing that. It looks like the now
famous motto "We can't be compatible to MULTIPLE standards at the same time."
applies...
Even
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Actually, I think changing the contract on getGeometryType to only ever
returning the basic (non-3d) type would clean up driver implementation code a
bit. Grepping for it in the drivers, you see a lot of
CPLAssert(wkbFlatten(poGeom->getGeometryType()) == wkbPoint)
and
|| (poLine->getGeometryType() != wkbLineString
&& poLine->getGeometryType() != wkbLineString25D) )
and very few unqualified calls to it.
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On December 13, 2013 at 12:00:34 PM, Paul Ramsey (pram...@cleverelephant.ca)
wrote:
I’ve pushed up some work to do this
https://github.com/pramsey/gdal/tree/isowkb
I had to change *two* method signatures, which I don’t really like, both
exportToWkb and getGeometryType needed a variant parameter added. The problem
is that getGeometryType returns the full WKB type, with dimensionality encoded,
which makes it somewhat duplicative of getCoordinateDimension. In an ideal
world, getGeometryType would only return the type number, and dimensionally
information would be inferred from getCoordinateDimension.
Then only the exportToWkb signature would need a variant parameter.
importFromWkb also was changed to ingest the ISO variant if that’s what it’s
fed. No changes to signature required there.
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On December 12, 2013 at 2:58:05 PM, Even Rouault (even.roua...@mines-paris.org)
wrote:
Le jeudi 12 décembre 2013 23:39:25, Paul Ramsey a écrit :
> I’ve been looking over the code, and I think I can make importFromWkb
> consume ISO inputs with relatively minor changes. (during the geometry
> type determination in the concrete types, it looks easy enough to add a
> little logic to deal with ISO type numbers) For exportToWkb, I’m wondering
> if maybe an optional parameter (wkbVariant?) that defaults to
> wkbVariantOGC would be sufficient?
Sounds good to me. Is "wkbVariantOGC" the variant currently implemented ? Is
our 3D support really compliant with an OGC standard ?
>
> It also seems the wkb reader/writer have little handling for empty geometry
> types. I’d like to add some in, if that’s OK.
Are you sure about that ?
See :
>>> from osgeo import ogr
>>> ogr.CreateGeometryFromWkb(g.ExportToWkb()).ExportToWkt()
'LINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
EMPTY').ExportToWkb()).ExportToWkt()
'LINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
EMPTY').ExportToWkb()).ExportToWkt()
'LINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POLYGON
EMPTY').ExportToWkb()).ExportToWkt()
'POLYGON EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTILINESTRING
EMPTY').ExportToWkb()).ExportToWkt()
'MULTILINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTIPOLYGON
EMPTY').ExportToWkb()).ExportToWkt()
'MULTIPOLYGON EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('GEOMETRYCOLLECTION
EMPTY').ExportToWkb()).ExportToWkt()
'GEOMETRYCOLLECTION EMPTY'
The only exception is POINT EMPTY due to the lack of wkb representation for it
:
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POINT
EMPTY').ExportToWkb()).ExportToWkt()
'POINT (0 0)'
>
> Fortunately the only substantial difference for ISO WKB is the type number.
>
> I’m starting an isowkb branch on my git repo to hold this piece of work, I
> don’t think it’ll be very big.
>
> Then I’ll start asking about ‘m’ dimensions :)
That's a fresh new land to explore...
>
> P.
>
> --
> Paul Ramsey
> http://cleverelephant.ca
> http://postgis.net
>
> On December 12, 2013 at 2:33:41 PM, Even Rouault
> (even.roua...@mines-paris.org) wrote:
>
> Le jeudi 12 décembre 2013 21:36:42, Paul Ramsey a écrit :
> > Hey all,
> > Is there already a facility for writing out ISO-standard WKB in GDAL? The
> > biggest difference is the wkbGeometryType number for the case of 3d
> > features. OGR currently uses the old extended SFSQL adopted by PostGIS.
> > ISO (naturally) did their own thing. As far as I can see, there’s no
> > support there now, or is there? P.
>
> Hi Paul,
>
> no, there's no support for ISO WKB yet. We still stick to
> http://home.gdal.org/projects/opengis/twohalfdsf.html
>
> I can imagine we could have exportToISOWkb() method in OGRGeometry*. Or we
> could add an extra boolean argument bISOWkb to the existing exportToWkb().
> Not sure about WkbSize() : does the size of ISO WKB blobs differ from the
> unofficial WKB ?
>
> Even
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
I’ve pushed up some work to do this
https://github.com/pramsey/gdal/tree/isowkb
I had to change *two* method signatures, which I don’t really like, both
exportToWkb and getGeometryType needed a variant parameter added. The problem
is that getGeometryType returns the full WKB type, with dimensionality encoded,
which makes it somewhat duplicative of getCoordinateDimension. In an ideal
world, getGeometryType would only return the type number, and dimensionally
information would be inferred from getCoordinateDimension.
Then only the exportToWkb signature would need a variant parameter.
importFromWkb also was changed to ingest the ISO variant if that’s what it’s
fed. No changes to signature required there.
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On December 12, 2013 at 2:58:05 PM, Even Rouault (even.roua...@mines-paris.org)
wrote:
Le jeudi 12 décembre 2013 23:39:25, Paul Ramsey a écrit :
> I’ve been looking over the code, and I think I can make importFromWkb
> consume ISO inputs with relatively minor changes. (during the geometry
> type determination in the concrete types, it looks easy enough to add a
> little logic to deal with ISO type numbers) For exportToWkb, I’m wondering
> if maybe an optional parameter (wkbVariant?) that defaults to
> wkbVariantOGC would be sufficient?
Sounds good to me. Is "wkbVariantOGC" the variant currently implemented ? Is
our 3D support really compliant with an OGC standard ?
>
> It also seems the wkb reader/writer have little handling for empty geometry
> types. I’d like to add some in, if that’s OK.
Are you sure about that ?
See :
>>> from osgeo import ogr
>>> ogr.CreateGeometryFromWkb(g.ExportToWkb()).ExportToWkt()
'LINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
EMPTY').ExportToWkb()).ExportToWkt()
'LINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
EMPTY').ExportToWkb()).ExportToWkt()
'LINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POLYGON
EMPTY').ExportToWkb()).ExportToWkt()
'POLYGON EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTILINESTRING
EMPTY').ExportToWkb()).ExportToWkt()
'MULTILINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTIPOLYGON
EMPTY').ExportToWkb()).ExportToWkt()
'MULTIPOLYGON EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('GEOMETRYCOLLECTION
EMPTY').ExportToWkb()).ExportToWkt()
'GEOMETRYCOLLECTION EMPTY'
The only exception is POINT EMPTY due to the lack of wkb representation for it
:
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POINT
EMPTY').ExportToWkb()).ExportToWkt()
'POINT (0 0)'
>
> Fortunately the only substantial difference for ISO WKB is the type number.
>
> I’m starting an isowkb branch on my git repo to hold this piece of work, I
> don’t think it’ll be very big.
>
> Then I’ll start asking about ‘m’ dimensions :)
That's a fresh new land to explore...
>
> P.
>
> --
> Paul Ramsey
> http://cleverelephant.ca
> http://postgis.net
>
> On December 12, 2013 at 2:33:41 PM, Even Rouault
> (even.roua...@mines-paris.org) wrote:
>
> Le jeudi 12 décembre 2013 21:36:42, Paul Ramsey a écrit :
> > Hey all,
> > Is there already a facility for writing out ISO-standard WKB in GDAL? The
> > biggest difference is the wkbGeometryType number for the case of 3d
> > features. OGR currently uses the old extended SFSQL adopted by PostGIS.
> > ISO (naturally) did their own thing. As far as I can see, there’s no
> > support there now, or is there? P.
>
> Hi Paul,
>
> no, there's no support for ISO WKB yet. We still stick to
> http://home.gdal.org/projects/opengis/twohalfdsf.html
>
> I can imagine we could have exportToISOWkb() method in OGRGeometry*. Or we
> could add an extra boolean argument bISOWkb to the existing exportToWkb().
> Not sure about WkbSize() : does the size of ISO WKB blobs differ from the
> unofficial WKB ?
>
> Even
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
On 13-12-13 00:24, Paul Ramsey wrote: The GeoPackage document actually specifies a representation for POINT EMPTY, "In GeoPackages these points SHALL be encoded as a Point where each coordinate value is set to an IEEE-754 quiet NaN value". I'm to blame for this one. It's specified in the GeoPackage spec because it's not specified in SFSQL or SQLMM and I didn't want to leave this as an unspecified part of the encoding. The reason I pushed for the nan based encoding is that it provides an encoding of 'point empty' that does not lose information. The alternative of encoding it as null or multipoint empty changes the semantics of the object. If you stick with the point wkb type then the only option for special values is special double values. point(nan nan) seemed like a reasonable approximation of point empty; a point where the coordinates are not valid numbers. If you think this is a bad idea or causes real difficulties in implementation please let me know, I'll bring it up in the geopackage swg then. Alternative solutions are also welcome of course. Pepijn ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
On 12 December 2013 23:24, Paul Ramsey wrote: > > The GeoPackage document actually specifies a representation for POINT EMPTY, > "In GeoPackages these points SHALL be encoded as a Point where each > coordinate value is set to an IEEE-754 quiet NaN value”. Couldn't OGC and ISO unify *all* their specs to quitely NaN? Or, couldn't FOSS implementations (PostGIS, OGR, ...) unify regardless the 'unspecified behaviour' in (some) specs? Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Sounds good to me. Is "wkbVariantOGC" the variant currently implemented ? Is our 3D support really compliant with an OGC standard ? Not really anymore, since SFSQL 1.2 defined OGC into sync with ISO. We’re in compliance with the old guidance that was passed and promptly forgotten in the period between SFSQL 1.1 and 1.2. Nothing wrong with that, we can call it something else (I guess?) > It also seems the wkb reader/writer have little handling for empty geometry > types. I’d like to add some in, if that’s OK. Are you sure about that ? Nope, you’re right. The empty support is implicitly tied to the understanding that numPoints == 0 means empty and numRings == 0 means empty and numGeoms == 0 means empty, rather than an IsEmpty() test. The GeoPackage document actually specifies a representation for POINT EMPTY, "In GeoPackages these points SHALL be encoded as a Point where each coordinate value is set to an IEEE-754 quiet NaN value”. P___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
On 12 Dec 2013 22:58, "Even Rouault" wrote:
>
> Le jeudi 12 décembre 2013 23:39:25, Paul Ramsey a écrit :
> > It also seems the wkb reader/writer have little handling for empty
geometry
> > types. I’d like to add some in, if that’s OK.
>
> Are you sure about that ?
>
> See :
>
> >>> from osgeo import ogr
> >>> ogr.CreateGeometryFromWkb(g.ExportToWkb()).ExportToWkt()
> 'LINESTRING EMPTY'
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
> EMPTY').ExportToWkb()).ExportToWkt()
> 'LINESTRING EMPTY'
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
> EMPTY').ExportToWkb()).ExportToWkt()
> 'LINESTRING EMPTY'
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POLYGON
> EMPTY').ExportToWkb()).ExportToWkt()
> 'POLYGON EMPTY'
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTILINESTRING
> EMPTY').ExportToWkb()).ExportToWkt()
> 'MULTILINESTRING EMPTY'
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTIPOLYGON
> EMPTY').ExportToWkb()).ExportToWkt()
> 'MULTIPOLYGON EMPTY'
> >>>
ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('GEOMETRYCOLLECTION
> EMPTY').ExportToWkb()).ExportToWkt()
> 'GEOMETRYCOLLECTION EMPTY'
>
> The only exception is POINT EMPTY due to the lack of wkb representation
for it
> :
> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POINT
> EMPTY').ExportToWkb()).ExportToWkt()
> 'POINT (0 0)'
See
http://blog.cleverelephant.ca/2010/03/nothing-nada-zip-bupkus.html
--
Mateusz Łoskot, http://mateusz.loskot.net
(Sent from mobile, apology for top-posting or broken quotes)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Le jeudi 12 décembre 2013 23:39:25, Paul Ramsey a écrit :
> I’ve been looking over the code, and I think I can make importFromWkb
> consume ISO inputs with relatively minor changes. (during the geometry
> type determination in the concrete types, it looks easy enough to add a
> little logic to deal with ISO type numbers) For exportToWkb, I’m wondering
> if maybe an optional parameter (wkbVariant?) that defaults to
> wkbVariantOGC would be sufficient?
Sounds good to me. Is "wkbVariantOGC" the variant currently implemented ? Is
our 3D support really compliant with an OGC standard ?
>
> It also seems the wkb reader/writer have little handling for empty geometry
> types. I’d like to add some in, if that’s OK.
Are you sure about that ?
See :
>>> from osgeo import ogr
>>> ogr.CreateGeometryFromWkb(g.ExportToWkb()).ExportToWkt()
'LINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
EMPTY').ExportToWkb()).ExportToWkt()
'LINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING
EMPTY').ExportToWkb()).ExportToWkt()
'LINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POLYGON
EMPTY').ExportToWkb()).ExportToWkt()
'POLYGON EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTILINESTRING
EMPTY').ExportToWkb()).ExportToWkt()
'MULTILINESTRING EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTIPOLYGON
EMPTY').ExportToWkb()).ExportToWkt()
'MULTIPOLYGON EMPTY'
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('GEOMETRYCOLLECTION
EMPTY').ExportToWkb()).ExportToWkt()
'GEOMETRYCOLLECTION EMPTY'
The only exception is POINT EMPTY due to the lack of wkb representation for it
:
>>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POINT
EMPTY').ExportToWkb()).ExportToWkt()
'POINT (0 0)'
>
> Fortunately the only substantial difference for ISO WKB is the type number.
>
> I’m starting an isowkb branch on my git repo to hold this piece of work, I
> don’t think it’ll be very big.
>
> Then I’ll start asking about ‘m’ dimensions :)
That's a fresh new land to explore...
>
> P.
>
> --
> Paul Ramsey
> http://cleverelephant.ca
> http://postgis.net
>
> On December 12, 2013 at 2:33:41 PM, Even Rouault
> (even.roua...@mines-paris.org) wrote:
>
> Le jeudi 12 décembre 2013 21:36:42, Paul Ramsey a écrit :
> > Hey all,
> > Is there already a facility for writing out ISO-standard WKB in GDAL? The
> > biggest difference is the wkbGeometryType number for the case of 3d
> > features. OGR currently uses the old extended SFSQL adopted by PostGIS.
> > ISO (naturally) did their own thing. As far as I can see, there’s no
> > support there now, or is there? P.
>
> Hi Paul,
>
> no, there's no support for ISO WKB yet. We still stick to
> http://home.gdal.org/projects/opengis/twohalfdsf.html
>
> I can imagine we could have exportToISOWkb() method in OGRGeometry*. Or we
> could add an extra boolean argument bISOWkb to the existing exportToWkb().
> Not sure about WkbSize() : does the size of ISO WKB blobs differ from the
> unofficial WKB ?
>
> Even
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
I’ve been looking over the code, and I think I can make importFromWkb consume ISO inputs with relatively minor changes. (during the geometry type determination in the concrete types, it looks easy enough to add a little logic to deal with ISO type numbers) For exportToWkb, I’m wondering if maybe an optional parameter (wkbVariant?) that defaults to wkbVariantOGC would be sufficient? It also seems the wkb reader/writer have little handling for empty geometry types. I’d like to add some in, if that’s OK. Fortunately the only substantial difference for ISO WKB is the type number. I’m starting an isowkb branch on my git repo to hold this piece of work, I don’t think it’ll be very big. Then I’ll start asking about ‘m’ dimensions :) P. -- Paul Ramsey http://cleverelephant.ca http://postgis.net On December 12, 2013 at 2:33:41 PM, Even Rouault (even.roua...@mines-paris.org) wrote: Le jeudi 12 décembre 2013 21:36:42, Paul Ramsey a écrit : > Hey all, > Is there already a facility for writing out ISO-standard WKB in GDAL? The > biggest difference is the wkbGeometryType number for the case of 3d > features. OGR currently uses the old extended SFSQL adopted by PostGIS. > ISO (naturally) did their own thing. As far as I can see, there’s no > support there now, or is there? P. Hi Paul, no, there's no support for ISO WKB yet. We still stick to http://home.gdal.org/projects/opengis/twohalfdsf.html I can imagine we could have exportToISOWkb() method in OGRGeometry*. Or we could add an extra boolean argument bISOWkb to the existing exportToWkb(). Not sure about WkbSize() : does the size of ISO WKB blobs differ from the unofficial WKB ? Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ISO WKB
Le jeudi 12 décembre 2013 21:36:42, Paul Ramsey a écrit : > Hey all, > Is there already a facility for writing out ISO-standard WKB in GDAL? The > biggest difference is the wkbGeometryType number for the case of 3d > features. OGR currently uses the old extended SFSQL adopted by PostGIS. > ISO (naturally) did their own thing. As far as I can see, there’s no > support there now, or is there? P. Hi Paul, no, there's no support for ISO WKB yet. We still stick to http://home.gdal.org/projects/opengis/twohalfdsf.html I can imagine we could have exportToISOWkb() method in OGRGeometry*. Or we could add an extra boolean argument bISOWkb to the existing exportToWkb(). Not sure about WkbSize() : does the size of ISO WKB blobs differ from the unofficial WKB ? Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
