Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#5138 closed defect (wontfix)

Contour data in Shetland Islands (Scotland) incorrect in OpenCycleMap?

Reported by: stevefaeembra Owned by: Andy Allan
Priority: minor Milestone:
Component: opencyclemap Version:
Keywords: Cc:

Description

I noticed that the contour lines in the North West quarter of the Shetland Islands in Scotland don't seem to match the terrain. They may not be from the Shetland Islands at all - the Shetlands are fairly low-lying, with a highest point of 450m?

You can see this by zooming into an area around 'Urafirth' or 'Trolladale Water' using the CycleMap? layer. Panning around, you can see that water features and coastline don't line up with the terrain contours - lochs running uphill, for example ;)

I couldn't find any public SRTM data north of around ~60.3 degrees N, roughly where this starts to happen (and the data above 60N has lots of voids), so it may be an edge case caused by stitching a different DEM in for this area?

cheers,

Steve

Change History (4)

comment:1 Changed 5 years ago by Tom Hughes

60N is basically the limit of SRTM data as they didn't fly right over the poles.

comment:2 Changed 5 years ago by stevefaeembra

had a quick look through the code on the SVN repository for SRTM2OSM.

I assume that's what OpenCycleMap? uses, correct me if I'm wrong ...

(Surely other DEMs are in use, given that Iceland, Faroe Island and Norway have contours much further north than this...)

I can only debug it in my head - I don't have a C# environment to hand, and my C# is rusty - but it looks as if the code will actually pick up the 3 cells affected:-

  • N60W001.hgt.zip
  • N60W002.hgt.zip
  • N60W003.hgt.zip

These contain "No data" for most of the first half of the DEM (you can load them up in QGIS; they appear as rectangular, rather than square, tiles). I couldn't find any bounds checking to exclude these tiles, and I'm not sure how well the contouring algorithm will cope with so much missing data.

So yes, it probably is an SRTM issue, caused by largely incomplete tiles which are non-empty.

comment:3 Changed 5 years ago by Andy Allan

Resolution: wontfix
Status: newclosed

OpenCycleMap? has never used SRTM2OSM - the contours are generated by gdal_contour and don't get converted into OSM format.

OpenCycleMap? (and my other layers) no longer use SRTM data at all, I use ASTERv2 data which has a number of advantages (coverage above 60N being one of the major ones) but a number of disadvantages. ASTER contains a number of incorrect height values and I expect this is one of them. They are hard to detect (unlike SRTM, which only had correct values and nodata 'voids') and so there's not a huge amount that I can do about them at the moment.

Hopefully there will be an ASTER v3 at some point in the future, and if not then I'll figure out an approach to detect and fix the anomalies.

comment:4 Changed 5 years ago by Tom Hughes

Ah right, I didn't realise you had switched to Aster now, so I'm afraid I misled you a bit there Steve.

Note: See TracTickets for help on using tickets.