# Increasing upload problems **URL:** \ **Category:** Command line tools\ **Created:** [May 7, 2026, 4:16pm UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368 "2026-05-07T16:16:21Z")\ **Posts on this page:** 20\ **Page:** 1

**Author:** ![Hol\_Ger](https://avatars.discourse-cdn.com/v4/letter/h/47e85d/32.png) [@Hol\_Ger](https://forum.mapillary.com/u/Hol_Ger)\ **Post date:** [May 7, 2026, 4:16pm UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/1 "2026-05-07T16:16:21Z")

Since about two days, I’ve been getting more and more errors like this when uploading: ```auto 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. I use MapillaryTools for uploading. Could Mapillary be the cause? ---

**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\ **Post date:** [May 7, 2026, 6:17pm UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/2 "2026-05-07T18:17:54Z")

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! 😉 ---

**Author:** ![boris](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/boris/32/71767_2.png) [@boris](https://forum.mapillary.com/u/boris)\ **Post date:** [May 8, 2026, 9:09am UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/3 "2026-05-08T09:09:29Z")

@caglarpmeta - would you mind taking a look? ---

**Author:** ![caglarpmeta](https://avatars.discourse-cdn.com/v4/letter/c/848f3c/32.png) [@caglarpmeta](https://forum.mapillary.com/u/caglarpmeta)\ **Post date:** [May 8, 2026, 11:53am UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/4 "2026-05-08T11:53:05Z")

could you please try restarting the uploader and report back if the problem persists. If it persists please send us the logs. ---

**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\ **Post date:** [May 8, 2026, 1:12pm UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/5 "2026-05-08T13:12:38Z")

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. ---

**Author:** ![Hol\_Ger](https://avatars.discourse-cdn.com/v4/letter/h/47e85d/32.png) [@Hol\_Ger](https://forum.mapillary.com/u/Hol_Ger)\ **Post date:** [May 8, 2026, 3:52pm UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/6 "2026-05-08T15:52:48Z")

This is what my last two uploads looked like: ```auto 20:03:13.352 - INFO - ==> Uploading... Uploading IMAGE (1/1): 52%|████████████████████████████████████████████████████▏ | 18.8G/36.1G [1:12:42<52:26, 5.89MB/s]21:18:21.802 - WARNING - Error uploading sequence_0/IMG_20260424_112100_00_423.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_8ee3a869d168331a80a8d2226ef5866c.jpg 21:18:21.804 - INFO - Retrying in 12 seconds (1/200) Uploading IMAGE (1/1): 53%|████████████████████████████████████████████████████ | 19.1G/36.1G [1:14:04<1:03:23, 4.78MB/s]21:19:42.668 - WARNING - Error uploading sequence_0/IMG_20260424_112714_00_458.jpg at offset=10280293 since begin_offset=0: HTTPError: 429 Client Error: Too Many Requests for url: https://rupload.facebook.com/mapillary_public_uploads/mly_tools_bb682e92adca2df082fe7629e9f2d6c2.jpg 21:19:42.668 - INFO - Retrying in 12 seconds (1/200) Uploading IMAGE (1/1): 100%|████████████████████████████████████████████████████████████████████████████████████████████████████| 36.1G/36.1G [2:21:03<00:00, 4.57MB/s] 22:26:41.527 - INFO - ==> Upload summary 22:26:41.527 - INFO - 1 sequences uploaded 22:26:41.532 - INFO - 38.7 GB read in total 22:26:41.533 - INFO - 38.7 GB uploaded 22:26:41.533 - INFO - 8463.007 seconds upload time 09:21:47.720 - INFO - ==> Uploading... Uploading IMAGE (1/3): 100%|████████████████████████████████████████████████████████████████████████████████████████████████████| 24.6G/24.6G [1:40:14<00:00, 4.40MB/s] Uploading IMAGE (2/3): 100%|████████████████████████████████████████████████████████████████████████████████████████████████████| 25.3G/25.3G [1:38:51<00:00, 4.59MB/s] Uploading IMAGE (3/3): 77%|█████████████████████████████████████████████████████████████████████████████▎ | 16.0G/20.8G [1:02:00<14:44, 5.71MB/s]13:46:57.256 - WARNING - Error uploading sequence_2/IMG_20260503_163736_00_972.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_8ec2d75985ffc11d2952119f0e69117d.jpg 13:46:57.257 - INFO - Retrying in 12 seconds (1/200) Uploading IMAGE (3/3): 100%|████████████████████████████████████████████████████████████████████████████████████████████████████| 20.8G/20.8G [1:20:09<00:00, 4.63MB/s] 14:05:05.818 - INFO - ==> Upload summary 14:05:05.819 - INFO - 3 sequences uploaded 14:05:05.824 - INFO - 76.0 GB read in total 14:05:05.825 - INFO - 76.0 GB uploaded 14:05:05.825 - INFO - 16755.356 seconds upload time ``` ---

**Author:** ![Hol\_Ger](https://avatars.discourse-cdn.com/v4/letter/h/47e85d/32.png) [@Hol\_Ger](https://forum.mapillary.com/u/Hol_Ger)\ **Post date:** [May 8, 2026, 4:09pm UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/7 "2026-05-08T16:09:43Z")

> [@GITNE](#): > > please update your `mapillary_tools` to the latest version. Uploading ZIPs has been deprecated. 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 🤣 . ---

**Author:** ![TheWizard](https://avatars.discourse-cdn.com/v4/letter/t/e56c9b/32.png) [@TheWizard](https://forum.mapillary.com/u/TheWizard)\ **Post date:** [May 9, 2026, 7:24am UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/8 "2026-05-09T07:24:21Z")

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. > [20:35:11] [STEP 9/10] Uploading to Mapillary… > [20:35:32] [INFO] Uploading sequence 1 of 5… > [20:37:27] [INFO] Uploading of sequence 1 completed (2.04 GB / 01:28 / 185.5 Mbit/s) > [20:37:27] [INFO] Uploading sequence 2 of 5… > [20:39:25] [INFO] Uploading of sequence 2 completed (2.24 GB / 01:30 / 199.1 Mbit/s) > [20:39:25] [INFO] Uploading sequence 3 of 5… > [20:41:24] [INFO] Uploading of sequence 3 completed (2.16 GB / 01:30 / 192.0 Mbit/s) > [20:41:24] [INFO] Uploading sequence 4 of 5… > [20:42:59] [INFO] Uploading of sequence 4 completed (2.74 GB / 01:33 / 235.7 Mbit/s) > [20:42:59] [INFO] Uploading sequence 5 of 5… > [20:43:02] [INFO] Uploading of sequence 5 completed (26.3 MB / 00:01 / 210.4 Mbit/s) > > [20:43:02] Processing item 2/7 (28.6%): GS020691\_080526\_Maastricht > [20:43:13] [PROCESS OK] GS020691\_080526\_Maastricht > [20:43:36] [INFO] Uploading sequence 1 of 5… > [20:45:27] [INFO] Uploading of sequence 1 completed (2.78 GB / 01:33 / 239.1 Mbit/s) > [20:45:27] [INFO] Uploading sequence 2 of 5… > [20:47:15] [INFO] Uploading of sequence 2 completed (1.58 GB / 01:29 / 142.0 Mbit/s) > [20:47:15] [INFO] Uploading sequence 3 of 5… > [20:49:12] [INFO] Uploading of sequence 3 completed (1.97 GB / 01:32 / 171.3 Mbit/s) > [20:49:12] [INFO] Uploading sequence 4 of 5… > [20:50:52] [INFO] Uploading of sequence 4 completed (2.06 GB / 01:35 / 173.5 Mbit/s) > [20:50:52] [INFO] Uploading sequence 5 of 5… > [20:51:08] [INFO] Uploading of sequence 5 completed (315.0 MB / 00:14 / 180.0 Mbit/s) > t > > [20:51:08] Processing item 3/7 (42.9%): GS030691\_080526\_Maastricht > [20:51:17] [PROCESS OK] GS030691\_080526\_Maastricht > [20:51:51] [INFO] Uploading sequence 1 of 4… > [20:54:04] [INFO] Uploading of sequence 1 completed (2.15 GB / 01:42 / 168.6 Mbit/s) > [20:54:04] [INFO] Uploading sequence 2 of 4… > [20:56:15] [INFO] Uploading of sequence 2 completed (2.34 GB / 01:43 / 181.7 Mbit/s) > [20:56:15] [INFO] Uploading sequence 3 of 4… > [20:58:19] [INFO] Uploading of sequence 3 completed (2.16 GB / 02:00 / 144.0 Mbit/s) > [20:58:19] [INFO] Uploading sequence 4 of 4… > [21:01:08] [INFO] Uploading of sequence 4 completed (2.33 GB / 02:47 / 111.6 Mbit/s) > > [21:01:08] Processing item 4/7 (57.1%): GS040691\_080526\_Maastricht > [21:01:16] [PROCESS OK] GS040691\_080526\_Maastricht > [21:01:39] [INFO] Uploading sequence 1 of 5… > [21:06:47] [INFO] Uploading of sequence 1 completed (3.47 GB / 04:50 / 95.7 Mbit/s) > [21:06:47] [INFO] Uploading sequence 2 of 5… > [21:11:54] [INFO] Uploading of sequence 2 completed (2.34 GB / 04:39 / 67.1 Mbit/s) > [21:11:54] [INFO] Uploading sequence 3 of 5… > [21:13:43] [INFO] Uploading of sequence 3 completed (2.25 GB / 01:30 / 200.0 Mbit/s) > [21:13:43] [INFO] Uploading sequence 4 of 5… > [21:15:21] [INFO] Uploading of sequence 4 completed (2.33 GB / 01:29 / 209.4 Mbit/s) > [21:15:21] [INFO] Uploading sequence 5 of 5… > [21:15:55] [INFO] Uploading of sequence 5 completed (1.09 GB / 00:32 / 272.5 Mbit/s) > > [21:15:55] Processing item 5/7 (71.4%): GS050691\_080526\_Maastricht > [21:16:03] [PROCESS OK] GS050691\_080526\_Maastricht > [21:16:26] [INFO] Uploading sequence 1 of 5… > [21:18:27] [INFO] Uploading of sequence 1 completed (2.98 GB / 01:33 / 256.3 Mbit/s) > [21:18:27] [INFO] Uploading sequence 2 of 5… > [21:20:15] [INFO] Uploading of sequence 2 completed (2.96 GB / 01:31 / 260.2 Mbit/s) > [21:20:15] [INFO] Uploading sequence 3 of 5… > [21:22:04] [INFO] Uploading of sequence 3 completed (2.93 GB / 01:33 / 252.0 Mbit/s) > [21:22:04] [INFO] Uploading sequence 4 of 5… > [21:23:50] [INFO] Uploading of sequence 4 completed (2.35 GB / 01:29 / 211.2 Mbit/s) > [21:23:50] [INFO] Uploading sequence 5 of 5… > [21:25:11] [INFO] Uploading of sequence 5 completed (2.13 GB / 01:19 / 215.7 Mbit/s) > > [21:25:11] Processing item 6/7 (85.7%): GS060691\_080526\_Maastricht > [21:25:19] [PROCESS OK] GS060691\_080526\_Maastricht > [21:25:53] [INFO] Uploading sequence 1 of 4… > [21:27:52] [INFO] Uploading of sequence 1 completed (1.97 GB / 01:29 / 177.1 Mbit/s) > [21:27:52] [INFO] Uploading sequence 2 of 4… > [21:29:52] [INFO] Uploading of sequence 2 completed (2.37 GB / 01:32 / 206.1 Mbit/s) > [21:29:52] [INFO] Uploading sequence 3 of 4… > [21:31:25] [INFO] Uploading of sequence 3 completed (2.22 GB / 01:28 / 201.8 Mbit/s) > [21:31:25] [INFO] Uploading sequence 4 of 4… > [21:31:44] [INFO] Uploading of sequence 4 completed (464.0 MB / 00:17 / 218.4 Mbit/s) > > [21:31:44] Processing item 7/7 (100.0%): GS070691\_080526\_Maastricht > [21:31:50] [PROCESS OK] GS070691\_080526\_Maastricht > [21:32:14] [INFO] Uploading sequence 1 of 2… > [21:34:04] [INFO] Uploading of sequence 1 completed (3.08 GB / 01:31 / 270.8 Mbit/s) > [21:34:04] [INFO] Uploading sequence 2 of 2… > [21:35:34] [INFO] Uploading of sequence 2 completed (2.49 GB / 01:28 / 226.4 Mbit/s) > > 20:48:49] Processing item 9/21 (42.9%): GX023651.MP4 > [20:48:49] → Sampling from video… > [20:56:24] → Correcting nested directory structure… > [20:56:32] → Renamed folder to: GX023651\_080526\_Maastricht > [20:57:02] [INFO] Uploading sequence 1 of 19… > [20:57:49] [INFO] Uploading of sequence 1 completed (890.0 MB / 00:34 / 209.4 Mbit/s) > [20:57:49] [INFO] Uploading sequence 2 of 19… > [20:58:43] [INFO] Uploading of sequence 2 completed (866.0 MB / 00:38 / 182.3 Mbit/s) > [20:58:43] [INFO] Uploading sequence 3 of 19… > [21:00:06] [INFO] Uploading of sequence 3 completed (880.0 MB / 01:08 / 103.5 Mbit/s) > [21:00:06] [INFO] Uploading sequence 4 of 19… > [21:01:06] [INFO] Uploading of sequence 4 completed (809.0 MB / 00:45 / 143.8 Mbit/s) > [21:01:06] [INFO] Uploading sequence 5 of 19… > [21:02:25] [INFO] Uploading of sequence 5 completed (990.0 MB / 01:04 / 123.8 Mbit/s) > [21:02:25] [INFO] Uploading sequence 6 of 19… > [21:03:22] [INFO] Uploading of sequence 6 completed (906.0 MB / 00:42 / 172.6 Mbit/s) > [21:03:22] [INFO] Uploading sequence 7 of 19… > [21:05:45] [INFO] Uploading of sequence 7 completed (984.0 MB / 02:10 / 60.6 Mbit/s) > [21:05:45] [INFO] Uploading sequence 8 of 19… > [21:07:51] [INFO] Uploading of sequence 8 completed (908.0 MB / 01:50 / 66.0 Mbit/s) > [21:07:51] [INFO] Uploading sequence 9 of 19… > [21:10:05] [INFO] Uploading of sequence 9 completed (857.0 MB / 01:59 / 57.6 Mbit/s) > [21:10:05] [INFO] Uploading sequence 10 of 19… > [21:11:37] [INFO] Uploading of sequence 10 completed (884.0 MB / 01:16 / 93.1 Mbit/s) > [21:11:37] [INFO] Uploading sequence 11 of 19… > [21:12:23] [INFO] Uploading of sequence 11 completed (926.0 MB / 00:30 / 246.9 Mbit/s) > [21:12:23] [INFO] Uploading sequence 12 of 19… > [21:13:09] [INFO] Uploading of sequence 12 completed (1.03 GB / 00:32 / 257.5 Mbit/s) > [21:13:09] [INFO] Uploading sequence 13 of 19… > [21:13:54] [INFO] Uploading of sequence 13 completed (1.08 GB / 00:29 / 297.9 Mbit/s) > [21:13:54] [INFO] Uploading sequence 14 of 19… > [21:14:40] [INFO] Uploading of sequence 14 completed (1.21 GB / 00:29 / 333.8 Mbit/s) > [21:14:40] [INFO] Uploading sequence 15 of 19… > [21:15:25] [INFO] Uploading of sequence 15 completed (980.0 MB / 00:30 / 261.3 Mbit/s) > [21:15:25] [INFO] Uploading sequence 16 of 19… > [21:16:10] [INFO] Uploading of sequence 16 completed (1.01 GB / 00:30 / 269.3 Mbit/s) > [21:16:10] [INFO] Uploading sequence 17 of 19… > [21:16:55] [INFO] Uploading of sequence 17 completed (1.02 GB / 00:29 / 281.4 Mbit/s) > [21:16:55] [INFO] Uploading sequence 18 of 19… > [21:17:27] [INFO] Uploading of sequence 18 completed (1.06 GB / 00:30 / 282.7 Mbit/s) > [21:17:27] [INFO] Uploading sequence 19 of 19… > [21:17:30] [INFO] Uploading of sequence 19 completed (40.2 MB / 00:02 / 160.8 Mbit/s) ---

**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\ **Post date:** [May 9, 2026, 12:41pm UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/9 "2026-05-09T12:41:22Z")

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. ---

**Author:** ![Hol\_Ger](https://avatars.discourse-cdn.com/v4/letter/h/47e85d/32.png) [@Hol\_Ger](https://forum.mapillary.com/u/Hol_Ger)\ **Post date:** [May 10, 2026, 3:29pm UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/10 "2026-05-10T15:29:45Z")

Never ending story: ```auto 15:18:21.112 - INFO - ==> Uploading... Uploading IMAGE (1/1): 81%|█████████████████████████▎ | 18.0G/22.1G [1:09:23<17:00, 4.30MB/s]16:28:57.901 - WARNING - Error uploading sequence_0/IMG_20250421_153751_00_742.jpg at offset=18315331 since begin_offset=0: HTTPError: 400 Client Error: Bad Request for url: https://rupload.facebook.com/mapillary_public_uploads/mly_tools_96e3adfb03a2561531e7c6f5ee07da20.jpg Uploading IMAGE (1/1): 100%|██████████████████████████████▉| 22.0G/22.1G [1:25:03<00:03, 4.64MB/s] 16:44:38.289 - INFO - ==> Upload summary 16:44:38.289 - INFO - Nothing uploaded. Bye. 16:44:38.290 - ERROR - HTTPError: POST https://rupload.facebook.com/mapillary_public_uploads/mly_tools_96e3adfb03a2561531e7c6f5ee07da20.jpg => 400 Bad Request: {"debug_info": {"retriable": false, "type": "ProcessingFailedError", "message": "Request processing failed"}} ``` ---

**Author:** ![osmplus\_org](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/osmplus_org/32/72465_2.png) [@osmplus\_org](https://forum.mapillary.com/u/osmplus_org)\ **Post date:** [May 11, 2026, 10:49pm UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/11 "2026-05-11T22:49:04Z")

> [@GITNE](#): > > 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](http://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.** ---

**Author:** ![dsdfidksmyw](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@dsdfidksmyw](https://forum.mapillary.com/u/dsdfidksmyw)\ **Post date:** [May 12, 2026, 2:39am UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/12 "2026-05-12T02:39:35Z")

If it doesn’t get fixed, another option for organizations is to sponsor a [Panoramax instance for their region](https://explore.panoramax.fr/en/instances). ---

**Author:** ![osmplus\_org](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/osmplus_org/32/72465_2.png) [@osmplus\_org](https://forum.mapillary.com/u/osmplus_org)\ **Post date:** [May 12, 2026, 9:28am UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/13 "2026-05-12T09:28:16Z")

CC BY-SA 4.0 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. ---

**Author:** ![dsdfidksmyw](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@dsdfidksmyw](https://forum.mapillary.com/u/dsdfidksmyw)\ **Post date:** [May 12, 2026, 9:51am UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/14 "2026-05-12T09:51:12Z")

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. ---

**Author:** ![osmplus\_org](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/osmplus_org/32/72465_2.png) [@osmplus\_org](https://forum.mapillary.com/u/osmplus_org)\ **Post date:** [May 12, 2026, 9:59am UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/15 "2026-05-12T09:59:39Z")

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 ---

**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\ **Post date:** [May 12, 2026, 4:20pm UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/16 "2026-05-12T16:20:40Z")

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”. ---

**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\ **Post date:** [May 12, 2026, 5:00pm UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/17 "2026-05-12T17:00:36Z")

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](https://en.wikipedia.org/wiki/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. ---

**Author:** ![dsdfidksmyw](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@dsdfidksmyw](https://forum.mapillary.com/u/dsdfidksmyw)\ **Post date:** [May 13, 2026, 6:26am UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/18 "2026-05-13T06:26:15Z")

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. ---

**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\ **Post date:** [May 13, 2026, 8:43am UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/19 "2026-05-13T08:43:50Z")

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](https://en.wikipedia.org/wiki/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. ---

**Author:** ![osmplus\_org](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/osmplus_org/32/72465_2.png) [@osmplus\_org](https://forum.mapillary.com/u/osmplus_org)\ **Post date:** [May 14, 2026, 10:09am UTC](https://forum.mapillary.com/t/increasing-upload-problems/10368/20 "2026-05-14T10:09:25Z")

> [@GITNE](#): > > I am also very concerned about Mapillary’s longevity or survival 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. [Next page](https://forum.mapillary.com/t/increasing-upload-problems/10368.md?page=2)