Minimum viable tagging for conditional parking lanes

There is road with parking lanes which allows parking and you need to buy a ticket

  • only for parking from 10:00 to 20:00 (parking is free after 20:00 and before 10:00)
  • except weekends (it is free)

Is it fine to tag it parking:condition:both=ticket?

Or is it better to leave it empty and not tagged. And only allowed solution is to tag it fully? (full tagging would be parking:condition:both=ticket parking:condition:both:conditional=free @ (Su, Mo-Fr 20:00-10:00) )

(Asking this question due to designing support for this in editor and I am considering what is the minimum viable plan for supporting tagging that would be both usable and acceptable)

2 Likes

Could the editor offer a checkbox and freeform text field for times when it’s free as an exception? Then it could tag something like parking:condition:both:conditional=free @ "weekdays 8 PM to 10 AM and Sundays" using the comment syntax from the opening hours syntax. I would hope that local mappers would appreciate that it avoids dataloss, even if it requires some polishing to become machine-readable.

2 Likes

Systematic leaving data in a wrong format and requesting cleanup seems a bad choice.

I would prefer no such quest at all or implementing full support over such solution.

Hey @Mateusz_Konieczny , you are maybe asking in context of implementing a UI for StreetComplete?`

Did you notice the new interface for the AddParkingFeeForm quest, in particular when selecting “No, but there is a max duration…”? Try it out. Since I knew you may eventually work on this, I made this UI be easily reusable, see TimeRestrictionSelectViewController. Also see DurationInputViewController.

1 Like

I made a mockup how a UI that could handle quite a lot of complexity (all that the tagging scheme allows?) could look like:

3 Likes

Yes, that is triggered by SC quest.

Large part of my reason is that people are unaware about all rules applying to paid parking.

I myself have not noticed that Saturdays are now paid in my city. Some people were unaware about some exceptions or remembered it badly. Some mentioned that they simply mark how long car will stay and app/vending machine handles time based exceptions.

Exact timing when parking is paid is not signed (or signed really poorly).

(all of that is from my city and small sample of people)

I’d say a simple parking:condition:both=ticket might be enough in some cases, especially if the user can’t find the details. And usually data users know that “around here” it’s free at lunch time and at night, or something, and it’s not really for a fee around the clock.

But it would really useful to be able to fill out the precise details when on survey. A kind of incremental accuracy

So to answer your original question, the best IMHO would be to propose both. A kind of “I’m not sure” answer, and a detailed one.

In terms of a UI, start with the assumption that lane has 24hr free parking. Then let the user add payment options such as fee, permitted, etc. Allow user to add conditions based on each payment type to further refine when and how they are being enforced. Time/date validation can happen as they are selected. For example; you can check that free and paid parking don’t occur at the same time. It also allows for simple inclusion of no parking periods stemming from additional signs.

1 Like