Closed nvkelso closed 7 years ago
srtm/N37W123.tif, etopo1/ETOPO1_Bed_g.tif
srtm/N37W123.tif, etopo1/ETOPO1_Bed_g.tif
Problem all the way up to zoom 15 :\
Norway: http://tangrams.github.io/walkabout-style/#12/62.7699/7.1612
gmted/50N000E_20101117_gmted_mea075.tif, etopo1/ETOPO1_Bed_g.tif
etopo1/ETOPO1_Bed_g.tif
Germany/Austria border: http://tangrams.github.io/walkabout-style/#13/47.5483/12.9911
srtm/N47E013.tif
srtm/N47E012.tif
I hope these 4 pairs of examples help debug, but let me know if you need more!
I'm starting to think we need a few unit tests around the footprint database, sources, and expected output in some tiles inside that source footprint range...
After the fix in marblecutter above, I re-ran pyramids 8/137/89
(Germany/Austria), 8/40/98
(SF), and 8/133/70
(Norway).
In the above comment, tile normal/13/4392/2861.png
only uses srtm/N47E013.tif
, but in the updated tile on S3, uses austria/ogd-10m-at.tif, srtm/N47E013.tif
(adding back the Austra source).
@iandees Generally the fix seems to have worked for all except Tahoe. But re-reading your comment I think you skipped Tahoe, so that may make sense? Please re-run Tahoe as well.
In Norway I see that one area fixed around the original report, but if I pan very far I see junk again. I suspect a priority needs to be toggled between the new Arctic DEM and the Norway national data (preferring norway national data?)
pgdc_5m/22_64_2_2_5m_v2.0.tif, kartverket/Terrengdata_6901_4_UTM33_10m_DEM.tif
On The Austrian/Germany border, the Austria portion looks great, but in Germany I was expecting better data (and I remember better data on dev, but need to verify). For example:
austria/ogd-10m-at.tif, srtm/N47E012.tif, eudem/eudem_dem_5deg_n45e010.tif
I'm surprised it's not eudem first, than srtm?Yep, I missed Tahoe at the top of the thread here. I kicked off 8-43-97
and 8-42-97
to render Tahoe, but it's still rendering.
Around https://terrain-lambda.dev.mapzen.com/hillshade/preview#12/62.9310/7.4995 you can see the border between the ArcticDEM (right) and Kartverket (left) data. ArcticDEM claims to be 5m while Kartverket claims to be 10m. The ArcticDEM seems to be way noisier and includes the top of ice floes whereas the Kartverket data seems to set the ice to zero:
I gave a higher priority on kartverket
images:
footprints=> update footprints set priority=priority-1 where source='kartverket';
UPDATE 255
…and it looks better, with fewer noise or gaps from ArcticDEM:
Nice! I like giving the kartverket
a better priority. How does that work when they're different resolutions? I remember it being a tie-breaker, but this seems to also reach across zooms?
The priority
value is sorted on before resolution
, so a footprint with a lower priority
number will take precedence over anything else at that zoom, even with a higher resolution.
Toggling between current v1 elevation tiles and the v2 tiles from Lambda Tiler in this area:
There's definitely better data in Austria, but Germany seems to have a hard time. It seems that SRTM and EUDEM are fighting each other because they have exactly equal resolution
values in the footprints database. I think we might want to bump EUDEM's min zoom from 9 to 10?
Sure, let's give that a try. Do they need different priorities, too? My guess is eudem
should have a better priority?
It seems that this might be more nuanced than setting priority. An example tile, 13/4391/2865
uses sources austria/ogd-10m-at.tif, srtm/N47E012.tif, eudem/eudem_dem_5deg_n45e010.tif
. The majority of the tile is from Austria (orange), the bits near the top are SRTM (blue), and there's EUDEM along the right side (red):
The next tile east uses sources austria/ogd-10m-at.tif, srtm/N47E013.tif
. The upper left is SRTM and the rest is Austria.
SRTM and EUDEM both have the same resolution
listed, so when they have equivalent priority
, the only thing deciding the order in which they get rendered on the tile is the distance between the centroid of the tile and the centroid of the footprint. In the case of 13/4391/2865
, the centroid for the EUDEM image is closer than the centroid for the next SRTM image to the east, resulting in an odd looking change in data that switches back to SRTM at the next tile to the east.
We can't simply adjust the EUDEM priority because that would put it above or below SRTM (and the Austria data) completely. My inclination would be to change the priority of EUDEM so that SRTM always appears over it.
@nvkelso suggested changing the resolution on the SRTM, which I did:
footprints=> select trunc(resolution::numeric, 3), count(*) from footprints where source='srtm' group by 1;
trunc | count
--------+-------
30.887 | 14297
(1 row)
footprints=> update footprints set resolution=90.0 where source='srtm';
UPDATE 14297
This means EUDEM shows up before SRTM and the result is the area looks like this in walkabout:
Much better!
Should we do something similar for the ArcticDEM and Norway?
Verified Tahoe is now fixed after the re-render in https://github.com/tilezen/joerd/issues/167#issuecomment-339462575.
On The Austrian/Germany border, the Austria portion looks great, but in Germany I was expecting better data (and I remember better data on dev, but need to verify). For example:
Noting here as not a ship block but later refinement that Austria data comes in at zoom 12 now, looks super bumpy at zoom 13, normalizes at zoom 14. Let's live with this and see if there's public feedback.
ArcticDEM and Norway are looking fine. Closing.
New Zealand could also do with a little zoom 14 / zoom 15 blending between SRTM and local source, see http://tangrams.github.io/walkabout-style/#14/-41.3186/174.9614.
But just a random idea ;)
Similar bumping in UK could be helpful? http://localhost:8000/#14/56.0011/-4.2947
srtm/N38W121.tif
srtm/N38W121.tif
v1.0
v1.1