Opened 6 years ago
Closed 6 years ago
#4293 closed defect (duplicate)
Polygon fill-extrusion issue in mapbox with ST_AsMVT created tiles
Reported by: | joedjc | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.5.2 |
Component: | postgis | Version: | 2.4.x |
Keywords: | Cc: |
Description
I am having some issues displaying ST_AsMVT created tiles in Mapbox.
This applies specifically to fill-extrusions (e.g. 3D buildings) in Mapbox. When rendering these tiles to foreground extrusions are missing.
I believe this to be a PostGIS issue because generating tiles from the same data in Mapnik renders correctly.
I've attached an image of a Polygon with fill-extrusion created from a PostGIS tile and a Mapnik tile from the same data source.
Could it be the case that the Polygon is created in a format which does not render correctly in Mapbox?
Attachments (3)
Change History (12)
by , 6 years ago
Attachment: | Screenshot 2019-01-11 at 10.14.49.png added |
---|
comment:1 by , 6 years ago
MVT version 2 (and version 3 isn't out yet) doesn't support 3d natively.
Can you explain what are you trying to do exactly? What is the input, the current output and the expected output?
comment:2 by , 6 years ago
This looks like reversed order of vertices. What is your PostGIS version? (select postgis_full_version() Can you share the dataset?
comment:3 by , 6 years ago
@Algunenano - I am displaying Polygon features using an extrusion style in Mapbox (really 2.5d rather than full 3D). It would typically be used to extrude buildings but it uses standard Polygons (see mapbox example: https://www.mapbox.com/mapbox-gl-js/example/3d-buildings/)
@ komzpa - I am using PostGIS 2.4.4 ("POSTGIS="2.4.4 r16526" PGSQL="100" GEOS="3.5.1-CAPI-1.9.1 r4246" SFCGAL="1.3.0" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 2.1.2, released 2016/10/24" LIBXML="2.9.4" LIBJSON="0.12.1" LIBPROTOBUF="1.2.1" TOPOLOGY RASTER").
Here is the dataset for the Polygon used in the example:
POLYGON((55.1659679979817 24.9837262257836,55.1678036156365 24.9841294406773,55.1681636731593 24.98353980785,55.1674536009453 24.9826248241092,55.166349678866 24.9828068916502,55.1659679979817 24.9837262257836))
GeoJSON:
{"type":"Polygon","coordinates":[[[55.1659679979817,24.9837262257836],[55.1678036156365,24.9841294406773],[55.1681636731593,24.98353980785],[55.1674536009453,24.9826248241092],[55.166349678866,24.9828068916502],[55.1659679979817,24.9837262257836]]]}
That Polygon isn't following the 'right hand rule', but I tried with one which does with the same results:
{"type":"Polygon","coordinates":[[[55.1675895300076,24.9860683065305],[55.1657664584022,24.9855976928018],[55.1659753590738,24.9845247978325],[55.1681225482439,24.9849268449059],[55.1675895300076,24.9860683065305]]]}
comment:4 by , 6 years ago
Here is the dataset for the Polygon used in the example:
Can you share the whole query (with a polygon example) so we can check if the output is valid?
What library are you using for the visualization? It's just a wild speculation, but if it isn't a Postgis issue it could be that it adds extra requirements on top of the MVT spec.
comment:5 by , 6 years ago
@ Algunenano -
Here is an example using a datasource i've created:
SELECT (ST_AsMVT(q, '303', 4096, 'geom')) as data FROM ( SELECT ST_AsMVTGeom( ST_MakeValid(ST_Transform(ST_GeomFromText('POLYGON((2.35044440995268 48.8547079153776,2.34939134536916 48.8548089953983,2.34865467128913 48.8544487872917,2.34849994773995 48.8531318335876,2.35117736888415 48.8532126364981,2.35044440995268 48.8547079153776))',4326),3857)), ST_MakeBox2D(ST_Point(260497.392395924, 6250714.42504853), ST_Point(261720.384848486, 6249491.43259597)), 4096, 256, true ) geom ) as q
This is the result:
\032$\012\003303\022\030\030\003"\024\011\252<\316\030"\217\006s\245\004\232\003s\324\013\314\017[\017(\200 x\002
The visualisation library is mapbox. I've attached a screenshot showing this exact layer/tile being rendered with fill-extrusion. I get the same result from all types of Polygons.
It's just a wild speculation, but if it isn't a Postgis issue it could be that it adds extra requirements on top of the MVT spec. - maybe but as far as I know mapbox is just extruding a standard Polygon, and also Mapbox create the MVT spec I think so i'd imagine they stick to it but I could be wrong. It's an odd issue though but only affects tiles I create with PostGIS.
by , 6 years ago
Attachment: | Screenshot 2019-01-11 at 15.39.33.png added |
---|
Example screenshot from query
comment:6 by , 6 years ago
Here is also a live example rendering a single tile in mapbox:
https://s3-eu-west-1.amazonaws.com/www.iventis.co.uk/test.html
comment:7 by , 6 years ago
The visualisation library is mapbox.
Mapbox, as a company, you appear to be using Mapbox GL JS (https://github.com/mapbox/mapbox-gl-js/).
If I run your query I get this:
\x1a250a0333303312191803221509aa3cce1822a2049e0dcb0f5c74d30ba60499030f2880207802
Just the polygon:
POLYGON((3861 1575,4134 2422,3136 2468,3194 1722,3469 1517,3861 1575))
I've used that output to pass it to node-mapnik and decoded it as:
[ { "name": "303", "extent": 4096, "version": 2, "features": [ { "type": 3, "properties": {}, "geometry": [ 9, 7722, 3150, 34, 546, 1694, 1995, 92, 116, 1491, 550, 409, 15 ] } ] } ]
node-mapnik also confirms that the MVT is valid.
I've tried downloading https://s3-eu-west-1.amazonaws.com/www.iventis.co.uk/assets/15/16597/11273.pbf and checking the tile with node-mapnik and, unless I'm missing something, that tile respects the MVT spec.
I suggest you to open an issue to Mapbox GL detailing your problem and providing a copy of the MVT file generated by Postgis (11273.pbf); even better if you provide both the one generated by Postgis and the one generated using Mapnik.
comment:8 by , 6 years ago
@Alguneano - ok thanks for looking into it. I have posted an issue with mapbox https://github.com/mapbox/mapbox-gl-js/issues/7767 so hopefully they will take a look.
Here is the same tile created by Mapnik in the example - which is working correctly:
https://s3-eu-west-1.amazonaws.com/www.iventis.co.uk/test_mapnik.html
comment:9 by , 6 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
This was an issue with the winding order, fixed in 2.4.5
Example screenshot