I think that everyone in the community appreciates that this may be a tough period in the life of the Mapillary team. But for the product that relies mostly (if not solely) on the community’s contributions as a main source of data, the team’s silence looks like an appalling demonstration of lack of respect towards all of us.
@eneerhut As you’re the only one who speaks with us as a Mapillary representative, could you please shed some light? Is that to show us that Facebook will find other ways to get these photos or just a temporary communication issue? We’re waiting for 6 weeks now for a clear understanding of the path ahead of you and us and are still in limbo (as most of our previous contributions).
You can still download the data through vector tiles. Sample code is here on the forums. With Mapillary default icons the result is something like this in QGIS:
Thanks for your patience and understanding on the other side of this platform update. There are a number of related issues being reported that we are tracking, prioritising, and addressing. Missing images is one of the most critical of these.
Many images have not been fully processed to display on the new platform, even though they were showing on the old platform. We are paying close attention to this and I am working with the team to get updates on when these images will appear on the new platform. As a regular contributor and user of my images for OSM, I fully understand the frustrations. Rest assured that the images are there, but we have some work to do to make sure they’re all appearing on the platform.
My actual problem is with the android app: I’ve captured a few thousand images today with the old app. Then I tried to upload and got the message “Download on the Google Play Store”. Okay, I downloaded the new app and searched for my photos … I didn’t find them in the new app! The photos are still there in the old app. I made a new test photo in the new app and that photo appears in the new app for uploading. How can I upload my existing photos?
I made a test photo with the new app. Where can I find it in the file system? I would like to make a “private copy” before uploading and deleting with the app. Where to find??
Apparently, this new update has also caused problems for OSM integration authors.
JOSM plugin author mentioned that image contributor info is not available anymore.
This is extremely limiting in some scenarios, where I would like to filter for, or filter out images by some user (myself or somebody else). In other cases, knowing the contributor allows to know what to expect quality/coverage wise.
I also started a separate thread on this at Page not found with links to JOSM tickets.
Some of the members of the OpenStreetMap Belgium chapter like to upload their images as members of our Organization on Mapillary, OSM Belgium members
This is now broken for all of them, when using the Desktop Uploader. They were able to upload images as individuals, but when they try to do it as a member of the org, everything seems to work, except that the green Upload button never becomes clickable.
Unfortunately it looks like we are now in some kind of “between” state. Big part of my last upload are available already in ID but not on the website. JOSM plugin is not working at all for me. New uploads don’t show up on any ‘procesing’ or ‘ready’ list. Hopefully mapillary will be back on track, but lack of information indicated by many will be ‘orange light’ forlots of users…Im also thinking about some kind of alternate workflow with my work to be able to fill in the functionality gap.
Canceling edit and delete sequences or single images is really big drawback. When I take pictures many things can happen. Sometimes I dont want to show them. I collect for many days and then upload and from time to time forget to delete something. Then when the pictures are published its simple because generally its easy to remember the spot where something unwanted happened and you can find it and delete the part.
When I take pictures many things can happen. Sometimes I dont want to show them. I collect for many days and then upload and from time to time forget to delete something
Exactly. Its almost impossible to correct all gps, headings, and other errors in the pre-processing stage in a desktop uloader. By removing the option to interact with our own images after upload, the future of mapillary is becoming in a ‘orange’ zone. It looks like it has become just a one-direction service
The option to delete imagery is definitely coming back. We’re working on a way to do this more efficiently than was possible in the past. As for other types of editing such as moving images, changing compass angles, and cutting sequences, each of these cause a lot of backend processing as each image needs to be re-processed.
Far more importantly, we need to implement better checks pre-upload. Here are some hypothetical examples:
Your images from 2016. Are you sure you want to upload these? Is this the correct time stamp for the images?
Your sequence starts in Norway and ends in Morocco. Does this look correct to you?
All your images have a compass angle of 0º. Would you like to interpolate them?
Delete images in the upload tool by drawing a bounding box for the area you would like to prevent uploads for (e.g. your house).
Duplication checks. You have uploaded these images already. - This is something we have already added to the Desktop Uploader.
The things I mention above are not confirmed and some will be harder than others, but I want to illustrate the importance of proper image checks before upload to prevent a lot of work for the user after upload.
agree in case if you (Mapillary) would provide contributors (spanned across numerous platforms MAC/Linux/Win) with a comprehensive set of universal tools capable of doing the preventive checks.
As I have mentioned above, my ‘edit sequence’ scenario is fairly simple - I am adjusting image locations in rare cases when I am temporary loosing GPS fix and interpolation does not do the trick - i.e. driving in the tunnels.
The rest (i.e. duplicates filtering, direction interpolation - could be achieved in CLI and potentially in future releases of DU)
OK, I personally found a way and a tool (Geosetter) to do a preventive locations checks and editing such sequences.
But for average user it was far more easier option to open the web-app, click on the sequence and adjust locations of 10-50 points.
In the new web-app (APIv4) only 15 out of 22 of June sequences have showed up.
7 sequences are not listed and not available (neither as processed/nor under processing)
They are/were available in APIv3 Sequences missing:
June 05th 09:38AM (25 images)
June 04th 09:49AM (120 images)
June 03th 05:10PM (500 images)
June 03th 04:53PM (500 images)
June 03th 09:19AM (381 images)
June 03th 09:11AM (500 images)
June 03th 09:01AM (500 images)
(all times are in UTC)
The following has been written from the following points of view:
IT support professional
advanced IT user across multiple platforms
MacOS user as main device
Congratulations to all responsible personnel at Mapillary for wrecking the user experience across a lot of possible touch points in just one big step:
no information was given about major platform changes in advance => I only got a short email: “Terms of Service and Privacy Policy Update” on June 9, 2021. No single mention of a LOT of technical changes which affect all users on all OS platforms.
only short announcement in the Mapillary Community forum => only few changes are told at all, dedicated users have to ask to get confirmation about a lot of already implemented changes.
abandoning the so called social login options without warning => no longer login possible with Google, Facebook, OSM. Being a former OSM login user, the fallback to the registered email address did not work for me on June 13, 2021, only very dumb error messages were shown. Working as of June 15, 2021.
rerouting all map related traffic towards Facebook domains => blocking all users with filtered internet access especially when it comes to Facebook domains. Not all organisations/companies want their employees waste work time with Facebook non-work offers and therefore block access to the obvious domains. Others like me want real privacy at home and therefore blocked Facebook already on the router level.
forcing a password upgrade at the same time => throwing all machine-to-machine communication into an error and therefore disturbing otherwise well running workflows.
removing the edit feature after upload => expecting the users to deliver already perfect content is far away from reality, especially for a user content driven service. People are now forced to create their own local workflows which creates a barrier for non-techie people who just wanted to upload their coverage.
changing the API with no warning => the JOSM Mapillary Plugin had to be rewritten and has been republished with Alpha status. I had no access to Mapillary image at June 13. Working as of June 15, 2021.
shipping mapillary_tools 0.6.0 after a very long frustrating waiting time on Github => this version failed immediately by throwing errors and had to be replaced with version 0.7.0. Meaningless error messages did not show possible reasons. Working as of June 15, 2021 in version 0.7.0.
But the upload process itself delivers only an error message not explaining the Facebook rerouting which can cause errors, see #4 in this list.
shipping Mapillary Uploader 2.0.0.0 (MacOS) in a way that the Homebrew cask has been removed completely from the repos as of June 14, 2021. After manually installing it on my computer, the uploader itself delivers only an error message not explaining the Facebook rerouting.
Addendum: On Windows, you got helpful filenames after downloading: An-Jd0N9Kj_mwSQAnLVIrShjI3LM3xU6Xbqvc8-hyjHGJfMCYlIC8otpGOMAklrF-yN7RQXsmrowpkf-tDHlRJ2w7jV4U1a5rB_uNxZfhSH29l2IkzU5wpyp12PyNMU.exe
My Summary as of June 15, 2021
a lot of unprofessional communication happened. Could have been prevented in advance to the relaunch.
a lot of technical issues were unresolved at relaunch time. I know the risks of this business by myself, but you must get better in dealing with this, guys!
resources to deal with increased user issues seems limited if available at all. Again, for a user content driven service it has to improve massively.
being a Facebook subsidiary might help establishing a business model in the long run. But excluding parts of the user base by rerouting traffic without telling and not delivering any acceptable alternatives is no good move.
As I am the self created “Mapillary ambassador” in the NGO I dedicate a lot of my volunteer work time for, people there still are waiting for my decision how to continue using and contributing to Mapillary after the “Platform updates”. I still have no answer, especially after compiling this long list above.
Thanks for the explanation, @eneerhut, but the unnecessary re-processing can be easily avoided 90% of the times by NOT processing the freshly uploaded sequences in the first place. Reading all the comments here it appears that only the most active contributors do edit their sequences, meaning that everyone will be pretty much happy to upload → verify and edit sequence → make it public and available for processing.
Processing has to take place to ensure we blur faces and license plates to begin with.
It’s also not ideal to have images sitting in limbo until some contributors go through an edit process, especially if there are 100,000s of images.
Why edit server side when you can do it client side and reduce the amount of data being uploaded, processing times, and the amount of work required?
These are great examples. Moving images within a sequence could be added as an option in the Desktop Uploader. We’re investigating options for Linux users going forward.
I would be happy to do that on a client-side, though (a) that’s difficult to do on a mobile device (b) one need to be a real techy headed to come up with a necessary toolset and workflow on their own.
Say, today I use the GPSsetter (thanks for the recommendation, guys!) + ExifTool + run the same sequence through mapillary CLI tools several times to get rid of duplicates (first run to lower the number of photos, then manually fix the GPS locations, rerun mapillary CLI tools to deduplicate the sequence further and update the embedded data).
It’s a VERY painful process, considering how slow tools are on 360 shots, thus I would prefer to have a Swiss-army app or the choice to do that all online in one go – as we had before.
I fully agree that you as a platform cannot put very big uploads into a waiting queue and have no idea when the uploader will apply his/her edits. This would have been a very uninformed decision if it would have been implemented that way.
Question ist, why you cannot create a separate process for heavy bulk uploaders who have different needs compared to the average user who just contributes smaller amounts and does not feel that they need edits?
Eg. "You uploaded a very big number of images which will have a big impact on our processing systems. Therefore we need to know if you plan to massively edit positions, apply blurs or apply other changes which would trigger complete re-processing of a lot of images and slow down service availability.
Are your images really ready for final processing?
Button 1 “Yes, all images are ready and no edit is necessary or not planned”
Button 2 “No, please give me 2 more weeks to edit my stuff. After finishing I will allow processing by pressing the final button.”
Button 3 “Cancel”
This 2 weeks time frame should be enhanced for 2 more weeks if wanted - and then everything would be cleared from the queues if not processed. Should be enough time in my understanding.
And yes, this can also been done locally but should be way better implemented than the current Desktop uploader which is far away from being helpful compared to the mapillary_tools CLI software.
Why does the Desktop uploader show me the all the positions - and does not offer to correct them? Snapping image positions to a selectable OSM path next to the wrong image positions would be my number 1 feature request. I just follow the OSM path on my smartphone and let the GoPro do the GPS/image work. And if there is no path in OSM, then I use JOSM to create a new one and will use it the next time.
And why were the mapillary_tools (at least in version 0.5.0) completely useless when using the option “interpolate_directions”? Never worked for me and I found myself editing it online again by sending my direction edits into your queues. Get this feature running as advertised and you will see a massive decrease in wasted CPU cycles.
Yesterday I realised my pictures dont show because Im using old Mapillary tools. I dont know if they will eventually appear…
I also miss very much option to not morph the picture to picture movement. Its very CPU intensive and take time, so normally I dont need it. Why the option disapeared?
I meant interpolate as it is referred to in Mapillary Tools: Derive image direction (image heading or camera angle) based on image latitude and longitude. If images are missing direction, the direction is derived automatically, if direction is present, it will be derived and overwritten only if the flag.
From memory it was referred to as normalize in the old UI.
Great points @GITNE and very much in line with our thinking. Agree with points 1 & 2 that you made.
I think it’s messy and unsustainable to start designing different tools like this. A big part of the platform update was to bring stability and set us up to improve upon Mapillary from a solid foundation. This required some significant backend work. We’re collating feedback and working out how we can improve Mapillary over time now that we have resources to build new features. Not everyone will be happy all of the time, but like any company/product/tool, we hope to get the balance right most of the time.
