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
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
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,
Selon Paul Ramsey pram...@cleverelephant.ca:
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
On 17 December 2013 09:03, Even Rouault even.roua...@mines-paris.org wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
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
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,
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
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
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
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
even.roua...@mines-paris.org wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
Back to
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
On 17 December 2013 20:16, Dmitriy Baryshnikov bishop@gmail.com 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
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
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 pram...@cleverelephant.ca wrote:
I’ve pushed up some work to do this
https://github.com/pramsey/gdal/tree/isowkb
On 12 December 2013 23:24, Paul Ramsey pram...@cleverelephant.ca 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
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
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
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
||
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
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
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
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
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
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
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
On 12 Dec 2013 22:58, Even Rouault even.roua...@mines-paris.org 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 :
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
27 matches
Mail list logo
