tommyjcarpenter/osmtogeojson

This is a W-I-P reimplementation of osmtogeojson in pure python.

osmtogeojson's Issues

Release to PyPi

@tommyjcarpenter thx for creating this lib, which comes handy as geojson support of mvexel/overpass-api-python-wrapper is incomplete.

However, to provide a PR, it would be helpful, if osmtogeojson would be released to PyPi.

KeyError when a relation has members

When I try to convert the output of the following query (the outline of Munich) on http://overpass-api.de, I get a KeyError: 195591882.

[out:json];area["de:amtlicher_gemeindeschluessel"~"^09162000"]->.cityarea;
rel(pivot.cityarea);
out geom;

(response as gist)

The conversion seems to fail because the ways are defined as members inside a relation:

{
  "version": 0.6,
  "generator": "Overpass API 0.7.55.7 8b86ff77",
  "osm3s": {
    "timestamp_osm_base": "2019-06-14T09:23:02Z",
    "timestamp_areas_base": "2019-06-14T08:18:02Z",
    "copyright": "The data included in this document is from www.openstreetmap.org. The data is made available under ODbL."
  },
  "elements": [

{
  "type": "relation",
  "id": 62428,
  "bounds": {
    "minlat": 48.0616244,
    "minlon": 11.3607770,
    "maxlat": 48.2481162,
    "maxlon": 11.7229083
  },
  "members": [
    {
      "type": "way",
      "ref": 195591882,
      "role": "outer",
      "geometry": [
         { "lat": 48.0837933, "lon": 11.5614117 },
         { "lat": 48.0839426, "lon": 11.5605688 },
         { "lat": 48.0839875, "lon": 11.5604997 },
         { "lat": 48.0841634, "lon": 11.5605373 },
         { "lat": 48.0849630, "lon": 11.5544544 }
      ]
    },
[...]

The conversion works with the javascript osmtogeojson, which has a function fullGeometryRelation to handle that case: https://github.com/tyrasd/osmtogeojson/blob/0d6190a2c3d23b3ce0ab9b302199834894334727/index.js#L209-L222

Relations with LineString and Polygon members have no geometry

If a relation has Polygons and LineStrings way members, the resulting feature has no geometry.

tyrasd/osmtogeojson instead seems to export every member as feature with an @relations property.

osmtogeojson should either behave accordingly or provide all members geometries as a GeometryCollection.

Example for relation/5576903:

{
      "type": "Feature",
      "properties": {
        "@id": "way/376770457",
        "covered": "yes",
        "highway": "service",
        "indoor": "yes",
        "layer": "-2",
        "location": "underground",
        "oneway": "yes",
        "ref": "Ebene B",
        "service": "parking_aisle",
        "sidewalk": "left",
        "@relations": [
          {
            "role": "",
            "rel": 5576903,
            "reltags": {
              "amenity": "parking",
              "fee": "yes",
              "name": "Schillerplatz",
              "opening_hours": "24/7",
              "operator": "APCOA PARKING Deutschland GmbH",
              "parking": "underground",
              "site": "parking",
              "type": "site",
              "url": "https://service.stuttgart.de/lhs-services/ivlz/index.php?uid=35&objectid=108523&objecttype=dept&page=svc&servicetype=parking&serviceid=9356&detailid=65&showservice=1",
              "website": "https://www.apcoa.de/parken-in/stuttgart/schillerplatz.html"
            }
          }
        ]
      },
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [
              9.178458,
              48.7770338
            ],
           ...
          ]]
      }
    }

Use @id as property name for osm id

npm-osmtogeojson (and hence overpass GeoJSON export, too) prefix osm meta information with an '@' to distinguish them from tags. I'd suggest to change osmtogeojson's output accordingly.

Incorrect winding order

Did not encounter yet any winding order issues, but as this is stated as open problem, perhaps geojson-rewind is helpful in fixing this.