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

[Paul Ramsey]

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
>> >
>> > _______________________________________________
>> > postgis-devel mailing list
>> > postgis-devel at postgis.refractions.net
>> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>