Maps 2.0: Our biggest map layer update ever! (looking for feedback)

[osmplus_org]

Suggested feature: Use OSM public GPX tracks for “Captures needed” prioritisation

Great update! However, in mountainous or rural areas (like the Alps), the “Captures needed” layer often highlights legal dead ends, such as forestry roads that are strictly closed to cyclists/vehicles.

To improve this, Mapillary could factor in the density of public OSM GPX tracks:

• High track density perfectly indicates which paths are actually heavily used and popular among hikers/cyclists.
• Targeting these “hotspots” yields a much higher real-world value for the community than blindly covering empty, legally restricted forestry paths.

Using OSM GPX data as a layer for prioritization would be a massive time-saver for power-mappers!

---

[Anders]

Just a quick update, the web is now live as well

Mapillary

[Yaro]

Thank you for the suggestion; we will take a look at improving this. At this point, we do not highlight everything and are hiding private or service roads as an example. If something is “legally restricted,” that definitely shouldn’t have been highlighted for capturing. Could you please share the link to the specific place you’re referring to?

Also, walking paths (with no cyclists and no car access) are considered valid for captures. So, they might be red on “captures needed”.

__
BR, Yaro

[GITNE]

Uhh, smoooooth! Thank you @Anders!

[Lowiekse]

Hi @Anders

How long will it take for this map to be updated?

I took some new images here on 7 August.

The sequences have already been fully processed.

KR Louis

Mapillary

uis.

[osmplus_org]

@Yaro

Also, walking paths (with no cyclists and no car access) are considered valid for captures. So, they might be red on “captures needed”.

In the Tyrolean mountains, there are many roads used exclusively for logging. I see a large number of these as not yet recorded in Mapillary. Among the roads used solely for forestry purposes, there are also those used for tourism, for example, by bikers. Some are also used for * skiing. Publicly relevant and popular attractions in the forest are easily identifiable by the numerous GPX tracks stored in OpenStreetMap.

• Ref: OpenStreetMap

[Yaro]

Hi @Lowiekse thank you for the report. The sequence is fully processed but, unfortunately, this sequence was classified as a vehicle, and thus it wasn’t matched well to the roads, as some roads here are one-way and thus are penalized by the algorithm. This led to a low confidence of the match, which in turn triggered our tiler to filter out the sequence. It is an ongoing struggle to make all classifications and matching 100% bulletproof, and this is one of the examples where we should improve it. I would say this fix will take some time, to be fixed in a correct way.

I will cc @caglarpmeta and we will take a look later on how to fix this one specifically.

__
BR, Yaro

[Yaro]

Thank you for the link. We will take a look at it in detail to confirm there’s an issue.

PS My hunch is saying me though, that if it’s on OSM and classified as a walkable / bicyclic (etc) path, and not private road/path, it can be captured

__
BR, Yaro

[Lowiekse]

this sequence was classified as a vehicle

So, actually, I walked too fast.

as some roads here are one-way and thus are penalized by the algorithm

In the Netherlands, you are allowed to cycle in both directions on many one-way roads.
So that’s allowed here too. I had to use a Google Street View image because Mapillary blurs the sign.

[Yaro]

Thank you for the details. Your capture was on foot, as I understand, and that should have been labeled correctly, as foot captures are easy to classify, but here we are. I am confirming that we’re looking at the ways to fix it.

About bicycles. We saw similar cases for bicycles (both ways are allowed to travel on a one-way street for cars) and we allow bicycles to travel both ways in this case . Also, bicycles are usually the hardest to classify (just FYI).

__
BR, Yaro

[GITNE]

@Lowiekse

In the Netherlands, you are allowed to cycle in both directions on many one-way roads.
So that’s allowed here too.

@Lowiekse But it is not the default in , right? Have the applicable one-ways been tagged with oneway:bicycle=no?
@caglarpmeta @Yaro Does the quality scorer take oneway:bicycle=no into consideration? Because, you know, assuming that bicycles can always and everywhere go either way would be a rather naive assumption.

[Lowiekse]

@GITNE

Where cyclists are permitted to cycle against the direction of traffic, this is indicated by a sign. It is indeed not generally permitted. As I’m not involved with OSM, I don’t know whether OSM takes this into account.

[AmericanMapper]

Thanks for the details on it!

[Anders]

Just a quick update, the update is now live on all platforms for all users. We have some small issues to iron out still, but nothing major was found during the beta. We will address these issues shortly.

Please keep the feedback coming, we appreciate it a lot!

[filipc]

Could this explain the delay in processing ?

[Yaro]

If that’s regarding tiles (map update), we had minor delays (up to 2 days) but it picked up everything yesterday and is actively working. I would say 12 to 18 hours should be plenty for it to crunch through everything.

There should be no other details with processing, only map update is slightly behind. If you notice anything else, please let us know.

__
BR, Yaro

[nnj4_furesoe]

Great update - very usefull indeed

[Welop7257]

Got nothing else to say other than great update!

Going to make efficient routing for Wardriving/Mapdriving a lot easier on my more rural end! I was getting quite confused as my early learning/test sequences were chaotic and unordered and kept missing little roads here and there on recent runs.

Another feature I’ve just recently noticed but that’s apparently been there forever and I haven’t seen is the 3D point cloud.. Neat way to visualize just how much data is being obtained from even super simple straightforward non-3D dash cams!

[GITNE]

Thank you @Anders for bringing the updates to all platforms. Speaking of feedback…

Aligned Layer Rendering

The “Best captures” and “Captures needed” layers render virtual sidewalks. While virtual sidewalks are indeed a useful concept for pedestrian routing, I am not sure they are so useful here. Consider this example:

All Captures	Captures Needed

The streets here have de facto been captured, yet the streets themselves are colored red (or remain white in the “Best captures” layer). This probably happens due to the images having been qualified as captured on foot and the streets having the sidewalk tag. Note that the original GPS data is precise and correct here. Just because a street has been captured on foot from a sidewalk does not mean that the street has not been captured.

Sidewalks also have different widths, which virtual sidewalks without additional tags (like sidewalk:width, sidewalk:both:width, sidewalk:left:width etc.) usually do not reflect very well from reality. Explicitly mapped sidewalks are a different story. Generally, it is correct to align imagery to explicitly mapped sidewalks because they are separate ways. However, one usually wants to know whether a street or road has been captured. So, explicitly mapped sidewalks have to be linked to a street or road name at some point in time or at some abstraction level, especially for pure data queries. Hence, sidewalks are more complex in the current OSM data model than one may think initially.

Furthermore, the virtual sidewalks algorithm creates pedestrian crossings where none exist. Therefore, I would recommend to abstain from rendering of and aligning to virtual sidewalks for now.

---

Naming

Good naming and consistency are crucial when building public facing software systems. For example, map2 is not a particularly good name for a URL query component. Keep in mind that URLs may be shared for viewing. A better name might be alignedLayer. What ever, it is worth to think harder here. Furthermore, map2=true is ambiguous. Use enumeration values, e.g. something like aligendLayer=best or alignedLayer=needed etc.

“Travel method” should rather read “Transportation mode” or “Mode of transportation” because contributors do not travel or make a trip while capturing. They rather use a mode of transportation when they capture.

“Color captures by date” should read “Color captures by age” when viewing “All captures” because the date filter has nothing to do with coloring. When viewing aligned layers “Color captures by date” should read “Fade captures by age” due to use of transparency and because it has nothing to do with the date filter.

Bad naming can lead to confusion at best and suffering, injury, and death at worst. See the “Naming Conventions” chapter for details here:

The worst programming language of all time

In other words, no need to add friction where friction is not needed.

[AmericanMapper]

Just updated on IOS! One thing I have noticed is private roads and driveways do show up on captures needed. I do like being able to see signs and data on my phone, it makes it so much simpler! Overall good update, aside from the captures needed showing private roads and driveways. (In the image below I have found multiple within a few seconds of looking at the map, they are circled in red)