Add destination_sign relation preset

[GenericError]

There are currently 73,726 relations with destination_sign type in the OSM database. It is also a long-standing feature within OSM but is notably missing from iD. I suggest that it should be added.

I am currently modifying a fork of the repo to add this, should the idea be approved, however am not ready to pull request as yet.

[1ec5]

By the way, there’s also a lesser-used destinationsign relation type that also claims to be useful for navigation software. I don’t quite understand the difference between the two relation types, but it would be nice to create more space between the two or eliminate any duplication.

[GenericError]

I was not aware of that relation but thanks for pointing it out.

From the wiki: "The other "destination_sign" relations focus on the physical appearance of the signs and require one relation for every sign. Other users might be interested in the area covered by signs pointing to any particular destination, in other words the network of ways leading there."

How to properly differentiate it may be difficult as a preset. However, there are currently less than 300 of these relations in the database and it has not gone through a proposal yet so I don't see it to be nearly as mature as destination_sign.

Edit: however we should probably find a way to differentiate them regardless

[simonpoole]

@GenericError note that you should be adding handling for properly splitting member ways too (this is necessary because for "unknown" reasons the via element has the role intersection).

[bhousel]

Ah yeah it would be better if they could change these destination sign relations to instead be from, via, and to, in order to match:

• restriction
• manoeuvre

There is special code in iD to avoid breakage when extracting nodes, or connecting and disconnecting constituent ways - but this only works for relation types with a from/via/to.

We have this problem with enforcement relations too. 😓

[simonpoole]

• manoeuvre

I suspect that should be 'transition'

We have this problem with enforcement relations too.

While there are from and to roles, they are supposed to be nodes if I'm reading the spec correctly and I'm fairly sure that for the rest the default splitting behaviour is OK, well at least it is not going to break something important.

[GenericError]

@GenericError note that you should be adding handling for properly splitting member ways too (this is necessary because for "unknown" reasons the via element has the role intersection).

Am I right in assuming that this handling the splitting will be difficult to implement? Or would it probably be a case of duplicating the code for the other bit and changing it to only care about "destination_sign" relations?

While there are from and to roles, they are supposed to be nodes if I'm reading the spec correctly and I'm fairly sure that for the rest the default splitting behaviour is OK, well at least it is not going to break something important.

From what I have seen other use and what I have used myself, ways tend to be used for from and to

[simonpoole]

@GenericError

From what I have seen other use and what I have used myself, ways tend to be used for from and to

https://taginfo.openstreetmap.org/relations/enforcement#roles would indicated that that roughly 3% of the from/to roles are erroneously used on ways, with other words I don't see anything wrt enforcements relations would warrant special casing them.

[GenericError]

Although destination_sign is different to enforcement and is used mainly with ways with what I can see from taginfo?

[simonpoole]

Although destination_sign is different to enforcement and is used mainly with ways with what I can see from taginfo?

See #6970 (comment) my response to bhousel suggesting that enforcement might have a similar issue, which it doesn't.

[1ec5]

(For completeness’ sake, connectivity relations also have via members.)

[maro-21]

Why are there two fields (strings on Transifex) with the same name?
What is the difference between them?

Destinations | destination=*

• presets.fields.destination.label
• presets.fields.destination_oneway.label

Destination Road Numbers | 'destination:ref=*

• key: presets.fields.destination/ref.label
• key: presets.fields.destination/ref_oneway.label

Destination Symbols | 'destination:symbol=*'

• presets.fields.destination/symbol.label
• presets.fields.destination/symbol_oneway.label

[quincylvania]

@maro-21 These fields are identical but one appears only if the oneway=yes tag is present. This isn't optimal for translation so we might think of ways to improve it in the future.

[maro-21]

Do we need separate fields for one way? Can't we remove one of them?

[quincylvania]

We need the oneway restriction since destination= is ambiguous on bidirectional highways. There are destination:forward and destination:backward tags for these cases, but they're too complex for iD to support right now. This is usually okay though since destination is mostly used on "link" highways that are typically oneway.

[maro-21]

Ah, I see.