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

[Paul Ramsey]

My 2.0 WKB emitter is biased in favor of the ISO SQL/MM numbers for
core types and the ZM variants, but can output standard (well, our
bit-flagged extended standard) OGC as well. I see I'm going to have to
add a backwards mode too, to output pre-2.0 PostGIS WKB since it's not
quite as standard as I thought.

P.

On Thu, May 6, 2010 at 9:20 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Paul Ramsey wrote:
>
>> 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
>
> Note that even these are also at odds with the SQL-MM specification too:
>
> <well-known binary representation>  <uint32> Value
> <wkbpoint>                          1 (one)
> <wkblinestring>                     2
> <wkbcircularstring>                 1000001
> <wkbcompoundcurve>                  1000002
> <wkbpolygon>                        3
> <wkbcurvepolygon>                   1000003
> <wkbmultipoint>                     4
> <wkbmulticurve>                     1000004
> <wkbmultilinestring>                5
> <wkbmultisurface>                   1000005
> <wkbmultipolygon>                   6
> <wkbgeometrycollection>             7
> <wkbpointzm>                        2000001
> <wkblinestringzm>                   2000002
> <wkbcircularstringzm>               2000003
> <wkbcompoundcurvezm>                2000004
> <wkbpolygonzm>                      2000005
> <wkbcurvepolygonzm>                 2000006
> <wkbmultipointzm>                   2000007
> <wkbmulticurvezm>                   2000008
> <wkbmultilinestringzm>              2000009
> <wkbmultisurfacezm>                 2000010
> <wkbmultipolygonzm>                 2000011
> <wkbgeometrycollectionzm>           2000012
> <wkbpointz>                         3000001
> <wkblinestringz>                    3000002
> <wkbcircularstringz>                3000003
> <wkbcompoundcurvez>                 3000004
> <wkbpolygonz>                       3000005
> <wkbcurvepolygonz>                  3000006
> <wkbmultipointz>                    3000007
> <wkbmulticurvez>                    3000008
> <wkbmultilinestringz>               3000009
> <wkbmultisurfacez>                  3000010
> <wkbmultipolygonz>                  3000011
> <wkbgeometrycollectionz>            3000012
> <wkbpointm>                         4000001
> <wkblinestringm>                    4000002
> <wkbcircularstringm>                4000003
> <wkbcompoundcurvem>                 4000004
> <wkbpolygonm>                       4000005
> <wkbcurvepolygonm>                  4000006
> <wkbmultipointm>                    4000007
> <wkbmulticurvem>                    4000008
> <wkbmultilinestringm>               4000009
> <wkbmultisurfacem>                  4000010
> <wkbmultipolygonm>                  4000011
> <wkbgeometrycollectionm>            4000012
>
> So which way do we want to do? I'd be more inclined to head towards SQL/MM
> rather than OGC. I guess if we're going to change this, 2.0 is the time to
> do it.
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland - Senior Technical Architect
> PostgreSQL - PostGIS
> Sirius Corporation plc - control through freedom
> http://www.siriusit.co.uk
> t: +44 870 608 0063
>
> Sirius Labs: http://www.siriusit.co.uk/labs
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>