Support relation on geojson

[humitos]

I found that relation type are being skipped. Is it intentional? Why? https://github.com/mvexel/overpass-api-python-wrapper/blob/master/overpass/api.py#L126

Is it possible to add support for them?

Thanks!

[colinmccormick]

I would also like to know the answer to this - hopefully it's not intentional.

[mmd-osm]

Another report of missing relation support: http://gis.stackexchange.com/questions/217278/what-is-the-right-code-for-getting-geojson-data-of-relations-by-overpass-in-pyth

[t-g-williams]

For those who may still be having problems with this, I have addressed this issue and created a pull request on github. See following link: #76

[TimHarder]

Thanks t-g-williams .. saved me a lot of headaches today. Thanks for the implementation of relations.!

On that note .. would also second the need for native support of relations.

[t-g-williams]

@TimHarder I just added a further commit that I hadn't gotten around to pushing ("added support for multipolygons"), it's been sitting on my computer for a while.
The previous commit that I made didn't account for multipolygons (i.e. more complex polygons that may have "inner" areas removed from them - see http://wiki.openstreetmap.org/wiki/Relation:multipolygon). This addresses that.
It seems to be failing some test though when I upload it to github, but the code runs on my computer.
Hope that helps

[mvexel]

@t-g-williams and others, I would love to add relation support and am considering this PR.

I think we can go ahead and add it if we can work on getting some test coverage. The code is a little hard to parse, but I think we can work on cleaning it up some after we merge and release.

Who can work on the test coverage?

[mvexel]

I do want to tackle this but not sure how yet. Looking at using pyosmium or perhaps interfacing with Shapely (which could potentially simplify other aspects as well -- reducing the code needed to support output formats but instead relegating that to Shapely.

Pinging a few experts! @lonvia @pnorman @iandees @tbolender

I am still more than happy to work on the current PR as well, but it has gotten stale and it would need to be manually merged. The reason I didn't merge it at the time was mainly that the code was just really hard to read. Also I would love some unit tests for it. (Test coverage is abysmal anyway so I am not setting a great example..)

Thanks all!

[pnorman]

I haven't researched this issue in detail, so I'm not up on exactly what's wanted.

pyosmium is a great option if you want to convert OSM data into WKB, or some other OCG geometry. That doesn't seem to be what this library is doing. Software using the result from this library may want to do stuff like turn ways into geometries, create area objects, etc.

[hbruch]

Perhaps it would be an option to integrate @tommyjcarpenter’s osmtogeojson? While still in an early stage, it has some relation support. And of course, some more test coverage would be required as well....

[tommyjcarpenter]

@hbruch As an aside, I am sitting on a lot of code that makes complex overpass queries in Python. Do you think that would be useful?Essentially I decomposed some complex overpass queries (like get me all X within Y meters of a Z) into python functions.

I've kicked off the process with my employer to open source all of the work. This could be slow moving though, but if this is of high interest maybe I can try to expedite things.