SRTM2OSM: Fehler beim Download der HGT-Files

Hallo,

ich bekomme auf 2 versch. Rechnern (Win7, Win10) an 2 versch. DSL-Anschlüssen folg. Fehlermeldung:

Srtm2Osm.exe -bounds1 55.01953 10.50292 69.08203 24.25781 -large
Srtm2Osm v1.12.1.0 by Igor Brejc and others

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

Calculating contour data for bound 10.50292,55.01953,24.25781,69.08203…
Downloading SRTM cell N55E010.hgt

An error occurred while accessing the network:
Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden… (SendFailure)

Vor ca. 3 Monaten hat das mit dem gleichen Setup funktioniert.

Hat jemand eine Idee oder ähnliche Probleme?

Vermutlich ist der Server außer Betrieb, von dem Srtm2OSM die Daten herunterladen will. Wäre nicht das erste mal.

bye, Nop

das kann es nicht sein. ich habe mit wireshark mitgetracet, welches File srtm2osm von welchem server laden will. Wenn ich das File im Browser downloade, funktioniert es.

Am Server liegt es nicht. Deine Eingabe macht bei mir auch Fehler, während eigene Eingaben laufen.
Was mir auffällt: Der abgefragte Bereich ist sehr gross. Vermutlich zu gross.
Zum Vergleich: Ich habe mir mal die Höhendaten von Island besorgt. Dazu habe ich Island in viele kleine Bereiche unterteilt:
call hl 63.3 -24.66 65 -23.3 Island_H10 11
call hl 63.3 -23.3 65 -21.9 Island_H10 12
call hl 63.3 -21.9 65 -20.5 Island_H10 13
call hl 63.3 -20.5 65 -19.2 Island_H10 14 usw.
dabei war hl die folgende datei:
srtm2osm -bounds1 %1 %2 %3 %4 -d Q:\srtmcache -step 10 -cat 200 50 -o Q:\osm_hoehen%5_%6.osm
das läuft auch jetzt.

Bei mir läuft es auch mit geringer Größe des Bereichs nicht.
Da ja jeweils einzelne HGT-Dateien heruntergeladen werden, würde es mich wundern, wenn hier die bounds1-Parameter einen Einfluss auf die Netzwerkverbindung hätten.

Gruß Werner

PS I:\garminsd\OSM2IMG> I:\GarminSD\Tools\Srtm2Osm\Srtm2Osm.exe -bounds1 47.0 4.0 48.0 5.0 -d I:\garminsd\SRTM -step 10 -cat 100 20 -o I:\garminsd\SRTM\tmp.osm
Srtm2Osm v1.12.1.0 by Igor Brejc and others

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

Calculating contour data for bound 4,47,5,48…
Downloading SRTM cell N47E004.hgt

An error occurred while accessing the network:
Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden… (SendFailure)

…glaube nicht dass es an der Größe liegt. Auch wenn ich nur 5km um einen Punkt etwas laden will: der gleiche Fehler

Srtm2Osm.exe -bounds2 60.86426 10.50293 5
Srtm2Osm v1.12.1.0 by Igor Brejc and others

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

Calculating contour data for bound 10.4798011892696,60.8529990370454,10.5260588107304,60.8755209629546…
Downloading SRTM cell N60E010.hgt

An error occurred while accessing the network:
Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden… (SendFailure)

From where are you trying to download SRTM data? For some time NASA servers require a proper login.

I try it from germany via Telekom DSL. But this doesnt seem to be the problem. Tracing with wireshark results in a SSL-Handshake problem. Propably the .net - version or some of its settings (if there are any) may cause the problem?

Url?

  1. Request: http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Eurasia/N60E010.hgt.zip

  2. Redirect to:

    The document has moved here.

    \n

  3. SSL-Handshake

Client:
No. Time Source Destination Protocol Length Info
81 11:29:46.545200000 wep02970 u-152-61-133-66.xr.usgs.gov TLSv1 181 Client Hello

Frame 81: 181 bytes on wire (1448 bits), 181 bytes captured (1448 bits)
Ethernet II, Src: Tp-LinkT_18:80:0c (64:66:b3:18:80:0c), Dst: Arcadyan_cc:e1:88 (74:31:70:cc:e1:88)
Internet Protocol Version 4, Src: wep02970 (192.168.2.108), Dst: u-152-61-133-66.xr.usgs.gov (152.61.133.66)
Transmission Control Protocol, Src Port: 53633 (53633), Dst Port: 443 (443), Seq: 1, Ack: 1, Len: 127
Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 122
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 118
Version: TLS 1.0 (0x0301)
Random
Session ID Length: 0
Cipher Suites Length: 28
Cipher Suites (14 suites)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 49
Extension: server_name
Extension: elliptic_curves
Extension: ec_point_formats
Extension: Unknown 23
Extension: renegotiation_info
Server:

No. Time Source Destination Protocol Length Info
83 11:29:46.707555000 u-152-61-133-66.xr.usgs.gov wep02970 TLSv1 61 Alert (Level: Fatal, Description: Protocol Version)

Frame 83: 61 bytes on wire (488 bits), 61 bytes captured (488 bits)
Ethernet II, Src: Arcadyan_cc:e1:88 (74:31:70:cc:e1:88), Dst: Tp-LinkT_18:80:0c (64:66:b3:18:80:0c)
Internet Protocol Version 4, Src: u-152-61-133-66.xr.usgs.gov (152.61.133.66), Dst: wep02970 (192.168.2.108)
Transmission Control Protocol, Src Port: 443 (443), Dst Port: 53633 (53633), Seq: 1, Ack: 128, Len: 7
Secure Sockets Layer
TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version)
Content Type: Alert (21)
Version: TLS 1.0 (0x0301)
Length: 2
Alert Message
Level: Fatal (2)
Description: Protocol Version (70)

Downloading https://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Eurasia/N60E010.hgt.zip via Browser works fine

seems that it has sthg to do with .net - version/config

Seems that certificate-handling has to be implemented in srtm2osm because of SSL-Encryption.

To solve the problem SSL handshake has to be added to Srtm3Storage.cs and SrtmIndex.cs after WebRequest.Create.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)192 | (SecurityProtocolType)768 | (SecurityProtocolType)3072;

Changed and tested it locally but don’t know where to upload the zip-file.

Great, is there a chance to get the fixed version directly?

Any progress here? Is srtm2osm still maintained by anybody? Which would be an alternative?

Thanks to Michi2.
He implemented support for https-communication.

Fixed.
Thx to Michi2.