Quest: Do you need to pay to use this ferry?
General
Affected tag(s) to be modified/added: toll Question asked: Do you need to pay to use this ferry?
Checklist
Checklist for quest suggestions (see guidelines):
- [x] 🚧 To be added tag is established and has a useful purpose
- [x] 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one)
- [x] 🐿️ Easily answerable by any pedestrian from the outside but a survey is necessary Since this quest would only appear at a ferry terminal, most users would already be boarding / unboarding this ferry and thus would know this.
- [ ] 💤 Not an overwhelming percentage of quests have the same answer (No spam) Not sure about this, I believe shorter ones are likely to be more diverse than most ferries. Alot of ferries around where I live are in both categories.
- [x] 🕓 Applies to a reasonable number of map data (Worth the effort)
Ideas for implementation
Element selection:
route=ferry AND fee not set AND toll not set
Since most longer ferry rides tend to require payment, this could be narrowed down by filtering for a minimum length requirement. Maybe around 5 km? Though I am not sure how todo this.
Metadata needed:
Proposed UI:
I believe a simple yes/no should suffice. In contrast to regular tolls, I believe most ferries do not differentiate payment based on what form of transport is using it. Eg. if a car pays then everyone pays. But would be interested if anyone else has examples / knowlege of the contrary.
I believe most ferries do not differentiate payment based on what form of transport is using it. Eg. if a car pays then everyone pays.
I don't think this is always true. For example, the Washington State Ferries Bremerton to Seattle ferry is free for walk-on passengers, but vehicles/drivers must pay (unless they purchased a round-trip ticket in Seattle).
I believe most ferries do not differentiate payment based on what form of transport is using it. Eg. if a car pays then everyone pays.
I don't think this is always true. For example, the Washington State Ferries Bremerton to Seattle ferry is free for walk-on passengers, but vehicles/drivers must pay (unless they purchased a round-trip ticket in Seattle).
Hmm, currently there are no ferries marked with toll:bicycle=no, and only a single one with toll:bicycle=no. Feels very rare, or maybe just not mapped?
Alternatively we could split it up into two quests:
- If toll is not set, and motorcar=yes, then ask "Do you need to pay to use this ferry with a car?"
- No-> Assume pedestrians are also free, and set toll=no
- Yes->Set toll:motorcar =yes
- If foot=yes, toll is not set, and toll:motorcar is not no, ask "o you need to pay to use this ferry as a pedestrian?"
Well, that sounds good to me, but only because when I think about answering these quests I'm thinking about the ferries I'm already used to! 😄
Is there any reason not to go all the way and just ask "who needs to pay to ride this ferry? (select all that apply) [pedestrians], [motor vehicles], [bikes]" or whatever? I get that it would add complexity, but I don't like imprecision...
Is there any reason not to go all the way and just ask "who needs to pay to ride this ferry? (select all that apply) [pedestrians], [motor vehicles], [bikes]" or whatever? I get that it would add complexity, but I don't like imprecision...
I feel like this would be rather spammy, since atleast in my region if one of them pays all pay. So the user would always be selecting all or none. Maybe this instead we could have "yes" "no" and "It depends" and the "It depends" option allows the user to specify more, according to your suggestions?
Maybe this instead we could have "yes" "no" and "It depends" and the "It depends" option allows the user to specify more, according to your suggestions?
Well, that approach would be problematic from quest guidelines standpoint:
- if implemented as a single quest, it would fail "⚛️ Atomic quests: Per quest, only one thing should need to be answered by the user.", as the same quest would be asking two questions, and
- if implemented by original yes/no/depends quest, and a followup quest for "depends" answer (which would avoid the "Atomic quests" issue), then there is a problem what would be tagged for "depends" answer, due to "🤔 No unanswerable quests: [...] This means that any answer given by the user must result in something being tagged"
if implemented as a single quest, it would fail "⚛️ Atomic quests: Per quest, only one thing should need to be answered by the user.", as the same quest would be asking two questions, and
that seems not different than building quest with unrolled building groups
and if rare can be answered with a note
TL;DR: there are less than 50 such complex ferry cases (i.e. fee applies to some, but not others) tagged worldwide currently. And ferries are somewhat rare themselves (compared to e.g. cafes or shops).
Added complexity is IMHO not worth covering them specifically -- just let users leave a note for such cases, unless the answer is "everybody needs to pay" or "it is free for everyone" .
Also, include and !~"fee.*" and !~"toll.*" in elementFilter to skip all such already-mapped complex cases.
that seems not different than building quest with unrolled building groups
Perhaps that might work (if selecting the group itself can be forbidden, which is currently allowed for buildings but unwanted for this)...
But what would be offered in that expanded menu? Ideally, all already tagged access methods would be scanned, and list of answers dynamically created for that. Because, it would be strange that offered answers include e.g. "Only cars have to pay" if the ferry only allows e.g. pedestrians and bicycles.
Also, we'd probably need for it to also have multiselect, otherwise the number of answers could grow prohibitive (e.g. this ferry allows for 6 access tags to board; if we were to ask which require fees without multiselect, we would have to offer 2^6=64 answers, which would IMHO be too prohibitive).
But even for more realistic simpler cases with just 4 transport modes (hgv, motorcar, foot, bicycle), 16 sub-answers might still be too much. And if we offered only some cases (e.g. only foot, bicycle and motorcar), then even those 50-ish cases would be significantly reduced in size (and users would still need to leave a note), making the whole effort questionable.
And then, we have things like this with fee:conditional = no@(age<6; dog) (which might be somewhat common, but with different ages), so not even that fee:foot=yes would be non-ambiguous.
Also, note that out of about 50 ferry routers worldwide which use such more precise tagging, about half of them uses toll:* and half fee:*.
Are 50 elements worldwide enough to satisfy "🕓 Effort vs impact" and justify extra complexity? 🤷 (if so, they should should definitely get "Rare" achievement too).
Added complexity is IMHO not worth covering them specifically -- just let users leave a note for such cases, unless the answer is "everybody needs to pay" or "it is free for everyone" .
Also, include and !~"fee." and !~"toll." in elementFilter to skip all such already-mapped complex cases.
+1, if we will have such quest
TL;DR: there are less than 50 such complex ferry cases (i.e. fee applies to some, but not others) tagged worldwide currently. And ferries are somewhat rare themselves (compared to e.g. cafes or shops).
Added complexity is IMHO not worth covering them specifically -- just let users leave a note for such cases, unless the answer is "everybody needs to pay" or "it is free for everyone" .
Also, include
and !~"fee.*" and !~"toll.*"in elementFilter to skip all such already-mapped complex cases.
Its actually even less than that, since your query includes tags like fee:note, fee:date, toll:amount etc. I manually counted all of them and got this:
- 9 Ferries where certain forms of transport (foot) dont pay while others do
- 5 Ferries where children do not pay, while adults do (different age limits to).
- 1 Ferry where you only need to pay in one direction.
So its even more rare than that. I suspect that in particular the children case is actually a lot more common, but I think that could be another quest for alot of amenities: Is this free for children, and if yes until what age?
there are less than 50 such complex ferry cases (i.e. fee applies to some, but not others) tagged worldwide currently.
I'm not sure I agree with the argument about the rarity of complex fare tagging, simply by nature of it being complex detail that hasn't really been surveyed much. I suspect as well that a lot of the nuance of these fares just isn't tagged currently. However,
ferries are somewhat rare themselves (compared to e.g. cafes or shops)
Absolutely. Thanks for bringing this up. So I suppose it probably does make sense to have a simpler quest after all.
What do you think about having the user choose "yes", "no", or "something else", where "something else" leaves a note instead? This is similar to @paulklie's suggestion above, but instead of this leading to a more complex menu, just starting the add note interface.
there is a problem what would be tagged for "depends" ["something else"] answer, due to "🤔 No unanswerable quests: [...] This means that any answer given by the user must result in something being tagged"
I thought there was an option in most quests that's something like "can't say..." that causes a note to be added and no tagging changed (but maybe it does change tagging somehow??). This is exactly what my proposed "something else" option would do—"it's more complicated, leave a note instead".
I'm not sure I agree with the argument about the rarity of complex fare tagging, simply by nature of it being complex detail
Possibly. But I'm not sure that it helps the case -- if it has been too complex to tag using existing full-fledged editors, then there is even less chance that StreetComplete would be able to tag it properly
What do you think about having the user choose "yes", "no", or "something else", where "something else" leaves a note instead?
I personally would be fine with that, however, I seem to recall it has been suggested (for other quests ideas) before and "having a regular custom answer leaving a note" was rejected in favor of having consistent Uh... / Can't say / Leave note interface instead. Can't find a reference(s) right now, though.
But perhaps if might be acceptable in this specific case, dunno. 🤷
What could be done is to keep the quest the simple Uh.../yes/no type (e.g. __"Does everyone need to pay to board this ferry?"_) but add an infobutton explanation saying something "If some customers need to pay, but others not, please leave a note with detailed information instead".
Another alternative is to do like we already do for selecting ferry allowed transport mode: make multiple yes/no quests. That would allow for collecting much more detail directly, but still allow the user to leave notes about even more complex exceptions.
I.e. have three simple yes/no quests:
- "Are all pedestrians required to pay to use this ferry?" asked only on
foot ~ yes|designated and !fee:foot and !toll:foot - "Are all cyclists required to pay to use this ferry?" asked only on
bicycle ~ yes|designated and !fee:bicycle and !toll:bicycle[^1] - "Are all motor vehicles required to pay to use this ferry?" asked only on
motor_vehicle ~ yes|designated and !fee:motor_vehicle and !toll:motor_vehicle
- Advantages:
- compared to "all or nothing" quest, users are able to add useful (directly usable) data for much more ferry lines
- compared to "have a subquest asking for who must pay if it is not everybody/nobody", it is simpler for users to answer (and easier to implement for quest writer)
- user can still leave a note for more complex cases (while still directly recording information for non complex parts - e.g.
motor_vehicle=yes,bicycle=yes,foot- note "free for age<6")
- Disadvantages:
- 3 quests means more work than 1 quest (much is copy/paste, though). Perhaps it could be made as one quest which does 3 different things? (we already have some quests which change text and answer IIRC). But still, it is more work.
- Not as detailed as "subquest asking for who must pay if it is not everybody/nobody" which could still cover even some (marginally?) more use cases (at a cost of even higher complexity).
[^1]: there a lot of bicycle=* specifically tagged on ferry lines and IME their treatment often differ (i.e. the may count as pedestrian with luggage instead of as a car and get a free treatment, but also can be counted as vehicle or as oversized luggage and require payment)
I.e. have three simple yes/no quests:
* _"Are all **pedestrians** required to pay to use this ferry?"_ asked only on `foot ~ yes|designated and !fee:foot and !toll:foot` * _"Are all **cyclists** required to pay to use this ferry?"_ asked only on `bicycle ~ yes|designated and !fee:bicycle and !toll:bicycle`[1](#user-content-fn-1-56e22828b5dc79a96ede62c66ead94c3) * _"Are all **motor vehicles** required to pay to use this ferry?"_ asked only on `motor_vehicle ~ yes|designated and !fee:motor_vehicle and !toll:motor_vehicle`
If we assume that every ferry that is free for motor_vehicle is also free for pedestrians, we could also ask for motor_vehicle first and skip the others. But with your solution we also ask for ways that already have fee=yes or no set. Seems a bit unneeded in this case?
Btw: I also just noticed that the querry will need to be quite complex since ferry routes can be both ways and Relations made up of ways. We need to ensure that we are not promoting for ways that are part of a ferry relation to avoid asking repeatedly.
If we assume that every ferry that is free for motor_vehicle is also free for pedestrians, we could also ask for motor_vehicle first and skip the others.
- Reasonable assumption. I agree that if it has
toll:motor_vehicle=no or fee:motor_vehicle=no, we could also assume samenovalue for bicycle and foot. - Also, if it has
toll:foot=yes or fee:foot=yes, we can likely assume the sameyesvalue applies to bicycles and motor vehicles too. - (same applies for classes above or below
bicycletoo - ifbicycleis free, so isfoot; and ifbicyclehas fee, so doesmotor_vehicle. Perhaps best ask the bicycle quest first, as it is guaranteed to auto-solve at least one other quest regardless of an answer?)
But with your solution we also ask for ways that already have fee=yes or no set. Seems a bit unneeded in this case?
Well, perhaps, but it is kind of ambiguous (especially when multiple access/transports are explicitly mentioned).
Does fee=yes mean that some have to pay, or that everyone needs to pay? I've seen elsewhere it being used both ways. As the quest would be asked rarely, I'd prefer if it would clear any such ambiguity and tag explicitly.
But yes, alternatively we could skip any ferry which has general toll=* or fee=* set (regardless of what such tag happens to mean exactly). But that is IMHO inferior solution, especially when we already have people on the ground ready to make it explicit. And "little extra verification never hurt anyone".™ 😺
it would have the same problem as https://github.com/streetcomplete/StreetComplete/issues/6373 - right?
On top of the ongoing discussion over splitting this into multiple quests, I think we also need to decide if we tag toll or fee. There has been discussion on this topic before: https://lists.openstreetmap.org/pipermail/tagging/2019-June/thread.html#46121. I originally proposed toll, since it is used (slightly) more than fee for ferries.
See also this newer discussion: https://community.openstreetmap.org/t/toll-yes-or-fee-yes-for-ferry-routes/119341
I'd prefer a fee.
IMHO:
-
tollis charge that is levied for the privilege of using something already existing (like road or a bridge) using just your own transportation method and fuel, i.e. there no extra direct cost for letting you through (but there are long-term road maintenance cost which are paid by that toll). -
feeis however money exchanged for some goods or service; in this case to pay for ferrying service, i.e. there is direct cost of ferry fuel & ferry personnel hourly wages that must be paid or the service can't operate at all (most ferries won't operate without fuel). Your vehicle gets transported by the ferry, it is a passive weight there, and is not moving on its own power as in road/bridge toll case.
Now, if there was ferry which does not consume fuel and does not have crew (something like this one?) then it might be more appropriate to use toll there instead of fee; but in vast majority of cases I'd go with fee.
And in any case, fee looks more generic to me (i.e. every toll is kind of a fee, but not all fees are tolls), so it should be safer to use. Also fee makes more sense to me for pedestrian-only ferries, or tourist ferry routes.
Here in Washington ferry routes can be part of a designated highway. For example, highway WA 305.
I think toll usually makes more sense, though I agree that some very infrequent or long-distance ferries could be counted as a fee.
Something brought up in the discussion linked above is how usually with ferries you just show up and pay, and rarely do you purchase a spot in advance. That might be another factor.
I agree that it should be several quests.
About the order, how about first ask "Is there any fee for anyone to use this ferry?"? It then tags fee=yes/no. If fee=yes, the other quests are asked, depending on which kind of passengers are allowed.
About the order, how about first ask "Is there any fee for anyone to use this ferry?"?
I agree that this is the best order, since most ferries are free for babies, and thus asking the opposite ("is it free for anyone?") would be rather useless.
I have created a flowchart to show in what way I would suggest asking quests for a ferry without any fee:tags:
I have created a flowchart to show
Great idea!
Unfortunately, I find it somewhat confusing, as it does not seem to use standard flowchart marking?[^1]
I.e. it adds additional decisions inside the flowlines (arrowheads) (e.g. "if foot=yes", "if bicycle=yes") instead of using additional diamond(rhombus) as would be standard to indicate additional decision branch, so it is unclear what happens at those places if condition inside flowline is not met?
E.g. What happens if "foot=no" or "foot=* is not tagged" after that "Tag fee=yes" in second row? Does the quest end there if foot=* is not tagged at all (which happens in some 64% of all cases)? Or does it branch somewhere else?
[^1]: I would guess there should be plenty of online tools to quickly produce standard flowcharts?
I.e. it adds additional decisions inside the flowlines (arrowheads) (e.g. "if foot=yes", "if bicycle=yes") instead of using additional diamond(rhombus) as would be standard to indicate additional decision branch, so it is unclear what happens at those places if condition inside flowline is not met? E.g. What happens if "foot=no" or "foot=* is not tagged" after that "Tag fee=yes" in second row? Does the quest end there if
foot=*is not tagged at all (which happens in some64%of all cases)? Or does it branch somewhere else?
Aye, I left those out to make it a bit more concise. If the condition is not met no further quests are asked and the flow terminates. I sadly accidentally wiped my browser cache and thus cant easily modify it anymore (created with draw.io).
https://github.com/commons-app/apps-android-commons/blob/7d96e9468983d3d482c341208b8e0836feca09ff/app/src/main/res/values/strings.xml#L95
So, (for example) if ferry route is tagged only with route=ferry and name=* (likely most common case), and the user answers "yes" to "Is there any fee for anyone to use this ferry?", the intention is to only tag fee=yes and ignore all the rest of the flow (i.e. skip asking who should pay)?
So, (for example) if ferry route is tagged only with
route=ferryandname=*(likely most common case), and the user answers "yes" to "Is there any fee for anyone to use this ferry?", the intention is to only tagfee=yesand ignore all the rest of the flow (i.e. skip asking who should pay)?
Well then the user would also be asked if passengers/ bikes / cars can use the ferry via their respective quests. Afterwards they would then also be asked about more fees,
Well then the user would also be asked if passengers/ bikes / cars can use the ferry via their respective quests.
Ah, yes. Given https://github.com/streetcomplete/StreetComplete/issues/6509 gets implemented, than that particular part would make sense. However,
Afterwards they would then also be asked about more fees,
Hmmm... I'm not sure it would? If that "tag fee=yes" happens on the first run and the quest terminates there, and then say bicycle=yes tag gets added by new (#6509) quest after that, it would seem to me that subsequent runs of this quest would fail initial "no fee or toll set", so it would never be asked again (and thus fee:bicycle=* would never get tagged by SC in such case)? Or am I misunderstanding how it is supposed to work?
-
Is this flowchart supposed to be a single quest (which happens to ask sub-questions, borderlining quest guideline "⚛️ Atomic quests: Per quest, only one thing should need to be answered by the user")?
-
Or is each diamond supposed to be a separate quest not directly corresponding to previous user decision, and instead only dependent on initial tags (which may not even come from SC user). If that is the case, it would IMHO be better to draw them as separate flows? (At least it is not understandable to me how it should work 😿)
- Or is each diamond supposed to be a separate quest not directly corresponding to previous user decision, and instead only dependent on initial tags (which may not even come from SC user). If that is the case, it would IMHO be better to draw them as separate flows? (At least it is not understandable to me how it should work 😿)
Aye, separate quests, see https://github.com/streetcomplete/StreetComplete/issues/6333#issuecomment-3348775861
Separate flows might be more correct, however I wanted to show the order of quests that a typical user would get when asked about ferries without any fee information. I believe one flow for each would make this a bit had to read.
BTW, GitHub supports Mermaid diagrams
example Mermaid diagram
so one can embed directly stuff like:
flowchart TD
START(Quest eligibility) --> ELIGIBLE{Is any `fee:*=*` or `toll:*=*` set?}
ELIGIBLE --> |Yes| IGNORE(ignore quest)
ELIGIBLE --> |No| S(start quest) --> ANYFEE{Ask: Is there any fee for anyone to use this ferry?}
ANYFEE -->|Yes| ANYYES[Tag `fee=yes`]
ANYFEE -->|No| ANYNO[Tag `fee=no`] --> END(end quest)
which shows
flowchart TD
START(Quest eligibility) --> ELIGIBLE{Is any `fee:*=*` or `toll:*=*` set?}
ELIGIBLE --> |Yes| IGNORE(ignore quest)
ELIGIBLE --> |No| S(start quest) --> ANYFEE{Ask: Is there any fee for anyone to use this ferry?}
ANYFEE -->|Yes| ANYYES[Tag `fee=yes`]
ANYFEE -->|No| ANYNO[Tag `fee=no`] --> END(end quest)
Aye, separate quests
OK so implementing this issue would create 3 quests like this (by default ordering asked from top quest to bottom quest)?
flowchart LR
START1(Quest1) --> ELIGIBLE1{Tags: Is any `fee=*` or `toll=*` or `fee:*=*` or `toll:*=*` set?}
ELIGIBLE1 --> |Yes| IGNORE1(ignore Quest1)
ELIGIBLE1 --> |No| S1(start quest) --> ANYFEE1{Ask: Is there any fee for anyone to use this ferry?}
ANYFEE1 -->|Yes| ANYYES1[Tag `fee=yes`] --> END1
ANYFEE1 -->|No| ANYNO1[Tag `fee=no`] --> END1(end Quest1)
START2(Quest2) --> ELIGIBLE2{Tags:`fee=yes` and `foot=yes` and no `fee:foot`?}
ELIGIBLE2 --> |No| IGNORE2(ignore Quest2)
ELIGIBLE2 --> |Yes| S2(start quest) --> ANYFEE2{Ask: Do pedestrians need to use this ferry?}
ANYFEE2 -->|Yes| ANYYES2[Tag `fee:foot=yes`] --> END2
ANYFEE2 -->|No| ANYNO2[Tag `fee:foot=no`] --> END2(end Quest2)
START3(Quest3) --> ELIGIBLE3{Tags:`fee=yes` and `bicycle=yes` and no `fee:bicycle`?}
ELIGIBLE3 --> |No| IGNORE3(ignore Quest3)
ELIGIBLE3 --> |Yes| S3(start quest) --> ANYFEE3{Ask: Do you need to pay to bring bicycle on this ferry?}
ANYFEE3 -->|Yes| ANYYES3[Tag `fee:bicycle=yes`] --> END3
ANYFEE3 -->|No| ANYNO3[Tag `fee:bicycle=no`] --> END3(end Quest3)
(and addition of #6509 for bicycles, with two existing quests for pedestrians/motor vehicles, would make it complete). That seems good to me!
Update: fixed inverted Yes/No in first diamond for Q2/Q3 😅