Quests for surface should not be shown for $highwaytype=link

[RubenKelevra]

I noticed that paths with

highway=footway
footway=link

are shown to have missing surface type/surface quality tags in SC.

While technically correct - as those tags are not there - those tags make no sense as the footway is just "virtual" and mapped for routers.

Docs

Source

How to Reproduce Zoom to a way with those tags in SC, and it will show up for the surface type quest.

Expected Behavior Those ways should be filtered for some details, like surface.

Details like access=* and and lit=* however make sense to show, as this is observable.

Versions affected v51.0-beta1

[westnordost]

hmm I don't know, while they are virtual they do have a surface. Just like all those "virtual" roads that exist on a large/complicated intersection which in real life is just a large asphalted area.

[RubenKelevra]

No, they don't have any non-virtual appearance. In this case, there's a footpath ending at the sidewalk.

So it's just for making a connection for routers to continue navigation "on the street" aka on the sidewalk.

As there are parking spaces between the sidewalk and the road center, the distance is quite large. This specific virtual path is 10.6 meters.

Here's an aerial shot:

I mean, I don't even know what I should answer in this case in SC – the sidewalk has paving stones, the parking spot is either concrete or asphalt and the street is asphalt. Should I do 3 different segments with 3 different surface tags and 3 different surface qualities?

And mapping the sidewalk separately doesn't make sense here either, as it's not separate from the street. Meaning, you can always cross the street. So if I would follow this route, I would have to create virtual footpath areas between the sidewalk and the street to represent this or something similar? Which would also pop up in SC for these quests – I guess.

[westnordost]

Hm yeah, I guess to split that way into two and select "paving stones" for the sidewalk area and asphalt for the rest would not really make sense

[mnalis]

I agree, while it is surely possible to do, micromapping those requires huge amount of effort being asked of mapper which is not proportional to miniscule benefit that it might bring. Which seem contrary to SC basic principles, especially:

• :clock4: Effort vs impact

I've had same issue generally in cities, especially at crossings: there 3m corner part of sidewalk, then there is 0.5m way "virtual footway" (although I've never seen footway=link user so far but I guess they should be marked as such, although it seem like even more useless database bloat) going from that sidewalk to kerb, then 3m zebra over the road to another kerb, then another 0.5m connection to another sidewalk, then another 3m corner part of the other sidewalk... I get asked for surface and smoothness for each of those little ways... All that times 4 for a one crossing. And then there is another city street 10 meters ahead, and whole thing repeats.

I mean, if one is set up for buffing up their SC score that might be gamification gratification, but for me, it gets boring really fast -- the main issue being I know the usefulness is almost nil. They're all paved, and whether that virtual 0.5m is half asphalt and half paving stones surface is really irrelevant, much less their smoothness (err, significant part of that virtual 0.5m way is lowered kerb which has anti-slip cuts in it, so should I mark it is smoothness=intermediate then, as opposed to 0.3m virtual footway part of asphalt which is smoothness=good, etc..)

---

TL;DR - So I would suggest in general skipping at least those quests (surface and smoothness, but maybe also lit and others?) on ways which are shorter than say 10m? (I'd personally also love for that distance to be configurable in preferences, of course, but I'd live with fixed hardcoded value too :smile: )

I think it would address the "don't bother the user with high-effort yet extremly-low-worth quests" in much more effective and generic way, then only skipping small number (less than 9k wordwide) footway=link ways would.

[RubenKelevra]

@westnordost wrote:

Hm yeah, I guess to split that way into two and select "paving stones" for the sidewalk area and asphalt for the rest would not really make sense

I agree, this doesn't make sense.

Also, if you navigate to the street and then walking along it, you would just turn right or left onto the sidewalk. So tagging an asphalt surface with an awful surface quality on the “link” on the other hand would imply that you need to traverse this surface – which is not the case.

So if you for example route for a mobility-impaired user, the router would try to avoid routing over this way – while this is not reflecting reality here.

[RubenKelevra]

@mnalis wrote:

TL;DR - So I would suggest in general skipping at least those quests (surface and smoothness, but maybe also lit and others?) on ways which are shorter than say 10m? (I'd personally also love for that distance to be configurable in preferences, of course, but I'd live with fixed hardcoded value too smile )

Tagging lit=yes/no kinda make sense IMHO. As routers my otherwise avoid this path as there's no positive information that it's lit attached.

I've had same issue generally in cities, especially at crossings: there 3m corner part of sidewalk, then there is 0.5m way "virtual footway" (although I've never seen footway=link user so far but I guess they should be marked as such, although it seem like even more useless database bloat)

Tagging, especially longer ways as virtual if they just connect to the sidewalk makes sense to me, as otherwise other mapper would maybe start micromapping the surface in the future. SC currently encourages this, as it asks for the surface, and you're supposed to split ways if the answer differs for the way section.

[matkoniecz]

the main issue being I know the usefulness is almost nil. They're all paved

The problem is that sometimes you have short stretches of cobblestone/really rough set. I also encountered cases where short sections were missing.

So I would suggest in general skipping at least those quests (surface and smoothness, but maybe also lit and others?) on ways which are shorter than say 10m?

That will cause problems when someone split footway because short section is actually steps. I do it very often.

Though maybe my area has more unjustified love of making obstacles for pedestrians and putting in avoidable steps?

[RubenKelevra]

@matkoniecz Agreed, skipping sections if they are short would just lead to missing data. Would be better to have SC auto-merge small sections if all tags and relation roles are equal.

But effort vs. impact would be small – they are usually split for a reason.

[westnordost]

I added that if footway=link (or cycleway, path, bridleway when applicable), the following quests are not displayed:

• AddCyclewaySegregation
• AddPathSmoothness
• AddCyclewayPartSurface
• AddFootwayPartSurface
• AddPathSurface
• AddWayLit
• AddCyclewayWidth

[Woazboat]

Could the same be applied to the overlays (e.g. for street lighting) so that footway=link ways are ignored? A user in my area reported a footway=link virtual connection as 'nonexistent' because they saw it in the street lighting overlay according to the note they opened. (StreetComplete version was reported as 54.0)

(Either that or somehow make it more apparent that these ways are virtual only and don't necessarily represent ways that have a distinct physical representation.)