Berlin/Verkehrswende/Parkraum/parking:lane-Schema-Update

In 2022 an update to the parking:lane schema was accepted. This page is meant to be an update guide from old to new tags.

This page is WIP, please help making it complete. See also https://github.com/zlant/parking-lanes/issues/93.

TODOs

• Check if parking:lane=no changed in meaning
  • Check Zlant editor
  • Check if current tagging in Neukölln, Berlin matches that meaning
  • parking:lane=no now means there is no physical parking lane. It says nothing about the condition. It's possible to allow parking on a street without a parking lane.
• Check if list is complete
  • Handle maxstay
  • Handle time_interval
  • Handle type of vehicle cases like parking:condition:both:hgv:conditional=free
  • Handle residential permits
• Is parking:condition:<side>:maxstay:conditional something that was possible to express in the old schema? If so, what is the update path?
  • Not really, in most cases :maxstay was used and thought to apply to the :time_interval condition. See my example below.

Helpful links

• Overpass Query showing all ways that use the old ":2" key syntax to create multiple conditions https://overpass-turbo.eu/s/1gPg
• The complex sign examples include some old tagging and new side by side.
• any key that has a "default", or "time_interval" or "vehicles" part anywhere after "parking:condition" https://overpass-turbo.eu/s/1gQ5

General validation rules

• Whenever we see parking:lane:<side>:default, this is the old schema and need to be moved to the new schema
  • TBD: Create a MapRoulette Challenge for this?
    • I don't think MapRoulette would work very well. Tagging parking requires on the ground knowledge or access to local parking regulations in text or illustrated form.
    • Mass-migration of simple tags that are assumed to valid can be done easily with JOSM. I'm willing to assist. /riiga
• …

Upgrade table

Old tag	New Tag	Process
parking:lane:<side>=fire_lane	parking:condition:<side>:reason=fire_lane	Tag can be moved programatically; TBD: how to handle multiple reasons?
parking:lane:<side>=no_parking parking:lane:<side>=no_stopping parking:lane:<side>=no_standing	parking:condition:<side>=no_parking parking:condition:<side>=no_stopping parking:condition:<side>=no_standing	There cannot be more than one value when these are present (you can't both forbid parking while allowing it in the same tag). That value is the default. For any deviations, use conditonal restrictions. These can safely be moved programatically.
parking:condition:<side>:default=free parking:condition:<side>=ticket parking:condition:<side>:time_interval=Mo-Fr 09:00-19:00	parking:condition:<side>=free parking:condition:<side>:conditional=ticket @ (Mo-Fr 09:00-19:00)	Data can be moved in the right order. First move the :time_interval to :conditional, adding the value of the main tag, i.e. "main_tag_value @ time_interval_value". Then move the value of :default to the main tag. :default and :time_interval can then safely be removed.
parking:condition:<side>:default=free parking:condition:<side>=ticket parking:condition:<side>:time_interval=Mo-Fr 08:00-18:00; Sa 08:00-15:00 parking:condition:<side>:maxstay=30 min	parking:condition:<side>=free parking:condition:<side>:conditional=ticket @ (Mo-Fr 08:00-18:00, Sa 08:00-15:00) parking:condition:<side>:maxstay:conditional=30 minutes @ (Mo-Fr 08:00-18:00, Sa 08:00-15:00)	Pay extra attention to the presence of any :maxstay tag which more often than not only was intended to apply to the :time_interval, not the default value. In the new tagging this is much more clearly expressed using :maxstay:conditional with the same time span as the :conditional value. Note: Semi-colons in the time_interval must be changed to commas when there are multiple spans. Also note: The maxstay tag now only accepts values with complete units (minutes, hours), not shorthand forms (min, h).