Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

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

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 4 comments

Comments

@openstreetmap-trac
Copy link

Reporter: stevefaeembra
[Submitted to the original trac issue database at 9.36am, Monday, 10th March 2014]

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

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 6.35pm, Thursday, 13th March 2014]

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

@openstreetmap-trac
Copy link
Author

Author: stevefaeembra
[Added to the original trac issue at 8.32pm, Thursday, 13th March 2014]

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.

@openstreetmap-trac
Copy link
Author

Author: Andy Allan
[Added to the original trac issue at 9.10am, Friday, 14th March 2014]

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.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 9.15am, Friday, 14th March 2014]

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant