quest for destination:lanes

[tiptoptom]

trafficstars

There was an issue for this at the sc repo but I think the main problem is that there is no tag for when there is no sign and that it's a bit complicate to find the right sign. https://github.com/streetcomplete/StreetComplete/issues/3806

Would that still be conceivable in scee?

https://wiki.openstreetmap.org/wiki/Key:destination

[Helium314]

It seems to be complex, and I have no idea what exactly to tag or which elements to select. But the "no unanswerable quests" blocker does not apply to SCEE, so this quest is totally acceptable.

Adding this quest myself (currently) is too much work for me, as I never dealt with destination tagging. If someone else wants to implement the quest, or can give a clear description of where to ask, and what could be answered, I can help.

[Helium314]

Alternatively it could also be realized as overlay

[tiptoptom]

Maybe we could start with turnlanes. But I think overlays can only show colors, so I don't know how useful this is for turnlanes/destination...

[Helium314]

But I think overlays can only show colors

They can also show icons and text, see the shop overlay. While currently not implemented, it's also possible to show rotated icons.

I had another look a the wiki page and data at some random locations.

• There is destination:lanes and destination, for before and after the split. Should both be supported, or only one?
• When looking through data, often there is not only the last way segment before / after the split tagged, but several more. Should this be supported in any way? Wiki states this is a possibility only for destination.
• There is also destination:to, destination:ref, destination:ref:to, destination:country, destination:int_ref and some more. Should any of these be supported?
• Which elements should this be asked for (if a quest), or what should be shown as missing (if overlay).

The quest/overlay can be extended later, but for a start I need element selection (with display style in case of overlay) and concept of a UI.

[Helium314]

I'd rather implement it as a quest, as with the overlay (almost) full support of destination tagging is required.

For element selection, does the follwing idea make sense?

• motorway_link or trunk_link branching off from a motorway or trunk (or _link)
• oneway
• no destination / destination:* tags
• not part of a destination_sign relation

Note that this is intentionally limited for simplicity. It could be expanded to be asked for more road types and non-oneways, but that's not relevant for the first implementation.

Then what should be tagged? Just ask to enter a bunch of names and put them into destination? And some "differs by lane" other answer should be available, showing the destination input for each lane. Again, once this is done the tagging could be expanded, e.g. to (optionally) add destination:ref and maybe others, and use some more convenient input like auto-complete.

@mcliquid you're probably not using SCEE, but you proposed the StreetComplete quest and maybe have more understanding in destination tagging. Do you have any comments / additions?

[mcliquid]

@Helium314 Thanks for the mention, I use SCEE but actually very rarely because I am still very influenced by the ranking in SC 🏆

First of all, a few tooltips:

• This can be used to display existing taggings on roads.
• With this you can visually check the tagging.

What else would need to be considered from my point of view: there are junctions that fall into the grid you developed, but consist of several pieces of road, because the speed is changed on the ramp. That means per exit with the same destination values there can be 2-5 ways. And thus many quests arise, which would all have to be answered in the same way. One example with 4 ways: http://overpass-turbo.eu/s/1uNP

I would possibly also include lanes=1 in the filter for simplicity at the beginning. Then a possible destination:lanes falls out. With oneway=yes you can also ignore destination:forward and destination:backward.

From my point of view, the biggest challenge for the user is the possible amount of directions. Just a generic example: https://commons.wikimedia.org/wiki/File:Abb.13-_Wegweiser,Autobahn-Normalien_1958-2.svg The desired tagging result would be: destination=Hachenburg-Höhr;Grenzhausen;Ransbach;Selters" How does a user manage to capture this (mostly while driving by as a passenger) in a short amount of time? And how do you set the semicolon?

I still find the quest extremely valuable and would be happy to see it here. Any other questions?

P.S.: Since turn:lanes was also mentioned here, I would suggest a separate quest and a UI like in the JOSM plugin:

[Helium314]

One example with 4 ways

My current plan would be to only ask the quest for https://www.openstreetmap.org/way/455892262, but not the following segments. Is it necessary / recommended to add destination for all of them?

I would possibly also include lanes=1 in the filter for simplicity at the beginning

That's a good idea, reduces effort for the initial version by a lot.

From my point of view, the biggest challenge for the user is the possible amount of directions

My current idea is some input like used in the cuisine quest, where several single inputs are composed into a semicolon-separated list. The suggestions could be taken from recent user input and from destination/:lanes/:forward/:backward tags of nearby elements. I see the issue with needing to do quick input... my only idea here is to optimize the form, so the suggestions never hide anything.

I am still very influenced by the ranking in SC

There's probably a lot of users not using SCEE because of this. I'm somewhat divided here. On one hand, I noticed that actually it's possible to make the edits count towards SC statistics while clearly stating the change comes from SCEE in changesets. But on the other hand I don't want to attract people that should stay with SC to use SCEE just because they can get more points there.

[mcliquid]

Is it necessary / recommended to add destination for all of them?

Since I don't know how routing software handles this, I decided to do it this way in Vorarlberg. But I assume that it is enough if it is only on the first route.

My current idea is some input like used in the cuisine quest, where several single inputs are composed into a semicolon-separated list.

That's a good idea. i would just try not to show an autocomplete list at the beginning, so that the textinput is forced at the beginning.

On one hand, I noticed that actually it's possible to make the edits count towards SC statistics while clearly stating the change comes from SCEE in changesets.

Offtopic: But can't you separate between the quests that are counted in the statistic? All SCEE quests that also exist in SC count, all others do not count?

[tiptoptom]

@mcliquid see #370

[tiptoptom]

@Helium314 @mcliquid I think it's a good idea to ask this quest just for ways directly at the junction and set destination=*

For direction:lanes and turn:lanes a seperate quest would be needed (maybe similar to the lanes count quest).

[Helium314]

A first version of the quest should be in https://github.com/Helium314/SCEE/actions/runs/4956071743 once the build is done. Re-uses the cuisine UI, and only supports single lane and oneway.

Now I depend on feedback, because the potentially eligible highways in my areay already have destination tags.

[mcliquid]

At least for me, the quest pin is not clickable.

[Helium314]

Oh... the Sprite sheet needs updating. This normally happens on version upgrade or first start, but this test build has the same version code as 53.0.

[Helium314]

I changed the icon to the street name quest icon, that one should work without needing to completely reset the app. https://github.com/Helium314/SCEE/actions/runs/4956699606

[Helium314]

Anyway, asking at that road very much looks like a bug... https://www.openstreetmap.org/node/1077040840 seems to be incorrectly detected as branching point because the oneway tags are not taken into account

[Helium314]

Should be fixed in https://github.com/Helium314/SCEE/actions/runs/4960596826

[tiptoptom]

We need to exclude oneways when there is no other way to go. https://www.openstreetmap.org/way/166258705

[Helium314]

Such details can be left for later when finalizing things.

More relevant is the UI, as it looks like it should be complete from the start, as adjusting it later will be much more work. I added a lanes UI to be shown of there is more than one lane: User can select each lane and set destinations like in the current UI. Lanes with destination get a checkmark to show something is already entered. Note that the UI is not complete:

• the lane image needs to be adjusted to show a single lane each (none readily available in SC)
• a "copy from previous" button could be added somewhere, as often two lanes have the same destinations. Alternatively it could be allowed to select multiple lanes
• there will be an "all lanes" button to be used if destination is the same for all lanes
• currently it's mostly a dummy UI (hence the ok button despite not all lanes having a checkmark)

Is the UI clear enough? Orientation is always the same, could this be confusing? Leftmost displayed lane is leftmost lane in travel direction.

For forward/backward, I plan to show the side selector (like in the lanes quest). The side selector will only be visible if the keyboard is hidden, as the quest form would be too high otherwise. If there is a single lane for a side, that should work nicely. But if there are more lanes, I fear the orientation may become confusing... it's still that leftmost displayed lane is the leftmost lane in travel direction, but that might not be obvious. My best idea currently is (animated!) rotation of the side selector after a side is selected, so it aligns with the lane selection UI. But this likely requires rotating the map with it, which I think is fine, but may not work for all users.

Any comments?

[tiptoptom]

@Helium314 I think we should have two different quests for destination=* and destination:lanes=* because destination=* refers to the way after the junction and destination:lanes=* refers to the way before the junction. https://wiki.openstreetmap.org/w/images/a/aa/Destination_vs_destination_lanes.svg

For destination:lanes=* your lane UI looks good. I think arrows on the lanes would be helpful and maybe a third quest to first ask for turn:lanes=*

[Helium314]

Hmm right, thanks

[Helium314]

Misunderstanding such things is why I initially didn't want to do it and asked for a clear description...

[tiptoptom]

@Helium314 ok sorry for the ambiguity

[Helium314]

I think destination:lanes will only work properly as overlay, because in many/most cases the way needs to be split appropriately before a quest would be applicable.

So my current idea

• destination quest
  • current UI and oneway version should be fine
  • element selection needs to be improved
  • could it be asked for some non-oneways?
• destination overlay
  • edit destination and :lanes, plus forward/backward
  • UI as above
    • maybe some adaptation because of the lanes tagging scheme with cycle lanes
    • require ways to be split properly before destination(:*) can be added
  • what to highlight as missing?
    • anything with more than one lane where a way with destination (or applicable for destination quest) branches off?
  • somehow show existing destination sign relations

Is any navigation software actually using destination:lanes? Wiki only has "If you know navigation systems using this tagging style, please add them here "

[mcliquid]

• current UI and oneway version should be fine

I have already solved a few quests in my area with it and was satisfied.

• could it be asked for some non-oneways?

Maybe all ways that are located directly before or after a junction?

Is any navigation software actually using destination:lanes? Not that I'm aware of. For OsmAnd see https://github.com/osmandapp/OsmAnd/issues/5246

[tiptoptom]

• destination quest
  • current UI and oneway version should be fine

I think the destination=* quest is already really good.

• element selection needs to be improved

We need to exclude oneways when there is no other way to go.

• could it be asked for some non-oneways?

I think we could include all junctions of 3 or more of the following types because those junctions usually have destination singes. And I think it would be enough to set the direction, leaving the junction, so therefore no overlay would be needed. highway=primary highway=secondary highway=tertiary

[Helium314]

Extended the highway selection, quest is now also asked for multi-lane oneways and two-lane non-onways. I ended up using the lanes form anyway, because this was necessary for some oneways.

I'm done with destination stuff now (except for necessary fixes), the overlay is left for someone else...

[tiptoptom]

For me the quest now works fine. I think a overlay would be handy, just to show if there is the destination tagged or not.

[mnalis]

I think the main problem is that there is no tag for when there is no sign

Has this been handled in any way? https://github.com/streetcomplete/StreetComplete/discussions/5035 suggests to "add destination:signed=no if no signs are posted". Could we add that to other answers?

I left notes like https://www.openstreetmap.org/note/3913412 but that is not sustainable in the long run (and neither is hiding the quest locally on the device by each user).

[Helium314]

destination:signed currently has 0 uses, and I don't want to introduce it in SCEE (see also #367). Having unanswerable quests isn't good, but acceptable for SCEE so useful quests that are unsuitable for SC for that reason can be implemented.

What you could do is adjusting the element selection. If you have many tertiary roads without destination signed, then maybe remove them from the filter. I found that the filter actually requires tuning based on location. E.g. in my experience, in a city highway=tertiary is much less likely to have destination sign than in rural areas.