Ansicht von 15 Beiträgen - 76 bis 90 (von insgesamt 129)
  • Autor
    Beiträge
  • #21282
    ChristianK
    ChristianK
    Keymaster

    Danke Max!

    Ich bin auch eben dabei einen komplett neuen Kartensatz mit den Distance/Dominanzwerten.
    Wird nach und nach online gestellt.

    Grüße
    Christian

    1 Teilnehmer(n) gefällt dieser Beitrag
    #21317
    Tobias
    Tobias
    Moderator

    Die neuen Elevate Versionen von heute unterstützen nun auch offiziell die neuen Werte, Testversionen hab ich gelöscht.

    Developer of Elevate mapstyle

    2 Benutzer dankten dem Autor für diesen Beitrag.
    #21472

    mbe57
    Teilnehmer

    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ß
    Michael

    #21474

    MaxBe
    Teilnehmer

    In 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
    Max

    • Diese Antwort wurde geändert vor 1 Jahr, 9 Monate von  MaxBe.
    2 Benutzer dankten dem Autor für diesen Beitrag.
    #21477

    mbe57
    Teilnehmer

    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
    Michael

    #21479

    mbe57
    Teilnehmer

    Ooops, 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ß
    Michael

    #21481
    ChristianK
    ChristianK
    Keymaster

    ist 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 csv

    Ausserdem 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

    #21483

    mbe57
    Teilnehmer

    Das wäre ein zusätzlicher Wert, und der kann ganz rechts stehen, dann sollte Dein Script doch keinen Stress haben, oder ?

    #21488
    ChristianK
    ChristianK
    Keymaster

    Normalerweise nicht. ..
    ;-)

    #21492

    mbe57
    Teilnehmer

    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.

    #21514

    MaxBe
    Teilnehmer

    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.txt

    Grüße
    Max

    PS: 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
    #21585
    ChristianK
    ChristianK
    Keymaster

    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
    Christian

    #21589

    mbe57
    Teilnehmer

    Hallo 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
    Michael

    #21591
    ChristianK
    ChristianK
    Keymaster

    Bin 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.

    #21598

    mbe57
    Teilnehmer

    world-PeaksDiff-0

    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.

Ansicht von 15 Beiträgen - 76 bis 90 (von insgesamt 129)

Du musst angemeldet sein, um auf dieses Thema antworten zu können.