Thanks, this is helpful.
PS Been there. At some point I wanted my dog to run by my side when I cycle (I’ve seen this a few times in the city), but it looks like my dog has other priorities immediately after I get on a bike 
__
BR, Yaro
2 Likes
This has now been fixed.
map2=true is now captures=all|best|needed to denote which layer to use. Existing links will resolve to captures=all, and the default is all at the moment (best will be the default eventually though).
3 Likes
Dear @yaro,
It is safe to assume that koninklijke and its trusty companion konink360 are helmet mounted, and that the helmet is worn for cycle rides, but bear in mind that the rider may occasionally have dismounted at say roadworks or to avoid recording themselves committing some traffic violation - which from 1 sep’26, in Belgium, apparently now is a traffic crime of a lower punishment category - unless the newspaper article about the new Penal Code had things the wrong way.
Best,
2 Likes
Hi @Lowiekse, the sequence you’ve shared here are now on the map and matched to the roads, it looks like, correctly.
At the same time, some other sequences you’ve shared in other message are not on the map yet, but I will check them as well, just a bit later, and they will appear on the map 
__
BR, Yaro
Oh, that was a big typo on my side. The 3 sequences which you shared here were classified as vehicular and hence were excluded from the “best captures” layer (as the algorithm couldn’t match them to the neghbouring roads). I manually updated them to be “bicycle” and now the changes are on the map and the images from those sequences are contributing to the “best captures” layer.
PS updated the initial message as well
__
BR, Yaro
2 Likes
Great, Yaro. Thank you. 
Looks like landuse=military is not filtered (example: Relation: Santahamina (16521302) | OpenStreetMap → https://www.mapillary.com/app/?lat=60.14532409631266&lng=25.04828371188694&z=13.742924269996776) out from the captures needed layer.
Mapillary’s interpretation here is correct because the landuse key does not denote legal or physical access, nor does landuse=military imply access=no or access=private. landuse denotes the use of land only, that is, how a land area is used or zoned. Furthermore, military land uses exist where public access is generally permitted and photography may or may not be allowed. Hence, if the area outlined by the relation you refer to is off limits for the public then the ways in that area should each be explicitly tagged with access=no or access=private (depending on context).
The same is true for landuse=retail areas, where usually most of the land is publicly accessible but some parts, like loading and unloading alleys, employee parking aisles, inner warehouses, or offices may be accessed by staff or personnel only (access=private).
1 Like
Mapillary has its own interpretation of various roads that it considers worthy for the “captures needed” highlights. It isn’t based on the legal interpretation if public access is allowed or not. Mapillary developers can filter out military areas with the principle of “better be safe than sorry” if they want to. Especially as exact tagging access restricted areas is always a bit up for debate: Rajavyöhykkeen väylille access=no vai access=permit?! - Suomi (Finland) - OpenStreetMap Community Forum
I’m just bringing this possibility into attention, as this layer looks weird when it is asking to go and photograph a local military garrison. Especially when it’s clearly visible from the default OpenStreetMap Carto layer that this is a restricted area, no matter how you would think it from a database perspective.
1 Like
Its because OSM has a lot of wrong data on driveways also. Private drives with 20 “no trespassing” and “violators will be shot” signs may still show up as a capture needed. You can contribute on OSM to fix this but its A LOT of wrong info, and it would take forever just to fix all in your county/region.
Do not confuse wrong data for lack of data or unmapped properties of existing data. Many ways in OSM have been imported from public sources or machine mapping, where simply some kind of highway tagged ways (often without names) had been imported to get started. Thus, OSM is not per se wrong but just incomplete or outdated, like every other map is too. And, I do not know about you but you might have noticed that Mapillary exists exactly for this reason. Mapillary exists to close this data gap in OSM where needed. If you see ways that lack access=private then do not complain. Fix the map (OSM database) so that everybody can benefit.
3 Likes
They will not do it for the exact reasons I have explained. OSM tags have a meaning, you know.
Mapillary has nothing to be sorry about because as always, contributors have to follow local laws and regulations. The Mapillary Terms of Service reiterate this. Do not confuse the visualization of a (potentially) incomplete dataset for incitement to break laws and regulations.
Besides, OpenStreetMap Carto does not render ways as private in landuse=military areas either and nobody complains that “the map says there is a public access road in a military installation but I am forbidden to go into a restricted zone”. It is the correct way to interpret the OSM data and render the map. The issue is neither with reality, the definition, nor interpretation of tags. The issue is that the map data is incomplete.
The best thing you can do is to simply fix the map, not the definition and interpretation of established tags.
2 Likes
I agree with both comments you left GITNE. I have gone and fixed some on OSM already in my local area, but again, its a lot. But hopefully other OSM contributors can also help, as this is a BIG issue with the new “captures needed” tag.
3 Likes
Great! 
Thanks to your contribution that huge heap of work just decreased a bit. Please, keep up the good work. Rome was not built in a day, either. 
Mapping is not a one time event nor ever finished, it is an ongoing collaborative process. Though eventually, map data can saturate over time to some extent locally.
3 Likes
What you just wrote is actually in conflict with Mapillary’s own capture guide: https://help.mapillary.com/hc/en-us/articles/115001477865-The-Complete-How-To-Guide-on-getting-great-Mapillary-imagery#01JE70ZTFNDTJ3QARH5WGXYX6W
Do NOT capture:
- …
- Military and other sensitive areas
- …
So basically this “captures needed” layer is in conflict with Mapillary’s own capture guide if they are guiding people to such areas. No matter if it’s permissible or not.
2 Likes
Thank you for the report and for all the investigation @gitne @Barro @AmericanMapper regarding captures needed roads. I will create a task to double-check those findings. Specifically, I will check whether the same rules apply correctly for images (captured in the excluded areas) and for roads with “captures needed”.
__
BR, Yaro
3 Likes
I captured some imagery from roads without it. But in the map they are still rendered as “capture needed”. Other roads I captured and uploaded in the same day are fine tho. What could be the reason? I can send an example in private if needed.
Thanks for the message. I would think the main reasons are either really bad GPS or sequence capture type misclassification (can be just an issue as well, of course). If you’re okay with it, just DM me the links to the sequences and I can check the reason.
__
BR, Yaro
The “Captures Needed” map layer looks to be overly selective about public highway=service ways, i.e. those that have no access tag. They are left out instead of being colored red when no imagery is available. Maybe it is due to lack of the name tag on many such public service roads? I do not know. I have not tested (because I do not want to mess around with the production OSM database) nor researched whether access=yes or access=public tagged public service roads get included by “Captures Needed”.
If it is not too much effort perhaps publishing a list of “Captures Needed” sensitive tags might help.