( https://github.com/streetcomplete/StreetComplete/commit/f6f358d7bf7b55f8163c97392c7cb7445ae7cc96 )

Now, StreetComplete users will get up to date suggestions in the atm operator, clothes container operator and charging station operator quests again :-)

Cool, thank you! For my use case, I don’t necessarily need the centroid, I could also just take the first point of a linestring etc.

By the way, is it a bug that if I export this query https://qlever.cs.uni-freiburg.de/osm-planet/bEcHTr to CSV, I get this:

name,type,geometry
Paris Gare du Nord,https://www.openstreetmap.org/node,POINT(2.3549733 48.8804003)

while if I export it to TSV, I get this:

?name	?type	?geometry
"Paris Gare du Nord"	<https://www.openstreetmap.org/node>	"POINT(2.3549733 48.8804003)"^^<http://www.opengis.net/ont/geosparql#wktLiteral>

(Note the different format of the header and also the “^^http://www.opengis.net/ont/geosparql#wktLiteral” at the end)

Wow, that’s great!

I did write some scripts to be used for StreetComplete using Sophox, only shortly after I had to disable them because Sophox wasn’t working properly anymore. Now, I can use QLever!

Is it possible to query e.g. the following?:

Select the - value of operator OSM key - the lat and lon of the centroid of ALL amenity=recycling + recycling_type=container?

I didn’t find out how I could do this

Roland Olbricht did a talk on the SOTM 2022 that touched on the topic of barrier-free mapping:

https://media.ccc.de/v/sotm2022-18470-routing-not-only-for-prams

https://github.com/streetcomplete/StreetComplete/issues/5173

As RubenKelevra’s interpretation is correct, I now improved the wording for StreetComplete.

It will now ask “Does this crosswalk have tactile paving on both ends?” when asking about whether to tag tactile_paving =yes or =no on the highway=crossing node.

I hope this prevents any further misunderstandings in the future.

Supaplex030 depiction of the situation is accurate:

As far as I know, there is either no consensus amongst mappers whether the footway=crossing extends to only till the curb or till the centerline of the connected sidewalk - or it is not documented clearly enough how it should be done (which would naturally be to connect the footway=crossing to the centerline of the sidewalk IMO, but eh, let’s not discuss this here 🤷‍♂️).

footway=link I’ve seen mostly be used for foot- or bike paths that do not really exist physically but are necessary to connect the paths for routing. Example: A road with sidewalks on both sides but for one reason or another, the sidewalk for one half of that road was tagged on the roadway itself (sidewalk=both) and the other half with separate highway=footway + footway=sidewalk ways. At the transition point between these two different ways to tag it, the separately drawn sidewalk ways must lead back to the roadway in order to remain routable. However, these ways do not really exist - there is no footway that leads from the sidewalk to the centerline of the road - and footway=link serves as an indicator for software to treat them accordingly.

I strongly discourage using footway=link for the “connector” of a footway=crossing and the centerline of a sidewalk because footway=link already carries the meaning explained above and such a “connector” is a different meaning altogether (i.e. it does exist physically).

7MB? Hm. Did anything change with the last update? Related topic in which I also measured how much is transferred on page load:

https://community.openstreetmap.org/t/performance-issues-with-discourse-3-0/8182

Regarding the page load times…. could it also be specific to Firefox on mobile?

I have now for some months noticed that Firefox on my mobile seems to get stuck loading a page sometimes and/or it takes really long to show. Even (I think) quite basic sites and with wifi internet connection.

When I tried the same page in Chrome, it loaded immediately. Something is wrong with my phone or something is wrong with Firefox on mobile (or maybe a plugin I am using - ublock?)

I’ve noticed that the talks from the SotM 2022 are online:

https://media.ccc.de/v/sotm2022-18524-inferring-default-speed-limits

Awesome!

I put the parser into the same repo as osm-legal-default-speeds now (in directory /parser), so everything is in one place. The source code for the demo is also in that repo (directory /demo)

https://westnordost.github.io/osm-legal-default-speeds/

I have now finished implementing the python script that parses the default speed limits wiki page: https://github.com/westnordost/osm-legal-default-speeds-parser

and also finished implementing a reference implementation / library in Kotlin multiplatform: https://github.com/westnordost/osm-legal-default-speeds

You mention one workaround to find if a road is urban or not with source:maxspeed, in fact, I think this (Overpass Wizard syntax-like) filter would yield the best result:

source:maxspeed~urban or maxspeed:type~urban or zone:maxspeed~urban or zone:traffic~urban or maxspeed~urban

But of course, this is only set accordingly if there is no maxspeed sign, which is an issue because

• there are other traffic rules that apply depending on whether a road is within a built-up area or not, e.g. regarding parking
• there are even other maxspeed related rules that apply only in a built-up area, e.g. the maxspeed of other vehicle types

But it is still an ok workaround. Additionally, if a fuzzy match is okay, one could look at highway~^service|living_street|residential$ or lit=yes or sidewalk~^yes|both|left|right$ or ~^sidewalk:(left|right|both)$=yes because e.g. roads in built-up areas usually have street lighting and sidewalks.

After all, a highway=primary can be either an urban road or an intercity road. Do you have an idea how to differentiate those?

That depends on the legislation. Some legislation define default speed limits based on the number of lanes a road has. Other legislation has different default speed limits based on whether the road has a dual carriageway or not (= a barrier that divides the traffic going into different directions). These things are potentially tagged. Communities in some countries also aligned the definitions of certain classifications of roads (for which different maxspeeds apply by default) with the definitions used in legislation. So for these countries, it may actually be possible to infer with certainty from e.g. highway=primary to a certain default speed limit.

But anyway, absolutely agree on that the information that is missing most of the times to properly infer the default speed limit is whether a road is within a built-up area or not. A tag like urban=yes/no does not exist. Router software maintainers struggle with this too.

A more automated solution has to be possible: Even my car has one of those computer vision systems which detects speed limits with staggering accuracy.

This is what Mapillary is doing, right? This data still needs to be (manually) processed and inserted into OSM though. It’s still a lot of work.

Actually, I think the best approach to properly get to current (non legislative but) de-facto speed limits is to not look at OSM data but have a fleet of cars constantly on the roads and sourcing the data for the current traffic situation for that. E.g. like Google does it (with data sourced by users of Google Maps). But whoever else may be collecting this kind of data (big taxi companies?, navigation system manufacturers?) , it is proprietary data and there is no good reason for them to give that away for free other than maybe to combine forces against a common market leader (Google).

So, bottomline, finding and properly mapping the legislative default speed limits to OSM tags is a improvement of the situation in any case.

Does this mean we can programmatically fill in default maxspeed for roads based on type of road wherever the tag is absent?

Yes, the goal is that data consumers can fill in default maxspeeds for roads where that information is missing in OSM. I.e. it should not be used to copy&paste maxspeed automatically everywhere, of course.

I worry a bit about performance.

I do too. #4079 will produce a relief.

But otherwise, I pushed the map rendering library tangram-es really far beyond what it is made for, and it shows. Nevermind possibly migrating to MapLibre, I think if something is done here, the more prudent move would be to do something similar what Bryan Housel and Ben Clarke did with (rap)iD: Use a hardware accelerated game/general purpose rendering library to render the OSM data itself.

I wonder what the conditions are that make a line green/pink/red.

The coloring depends on the overlay. Right now, the only color convention is red for “information is missing” and black for “no” (e.g. no sidewalk). This may change. Early mockups envisaged to show a legend, but I dropped this idea because it adds effort for overlay contributors + translators and the user can simply tap on one specifically-colored element to see what the color means.

Could I use this feature to re-survey an area? (See also https://github.com/streetcomplete/StreetComplete/discussions/3644.)

Right now, the “OK” button is greyed out if you did not change anything. So, setting e.g. check_date:sidewalk while not otherwise touching the tagging is currently not possible in this first version.

However, the idea is to enable the thing you mentioned in the future by adding some kind of setting for the overlays in which you can specify to color elements last checked more than X days/weeks/months/years ago as if they haven’t been tagged at all yet. E.g. if you set this slider to “1 day”, probably the whole map except those you just answered will appear in red. For such elements, the OK button shall be not greyed out. I did not implement this yet because I did not see a use case that’s worth further delaying this initial version of the overlays.

FWIW, I created an account at PlantNet to contribute some observations and noticed that I retain my copyright for pictures contributed but must agree to license them under a permissive cc-license. Not sure how it works with Flora Incognita.

Which do you find better / more accurate? PlantNet or Flora Incognita?

Then, the script’s counting is not correct as it shows a higher number than SC. E.g. for me the quest AddIsDefibrillatorIndoor shows in SC 19 and the script 21.

I think the discrepancy can be explained by this:

https://github.com/streetcomplete/sc-statistics-service/blob/master/classes/ChangesetAnalyzer.class.php#L36-L69

When you solve a quest, then undo a quest, then solve it again (differently), that’s 3 changes. StreetComplete only counts this as one. Wieland’s script probably counts this as 3 (because it is easier and the difference will usually not be that high).

Old changesets by SC with version <X are not parsed. If you still had the stars in your app when version X was introduced, they were used as start value instead of 0 stars.

This is likely to be true.

But still not true. All changes ever done with SC beginning with v0.1 are included in the statistics shown in the app.

I love these kinds of animations!