Hi. I have downloaded several GB of aerial imagery, available as .jpg and .jgw files, but not as a imagery service.
I try to use in JOSM with the import picture plugin, and the imagery is displayed as usuarl, but that way i have to load manually every image (800+ of them), and previously seach in a grid the file name to load for the area i’m editing.
The imagery is the more recent and best quality, so i want to use that instead of the imagery proposed by JOSM. ¿There is a free imagery server where i can send the pictures and get the mosaics in JOSM? That way it can be useful for myself and the whole community…
Before going into the technical details: What is the source of the imagery and is it published under a compatible license or do you have a permission to use it?
As it seems the best choice, I’m trying to upload imagery to openaerialmap.org without success for now. Maybe the size of the files is the problem, but the error is generic. I contacted them for help. I will update here… Thanks.
Still no response from openaerialmap.
I tried another option making a local pyramid with gdal_retile.py but the process fails every few hours complaing about some of the jpg. I renamed the jpg and “-resume” the process several times but now the size is reaching 50GB (original) + 200GB (the pyramid) so i need to move the files from ssd to a hdd and retry.
How can i calculate/estimate the storage requirements for the pyramid?
You can view it as a reverse pyramid. 200 GB seems to be a bit large. Each zoom level should have 4x fewer pixels, so (idealized), each lower zoom level from the original should be 50/(4^(max_level - level)). So we are looking at the sum from 0 to max_level of that.
The bottom layer should be ~50GB (probably a bit more, since we are losing some efficiency), the next layer up should be 50/4=12.5GB, the next should be 12.5/4=3.125GB. This comes out to ~62.5GB if the original is z24. Now, if you are trying to make tiles for higher z levels, you are going to run into problems. The first additional z level brings us to 250 GB, and the one after that brings us to 1TB.
For those interested, here are the idealized size (GB) given an initial size of 50GB and a max zoom of 24.
zoom
size
total (0-current zoom)
0
1.77635683940025E-13
1.77635683940025E-13
1
7.105427357601E-13
8.88178419700125E-13
2
2.8421709430404E-12
3.5527136788005E-12
3
1.13686837721616E-11
1.4210854715202E-11
4
4.54747350886464E-11
5.6843418860808E-11
5
1.81898940354586E-10
2.27373675443232E-10
6
7.27595761418343E-10
9.09494701772928E-10
7
2.91038304567337E-09
3.63797880709171E-09
8
1.16415321826935E-08
1.45519152283669E-08
9
4.65661287307739E-08
5.82076609134674E-08
10
1.86264514923096E-07
2.3283064365387E-07
11
7.45058059692383E-07
9.31322574615479E-07
12
2.98023223876953E-06
3.72529029846191E-06
13
1.19209289550781E-05
1.49011611938477E-05
14
4.76837158203125E-05
5.96046447753906E-05
15
0.00019073486328125
0.000238418579101563
16
0.000762939453125
0.00095367431640625
17
0.0030517578125
0.003814697265625
18
0.01220703125
0.0152587890625
19
0.048828125
0.06103515625
20
0.1953125
0.244140625
21
0.78125
0.9765625
22
3.125
3.90625
23
12.5
15.625
24
50
62.5
25
200
250
26
800
1000
Geofabrik has a tile calculator as well, but it only goes to z18.
“openareialmap” is HOT, the likelihood of you getting an answer is very low. It is a typical “humanitarian software” project with all the problems that come with that.
Process the jpg & jgw wiith gdal translate
for arch in *.jpg; do gdal_translate -a_srs EPSG:32721 -of GTiff -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR ${arch} …/MVDtiff/${arch}.tiff; done