opening hours proposal affects all traffic

[RobJN]

Similar to #10 using opening_hours= on a highway= + cycleway=lane would impact all traffic.

And you can't just use bicycle:opening_hours=* as the cyclists can still use the road outside the hours, it's just that the shared busway is no longer restricted to buses + bikes only.

The wiki provides an example of what to do here:

The issue with using this is that you need to know the position of the cyclelane in relation to the other lanes of traffic (the "=1" in the tag shown).

If you don't know this, then may I suggest using the :conditional sub-tag. There are already some examples of this on TagInfo:

https://taginfo.openstreetmap.org/keys/cycleway:conditional#overview https://taginfo.openstreetmap.org/keys/cycleway:left:conditional#overview https://taginfo.openstreetmap.org/keys/cycleway:right:conditional#overview

[matkoniecz]

In general, this part deserves more info given obnoxious complexity of opening hours - what has opening hours? Bicycle lanes? Bicycle parkings?

Also, opening hours of road are use modelled with thing like https://wiki.openstreetmap.org/wiki/Conditional_restrictions

[mvl22]

what has opening hours? Bicycle lanes? Bicycle parking?

Cycle lanes. This is part of the CLT dataset (Cycle Lanes & Tracks), as the key CLT_ACCESS. See: https://bikedata.cyclestreets.net/tflcid/conversion/#ss_access

In London, some cycle lanes are only considered legally in operation for some time period, e.g. during peak traffic. At other times, vehicles are allowed to drive in them, i.e. as if the white line was not present.

[mvl22]

CLT_ACCESS values are strings but due do not appear to have been done to any standard - examples are:

• mon-sun 7am-7pm
• Mon-Sat 7-10am 4-7pm
• 8am-One hour before dusk.
• at any time
• 7AM-7PM mon-sun

However, there is a long tail, with some common values appearing many times. I think it would be worth having the those top values that have 20 or more instances turned into OSM-compliant strings as per the OSM spec, to avoid about 1,000 fixes having to be done manually, for the sake of 20 lines of code.

@systemed Action here is to convert from using the current fixme:opening_hours to OSM compliant datetime strings for those values with ≥20 instances. The rest can remain as fixme with the original string, as they are a long tail not worth trying to automate.

[systemed]

Sounds sensible. If someone has a spare minute and would like to put the mapping in here, that'd be great as my knowledge of the conditional time syntax is approximately zero...

[mvl22]

On the point that Rob raises, namely use of opening_hours, changes also need to be made in that respect.

Currently handling of this tag is implemented in the code reasonably safely using a fixme -prefixed tag:

if pr['CLT_ACCESS'] then tags["fixme:opening_hours"]=pr['CLT_ACCESS'] end

However, as Rob points out, this is problematic when de-prefixed for the case of a cycle lane that is an attribute of a highway, rather than a cycle track in its own right. This will be worse when, as above, we remove the fixme prefix for the common cases.

I agree with Rob that opening_hours is not correct on a main highway, and bicycle:opening_hours is not correct either for the reasons given.

What should happen is, as Rob also suggests, is that the cycleway itself is given conditional access. cycleway:conditional will work for both highway=secondary + cycleway=lane and for dedicated highway=cycleway.

@systemed Action here is:

• In all cases, we should change from opening_hours to cycleway:conditional (or the cycleway:left:conditional and cycleway:right:conditional variants if being used) = yes @ datetime-string. E.g. CLT_ACCESS=mon-sat 7am-7pm will become cycleway:conditional=yes @ Mo-Fr 07:00-19:00.

• Because we are specifying cycleway:conditional rather than access:conditional this will satisfy Rob's point about not polluting the main highway for any user.

• Where there is ≥20 instances, drop the fixme: prefix, i.e. cycleway:conditional=yes @ Mo-Fr 07:00-19:00. Those with fewer instances would retain the prefix, e.g. fixme:cycleway:conditional=yes @ 7am-closes at various times due to british summer time

[mvl22]

Sounds sensible. If someone has a spare minute and would like to put the mapping in here, that'd be great as my knowledge of the conditional time syntax is approximately zero...

I've added a link to the OSM spec.

To take the initial examples:

• mon-sat 7-10am 4-7pm -> Mo-Sa 07:00-10:00,16:00-19:00
• mon-sat 7am-7pm -> Mo-Sa 07:00-19:00
• Mon-Sun 7am-7pm -> Mo-Su 07:00-19:00
• mon-Fri 7-10am 4-7pm -> Mo-Fr 07:00-10:00,16:00-19:00

I think these are right, but perhaps you can double-check :) I'm sure the rest you can work out.

[matkoniecz]

fixme:cycleway:conditional=yes @ 7am-closes at various times due to british summer time

It should not be added as tags - in general, imports adding fixme tags are a mistake.

If neither people importing data nor mappers at time of import are not interested in fixing such problems, then approximately noone is going to fix it later. Or it will take decades.

[mvl22]

It should not be added as tags - in general, imports adding fixme tags are a mistake.

If neither people importing data nor mappers at time of import are not interested in fixing such problems, then approximately noone is going to fix it later. Or it will take decades.

I don't really agree.

The conditional restriction is useful information that should has been surveyed and saves the time of re-surveying. But it's not reasonable for an import to get perfection for this kind of data. This is no different to when I have surveyed something but add a note for something that I don't have time or knowledge how to tag.

The presence of the fixme is not harmful, and it is much more likely to translate into improvement in future than if the area BOTH a) has to be resurveyed and then b) the same complex restriction string has to be worked out.

[matkoniecz]

But it's not reasonable for an import to get perfection for this kind of data. '

It is reasonable.

This is no different to when I have surveyed something but add a note for something that I don't have time or knowledge how to tag.

It is different as imports can dump massive amount of fixmes, like human editing will be more limited and often notice that adding such fixmes is not really a good idea. Or others will ask them to stop and start fixing existing ones.

See https://taginfo.openstreetmap.org/tags/?key=fixme&value=Import%20CTR%20Veneto.%20Sostituire%20con%20building%3Dstable%20(stalla)%20o%20building%3Dbarn%20(fienile)#chronology for a story how importing fixmes works (not really)

Or https://taginfo.openstreetmap.org/tags/fixme=no%20population%20estimate%20available%2C%20defaulted%20to%20village#chronology https://taginfo.openstreetmap.org/tags/fixme=Revisar%3A%20este%20punto%20fue%20creado%20por%20importaci%C3%B3n%20directa#chronology https://taginfo.openstreetmap.org/tags/fixme=draw%20geometry%20and%20delete%20this%20point#chronology https://taginfo.openstreetmap.org/tags/?key=fixme&value=Import%20CTR%20Veneto.%20Vericare%20sul%20campo%20fence_type%3D*#chronology https://taginfo.openstreetmap.org/tags/fixme=Ubicar%20el%20POI%20en%20el%20lugar%20que%20corresponde#chronology https://taginfo.openstreetmap.org/tags/?key=fixme&value=Sostituire%20con%20building%3Dstable%20(stalla)%20o%20building%3Dbarn%20(fienile)#chronology

All taken from the most popular fixme values.

[RobJN]

It should not be added as tags - in general, imports adding fixme tags are a mistake.

Like Martin, I also don't really agree here. There is some really useful information in the cycle database and finding some way to put it in to OSM is useful. This includes edge cases and if done well, we can run a campaign to resolve edge cases manually. There are already active mappers using this data set they just note that they cannot do all of it on their own. So this import would get a big chunk done allowing the active mappers to focus on some of these harder edge cases.

They way I see it:

• It is not hurting anyone putting this data in.
• Having this data in makes it easy for active mappers to use (compared to them having to look at the source data)

[matkoniecz]

I guess that it depends on scale, if it ends adding 1000 fixmes and there are active mappers working through this - it can work.

If import adds 1 000 000 of fixmes or 80 000 then it is soud-crushing and it will likely stay approximately forever like say https://taginfo.openstreetmap.org/tags/tiger%3Areviewed=no#chronology

[mvl22]

Yes it’s only about 1,000.

Totally I agree millions would not acceptable.

[systemed]

Addressed in https://github.com/cyclestreets/tflcid-conversion/commit/f02356bbc5a256f8a74bfc71a9e1a4e81ed88ee0 as per above.

For highways with a cycle lane, cycleway:conditional (optionally with left/right) is used as per above.

For off-road cyclable tracks, such as through parks, bicycle:conditional is used instead. It is possible, probable even, that some of these have the same restrictions for foot access but we can't ascertain that from the data.

The top matches are translated directly into opening_hours-compliant syntax. Those with <11 instances are instead stored as fixmes, as per fixme:cycleway:conditional=...some non-machine parseable text....