We’re thinking about what to prioritize next to make Mapillary more useful for OpenStreetMap editing. How do you access Mapillary imagery?
- iD imagery layer
- Rapid imagery layer
- JOSM
- Other
0
voters
What would you like to see next?
I use both ID and JOSM - and sometime parallel mapillary website because it is sometimes easier to walk through the images of a sequence
3 Likes
“It’s complicated” :
Use ID to edit OSM, using either the iD photolayer to check photos, filtered by period, or the mapillary/app webpage filtered to just my own recent pics - especially useful when editing whatever was noticed while walking or cycling.
Use JOSM to finetune position and direction of single photos taken during my walks - GPS is quite accurate, and the compass in the camera is reasonably correct, but the various Belgian layers in JOSM make it easy to fine-tune based relative to features on the GRB, the Lidar / Skyview, and the Recent or Preliminary aerial photo layers.
Use two JOSM plugins to finetune position and direction:
photoadjust to position photos on the map and make them movable, then
photo_geotagging to write adjusted gps position info to the image file header.
To return to your question “What would you like to see next?”
There’s a JOSM Mapillary plugin, but it’s not clear what it actually accomplishes; it would be helpful to a logged-in Mapillary user who could use this to adjust location and direction of photos -even from other users- when -based on their own recent visit- they spot an error.
It could also be used to correct those orange photo markers, which are occasionally way out of whack - for example when the blue dot is on a city street (where it was taken) yet your clever-clog correction places it inside a building (which is not the case).
There ia another niggle : spurious blurs of information which is pertinent to mappers.
Similar to Langfahrer I use the JOSM Mapillary plugin, ID and the Mapillary website. I also use the OSMOSE integration layer but that seems hit or miss. Not for editing OSM directly but when planning where to capture imagery I use OSMAnd and brouter web.
Biggest feature request would be that the JOSM plugin had a “play” option to automatically step through the current sequence rather than having to step manually.
The JOSM plugin also seems a lot slower than using the Mapillary website directly and is pretty buggy, it tends to throw up a lot of exceptions and pops up again even after I have removed the ma[pillary layer.
- Generally, quality and usability improvements for JOSM:
- more stability and snapiness in general
- better loading of full-resolution images: they do not immediately load, and need multiple zoom-in/outs
- better 360° support: it’s a bit slow for now, and on zoom in doesn’t display full-resolution quickly, jumping between resolutions and even resets zoom factor before showing full resolution.
- better navigation, see website
- better point feature support (see also website, where this is already better)
- feature marked in picture(s)
- e.g. multiple views of the feature
- e.g. lines on the map from the pictures showing the FOV of the active views
- A 2D map layer with all the SfM 3d points projected in top view, for:
- Mapping building contours without aerial photos
- The former, plus the ground as reprojected from the images
- Mapping areas, mapping street widths
- Mapping painted arrows, lanes etc. on the street’s surface
- Mapping street properties
The SfM items would of course need some improvements of SfM [1] [2]
JOSM Mapillary plugin dev here (taylor.smock on JOSM Trac, tsmock on GitHub).
I’ll address some of the points risen about the plugin specifically.
AFAIK, there is currently no API for me to use for adjusting location and direction of photos.
I will note that the plugin does let you use either computed location or reported location layers, with the caveat that if the difference between computed and reported locations is large enough, the reported location is used instead (after you click on the image/sequence).
It used to have that functionality, but I think the supporting API got dropped in the v3 → v4 transition.
I moved the plugin to use the JOSM image viewer dialog, which doesn’t have a play option. Feel free to file a ticket on JOSM Trac for it though. If someone files a ticket for it before you do, you can also use the upvote functionality.
This is a fair point; there are some things I did to try and keep things fast (specifically, if you are going through trip photos), but I run into some (current) limitations with the JOSM implementation. I’ve done some work towards fixing that. The problem is that the JOSM image viewer doesn’t support loading a lower resolution image and then a higher resolution image; I do the lower resolution image first since it means that you can flip through images quickly, but it does also mean that there is a funky code path that needs to be taken to get the full resolution images to show up. I’ve been working on-and-off to fix that, but it hasn’t been high priority (since no one was filing tickets about it…)
For better image loading, see #21432 ([WIP PATCH] Tile images so that we can zoom in to full resolution) – JOSM .
I haven’t seen this. Have you filed bug reports? Are you running old versions of JOSM + the plugin?
I’m actually pleasantly surprised with the speed of the 360 support in JOSM; that is all done via CPU right now. Someone wrote a plugin awhile back that used OpenGL for rendering 360 images. You can try using that. The reason why JOSM doesn’t do that in core is it would require adding another library with platform specific quirks. The library that the OpenGL renderer uses doesn’t work on macOS for example (IIRC).
JOSM core will work on any platform that Java works on. The OpenGL renderer for 360 images will work on some specific platforms.
I don’t know what you mean by this, specifically. With that said, there is an Mapillary: Image Navigation pane in the plugin that might do what you need/want. It was broken for awhile, but it was low priority since no one filed bugs. I fixed it a few months back but never did a release (again, since no one had filed a bug about it).
I did a bit of initial investigation for this in Initial support for Mapillary point clouds by tsmock · Pull Request #229 · JOSM/Mapillary · GitHub . I wasn’t happy with the output at the time (too sparse, IIRC).
As a PSA, you can help me (the guy working on JOSM, the JOSM Mapillary plugin, the JOSM, MapWithAI plugin, the JOSM sidewalks plugin, the JOSM MapRoulette plugin, occasionally the HOT Tasking Manager, etc.) prioritize problems/features by doing the following:
- Report bugs. I cannot fix that which I do not know about.
- Report papercuts. If no one complains about it, then I assume that it works “ok” for most people, or that it at least isn’t something they care about.
- Help me prioritize bugs. JOSM Trac has vote capabilities. Use it. Please.
2 Likes
I don’t edit in Open Street Map. 
I tend to start with the imagery pop up in iD, but generally tend to just open it in a new tab, as the pop up is clunky, takes up screen space at scale that makes it usable for features smaller than a building, and I think the iD version is also lower res
ID.
Starting from my recent Mapillary pictures, I go to ID. The first thing I do is to get rid of the Mapillary Photo Overlay. First because it is overcrowded with pictures, and my recent pictures are not on it anyway. Third, I need full control of the pictures to check everything.
I would like you to reinstate the Mapillary url key in ID. Believe me, the OSM Wiki is wrong and I can know it as I work with it daily. Of course the short key can be maintained, just use iif(isnum(…
My work of maintaining defibrillators is too difficult. I use bookmarklets to switch from OSM to Mapillary.
I need a website overlaying =
- Mapillary
- OSM
- Overpass Turbo
- NotesReview
What is snapiness ?
I would most like to see next the widget that stops breaking every other time it’s used
Good to know that this problem wasn’t just my local browser setup! I am using Debian Linux and Firefox ESR. I only rarely use the OSMiD/Mapillary photo layer, instead using my own photos locally.
@HellPhoto - I haven’t seen that behavior - any chance you can reliably reproduce it? What browser are you using?
I cannot reliably reproduce it. You likely have to zoom and pan and switch images/navigate a bunch of times, because that’s the usual way I’m using it. I suspect it’s likely something to do with image loading delay and some values breaking. I believe it has something to do with that warping transition thing the image does, because it usually breaks mid-warp and then becomes increasingly more distorted. Once it breaks, it’s broken for the rest of the session. Firefox, Vivaldi.
@boris
The failure mode for me increases likelihood if I do a lot of mouse rolling/zoom image panning. I can get a failure after 2-3 images that way. It doesn’t seem to fail on the first. If I dont zoom/pan it may take 20-40 image calls before it does. I get the impression it is the panning that eventually breaks it. Zooming without pan less so. Whatever it does it also sticks Firefox in that failed mode, eg closing/opening an FF tab the fault is still there. Close and relaunch FF does clear it.
I agree with @HellPhoto report.
Sorry this is so vague. I just assumed it was a local FF problem on my system.
Thank you both! @oscarlorentzon - FYI, 2 reports above of Mapillary JS seemingly breaking on Firefox.
I guess I should mention, although I assume these use the same backend code. It’s a little bit more difficult, but following same “steps” one can break the widget on Mapillary main website too.
Only warning in console is Incorrect mesh URL for ################ (null, null) @ main.c7e2655ba53edd99.js:110
