mibe / srtm2osm Goto Github PK

Don't extract and delete the .hgt.zip files, but when loading these files extract them in memory. This will save some space on disk.

See this issue on the OSM-Wiki talk page. Srtm2Osm generates isohypses although it shouldn't.

See this issue on the OSM-Wiki talk page.

Hi,

I was wondering if this is normal ? Is the server down sometimes or they change seomthing on their side ?
Is your wonderful tool still usable ?

C:\Users\***\Downloads\Software\Srtm2Osm > Srtm2Osm.exe -bounds2 47.6628 10.3707 50 -step 5 -o output.osm
Srtm2Osm v1.13.1.0 by Igor Brejc and others

Uses SRTM data to generate elevation contour lines for use in OpenStreetMap

Downloading data for SRTM index generation

An error occurred while accessing the network:
The remote server returned an error: (404) Not Found. (ProtocolError)
URI: https://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Australia/
```

Thanks for your feedback.

Sorry if this is not the right place for what I am asking.
I am using this program to add contour lines to my gps OSM maps.
The command I send is:

srtm2osm.exe -bounds1 -119.7 49.76 -119.25 50 -step 10 -cat 2000 1000 -corrxy 0.0005 0.0005 -maxwaynodes 5000 -large - -o srtm-kelowna.osm > srtm.log

When I tried to sort it with OSMIUM I got an error because of the node ID.
I corrected this by adding these parameters to the line:
-firstnodeid 9000000000000000000 -firstwayid 9000000000000000000 and that solved it.

Later the error is due to the timestamp:
can not parse timestamp: '2023-06-09T22:36:40.4567369Z'

Below I copy a part of the first line of the file.
<node id="9223372036854775807" timestamp="2023-06-03T12:55:25.5578799Z" user="Srtm2Osm" uid="941874" lat="43.99925"...

Is it normal for srtm2osm to produce this date format?
Or is the problem somewhere else?

Regards

Don't start node / way ID's at 2^63-1 as the default. It looks like downstream programs like splitter / mkmap have a problem with this number.

Thanks to have had a look.

I have a problem, but it may be my fault:

Srtm2Osm.exe -bounds2 47.6628 10.3707 50 -step 5 -source "https://terrain.ardupilot.org/data/SRTM" -o output.osm
or
Srtm2Osm.exe -bounds2 47.6628 10.3707 50 -step 5 -o output.osm

Uses SRTM data to generate elevation contour lines for use in OpenStreetMap

Calculating contour data for bound 10.203497521711,47.5501903704538,10.537902478289,47.7754096295461...
Downloading SRTM cell N47E010.hgt

ERROR: 1 is not a supported code page.
Parameter name: codepage

Do I miss something ?

Originally posted by @DGrv in #5 (comment)

See this issue on the OSM-Wiki

See if Srtm2Osm can be compiled & used with .NET Framework 4.5.

See this issue on the OSM-Wiki talk page. Maybe display a warning instead of throwing an error.

Maybe the LiDAR Elevation files of Europe by Sonny which can be found here: https://sonny.4lima.de
are of interest to be used with Srtm2Osm too. They are offered in the SRTM-fileformat .hgt as well as .geotiff
In that case it would be ideal to mention them on the Wikisite https://wiki.openstreetmap.org/wiki/Srtm2Osm for people who are searching for good elevation source data.

See this issue on the OSM-Wiki talk page.

The source parameter does support the file scheme for local files, but it still needs the directory structure of the original SRTM server with the continents. So just throwing a bunch of .hgt files in a directory will not work.

This should be changed so that "throwing a bunch of .hgt files" will work. This is much easier for DEMs that are in SRTM format but not necessarily from the SRTM server, like in #13.

See this issue on the OSM-Wiki talk page. It looks like the algorithm cannot find the correct IsohypseMovement value.

The server with the SRTM files is gone (again).
The replacement for https://terrain.ardupilot.org/data/SRTM/ could be http://firmware.ardupilot.org/SRTM/

As a workaround, one could use the parameter source:
-source http://firmware.ardupilot.org/SRTM/

Remove the SharpZipLib dependency and use the .NET class ZipArchive instead. The version currently used of the dependency is old as the hills. Version 0.85 came out AFAIK end of 2006?

However, the ZipArchive / ZipFile classes require .NET Framework 4.5 and are not available in 4.0. See #7 for that.