[postgis-devel] [PostGIS] #1807: ERROR: Unknown WKB type (13)! Full WKB type number was (13)

PostGIS trac at osgeo.org
Thu May 17 08:10:58 PDT 2012


#1807: ERROR:  Unknown WKB type (13)! Full WKB type number was (13)
---------------------------+------------------------------------------------
 Reporter:  hsingh19       |       Owner:  pramsey      
     Type:  defect         |      Status:  new          
 Priority:  high           |   Milestone:  PostGIS 2.0.1
Component:  postgis        |     Version:  2.0.x        
 Keywords:  Full WKB type  |  
---------------------------+------------------------------------------------

Comment(by pramsey):

 This patch fixes it, but I'm ambivalent about the "solution" the core
 problem is this.

 Back in 1.5, the type number used internally were mapped directly into the
 WKB type number, so these are the numbers that were emitted for each type.
 {{{
 #define POINTTYPE       1
 #define LINETYPE        2
 #define POLYGONTYPE     3
 #define MULTIPOINTTYPE  4
 #define MULTILINETYPE   5
 #define MULTIPOLYGONTYPE        6
 #define COLLECTIONTYPE  7
 #define CIRCSTRINGTYPE    8
 #define COMPOUNDTYPE      9
 #define CURVEPOLYTYPE    13
 #define MULTICURVETYPE   14
 #define MULTISURFACETYPE 15
 }}}
 In 2.0 we started using the ISO SQL/MM type numbers, and we decoupled the
 WKB numbers from the internal numbers, so we wouldn't have to change our
 internal format if the spec changed. The WKB numbers we are using are
 these:
 {{{
 #define WKB_POINT_TYPE 1
 #define WKB_LINESTRING_TYPE 2
 #define WKB_POLYGON_TYPE 3
 #define WKB_MULTIPOINT_TYPE 4
 #define WKB_MULTILINESTRING_TYPE 5
 #define WKB_MULTIPOLYGON_TYPE 6
 #define WKB_GEOMETRYCOLLECTION_TYPE 7
 #define WKB_CIRCULARSTRING_TYPE 8
 #define WKB_COMPOUNDCURVE_TYPE 9
 #define WKB_CURVEPOLYGON_TYPE 10
 #define WKB_MULTICURVE_TYPE 11
 #define WKB_MULTISURFACE_TYPE 12
 #define WKB_CURVE_TYPE 13 /* from ISO draft, not sure is real */
 #define WKB_SURFACE_TYPE 14 /* from ISO draft, not sure is real */
 #define WKB_POLYHEDRALSURFACE_TYPE 15
 #define WKB_TIN_TYPE 16
 #define WKB_TRIANGLE_TYPE 17
 }}}
 Note that they are *different* once you get above 9. The old numbers
 skipped 10, 11, 12, which were used for internal purposes in the parser.

 And it gets worse. Only the numbers up to 12 are in ISO SQL/MM. 13 and 14
 appeared in a draft, but appear to have no concrete instantiations. The
 numbers we are using for PolyhedralSurface, TIN, and Triangle were chosen
 more or less at random from the top of the queue. The OGC SFSQL1.2
 document says that PolyhedralSurface is coming in a future SQL/MM
 revision, and at that point who knows *what* numbers (or binary
 structures) it will use for the 3D objects.

 The point here is that our "well known" binary is getting less well known.

 Because of the 1.5/2.0 differences, it's possible to emit dumps from 1.5
 that don't load in 2.0. The patch fixes this for CurvePoly and MultiCurve,
 but re-claiming those numbers from the abstract types 13 and 14 that
 aren't actually used by the 2.0 WKB code. That leaves 15 with a clear
 conflict, meaning MultiSurface in 1.5 and PolyhedralSurface in 2.0.

 Another issue I can't believe got by our testing round.

 There are no good fixes.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1807#comment:6>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.


More information about the postgis-devel mailing list