drolbr
multipolygon invisible
Hi,
first time I write here. I wrote an issue in OSM's github, they told me it was a pb of overpass. I copy/paste the isssue I have made over there but I edit it to show you the overpass's pb :
I have 2 pbs, one with ID and the other one with OSM (edit : overpass). I open 2 issues, with the same text because my "story" mixes both. I wanted to add a relation to a polygon (in ID) : the relation (multipolygon) is a very big one (scrub) and I'm in the middle, very far from the outer and from any inner. Visible here : https://www.openstreetmap.org/query?lat=-27.70305&lon=-66.00780
- ID's pb : when I select the polygon and go in its relations' part, the scrub is not listed : when zooming out (losing the possibility to edit the polygon), I found the outer line, found the number of the relation. But when I come back to the polygon (zoom in) and put this number in the relation, nothing happens. How to add a relation if the wanted relation is not listed and you can not add its number ?
- edit : overpass's pb ? Before to zoom, I opened a new tab (right click on the title "openstreetmap") to be out of ID but in the area of the polygon (see link above). I use the last button on the right (request on the objets) on the scrub. Result : the request don't see the scrub. The request sees the administrative limits and nothing else. But on the map we see only one (or almost) thing : the scrub. Even if I found how to have the number of the scrub (see point 1), I think it should be better that the request find it directly.
Best regards
This is by design: relation 6058381 doesn’t have a name tag so it doesn’t qualify for an in area lookup. Try querying the border of this scrub instead which works - I just did that on my mobile to determine the relation number above.
Ok, I understand why the query doesn't see the scrub. But a scrub with a name ? Are you sure that "no name = not in a query's answer" is a good rule ?
Best regards
As you can see here https://github.com/drolbr/Overpass-API/blob/master/src/rules/areas.osm3s#L5-L8 all relations with type=multipolygon need to have a name so that an area is created on the server. It doesn't only apply to natural=scrub.
Yes, I had understood that it is what you have in your request.
But if you change your request and delete the "
the result will be so bad ? A pb of time of execution ? A pb of too many answers ?
Best regards
It's too expensive to calculate and not needed by most consumers. Leaving out "name" would increase the number of polygons to be processed from 364355 to 3319957 - and it would probably fail because it needs too much memory.
Yes, in taginfo there are more than 3 000 000 of multipolygons but they are 0.06% of all the objects.
I just create the query on overpass-turbo (rel[type="multipolygon"]({{bbox}});) ; Very long time of execution for a big map but on OSM you allowed only request for small areas. So I have tried at the max zoom you allowed on different types of map : on a city and out of a city. 90% of the time there are no multipolygon in the area and the answer of overpass-turbo is immediate. One time the request has found 8 multipolygons, the execution time was a little more than when nothing but it looks not very bad to me. Of course I don't know how many memory/ressources overpass-turbo needs to execute the requests. Same pb with "area=yes/name" : 1 200 000 area=yes but only 26% have a name. Are you really sure that your server will be crashed with these 2 corrections ?
And you say that "not needed by most consumers" : how do you know what we need ? In your request, you add "railway=station + name" = 89 000 objects you add "railway=turnable" : 2250 ways in taginfo but no answer with a "name" maybe because no result or so few that taginfo doesn't calculte it. you add "railway=roundhouse" : 536 answers and with a "name" no answer of taginfo. Why to add these queries with so few answers that probably "not needed by most consumers" and not a query on more than 3 000 000 objects : probably more needed, don't you think ?
Best regards
The public Overpass instances have limited capacity and depend on funding by FOSSGIS e.V.. It's simply not feasible to calculate areas for that many objects on a wide planet scale. You're very welcomed to set up your own Overpass instance, or sponsor a third Overpass instance to handle the additional load this would cause.
Ok, that' clear now ! You really should changed the title in OSM : "request on some objects" rather than "request on the objects"
Best regards