Hi, referring to the site at https://www.openstreetmap.org/#map=16/46.6548/11.1634 In the center is an industrial zone, which imho is a well defined multipolygon. Also the area is colored to be an industrial zone - so I would think there is no mistake with the area as such. However, when using the object query tool on the buildings standing on the industrial zone, the latter will not show in the surrounding objects. When querying close the border of the industrial zone, the multipolygon surrounding it will show in the nearby objects. I did not find differences to other industrial zones nearby, where query works fine. - the ways making up the multipolygon exist and their endpoints are connected and form a ring (one of the ways is defined counterclockwise, the other 3 clockwise, though. - The industrial zone does not have a name (most others in the region do, so this might be an issue) - some other areas defined by the same user also have the same problem (e.g. the orchard right next to the industrial zone. I really think there is nothing wrong with the definitions - so maybe somehow a failed changeset? - The relation does have the <tag k="landuse" v="industrial"/> ande <tag k="type" v="multipolygon"/> Note that the issue propagates when exporting the data via osm2pgsql; the buildings will not show to be part of the industrial zone. So do these multipolygon require a name to show in the surrounding objects or can someone find another issue? Thank you, Andi asked 17 Oct '17, 20:59 achrist1 |
You can open dev console and check the networking tab, there are three querries: https://www.openstreetmap.org/query?lat=46.65684&lon=11.16265&xhr=1 this one seems to generate the template foe the answer translated onto the right language. Next two are actual data requests made to Overpass API The closest objects
and surrounding objects:
Here is the description for Overpass QL is_in statement http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Query_for_areas_.28is_in.29 The important part: Area creation depends on some specific extraction rules, there's no area counterpart for each and very OSM way or relation! And here are some details of how the areas for Overpass API are produced http://wiki.openstreetmap.org/wiki/Overpass_API/Areas In the nut shell, it should be named multypoligon/administartive boundary or postal_code area. answered 18 Oct '17, 03:31 dkiselev Thanks, but oh boy, this does nowhere show up in the wiki, e.g. https://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon has even wrong examples, which suggest that the multipolygon tag alone is sufficient to create an area...(or, as always possible, I again prove that I cannot read properly) Have you got any idea why the name would be so important to define an area? I mean, I would not be so sure that all industrial zone (all being areas) even have a name. On the other hand I would not think that it is out of the question that a multipolygon road could have a name. So for distinction purposes the name is not so strong. Do you know where I could suggest this to be thought over? Thanks, Andreas
(18 Oct '17, 20:32)
achrist1
It's enough to create multypoligon to create an area in OSM terms, but Overpass is actually is separate project it's closely related to OSM but Overpass treats areas little bit different. So it's enough to create multypoligon from OSM perspective but it wouldn't be imported to Overpass database. I know that it's sounds confusing but OSM is more like a collaboration of different projects instead of one solid project.
(18 Oct '17, 20:52)
dkiselev
|
Could the problem be that (as you observed) one of the ways is counterclockwise and the other three are clockwise? I realise that the wiki states direction of ways shouldn't matter, but perhaps the renderer's implementation does assume that the endpoint of way N is the startpoint of way N+1.
Hi, I think dkiselev's answer is actually spot on. Thanks for your suggestion, though