Forum Replies Created

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • in reply to: Straßen sind sehr dünn dargestellt. #17430


    Wenn ein User das möchte, kann er schon ein paar interessante Voreinstellungen direkt in der Theme (XML) im Header festschreiben. Zumindest eigene Strichdicke, Schriftgröße und Hintergrundfarbe funktioniert bei mir problemlos (bin allerdings nicht mehr ganz uptodate, was Mapsforge- und App-Versionen angeht, also ohne Garantie). Beispiel:

    <rendertheme xmlns=”” xmlns:xsi=”” xsi:schemaLocation=”file:///c:mapsforge_renderTheme-v4.xsd” version=”4″ map-background=”#ffffee” base-stroke-width=”0.8″ base-text-size=”1″ >

    Falls natürlich jemand immer nur 1 Style und 1 App benutzt, kann er das auch via App-Einstellungen handhaben. Aber wenn er -wie ich- mehrere Styles von verschiedenen Autoren abwechselnd nutzt, kann das schon praktisch sein. Dann muss man nicht bei jedem Wechsel erst wieder in den App-Einstellungen rumfummeln, sondern es passt gleich.

    in reply to: neue Tags #3546


    Die surface ist echt eine extrem sinnvolle Ergänzung!
    Stell ich gerade wieder fest, leicht erschüttert…
    Da hab ich extra die Bulgarien-Map runtergeladen, um an einem Schotterpisten-Land die surface-Markierung für normale Straßen testen zu können (und zusätzlich noch tracktypes dazu, wenn schon denn schon) – und merk plötzlich erst, wieviel Mist eigentlich hier bei uns selbst getagged ist!! Unglaublich… Die Highway-Typen und Surface und Tracktypes gehen wild durcheinander, auch bei ganz normalen Straßen, die ich vor Ort kenne. Krass!
    Hmm, nach etwas weiterem Suchen, scheine wohl nur zufällig über eine besonders schlechte Ecke gestolpert zu sein, woanders sieht die Lage wesentlich besser aus, uff!
    Jedenfalls die surface ist auch für Mapper eine große Hilfe.

    in reply to: Mapsforge 0.5.0 #3544


    Ah, there’s hope returning a bit… ;-) Great, thanks!

    About error reporting, you’re right, Cruiser actually reports some things. Perhaps it’s mainly missing symbols that aren’t reported yet.
    Just noticed it again when trying to use named colors, that creates a message.

    Perhaps it wouldn’t be too complicated to include a few color names again, like Locus and Oruxmaps use? It’s about a dozen only, but even those few make the code already much easier readable.
    Acc. to the locus-manual last year, and works also in Orux, they understand “black” (#000000) white (#ffffff) lightgray (#D3D3D3) gray (#bebebe) darkgray (#A9A9A9) red (#ff0000) blue (#0000ff) green (#00ff00) yellow (#ffff00) cyan (#00ffff) magenta (#ff00ff)
    Of course wish there were a few more yet (brown, darkbrown, lightbrown, beige, olive….), but at least those help much already.

    And tried the base-stroke-width, it also works beautifully, like base-text-size. Do you think it would be possible to create also something like base-zoom-shift? 8-)
    (PS: if you like feel free to copy my stuff to the mapsforge lists or wherever it may concern)

    in reply to: Mapsforge 0.5.0 #3538


    Thanks emux, I’m trying to read through your links, much is a bit over my head, and it’s also a time issue…

    The theme-validator sounds interesting, is that something to be added as a styler to Notepad++ or such? But if so, I suspect it wouldn’t tell which symbols are missing?
    Have accidentally rediscovered now (in old notes) that the old AdvancedMapViewer031 does reveal which pics exactly are missing, after modifying the xml to version2 again. Perhaps a newer Locus meanwhile too, no idea. Just decided to finally update it and looked into their forum , but only to discover that the new version has some bad bug again, so have happily kept my old one again.

    Interesting find in your render-xml link, there is a “base-stroke-width” – looking forward to try it. Had been looking for a general zoom setting next to the base-text-size, and this could very well be it.

    Unfortunately have also found something about the killer-bug #1 at
    The bug report dates from 2012, and Menion from Locus had posted how to fix, but it seems rather complicated, and last summer Ludwig replied that he doesn’t quite understand it yet. My hopes are sinking again :(

    Regarding multiple line symbols, I mean to show at the same time at the same way multiple rules like this (simplified for demo):
    <rule e=”way” k=”surface” v=”paved”>
    <lineSymbol src=”file:../quality/surf_paved.png” align-center=”true” repeat=”true” />
    <rule e=”way” k=”mtb_scale|mtb:scale” v=”mtbs_1|1″>
    <lineSymbol src=”file:../quality/mtb_1.png” align-center=”true” repeat=”true” />

    in reply to: Mapsforge 0.5.0 #3529


    Hi Emux,
    you’re my last hope ;-)

    Cruiser is a very nice little app, and I use it to play with the new stylemenus, which are great fun!
    (And in a second step it would be very helpful to add min-zooms to the layers, not just on/off…)
    Of course, the best thing would be if single elements could be switched by a user individually in a checkmarks list, similar as in Osmand. At the moment he can only switch a set of combined rules which the theme creator has predefined. Of course slightly advanced users can do that themselves far easier now than before, so it’s still a HUGE step forward.

    Another great step forward is that finally errors in a style don’t stop the whole thing anymore!
    They are simply ignored now. (In a second step it would be nice to be informed which line in a style causes a prob, perhaps as a user setting..)


    But my #1 prob since years is a real killer bug in mapsforge!
    The infamous “common value bug”, that Christian keeps mentioning:
    Mapsforge can show wrong values in a map, if an element has multiple keys.
    The prob is that mapsforge rules don’t compare keys with their own values, but with ALL values of ALL keys of a given node or way.
    A building has amenity=parking / building=yes / access=private
    Rule access=private? TRUE!
    Rule access=yes? TRUE! (should be wrong)
    Locus has it fixed since years, but native Mapsforge not yet.

    For theme creaters it’s a huge prob, and Christian also struggles endlessly with this when creating the OAMaps.
    As a workaround he’s trying to retag all things to specific values if possible, for example ford=fd_yes instead of simply “yes”, or noexit=nd_yes instead of “yes”, but cannot cover all.

    For demonstration I’ve attached a file with a test code to highlight some example ways.


    Another prob I have now with mapsforge, but only since the new version:
    linesymbols are restricted to 1 now.
    If multiple ones are painted, only 1 wins, the others vanish.
    But multiple symbols are needed to be able to display several keys.

    Those multiple symbols work great in Locus, but I’d prefer to have them work in all mapsforge apps, in case others may want to use my fancy style some day too (still in the works).
    (That said, my Locus version is still a rather old one, so I *hope* it still works ;-))

    in reply to: neue Tags #3489


    NOEXIT: Danke für die Bestätigung und Testen.
    Hätte allerdings nicht gedacht, dass es tatsächlich Absicht sein könnte, Kartenelemente erst zu definieren und dann gleichzeitig einen Schalter zu setzen, dass sie gar nicht erst in der Karte landen sollen. Jedenfalls nicht NoExit-Nodes am Ende von Wegen, Tracks und Pfaden, die im Normalfall keinerlei anderen key dran haben, mit dem sie als blinder Passagier mitreisen könnten. Zumal für die paar, die auf Wendeplatten landen, ein zweites Symbol sinnlos ist, da gibts ja schon immer die weißen Kreise.

    in reply to: neue Tags #3459


    Nun ist mir völlig unerwartet doch noch ein angezeigter noexit-Node über den Weg gelaufen. Der ist allerdings auf einer Wendeplatte! Könnte es evt. sein, dass die noexits quasi nur als “Anhängsel” übertragen werden, also nur wenn noch ein anderer key (z.B. highway) explizit am Knoten hängt? Könnte auch mit dem renderable=false zu tun haben, keine Ahnung.

Viewing 7 posts - 1 through 7 (of 7 total)