Betrachte 15 Beiträge - 226 bis 240 (von insgesamt 242)
  • Autor
    Beiträge
  • #38652
    Tobias
    Tobias
    Moderator

    Hab mir die Daten nicht angesehen, aber kann es sein, dass bei der Relation die Schwierigkeit der ganzen Route vermerkt ist und bei den ways eher die der einzelnen Abschnitte?

    Developer of Elevate mapstyle

    #38654
    Peter47
    Peter47
    Teilnehmer

    Bei der Relation ist keine Schwierigkeit, nur bei den ways.

    #38657
    Tobias
    Tobias
    Moderator

    Ach so, hab’s falsch gelesen. Na dann halt wie bei Wanderwegen/MTB Stücken darstellen: die Schwierigkeit der ways so darstellen, wie sie ist, es gibt eben leichtere und schwerere Anteile in der Route. Routen ggf. seperat neben der eigentlichen Loipe. So ist das vielleicht mit den Dubletten zu verstehen: das eine ist eben die Loipe, das andere die Route.

    Developer of Elevate mapstyle

    1 Teilnehmer(n) gefällt dieser Beitrag
    #38667
    Peter47
    Peter47
    Teilnehmer

    Das mit den leichteren und schwereren Anteilen der Route klingt gut.
    Die Übernahme von Attributen von den ways auf die Route macht wohl nur dann Sinn, wenn diese nicht in der Route angegeben sind, und type, route und piste:type identisch sind, sonst würde man ja evtl. die Attribute z.B. eines Wanderweges übernehmen, der im Winter evtl. auch als Loipe genutzt wird.
    Beim Problem der unterschiedlichen Namen ist mir noch nix eingefallen …..
    lg Peter

    #38715
    ChristianK
    ChristianK
    Verwalter

    Die Doubletten traten bislang deswegen auf weil manche Wege selbst als Pseudorouten getagged ware die auch zusaätzlich als Elemente in Route-Relationen vorhanden waren.
    = die Relationselemente wurden als eigene Wege (Relationsanteil) erzeugt und auch die doppelt getaggten Wege wurden dargestellt = Doubletten.

    Nunmehr werden alle Wege die „piste“ tags haben aus den OSM-Wegen herausgelöst und auf eine Wege umkopiert – nur die „piste“ relaventen tags bleiben dabei erhalten.

    Wobei _ZUR ZEIT NOCH_ die piste:difficulti der Wge durch die RelationsTags überschrieben werden so ein Weg auch Element einer Relation ist.

    HIer wird es demnächst eine Relationspriorität für piste:difficulty geben.
    = wenn ein Relationselement ein eigenes piste:difficulty aufweist hat dies dann Vorrang vor jenem der Relation.

    Das ist in Arbeit und erfordert eine andere Vererbungslogik um dies auch sauber abzubilden.
    Bitte um etwas Geduld, ich will das sauber abbilden und nicht bloss dazupfuschen.

    LG, Christian

    1 Teilnehmer(n) gefällt dieser Beitrag
    #38725
    ChristianK
    ChristianK
    Verwalter

    Das Ganze ist so nicht lösbar.
    = völlig chaotisches mapping.

    Nicht umsonst behandelt Lonvia die Routen stiefmütterlich – schau Dir das mal an.

    Beispiel:
    https://www.openstreetmap.org/way/774530740

    Ist selbst als
    piste:type=downhill
    und
    piste:grooming=classic (wie bitte, ein downhill mit 2 Spuren??)
    getagged

    PLUS ist der Weg member in 2 Relationen.
    Das ist völliger Blödsinn da das Eigentagging des Weges auch als Relation angelegt werden müsste.

    Somit ist es nicht möglich Doubletten zu vermeiden.
    = die Vererbung der piste:difficulty zu den Relationen ist absolut nicht machbar da es möglich ist das die piste:difficulty die auf dem Weg liegt für eine andere piste:type gedacht ist als in der Relation hinterlegte.

    So ein….

    #38736
    Peter47
    Peter47
    Teilnehmer

    Das Ganze ist so nicht lösbar.
    = völlig chaotisches mapping.

    Eine Idee als Diskussionsbasis:
    Zuerst meine Erkenntnisse zu grooming:
    Auswertung piste:grooming für Wintersport: peter@danninger.eu, 8. 4. 2019
    ===============================================================================
    classic 31336 38.27%
    classic+skating 22204 27.11%
    backcountry 10713 13.08%
    classic;skating 10660 13.02%
    scooter 3739 4.57% wie classic, nur schmaler (1 Spur)
    skating 1309 1.60%
    alle anderen sind weit unter 1%
    ——————————————————————————-
    piste:type = downhill classic|~ = normale Piste (Default)
    backcountry = unpräpariert, evtl. Skitouren-Abfahrt
    (mogul = Buckelpiste, kaum verwendet)

    piste:type = nordic classic|scooter
    skating
    classic+skating|classic;skating
    (backcountry = ungespurte Loipe, kaum verwendet)

    wenn piste:type = hike backcountry = Schneeschuh-Tour
    classic = Winterwanderweg

    wenn piste:type = sled backcountry = unpräparierte Rodelbahn
    classic|~ = Naturrodelbahn (Default)

    piste:type = skitour (backcountry, eigentlich redundant)
    Die Abfahrt führt oft nahe der Aufstiegspur, in diesen Fällen nicht mappen.
    Um eine Skitouren-Abfahrt zu mappen:
    piste:type = downhill
    piste:grooming = backcountry
    ==> grooming wird also für viele Winter-Routen verwendet !!!
    Man darf also nur dann Attribute wie difficulty, grooming, …. vom way auf die route (relation) übernehmen, wenn type=route, route=piste und piste:type übereinstimmen !!!
    Nur so verhindert man, dass z.B. difficulty einer Schneeschuhroute auf die Skitour übernommen werden.
    Und zusätzlich muss man klären, wer Priorität hat, aber das ist evtl. bei OSM definiert ?
    lg Peter

    • Diese Antwort wurde vor vor 2 Monaten von Peter47 Peter47 bearbeitet.
    #40222
    Peter47
    Peter47
    Teilnehmer

    Ich habe über den Vorwurf „Chaotisches Mapping“ nochmal nachgedacht.
    Den halte ich für unbegründet, welche Chance haben denn die Mapper?
    Leider gibt es ja keine wirklich sinnvolle Philosophie hinter den OSM-Relationen, welche die Mapper verstehen und beachten könnten. Es gibt weder verständliche Doku noch funktionierende Plausi-Kontrollen bei irgendeiner Mapping-Software.
    Also bleibt den Karten- und Theme-Implementierern nix anderes übrig, als das Beste draus zu machen.
    Ich persönlich habe auch eine Bitte:
    Gibt es eine Möglichkeit, informiert zu werden, wenn eine neue Elevate publiziert wird, damit ich meinen Winter-Fork zeitnah anpassen kann ???

    #40224
    Tobias
    Tobias
    Moderator

    Leider gibt es ja keine wirklich sinnvolle Philosophie hinter den OSM-Relationen, welche die Mapper verstehen und beachten könnten.

    Also das hier finde ich recht klar:
    https://wiki.openstreetmap.org/wiki/Tag:route%3Dpiste

    Tags for the associated ways

    These tags (among others) are properties of the underlying ways (i.e. elements of the relation) and thus should be applied to the ways and not to the relation:

    piste:type
    piste:grooming=*
    piste:difficulty=*
    piste:oneway=*
    piste:lit=*
    lanes=*

    Bei dem veralteten route=ski ist das etwas uneindeutiger:
    https://wiki.openstreetmap.org/wiki/Tag:route%3Dski

    Gibt es eine Möglichkeit, informiert zu werden, wenn eine neue Elevate publiziert wird, damit ich meinen Winter-Fork zeitnah anpassen kann ???

    Einfach das Thema abonnieren:
    https://www.openandromaps.org/oam-forums/topic/elevate-updates-und-testversionen-neuigkeiten

    Developer of Elevate mapstyle

    #40233
    Peter47
    Peter47
    Teilnehmer

    Einfach das Thema abonnieren:

    Als Antwort kommt „undefined“ … aber vielleicht hats ja trotzdem geklappt !

    #40239
    Tobias
    Tobias
    Moderator

    Einfach das Thema abonnieren:

    Als Antwort kommt „undefined“ … aber vielleicht hats ja trotzdem geklappt !

    Christian meinte letztens dazu:

    Wenn Du ein „undefined“ beim Abonnieren/Abbestellen der Benachrichtigungen einzelner Threads/Foren bekommst so klick mit der rechten Maustaste=“in neuen Tab öffenen“ auf die Links – das funktioniert.
    Weis der Kuckuck was hier wieder schief läuft…

    Developer of Elevate mapstyle

    #40453
    Peter47
    Peter47
    Teilnehmer

    Leider gibt es ja keine wirklich sinnvolle Philosophie hinter den OSM-Relationen, welche die Mapper verstehen und beachten könnten.

    Also das hier finde ich recht klar:
    https://wiki.openstreetmap.org/wiki/Tag:route%3Dpiste%5B/quote%5D

    Ich versuche ein Beispiel zu formulieren, und hoffe dass mir ein OSM-Profi weiterhelfen kann:
    Ich will eine Schitour in OSM taggen, oder auch Wandertour, MTB-Tour, egal, das Problem ist identisch.
    Da schon Teilstrecken existieren, soll es eine Relation werden, welche die Teilstrecken einsammelt.
    Jetzt sind die Teilstrecken im Sommer Wanderwege, Radwege, im Winter Schitouren, Schneeschuh-Touren, mit entsprechenden Angaben zu grooming, type, difficulty, ….
    Die Relation sollte also Angaben für die ganze Route mitbringen, da die Teilstrecken meist nicht eindeutig sind.
    Es dürfen nur dann Attribute wie difficulty, grooming, …. vom way auf die route (relation) übernommen werden, wenn type=route, route=piste und piste:type übereinstimmen !!!

    Entspricht das der OSM-Philosophie und wäre das so machbar ???

    #40473
    Tobias
    Tobias
    Moderator

    Ich will eine Schitour in OSM taggen, oder auch Wandertour, MTB-Tour, egal, das Problem ist identisch.

    Die Lösungen können, müssen aber nicht identisch sein. Da WIE das ganze in OSM kartiert wird, immer auch eine Sache von Aushandlungen und Vorschlägen (und Praxis) der Mapper ist, und sich im Idealfall dazu auch eine Beschreibung im Wiki wiederfindet.

    Die Relation sollte also Angaben für die ganze Route mitbringen, da die Teilstrecken meist nicht eindeutig sind.
    Es dürfen nur dann Attribute wie difficulty, grooming, …. vom way auf die route (relation) übernommen werden, wenn type=route, route=piste und piste:type übereinstimmen !!!
    Entspricht das der OSM-Philosophie und wäre das so machbar ???

    Kommt darauf an, siehe oben! Daher – nicht selber überlegen, was ist das sinnvollste, sondern schauen, was ist der aktuelle Stand im Wiki/in den Foren/in der Praxis.
    Deshalb habe ich oben auch das Wiki verlinkt, mit einer dem entsprechenden Vorgehensweise:
    https://wiki.openstreetmap.org/wiki/Tag:route%3Dpiste

    Zum Thema wie etwas am besten kartiert wird sind die OAM-Foren auch nicht die geeigneten Anlaufsstellen, lieber die OSM-Foren, -Mailing-Listen oder Diskussionseiten im Wiki (letzeres nicht unbedingt zur Hilfestellung, sondern eher wenn die Wikiinhalte diskutiert werden sollten).

    Developer of Elevate mapstyle

    #40475
    Peter47
    Peter47
    Teilnehmer

    nicht selber überlegen, was ist das sinnvollste, sondern schauen, was ist der aktuelle Stand im Wiki/in den Foren/in der Praxis.

    OK, alles klar. Wenn es keine Strategie gibt, daher jeder macht was er will, und überlegen sogar unerwünscht ist …. dann ist das aktuelle Chaos ja nicht zu vermeiden …. und Christian hat mit seinem Urteil „Chaotisches Mapping“ ja recht.
    Ich war in meiner beruflichen Laufbahn Projektmanager und hab daher erwartet, daß es bei OSM auch sowas gibt, teilweise sind auch Anzeichen zu erkennen, so ein Chaos hab ich aber nicht vermutet.

    #40477
    Tobias
    Tobias
    Moderator

    Das „nicht selber überlegen“ bitte nicht aus dem Kontext reißen. Ich meinte damit, dass es sinnvoller ist, nachzulesen, was der Konsens in dem jeweiligen Fall ist, anstatt selbst was Neues auszudenken, und damit das Chaos zu vergrößern.
    Und ja, es ist in Teilen chaotisch und manchmal wäre mir auch mehr Steuerung lieber. Jedoch klappt es insgesamt erstaunlich gut. Die Regeln werden nunmal von denen, die sie anwenden gemacht, was auch klare Vorteile hat. Und es gibt dazu auch Vorschläge, wie was zu kartieren ist, mit Abstimmungen. Aber praktisch keine zentrale, lenkende Instanz, alles eher selbst regulierend. Leider manchmal aber zu wenig.

    Developer of Elevate mapstyle

Betrachte 15 Beiträge - 226 bis 240 (von insgesamt 242)

Sie müssen angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.