Bug report #4767
PostGIS 2.0 ST_AsBinary drops forcing 2d, breaks WKB parser of QGIS
Status: | Closed | ||
---|---|---|---|
Priority: | High | ||
Assignee: | Tim Sutton | ||
Category: | Data Provider/PostGIS | ||
Affected QGIS version: | 1.7.3 | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | fixed |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 14630 |
Description
Up to PostGIS-1.5 ST_AsBinary used to internally force the geometry dimensionality to 2d, due to lack of standard specifications for higher dimensions. As of PostGIS-2.0 the new SQL/MM higher dimension specifications are used. Qgis is unable to parse such WKB and complains as follows:
Debug: /usr/src/qgis/qgis-1.7/src/core/qgsgeometry.cpp: 3701: (boundingBox) Unknown WkbType ENCOUNTERED
Mapserver contains an explicit Force2D call since a long time. Qgis could do the same for a quick fix.
Associated revisions
Simplify code handling geography and support postgis-2.0 WKB (sqlmm; fixes #4767)
History
#1 Updated by Sandro Santilli almost 13 years ago
- Affected QGIS version changed from master to 1.7.3
Here's a fix for the 1.7 branch, which also improve the support for geography (fixing opening a geography table with no type advertised in geometry_columns). Note: this was tested against PostGIS 1.4, 1.5 and 2.0svn, opening geometry and geography columns with 4 dimensions.
The following changes since commit 7a9110ab8de73475313f44ebeae76aaa31bf4c43: Alexander Bruy (1): always save last used dir in Raster terrain analysis plugin (fix #4693) are available in the git repository at: [email protected]:strk/Quantum-GIS.git release-1_7-pgis-2_0 Sandro Santilli (1): Simplify code handling geography and support postgis-2.0 WKB (sqlmm) src/providers/postgres/qgspostgresprovider.cpp | 34 +++++++++++------------ 1 files changed, 16 insertions(+), 18 deletions(-)
#2 Updated by Sandro Santilli almost 13 years ago
- Category set to Data Provider/PostGIS
I'll postpone port of the fix to master as master is currently undergoing a refactoring
#3 Updated by Sandro Santilli almost 13 years ago
2b739d945d90d31b11561f0ca3938706b4162ebf by jef adapted the patch to master branch.
Does it need to be also backported in a 1.8 branch ?
#4 Updated by Sandro Santilli almost 13 years ago
- % Done changed from 0 to 100
- Status changed from Open to Closed
Fixed in changeset 8d65c9728065d5b34b4e8c0418ad7767ea6f514e.
#5 Updated by Sandro Santilli almost 13 years ago
The commit references don't make it obvious which branch contains the commit :(
I've no time to file a bug for that against hub...
Anyway, I'm assuming 8d65c9728065d5b34b4e8c0418ad7767ea6f514e is in 1.7.
Do we need to port in 1.8 as well ?
#6 Updated by Sandro Santilli almost 13 years ago
- Status changed from Closed to Reopened
Done in 1.7 branch and master (2.0).
Still needs to be taken care of in 1.8 branch.
#7 Updated by Jürgen Fischer almost 13 years ago
Sandro Santilli wrote:
Fixed in changeset 8d65c9728065d5b34b4e8c0418ad7767ea6f514e.
FTR I changed the commit message to contain "fixes #4767".
#8 Updated by Sandro Santilli almost 13 years ago
- Assignee set to Tim Sutton
@jef: great, thanks !
@tim: I've been told you're the one taking care of backports to 1.8 :)
#9 Updated by Giuseppe Sucameli over 12 years ago
- Resolution set to fixed
- Status changed from Reopened to Closed
The fix seems already present in branch 1.8.