Closed ARiisgaard closed 4 years ago
Have you check whether the placement is correct for the original data before tiling?
When I open the file in Qgis, everything looks alright
Just ran a test with data from Austin:
Austin produced similar results to what happened in India:
Which also gets "Fixed" by changing the resolution - this time by 0.15
resolutions[z] = size / Math.pow(2, z - 0.17);
I think I found the root of the resolution issue. In my map I calculate the tile resolution as:
for (z = 0; z < 18; ++z) {
resolutions[z] = size / Math.pow(2, z - 0.17); //0.17 is my "dirty fix" - the value is found by trial and error
}
Which produces resolutions like this:
0: 0.01665737421251866
1: 0.00832868710625933
2: 0.004164343553129665
3: 0.0020821717765648327
4: 0.0010410858882824163
...
As mentioned before this created a good result, but I had no clue how the magical "0.17" should get calculated from aside from trial and error
However gdal2tiles also created resolution data in the tilemapresource.xml file. The full file is visible in the bottom of this comment, but the part I want to highlight reads:
<TileSet order="2" units-per-pixel="0.00416666666667" href="2"/>
<TileSet order="3" units-per-pixel="0.00208333333333" href="3"/>
<TileSet order="4" units-per-pixel="0.00104166666667" href="4"/>
Notice how the units-per-pixels for each tileset matches the resolutions I calculated by trial and error.
I'll create something that reads the xml-file and uses those values for the resolution instead of trying to calculate the resolution itself
Full tilemapresource.xml file:
-<TileMap tilemapservice="http://tms.osgeo.org/1.0.0" version="1.0.0">
<Title>testUS.tiff</Title>
<Abstract/>
<SRS>GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AXIS["Latitude",NORTH],AXIS["Longitude",EAST],AUTHORITY["EPSG","4326"]]</SRS>
<BoundingBox maxy="30.60000000000814" maxx="-95.35000000000004" miny="28.67500000000814" minx="-99.14166666666671"/>
<Origin y="28.67500000000814" x="-99.14166666666671"/>
<TileFormat extension="tiff" mime-type="image/tiff" height="256" width="256"/>
-<TileSets profile="raster">
<TileSet order="2" units-per-pixel="0.00416666666667" href="2"/>
<TileSet order="3" units-per-pixel="0.00208333333333" href="3"/>
<TileSet order="4" units-per-pixel="0.00104166666667" href="4"/>
</TileSets>
</TileMap>
Great! I still wonder why that doesn't work out of the box, since you should not be the only one who has that issue. But good to see that you are close to fixing it!
I think that the person creating the original map must have used another method to get tiles than a hack of gdal2tiles. Doesn't seem like he had a xml file among the tiles, which is probably why he generated the resolution in the script. So it doesn't work out of the box, since he never used the gdal2tiles-box
If the tiles just get loaded the into the maps all cities are misplaced as show below
I learned that by tinkering with the tile resolution everything pops in place. The image above have the resolution calculated as:
My dirty fix so far have been by trial and error to find what the resolution should be. I ended up with this
The question is then, why 0.095??
I'm not sure if it is connected to the issue #22, because my tile origin is the top left, which is the corner without any weird edge.
For the record the map I originally got the code from used the resolution formular:
But that results in a tileplacement, where everything get screwed up: