Skip to content
This repository was archived by the owner on Jun 10, 2025. It is now read-only.

Replace homegrown converter with osm2geojson #140

Closed
wants to merge 6 commits into from

Conversation

dericke
Copy link
Contributor

@dericke dericke commented Mar 5, 2021

Replaces the built-in method to convert Overpass JSON to geojson with the osm2geojson library. The motivation is to reduce the scope of this library and offload some maintenance burden.

Important differences:

  • osm2geojson uses 7-digit coordinate precision, same as the Overpass JSON. This lib has been producing 6-digit geojson up until now
  • osm2geojson nests the id attribute under properties, this lib has been putting id as a top-level attribute

Setting as a draft PR until:

Closes #135 and possibly some others?

@mvexel
Copy link
Owner

mvexel commented May 15, 2021

Hey cool! Sorry it took me so long to respond.
Since this would be a breaking change, with the id moving to properties, this would mean a 1.0 release. I would like to shore up tests before we do that, but in general I like not relying on bespoke code when a well-established library is available.

What work do you think needs to be done to the unit tests? Last I checked test coverage is still pretty poor...

@dericke
Copy link
Contributor Author

dericke commented May 17, 2021

Testing is not my greatest strength, but I think #141 would be a good start in improving the tests. I'll try to do some more comprehensive analysis to see what can be improved beyond that.

mvexel added a commit that referenced this pull request May 21, 2021
@mvexel
Copy link
Owner

mvexel commented Nov 18, 2021

@dericke what is left to do before we can merge this? Should there be a 1.x branch since this would be a breaking API change? @russbiggs can you comment on whether this will break #130 ?

@dericke
Copy link
Contributor Author

dericke commented Nov 18, 2021

I was just waiting until the PR related to tests was merged, which I see you've done (thanks!), and for feedback on the API change. I don't feel confident on judging whether the API change is significant enough to warrant a major version increment or not.

@dericke dericke marked this pull request as ready for review November 18, 2021 20:47
@russbiggs
Copy link
Contributor

@mvexel it looks like this would remove all the changes I made in #130 since it removes the whole _as_geojson method. I'm not sure if osm2geojson would do the same as what my PR does.

@dericke
Copy link
Contributor Author

dericke commented Nov 19, 2021

It does appear that this PR currently regresses #130 . I'll look into doing a PR against osm2geojson to fix this.

@dericke
Copy link
Contributor Author

dericke commented Dec 28, 2021

The PR for osm2geojson was accepted, so when using version >= 0.1.30 of that library, #130 is not regressed.

@mvexel
Copy link
Owner

mvexel commented Mar 22, 2022

Hey, see my comment here: #135 (comment)
Do you agree it makes sense to adopt __geo_interface__? /cc @sgillies

@dericke
Copy link
Contributor Author

dericke commented Mar 24, 2022

I like the idea of supporting __geo_interface__, but wouldn't that still require a converter—provided either by this lib or an external dependency—to go from overpass json output to __geo_interface__-compatible output?

@mvexel
Copy link
Owner

mvexel commented Jun 11, 2022

I like the idea of supporting __geo_interface__, but wouldn't that still require a converter—provided either by this lib or an external dependency—to go from overpass json output to __geo_interface__-compatible output?

Yes, it would. But then any library that adopts __geo_interface__ would be able to handle the output.

@t-vi
Copy link

t-vi commented Apr 16, 2023

Just a quick shout: It seems that the example for MapQuery hits a very similar "polygons only as references" problem as #122 (which #129 apparently partially fixed).
So it would seem that there would be more work to do on the geojson conversion unless it is dropped in favour of an external solution (but I don't know what level of activity to expect for that, either).

@JanBeelte
Copy link

I like the idea of supporting __geo_interface__, but wouldn't that still require a converter—provided either by this lib or an external dependency—to go from overpass json output to __geo_interface__-compatible output?

Yes, it would. But then any library that adopts __geo_interface__ would be able to handle the output.

I agree this would probably be the best option, but given nothing is happening on that end wouldnt it be better to merge this one than the status quo?

@tumluliu
Copy link

tumluliu commented Nov 3, 2023

This PR's code can resolve the "corrupted multipolygon" issue from my end. I hope it can be merged soon if no other blockers. Thanks a lot for the nice job @dericke !

@mvexel
Copy link
Owner

mvexel commented Jan 8, 2024

I don't see any other blockers here. I think we're good to finally (sorry..) merge this /cc @metazool

@mvexel
Copy link
Owner

mvexel commented Feb 13, 2024

okay I royally messed up the pr review process and committed everything to main instead. I'm going to close this now for that reason. Everything should be there but I'll double check

@mvexel mvexel closed this Feb 13, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multipolygons are breaking geojson convertion
6 participants