Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#2587 closed defect (fixed)

CompoundCurve with empties parses differently from WKB and WKT

Reported by: mloskot Owned by: pramsey
Priority: medium Milestone: PostGIS 2.2.0
Component: postgis Version: 2.1.x
Keywords: wkt, wkb Cc:

Description

Related to WKT/WKB/GeoJSON output always valid input thread, this might seem like a fabricated example, so I'm not sure if could be considered as a bug. Here it is:

PostGIS successfully parses this WKB

010900000002000000010200000000000000010800000000000000

which is equivalent to this WKT

COMPOUNDCURVE(EMPTY,CIRCULARSTRING EMPTY)
COMPOUNDCURVE(LINESTRING EMPTY,CIRCULARSTRING EMPTY)

But fails, what is expected, to parse that WKT throwing:

ERROR:  incontinuous compound curve

In fact, all combinations of multiple empty components are rejected:

COMPOUNDCURVE (EMPTY, CIRCULARSTRING EMPTY)
COMPOUNDCURVE (LINESTRING EMPTY, CIRCULARSTRING EMPTY)
COMPOUNDCURVE (CIRCULARSTRING EMPTY, CIRCULARSTRING EMPTY)

Interestingly, mixing empty with non-empty:

COMPOUNDCURVE(EMPTY, CIRCULARSTRING(1 5,6 2,7 3))
COMPOUNDCURVE(LINESTRING EMPTY, CIRCULARSTRING(1 5,6 2,7 3))
COMPOUNDCURVE(CIRCULARSTRING EMPTY, CIRCULARSTRING(1 5,6 2,7 3))

results in different kind of error:

ERROR:  getPoint4d_p: point offset out of range

Shouldn't the last error be:

ERROR:  incontinuous compound curve

Change History (5)

comment:1 Changed 6 years ago by pramsey

We've always had different rules for WKB and WKT inputs (try, for example, an unclosed WKB polygon and WKT polygon, one gets int the other does not). So this is not really a huge deal, IMO (except insofar as our general policy is a bit of a huge deal, but we've lived with it for a long long time).

I'd like to examine the last case, if only to try and catch it more cleanly that it looks like it's being caught.

comment:2 Changed 6 years ago by mloskot

Paul,

Thanks for the feedback, yet another brick to my understanding of PostGIS. Certainly, I agree with you, not a big deal and as I mentioned, it is a case from very far corner, I wasn't sure though, hence the ticket.

I admit that recently I've been stress-testing PostGIS vs my interpretation of OGC+SQL/MM.

comment:3 Changed 6 years ago by robe

Milestone: PostGIS 2.1.2PostGIS 2.2.0

"not a big deal" is all I need to push this.

comment:4 Changed 5 years ago by pramsey

Resolution: fixed
Status: newclosed

Changed the code to catch the last error a little more validly and safely than the hail-mary "you almost walked off the end of the point array" catch. r13452

comment:5 Changed 5 years ago by mloskot

The fix looks good to me, thanks Paul.

Note: See TracTickets for help on using tickets.