You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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_datasourcemulti_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 ?
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.
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 thatmove_to
s which originally represented independent geometry parts (true multipolygons) will be handled correctly butmove_to
s representing inner rings in polygons with holes will be incorrectly split.The text was updated successfully, but these errors were encountered: