-
-
Notifications
You must be signed in to change notification settings - Fork 474
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
Missing MultiPolygons #866
Comments
Is there any polygon with highway=pedestrian in your polygon table? If not then maybe your Also, are you aware that the relation with id=3923874 will end up in planet_osm_polygon with osm_id=-3923874 (i.e. negative ID)? |
The c-transform drops relations when they don't have a polygon-like tag (which highway isn't) and don't have an area tag. I think that is wrong. |
👍 |
I think the issue happens because some boundary linestrings can not be merged as rings. select string_agg(distinct name, ', ') as name, ST_IsClosed(ST_LineMerge(ST_Union(way))), ST_IsSimple(ST_LineMerge(ST_Union(way))) from planet_osm_line where admin_level='2' and boundary='administrative' and tags->'name:en' = 'Spain' group by osm_id;
name | st_isclosed | st_issimple
--------+-------------+-------------
España | f | t
(1 row) select ST_AsGeoJSON(ST_MakePolygon(ST_LineMerge(ST_Union(way)))) from planet_osm_line where admin_level='2' and boundary='administrative' and tags->'name:en' = 'Spain' group by osm_id;
ERROR: Shell is not a line If you try to ignore unclosed linestring you can see next picture: select ST_AsGeoJSON(ST_LineMerge(ST_Union(way))) from planet_osm_line where admin_level='2' and boundary='administrative' and tags->'name:en' = 'Spain' group by osm_id; select ST_AsGeoJSON(ST_BuildArea(ST_LineMerge(ST_Union(way)))) from planet_osm_line where admin_level='2' and boundary='administrative' and tags->'name:en' = 'Spain' group by osm_id; Does anybody know how to close unclosed linestrings automatically? |
Turns out that this is not trivial to fix with old-style MPs as we run into odd corner cases. I'll fix that as part of #862 instead. |
The tag type=multipolygon already indicates an area, no matter what the other tags say. Fixes osm2pgsql-dev#866.
Hi, it is the same bug? https://help.openstreetmap.org/questions/66116/how-to-configure-osm2pgsql-get-all-relations |
No. The relation mentioned import without issues using latest osm2pgsql and the default style when downloading them directly from the OSM API. |
The tag type=multipolygon already indicates an area, no matter what the other tags say. Fixes osm2pgsql-dev#866.
Thanks. I fixed upgranding osm2pgsql ( |
The tag type=multipolygon already indicates an area, no matter what the other tags say. Fixes osm2pgsql-dev#866.
Hi All
I have posted this question on the OSM forum but the responses were "well it works for me" - so I was wondering if anyone here could shed some light.....
https://forum.openstreetmap.org/viewtopic.php?id=63521
I have loaded a full planet import into Postgres and I am coming across occurrences where some multipolygons are not getting imported into the planet_osm_polygons table. They do however exist in the planet_osm_rels table. I have loaded both with and without the multipolygon switch but still these features do not get imported
This is my import command: (version 0.96 - style sheet is default):
osm2pgsql -v -l --unlogged --create --slim -C 50000 --number-processes 6 --multi-geometry --flat-nodes planet.nodes --extra-attributes -S /usr/local/share/osm2pgsql/default_timestamp_version.style --hstore -d osm_planet -U osm planet-latest.osm.pbf
Below are a few examples of Mutipolygons that don't get added to the planet_osm_polygon table:
https://www.openstreetmap.org/relation/3923874
https://www.openstreetmap.org/relation/5325528
https://www.openstreetmap.org/relation/5325529
Am I missing something?
Thanks,
Mike
The text was updated successfully, but these errors were encountered: