v47.0-alpha1 Pre-release Feedback

[tordans]

Thanks for adding the parking overlay, @westnordost! It will be a huge help with our project to collect and process parking data.

I looked at the preview today and have a few remarks.

Based on my experience with training new mappers to map parking data for our project in Berlin and based on my background in UX design I expect users to have a few issues with the current design:

• I expect users to have trouble to understand which elements of the UI are interactive vs. "context".
• I expect users to have trouble to "translate" the colors of the visualized data.
• I expect users to have trouble easily seeing where action is needed.

This might look like a lot … but on the other hand the new overlays are super new and the parking overlay is way more complex than those before (and even those have not been around long). And also, the overlays are a very different UI that has not been optimized compared to the other parts of the app. — Meaning: Let's take the time to improve those overlays for (new) users and optimize them to be on point in what each wants to achieve.

The biggest question for the parking overlay is IMO, what it's core is. In my opinion, it should be about "collect parking info where none is given, yet". Or, as a question: "is the tagging fully | partially | not present?"

The challenge is "lets collect complete data on parking in our neighbourhood".

Based on this, I suggest to change the legend and color schema of the overlay:

• black: no parking data present
• green: parking data present (incl. "separate")
• yellow: some parking data present but some data missing

(Color names are picked to make writing and reading easy; the actual colors should be picked based other constraints.)

A variation of that – which still would be a lot less data that the current preview – would to explicitly show no parking:

• black: no parking data present
• red: parking data present, no parking (all kinds)
• green: parking data present, parking allowed (incl. "separate")
• yellow: some parking data present but some data missing

The current visualization tells a different story. It give information about attributes of the parking data. And with this, it tries to tell me to validate the existing given data, mainly where the car is parked (on the road, half on curb, …). See legend at #4329 (comment).

My take is, that this is (a) not the best goal for the overlay (validation vs. completeness) and (b) makes the overlay a lot more complex that it needs to be. The last part is exacerbated by the fact that the overlays do not have a legend (yet).

---

Add a legend

I know you decided against a legend in the initial release for good reasons. However, I do think the UI needs one. On the one hand for the line-colors, but also for additions like the choker. For the choker, the legend should probably also explain what a choker means for mapping parking lanes: Something like the recommendation to not split the lines there, but rely on post processing to remove the parking spots of the choker.

---

Highlighting

Right now, selecting a road segments highlights the road, but the parking part does not change. If possible, it would make the UI clearer to also highlight those parts since they are part of what one interacts … and part of the data that is change.

---

Line ending

For densely mapped areas like Neukölln the fact that the highway line ends in a rounded corner but the parking segment ends in not-rounded corner creates some unclarity. Could the highway also end in a not-rounded corner?

---

Dashed lines

I suggest to remove the concept of dashed lines for the parking overlay. They cause edge cases:

• They suggest something like parking spot that are mapped separately. Less experienced users will have a hard time seeing the difference in the blue rectangles vs. the black once…
• They work badly in small highway segments where.

---

Streamline look of separately mapped areas

Right now, those have a border and fill. The parking visualization next to a highway only has a fill (or thick border). But both are part of the "data layer" (in the sense of a background layer, highway layer for interaction, data layer for showing the data). Ideally all data layer elements would look more similar than ATM.

---

Show separately mapped areas in editor

Is there maybe a way to pick up the color or shape of the separetely mapped area in the editor view? I don't see an easy solution, but it would help explain the UI a lot, if the blue shape could appear below or at least the color could be picked up. Maybe only change the --> Icon from Orange to the Blue of that area?

---

Reduce color

Following the train of thought about how to better separate the different layer (background layer, highway layer for interaction, data layer for showing the data), one thing could be to reduce the overall colorfulness of the different UI parts.

• Reduce the color of the background layer (see comment)
• use just one icon and color for cars; the fact that they are different and different color does not help in understanding the meaning but is visual noise

[westnordost]

Edit: First of all, thank you for the feedback! Some things could be done, some others are deliberate or cannot be changed. In detail, see below

General remarks

Purpose of overlays

Explicitly the purpose of any overlay is to complete and maintain the data. The latter, by having a handy visualization of as what it is tagged now.

So, you could say that each overlay has a dual purpose. But on the other hand, even the guy who just wants to complete the map data has an interest in correcting it if he notices it is wrong.

If I reduced the color palette to essentially "tagged or not tagged", I would pretty much take away from the user the second use case while keeping it that colorful will only be an inconvenience to those just wanting to complete the data without wanting to confirm whether the data already present is correct. Once you (the user) know, that red in any overlay means "missing/incomplete/invalid data", the other colors should not be a big distraction.
The same applies for any other (future) overlays like the cycleway overlay.

Specific to the parking overlay is additionally that experience in mapping these showed that it is quite subjective in some cases whether a parking situation should be tagged as A) "parking off the roadway in designated spaces" (street_side) or B) "on the road" + "there are some/many chokers".
However it is mapped, it is important that it is mapped consistently alongside at least one street. So if the start of a street has been mapped like A, the rest should too (or the previous one corrected to be B). For this reason, chokers and the roadway width are being displayed and for this reason, it should be easily visible on the map how the other section of road has been mapped.

This is why I do not plan to change the coloring.

Colors

The reserved color palette that is the same for all overlays is:

• #D00055 (red/pink): "missing/invalid/incomplete/out of date"
• #444444 (black/grey): "no"
• transparent: "mapped separately"

For each, there is a good reason and it is important that this is consistent amongst all overlays.

Why not differentiate between incomplete and missing?

It is not relevant for the surveyor whether an information is merely incomplete or missing completely. In any case, he should re-survey it. The same applies for when it is out of date.
The quest and overlay forms also usually do not even show incomplete data as present at all.

Why not "black" for missing data?

Red is often used in other UIs (and real life) for errors and such. Pink is often used as a placeholder color in at least graphics design context. In any case, these are colors meant to stand out and be somewhat vexing, wanting you to fix it.
If there is simply no parking, no cycleway, no parking, it should not look as if it necessitates an action.

Though, I recently made the red/pink darker for better distinction to other colors (for red-green color-blind), but this takes away the "vexing" effect a bit. I'll see what I can do without fucking it up for color-blind people.
(By the way, you mention "red" for "no", "green" for "yes". There can not be a red and green in the color palette for this reason.)

Why is "seperate" invisible?

In order to not occlude the separately mapped data highlighted as separate geometry.

Replies to specific feedback

Add a legend

I guess this could be done, at least by color. A PR is welcome, however it should not be too effortful for the overlay author to create one. I.e. he should not have to write a custom UI for that. A legend definition could e.g. look like this (kind of pseudo code):

override fun getLegend(): List<Pair<Color, Text>> = listOf(
    Color.RED -> "missing data"
    Color.BLUE -> "parking off roadway"
    // ...etc
)

Highlighting
Line Endings
Show separately mapped areas in editor [...] (Maybe only change the --> Icon from Orange to the Blue of that area?)

Technically not possible.
To change the arrow color in the form would be inconsistent with the separate" arrow icons shown in other UIs within StreetComplete. I find it more important to be consistent here than to match the arrow color with the color of the separately mapped parkings.

Dashed lines

True, for very very short sections (I mean, you can zoom in), this is a problem. But on the other hand, these are so short that it hardly matters whether it is e.g. "on roadway in marked spaces" or "on roadway" because this will be just 1-2 parking spaces or so.

However, I see that I am kind of misusing the dashed-style for "no parking without further reason supplied". For the other colors, the dashed style depicts that there is some parking, but not along the whole length. For "no parking", it carries a completely different meaning. I will remove that.

Streamline look of separately mapped areas

The separately mapped parking areas have exactly the same color as when the user selected "parking off roadway" or "parking off roadway in designated spaces" (street_side) except that it has a slight border. That areas have this slight border is the same for all overlays and I'd argue that it helps the user distinguish the cases whether it was mapped separately or mapped on the road.

Reduce color

A PR is welcome for desaturating (to 100%?) the background map while an overlay is active. Otherwise, I might get to it in the frame of the cycleway overlay.

Regarding the colors of the cars:

It's true that it does not carry meaning. These were my thoughts when adding different colors:

• StreetComplete should follow its reputation to be playful, different-looking and -colored cars does just that. (Initially I thought about adding animations about cars parking in and out but quickly disregarded that for being to effortful). For the parking lane quest for example, there are also cars driving along the lanes, in different colors. (Except on the first of April)

• The key meaning of the visualizations lie not in the color or shape of the cars, but in their positional placement. Hence, I'd argue that the color and shape of the cars do not really matter as long as the positional placement is communicated clearly

• When selecting a (new) value, the user is presented just with red cars for clarity, what you comment on here is just the "WYSIWYG" view

Overall, I do not have a very strong opinion about this but I do prefer to keep the different colors and shapes as eye candy. Let's see if/how much other users will be confused by this.

[westnordost]

I made the red #FF0000 red again (on my phone, it looks a bit more intense than when I make a screenshot of it, no idea why):

See the color palette now: https://davidmathlogic.com/colorblind/#%23444444-%23FF0000-%231A87E6-%232FACE8-%2330D4EE-%2310C1B8-%230DA082-%23F37D1E-%23EEBD0D-%23B6EF28

[joshinils]

There is no distinction between non-downloaded (parking-) data and ways which are tagged as separately mapped parking (where the separately mapped parking may or may not exist, even if that may be in error).

I wondered, but for quests it indeed makes no sense to show the boundary of the downloaded area like JOSM does with the hatched background, one can always scan for quests again, and again.
But for overlays data is shown for ways which are downloaded only, and all ways are always shown simply by looking at the map, so there is no distinction between a downloaded and a missing way.
Whereas a "rectangle of dots" representing unsolved quests means I have scanned for quests there.

To test the parking-overlay, I created a quest-preset containing no quests as to not interfere with selecting road segments (which also could be shown where the ways are split, before selecting a way).

I noticed this because when scrolling away from downloaded parking-overlay data the streets look like they are tagged with the transparent-looking parking=separate, where in reality I have just not downloaded the data yet.
Also, downloading overlay data via scanning for quests seems a bit weird in hindsight I feel, since the overlays are not quests.

I think a mode which disables all quests when an overlay is enabled could work well for this, especially in areas where there are an overwhelming amount of unsolved quests.

[peternewman]

How did you install it @tordans ? Some pseudo-feedback from me is Google Play is only offering v46.1 currently despite being in the beta. I don't know if it's still being checked/approved or whether they just offer the latest release not the highest version number...

[tordans]

@peternewman I installed the .apk from https://github.com/streetcomplete/StreetComplete/releases/tag/v47.0-alpha1 manually to provide some early feedback.

[joshinils]

there exist traffic signs for the types of colors discussed. maybe a sign on the map can be used additionally to the colors?
meaning a small icon in the middle of the color to the side of a way.
the signs should be understood anyway, otherwise i would not know how to map correctly.
drawback could be that too many of them clutter up the map. maybe only show signs when zooming in far enough.

[joshinils]

(since this is the only post i will put my thoughts to the alpha here too)

when splitting a way, I would like more context.
If trees, kerbs, bollards etc. exist in OSM, could they be displayed? Even when it is only while splitting.
That would make it easier to split a road in the correct place instead of guessing compared to houses as the only reference in the map.

---

I noticed some variations which I could not map explicitly as what they are;

• a single disabled parking spot marked on the roadway
• "no stopping" with time limits and only on certain weekdays.
• taxi ranks (though i think there is no explicit tagging for those?)
• bus stops, 15m infront and 15m after the position of the sign
  • bus stop signs are not show as context in SC
  • also in germany the required 5m (or 8m if there is a cycletrack up a kerb, infront of an intersection) from the kerb-intersection could be somehow not rendered?
• Boundary marker (Zeichen 299; Sperrfläche) without the bus stop:
• narrow streets where it is not legally possible to park on both sides at the same time, but it is legal to park on either side.
  • parking:condition:either_side_only=yes
• a bike lane
  • fahrradschutzstreifen (durchbrochener schmalstrich)
  • radfahrstreifen (durchgezogener breitstrich und zeichen 237)
  • Which logically could be derived from a cycle lane existing in OSM data, and then ask about them existing and implying a "no parking" tagging there.
• no parking because this segment is inside an intersection
• no parking because it is the inner (left) side of a split (i.e. kerb and fence) road and not a one-way street.

Those only pertain to restrictions in parking, however when parking is allowed, something like a disc being required, or only certain types of vehicles may park somewhere is currently not possible to map.

so for example a zone with a disc requirement and time limits and certain weekdays is not possible to map right now, and then inside that a section where other limits apply and only cars may park, etc.

I am looking forward to future improvements, and this version works well for what it can do now!

[westnordost]

Regarding "no stopping" with time limits, disc parking and similar:

There is actually such a selection available. Select "No parking here / Not allowed", then in the next dialog select "Parking / Stopping restricted conditionally". This pops up a dialog that tells you:

If it is possible to park or stop at all here, indicate the type of on- or off-street parking. Additional restrictions can be specified later.

Alternatively, you can leave a note (with a photo).

Regarding areas where parking is prohibited implicitly:

I.e. before and after bus stops, intersections, roundabouts, turn lanes, around rail crossings, at driveway entrances etc etc.

It is not necessary to split the way to specifically exclude these areas from the usual parking lanes. Any proper application that wants to display or calculate the street parking capacity in detail has to in any case cut out those sections of the road from the "parkable" area. Hence, micromapping this is not necessary and will only lead to more effort tagging it and maintaining it.
(After all, for example, we also do not tag cycleway=no for the section of a continuous cycle lane that crosses an intersection only because all markings - inclusive car lane markings - stop on the intersection area).

And with "proper application", I actually mean the very application that @tordans, @SupaplexOSM and Lars Ligner are working on right now, which will be the first OSM based application that consumes the street parking data in (such) detail and will be open source.

Anyway, if the way is already split up on those section of the road where there is implicitly no parking, you might as well answer it micro-mapped in detail in that case and you would simply answer "No parking here / Not allowed" -> "No explicit sign / parking not possible" then

[joshinils]

Additional restrictions can be specified later.

I guess this will do, SC set the section as
parking:lane:right=parallel
parking:lane:right:parallel=on_street

so the following conditional restriction is missing now;
parking:condition:right=free
parking:condition:right:conditional=no_parking @ (Mo-Sa 07:00-10:00)
https://www.openstreetmap.org/note/3351812

I don't know if I interpreted the tagging correctly.
I also am not sure if I used the overlay correctly in this situation.

In any event, this popup message with "indicate the type of on- or off-street parking. Additional restrictions can be specified later." confused me.
The notice did not let me choose anything when it was open, and I might have selected the opposite of what is required for the correct tagging.
And the ok-button did nothing, and there seems to be no change to the tagging.
There also was no popup asking me to open a note then and there, I created the above note on my own.

[joshinils]

Regarding areas where parking is prohibited implicitly:
I.e. before and after bus stops, intersections, roundabouts, turn lanes, around rail crossings, at driveway entrances etc etc.

No one should split a way right before an intersection, if 2m after the kerb there is a sign prohibiting parking, when legally you may not park 5m from the kerb-intersection point.
But what I want to make sure is that no one gets the idea that they should do that.
Only if signage changes mid-way through a street, for example, should a way be split since there is a need for it.

But bus stops are legally a 30m strip of no_parking, for which someone might get the idea that they need to split a way to reflect that somehow.
For that reason, I think bus stops should somehow be visible in the parking-overlay, with the 15m-radius buffer applied.
Then logically this overrides any allowed parking in that segment.
And if the no parking is extended beyond the 15m then micro-mapping is needed anyway.
(all of this assumes accurate mapping of bus stop signs, and accompanying bus stop platforms, which I have seen wrong)

Turn lanes are a different reason, they may be short or not. Only if arrows are painted on the road exists a "no parking" ban.
Where this starts can be micro-mapped by splitting the way.

Actual roundabouts (opposed to implicit ones via one-way signs or turn restrictions and give-way signs) could just not be selectable, they look weird if they are too small anyway.
Currently, I can set parking data on roundabouts.

The same goes for actual one-way streets with a sign (thus permitting parking on the left-hand side) compared to split-roads for purposes of mapping a median and tagging oneway=yes which to my understanding only influences routing and does not represent the existence of a traffic sign.
There seems to be no distinction between a legal one-way and a routable one-way road in OSM 🤷‍♂️ .

[wielandb]

In any event, this popup message with "indicate the type of on- or off-street parking. Additional restrictions can be specified later." confused me. The notice did not let me choose anything when it was open, and I might have selected the opposite of what is required for the correct tagging. And the ok-button did nothing, and there seems to be no change to the tagging. There also was no popup asking me to open a note then and there, I created the above note on my own.

Maybe I can clear up the confusion a bit. The "Additional restrictions can be specified later." is in reference to a quest that is not implemented yet. (@matkoniecz is working on it) It means, you can choose now how parking is done here in priciple, and after you've done that a quest will pop up saying "okay, this on-street parralel parking that is tagged here, is it free for everyone (or just at times? only for residents? only with a ticket?)"

I think actually the old translation/string made it more clear, so maybe it could be changed back?

In the "old versions" (where street parking was implemented as a quest but you had to compile it yourself to test it), the string when you clicked on the sign with the asterisk said (in german)
"Wenn es überhaupt möglich ist, hier zu parken oder zu halten, beantworte zunächst, wie diejenigen, die es dürfen, hier parken. Welche Einschränkungen genau gelten, kann später hinzugefügt werden."
So, translated:
If it is at all possible to park or stop here, please answer how those who might park here can do so. Which restrictions apply exactly can be specified later.

Now, the string just says: If [...] please indicate the type of on- or off-street parking

I think the part that translates to "please first state how those allowed to park here do so" was helping with clarification, would you agree?

[bgo-eiu]

I think the taxi key can be used the same way as the bus key is for bus lanes, there are examples of people mapping taxi ranks like this on taginfo.

[deevroman]

Also a few comments:

1. In night mode, it is much more difficult for me to understand which section of the road is allocated.

Examples

2. Plus hints when cutting objects. Bus stops are a useful landmark.

3. It is impossible to solve the quest, only for one side of the road. This would be useful for multi-lane roads, because the restrictions can vary greatly, and they are visible only if you go in the opposite direction. I start from the length of the plot, ending with the type of restriction.

[joshinils]

I noticed all three myself. Especially no_parking with its almost black colour is most difficult to see against the dark blue background

[HolgerJeromin]

ref #4417

[bgo-eiu]

The bus stop point is a good one. Where I live the parking conditions are very strongly related to the bus system, and the most common place to split a way would be around a bus stop. (Officially in the United States at least, bus stop signs themselves are classed as a type of parking sign as well.)