#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.