Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1099 from ahuarte47/Issue_8725R-ST_simplify
Fix bug #8725R: fix collapsed geometries by ST_simplify function of postgis
- Loading branch information
Showing
9 changed files
with
72 additions
and
32 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When activating "simplify on provider side if possible" on PostGIS layer I get an image output that is not drawing a few pixels. This is because this patch uses ST_Simplify which will drop vertices that are important for a for a complete image. Why not use ST_SnapToGrid instead?
See result with ST_Simplify (see missing white pixels in parcel network):
vs: ST_SnapToGrid:
Data can be downloaded from http://data.linz.govt.nz/layer/772-nz-primary-parcels/
Note: I'm using simplification threshold of 1.00 pixel. Also I don't see any render issues when using not using provider side simplification.
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say the current behavior is correct - st_snaptogrid won't help with speeding up the rendering as the original number of vertices will still be returned from postgis. St_simplify results in a speedup because it removes unnecessary vertices from the geometry.
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the right parameter is passed map to pixel value is passed to ST_SnapToGrid I would have thought the number of vertices would be reduced as it removes consecutive points falling on the same cell.
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@palmerj interesting -- I didn't realise st_snaptogrid behaved this way. I still think st_simplify is a better method because it reduces vertices on segments which would appear straight at a given scale (eg, imagine a complex wiggly boundary which can be reduced to a two point line when zoomed out far enough. In this case using st_snaptogrid to snap points to pixels will still result in many vertices along this segment).
That said, @ahuarte47 I've just encountered this same issue myself. It seems to happen on polygon layers when a whole feature is reduced to less than the size of a single pixel (using a postgis layer with provider simplification enabled).
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @palmerj, I would test the "NZ Primary Parcels" layer, what CRS should I download?
May be EPSG:4167 ?
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ahuarte47 Yes EPSG:4167 is best.
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jef-n Are you suggesting st_snaptogrid is the way to go? Because your test case is reduced to just two vertices with st_simplify.
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just verified that st_snaptogrid also reduces the number of vertices. I didn't check what either function does - perhaps even combining both could make sense.
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @palmerj, I have tested your data in postgis (PostgreSQL 9.2) and I have not white pixels :-(
You are right, I use ST_simplify, but to avoid geometries collapsed I use a trick, when them are collapsed I use the BBOX of the original geometry ( 8b53001#diff-85b8cc237feeed878a569af636cd9d88R373 )
About white pixels, what can I do?
Best Regards
Alvaro
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm interesting. Did you tick the box for "simplify on provider side if possible"? Using latest Ubuntu dev build from last night I still get the white pixels.
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also getting the problem with qgis master on win32.
Note I'm running PG 9.1 and PostGIS 2
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @palmerj, then I must install PostgreSQL 9.1 + PostGIS 2
Best regards
8b53001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @palmerj, I have tested your layers in (PostgreSQL 9.1.11 + Postgis 2.0.3) and (PostgreSQL 9.3.02 + Postgis 2.1.1) in Windows XP SP3 32bits and It works fine, but using Postgis 2.1.1 I found this error on two of my layers :-)
I have done many tests and ST_Simplify not seem reliable (Sometimes it returns NULL, sometimes returns EMPTY):
http://lists.osgeo.org/pipermail/postgis-devel/2012-December/023152.html
http://trac.osgeo.org/postgis/ticket/1987
Using SnapToGrid it works fine!
Can you test this pull ( #1131 ) please ?
SnapToGrid may return more vertices, but the result is safer:
http://blog.cartodb.com/post/20163722809/speeding-up-tiles-rendering
Alvaro