Multipolygons are breaking geojson convertion
See original GitHub issueWhen trying to fetch multipolygons (e.g. 11038555), I get error:
Received corrupt data from Overpass (incomplete polygon).
It seems that happens because outer and inner members are not always closed: they may be just ways.
Are you planning to improve this?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:5 (4 by maintainers)
Top Results From Across the Web
Polygons and MultiPolygons should follow the right-hand rule
I used it for past 3 years without any problem with my old GeoJSON file. Now geojsonlint enforce the right hand rule, how...
Read more >Multipolygons to Polygon - FME Community - Safe Software
You'll need to consider using the Deaggregator transformer to break your polygon groups into unique entities. Though make sure you retain ...
Read more >Issue with converting topology MultiPolygon to geojson #298
I know that topojson when converting from geojson to topology is represent Multypolygon as Polygon with special structure of the array.
Read more >More than you ever wanted to know about GeoJSON
Polygons are where GeoJSON geometries become significantly more complex. They have area, so they have insides & outsides. And not only do they ......
Read more >DbGeography polygon to JSON - Stack Overflow
You can convert an instance of Foo to JSON like: ... int MultiLineStringWkb = 5; /// <summary> /// Well-known-binary multi-polygon value.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I had a quick look at replacing the built-in geojson method with osm2geojson, found that osm2geojson uses 7 decimal points of precision for coordinates, while this library has been using 6 (default from the geojson library) and osm2geojson nests the
id
property of a feature under properties, whereas the built-in method puts it in the top level of the feature.I think the best way to go about supporting GeoJSON properly is not to roll our own but instead support
__geo_interface__
. Sincegeojson
implements this interface too, there’s no need to introduce any other dependencies.