Splitting ways corrupts step_count

[matkoniecz]

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)

Simply removing tag would be better

related to #3740

triggered by streetcomplete/StreetComplete#2145 MarcusWolschon/osmeditor4android#1251

[quincylvania]

@matkoniecz Hmm instead of removing the tag, 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]

@matkoniecz Hmm instead of removing the tag, 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]

There are some more tags that might have a meaning for the geometry. Discussion still happening in streetcomplete/StreetComplete#2145 but the following came to my mind:

• capacity (f.e. bicycle parking mapped as line)
• parking:lane:[left/right/both]:capacity (described as "possible enhancements" to the parking lane schema on the wiki, so not official, but I think the tagging makes sense for parking:lane:[left/right/both]=marked - for all other parking lane types the capacity could just as well be computed)

[quincylvania]

At least the user should be asked if the assumed counts are correct.

@DerDings I'm afraid most mappers won't know nor care which part has exactly how many steps. iD is meant to help non-experts contribute usable data, not perfect data. It's not ideal to estimate, but it'd be a real problem if someone goes out and surveys step counts for accessibility and then later iD discards that data entirely.

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

Probably, but if so then it's not worth worrying too much about this functionality.

If one property varies so much that the way needs to be split, it is likely that the measures of the steps also vary.

I'm not sure this is a fair assumption. Stairs could change in color, width, access, incline, surface, level, layer, etc., but I don't see why that would necessitate a change in spacing.

[westnordost]

Stairs could change in color, width, access, incline, surface, level, layer, etc., but I don't see why that would necessitate a change in spacing.

incline certainly would :-)

I tend towards deleting step_count (etc) when implementing this in StreetComplete because once this tag is tagged wrongly, it is quite unlikely that someone else will notice and correct it while of course when the tag is missing, it can be detected easily that the information is missing (by StreetComplete).

Edit: capacity, step_count etc. are all properties that can just as well be estimated quite well from the length of the way, so they are not really so necessary. Except of course if the value is quite unusual, for example for very steep or very flat steps, for stacked bicycle parkings, for only very few marked parking spots within a marked parking lane, ...
My point is: Since a default value for these can be calculated from the length of the way, if it is defined, it is even more important that it is correct.

[DerDings]

At least the user should be asked if the assumed counts are correct.

@DerDings I'm afraid most mappers won't know nor care which part has exactly how many steps. iD is meant to help non-experts contribute usable data, not perfect data. It's not ideal to estimate, but it'd be a real problem if someone goes out and surveys step counts for accessibility and then later iD discards that data entirely.

If estimating is preferred, a tag like fixme=check <key> could be added to both fragments to state that the value may be inaccurate. fixme is found by various QA tools and it's likely someone will check it. Since the whole thing were talking about is a very particular case, this won't be spammy. The tag fixme=check step_count could also be used as a trigger for resurveying step_count in StreetComplete.