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

[Mark Cave-Ayland]

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