#1037 closed defect (fixed)
geography: ST_Intersects, ST_DWithin gbox_overlaps: geometries have mismatched dimensionality
| Reported by: | robe | Owned by: | pramsey |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 1.5.4 |
| Component: | postgis | Version: | 1.5.X |
| Keywords: | Cc: |
Description (last modified by )
Paul,
Can you take a look at the attached query and let me know if it errors out for you. I'm getting a lot of these errors with my California geometries when experimenting with geography. This query gives a: ERROR: gbox_overlaps: geometries have mismatched dimensionality error.
This fails on 1.5.2, 1.5.3 rc1, and 2.0.0 trunk.
This particular polygon has 380 points (smallish in myset). I've tried with smaller polygons and don't have the issue so not sure if its a number of points issue or not. I've got some polygons with over 20,000 points also failing. This is on a Windows 2008 R2 (64-bit running 32-bit PostgreSQL/PostGIS in case that matters).
Attachments (1)
Change History (7)
by , 13 years ago
| Attachment: | geog_intersects_dwithin_failure.sql added |
|---|
comment:1 by , 13 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 13 years ago
The geometries actually do have mismatched dimensionality… the first is a POLYGONZ and the second is a POINT. The question is what the right thing to do is and whether I can pass over this error without breaking other things.
comment:5 by , 13 years ago
hmm since we haven't released 1.5.3 yet — you want to push this to 1.5.3 too. It's okay to say no.
comment:6 by , 13 years ago
hmm they have zs in them? — how could I have missed that. I must have been looking at the ST_AsText. I guess Nicklas is right — you get z data in places you weren't planning.
This could be related to bug #261 that you fixed.
You did say their might be other cases like this lurking in the code. FWIW:
ST_Distance, ST_DWithin, ST_Intersects calls for these 2 geometries also gives the
ERROR: gbox_overlaps: geometries have mismatched dimensionality