Opened 7 years ago

Closed 7 years ago

#1807 closed defect (fixed)

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

Reported by: hsingh19 Owned by: pramsey
Priority: high Milestone: PostGIS 2.0.1
Component: postgis Version: 2.0.x
Keywords: Full WKB type Cc:

Description

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.

Attachments (2)

wkbtest.sql (774 bytes) - added by pramsey 7 years ago.
wkb.patch (796 bytes) - added by pramsey 7 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 7 years ago by 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?

comment:2 Changed 7 years ago by pramsey

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

comment:3 Changed 7 years ago by hsingh19

I am on Solaris 10.

comment:4 Changed 7 years ago by 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.

Changed 7 years ago by pramsey

Attachment: wkbtest.sql added

comment:5 Changed 7 years ago by 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.

Changed 7 years ago by pramsey

Attachment: wkb.patch added

comment:6 Changed 7 years ago 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.

comment:7 Changed 7 years ago by 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.

comment:8 in reply to:  7 Changed 7 years ago by 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

comment:9 Changed 7 years ago by 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.

comment:10 Changed 7 years ago by robe

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

comment:11 Changed 7 years ago by 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?

comment:12 Changed 7 years ago by pramsey

Resolution: fixed
Status: newclosed

OK, committed at r9761

Note: See TracTickets for help on using tickets.