Add a maxspeed overlay

[letypequividelespoubelles]

Use case IMHO it would be a very usefull overlay, as maxspeed isn't a resurveyable quest, and not so easy to map and correct (no opendata for it in France, no easy editors to do it in situ).

Proposed Solution As UX, I might proposed that highway are in a specific color (red ?) if there are no maxspeed tag. If a mawspeed is already tagged, put a sign (in a form of a traffic sign) to tell what's already tagged :

• speed limit value in a circle in case of maxspeed=* tag
• speed limit value in a square in case of a zone:mawspeed=* tag
• a city icon in case of a maxspeed=XX:urban tag
• a strikethrought city icon in case of a maxspeed=XX:rural

When clicking on a highway to add/modify the speed limit, the same UX as for the maxspeed quest would be perfect.

Thanks !

[westnordost]

Regarding the coloring, I've been doing some research and thinking about which maxspeed values could/should be grouped together. Though, the color suggestions are probably not color-blind-friendly.

% of maxspeed values	maxspeed value	suggested color
1%	130	violet
1%	120	blue
1%	110	blue
3%	100	teal
3%	90	teal
6%	80	green
5%	70	green
8%	60	chartreuse
27%	50	yellow
9%	40	yellow
22%	30	amber
3%	20	orange
1%	10	orange

[riQQ]

Here's the table with the colors visualized with example values:

% of maxspeed values	maxspeed value	suggested color	color code
1%	130	violet	#ee82ee
1%	120	blue	#0000ff
1%	110	blue	#0000ff
3%	100	teal	#008080
3%	90	teal	#008080
6%	80	green	#008000
5%	70	green	#008000
8%	60	chartreuse	#7fff00
27%	50	yellow	#ffff00
9%	40	yellow	#ffff00
22%	30	amber	#ffbf00
3%	20	orange	#ffa500
1%	10	orange	#ffa500

Click for markdown

| % of maxspeed values | maxspeed value | suggested color | color code |
| -------- | ---------- | ------------ | ---- |
| 1% 	| 130 | violet | `#ee82ee` |
| 1%  | 120 | blue | `#0000ff` |
| 1%  | 110 | blue | `#0000ff` |
| 3%  | 100 | teal | `#008080` |
| 3%  | 90  | teal | `#008080` |
| 6%  | 80  | green | `#008000` |
| 5%  | 70  | green | `#008000` |
| 8%  | 60  | chartreuse | `#7fff00` |
| 27% | 50  | yellow | `#ffff00` |
| 9%  | 40  | yellow | `#ffff00` |
| 22% | 30  | amber | `#ffbf00` |
| 3%  | 20  | orange | `#ffa500` |
| 1%  | 10  | orange | `#ffa500` |

[westnordost]

Though, the overlay needs to handle situations where both the maxspeed and the implict maxspeed road type is tagged, too. And maybe other less common situations.

[letypequividelespoubelles]

How is it possible ? You can't have for exemple maxspeed=FR:urban and maxspeed=50 on the same way, if yes it's a mistake ! Do you have any possible right tagging scheme where this might happen ?

[westnordost]

But you can have maxspeed:type=FR:urban and maxspeed=50 on the same way.

[matkoniecz]

Though, the overlay needs to handle situations where both the maxspeed and the implict maxspeed road type is tagged, too. And maybe other less common situations.

In case of matching ones it can be ignored, and in case of mismatches I think it would go to "I give up" class.

But that would require maintaining list of expected maxspeed values...

[westnordost]

The colors above are obsolete because there'd need to be a different color palette anyway (that is color-blind friendly)

[joshinils]

This should also tag the source, e.g. a zone vs a plain sign. Examples include: source:maxspeed=DE:zone30, maxspeed=30 + maxspeed:type=sign, maxspeed:type=DE:zone30, source:maxspeed=DE:bicycle_road, zone:maxspeed=DE:30 , traffic_sign=DE:274.1, traffic_sign=DE:274-30, traffic_sign=DE:244.1, traffic_sign=DE:244.3

and which of these are mutually exclusive...

what about tagging maxspeed as walk? for example where traffic_sign=DE:239,1022-10 implies cycling at walking pace (i.e. maxspeed:bicycle=walk) or highway=living_street in germany too.

[matkoniecz]

The highest complexity would be likely for cases where speed limits depends on way direction.

Or https://taginfo.openstreetmap.org/keys/maxspeed%3Aforward#overview https://taginfo.openstreetmap.org/keys/maxspeed%3Abackward#overview is edge case that can be ignored?

[tszym]

Even considering that as edge case to ignore for a first implementation, the overlay would bring a lot of help to mappers already. Eventually it could be nice to handle direction dependent speed limits, maybe with an UI similar to the one for the sidewalks overlay (maybe hidden behind a "other answers" button).

I believe the implementation of that overlay should not be blocked by discussions over trying to nail the perfect feature covering all cases right from the beginning, as from a user perspective, it feels like that overlay would help a lot even with basic features, while more improvements are developed later. Max speeds are a complex issue, especially since it is country dependent, so it could even be first developed behind a regional feature flag, like some quests that are never displayed for some countries.

[arrival-spring]

Colours seem to be the tricky thing here, as there are lots of possible maxspeed values and, at the moment, only 9 colours in the overlay palette.

The JOSM maxspeed style has this:

Colourblind comparison of these colours

[RubenKelevra]

@westnordost wrote:

But you can have maxspeed:type=FR:urban and maxspeed=50 on the same way.

That's why I prefer to not spread the same information to two tags.

The OSM wiki got a machine readable list of the implicit maxspeed=* values. So StreetComplete could compare the explicit value of the maxspeed tag to what's tagged in the depricated source:maxspeed / maxspeed:type Tags.

If there's a missmatch the road can be rendered with red as an error (without the overlay SC could show a quest for maxspeed here).

Then both options can be shown to the user to decide which one is correct and the tags can be cleaned up by either tagging maxspeed=50 (and maxspeed:type=sign if you think that's necessary) or maxspeed=FR:urban.

With a third button the user could respond that both is wrong and default back to the regular maxspeed questionare.

StreetComplete could do the same for resurveying, so the tags are slowly fixed if surveyed by users.

[RubenKelevra]

@arrival-spring wrote:

Colours seem to be the tricky thing here, as there are lots of possible maxspeed values and, at the moment, only 9 colours in the overlay palette.

The JOSM maxspeed style has this:

Colourblind comparison of these colours

I think the color scheme of JOSM is pretty suboptimal, as it includes different shades of red which is currently used to show missing information.

Maxspeed zones are also missing from that list... so there are additional visual cues or colors necessary for this...

I got a different idea:

How about using solid green for xx:urban, solid amber for xx:rural and solid orange for xx:motorway.

For explicit numbers the path gets rendered as zebra with black.

So e.g. for Germany:

• DE:urban = green
• 50 = zebra green
• DE:rural = amber
• 100 = zebra amber

For numbers different than these the colors are mixed, depending on the distance - so 70 gets a 20:30 mix of green and amber.

To have colors to mix numbers below xx:urban is defined for 0 and violet is defined for 150 (and none) to allow for numbers greater than xx:motorway.

If there's a zone, the secondary color for the zebra could be changed to white.

This way we don't have to worry about mph values, as the color scheme just adopts to the local defaults and mixes from there.

It also gives some visual feedback if a speedlimit has increased or decreased by a 'severity' type color mixing - which works better visually IMHO than random colors schemes used in JOSM.

Btw: Color blindness shouldn't really be a consideration here, as Android supports color correction for the different types:

[joshinils]

depricated source:maxspeed / maxspeed:type Tags.

Since when? The wiki does not mention them as deprecated but shows Status: in use.

[RubenKelevra]

depricated source:maxspeed / maxspeed:type Tags.

Since when? The wiki does not mention them as deprecated but shows Status: in use.

I was referring to the fact that you don't need an additional tag recording the "source of the maxspeed" if you tag the implicit value in the maxspeed-Tag directly.

So I get why you may want to add maxspeed:type=sign if you tag an explicit value, but I don't see a reason to add a source:maxspeed=xx:urban if you tag maxspeed=xx:urban.

[arrival-spring]

I have started work on this, and despite my previous comment, colours are probably not going to be the most difficult bit.

My work so far has been on a parser and tagger for speed limits (see here https://github.com/streetcomplete/StreetComplete/issues/1998#issuecomment-676787192 for some idea of the complications with that)

Next I've been thinking about the UI and would welcome input. If no speed limit is set we want to encourage people to say either that there is a sign (and its value) or that there is no sign and that the road is urban/rural/whatever. However, some people like to tag, say, both maxspeed:type=FR:urban and maxspeed=50 so these would both need to be presented to the user and allow them to edit or remove them. And then there's the option of switching to highway=living_street as well.

And what to do about maxspseed:advisory? The maxspeed quest treats it as mutually exclusive with maxspeed or maxspeed:type, however about half of the time it's tagged in the wild it's combined with maxspeed, so should that be presented as well? As in "There's also an advisory speed limit", but then that's potentially three things for the user to be editing at once: type, limit and advisory limit.

I'm aware of default speed limits and osm-legal-default-speeds and have thought about using it, but am not quite sure. Any suggestion of adding explicit speed limits when the user did not select it is out of the question, but maybe using it to attempt to show when maxspeed and maxspeed:type are mismatching could be ok, but would at least be quite complex.

When I mentioned the JOSM style I was by no means saying that it was the best option, just noting it as something that exists.

How about using solid green for xx:urban, solid amber for xx:rural and solid orange for xx:motorway.

And there's also xx:trunk in some countries at least, as well as the GB tagging.

There is also the option on overlays of displaying text written along the way, but this would not be so visually striking for spotting errors.

[joshinils]

However, some people like to tag, say, both maxspeed:type=FR:urban and maxspeed=50

I don't remember where (maybe at FOSSGIS), but I heard it is more important to have the explicit number in maxspeed over anything else, since some software only cares about that tag. Anything else is nice to have of course, but I think there should never be no bare maxspeed tag.

[arrival-spring]

In SC people can only survey what's there, and if there's no sign then they can't tag maxspeed.

Due to lack of maxspeed tag in many places, software that solely relies on that needs to catch up, but I think all routing software makes assumptions, as you basically have to.

maxspeed:type is more information and is definitely useful

[NathanARF]

I would like to see an overlay for this have both maxspeed and maxspeed:type available to edit, particularly in the UK where there are a lot of speed limits mapped, but either maxspeed:type (useful for 60 mph and 30 mph speed limits) or maxspeed are not tagged. A lot of roads around me are lowering to 20 mph, which involves the changing of both tags, so the more we can alter and visualise on the go, the better in my opinion.

[RubenKelevra]

@NathanARF I disagree. StreetComplete has never shown any tags, it has always abstracted the technicalities and shown in a simple easy to approach way. If you want to see and edit the tags directly, just open the map in Vespucci?

[NathanARF]

I do not mean to edit tag values, as SC is meant to be for novice users, right? Just that the ability to make sure both maxspeed and maxspeed:type can be added or updated on road segments by users and visualised appropriately. By selecting a road segment with maxspeed=30 mph and maxspeed:type=sign, this could be shown with a sign graphic with the speed limit tagged on the road.

[RubenKelevra]

@arrival-spring wrote:

In SC people can only survey what's there, and if there's no sign then they can't tag maxspeed.

This conclusion goes against common practice. The absence of a sign is also an information which can be mapped. Similar to the abscene of a "don't park here" sign where you're adding "edge of the road" parking via the "Street parking" overlay, if you're inside city limits (at least that's the law here in Germany).

So I don't think that's a plausible scenario that a user, who's local most of the time, cannot answer what default limit applies if he/she walks along a road without a posted speed limit on it.

[RubenKelevra]

I do not mean to edit tag values, as SC is meant to be for novice users, right? Just that the ability to make sure both maxspeed and maxspeed:type can be added or updated on road segments by users and visualised appropriately. By selecting a road segment with maxspeed=30 mph and maxspeed:type=sign, this could be shown with a sign graphic with the speed limit tagged on the road.

I mean I think that's what I suggested before, isn't it? I just don't see why you want two layers make more sense here than one?!

SC should read all three tags which are currently commonly used and if they don't agree show this as an error. Otherwise they info should be presented to the users in a single layer.

If there are changed made, it makes sense to tag the speed into maxspeed=* as explicit or implicit value and if explicit add the maxspeed:type=sign Tag in addition.

[joshinils]

How much does SC want to rely on the person using it to know the local laws?

If I'm on holiday, I would have to disable this quest, or at least a part of it, since I may not know where or why there is which default speed limit. In that sense, SC should only ask for obvious things like explicit signs or a lack thereof. I may be able to answer that there is a city-limit sign, but not know that traffic_sign=DE:310 implies maxspeed=50 for the direction the sign is facing.

[NathanARF]

Perhaps asking a question if a certain sign is seen would be required then? The 'urban area' signs across Europe vary, and some do not change the speed limit.

[RubenKelevra]

@NathanARF wrote:

Perhaps asking a question if a certain sign is seen would be required then? The 'urban area' signs across Europe vary, and some do not change the speed limit.

What do you mean?

SC does exactly this for as long as I remember in the maxspeed quest. This ticket is about an overlay for maxspeed ...

[joshinils]

Then the overlay has to show both if a sign has been seen previously (or not) and at the same time display a potential number which has been seen on said sign (or if the sign has no number and implies a default).

Overall, It should say if one can deduce the actual maxspeed from the tags present or not, or if they are mismatched and in conflict.

[RubenKelevra]

@joshinils wrote:

How much does SC want to rely on the person using it to know the local laws?\n\nIf I'm on holiday, I would have to disable this quest, or at least a part of it, since I may not know where or why there is which default speed limit.\nIn that sense, SC should only ask for obvious things like explicit signs or a lack thereof.\nI may be able to answer that there is a city-limit sign, but not know that traffic_sign=DE:310 implies maxspeed=50 for the direction the sign is facing.

SC always relies on local law knowledge. If you're not certain how something is restricted/working/designed/meant to you should not answer it.

I wouldn't go on holiday and start mapping parking situations or speed limits in a foreign country, because I know I have no idea how these work.

So yes, you would deactivate the quest. But how is that an argument against showing an overlay for speed data in SC?

[NathanARF]

What do you mean?

SC does exactly this for as long as I remember in the maxspeed quest. This ticket is about an overlay for maxspeed ...

I was thinking more about asking whether an urban area sign is seen with regards to confusing limits in foreign countries, but you're right users should not attempt to solve quests they don't know much about

[westnordost]

@arrival-spring well, all these edge cases have been the reason why I shied away from implementing this so far. Not only is it an incredibly complex topic because there are so many possible ways to tag it, the whole source:maxspeed topic doesn't exactly make it easier. I recently made a list of things to take into account, I'll just put it here:

• need to support everything that is valid and may not overwrite such valid data, only correct or complement it: forward/backward, for different times, varying speed limits (through digital display), advisory speed limit, walk speed limit, etc.

• should probably not replace zone:maxspeed (source:maxspeed, etc.) with maxspeed:type when re-tagging as long as none of these keys is deprecated but in that case just update the current tag. Problem: For some of these keys, sign is actually not a valid value. Problem 2: For some of these keys, the values for slow speed zones differ (DE:30 vs DE:zone30)

• need to decide on a color palette for the speeds - which number ranges map to which color?

• instead of specifying speed limit or urban/rural, need to offer choices for streets with fixed speed limits based on another sign (living streets, bicycle roads?, pedestrian zone?, school zone?, silver zone?, shared zone?, ... more? - see default speed limits, depending on the country, there may be many of these). Of course, need (simplified) pictures of such signs too

• not all countries use urban/rural/... (or whatever) distinction. There is a huge range of other distinctions which is pretty much impossible to properly support. Reason: For many countries, there is not even a source:maxspeed value defined for certain road types. E.g. some US states have different speed limits for residential/business/other but there is not even any value defined for this in the wiki. Hence, not really sure how to solve this.

• As per previous point, maxspeed:signed=yes/no (or similar) would solve it all in one go and make it also easier for the surveyor. Maybe propose it? Unknown if there'd be support for this in the community. Does it need to be proposed? *:signed=yes/no keys are already well established - albeit mostly by StreetComplete itself.

• should probably support tagging vehicle specific speed limits (200k+ taggings)

• should probably support time-limited speed limits (60k+ taggings)

• should probably support speed limits that differ per direction (100k+ taggings)