Querying landuse metainformation for a lat-lng

[krnlde]

I'm trying to always receive the ground information (landuse, leisure, amenity, natural, ...) of a given coordinate.

[out:json];
way(around:50.0, {{center}})->.a;
(
  way.a[amenity];
  way.a[natural];
  way.a[landuse];
  way.a[leisure];
);
out;
is_in({{center}})->.a;
(
  area.a[landuse];
  area.a[leisure];
  area.a[amenity];
  area.a[natural];
);
out;

What I was trying to do was to find the enclosing element for a coordinate that has at least one of the tags.

Why is there some areas that won't return a landuse information (e.g. most forests) but can be printed in whatever color and pattern it is by the tile drawer server? How do I always get these metainformation?

[mmd-osm]

This seems to be the same issue as discussed in #77

[krnlde]

Yes it's the same issue. I didn't see that, sorry. Besides that, my question is more concrete in relation to finding information about areas. I found out that, for some areas you don't receive information by is_in but by around. Please mind these two examples:
http://overpass-turbo.eu/s/30X
and
http://overpass-turbo.eu/s/30Z

The first one matches landuse: farmland because the border of this area intersects the around radius, where the second query doesn't return the landuse of the same area... How come that around returns a result for an area, but is_in doesn't?

[mmd-osm]

around really has no concept of an "area", it currently works on non-area objects like nodes and ways only. If you compare different outputs you'll notice that only is_in returns an area while around returns ways (or points).
Areas are a special data type created by a dedicated preprocessing step - see http://wiki.openstreetmap.org/wiki/Overpass_API/Areas for details about the proprocessing rules. The reason why you don't get a result for is_in is related to the issue in ticket #77, i.e. there's no name tag on your landuse=farmland. If your landuse doesn't match any of those rules, preprocessing will simply not create any area, hence is_in will not find a result. The rules for transforming ways into an area will probably change in the future (see that other ticket for details).
around otoh doesn't require that preprocessing step. If your way or node is within a certain radius and matches your filter criteria you will get it as a result, independent of any area object.

[krnlde]

Thank you very much for this clarification :) That helped a lot. So I quote from that, there's currently no solution to extract the landuse/amenity/surface/nature information from every spot inside a way.

I'll stick with my solution where I combine the results from is_in and around for now.

[mmd-osm]

Right, the area based is_instatement won't provide that information unless the rules explicitly allowed the creation of an area in the first place.

BTW: your combined is_in / around approach is not guaranteed to work in any case. Assuming all lines making up the landuse are completely outside of your 50m radius, you will not get any result, even if your center point is perfectly within the landuse - see http://overpass-turbo.eu/s/34d as an example.

[krnlde]

Yeah I know. This's why I opened this issue in the first place. Do you have any suggestions on this?

[krnlde]

Hi again. Keeping the previous conversation in mind - is there anything I can do to achieve my goal?

[mmd-osm]

For the time being you could set up your own local Overpass API instance and adjust the rules in areas.osm3s according to your needs.

c.f.: https://help.openstreetmap.org/questions/20841/how-to-query-all-elements-within-an-outline-way-from-overpass-api

[krnlde]

That seems to be an appropriate solution for now. Thanks for your support!

[krnlde]

Hey guys. Just to awake this issue from a deep slumber: If there is any news other than the mentioned workaround I'd be happy to test and contribute.

[soshial]

Same question. I'd love to know if I can load landuse for a specific location/coordinate.

Asked a question on SO. There are a lot of such questions.