- Beiträge
Hallo,
leider sind in der aktuellen sachsen.map die Fahrrad-Routen im Zoomlevel 12 irgendwie beschädigt oder sorgen zumindest für Darstellungsprobleme. Zwei Screenshots zum Vergleich zeigen das Problem (oben aktuelle map, unten sachsen.map vom Juni 2014). Beides mit dem aktuellen OAM cycle theme in Orux 6.0.9 (wobei dies ein Problem ist was bei diversen themes zu beobachen ist). Zoomt man näher heran (z.B. Level 13) sieht es normal aus.
Hallo
Ich habe die Karte in locus gecheckt und sie ist ok.
In orux wird der zoom Level seit einigen Versionen etwas seltsam angezeigt – ein mischmasch aus echten vector Level und digital zoom.
Zumindest habe ich das so nebenbei mitbekommen.Vg
ChristianHallo ich muss das leider noch einmal aufrühren, weil ich noch nicht so richtig schlau aus der ganzen Sache geworden bin. Vielen Dank erstmal Christian für die Antwort und natürlich generell für deine Arbeit. Das Problem scheint jedoch nicht für orux spezifisch, sondern ich habe es unter locus reproduziert. Ich weiß nicht, ob dies ein Problem der Karte ist oder ein Bug in mapsforge (auch in der aktuellen orux beta mit mapsforge 0.5.x). Da es aber mit früheren Karten von openandromaps funktioniert lag es für mich erstmal nahe, dass es ein Kartenproblem sein könnte. Aber es kann natürlich auch ein Problem in mapsforge sein, dass mit irgendwelchen neuen Tags nicht zurecht kommt (oder etwas ganz anderes).
Um auszuschließen, dass die Datei beim Download kaputt gegangen ist habe ich sie noch einmal runtergeladen und entpackt und die Prüfsummen (6c7b7afab63664252a94cdd9e5a502f3 md5) verglichen (auf dem PC und auf den Smartphones).
Noch eine Anmerkung: Das ganze mit dem Elevate Theme zu untersuchen ist so glaube ich wenig sinnvoll, da zumindest bei mir (moto defy) auf Level 12 (orux) überhaupt keine Radrouten gerendert werden (vermutlich ist das auch so gewollt) und daher tritt dort auch das Darstellungsproblem nicht auf.viele Grüße
jjIn Locus musst Du die neue Elevate Theme 2mal aufrufen.
das erste Mal wird sie aktiviert und bein 2ten Mal kannst Du dann auswählen ob Du generell Rad/Wanderrouten darstellen willst und welche Elemente (Overlays).
Das funktioniert nur halt auf 2 mal – das ist noch etwas buggy.Das Ganze muss auf allen Geräten mit Locus/Orux funktionieren nur eben in Orux stimmen die ZoomLevel nicht – ich weis nicht was sich Orux dabei gedacht hat.
@Tobias: Gabs da nicht auch einen Thread im OruxForo?Bei mir funktioniert alles auf dem XperiaActive/SamsungTab4/Virtualbox. Acu die Routen sind IMO korrekt in der OSM eingezeichnet.
Sorry, ich kann das nicht nachvollziehen, ich hätte Dir gerne geholfen nur weis ich wirklich nicht was auf Deinen Geräten los ist – wie gesagt in ORUX gibts ein Problem mit der Anzeige der ZoomLevel NICHT mit den Karten an sich.Was ich machen musste war die Openandromaps_Themes in Locus auf der VirtualBox neu installieren – keine Ahnung warum.
Hallo,
Christian ist auf der richtigen Spur.In OruxMaps wird seit der Version 6.0 statt dem im Theme und Karte angegeben Zoomlevel ein niedrigerer angezeigt, also was bei Dir als 12 angezeigt wird ist eigentlich 11. Der Hintergrund: OruxMaps verwendet eine größere Kachelgröße bei Mapsforge Karten (512px statt 256px, kein digitaler Zoom im Spiel), damit diese auch bei modernen Smartphones mit hohen Pixeldichten gut lesbar sind. Damit das ganze problemlos umschaltbar bleibt mit anderen Karten die noch 256px Teile verwenden (also bei gleichem Zoomlevel immer der selbe Ausschnitt zu sehen ist), hat Orux den Zoomlevel bei Mapsforge Karten verändert.
Die „zerstückelten Routen“ (lokal und regional) sind deshalb bei OruxMaps in Zoomlevel 12 (eigentlich 11!) in Andromaps_HC sichtbar, weil sie eigentlich gar nicht für diesen Zoomlevel in der Karte angelegt sind. Ein Bug in den Mapsforge Karten zeigt jedoch Eigenschaften auch schon früher an, wenn die Elemente, an denen die Eigenschaften definiert sind (hier: bestimmte Straßen) auch schon früher in den Karten enthalten sind. Wenn die Route nun auf eine andere Straße wechselt, die noch nicht angezeigt wird, wird auch die Route nicht angezeigt (wie es eigentlich auch von der Kartendefinition her vorgesehen ist.)
Mit Elevate umgehe ich das (nicht nur bei den Routen), in dem ich den Zoomlevel zur Anzeige der Route begrenze. Mit Elements ist das ganze wiederum bewusst ausgeschaltet, so dass da die selben „zerstückelten Routen“ auftreten.
Daher war das eigentlich schon immer so, nur der angezeigt Zoomlevel in OruxMaps ist nicht auf andere Programme wie Locus übertragbar und führt da zu Verwirrung.
Warum jetzt die 2014er Karte da sich so unterscheidet kann ich nur Mutmaßungen anstellen – entweder hat Christian da den Zoomlevel der Routen/Straßen im Tagmapping verändert, oder die Straßenart, auf der die Routen liegen, haben sich in den OSM Daten geändert.
Edit: wenn man genau auf den Screenshot von der 2014er Karte schaut, sieht man auch die unter den Routen liegenden Straßen (weshalb die Routen überhaupt angezeigt werden), die werden in der aktuellen auch nicht angezeigt.Viele Grüße,
TobiasDeveloper of Elevate mapstyle
Ich habe in den Andromaps_Themes jetzt auch die lcn/rcn auf level 12 gesetzt, damit ist die Sache dann weniger verwirrend.
Hallo Christian und Tobias,
es sind seit meinem letzten Schreiben 3 spannende und erfolgreiche Jahre für OAM vorübergegangen für die ich euch zunächst ganz herzlich danke. Trotzdem möchte ich erneut die unvollständigen Fahrradrouten (Zoomlevel kleiner 12) thematisieren mit dem Ziel OAM ein Stück besser zu machen.
In den 3 Jahren sind die Displays größer und hochauflösender geworden, die Arbeitsspeicher größer und die Rechenleistung stärker. Ich finde es einfach absolut unpraktisch und auch nicht mehr zeitgemäß (in Anbetracht der Leistungsfortschritte beim Smartphone und der Tatsache, dass es 2014 ja auch schon ging) dass Radrouten(stücke) (rcn, lcn) verschwinden wenn man aus Stufe 12 heraus zoomt und nur noch (inter)nationale Radrouten gezeigt werden. Es ist klar dass regional Radrouten in der Regel nicht mehr gut auf Level 8 dargestellt werden können (weil es zu viele davon geben könnte), aber ich finde bis level >=10 ist es sinnvoll rcn darstellen zu können und bis level >=8 lcn. Ich erlebe es öfters, dass ich lange Tagesrouten aufgrund des Wetters unterwegs umplanen muss. Das ist in Zoomlevel 12 einfach nicht möglich. Die theme designer können wenn es ihnen zu viel Information ist dann auch noch Feintuning betreiben, indem sie z.B. rcn erst ab Level 9 oder 10 darstellen.
Was schlage ich also vor:konzeptionell: Dass man die Karten so erstellt, dass Wege die mit den Radrouten relationen versehen sind bereits in niedrigeren Zoomleveln mit exportiert (gespeichert) werden auch wenn der eigentliche Weg in dieser Zoomstufe normalerweise nicht exportiert werden würde, sodass diese Radrouten dann dargestellt werden können. Es scheint dies ja für die (inter)nationalen Routen (ncn und icn) gemacht zu werden, denn diese verschwinden ja auch nicht, denn es werden die darunter liegenden Straßen angezeigt auch in der Zoomstufe 7 wenn man im Elements theme den layer für die Radrouten deaktiviert (siehe die zwei Screenshots). Um dieses “Problem” mit einem Style einfach zu lösen, könnte man optional zusätzlich für diese Abschnitte die normalerweise aber nicht exportiert würden ein spezielles tag (z.b. forced-export) mit anheften, sodass man diese mit einer einzigen Regel auch unsichtbar machen kann, ohne wissen zu müssen ab welcher Stufe diese Art von Weg normalerweise exportiert werden würde. Aber das wäre wie gesagt optional.
methodisch:
Mir ist nicht bewusst welches genau das Problem ist, was z.B. dazu führte das Routen des Typs lcn im aktuellen Setup (wie wir ja bereits 2015 festgestellt haben) nun nicht mehr ab Level 10 vollständig erscheinen. Da ich den OAM-Code nicht online gefunden habe weiß ich nicht, ob es
– im Mapsforge Writer,
– in der Mapsforge Render Library oder
– in der OpenAndroMaps-Konfig für den Mapsforge Writer selbstliegt. Fakt scheint: es ging 2014, und es gibt einen Weg dies für die (inter)nationale Routen zu realisieren.
Methodisch bietet sich (mit meinem begrenzten Wissen zum Problem und eurem Setup) nun die folgenden Optionen:
1. Ihr findet heraus wie die Strategie / Workaround für die (inter)nationalen Routen gemacht wird und erstellt dann analog dazu die ML Karten (die sind ja eh größer) für die Bundesländer (später evtl. auch für die Länderkarten) so, dass lcn Routen ab Level 8, und rcn Routen ab level 10 mit exportiert werden. Die Themer und versierte Endnutzer können dann selbst entscheiden ab wann sie konkret die Routen darstellen wollen.2. man stellt sich die Frage wie “open” openandromaps sein soll, und ob ihr euer setup und den workflow auf github einstellt. Mit eurer Hilfe (insbesondere Erklärungen und guter Doku zum Setup) könnte ich versuchen dies dann für die Radwege zu realisieren aber prinzipiell könnte dann auch jeder mit Informatik Know-How OAM Karten individuell für sich rendern und dies z.B. in ähnlicher Form für Wanderwege, Wasserwege oder Eisenbahnschienen zu realisieren, (je nachdem was sein spezielles Interesse ist), was prinzipiell gut ist, aber ich nicht weiß ob dies auch negative Auswirkungen für das OAM Projekt haben könnte.
3.Wenn es definitiv ein Bug im MapsforgeWriter ist, wirkt man mit einer Issue oder sogar einem PullRequest auf die Entwickler von Mapsforge ein diesen Bug zu fixen oder ggf. ein konfigurierbares Feature analog zu den nationalen Routen zu ermöglichen.
Ich hoffe wir finden dafür eine Lösung um OAM ein Stück attraktiver für Radfahrer zu machen.Viele Grüße
jjMir ist nicht bewusst welches genau das Problem ist, …. weiß ich nicht, ob es
– im Mapsforge Writer,
– in der Mapsforge Render Library oder
– in der OpenAndroMaps-Konfig für den Mapsforge Writer selbstDas Problem ist das el Limits für Anzahl der darstellbaren Elemente gibt. – Wie viele das in welchen BaseZoomLeveln sind ist nicht bekannt. Wenn ich die rcn und lcn in einen Level <12 mit aufnehme dann bedeutet das das ich mit diesen den BaseZoomLevel 2 in der Regel überlaste was zu weissen Kacheln führt.
In "normal" gemappten Regionen mag das noch funktionieren, in Deutschland wird es Probleme geben. Somit verlege allen nicht wirklich benötigten Tags in Level >=12.Mir selbst wäre es auch lieber die rcn ab Level 10 am Smartphone zu haben.
Sieh Dir mal DAS hier an, hier ist – salopp gesagt – jeder zweite Weg als Radweg getagged:
https://cycling.waymarkedtrails.org/#?map=9!51.4877!5.4211Und es wird auch nicht zwischen rcn und lcn unterschieden, also ist jeder noch so unwichtige lokale Radweg als rcn eingetragen. Leider scheitert hier jeder noch so ausgetüftelte Denkansatz an der OSM-Realität.
Wie gesagt ich hätte gerne die – korrekt getaggten rcn’s in meiner Heimat ab Level 10, nur…
LG, Christian
Hallo JJ,
noch als Ergänzung: mit den modernen Smartphones siehst Du sogar mehr von einer Route bei ZL12 statt weniger. Bei einer vernünftigen Mapsforge Implementierung werden zwar die Kacheln an die Pixeldichte angepasst, so dass pro Quadratzentimeter Display genau so viel Routen sichtbar sind wie 2014 – dafür hat Dein Smartphone aber viel mehr Quadratzentimeter Display.
Bei Locus ist da ein eigentlich großer Nachteil auch noch ein Vorteil: das ist bei der Kachelgröße 256px entsprechend 160ppi hängen geblieben, d.h. Du siehst bei 480ppi dreimal so viel Karteninhalt (dafür leider sehr dicht gedrängt und mit sehr vielen Kachelkanten, die weitere Probleme verursachen).
Viele Grüße,
TobiasDeveloper of Elevate mapstyle
Hallo Christian,
vielen Dank für die schnelle, ausführliche Antwort. Es freut mich, dass prinzipiell das Interesse für Radrouten in gröberen Zoomstufen da ist, und es im Moment “nur” an technischen Hürden liegt. Also wie ich das aus deiner Schilderung verstehe ist es ein Problem in der mapsforge render library (nur für android? oder hat man das gleiche Problem mit der reinen Java Implementierung für PCs mit z.B. Cruiser Desktop, oder werden die tiles doch schon korrupt serialisiert im MapsForgeWriter?) Hast du dazu schon eine Issue oder Mail auf der mapsforge-dev Mailinglist gepostet? Ich habe nur folgendes gefunden https://groups.google.com/forum/#!topic/mapsforge-dev/kQKfCMGk2Ec, welches aber so wie ich verstehe nicht an der Menge an Wegen sondern an zu vielen tags und korrupten ways lag. Für die unbekannte Begrenzung könnte ich mal eine Issue an die maps-forge devs stellen, habe aber in oben erwähntem Post etwas von Short.MAX_VALUE (also 32767) gelesen, allerdings bin ich mir nicht sicher, welche Begrenzung du meinst und welche dich konkret interessieren, die Anzahl an Ways pro tile oder Nodes per Way (letzteres müsste Short.MAX_VALUE sein pro WayCoordinateBlock). Ich habe anhand der Format Spec und etwas Schauen im code eine erste Übersicht erstellt (s.unten, müsste ich noch von mapsforge-devs gegenchecken lassen). Die größte Limitierung scheint, dass ein Tile momentan beim Lesen nicht größer als 8 MB sein kann. Hast du eine Testkarte wo die Tiles, weiß bleiben aufgrund von zu viel “Rad”wegen?Wofür das BasezoomLevel ist verstehe ich leider im Moment nicht und auch die docu ist dazu leider nicht hilfreich. Aber so wie ich das verstehe könnte man wenn das wirklich ein Problem wäre mehr Zoomintervalle definieren, die weniger Zoomstufen abdecken und damit verhindern dass zu viele Ways in unteren leveln sind?
Das Problem mit anderer Klassifizierung von Radrouten in anderen Ländern (insbesondere das Niederlande Beispiel was du gesendet hast) leuchtet mir ein, daher ja auch mein Vorschlag es nur für die Bundesländerkarten (von Deutschland) zu tun, denn da gibt es in OSM ja klare Guidelines betreffs lcn und rcn.
@Tobias, danke für den Versuch der tröstenden Worte, aber leider geht deine Rechnung nicht ganz auf. Ja, man sieht auf level 12 auf einem 4,3” Display etwas mehr als auf einem 3,7”, aber auf letzterem sieht man auf Level 10 trotzdem mehr als auf dem größeren in Level 12 ;-). Also wenn ich die 2014er Karte benutze auf dem 3,7” geht das mitunter besser, allerdings ist die leider etwas veraltet, was schon zu der ein oder anderen bösen Überraschung geführt hat. Und ich habe auch keine Backups von 2014 für andere Bundesländer.___LIMITS_____
Based on binary format specs v5 (July 2018) # zoom intervals/subfiles 255 size of ONE subfile: ~ 18 446 petabytes cum. size of first n-1 subfiles: ~ 18 446 petabytes cum. size of first m-1 tiles: 524 288 megabytes size of POI segment no direct limitation, limited only by tile data segment size size of way segment no direct limitation, limited only by tile data segment size # of way data blocks no direct limitation, limited only by tile data segment size # tags per way/poi 15 # total POI tag names per file 65 535 # total WAY tag names per file 65 535 Based on map writer Based on map reader # way coordinate blocks per way data block short.Max code # way nodes per way coordinate block short.Max code # ways per tile int+ code # ways per zoom level int+ # tile size (=block) MAXIMUM_BUFFER_SIZE Based on Renderer Defintions: short.Max explicitly checked if <= 32 767 int+ implicit limit by used datatype 2 147 483 647 MAXIMUM_BUFFER_SIZE 8 000 000 bytes@Tobias :
Kannst Du bitte die RCN bei ZL10/11 wieder in die Them aufnehmen?
Ich habe ein tag-mapping hinzugefügt bei dem – für einzene Karten – die RCN in diesen ZL’s wieder aufgenommen werden. Bei der Austria.map funktioniert es.denn da gibt es in OSM ja klare Guidelines betreffs lcn und rcn.
… die nicht eingehalten werden …
VOR ALLEN nicht in Deutschland, hier machen sich manche Mapper Ihre eigenen Regeln und verteidigen die wie in einem KleingartenVereinsKrieg. So ist eben in manchen Regionen wirklich jeder zweite Feldweg als Radrelation getagged. Was dazu führt das die Erstellung der Deutschlandkarten mittleweile sage und schreibe 5 Tage braucht und die Karten völlig unübersichtlich werden wenn bereits ab ZL10 die (falsch getaggten) RCN mit aufgenommen werden.Was das Debuggen der Karten betrifft so gibt es hier kaum eine Möglichkeit Fehler genau zu lokalisieren, das ist eine Raterei, leider.
Sobald @Tobias die Theme um die ZL11/10 RCN erweitert hat werde ich Schritt für Schritt die RCNs auf ZL10/11 mit aufnehmen – mal sehen.LG, Christian
Ab Dienstag stehen die Karten
– Austria
– Slovakia
– Slovenia
mit RCN ab ZL 10 zum regulären Download zur VerfügungWas sicher Probleme machen wird sind die DE-Karten da mit diesem Mapping viele Wege (highway=*) in den heiklen BaseZoomLevel 2 fallen die sonst erst in BZL3 aufschlagen würden.
Zum testen bitte in die Elevate hinter:
<rule e="way" k="network" v="icn" zoom-max="13" zoom-min="12"> <line stroke="#680040FF" stroke-width="3" stroke-linecap="butt" /> </rule>diesen Code einfügen:
<rule e="way" k="network" v="rcn" zoom-max="11" zoom-min="10"> <line stroke="#908000FF" stroke-width="2.5" stroke-linecap="butt" /> </rule>Ich werde es mir ansehen. Kann aber sein, dass es für Karten die die Routen ab ZL 12 enthalten dann zu Darstellungsfehlern wie ganz oben kommt, daher ggf. eher nur was für Elements.
Developer of Elevate mapstyle
Das Problem ist das die RCN in jenen Karten in denen diese erst ab ZL12 (Germany.map) im tag-mapping enthalten sind sehr wohl auch schon in höherwertigen highways in BaseZL2 angezeigt werden wenn die Theme das zulässt.
= zerhackte RCNs
Die einzige Lösung die mir dazu einfallen würde wäre eine Option in der Theme „Regionale Radwege ab Zoom 10“ die per default nicht aktiv ist.
Ist nicht sauber, führt zu Verwirrung und Supportaufwand, ich weis…
Was tun??
Es als Overlay-Option anzubieten führt wahrscheinlich eher zu „Wieso werden bei mir in ZL10 die Radwege nicht angezeigt?“ Deshalb sehe ich die Nutzung von Elements da am sinnvollsten, bisher hat sich ja die Nachfrage nach Routen in diesen ZL in Grenzen gehalten.
Developer of Elevate mapstyle
1 Teilnehmer(n) gefällt dieser Beitrag
- Sie müssen angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.