OverpassQL query for list of unique names of highways near matched element (use cases such as PoI conflation)

Help and support
, ,
1

I need some help here on a non trivial spatial query on OpenStreetMap dafa. Examples which return a list of something (such as specific kind of amenity=, like schools, healthcare, etc) already are well documented. I suppose one (not the only one) strategy would use the following general idea:

  1. work with features near/around the target feature (note: almost always literal point of node itself or centroid of a closed way or relation; this is more close to result used for “poi conflation”, not “road conflation”)
  2. custom OverpassQL output (maybe CSV?) focused only in return what’s not in the target element itself
  3. keep reference to original PoI element, such as having original id of node/way/relation as a key for what’s around (it’s not necessary return full tagging/geometry)

This specific query I ask in the title would not need (actually, is better to just return the unique names, maybe sorted by distance) full details of the around elements. Also, use cases tend to be the following:

  1. The targeted PoI neither has addr:street or have, but the external dataset uses another addr:street (which is not merely a misspelled name). This might be easier for human comparing with slippy map on background, but tools making suggestions would fail if is not loaded also near streets (this explain why an example of special query only for get list of alternative street names)
  2. An external data may be using not the name= of highway, but old_name=, alt_name or loc_name (all these don’t show on slippy maps, so humans would need to click one by one and inspect tags :confused:)
  3. The typical use case already has few initial matched PoIs and, when not, users are likely to already focus on a city-level or lower area (so, performance issues with around clause, if any, likely will not matter)
  4. Repeated names (e.g. real world street is just one, but on OSM it may have been split on several ways) better appear just once (preferable the near one)

Thanks in advance!

PS.: one reason to subdivide conflation (see OSM Wiki: Conflation) as “PoI conflation” (hint: a lot of conflation strategies on OSM tend to be “road conflation”) is both because geometry/position alone become less viable and because the metadata (both already in the element, or something near) become main objective. Also, PoI conflation, unless already exist a strong referential code previously added (the ref= and ref:*=) is highly human-in-the-loop. and even when does have strong referential code, any inconsistency (such as external dataset mark as closed or changed and now is another address) human mappers become afraid of move/delete

2

I’m not sure that I understand what you want, but some ideas.

First: amend given objects with street names, in this example schools:

area[name="Wuppertal"];
nwr(area)[amenity=school];
foreach
{

way(around:100)[highway~"primary|secondary|tertiary|unclassified|residential|pedestrian"]->.w;
   convert info ::=::,::geom=center(geom()),streets=w.set(t["name"]);
   out geom;
}

{{style:
node { text:streets; }
}}

This amends in the loop each school individually with the names of the
surrounding streets.

If you want to display the result on a map, then you need to do that on
this instance of Overpass Turbo, because
the standard one do show geometry only for pristine OSM objects.

Second: screen objects with addresses for non-matching streets. Note
that there is a debug tool within Nominatim that most likely runs a lot
faster. Aside from that, the follow query does that:

area[name="Troisdorf"];
nwr["addr:street"](area)->.addr;
way["highway"]["name"](area)->.streets;
for .streets->.street (t["name"])
{
   (.addr; -
nwr.addr(around.street:100)(if:t["addr:street"]==street.val);)->.addr;
}
.addr out center;

This works on the normal instance although it is slow.

1 Like