Streetcomplete: Splitting ways corrupts step_count

[DerDings]

When a way with a value for step_count (e.g. step_count=5) is splitted, two ways are created with the same value for step_count, which leads to the total steps of both ways being doubled (two ways with step_count=5 in a row => 10 steps in total)

How to Reproduce

1. Find steps that can be splitted, e.g. by the surface quest: https://overpass-turbo.eu/s/YQR
2. Split the way with StreetComplete

Versions affected
v24.0 (probably among others)

Possible solutions

1. disable splitting ways which have a numeric value for step_count.
2. when splitting a way with 'step_count', immediately ask how many steps there are in each segment.

[DerDings]

related to #2144

[westnordost]

Oh damn, didn't think of that! Should have waited a day with the update!

Any other tags that come to your mind that should change their value based on the length of way?

On October 8, 2020 7:59:16 PM GMT+02:00, DerDings [e-mail] wrote:

When a way with a value for step_count (e.g. step_count=5) is
splitted, two ways are created with the same value for step_count,
which leads to the total steps of both ways being doubled (two ways
with step_count=5 in a row => 10 steps in total)

How to Reproduce

1. Find steps that can be splitted, e.g. by the surface quest:
   https://overpass-turbo.eu/s/YQR
2. Split the way with StreetComplete

Versions affected
v24.0 (probably among others)

Possible solutions

1. disable splitting ways which have a numeric value for step_count.
2. when splitting a way with 'step_count', immediately ask how many
   steps there are in each segment.

[westnordost]

Btw might be a problem in every other editor too. Should be checked and a bugticket created for each where the problem exists as well.

Maybe it would be better to delete the offending key rather than trying to "correct" it.

On October 8, 2020 7:59:16 PM GMT+02:00, DerDings [e-mail] wrote:

When a way with a value for step_count (e.g. step_count=5) is
splitted, two ways are created with the same value for step_count,
which leads to the total steps of both ways being doubled (two ways
with step_count=5 in a row => 10 steps in total)

How to Reproduce

1. Find steps that can be splitted, e.g. by the surface quest:
   https://overpass-turbo.eu/s/YQR
2. Split the way with StreetComplete

Versions affected
v24.0 (probably among others)

Possible solutions

1. disable splitting ways which have a numeric value for step_count.
2. when splitting a way with 'step_count', immediately ask how many
   steps there are in each segment.

[DerDings]

Any other tags that come to your mind that should change their value based on the length of way?

duration=*, but that is very uncommon (and discouraged) with regular highways. Maybe it is used for some escalators or moving walkways.

(In my opinion, escalators shouldn't be splitted at all, because they're not only a chunk of highway, but also ONE machine. But that should be discussed in the community, not here.)

[DerDings]

Btw might be a problem in every other editor too. Should be checked and a bugticket created for each where the problem exists as well.

I just tried Vespucci, same problem.

[matkoniecz]

Maybe it would be better to delete the offending key rather than trying to "correct" it.

possible alternative from https://github.com/openstreetmap/iD/issues/8069#issuecomment-706176064 :

I think iD can be smart enough here to distribute the step count proportionally to the resultant lengths. Sure it may not be 100% accurate, but it should be pretty close and it preserves the total step count.

[DerDings]

Maybe it would be better to delete the offending key rather than trying to "correct" it.

possible alternative from https://github.com/openstreetmap/iD/issues/8069#issuecomment-706176064 :

I think iD can be smart enough here to distribute the step count proportionally to the resultant lengths. Sure it may not be 100% accurate, but it should be pretty close and it preserves the total step count.

I don't think this is a good idea. At least the user should be asked if the assumed counts are correct. There are very few stairs that need to be split at all. If one property varies so much that the way needs to be split, it is likely that the measures of the steps also vary.
We're not talking about simple stairs here, because those probably don't need to be split at all.

[westnordost]

I'd also prefer to delete this information so that it can be recorded anew. After all, with a little bit of luck, the one guy who splitted it will immediately after also count the steps.

[westnordost]

What further comes to my mind which should be deleted on splitting a way is:

• capacity. f.e. capacity on a bicycle parking drawn as a line
• parking lane capacity? What is the tag for that? @matkoniecz is there one? If there is one in the future, which one will is probably be?

[matkoniecz]

capacity. f.e. capacity on a bicycle parking drawn as a line

I would consider tagging bicycle parking on line to be a tagging error - node or area is always better (though I remember participating in discussion on this topic on OSM Carto renderer issues and later on tagging mailing list and at least one person had a different view)

parking lane capacity - there is tag for that but I am kind of skeptical is it something useful - it would require massive effort and capacity differs based on vehicle size (Smarts, regular car, delivery truck, SUV, oversized car - all of them will fit different number on parallel parking lane). But for completeness may be handled.

[westnordost]

parking lane capacity - there is tag for that but I am kind of skeptical is it something useful

I was thinking about it. I think it may make sense on parking:lane:right=marked because the documentation mentions that there are only a few marked slots. But who knows how few?

[matkoniecz]

Even in such cases there are places where you can fit three small cars or one big. If I am in mood for ridiculous detail I just slice road into 10m section of parallel/perpendicular.

But who knows how few?

Even for detail oriented cases like A/B Street something like "15% of roadside is usable as parking spots" should work about as well as explicit count, with much lower effort.

Note: such counts may work in cases where roadside parkings have explicit slots for cars. Not sure how popular it is.

[matkoniecz]

Though I again got distracted in offtopic: some people tag this and it would be nice to somehow handle this, even if I see tagging this as a waste of time. Either by dropping tags silently or by estimating distribution like iD did.

Dropping tags works well for step_count as SC will reask, not sure what would be better for car capacity.

Bicycle parkings counts are not a problem as I think that SC will not split them.

[DerDings]

I thought about it a while and now I think deleting a tag is not a good idea because it doesn't cherish the effort somebody put in surveying it.

So maybe estimating is the better option. A tag like fixme=check <key> could be added to state that the value may be inaccurate. The tag fixme=check step_count could also be used as a trigger for resurveying step_count in SC.

[westnordost]

Well, I could also say

I thought about it a while and now I think automatically "fixing" a tag is not a good idea because it doesn't cherish the effort somebody put in surveying it.

The issue is, that this estimation might be wrong. Wouldn't it be better to re-survey it then? And also more respectful towards the previous effort?

[rhhsm]

Just came back from surveying, counting steps, and found a few that would really need to be split before a step count should be added. Two of them were steps that crossed a road and a path (lazy mapper at work, probably...), where you would want to know the step count for each part below and above the junction. Another had a path branching off halfway that wasn't mapped. So the step count quest could (should) be enhanced by adding the possibility to split the steps before entering the step number (like "Differs along the way…", but needs rewording).

I agree that after splitting steps that already have step_count tags, it's better to delete them for resurvey than to estimate them and probably introduce errors. You could even search for 2 consecutive steps with the same step_count, and ask if they are really of equal length...

[peternewman]

I thought about it a while and now I think deleting a tag is not a good idea because it doesn't cherish the effort somebody put in surveying it.

It could always add the old step count in a note or fixme?

[peternewman]

If you want to be safe, then splitting a way should drop any of these capacity variants (or capacity*):
https://wiki.openstreetmap.org/wiki/Key:capacity

The similar but different:
https://wiki.openstreetmap.org/wiki/Key:seats
https://wiki.openstreetmap.org/wiki/Key:capacity:seats

The obvious (I don't really see why they are needed and can't be measured):
https://wiki.openstreetmap.org/wiki/Key:length
https://wiki.openstreetmap.org/wiki/Key:distance

When these are corrupted to have a value:
https://taginfo.openstreetmap.org/keys/flat_steps#values

In summary there are some odd tags (having looked through all the keys listed on the wiki!

[westnordost]

Thank you for the research!

distance seems to be used only on certain relations and on milestones. length seems to be used mostly on some imported rivers and aeroways. So I think these are safe to ignore.

capacity:seats only on certain amenities/leisures (theatres, cinemas etc), seats is used on benches and benches can be ways. So, seats is like capacity.

The final code is:

remove("step_count")
// only remove if "steps" is a number cause it is apparently also used to denote kind of steps
if (get("steps")?.toIntOrNull() != null) remove("steps")
remove("seats")
// remove any capacity: "capacity", "bicycle_parking:capacity", "parking:lane:both:capacity", "parking:lane:right:capacity:disabled" etc.
val capacityRegex = Regex("^(.*:)?capacity(:.*)?$")
val keysToDelete = keys.filter { capacityRegex.matches(it) }
for (key in keysToDelete) {
    remove(key)
}

[peternewman]

Thank you for the research!

No worries.

So I think these are safe to ignore.

It's not worth doing distance and length now just in case?

// only remove if "steps" is a number cause it is apparently also used to denote kind of steps
if (get("steps")?.toIntOrNull() != null) remove("steps")

Did you want to do flat_steps too with the same logic?

[westnordost]

Did you want to do flat_steps too with the same logic?

Nah, look at the usage count.

But I further also added this

// only remove "incline" if it contains a number
val inclineNumberRegex = Regex("[0-9]")
val inclineValue = get("incline")
if (inclineValue != null && inclineNumberRegex.containsMatchIn(inclineValue)) remove("incline")

[peternewman]

Did you want to do flat_steps too with the same logic?

Nah, look at the usage count.

Yeah I was just thinking to pre-empt future increased usage.

I thought of another too, addr:interpolation, we shouldn't hit it, but if someone put it on a road or something. It's widely used anyway, and would have a big impact if it was duplicated.

[westnordost]

what about addr:interpolation?

[1ec5]

There are very few stairs that need to be split at all.

I’ve split plenty of highway=step ways, almost always because improved aerial imagery makes clear that there’s actually more than one flight of stairs separated by a landing (highway=footway). The overall step count was correct but now needs to be distributed over the two flights of steps.

[peternewman]

what about addr:interpolation?

If someone has used the addr:interpolation tag on a way they shouldn't have, or someone else has added other properties to that way (e.g. footpath), we may be asking to split it, at which point it should drop those tags too.

Unlikely, but as I've seen people tagging childrens playground roundabouts as traffic junctions, anything is possible!

[westnordost]

Dropping the addr:interpolation tag isn't going to solve this because the information is on the nodes. One way or another, splitting a addr:interpolation produces incorrect data (one end of the interpolation is missing), so it is better IMO to not delete anything further to keep the chance open to fix it

[peternewman]

Dropping the addr:interpolation tag isn't going to solve this because the information is on the nodes. One way or another, splitting a addr:interpolation produces incorrect data (one end of the interpolation is missing), so it is better IMO to not delete anything further to keep the chance open to fix it

Ah, yes sorry, that's me thinking but not looking at the detail!