a complete logical highway by name

[ghost]

A not yet released "complete" feature from mmd of Overpass-API drolbr/Overpass-API#95 can help people to show complete highways, even when there are gaps between.

Searching for "Ostmerheimer Straße, köln" with nominatim at openstreetmap.org will lead here http://www.openstreetmap.org/way/209985260#map=19/50.95779/7.04874&layers=N

And you will see just a small piece of the disired highway.

By adding a new parameter like _logicalhighway to the /way/209985260 page, open an call to overpass-api and render the result in a new layer. Maybe you can use another color for distinguishing.

[tomhughes]

What are you actually reporting/proposing here?

[ghost]

The issue is described better, sorry.

It would be nice to render all belonging ways for one highway (by name and distance). This gives you a better impression of its dimension.

Until now there were no good possibility to query for those belonging highways.

[tomhughes]

Well it's still not, given that the feature is not released in overpass, and anyway given that it just matches for other nearby roads with the same name it is only a heuristic.

In any case this seems like an awfully specialist use to include on the main site, and certainly we wouldn't add anything that was only triggering by manually fiddling with the URL so it would definitely need more UI than you have proposed.

[ghost]

If a highway belongs together or not is always an heuristic, I believe (think about gaps in between). There are no clear worldwide rules. But he Overpass query does the job well.

It is a special use, no doubt. On the other side, showing a street is missing now in Openstreetmap, like a normal human would expect it. As website user, I sometimes don't care about a partial way, I want to be able to see the way completely. But it is difficult to detect in a low zoom level what is part of a long street and what is not. My proposal would solve this.

A bit more UI is needed, yes. If a way contains a highway tag, it could offer a link Show complete highway to our special parametric site. Nominatim misses such a feature too, see twain47/Nominatim#114. Its target link can be changed easily to this too.

[jase88]

Is this really a frontend problem or shouldn't this be considered for "the new API"? Imho it looks like a hacky way on the frontend to get all parts with the same name, which is better placed in the backend.

[mmd-osm]

The following link points to a test instance, where you can play around a bit with this new "complete" feature @jotpe referred to earlier in this ticket: http://overpass-turbo.eu/s/857

In the example, Overpass API will return all ways named "Ostmerheimer Straße" up to 200m distance to the starting way id 209985260. Collecting ways will stop as soon as no new ways with that name are found.

Finding related highway parts is just one possible use case of this feature. I tend to agree this is a bit heuristic, but may be better than simply displaying a tiny bit of a highway, which happens to be the result of a Nominatim query at that time. As street relations (don't remember how they're called exactly) are not available on a worldwide scale, it may be difficult to implement this feature without some kind of heuristic approach.

Other ideas how complete could be used can found in the related Overpass API ticket. This however is a bit beyond the scope of this ticket.

[DominicFath]

@mmd-osm This is exactly the query I need. Looks great. What is that status on this "complete" feature making it into the official API? At the moment there seems to be an issue with the dev server though

[mmd-osm]

@DominicFath : the original pull request is now more than 2 years old and unfortunately, I don't have any details when Roland will eventually merge this into the master branch.

The example is currently working here: http://overpass-turbo.eu/s/o2E

All it needs is a way id, other nearby ways matching the way's name are automatically fetched.

[mmd-osm]

I put up a small proof of concept to demonstrate @jotpe's proposal: http://dev.overpass-api.de/tmp/psv/complete/

Just click on some street with a name and see all parts of the street highlighted, regardless of how fragmented the underlying OSM data is. Small gaps are also ok.

Caveat: a bit of patience may be needed, the dev instance doesn't run on fast and shiny SSDs.

[mcm-jyl]

@mmd-osm, @jotpe, the day before I discovered http://dev.overpass-api.de/tmp/psv/complete/, I was "hacking" on Overpass-Turbo, but just using bbox (sufficient for my needs). For having no heuristic, accept only connected ways. Yes it won't fill gaps but if Nominatim delivers the few trunks (sorted by decreasing length) it delivers something usable. For national roads crossing a town, this portion may have only the street name, not the national reference. If you try to fill the gap, 200 m will be to little. On the other hand, adding a gap may coalesce two different roads in different communes. Here quite stupidly a single name is used across 3 communes. This works because it's the same street (a former road?), but very common names could be "reused" by two different communes close by. Associated streets should be promoted, at editor level to create the relations and Nominatim should show associated streets first.

BTW, for the previous example, in fact all the service roads south from here are part of Rue du Bignon. Yes about 10 buildings on 40, rue du Bignon going over 2 communes...

Until recently the Route du Chêne Morand had the same name on both sides of the highway (now Rue on one side, Route on the other side). On a user point of view it's important to know that you can't go from one part to the other.

Even more crazy - here only a proper representation with associated_street or strict connection can help: The [Rue des Loges in Chantepie](http://www.openstreetmap.org/search?query=Rue%20des%20Loges%2C%20Chantepie#map=18/48.08864/-1.62449= has been split. A truck went to Chantepie saw a "normal" Rue des Loges. But the street narrowed and went to a cul-de-sac. The guy wanted to deliver on the other side of the road. Your proposal doesn't deal with such cases as seen here.

Maybe in order to deal with not connected segments the UI could indicate the distance between the displayed objects and the zoom could be tuned to display other segments no more than let say one tenth of the total segment length (so that you see easily that some same named streets are close by. Letting you decide if it's one or two streets.

[simonpoole]

@mcm-jyl associated street relations are long dead and didn't do what you are thinking of to start with (you are thinking of "street" relations, which however are widely unpopular too).

[mcm-jyl]

@simonpoole, 4,974,713 associated street relations, that's not exactly what I would consider as "long dead", but yes street relations can also do the job. Here I'm speaking about the rather rare case where ways are NOT connected but belong to the same street. What is your alternative to prevent arbitrary fusion of streets sharing the same name?

[woodpeck]

I think it depends very much on your use case and your definition of what a "logical highway" is. It is not set in stone that a "logical highway" must stop at a boundary and that the fusion of two nearby streets carrying the same name is therefore "arbitrary". (There could be use cases where two parts of a street may be "the same street" in a postal sense but looking at it with the eye of who maintains the street, a change from highway=primary to highway=secondary might indicate the street becomes "different", and any fusion of two connecting streets just because they have the same name is "arbitrary").

I usually load all streets for the country of interest into a PostGIS database together with all boundaries, and then have them joined (or split up by geometry) for the particular use case. I think it is a too multi-faceted problem to expect to solve with an Overpass query.

Also, I think that it shouldn't be the job of the OSM web site (this is the issue tracker for the OSM web site after all) to offer interpretations on the data. Frankly I wonder why Overpass is involved in this discussion at all - the original poster had the problem that only a little part of a street was shown when he searched for it (basically, the first hit found by Nominatim). Could this not be solved by using Nominatim's dedupe=0 parameter and then displaying all search results instead of just the first?

[mcm-jyl]

@woodpeck, very good points here. Then a better approach would to "join" the connected ways with similar status. I didn't mention that but IMHO, the individual parts would remain accessible if you click on such a "joined" street. For my first example it cross 2 communal boundaries but it's one street (in the common sense). But for the postal delivery they have 3 zip codes. So except a decision made by locals to have 1 or 3 streets (i.e. explicit definition of street), I don't see a solution, but is it a problem? Here 2 postal codes and town names for one single address number... making some places hard to find with navigation engines! The issue is more when streets are split into segments due to crossings, routing, etc. In that case all important attributes should remain the same (name, ref and probably highway and surface if set and different). Maybe tuning the initial zoom level to display all segments close by would be sufficient (and ordering using shared nodes), but a normal user expects to see the whole street, not tiny segments due to crossings for instance.

[mmd-osm]

Could this not be solved by using Nominatim's dedupe=0 parameter and then displaying all search results instead of just the first?

Interesting. This parameter was undocumented on the OSM wiki until only a few weeks ago, based on your answer on Help OSM last September. That's why I completely overlooked it when @jotpe raised an issue on Overpass API two years ago.

The search result on the left-hand sidebar would probably blow up with such a large unaggregated list of street elements. On the other hand, the resulting geometry returned by dedupe=0 would for sure be a very good starting point for such a feature. It did a small test with London Waterloo Road and it seems to include everything we need. Possibly, we would need something to combine the best of those two results: a concise list along with comprehensive geometry.

The tricky part is indeed to find some meaningful concept of a logical street. I fully agree with @woodpeck that this is not straight forward, and different users might have different expectations and use cases. On the other hand, the search result as it is presented today is not very appealing to normal users, as @mcm-jyl also remarked:

but a normal user expects to see the whole street, not tiny segments due to crossings for instance.

NB: why Overpass? Well, it's good for prototyping and can be easily adjusted to try out different approaches. I don't expect the final solution to be based on Overpass - Nominatim would be the target architecture.

[mcm-jyl]

@mmd-osm, you meant London Waterloo Road: html output format is more end user friendly. Except that minor edit I fully agree with you. A dedupe=2 could combine directly the similar ways and the zoom level could be set up to see the first answer if close by (nice to have). No need for Overpass then ;-).

[mmd-osm]

@mcm-jyl : json format was chosen with the intention to use it as data source for osm.org. The HTML version you mentioned does not really fit nicely into the current UI. You really want the raw data and process/enhance it via Javascript/HTML.

Also, I wouldn't recommend to "enhance" the dedupe parameter. Probably something like fullgeometry=[0 | 1] with default being 0 would be better suited.