ERROR: Unknown WKB type (13)! Full WKB type number was (13)

[hsingh19]

I installed Postgres 9.1.3 and Postgis 2.0. When I tried to restore the dump from Postgres 9.0.3 / Postgis 1.5 , I get ERROR: Unknown WKB type (13)! Full WKB type number was (13) error. Any suggestions or Ideas.

[robe]

Hmm I think 13 corresponds to circular string as I recall. Shouldn't have issues loading those unless it is going thru a function that doesn't support it. Which OS are you on?

[pramsey]

Yes, that's an exciting error. A tiny dump file that exhibits it would be appreciated.

[hsingh19]

I am on Solaris 10.

[pramsey]

Like I said, a small test data file that shows up the problem would be super. Make a tiny table (select * from something limit 10) on your 1.5 instance, dump it, confirm it fails to load on your 2.0 instance, then attach it to this ticket.

[pramsey]

I made my own. The WKB numbers emitted by 1.5 seem to be incompatible with those in 2.0, though in fact 13 is a legal number in 2.0 (just for a different object type) so more investigation to completely characterise this is needed.

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

[pramsey]

One small piece of good news, wikipedia things our PolyhedralSurface, TIN and Triangle numbers are correct ​http://en.wikipedia.org/wiki/Well-known_text#Well-known_binary

Still leaves us with a 1.5/2.0 conflict on number 15.

[Mike Taves]

Replying to pramsey:

One small piece of good news, wikipedia things our PolyhedralSurface, TIN and Triangle numbers are correct ​http://en.wikipedia.org/wiki/Well-known_text#Well-known_binary

I added this to Wikipedia a while back (I'm pretty much an inactive editor now), and I found the WKB codes from "OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture" (OGC 06-103r4), date 2011-05-28, version 1.2.1, downloaded from ​http://www.opengeospatial.org/standards/is

Look at pages 64-72

[pramsey]

OK, better news. Although I wouldn't put choosing different numbers past ISO. OGC looks to ISO, but less often the other way around.

[robe]

pramsey — your patch seems like a good compromise to me.

[mcayland]

I'm fairly sure this came up in discussion earlier in 2.0 development (as the ISO-MM draft uses numbers like 1000000X in the copy I have) but still…

If there isn't a standard then I guess all we can do is extend it using the principle of least surprise and document it. I like the comment in the patch, but I'm wondering if we do need a slightly more formal description of WKB types in the documentation so that other people can find it easily and use it as a reference?

Also: isn't the patch missing an extra break statement?

[pramsey]

OK, committed at r9761