Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

incorrect handling of multipart geometries #19

Closed
springmeyer opened this issue Jul 26, 2013 · 3 comments
Closed

incorrect handling of multipart geometries #19

springmeyer opened this issue Jul 26, 2013 · 3 comments
Milestone

Comments

@springmeyer
Copy link
Contributor

Mapnik encodes each part of a multipart polygon in a separate array. This is to enable styling control over marker placement and labeling: you might wish for a placement per polygon part or a on the largest polygon part.

As far as Mapnik rendering is concerned (AGG renderer) and SVG rendering models in general, geometry parts can be stored and rendered one at a time or in a batch (flattened into one path).

Currently the vector tile encoding represents the flattened path, which was a shortcut taken to simplify the encoding.

So when encoding (creating) a vector tile we loop over all possible geometry parts and then they each get added to the single geometry array of a protobuf feature. (and incidentally the last geometry type wins in the case of a geometry collection meaning that collections are not supported).

This has one limitation: when decoding geometries we cannot easily distinguish the original geometry parts.

Currently this means that we take the flattened geometry as is. In short we assign one geometry to one feature even if the original data included multiple geometries. This means that when later decoded back into mapnik objects and styled you'll only get one marker for multigeoms rather than for each geometry (the default when geometries are stored properly). The default text labeling in mapnik is to only label the largest geometry (relevant for polygons and lines) so this bug will be less noticeable but still likely result in different labeling on a vtile vs the original data (until this is fixed).

One decoding fix is to split each geometry into parts for each move_to encountered. This means that move_tos which originally represented independent geometry parts (true multipolygons) will be handled correctly but move_tos representing inner rings in polygons with holes will be incorrectly split.

@springmeyer
Copy link
Contributor Author

39f907f moves to implementing the one potential fix I see. This has the drawback of now incorrectly splitting single polygons with holes, but this seems like a lesser problem than completely flattening multipolygons.

springmeyer pushed a commit that referenced this issue Feb 15, 2014
@wibrahim
Copy link

wibrahim commented Apr 1, 2015

Was just running some test with GEOMETRYCOLLECTION and vector tiles. My geometry collection contains a Polygon and a Point (the point is the centroid of the polygon so that the label could be placed only at that point). I did set the tile_datasource multi_geometry to true but still when rendering from the vector tile I am only getting the Polygon geometry and not the Point.

Are geometry collections still not supported by vector tile ? Was that fixed in any release or am I doing something wrong ?

@springmeyer
Copy link
Contributor Author

Geometry collections are not supported @wibrahim. I recently fixed this in #94 because it was easy now that upcoming Mapnik 3.x supports strongly typed geometries. But the currently release does not handle them properly (as you see). So I've created #98 just to make that super clear and it will be closed once #94 merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants