[postgis-devel] wkb geometry type codes: PostGIS vs OGC

[Raven Kopelman]

Hi Paul,

I appreciate the confirmation that I'm not crazy; we'll add a flag to
allow side-by-side support for conflicting WKB implementations within
FME.

Looking forward to PostGIS 2.0!

Thanks,
Raven


On Wed, May 5, 2010 at 11:52 AM,
<postgis-devel-request at postgis.refractions.net> wrote:
> ------------------------------
>
> Message: 7
> Date: Wed, 5 May 2010 11:52:51 -0700
> From: Paul Ramsey <pramsey at cleverelephant.ca>
> Subject: Re: [postgis-devel] wkb geometry type codes: PostGIS vs OGC
> To: PostGIS Development Discussion
>        <postgis-devel at postgis.refractions.net>,        Mark Leslie
>        <mark.leslie at lisasoft.com>
> Message-ID:
>        <p2r30fe546d1005051152nc54d164t5305be4bee275852 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Raven,
>
> Well, reading through the code base shows that you are, in fact,
> correct. We are just relaying our internal type numbers out into the
> WKB, the net effect being that we are producing non-standard WKB for
>
> #define CURVEPOLYTYPE    13 /*should be 10*/
> #define MULTICURVETYPE   14 /*should be 11*/
> #define MULTISURFACETYPE 15 /*should be 12*/
>
> So... where from here? My new WKB emitter for 2.0 is designed to
> return the standard, correct, type numbers.
>
> What do you think, as a consumer of our... er... product. ?
>
> P
>
> On Wed, May 5, 2010 at 10:27 AM, Raven Kopelman <raven.kopelman at safe.com> wrote:
>> Hi Paul,
>>
>> While your response is exactly what I would have hoped for, it does
>> call my ability to read WKB into question.
>>
>> The following are query/result pairs as run through pgAdmin III,
>> against PostGIS 1.5
>>
>> select ST_AsBinary(ST_GeometryFromText('COMPOUNDCURVE(CIRCULARSTRING(0
>> 0, 1 1, 1 0),(1 0, 0 1))', 4236));
>> "\001\011\000\000\000\002\000\000\000\001\010\000\000\000\003\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\360?\000\000\000\000\000\000\360?\000\000\000\000\000\000\360?\000\000\000\000\000\000\000\000\001\002\000\000\000\002\000\000\000\000\000\000\000\000\000\360?\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\360?"
>>
>> select ST_AsBinary(ST_GeometryFromText('CURVEPOLYGON(CIRCULARSTRING(0
>> 0, 4 0, 4 4, 0 4, 0 0),(1 1, 3 3, 3 1, 1 1))', 4236));
>> "\001\015\000\000\000\002\000\000\000\001\010\000\000\000\005\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\020@\000\000\000\000\000\000\000\000\000\000\000\000\000\000\020@\000\000\000\000\000\000\020@\000\000\000\000\000\000\000\000\000\000\000\000\000\000\020@\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\001\002\000\000\000\004\000\000\000\000\000\000\000\000\000\360?\000\000\000\000\000\000\360?\000\000\000\000\000\000\010@\000\000\000\000\000\000\010@\000\000\000\000\000\000\010@\000\000\000\000\000\000\360?\000\000\000\000\000\000\360?\000\000\000\000\000\000\360?"
>>
>> In the case of the compound curve, I see a geometry type of \011 which
>> I believe means 9, which matches the OGC as well as liblwgeom.h.
>>
>> In the case of the curve polygon, I see a geometry type of \015 which
>> I believe means 13, which matches liblwgeom.h, but not the OGC.
>> Multicurve and Multisurface are similarly "off".
>>
>> If you can point out my error I would greatly appreciate it.
>>
>> Thanks,
>> Raven
>>
>>
>> On Tue, May 4, 2010 at 5:14 PM,
>> <postgis-devel-request at postgis.refractions.net> wrote:
>>> Message: 5
>>> Date: Tue, 4 May 2010 14:19:00 -0700
>>> From: Paul Ramsey <pramsey at cleverelephant.ca>
>>> Subject: Re: [postgis-devel] wkb geometry type codes: PostGIS vs OGC
>>> To: PostGIS Development Discussion
>>> ? ? ? ?<postgis-devel at postgis.refractions.net>
>>> Message-ID:
>>> ? ? ? ?<y2h30fe546d1005041419qa0926deaze1911f76efd600e7 at mail.gmail.com>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> Raven,
>>>
>>> The WKB emitted by PostGIS will use the standard OGC type codes. The
>>> internal structure of PostGIS will use its own type codes. Even the
>>> EWKB emitted by PostGIS will use the OGC type codes. So your parser
>>> shouldn't know/care what values we have in liblwgeom.h
>>>
>>> Yours,
>>>
>>> Paul
>>>
>>> On Tue, May 4, 2010 at 2:10 PM, Raven Kopelman <raven.kopelman at safe.com> wrote:
>>> > Hi PostGIS developers,
>>> >
>>> > I'm working on PostGIS support for Safe Software's FME and have a couple
>>> > questions about the way PostGIS does things.
>>> >
>>> > In particular, it looks like the WKB geometry type codes used by PostGIS
>>> > don't line up with those specified by the OGC.
>>> >
>>> > For example, from liblwgeom.h:
>>> >>
>>> >> #define CURVEPOLYTYPE 13
>>> >> #define MULTICURVETYPE 14
>>> >> #define MULTISURFACETYPE 15
>>> >
>>> > Whereas the OGC has
>>> >>
>>> >> CurvePolygon 10
>>> >> MultiCurve 11
>>> >> MultiSurface 12
>>> >> Curve 13
>>> >> Surface 14
>>> >> PolyhedralSurface 15
>>> >
>>> > SQLMM of course offers some completely different alternate choices,
>>> > something like:
>>> >>
>>> >> CurvePolygon 1000003
>>> >> Multicurve 1000004
>>> >> Multisurface 1000005
>>> >
>>> > which, if I recall the values correctly, have an unexpected (and possibly
>>> > coincidental) alignment with the PostGIS choices...
>>> >
>>> > I'm curious about this apparent discrepancy, and what it implies about my
>>> > chances of keeping our WKB parser more or less vendor neutral.
>>> >
>>> > And I haven't tested this yet, but I presume that ST_AsBinary() will return
>>> > the same PostGIS specific type codes as ST_AsEWKB()?
>>> >
>>> > Thanks,
>>> > Raven