Since about two days, I’ve been getting more and more errors like this when uploading:
Error uploading chunk_size 973273 at begin_offset 0: HTTPError: 412 Client Error: Precondition Failed for url: https://rupload.facebook.com/mapillary_public_uploads/mly_tools_406b0b5e1abe2fb86e9537c1b8c15976.zip
Error uploading sequence_0/IMG_20260418_103802_00_256.jpg at offset=None since begin_offset=None: HTTPError: 429 Client Error: Too Many Requests for url: https://rupload.facebook.com/mapillary_public_uploads/mly_tools_a022591556d0973bb450d59109548371.jpg
Upload error: HTTPError: 408 Client Error: Client timeout for url: https://rupload.facebook.com/mapillary_public_uploads/mly_tools_406b0b5e1abe2fb86e9537c1b8c15976.zip
Error uploading chunk_size 1048576 at begin_offset 0: HTTPError: 503 Server Error: Failed to write to server for url: https://rupload.facebook.com/mapillary_public_uploads/mly_tools_8678c78aab9a897c28fc34ac06c65071.zip
Several attempts may be required before an upload is successful.
No multiple attempts for me but I am experiencing really unusually low upload speeds since this morning. About ¼ of the usual speed.
Btw @Hol_Ger, please update your mapillary_tools to the latest version. Uploading ZIPs has been deprecated. Redundant double storage requirements per sequence and ZIP packing are gone!
Since about 4:20 AM UTC, I am seeing upload speeds returned back to normal. So, I guess it may have been an ISP issue because I do not share my internet connection nor have background auto‑updates on or other devices use it.
I’d already done that in my desperation. See the error message refering to mly_tools_a022591556d0973bb450d59109548371.jpg. In 0.14.7, the failover works at least as reliably as the errors .
I checked the logfile from the upload of yesterday, there where some little hickups (item 4), but average around 200 Mbit is normal for the 360 image uploads (12 upload workers and 2 Gbit fiber connection). The Hero upload was a bit higher, but that’s always the case, no idea why. But in a run there was also a little speed hickup (see last logfile entry). But I had the last months never a failure of connection error.
I do also see HTTP 412 and HTTP 429 errors sporadically blip up. However, since the uploader always recovered from these errors, I did not deem them worth reporting. So yeah, errors do come up but not on every upload session or sequence uploaded.
I have observed though that chances for such errors to pop up increase when I surf the Mapillary web app while uploads run in the background. My guess is that because graph.mapillary.com and rupload.facebook.com resolve to the same IP address hiccups can happen. Ultimately, they are also just aliases for star.c10r.facebook.com. graph.mapillary.com is used heavily by the web app. mapillary_tools uses it too, especially on sequence commit but not as much as the web app. In this context, the HTTP 429 Too Many Requests error seems to make sense, especially when you consider that modern web browsers make lots of concurrent requests while at the same time mapillary_tools uses concurrent upload workers.
The HTTP 412 Precondition Failed error kind of also makes sense in Mapillary’s current scenario and configuration when one thinks about what it actually means.
HTTP 412 Precondition Failed
The server does not meet one of the preconditions that the requester put on the request header fields.
So, when rupload.facebook.com shares the IP address with graph.mapillary.com strange things may happen. Anyhow, imho the upload infrastructure should be completely disjoint or untangled from the web service, IP address wise as well as domain name wise. But, this is just my opinion.
Furthermore, since some organizations block the facebook.com domain, it may be a good idea to have all Mapillary code access mapillary.com domains (or at least aliases) only.
I would like to add another perspective to your technical explanation.
In many organizations — especially public authorities and larger companies —
access to facebook.com is blocked at the firewall or proxy level due to
data‑protection concerns or simply because social media is considered a
productivity risk. These blocks are often implemented very broadly, sometimes
entire IP ranges or entire Meta infrastructure segments are filtered.
Because Mapillary shares parts of the same IP space and backend infrastructure
with Facebook, this has an unintended side effect: Mapillary becomes inaccessible even though it is not a social media platform,
but a highly productive GIS street‑level tool.
I have personally seen how, during official GIS or Geo‑Office trainings,
Google Street View is seamlessly integrated into the workflow, while Mapillary
is not even considered — not because of preference, but because the platform
is silently blocked by IT policies. Many staff members simply assume that
“GSV is the only option”, unaware that Mapillary often provides more recent
imagery.
This is why your suggestion to separate Mapillary’s upload and web service
infrastructure from Facebook’s IP space makes a lot of sense.
It would not only reduce technical conflicts (HTTP 412/429), but also help
Mapillary remain accessible in environments where Facebook is intentionally
blocked.
In short: The current IP coupling does not only cause technical hiccups — it also
limits Mapillary’s adoption in professional GIS environments.
I have looked at Panoramax, tell me why I should contribute to another platform voluntarily pictures which then publishes them under the unfavourable license CC BY-SA 4.0.
Each Panoramax instance can choose their own license under which they want their pictures to be published. It’s designed for freedom of choice, if you don’t like the license of a particular instance, then you can spin up your own and choose which one you want. A company could spin up one just for themselves, limit contributions to certain people, have a geographic restriction, or have a restrictive license on there.
To make it clear, I explicitly want my images to be analysed using AI and used by high-volume platforms to improve maps. It goes without saying for me that a good further product may cost something. In Oanaramax, my recordings end up in a very incomplete database, which has not yet proven in any way that any of it ends up with people.
And since Mapillary images can also be used by OpenStreetMap, I am also just right for free maps in my Mapillary participation
You have spelled out exactly what I had implied in my statement. Thank you. Having the Mapillary platform access facebook.com domains not only hurts Mapillary’s adoption but also is a strategic mistake imho. This does not mean that Mapillary should not run on Meta infrastructure or use its CDN. In fact, as a contributor and user of the platform, I do not care much (or maybe only slightly more in some very specific circumstances) on what or who’s infrastructure it runs on. However, it is a strategic mistake to carelessly lump Facebook’s social media leisure and advertising use case with Mapillary’s serious productivity tool use case at this technical level. And, you are absolutely right that same organizations not only block the facebook.com domain but also IP address ranges for which it will not be enough to just update Mapillary code in this case. But, it should be the first easy thing to fix. Of course, there are also IT departments that just block a complete company profile, like for example “Meta” which can be available as a single click solution in an enterprise firewall. In this case, there is nothing else Mapillary can do but it is also okay because everybody is free to block whatever network traffic they want on their side of the “fence”.
Thank you for pointing out Panoramax. However, I am not sure that spinning up your own imagery collection instance and choosing or creating your own license helps collaboration, sharing, or anybody really much at all in the grand scheme of things. Please, do not get me wrong. Everybody is free to do so, of course. If you have a special use case or some rational reason to do so then sure, go ahead. But again, it has to be a really really good reason, which there very seldom is. Mapping is a global effort and no single entity can map the whole world alone, no matter whether it is a commercial, private, government, or volunteer driven organization. Consequently, it makes only sense for everybody to contribute to only one critical mass repository. Of course, only as long as this repository does a good job in being a reliable custodian of the imagery collected by every contributor. This is also why I have voiced earlier that imho Mapillary should have become or work towards becoming a committee steered foundation. In fact, in another, even grander scheme of things, we already have a similar super organization for mapping and naming. And, apparently most people are fine with it for what it does. It is the International Astronomical Union.
I know, it is not a perfect analogy or example because the IAU does not host imagery but they basically map not only celestial bodies but also features on them. I hope this helps to understand what I am trying to convey.
I too like the idea of having a central repository for images. It would be nice if it was structured like Overture Maps Foundation or even an integral part of it. Having corporate membership would help a lot with funding and storage. Especially if AWS and Azure were storing the data, that would help with Facebook URLs being blocked. Having camera grants go to regions that need imagery would be an awesome thing to do. It would help a lot with the data quality issue particularly for Overture Places if the images could be analyzed for relevant POI information. Also, having multiple stakeholders would mean that it wouldn’t be forgotten about or unceremoniously shut down. That’s why I’m a little concerned about Panoramax. Since it’s a collection of individual servers, you won’t know if your images will survive for very long.
Although we are going off on a tangent here (because this thread is about upload issues to Mapillary), I mostly agree with you. I am also very concerned about Mapillary’s longevity or survival because as for now Meta is the only large stake holder and main sponsor of this whole endeavor. And, while I am not forgetting thousands of contributors who also have already spent/invested considerable amounts of time and money into Mapillary, I am afraid that they ultimately have little to no say in this matter. Most of us more or less understand how the world works. A project that aims to become a critical mass imagery repository needs large sponsors with deep pockets, not only initially. It does not necessarily mean that it has to be run as a private company but it sure relies on financially strong supporters, sponsors and donors, like large corporations or governments. Panoramio is a very good lesson and reminder on how things can go wrong, although it has been later more or less superseded by Google Map Maker and even later by Google Local Guides. But, it is never great when a project of such scale in terms of funding and amount of people involved relies on a single point of failure, that is at the whim or prosperity of a single large or powerful (especially commercial) stake holder.
Even though one of my topics is only indirectly related to occasional upload problems, why am I always in such a hurry? My problem is a lack of SSD storage space. I upload images and then delete the originals. Then I format my microSD cards. That way, I don’t have a storage problem myself. Why do I do this so carelessly? Quite simply, I can always create new, current images. To be honest, I’m not very interested in historical images, and anyone who needs them can pay for that service. What I am interested in are time-lapse images that are suitable for improving current navigation maps. Therefore, it doesn’t matter to me how long Mapillary exists; please don’t misunderstand, I wish Meta success.
For me, Street View images are valuable as long as they’re fresh. Just like fresh salad on a plate. As soon as there’s fresh, young, crisp lettuce available, the old stuff can go in the compost. Nobody would ever archive lettuce.
There will always be platforms interested in Street View images, so I’m not worried.
What I find fantastic is seeing my own pictures and those of others on Mapillary; it’s truly wonderful, or rather, simply an extra gift, a reward. Thank you so much, Mapillary, and thank you, Meta, for every day; you guys are amazing.
.