RFC: Proposal to deprecate maxspeed:seasonal:winter

I am proposing to deprecate maxspeed:seasonal:winter because it is essentially a synonym of maxspeed:conditional=** @ (winter)

See the wiki page for the proposal here

Dealing with more, and possibly conflicting, tags makes things more difficult and complicated for anyone interested in mapping or using speed limit data in OSM.

Part of the reason for creating this proposal is that I am looking at creating a speed limit overlay for StreetComplete, which will therefore be both a data consumer and mapper.

Please, cross post this announcement on the tagging mailing list on my behalf by sending an email to: tagging@openstreetmap.org

3 Likes

The parentheses are unnecessary with such simple conditions, i.e. you can simply use maxspeed:conditional=100 @ winter instead of maxspeed:conditional=100 @ (winter), similar to @ wet.

I wouldn’t say that requiring a opening hours parser - which doesn’t exist in Lua (the most common language for on-the-fly tag transformations), Ruby (the language behind osm.org), or Swift (the language for one of the two main mobile platforms) - is making things less difficult or complicated for anyone interested in using the data.

1 Like

Surely this is the wrong way around? https://taginfo.openstreetmap.org/search?q=maxspeed%3Aseasonal%3Awinter#keys suggests 3700 uses, https://taginfo.openstreetmap.org/keys/maxspeed%3Aconditional#values (when you search for winter) has only 600.

2 Likes

All other date-based, time-based, and weather-based conditional restrictions already use :conditional. It makes no sense to do something completely different for winter conditions.

3 Likes

Overpass, Europe but for 1 instance deep into the Balkans shows maxspeed:seasonal:winter. Almost funny, it was tagged to be sure with

  • maxspeed:seasonal:winter = 70.
  • maxspeed:conditional = 70 @ snow

Belarus shows a half dozen, the 3.7K sort of blanketed across Finland only i.e. the exclusive party which could have a voice. This belongs then to the local community to agree me thinketh.

Just to annoy everybody :-). I would point out that winter isn’t part of the opening hours spec, and if anything you would need an conditional restriction parser (which in turn would need an OH parser if an OH value is present).

2 Likes

It’s interesting that apparently the only projects which have a documented use of maxspeed:conditional are editors (and I’d count StreetComplete as an editor too). Of the routers on osm.org both OSRM and Valhalla have documented their key and tag usage on taginfo.

3 Likes

OSMAnd does seem to support maxspeed:conditional, with month ranges and winter (and possibly also maxspeed:seasonal:winter?)

1 Like

You need an opening hours parser if you want to support all conditional restrictions, including time and date conditions. But there’s nothing to stop you from supporting only some of the types of conditions available with the conditional restriction syntax.

Yes, but maxspeed:conditional as a whole has 68 531 uses, and I don’t see why it makes sense to special-case this one particular flavor of conditional speed limit.

3 Likes

Thank you for the comments so far.

It seems this has not been posted to the tagging mailing list yet and so per the proposal process I am requesting again: Please, cross post this announcement on the tagging mailing list on my behalf by sending an email to: tagging@openstreetmap.org

You can post to the tagging@ list yourself by subscribing to it and sending a mail.

1 Like