- Beiträge
Danke Max!
Ich bin auch eben dabei einen komplett neuen Kartensatz mit den Distance/Dominanzwerten.
Wird nach und nach online gestellt.Grüße
Christian1 Teilnehmer(n) gefällt dieser Beitrag
Die neuen Elevate Versionen von heute unterstützen nun auch offiziell die neuen Werte, Testversionen hab ich gelöscht.
Developer of Elevate mapstyle
2 users thanked author for this post.
Hallo zusammen,
ich habe mir die Prominenz-100km-Gipfel einmal herausgefiltert und mir fielen so Dinge auf wie<node id=“4967402537″ lat=“43.012262″ lon=“-6.2593687″ version=“1″>
<tag k=“name“ v=“Pico Frente de las Enramadas“/>
<tag k=“natural“ v=“peak“/>
<tag k=“ele“ v=“18941″/>
</node>
Gibt es etwas sinnigere Datenquellen für Gipfel (mit denen man einen automatischen Abgleich per Skript machen kann) ?
Dann gibt es so Spezialisten, die über 200 mal xyz ft in den Namen packen, keine ele, das übliche Problem eben.
Dank und Gruß
MichaelIn der neueren Version der Daten seit letzter Woche hat der Pico Frente de las Enramadas eine angemessene Dominanz von 487m.
Wir habe da eine Notbremse eingebaut und glauben ab 9000m nicht mehr dem Mapper, sondern schaun noch mal in den Höhendaten nach. Ein angehängtes „m“ wird ignoriert, ein angehängtes „ft“ umgerechnet. Da hörts dann aber auch auf, „123 m.ü.A“ oder „123 m.ü.NN“ wird ignoriert.
Fehlende ele=* und uninterpretierbare Zahlen bekommen einen Wert aus den Höhendaten. Richtig Angst hab ich vor Leuten, die Tausendertrennzeichen machen und „1.234“ schreiben, wenn sie „1234“ meinen 😉 Das lässt sich dann nicht mehr automatisch erkennen.
Grüße
Max2 users thanked author for this post.
OK, Max, wenn ich also die wichtigsten Gipfel ab ZL 6 oder 7 in die Übersichtsdaten einblenden will, nehme ich besser Deine Höhenwerte, nicht die aus OSM.
Schöne Grüße
MichaelOoops, Max, auf https://geo.dianacht.de/topo/topographic_isolation_viefinderpanoramas.txt ist nur die Dominanz-Info enthalten, nicht die korrigierten ele-Werte. Kannst Du die bitte mit dazu geben ?
Ich habe die Daten mit denen des alten Links im Forum verglichen. In der Tat eine ganze Reihe von Abweichungen …
Dank und Gruß
Michaelist nur die Dominanz-Info enthalten, nicht die korrigierten ele-Werte. Kannst Du die bitte mit dazu geben ?
Bitte ändert das Datenformat nicht zu oft.
Meine Scripts erwarten eine Reihenfolge an Werten im csvAusserdem ist das Ganze IMO genau genug und wennFehler im Tagging auch zu Fehlern im Rendering führen werden die wenigstens auch ab und an korrigiert.
LG, Christian
Das wäre ein zusätzlicher Wert, und der kann ganz rechts stehen, dann sollte Dein Script doch keinen Stress haben, oder ?
Noch so ein auffälliger Amok-Wert:
<node id=“332019543″ lat=“17.577222″ lon=“121.143056″ version=“3″>
<tag k=“name“ v=“Mount Lacob-ti-duyog“/>
<tag k=“natural“ v=“peak“/>
<tag k=“ele“ v=“7274″/>
</node>
auf den Phillippinen.
Macht es Sinn KEINEM der OSM-Werte zu trauen und immer gegen die Höhendaten zu checken – gfls. mit einer Toleranz von 5 oder 10% ?
Der Wert im obigen Beispiel ist auch kein ft-Wert, sondern einfach Blödsinn.Ich bin kein grosser Freund der Satellitendaten. Mal ist der Satellit durch Gletscher geblendet, mal reflektiert eine Wand, mal misst er Baumkronen statt Boden… Sonnys erfreuliches Hobby, bessere Höhendaten zu sammeln hat schon seinen Sinn 😉
Zur Qualitätssicherung kann man das schon nehmen, wobei man da vermutlich nochmal die anderen Gipfel im Umkreis suchen müsste, um zu sehen, wo der Fehler liegt. Klaren Unsinn kann man erkennen, aber ob Node 249943629 wirklich nur 3.011m (OSM) oder 2979m (SRTM) hoch ist oder , kann man nur raten, wenn man nur diese beiden Werte hat. Beim Node 4466545592 (7027 oder 5884m) z.B. wäre vermutlich eher die Position (welche? Höhendaten oder Node?) zu prüfen als der Eintrag in ele=*.
Ich glaube, man kann niemandem trauen und im Zweifel traue ich schon aus Höflichkeit dem Mapper 😉 Eine Vergleichsliste gemappt/SRTM kann ich aber erzeugen, falls jemand da was basteln mag:
https://geo.dianacht.de/topo/peakele_viewfinderpanoramas.txtGrüße
MaxPS: Die Höhen in Fuß sind echt ein Problem. Der Faktor ~3 taucht ungewöhnlich oft auf bei den Bergen mit grosser Abweichung.
1 Teilnehmer(n) gefällt dieser Beitrag
Danke Max
Die Liste ist Gold wert!
Diese fießen Tausender-Werte sind mit deiner Liste und LibreCalc leicht zu filtern:
^[0-9]{1}[.|,][0-9]{3}
bzw für 5-stellige ft-Werte EV
^[0-9]{2}[.|,][0-9]{3}Wenn „feet“ -Werte dabei sind rechne ich die in Meter und tagge die „feet“ als ele:ft=
Ich werde mich gar nicht lange mit Massenedits spielen und das einfach händisch in OSM korrigieren
Sind 163 Werte, das geht „zu Fuss“ an einem Nachmittag.Grüße
ChristianHallo Christian,
in der Tat ist diese Liste extrem wertvoll. Ich habe einmal die relativen Differenzen bestimmt, für SRTM-Hohen von 50+ m, ansonsten würden die Anzahlen noch größer), und ft und feet habe ich vorher umgerechnet dabei:
Abweichung Anzahl
in >= % der Fälle
20 8246
50 2230
100 977
200 760
400 31
800 15
Die 800/400%-Liste habe ich manuell in OSM kontrolliert und korrigiert. In einer Reihe von Fällen ist nicht nur der ele-Wert falsch, sondern auch die Position …
Schönes WoE
MichaelBin eben mit der Bereinigung der Tausender-Trennzeichen fertig geworden.
Ein paar „feet“ – Werte waren auch mit dabei, die habe ich – wie gesagt – in ele:ft konserviert.Jetzt gibts noch die „ausgewiesenen“ feet-werte, also jene bei denen im ele_string [f|‘] vorkommt.
Das sind 123 Stk.ev. ‚mach ich das übers WE.Hallo zusammen,
im ZIP-File steckt eine CSV-Datei die die Abweichungen und Quotienten zeigt (die innerhalb +/-5% habe ich herausgenommen).
Der Anfang zeigt die irrwitzigen Werte, dann ca. 600 Einträge bei denen der Quotient auf ft hindeutet (feet wird auch durch einfaches Hochkomma ‚ markiert. Das Ende hat andere Anomalien (u.a. die mit dem Tausender-Punkt, die Christian schon hat), und weiter in der MItte sind viele, die auf Feet hindeuten, durch den Quotienten.
- Sie müssen angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.