Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #5016

    jj
    Participant

    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.

    #5020
    ChristianK
    ChristianK
    Keymaster

    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
    Christian

    #5039

    jj
    Participant

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

    Attachments:
    #5044
    ChristianK
    ChristianK
    Keymaster

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

    #5046
    Tobias
    Tobias
    Moderator

    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,
    Tobias

    #5056
    ChristianK
    ChristianK
    Keymaster

    Ich habe in den Andromaps_Themes jetzt auch die lcn/rcn auf level 12 gesetzt, damit ist die Sache dann weniger verwirrend.

    #24329

    jj
    Participant

    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 selbst

    liegt. 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
    jj

    #24346
    ChristianK
    ChristianK
    Keymaster

    Mir 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 selbst

    Das 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.4211

    Und 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

    #24362
    Tobias
    Tobias
    Moderator

    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,
    Tobias

    #24460

    jj
    Participant

    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_____

    [/crayon]
    • This reply was modified 1 week, 1 day ago by  jj.
    • This reply was modified 1 week, 1 day ago by  jj.
    #24525
    ChristianK
    ChristianK
    Keymaster

    @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

    • This reply was modified 4 days, 9 hours ago by ChristianK ChristianK.
    #24536
    ChristianK
    ChristianK
    Keymaster

    Ab Dienstag stehen die Karten
    – Austria
    – Slovakia
    – Slovenia
    mit RCN ab ZL 10 zum regulären Download zur Verfügung

    Was 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:

    [/crayon]

    diesen Code einfügen:

    [/crayon]
    #24538
    Tobias
    Tobias
    Moderator

    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.

    #24540
    ChristianK
    ChristianK
    Keymaster

    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??

    #24542
    Tobias
    Tobias
    Moderator

    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.

    1 user thanked author for this post.
Viewing 15 posts - 1 through 15 (of 16 total)

You must be logged in to reply to this topic.