Contour line rendering (or contour line data) is wrong!

[robekras]

The contour lines on OpenTopoMap are incorrect.

Please compare these views:

This website shows a correct topo map:
https://www.freemap.sk/#map=15/46.063256/10.925517&layers=X

And on opentopomap :
https://opentopomap.org/#map=15/46.06278/10.92279

Please follow the river Fiume Sarca. You will see that the contour lines on opentopomap
shows the river is sometimes flowing up the hill!

The problem seems to be a fundamental one, and is not only related to this map area.

I think the issue #322 is related to the same problem.

Also all the contour lines on cycleOSM (see openstreetmap.org) and Radfahrerkarte (also on German openstreetmap.org) are incorrect.
I'm not sure, but the rely on OpenTopoMap?

Take a look at the freemaps.sk the 'Strada forestale Bael' in the middle of the view:
I know that the SRTM data are correct because I have the GPS track for the 'Strada forestale Bael' and the elevation profile calculated with routeconverter (based on SRTM data) is correct.
If you take a look on OpenTopoMap (CyclOSM etc.) and follow that 'Strada forestale Bael',
it looks like the way is going down about 300 m and then it is going up about 300 m again.
That is absolutely wrong!

[max-dn]

I'm not sure, but the rely on OpenTopoMap?
No, they don't get their data from OpenTopoMap, they also use SRTM (or some derivates of SRTM like viewfinderpanoramas.org...).

I don't know, where the elevation in freemap.sk comes from. Maybe ASTER (which is better at the fiume sarca, but not everywhere), maybe they use some free regional elevation models. I'm sure, its not SRTM.

[robekras]

Routeconverter shows a correct elevation profile. And as far as I know the basis is SRTM.
I implemented this some years ago for routeconverter (OK, I don't know whether this was changed in the meanwhile)

I've taken a look at (your?) https://geo.dianacht.de/topo/ and this site shows a correct contour line in contrary to www.opentopomap.de

The most curious thing, nobody seems to be interested in fixing this error, or at least want to accept that there is an error.

I just checked RouteConverter. It is using SRTM3. And elevation profile is correct.

[max-dn]

I've taken a look at (your?) geo.dianacht.de/topo and this site shows a correct contour

Yes, it's mine and elevation data are from ASTER for this region. Aster happens to be better at the position.

The most curious thing, nobody seems to be interested in fixing this error, or at least want to accept that there is an error.

Yes, that is a error. Someone else could fix it by providing better worldwide elevation data. There are better data in many countries, they could be combined (if the dozens of licenses allow it). All would be grateful to this supplier, but the OTM does not have the resources to do this work. I have a look at coprnikus data, but ever conversin needs some weeks on my computer andI don't always have time right when one step is done.. ;)

[robekras]

geo.dianacht.de/topo is a fork of opentopomap.
But where is the difference? You use ASTER, and contour lines are correct.
Do you know whether opentopomap uses different elevation data? And which one?

I'm not really convinced that the problem is related to the basic elevation data.
As far as I can see, RouteConverter can use different sources of elevation data:
SRTM1, SRTM3, sonny1, sonny3, ferranti1 and ferranti3.
As I understand sonny and ferranti takes the original SRTM data and fill the gaps with other data!?

I tried to configure RouteConverter to use the different elevation data sources,
and looked at the elevation profile. I did not see any difference.
But I'm not sure whether RouteConverter did really use the different sources.
Nevertheless the elevation profile of RouteConverter matches the reality.

As far as I can remember I observed that the orignal SRTM data contained some gaps
especially in really steep terrain (e.g. Via Ponale at the Lake Garda).

The region around Ranzo and Margone is relatively steep terrain,
but I think this will not explain the really great difference in contour lines between opentopomap and geo.dianacht.de/topo/

My guess is more like a calculation error in calculating the contour lines.
or maybe in the process of merging the orignal (e.g. SRTM) data with data from other sources?

[max-dn]

You use ASTER, and contour lines are correct. Do you know whether opentopomap uses different elevation data? And which one?

SRTM with filled gaps from http://viewfinderpanoramas.org/ for the hillshading, the contour lines where from opensnowmap.org I think (which also uses SRTM).

I'm not really convinced that the problem is related to the basic elevation data.

I downloaded the elevation data from (dataset SRTM_GL3 from opentopography.org) for the image below and marked all values < 300m in red. You can see that the crater is already present in the SRTM data (I think, opentopography.org has the original data).

SRTM1, SRTM3, sonny1, sonny3, ferranti1 and ferranti3.
As I understand sonny and ferranti takes the original SRTM data and fill the gaps with other data!?

They fill gaps that are obviously wrong, so where values are really missing, or completely nonsense. A small crater at a river can be detected as error if you look at the river ("there is no lake, so the date must be wrong") but not if you just take the elavation data for correcting.

In sonny's case, he takes public data (no idea about Trento, but Alto Adige has great free data, for example: http://geokatalog.buergernetz.bz.it/geokatalog/#! ) and overlays the complete dataset on top of the srtm data, so you only use SRTM where you have nothing better. That would be just the job mentioned yesterday to be done worldwide ;)

[robekras]

I downloaded the SRTM_GL1 tile for N46E010 from opentopography.org as TIF and also have downloaded the ASTER data
and played around with GRASS GIS.
The output shows two obvious differences to the elevation data between the ASTER elevation image and the SRTM_GL1 elevation image. The one is the 'crater' and the steep terrain in the east, and the other really obvious one is the 'cut' between Ranzo and Margone.

Wrong contour line showing the road would go down and up again

The elevation image from ASTER data doesn't show the 'crater' and the 'cut':

On the fly, I haven't found any other areas with such obvious discrepancies.
Only some smaller one in Austria, and in the Dolomite Alps, and the one in #322

So somehow the ASTER data seems to be more reliable and accurate than the SRTM_GL1 data.

It's really hard to find out what (raw) data are existing, and which site uses which elevation data.
And website can merge different datasource to get new one and so on.

It's just annoying when you're cycling in the Alps, and you can't really trust the contour lines, and you have few alternatives because too many sites rely on the (sometimes) inaccurate SRTM_GL1 data.