#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 by , 11 years ago
comment:2 by , 11 years ago
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 by , 11 years ago
Milestone: | PostGIS 2.1.2 → PostGIS 2.2.0 |
---|
"not a big deal" is all I need to push this.
comment:4 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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
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.