- AutorBeiträge
- Juni 9, 2019 um 10:41 Uhr #29333ChristianKAdministrator
… welche Karte soll ich neu durchlaufen lassen?
1 Teilnehmer(n) gefällt dieser Beitrag
Juni 9, 2019 um 10:46 Uhr #29335Peter47TeilnehmerWenns nicht zuviel verlangt ist: Alpen,
aber zum Testen würde auch Bayern reichen.
lg PeterJuni 17, 2019 um 14:35 Uhr #29670Peter47TeilnehmerSodale, bin jetzt wieder beim Radeln ….
Südburgenland, Südsteiermark, Ungarn, Slowenien, schaun mer Mal.
Aber wenn ich heimkomme freue ich mich natürlich über neue Karten zum Testen 🙂
Auch meine Bergkameraden freuen sich darauf im nächsten Winter die OAM auch für Winter-Touren verwenden zu können !
lg Peter1 Teilnehmer(n) gefällt dieser Beitrag
Juli 8, 2019 um 16:32 Uhr #29920Peter47TeilnehmerBin bei viel Gegenwind und Hitze ins Meditieren gekommen, konkret über den „scale“ Parameter.
Derzeit hat dieser ja 3 Parameter:
– stroke: witdh und dy werden skaliert
– none: nix wird skaliert
– all: hab ich nicht verstanden ….
Der Faktor ist derzeit: Math.pow (1.5, zoomLevel – 12)
Ich bin immer noch überzeugt, daß man ganz viele zoom-min / zoom-max Angaben in den Themes entbehren könnte, wenn man einen weiterentwickelten „scale“ Parameter hätte.
Meine Überlegung:
– den „scale“ Parameter überall erlauben, wo es evtl. Sinn machen könnte.
– Anstatt stroke/none/all den scale-Faktor angeben, also z.B. „1.5“ als Default, oder „1.0“ als Ersatz für „none“.
– evtl. sogar den Mindes-Zoomlevel „12“ parametrierbar machen.
===> Was denken die Theme-Autoren, Spezialisten, ….. ???
lg PeterJuli 8, 2019 um 21:32 Uhr #29928TobiasAdministratorBei Elevate sind die meisten zoom-min/max aus anderen Gründen, unterschiedliche Darstellungen sind damit nicht hinzukriegen:-)
Das nervigste für mich sind die anwachsenden Punkte wenn stroke-linecap=round, aber das ist ggf. ja schon behoben – ich habe ja scale noch gar nicht integriert. So dringend ist es für mich also nicht..
Wenn dann musst du dich für diese Diskussion an mapsforge-dev wenden.
Developer of Elevate mapstyle
Juli 13, 2019 um 13:16 Uhr #29978Peter47TeilnehmerErgebnis Kurztest neue Bayern-Karte:
Auswertung „grooming“ bei Langlauf-Loipen kann schon wieder a bisserl mehr 🙂
Solange keine Relation im Spiel ist, sieht es gut aus, war aber erst ein „Kurztest“.
Wenn aber Relationen im Spiel sind, gibt es immer noch diese zusätzlichen Dummy-Loipen (difficulty und grooming unbekannt) parallel zur eigentlich richtig dargestellten Loipe.
lg PeterJuli 22, 2019 um 12:04 Uhr #30067ChristianKAdministratorgibt es immer noch diese zusätzlichen Dummy-Loipen (difficulty und grooming unbekannt)
Hallo Peter,
Gib mir bitte noch mal ein paar Relationsnummern – Danke
LG, Christian
Juli 23, 2019 um 11:21 Uhr #30081Peter47TeilnehmerServus Christian,
Die Relationsnummern gehen aus den Screenshots hervor.
Das Problem ist scheinbar a bisserl komplizierter, vielleicht könnte man es auch als Tagging-Fehler abtun, das hilft aber leider nicht.
Soweit ich das verstehe, tritt das Problem immer dann auf, wenn im Eltern-Element was anderes angegeben ist (oder Angaben fehlen) als in der verknüpften Relation.
Beispiel für korrekte Loipe: Loipe Lenggries
Beispiel für fehlerhafte Loipe: Loipe Dietramszell
Vielleicht macht es Sinn, vom Elternelement nur Angaben zu übernehmen, die in der Relation fehlen, z.B. den Namen ?
Sollte für alle Relationen zutreffen, nicht nur Langlauf, evtl. sogar nicht nur Winterrouten ?
lg PeterJuli 23, 2019 um 18:32 Uhr #30092Peter47TeilnehmerHab wieder was gefunden, das ich nicht ganz durchblicke.
Die Schnell-Installations-Links.
Orux schaut ja einfach aus, verweist direkt auf eine .zip Datei.
Aber gibt es da Konventionen, Namen bzw. Inhalt der .zip ?
Locus macht offensichtlich einen Umweg über eine .xml Datei, landet aber auch bei einer .zip Datei.
Gibts Konvention für den Inhalt ?
Kann ich auch .zip anbieten OHNE die ?????_LE Verzeichnisse bzw. Dateien ?lg Peter
Juli 24, 2019 um 07:56 Uhr #30094ChristianKAdministratorFür das Action_Script Interface gibtts sogar eine Anleitung:
https://docs.locusmap.eu/doku.php?id=manual:advanced:customization:actionsHier eines von OAM:
<?xml version='1.0' encoding='UTF-8'?> <locusActions> <download> <source><![CDATA[http://download.openandromaps.org/mapsV4/europe/Alps.zip]]></source> <dest><![CDATA[/mapsVector/Alps.zip]]></dest> <after>extract|deleteSource|refreshMap</after> </download> <download> <source><![CDATA[http://download.openandromaps.org/themes/Elevate4_Locus.zip]]></source> <dest><![CDATA[/mapsVector/_themes/Elevate4_Locus.zip]]></dest> <after>extract|deleteSource</after> </download> </locusActions>
LG, Christian
1 Teilnehmer(n) gefällt dieser Beitrag
Juli 24, 2019 um 08:49 Uhr #30096ChristianKAdministratorBetreffend der Doubletten:
Das ist klassisches Fehltagging.
Eine Relation ist dazu da die Tags die auf den einzelnen Wegen fehlen zu ergänzen.
Sind die Tags in der Relation UND im Way enthalten wirds teuflisch.Ich werde jetzt mal den PC abschalten denn dieses Deppenproblem betrifft sicher auch die neue Relationsauflösung der Rad.- und Wanderwege die schon sehr weit fortgeschritten ist.
Im Grunde würde dies bedeuten das ich …..
… eine UnMenge zusätzlicher Arbeit bei der Erstellung der Programme und dann jedes Monat beim Update jede Menge Rechenzeit investieren muss nur weil sich niemand auch nur einen Deut um die Regeln schert.Juli 24, 2019 um 12:53 Uhr #30098Peter47TeilnehmerServus Christian,
Vielleicht hilft die Anlage ja weiter.
Hinweis: Auch bei der fehlerfreien Loipe sind (identische) Tags im Way und der Relation definiert.
Wäre es nicht machbar und vielleicht auch logisch, wenn Tags in der Relation evtl. Tags im Way overrulen würden?
Bei teilweise dutzenden Relationen evtl. von verschiedenen Autoren kann doch nur schwer ausschließen, daß es Überschneidungen gibt, das sind einfach nur Spekulationen, ich kenne die OSM-Regeln (leider) zu wenig.
lg PeterJuli 24, 2019 um 13:59 Uhr #30102Peter47TeilnehmerHab soeben noch was gefunden:
Wenn im Way und in der Relation korrekte aber unterschiedliche Tags für difficulty und grooming definiert sind, dann werden beide in diesem Abschnitt angezeigt, also Doubletten, kommt leider öfters vor.
lg PeterJuli 24, 2019 um 15:23 Uhr #30107ChristianKAdministratorWäre es nicht machbar und vielleicht auch logisch, wenn Tags in der Relation evtl. Tags im Way overrulen würden?
Gerade die difficulty ist etwas das eher dem WAY zugeordnet sein sollte denn eine Relation umfasst idR sowohl (zB) die einfachen Loipen in der Ebene als auch die steilen Anstiege/Abfahrten.
Wäre es nicht machbar und vielleicht auch logisch, wenn Tags in der Relation evtl. Tags im Way overrulen würden?
Mal rein Prinzipiell:
Der Way auf den sich eine Relation referenziert bleibt als solcher unverändert erhalten (was die Probleme verursacht wenn die TAGs sowohl in der Relation als auch im Way vorkommen) – es wird eine Kopie mit den TAGS der Relation angelegt.Wenn mehrere Relationen auf einen Way referenzieren dann gibt es anschliessend genau so viele Kopien des WAYs wie Relationen – ohne Verbindung untereinander. Kopien werden dann nacheinander / übereinander gerendert.
Wie (dx versetzt nach difficulty zB) das bestimmt die Theme.Die Pisten sind ein spezielles Ding da im Prinzip kaum „echte“ Wege als Basis dienen sonder eigentlich kopien der Relationen. Odor vicev versa: Zuerst eine Pseudorelation als WAY und dann eine Relation die auf die Pseudorelation refferenziert.
Warum: Lonvia akzeptiert nur echte Relationen, ich schätze hier wurden 1way_Relationen angelegt um die Pisten eben in Lonvia zu sehen – ohne die underlaying ways (Pseudorelationen) zu bereinigen.Ich werde ein Tag einführen mit dem klar ist das hier eine Piste zur Basis einer Relation vorliegt:
render_layer=piste
Ich würde vorschlagen dies als kapselnde RULE zum Rendern der Pisten zu verwenden
Damit ist die Kompatibilität mit Lonvia/Waymarkedtrails hergestellt.Das gleiche Tag wird es auch für MTB/HIKE/CYCLE Relationen in OAM V5 (Winter/Frühjahr 2019/2020) geben
Das mit den Doubletten Relation/Way bei difficulty und grooming ’schau ich mir noch an.
LG, Christian
Juli 24, 2019 um 16:35 Uhr #30109Peter47TeilnehmerDanke für die ausführliche Erläuterung …. ich muß noch viel lernen 🙂
Hab grad wieder a bisserl getestet:
Ein Stück Langlauf-Loipe (96217880): easy – classic+skating
ist Bestandteil von:
Loipe Kloo-Ascher Runde: intermediate – classic;skating
(Loipe) Route 36: advanced – classic;skating
Wanderweg W8: grade2
Der Loipenabschnitt wird ohne Doublette, aber m.E. nicht korrekt dargestellt:
advanced – classic;skating, sollte aber easy – classic+skating sein.
Eine kilometerlange Loipe besteht halt aus einfachen und schwierigeren Teilstücken, spricht das nicht für das overrulen, damit jedes Teilstück korrekt angezeigt wird ?
Das ist sicher kein Winter-Routen Problem.
Ist der Fernwanderweg GR20 in Korsika nun easy, medium oder advanced?
Er hat von allem etwas, also müssen auch alle Teilstücke korrekt getagged und angezeigt werden!
lg Peter - AutorBeiträge
- Sie müssen angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.