-
AutorBeiträge
-
Oktober 22, 2017 um 09:11 Uhr #20650Hermann FreibergerTeilnehmer
Mir ist folgendes aufgefallen:
Wenn man im Gebirge wandert, wechselt manchmal die Anzeige der Gipfelnamen etwas unorthodox. Ein Beispiel:
Im Sengsengebirge der „Hohe Nock“: ist im Umkreis einer der höchsten und markantesten. Bei kleineren Auflösungen wird er gar nicht angezeigt, obwohl ein paar kleinere und für die Orientierung weniger bedeutende Berge angezeigt werden. Wenn man hineinzoomt, dann taucht manchmal zuerst die Höhenangabe auf und dann erst der Name. Wäre es beim Rendern möglich, ein wenig z.B. auf die Höhe zu achten und die höchsten Berge in der Anzeige zu bevorzugen?Die Angabe bezieht sich auf die Karte Austria, das Kartenthema Elevate LE.
Im Anhang:
1x.png – zeigt die Höhenangabe, Dann hineinzoomen:
2x.png – zeigt gar nichts, Weiter hineinzoomen
3x.png – zeigt Gipfelnamen und HöheOktober 22, 2017 um 20:52 Uhr #20675TobiasAdministratorDas sind grundsätzlich drei Probleme:
– Gipfel werden angezeigt, soweit Platz ist, es können nicht „von Hand“ gewählt werden wie bei gedruckten Karten
– Es gibt keine Daten, die „wichtige“ Gipfel kennzeichnen. Höhe alleine ist unzureichend, so ist z.B. die 1998m hohe Pyramidenspitze im Zahmen Kaiser ist wichtiger als die 2002m hohe Vordere Kesselschneid gleich daneben.
– Locus kann mit seiner eigenen abgewandelten Mapsforge Version nicht priorisieren, was angezeigt wird. Dazu braucht es die aktuellere Original Mapsforge Version, an die kommst Du in Locus nur, wenn Du die mehrsprachigen Karten verwendest (trotzdem bleiben die Kartendarstellung im Vergleich zu anderen Apps fehlerhaft wegen zu kleiner Kartenkacheln bei hoher Pixeldicht). Auch mit diesen Karten können wichtige Gipfel nicht bevorzugt angezeigt werden, jedoch wird der Name gegenüber der Höhe bevorzugt. Nur wenn eben keine Platz für den Namen ist, kann es sein dass nur die Höhe dargestellt wird.Developer of Elevate mapstyle
Oktober 22, 2017 um 20:55 Uhr #20677TobiasAdministratorAch ja, der Höhenwert kann im übrigen nicht mit der Namensanzeige verknüpft werden. Wenn dann müsste es ein Wert sein wie importance=very.
Developer of Elevate mapstyle
Oktober 27, 2017 um 10:58 Uhr #20726SonnyTeilnehmerGute Beobachtung und auch ein klasse Beispiel dieser Screenshot. Der Hohe Nock ist ja der höchste Gipfel des Sengsengebirges, und sollte zwecks Orientierung in der Karte theoretisch vor allen anderen Gipfelnamen erscheinen, noch vor „Seekopf“ oder „Haltersitz“.
Genau dieses „Phänomen“ ist für mich aus Anwendersicht derzeit noch das größte Problem von Vektorkarten ala OAM gegenüber Rasterkarten wie die Amap oder die Kompass. Wenn ich rauszoome geht durch das Fehlen von den wichtigsten Gipfeln (und auch Ortsbezeichnungen) sehr schnell die Orientierung verloren wo man sich auf der Karte gerade befindent.
Das selbe gilt wiegesagt auch für Ortsbezeichungen. Nicht selten wird zwar irgendeine unbeduetende Ortschaft oder Stadtteil beschriftet nicht aber die dazugehörige Stadt oder Gemeinde.
Ich habe mir die Stelle im Gebirge auch mit der Locus-eigenen Karte „LoMaps Austria“ angeschaut, auch hier gibts das selbe Problem.
@Tobias: gibts derzeit für die Verwendung in Locus überhaupt irgendwelche Karten und geeignete Themes, die diesem Problem einigermaßen Herr werden, oder wird das prinzipbedingt wie oben von dir erklärt nie bei Vektorkarten funktionieren?Oktober 27, 2017 um 22:08 Uhr #20734TobiasAdministrator@tobias: gibts derzeit für die Verwendung in Locus überhaupt irgendwelche Karten und geeignete Themes, die diesem Problem einigermaßen Herr werden, oder wird das prinzipbedingt wie oben von dir erklärt nie bei Vektorkarten funktionieren?
Wie gesagt, nimm die multilingual Karten und Elevate für Locus. In Elevate ist sowohl LE als auch das normale Elevate enthalten. Letzteres kommt in Locus nur bei ML Karten mit einer neueren Mapsforge Version zum Einsatz, die auch „priority“ unterstützt. Dadurch ist das Ortsproblem praktisch behoben, nur an Kachelkanten kann es haken – und an denen gibt es in Locus wegen der festgeschriebenen Kachelgröße von 256px sehr viele.
Am besten funktioniert das ganze in Apps mit aktiviertem „Label Layer“ wie Cruiser, da ist auch das Kachelkanten Problem gelöst. Dort in der nicht-GL Version unter Settings->Map->Rendering->Advanced einstellen, dann ist der Label Layer aktiv.
Bevorzugt werden dann zuerst Hauptstädte (Länder>Staaten), dann Großstädte, Städte, Dörfer usw.Für die Gipfel bräuchte nun noch ein geeignetes Unterscheidungsmerkmal, dann ist das auch machbar. Aber wahrscheinlich müsste das berechnet werden, wie z.B. hier:
http://wiki.openstreetmap.org/wiki/User:Maxbe/Kartenversuch#Dominanz_von_Gipfeln
https://github.com/k127/osm-peak-dominance
Keine Ahnung, ob das im Kartenerstellprozess noch machbar ist.Developer of Elevate mapstyle
Oktober 28, 2017 um 15:00 Uhr #20742ChristianKAdministratorKeine Ahnung, ob das im Kartenerstellprozess noch machbar ist.
Das geht sicher für kleine Karten, Global = Planet.osm ist das eine echte Herausforderung.
Ich müsste hier einen eigenen Rechner mit Linux + GIS_DB aufsetzen und für die ganze Welt diese Daten rechnen.
Sorry, das ist für mich nicht möglich, dafür fehlen mir – ehrlich gesagt – sowohl von der Mathematik als auch der Programmierung her die persönlichen Voraussetzungen, Nobody is perfect 😉Wenn das jemand machen könnte und diese Daten direkt über ein Tag in die OSM-Datenbank einpflegt bzw. als CSV (OSM_ID des summits, Prominenz_Stufe) zur Verfügung stellt würde ich das klarerweise übernehmen.
Wobei – soweit ich das Ganze verstanden habe sind das keine Absolutwerte sondern Relativwerte innerhalb eines bestimmten Gebietes. Inwieweit man das allgemein gültig in eine Klassifizierung einbringen kann – wie gesagt, da müsste ein berufenerer als ich ans Werk.Anyone??
Sonst sind diese Methoden _äusserst_ Interessant, vor allen die Herangehensweise ist faszinierend.
Danke für die Links!VG
ChristianOktober 28, 2017 um 22:44 Uhr #20745TobiasAdministrator@ChristianK – ich hab da noch weniger Ahnung, deshalb der unbedarfte Vorschlag… eigentlich war ich auf der Suche, ob inzwischen Prominenz/Dominanz von Gipfeln gekennzeichnet werden, da bin ich über das gestolpert.
Developer of Elevate mapstyle
Oktober 29, 2017 um 07:47 Uhr #20752ChristianKAdministratordeshalb der unbedarfte Vorschlag
Die Idee ist toll und lässt mir keine Ruhe, ist auf der TODO-Liste.
Ich werde mal die summits aus dem planet.osm rausfiltern, dann sehen wir den Umfang der ganzen Sache.LG
ChristianOktober 29, 2017 um 10:10 Uhr #20754ChristianKAdministratorHallo @Tobias
Ich habe bei der Durchsicht der natural=peak noch so einiges gefunden.
zb. zusätzlich zu natural=peak
<tag k="tourism" v="viewpoint"/>
<tag k="place" v="locality"/>
<tag k="man_made" v="survey_point"/>
etc.Am häufigsten kommt der survey_point vor.
Eigentlich könnten wir diese Zusatztags die ev. den Peak verdecken eliminieren denn das ein peak uA ein viewpoint ist sollte eigentlich klar sein.
Oft gibt es auch den tag man_made=cross, das könnte man doch in verbindung mit natural=peak zu summit:cross=yes transformieren
Die man_made=tower würde ich drinnen lassen.
Was meinst Du dazu?
… und in Schottland gibt bereits einige „prominence“ tags 🙂
VG
Christian<translation> <name>clear peaks from add. tags </name> <description>clear ele tags </description> <match type="node" mode="and"> <tag k="natural" v="peak"/> <match mode="or"> <tag k="place" v="locality"/> <tag k="man_made" v="survey_point"/> <tag k="tourism" v="viewpoint"/> </match> </match> <output> <copy-unmatched/> <tag k="natural" v="peak"/> </output> </translation> <translation> <name>unify summit cross </name> <description>.</description> <match type="node" mode="and"> <tag k="natural" v="peak"/> <match type="node" mode="or"> <tag k="man_made" v="cross"/> <tag k="man_made" v="summit_cross"/> </match> </match> <output> <copy-unmatched/> <tag k="natural" v="peak"/> <tag k="summit:cross" v="yes"/> </output> </translation>
Oktober 29, 2017 um 10:21 Uhr #20756TobiasAdministratorDas habe ich eigentlich alles schon auf Theme-Ebene gelöst:
– survey_point wird in Elevate gar nicht angezeigt, von daher eh kein Konflikt.
– Kreuze:<rule e="node" k="summit:cross|man_made" v="yes|cross" zoom-min="14">
– Viewpoint wird nur angezeigt, wenn kein natural=* vorkommt:<rule e="any" k="tourism" v="viewpoint"> <rule e="any" k="natural" v="~" zoom-min="15">
– Ansonsten ist eh alles über priority geregelt, wo halt wieder die Locus engine das nachsehen hat
Problem bei prominence (wie auch importance): laut Wiki abandoned
Developer of Elevate mapstyle
Oktober 29, 2017 um 10:27 Uhr #20758TobiasAdministratorAch ja, locality wird auch nur unter bestimmten Umständen angezeigt, bei Gipfel auch nicht da natural=*
<rule e="any" k="place" v="locality" zoom-min="15"> <rule e="any" k="mountain_pass|natural|tourism" v="~">
Developer of Elevate mapstyle
Oktober 29, 2017 um 11:10 Uhr #20760ChristianKAdministratorJa, ich hatte die Theme schon lange nicht mehr im Editor …
Somit lässt sich hier nichts mehr optimieren.Es sind übrigens 478761 Peaks im Planet-File.
Oktober 30, 2017 um 15:16 Uhr #20788SonnyTeilnehmerEcht interessant, dass sich da jemand schon Gedanken gemacht hat wie man die „Eigenständigkeit“ von OSM-Gipfeln ermitteln kann und wie man diese in Karten verwendet. Ich habe mir den OSM-Thread durchgelesen und auch die vom User „maxbe“ erzeugten Karte(n) angeschaut:
http://geo.dianacht.de/tests/gipfel.php
http://geo.dianacht.de/tests/dominanz.php
https://geo.dianacht.de/topo/Es gibt einige – auch komplizierte – Berechnungsversuche der Eigenständigkeit von Gipfeln anhand von seiner Dominanz, Schartenhöhe (=Prominenz), Höhe und jeweils noch ein paar relativen Werten wie z.b. Prominenz/Höhe etc.
Aber gerade für die Anwendung in Karten für das Problem: „zu viele Gipfel auf zu engem Raum – welcher soll eingezeichnet werden“, kann man sich meiner Meinung nach wirklich ganz auf den Wert „Dominanz“ konzentrieren, wie es maxbe bei seinen Karten gemacht hat.
Er hat in seiner 2. Karte zwei mögliche Ermittlungsverfahren benutzt:
1.) Bestimmung der Dominanz anhand des Abstand zu anderen Gipfeln (= einfach, schnell).
2.) Bestimmung der Dominanz anhand des Abstands zu Höhenlinien eines DTM (wie die Dominanz ja eigentlich definiert ist).
Wahrscheinlich reicht für den OAM-Zweck aber sogar die einfachere 1)- Methode. Besser als die derzeitige Situation ist es bei weitem.Die Gipfelauswahl in seiner 3. Karte überzeugt jedenfalls ziemlich, die Haupfgipfel jedes Gebirges sind eingezeichnet, sowie dominate Gipfel in genügend Abstand zu diesen Hauptgipfeln ebenfalls. Alle anderern Gipfel werden in diesem Zoomlevel ausgeblendet.
Bei der OAM in Locus (Multilanguage, Elevate-Theme) hingegen werden nichtmal die höchsten Gipfel des Sengsengebirges (Hoher Nock, rechts oben) und des Toten Gebirges (Großer Priel, links unten) eingezeichnet, dafür jede Menge Nebengipfel.
Die Frage ist ob du Christian programmtechnisch, ev auch mit der Hilfe von maxbe, bewerkstelligen kannst die Dominanz eines Gipfels zu ermitteln – ähnlich wie er in seiner Karte. Jedenfalls wäre das ein großartiger Übersichtsgewinn und Alleinstellungsmerkmal von deinen OAMs 😉
Oktober 30, 2017 um 20:22 Uhr #20793ChristianKAdministrator/*Es sind übrigens 478761 Peaks im Planet-File.*/
MaxBe hat selbst geschrieben das diese Methode nur für kleine Karten möglich ist.
Wenn jemand das für das ganze Planet-File machen kann baue ich das selbstverständlich ein.Ich wüsste nicht wie das zu bewerkstelligen ist, auch nach einem WE nachdenken 😉
Oktober 31, 2017 um 16:45 Uhr #20802mbe57ModeratorKennt jemand MaxBe, und würde er den Algorithmus für Variante 1 Mitteilen ?
Ich halte das für eine 1/2 Mio Gipfel für machbar. In Kacheln geeigneter Größe (muss man überlegen/probieren) gruppieren, immer mit den Nachbarkacheln inkl. vergleichen. Dann explodiert die Laufzeit nicht. -
AutorBeiträge
- Sie müssen angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.