search

tilezen / joerd

Joerd can be used to download, merge and generate tiles from digital elevation data
MIT License
319 stars 49 forks source link

SRTM is used instead of NED at south Lake Tahoe (zoom 10, 11, 12+) #167

Closed nvkelso closed 6 years ago

nvkelso commented 6 years ago

v1.0

screen shot 2017-10-20 at 17 48 19

v1.1

screen shot 2017-10-20 at 17 48 12
nvkelso commented 6 years ago
nvkelso commented 6 years ago

Problem all the way up to zoom 15 :\

nvkelso commented 6 years ago
nvkelso commented 6 years ago

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

iandees commented 6 years ago

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

nvkelso commented 6 years ago

@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?)

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:

iandees commented 6 years ago

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.

iandees commented 6 years ago

Norway

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:

image

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:

image

nvkelso commented 6 years ago

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?

iandees commented 6 years ago

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.

iandees commented 6 years ago

Austria/Germany Border

Toggling between current v1 elevation tiles and the v2 tiles from Lambda Tiler in this area:

germanyaustriaborderterrain1

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?

nvkelso commented 6 years ago

Sure, let's give that a try. Do they need different priorities, too? My guess is eudem should have a better priority?

iandees commented 6 years ago

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

image

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.

iandees commented 6 years ago

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

germanyaustriaborderterrainafter1

nvkelso commented 6 years ago

Much better!

Should we do something similar for the ArcticDEM and Norway?

nvkelso commented 6 years ago

Verified Tahoe is now fixed after the re-render in https://github.com/tilezen/joerd/issues/167#issuecomment-339462575.

nvkelso commented 6 years ago

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.

nvkelso commented 6 years ago

ArcticDEM and Norway are looking fine. Closing.

nvkelso commented 6 years ago

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

nvkelso commented 6 years ago

Similar bumping in UK could be helpful? http://localhost:8000/#14/56.0011/-4.2947