Destination fields for link features

[1ec5]

Freeway ramp tagging would be much more efficient if iD would include destination fields in its link presets. These fields would also steer mappers away from naming freeway ramps with descriptive names like “Ramp to Story Rd. East” just to get a navigation application to announce a ramp correctly.

The Motorway Link and Trunk Link presets (and maybe the other link presets?) would have the following additional fields:

• Destinations (destination) – text
• Destination References (destination:ref) – text
• Destination Symbols (destination:symbol) – combo box
• Junction Reference (junction:ref) – text

Since it’s possible for a link way to be two-way, it may be preferable to split these tags into :forward and :backward fields, similar to how the Cycleway field is split into :left and :right fields.

As a stretch goal, it would be awesome if the Destination References field could suggest refs based on the ref tag on the connecting non-link way. (Although for the U.S., cardinal directions would have to be determined by looking at route relations.) The Junction Reference field could also suggest the connecting motorway junction’s ref tag.

#1878 suggests adding a similar field to the Motorway Junction preset, based on the exit_to tag, but that tag is more or less moribund at this point.

[bhousel]

The Motorway Link and Trunk Link presets (and maybe the other link presets?) would have the following additional fields:

I agree this would be a valuable addition.. @1ec5 can you take the lead on adding these fields to all the link presets?

As a stretch goal, it would be awesome if the Destination References field could suggest refs based on the ref tag on the connecting non-link way.

I'm less convinced that this is a good idea - often the link road doesn't really connect to the destination:ref.

I might be confused about proper tagging though. A good example is the destination sign here. It says "To I-78", but I-78 is about a mile away.

[1ec5]

As a stretch goal, it would be awesome if the Destination References field could suggest refs based on the ref tag on the connecting non-link way.

I'm less convinced that this is a good idea - often the link road doesn't really connect to the destination:ref.

I agree that there would be plenty of false positives. If we implemented it as a dropdown suggestion, would that mitigate the problem?

The problem this suggestion attempts to address is that, in the U.S. and a few other countries, the way ref prefixes aren't especially discoverable from looking at street-level photography alone. However, on second thought, maybe the better approach is to improve Mapillary's sign detection to the point where we could rely on its detection of route shields. 🤔

[1ec5]

I might be confused about proper tagging though. A good example is the destination sign here. It says "To I-78", but I-78 is about a mile away.

This is where you'd use the destination:ref:to tag. There's a panoply of destination tags; I'm not sure whether it would clarify or confound the user if they were presented with more of them. Unfortunately, destination signs really are quite nuanced…

[bhousel]

I agree that there would be plenty of false positives. If we implemented it as a dropdown suggestion, would that mitigate the problem?

Yes that is probably best for now. It could work similarly to how we have dropdowns for some of the Address fields, which can suggest things like Street, City, Zip from nearby features.

This is where you'd use the destination:ref:to tag. There's a panoply of destination tags; I'm not sure whether it would clarify or confound the user if they were presented with more of them. Unfortunately, destination signs really are quite nuanced…

I guess the real question is, how bad is it for somebody to add destination:ref instead of destination:ref:to? Does it break OSRM or just cause it to issue a slightly silly instruction?

If destination tagging is really complex, we might need to build a special field for it (like we have for turn restrictions) - which is fine, but a much bigger lift and pushes this back a few months.

I'm reading here: https://wiki.openstreetmap.org/wiki/Exit_Info - it does seem kind of complicated.

[1ec5]

I guess the real question is, how bad is it for somebody to add destination:ref instead of destination:ref:to? Does it break OSRM or just cause it to issue a slightly silly instruction?

OSRM doesn’t currently recognize destination:to or destination:ref:to: Project-OSRM/osrm-backend#3542 (comment).

More to your point, these destination tags affect guidance instructions attached to a route but not the route itself. Some of the differences between the tags are quite subtle, like destination versus destination:street, in which case mistagging could cause weird instructions but wouldn’t break routing. Other mistakes, like tagging name instead of destination, could cause a data consumer to ignore the value entirely (cf. mapbox/mapbox-navigation-ios#410).

For data consumers, issues with freeway ramp guidance can really affect usability, almost as much as connectivity issues. But given the rabbit hole we could go down – a graphical guidance sign layout tool, anyone? – I think we should start small with a few ordinary fields for common tags. At least that would discourage misuse of name and ref.

[quincylvania]

These fields make even more sense to add now that we have #5582.

Before seeing this issue, I added a basic text field for destination to link roads in ecec397. Both destination and destination:ref currently have an order of magnitude more usage than their :forward and :backward counterparts. We don't have a stock UI to handle all three variants without adding multiple fields. Is the goal to support just destination:forward and destination:backward but not destination?

[pnorman]

You don't want *:forward and *:backward for links that aren't oneway=no, which is the vast majority of them.

[quincylvania]

In 6adc174 I added fields for all four properties to all of the highway _link presets. These only appear when oneway=yes to avert users entering ambiguous data. The destination and destination:ref fields seem fundamental so I added them to the top, while the highway:symbol and junction:ref fields are available under "Add field:" (where I also moved Name and Road Number).

I think this system actually works pretty well. Later on someone could make custom fields for the :forward and :backward variants that only appear when oneway=no or is assumed to be no.

@1ec5 I'd love to hear your feedback! I'm also wondering if this issue should be closed or renamed or not.

[bhousel]

Cool! I tried this out around my favorite spaghetti junction. I like it!

One thing that I think we might need to address is that the destination values are supposed to be ordered in the semicolon delimited list - from the top of the sign to the bottom.

I'm not sure whether our semiCombo field tries to impose an order - and we don't yet allow users to drag the chips around to reorder them - and most users wouldn't even know that value ordering is important in the first place, so this might be a thing that causes issue for people.

I'd like to get @1ec5's thoughts whether this matters. If this is something that would cause problems, I'm pretty ok with them being plain text fields for the time being.

[quincylvania]

@bhousel It looks like the semiCombo field maintains the order of the values in the tag and appends values in the order they are entered. My personal preference is to keep these fields as semiCombo for the time being and let reordering occur in the raw tags editor. We can open an issue for drag-and-drop reordering of semiCombo field values if you think that's worthwhile.

[1ec5]

Thanks @quincylvania, I’m really digging the more flexible optional field mechanism.

There are more complicated scenarios requiring additional tags like destination:ref:to, especially in the U.S., but I think the four tags you’ve added are the most intuitive/distinguishable to non-advanced mappers. (In fact, I’m struggling to come up with a short name for destination:ref:to that reflects real-world usage and isn’t easily confused with destination:ref.)

junction:ref can contain multiple values, but I think it’s fine to leave it as a normal text field, since that’s what we have for ref despite the possibility of route concurrencies. I do wonder whether we should display it initially in the same spot as in the Motorway Junction preset, for consistency’s sake.

The order is meaningful in destination and destination:ref (and maybe in destination:symbol). Some routers ignore the order and pick the most “relevant” value for a given route, but the original order would matter to any router that renders guide signs, like CheckAutopista2 does. (Incidentally, this is my principal objection to liberal usage of destination:street: it discards information about the order, which can sometimes be atypical.)

Dragging-and-dropping the chips would be ideal but not essential. If mappers don’t figure out that the order matters, maybe we could try applying display: block to each chip, reflecting how guide signs put each destination on a separate line. Aside from destination tags, are there any other occurrences of semiCombo where the order technically matters?

Is there a way to hide the dropdown arrow on the destination and destination:ref fields? As with name and ref, we can’t currently suggest any values to the mapper. #4178 (comment) proposed suggesting nearby refs, but I’m having second thoughts about that idea. Route relations are complicated.

I brought up :forward and :backward because it might be interesting to generalize the cycleway:left/cycleway:right field to work for any directional tag. But I definitely agree it’s nonessential.

Great work @quincylvania!

[quincylvania]

@1ec5 Thanks for the detailed response!

If mappers don’t figure out that the order matters, maybe we could try applying display: block to each chip, reflecting how guide signs put each destination on a separate line.

Is there a way to hide the dropdown arrow on the destination and destination:ref fields? As with name and ref, we can’t currently suggest any values to the mapper.

I like both of these ideas a lot! The dropdown arrow is certainly deceiving when no menu pops up. I'll work on these items and leave the fields as semiCombo.

I brought up :forward and :backward because it might be interesting to generalize the cycleway:left/cycleway:right field to work for any directional tag. But I definitely agree it’s nonessential.

I agree it would be cool to generalize that field one day if anyone is looking for more work 😄.

I'm closing this issue since I think the four new fields are sufficient for now. Feel free to open new issues for any lingering tasks.

[quincylvania]

Here's what the Destinations field looks like with full-line values: