2
2
Fork
You've already forked overpass-api-python-wrapper
2

Replace homegrown converter with osm2geojson #140

Closed
dericke wants to merge 6 commits from use_osm2geojson into main
pull from: use_osm2geojson
merge into: mvexel:main
mvexel:main
mvexel:tutorial/d1-httpx-nvim
mvexel:0.8.x
mvexel:dev-contributor-tooling
mvexel:1.0-dev
mvexel:dev
mvexel:feature/api-modernization
mvexel:maintenance/base-0.8
mvexel:maintenance/geojson-fixtures
mvexel:archive/async-models
mvexel:maintenance/endpoint-guard
mvexel:maintenance/live-query-tool
mvexel:maintenance/modernize-plan
mvexel:archive/dev-prebaseline-20260502
mvexel:archive/modernize
mvexel:archive/chore-tests
mvexel:chore/poetry
mvexel:archive/readme
dericke commented 2021年03月05日 20:11:25 +01:00 (Migrated from github.com)
Copy link

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:

  • it is decided either that these differences are acceptable, or either osm2geojson or this PR is modified to produce identical output
  • it is confirmed that this will not regress recent PRs such as #130

Closes #135 and possibly some others?

Replaces the built-in method to convert Overpass JSON to geojson with the [osm2geojson](https://pypi.org/project/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: - [ ] it is decided either that these differences are acceptable, or either osm2geojson or this PR is modified to produce identical output - [x] it is confirmed that this will not regress recent PRs such as #130 Closes #135 and possibly some others?

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...

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 commented 2021年05月17日 19:41:51 +02:00 (Migrated from github.com)
Copy link

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.

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.

@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 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 commented 2021年11月18日 21:46:58 +01:00 (Migrated from github.com)
Copy link

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.

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.
russbiggs commented 2021年11月19日 02:02:29 +01:00 (Migrated from github.com)
Copy link

@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.

@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 commented 2021年11月20日 00:57:25 +01:00 (Migrated from github.com)
Copy link

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

It does appear that this PR currently regresses #130 . I'll look into doing a PR against osm2geojson to fix this.
dericke commented 2021年12月28日 21:24:21 +01:00 (Migrated from github.com)
Copy link

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

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

Hey, see my comment here: https://github.com/mvexel/overpass-api-python-wrapper/issues/135#issuecomment-1075451525
Do you agree it makes sense to adopt __geo_interface__? /cc @sgillies

Hey, see my comment here: https://github.com/mvexel/overpass-api-python-wrapper/issues/135#issuecomment-1075451525 Do you agree it makes sense to adopt `__geo_interface__`? /cc @sgillies
dericke commented 2022年03月24日 23:11:17 +01:00 (Migrated from github.com)
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?

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?

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 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 commented 2023年04月16日 13:57:04 +02:00 (Migrated from github.com)
Copy link

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).

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 commented 2023年11月03日 17:36:18 +01:00 (Migrated from github.com)
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?

> > 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 commented 2023年11月03日 19:46:47 +01:00 (Migrated from github.com)
Copy link

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 !

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 !

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

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

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

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

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
mvexel/overpass-api-python-wrapper!140
Reference in a new issue
mvexel/overpass-api-python-wrapper
No description provided.
Delete branch "use_osm2geojson"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?