I'm making an API request to OSM with a bounding box query.

When I'm getting an object back that's a multipolygon, I'm unclear how I can differentiate if the relation is inner vs outer. I figured that would be included in the API response, but it's not. What am I missing? Is there some way I'm able to differentiate between the two?

{
          "type" => "Feature",
            "id" => "relation/296087",
    "properties" => {
               "timestamp" => "2018-07-14T19:04:53Z",
                 "version" => "5",
               "changeset" => "60718245",
                    "user" => "escallic",
                     "uid" => "2110789",
               "addr:city" => "Isla Vista",
             "addr:county" => "Santa Barbara",
        "addr:housenumber" => "6585",
           "addr:postcode" => "93117",
             "addr:street" => "El Colegio Road",
                "building" => "apartments",
         "building:levels" => "2",
                    "name" => "Tropicana Gardens",
                    "type" => "multipolygon",
                      "id" => "relation/296087"
    },
      "geometry" => {
               "type" => "Polygon",
        "coordinates" => [ ..... ]
      }

}

Update The query I'm using to make the request is below: http://overpass-api.de/api/map?bbox=-119.86475115542854%2C34.410451138127065%2C-119.85719244457147%2C34.416207261872934

I'm then taking the data (XML) and using the npm package OSMToGeoJSON to convert it into JSON. I believe that is where the relation information is being lost, as I see it in the raw XML.

How would one make a query for all data in a bounding box, but request JSON. I tried adding the query param data=[out:json]; to my response, but I did not get any data back>

I need the inner/outer data for the polygons, because I am re-drawing these maps. I work on a project where were turn these maps into tactile maps for the blind community. If I don't know whether the polygon is supposed to be inner vs outer, it ends up rendering incorrectly.

asked 19 Dec '18, 23:30

kida001's gravatar image

kida001
11113
accept rate: 0%

edited 20 Dec '18, 18:15

I doubt you made your query with Overpass, so that tag is somewhat misleading. When I request the relation with id=296087 with this Overpass Query there is a section with 'members'.

If you cannot use Overpass for some reason, I don't how how to solve the problem though.

(20 Dec '18, 07:23) escada

@escada I'm sending my bbox query to http://overpass-api.de/api/map ... is that not overpass?

(20 Dec '18, 07:28) kida001

@escada - i'm not requesting a specific relation ID, we request data for an entire bounding box. It would be to cumbersome to make a request for every single relation in the result of a bounding box. When I make a bbox query, it does not return the relation data

(20 Dec '18, 07:29) kida001
3

Please explain what you mean by "differentiate if the relation is inner vs outer". In OSM we have relations which can have members and these members can (but are not required to) have inner/outer roles. What exactly is it that you want to do?

(20 Dec '18, 08:49) Frederik Ramm ♦
2

please post the complete OverPass query you make. We need to know which "out" statement you are using and which output format. The sample you posted does not look like the default data type that I get.

It does not matter whether you ask for a particular relation or do another query.

(20 Dec '18, 11:39) escada

@escada @frederik-Ramm I've updated my post with query information requested. Hopefully that helps explain what I'm doing.

(20 Dec '18, 18:12) kida001
showing 5 of 6 show 1 more comments

There is no such thing as an "inner" or "outer" polygon. There are "inner" or "outer" rings of a polygon, and in OSM these rings can consist of one or more ways. The individual members of a multipolygon relation in OSM can have "inner" or "outer" roles hinting at whether they are part of an inner or outer ring, but these roles are neither required nor guaranteed to be there. Therefore, any algorithm that turns OSM data into geometries - like the "OsmToGeoJSON" you claim to be using - needs to apply logic to build correct polygons.

Once a GeoJSON has been built, there's nothing you can or have to do - either the GeoJSON contains the correct polygons (with potential holes in them) or it doesn't. At this point, any inner/outer information is not relevant to you any more, it has been processed into the polygon geometry.

If OsmToGeoJSON does not produce correct polygons for you then this will be fore one of two reasons:

(1) it is implemented sloppily or incompletely (a working algorithm for polygon construction is described in https://wiki.openstreetmap.org/wiki/Relation:multipolygon/Algorithm) or

(2) it cannot build some polygons correctly because the response you get from the "map" request lacks referential integrity, i.e. some relations reference ways that are not contained in the response.

permanent link

answered 20 Dec '18, 21:48

Frederik%20Ramm's gravatar image

Frederik Ramm ♦
69.4k806291086
accept rate: 24%

I re-read my post and don't see where I referred to it as an inner/outer polygon in that way. I was referring to the relation of the polygon, just as OSM describes on their wiki for polygons. Sorry if I didn't get the technicalities of it 100% . We are not 'sloppily' drawing them, we're trying to find the correct way to handle how we use 'fill' on a polygon object.. Thanks for the link.

This feels like the most unfriendly forum I've posted on. Both your post and the comments feel demeaning. If you're going to be salty about giving an answer and use subtle language to demean folks, just don't post.

(20 Dec '18, 22:23) kida001

Frederik, I should not be so decisive. If we read the same multipolygon related OSM Wiki main page there for a member without the inner/outer role we read "Do not use". So, yes, the multipolygon member role is required. Besides, you have a stange understanding/interpretation of the "polygon" notion, hardly in conformity with the mentioned main page. There, in the "Valid MP conditions" we read "We define a valid (closed) polygon as the combination of a subset of member ways which, when their endpoints are joined, form a closed polygon". So, it is a closed polygonal line, sometimes called "ring".

(21 Dec '18, 09:55) sanser

GeoJSON works differently than the OSM data model: It doesn't represent polygons-with-holes as relations with "inner" and "outer" members. In fact, the OSM concept of a "relation" doesn't really exist in GeoJSON.

Instead, the "coordinates" member of a GeoJSON Polygon will simply consist of multiple arrays of coordinates, the first of which represents the outer ring of the polygon, and the remaining of which represent the inner rings. See the relevant section in the GeoJSON spec.

So if OsmToGeoJSON is working correctly, the part that you omitted here

"coordinates" => [ ..... ]

should contain the coordinates of the inner rings and outer ring of your polygon.

permanent link

answered 21 Dec '18, 11:13

Tordanik's gravatar image

Tordanik
10.6k1294131
accept rate: 34%

Wow thank you. Yes I've seen the multiple sets of coordinates/arrays. The first array is consistently the outer ring?

This would be a super helpful assumption to make when drawing polygons, as I was currently going the route of using/writing a function that detects if a polygon is within any of the other polygons we receive, which if it's not needed, would make things much easier.

(22 Dec '18, 17:17) kida001

@kida001: The first array should consistently be the outer ring according to the GeoJSON specification. I haven't checked myself if OsmToGeoJSON does implement this correctly, but I would start from the assumption that it does.

(22 Dec '18, 19:22) Tordanik
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×346
×237
×106

question asked: 19 Dec '18, 23:30

question was seen: 605 times

last updated: 22 Dec '18, 19:22

powered by OSQA