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)

[westnordost]

As for the UI, I imagine it like this:

1. Same UI as for lit overlay: Current state is displayed in tappable box. When tapped, a range of possibilities is displayed

2. Possibilities should include: living street, bicycle road, pedestrian street, ... etc. , digital display, sign, advisory sign, no sign, ...

3. Certain selections, such as "sign" and "advisory sign" require input within the selected item. (I'd say, after the item has been selected, not in some dialog box)

4. If there is a fixed speed limit specified but the speed limit is supposed to be implicit (=source:maxspeed is something else than sign), the item that is shown should be "no sign", with no possibility for the user to input or change the speed limit. To keep the UI simple. If the fixed speed limit does not match with what the default-speed-limits would suggest, it should be treated as invalid / not set.

---

Forward/backward speed limits should be supported by a "other answer" option, which switches the UI to a street side select on which the currently selected item is displayed as a floating icon for each side.

---

The Speed limits quest can be deleted when the overlay finished, IMO, because it is one of those information where the context (i.e. how it is tagged in other near places) is very important: E.g. you don't see a sign in the short segment that is highlighted? -> use same speed limit as further up/down the road.

[arrival-spring]

It certainly is complex, and seems to get more so the more I think about all of the possible combinations and edge cases. I'm making progress, but it will be a while.

Thank you for that list, I had thought of some of that, and had not been sure whether it was worth implement some of it. I'll work through it and see how I go.

I've had some discussion on OSM Slack about USA tagging and will probably ask some more questions in various places too.

Not allowing to edit the speed limit would be at least a bit controversial I should think, but I do understand the reasoning.

[westnordost]

An additional note: Different speed limits per lane. I've noticed during my vacation in Spain in a number of different cities that on urban roads that have more than one lane in a direction, oftentimes one of these lanes is limited to 30 (and has bicycle "sharrow" markings) while the other has the normal 50 speed limit.

(Hence the "recuerde", because it basically is the rule in the whole city. This photo is from Valledolid.)

If not a direct support to let the user specify it, at least it must be handled somehow, e.g. if maxspeed:lanes=* is specified but maxspeed=* isn't, or the user specifies a maxspeeed that is not the max of the speed limits specified in maxspeed:lanes.

[michaelblyons]

Navigation aids are going to have to develop a whole new UI to deal with that.

Isn't the correct answer for SC to leave a note?

[joshinils]

Isn't the correct answer for SC to leave a note?

No, if there is a tagging scheme available, use it. In this case, there is: https://wiki.openstreetmap.org/wiki/Key:maxspeed#Lanes We (as mappers by hobby) are not responsible for how the data is used and by whom.

Otherwise: I don't like leaving notes If I don't know if something can even be tagged at all in the first place. i.e. Any answer the user can give must have an equivalent tagging.

[westnordost]

Both of your comments are off topic here.

Leaving a note in the maxspeed quest is fine for an uncommon situation (maxspeed hours, maxspeed different per side, maxspeed different per lane, etc etc.). After all, the quest is only asked once when no maxspeed data is yet tagged. (Also, just specifying the max speed, i.e. 50 in the case above, would not be wrong either.)

For the overlay it is a different situation, because it has to deal somehow with data that is already there plus offers the user to edit it. So, it has to make sure that it does not overwrite correct data with incorrect data or creates conflicting data (e.g. maxspeed:lanes=50|30 and maxspeed=30 is added and otherwise nothing is changed.)

[arrival-spring]

I've found a problem with using osm-legal-default-speeds to determine if the maxspeed is 'correct'.

e.g. in France there are rural roads and rural dual carriageways as different road types. Problem:

• A road that is a rural dual carriageway could be correctly tagged as maxspeed:type=FR:rural oneway=yes maxspeed=110
• A rural single carriageway that is oneway, e.g. because it is just before a roundabout could be correctly tagged as maxspeed:type=FR:rural oneway=yes maxspeed=80

But whether maxspeed is included or not, this always exact matches as rural dual carriageway, so the latter would appear as a 'wrong' speed limit.

• maxspeed:type=FR:rural oneway=yes
• maxspeed:type=FR:rural oneway=yes maxspeed=110
• maxspeed:type=FR:rural oneway=yes maxspeed=80

oneway=yes fuzzy matches dual carriageway rural=yes + oneway=yes exact matches rural dual carriageway though

How is this best solved? I would really want a list of all the possible speeds it could be, based on the fuzzy matching, but that's not quite the aim of osm-legal-default-speeds

[westnordost]

Yes, the analysis is correct.

Hm well, what exactly do you want to use the default speed limits for?

[westnordost]

If the answer is: To see if the maxspeed matches with what would be the default speed limit in case an indicator is present that the maxspeed does not come from a sign: That's a bit difficult, because

• there could always be mistakes in that data, or the data could be outdated. We probably don't want to mark everything red because the data hasn't been updated
• I guess it would only be OK to use exact matches, not fuzzy matches to determine if the explicit and implicit speed limit don't match. Plus, it has to made sure that exact matches are really always exact matches, not 99% sure guesses. Until very recently, the oneway=yes thing was not even classified as a fuzzy match, it was classified as an exact match

[arrival-spring]

Indeed, it's as you suggested here:

4. If there is a fixed speed limit specified but the speed limit is supposed to be implicit (=source:maxspeed is something else than sign), the item that is shown should be "no sign", with no possibility for the user to input or change the speed limit. To keep the UI simple. If the fixed speed limit does not match with what the default-speed-limits would suggest, it should be treated as invalid / not set.

I've got to the point where I started thinking about that and came to similar conclusions as you.

To continue with my example above, both of those would be fine, but a road with maxspeed=70 would be an error and so it would be good if that was highlighted somehow.

The alternative would be to display both the type "urban/rural..." and the speed value, although if I was visiting some other country I would have no idea if they were not matching.

And if we use default speeds but then some law changes then should all earlier versions be banned from editing to save from trying to 'fix' data which is actually because of outdated matching data held in that version of SC?

[westnordost]

I read this comment a week ago but couldn't come up with a better solution than showing both at least in the case where they do not match.

And if we use default speeds but then some law changes then should all earlier versions be banned from editing to save from trying to 'fix' data which is actually because of outdated matching data held in that version of SC?

Earlier versions cannot be banned from editing, only from uploading. This mechanism wouldn't fit here.

[arrival-spring]

And if we use default speeds but then some law changes then should all earlier versions be banned from editing to save from trying to 'fix' data which is actually because of outdated matching data held in that version of SC?

Earlier versions cannot be banned from editing, only from uploading. This mechanism wouldn't fit here.

Hmm, I didn't make myself clear there. e.g. at the moment GB:nsl_single means 60 mph, but if the law changed next year and it then meant 50 mph then (earlier versions of) SC (before updates to default-speed-limits) would show GB:nsl_single + 50 mph as an error or incomplete or something if we were in any way strict with using default-speed-limits. So we need to avoid that situation.

I read this comment a week ago but couldn't come up with a better solution than showing both at least in the case where they do not match.

So maybe we need to always show both (as we cannot match type and speed with 100% confidence and forward/backward compatibility)?

i.e. For places with no data, user can select either sign or no sign For places with only one of type/maxspeed tagged we just show that For places with type and maxspeed tagged we show both (and allow both to be edited? But if user changes type to other unsigned type then only show that and remove existing speed).

[westnordost]

Maybe, yeah... do you have a clear idea how the UI should look like already?

[arrival-spring]

A reasonable idea, I haven't got to the stage of implementing it yet though.

It risks getting complicated when taking into account vehicles and conditions, and then that in each direction also.

• Main type/speed at the top
• Row/s for any conditional with smaller speed sign and drop down to select condition type (and then add details)
• • Conditionals e.g. depends on time of day, depends on time of year, depends on weather
• Row/s for vehicles, denoted by icons, then similarly any conditions to the side

If directions are specified then the streetside view would maybe just show the speed/type (could have a plus or something if there's more tagged) then tapping on a side takes you to a similar form to the above.

[westnordost]

Here are some mockups of how I think the basic (and more advanced) UI could look like, without considerations on how to display urban/rural + maxspeed sign at the same time:

[matkoniecz]

@arrival-spring

Is https://github.com/arrival-spring/StreetComplete/tree/maxspeed-overlay having latest code that you did? WHat you recommend using it as a base for someone who would want to finish it?

Are there somewhere TODOs of what remains unfixed (or maybe TODOs are in code?)?

[arrival-spring]

Is https://github.com/arrival-spring/StreetComplete/tree/maxspeed-overlay having latest code that you did?

I have just pushed a couple of unpushed commits, so it is now up to date with my latest code.

WHat you recommend using it as a base for someone who would want to finish it?

It was so much work analysing all of the tagging that yes, I think I would.

I had not got to any UI work, but was in fact still in parsing and tagging of speed limits, however that was largely complete.

The point where I got stuck was with supporting time conditional speed limits, as I could not fully understand the opening hours parser and how to add to it. Specifically, it needs to support at least "SH off" and also month only limits, "Jun-Dec" etc., if it is to support the majority of time conditional speed limits.

It's possible that the data structure I went for is too complicated, nested and confusing. Changing it would be possible, but somewhat involved.

The problem is that speed limits (in OSM) are so complicated. It is possible to have/tag a speed limit, which could be different per vehicle, depend on weight, weather or time, which could be different per side of the road and even per lane. There could also be an advisory limit. And then we want to know what type of speed limit it is (maxspeed:type etc.), again that could be per direction, but probably not applicable to the rest of it. I did deal with almost all of that complexity, but putting it into an accessible data structure is not trivial, and the one I have might not be.

Also, I have seen that some of the way tests are done has been changed on master since I did this work, so will need changing here as well.

Are there somewhere TODOs of what remains unfixed (or maybe TODOs are in code?)?

I think there are a couple of TODOs in code, but main things are as above, and then actually making the overlay and designing the UI.

One TODO which I think is in the code is to remove the checks and tests for maxspeed:seasonal:winter etc. as I have completed a (discussed) mass edit to retag such things to use maxspeed:conditional and so support is no longer needed.

[matkoniecz]

I guess the question at which point StreetComplete should give up and announce that it is too complex to edit with it.

For example conditional per lane speed limits may be a point where detecting and giving up would be good enough.