Comments (12)
The pattern of gaps as you zoom and pan look like problems I've had with geometries that become invalid when clipped at tile boundaries. It's not necessarily a pg_tileserv
issue--I've also run into this when making static tiles with tippecanoe
--but if it is the same as I've seen before then the key factor is the cut lines that any tiling process has to make. I don't know if any of these will necessarily fix the problem, but here are things I've done that have helped with issues that look similar:
- First, I'd inspect the geometries as stored with
ST_IsValid()
because one possibility is that they themselves have the kind of minor technical invalidities that vector tile output can cope with until a crop interacts with it. If it does tell you that any are invalid,ST_IsValidReason()
andST_MakeValid()
can help with identifying and/or fixing the issue. - If this is a function layer, it may be worth wrapping geometries with
ST_MakeValid()
. If it's a table layer, it might be worth trying to make a function layer that does this. The reason for that is that doing it at the function stage can applyST_MakeValid()
to the post-crop geometries. - If the geometries are stored as
Polygon
types, it may help to turn them intoMultiPolygon
s. The first gap to appear looks like it would be switching from single polygon to MultiPolygon, which I've sometimes had cause problems. - Putting the geometries through
ST_Buffer()
with a buffer radius of zero is sometimes surprisingly effective at fixing geometries. If that doesn't help. then the same with a tiny positive buffer radius sometimes does, though depending on the application this option may not be worth it because of the changes it makes to the data. - Sometimes putting complicated geometries through
ST_Subdivide()
solves a lot of problems, as well as making spatial indexes more effective. The catch here is that you need to be able to merge them back together in the display layer. - Simplifying the polygons may help, though depending on the application that may again not be worth it because of the loss of fidelity.
from pg_tileserv.
That's very curious... what does that load do that causes render to fail sometimes?
from pg_tileserv.
The zip file contains the two versions of the polygon seen in video above
polygon-in-video.zip
created via
ogr2ogr -nln au_lga_01_2018_multipoly -f "PGDump" au_lga_01_2018_multipoly.sql lga_2018_aust.gpkg
ogr2ogr -nlt POLYGON -nln au_lga_01_2018_poly -f "PGDump" au_lga_01_2018_poly.sql lga_2018_aust.gpkg
➜ ogr2ogr --version
GDAL 3.7.2, released 2023/09/05
Original as geojson https://gist.github.com/sabman/d008a15d83d88eb1bed3a5853bbcd61f
from pg_tileserv.
I wonder how much of this advice we should wrap into the system. We cannot easily do valid/makevalid without bogging down in CPU overhead. We could automatically fluff polygons up into multis without too much cost.
from pg_tileserv.
For this particular case, yeah, the last time I saw this was when MVT output was still pretty new and we generated invalid outputs during tile clipping. The reason we use wagyu for clipping (still) is because it more reliably produces valid output. However, if you feed it invalid input then bets are off.
from pg_tileserv.
I'm not sure if I have this wrong last time I tried loading multiploygons tileserver didn't see them but that may have been unrelated... so I used the following to load the data. Which as @eldang suggests might have made the geometries invalid.
ogr2ogr -nlt POLYGON -f "PostgreSQL" PG:"host=mygost user=postgres password=pass dbname=postgres port=6443" lga_2018_aust.gpkg
I'm gonna try some of the suggestions
from pg_tileserv.
Yea loading as multipolygons seems to have resolved this issue. basically loading using same command without the -nlt POLYGON
does the trick!
from pg_tileserv.
I think what's going on in cases that are resolved by storing the source geometries as Multi* is that the the crop would turn a single polygon into two, and isn't done in a way that allows breaking them into two rows. I could see a universal cast-to-Multi being worth it for these, if the cost really is low enough. Would it be difficult to make that behaviour conditional on what the actual source geometry type is? Or is a redundant cast to ST_Multi()
so low cost that I'm now overthinking things and it's worth just applying it to everything?
from pg_tileserv.
If the problem is "clip turns poly into multipoly" surely we would have seen this in a lot more cases. It also means that there might actually be a bug hiding somewhere wanting to be fixed. If we could have the offending polygon and reproduce the behaviour, perhaps we'd find something (not in tileserv, but in PostGIS). Does the behaviour reproduce in the tileserv web UI, given the right input data? Step one is deriving a reproduceable case.
from pg_tileserv.
I think it's specifically that a clip can make a multipolygon out of a polygon when the shape has two arms that are connected on one side of the cut line and disconnected on the other. I've mostly run into this with blatantly gerrymandered electoral districts.... I can probably cook up a test case next week with Texas data, but it might be more useful to start with the specific file that opened this issue. @sabman is it something publicly available, and if so could you share a link?
from pg_tileserv.
Yea I can create SQL dumps for both cases. One with polygon and the other with multipolygon. Would that be enough to start with?
from pg_tileserv.
If you can dump the one offending polygon, in the form (poly or multi) that is causing the problem, that would cut down the amount of hunting we have to do.
from pg_tileserv.
Related Issues (20)
- Sampling of points at lower zoom. HOT 2
- Opt out index/preview pages and/or json metadataendpoints HOT 5
- why cant i query tiles ? HOT 1
- superfluous response.WriteHeader call HOT 1
- Please bump golang.org/x/sys dependency
- Expand jsonb properties in tilejson HOT 1
- pg partionned tables HOT 3
- --version returns latest instead of version number
- Point is not shown when zoom > 1 and longitude is = -90 HOT 1
- How to get labels along with geometries in protobuf tiles rendered using Leaflet.vectorGrid? HOT 1
- Get only the last result in a temporal filter HOT 5
- Proxy configuration at sub-route HOT 2
- docker pg_tileserv:20231121 `GLIBC_2.34' not found HOT 9
- Mapbox Vector Tiles (MVT) data Not visible for point layer at lower zoom levels . HOT 1
- config - web site basemap URL
- helm chart? HOT 5
- support fully qualified column names in properties and filter query parameters
- Request: H3 Function Example HOT 1
- How to reload layers with `--no-preview` flag HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pg_tileserv.