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,
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
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 did
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
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 dat
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
param
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.o
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
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.
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
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
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
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 t
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 *tw
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
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(po
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
>
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->getGeometr
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 dimensio
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 GeoPac
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 sp
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
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 imp
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
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
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 (nat
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 supp
27 matches
Mail list logo
