[meshdb-devel] RE: srtm tiles

[Paul J. <pau...@ja...>]

Hi,
=20
There are areas that the data was not recorded, not all NaN is water.
=20
I used this utility to fix the issues that I was having with missing =
data. Give it a go, it should resolve the issues you are seeing.
=20
http://www.3dnature.com/srtmfill.html
=20
Regards,

Paul

________________________________

From: Ian Lister [mailto:il...@em...]
Sent: Mon 27/12/2004 3:52 PM
To: mes...@li...
Cc: Paul James
Subject: Re: srtm tiles



On Tue, 21 Dec 2004, David Leonard wrote:
>Ian, I finally managed to get around to making new altitude maps from
>SRTM data. I've committed to my dev branch.. if you feel like porting
>it to HEAD and building new alt data files, then do so.

Fantastic, thanks. The change you're referring to in CVS is
src/geo/make-hgt-qt/main.c:1.1.2.2, right? Is there any reason we =
wouldn't
want that on HEAD?

Anyway, I've merged it on to HEAD, and fixed a bug which meant the
quadtree covered an extra degree east and north that it didn't need to.
This means that the 26-29S/151-154E (3x3) range that covers our area of
interest now fits in a 64MB quadtree rather than 256MB, which is handy
because the server has a hard VM size resource limit that allows us to =
map
64MB in but not 128MB.

>You probably want to eval the new data first. I have a db online at
>  <http://www.adaptive-enterprises.com.au/~mesh/db2/>

Cool. The initial impression is certainly of much better data, but there
are a few anomalies that we should work out before switching the main =
site
across. One that jumped out from the nodes already in there is visible =
in
the elevation diagram between David's place and Paul's:

  http://www.brismesh.org/db/view.php?nodeid=3D3&peerid=3D1466
  =
http://www.adaptive-enterprises.com.au/~mesh/db2/view.php?nodeid=3D2&peer=
id=3D3

The old data shows Tingalpa Reservoir as being around 20m ASL. The SRTM
data has it as NaN, which we can't sensibly interpret as anything other
than 0, but is clearly no longer appropriate with the SRTM data. It's
kinda nice in the terrain diagram having inland water bodies showing up
black, but having that due to them being NaN is not so nice as it leads =
to
incorrect elevation diagrams as seen in the second URL above.

The sea data is more confusing, though. Rather than being a consistent
NaN, like the old data is, it varies from a fairly significant distance
above sea level to a fairly significant distance below.

  =
http://www.adaptive-enterprises.com.au/~mesh/db2/view.php?nodeid=3D6&zoom=
=3D5

Other areas show the sea being as far as 50m below sea level.

Perhaps we should do some processing of the SRTM data using the NaN =
areas
in the old data and the water body information in the VPF database to =
set
appropriate altitudes for the NaN areas in the SRTM data, and to find =
the
sea areas to set to 0 or NaN in the SRTM data?

Anyway, in the meantime I'll set it up at an alternate URL on the main
server so that at least it's accessible for people to play with, and to
use with the real database.

>merry xmas! i'm heading off early tomorrow morning...

Enjoy :-)

Ian