Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Tobias

#31
Quote from: bezel on March 09, 2017, 08:21:01
warum werden bei der Kombination OAM+Elevate "Radfahren" mehr Straßen als Radwege gekennzeichnet, als unter Lomaps mit Elevate "Radfahren" od. mit internem "Radfahren+Wandern"-theme?
Das liegt an dem von Christian in OAM verwendeten "UCN" Routen und Auswertung von weiteren Markierungen, nicht nur Relationen. Normalerweise werden Fahrradrouten in OpenStreetMap so markiert:
http://wiki.openstreetmap.org/wiki/Fahrradroutentagging_Deutschland

Es gibt aber auch vereinfachte (oder unvollständige) Markierungen:
http://wiki.openstreetmap.org/wiki/Cycle_routes#Tagging_cycle_route_networks
In Deinem Ausschnitt z.B.:
http://www.openstreetmap.org/way/8025861#map=17/47.98345/7.88902&layers=D
Da ist ein lcn=yes vorhanden, das sagt aus, dass das eine lokale Radroute sein soll. Das wird in OAM ausgewertet, in LoMaps nicht.
#32
Quote from: jusc on March 08, 2017, 12:45:47
ach so, die  Singletrail-Skala hat aber gerade mal drei Farben für fünf  Schwierigkeitsgrade. Damit kann man imho auf Karten, zumal auf einem 4 -5 Zoll Smartphone wenig anfangen.
Deshalb wird auch S1 und S3 zweifarbig dargestellt, wie auch auf der Singletrailskala als fließender Übergang.

Das Schema blau-rot-schwarz ist an die Skipisten angelehnt, wie auch die Wanderweg-Einteilung vom DAV (+gelb), also sollte es eigentlich durchaus einleuchtend und verständlich sein.

Von Mountainbikern hab ich da bisher ziemlich positive Rückmeldung. Höchstens, dass sie bei Gegenden mit höherer Wegdichte außerhalb der Alpen (Elevate habe ich auf die Nutzung in den Alpen optimiert) auf die Markierung von Forstwegen verzichten können (insb. S0), deshalb hab ich da optional gemacht.
#33
Quote from: jusc on March 07, 2017, 08:18:23
Kann man denn davon ausgehen, dass Mountainbiken, auf nicht speziell ausgeschilderten Routen, erlaubt ist, wenn  "mtb:scale=X"  getaggt wurde? In manchen Bundesländern ist m. W. das Radfahren auf "schmalen" Waldwegen nicht gestattet. Dass der Weg ev. trotzdem geeignet ist, kann natürlich sein.
Wenn Radfahren verboten ist (mittels bicycle=no), wird mtb:scale nicht angezeigt. Das geht davon aus, dass Radfahren auf tracks und path grundsätzlich erlaubt ist, das ist aber nicht in jedem Land so. Bei OpenStreetMap ist das je nach Land verschieden:
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
In Deutschland aber trifft das zu, d.h. in BW müssten alle Wege, auf denen Radfahren verboten ist, mit bicycle=no markiert sein.

Quote from: jusc on March 07, 2017, 13:50:03
Auf Taginfo muss man aber auch erstmal draufkommen.
Eigentlich reicht die Elevate Legende, da ist einerseits alles kurz beschrieben, andererseits wird auf http://wiki.openstreetmap.org/wiki/DE:Key:mtb:scale verlinkt.

Das Blau kommt übrigens von der Singletrail-Skala, auf der MTB-Scale beruht:
http://www.singletrail-skala.de/s0
Daher macht es wenig Sinn, hier andere Farben zu verwenden. Und da die Darstellung in Elevate von Routen und Pfaden sich sehr deutlich unterscheidet, ist auch wenig Verwechslungsgefahr gegeben.
#34
Quote from: jusc on March 06, 2017, 15:34:17
Hier scheint der TO aber "mtb:scale=0" mit  MTB-Routen zu verwechseln und zu dem Schluß zu kommen, dass die Routen nicht in den LoMaps enthalten sind.
Wie man´s macht macht man´s falsch.  ;D
Scheint so 8)

Aber eigentlich ist ja fast Absicht dahinter, für mich sind Routen zweitrangig. Wichtiger ist mir, die Eigenschaften der eigentlichen Wege gut zu erkennen, und mir damit selber Touren zusammen zu stellen. Wenn jemand also einen Weg mit "mtb:scale=0" bewertet hat, ist da die Aussagekraft eigentlich höher für die Eignung als irgendwelche ausgeschilderten Routen. Auch wenn das für manche schon eher vom Anspruch her langweilig ist ;-)
#35
Elevate funktioniert nur mit OAM richtig, für LoMaps ist es nicht gemacht. Macht für mich auch wenig Sinn, dass dafür auch noch anzupassen, da in LoMaps viele Eigenschaften fehlen, die Elevate/OAM ausmachen, noch dazu da LoMaps etwas kosten.
mtb:scale=0 anzuzeigen macht durchaus Sinn, da es ja auch sein kann, dass gar nichts getagged ist. So ist man auf der sicheren Seite. Jedoch kann das bei highway=track überhand nehmen, deshalb lässt sich auch die Anzeige für tracks etc. abschalten.
#36
I finally came around to test it, works great for me in the latest beta. No more "moving" ways.
Thanks menion!
#37
Quote from: menion on October 12, 2016, 12:12:31
Hello John, Tobias,
thanks for a feedback. I'll enable this improvement to next BETA version, so there will be some time to test it.
After checking with the last beta versions, still same behavior - probably planning for beta version 3.21 instead 3.20.x?
#38
Im Locus-internen Theme werden viel weniger Informationen angezeigt, deshalb ist die Darstellung zuverlässiger. Es wird da gar nicht force-draw oder anderes verwendet.

Schalte einfach mal bei Elevate alle Beschriftungen außer den Ortsnamen ab. In Deiner Konfiguration von Elevate werden viele andere Informationen angezeigt, die in Konkurrenz zum Ortsnamen stehen. Am besten zur Ortsnamendarstellung ist der Stadt-Kartenstil. Dass Ortsnamen bevorzugt werden lässt sich nur zuverlässig mit priority steuern, was Locus aber nicht unterstützt.

Elevate ist für Standard-Mapsforge entwickelt und funktioniert da einfach besser. Ich habe viele Optimierungen in die Locus-Version eingebaut, aber manches geht einfach nicht. Wenn ich nur so wenig zulassen würde wie im Locus internen Theme, würde die Standard-Mapsforge-Version für alle anderen Anwendungen darunter leiden. Wie oben geschrieben würde es ggf. Sinn machen, alle Informationen erst einen Zoom-Level höher anzuzeigen, da zögere ich jedoch noch.
#39
+1

There was a similar issues in standard mapsforge 0.5 which was fixed in 0.5.1, discussion and issue here:
https://groups.google.com/d/msg/mapsforge-dev/xQHb-CNxlag/UxiDgFXyyLMJ
https://github.com/mapsforge/mapsforge/issues/580

The problem is that stroke width is scaled for zoom levels >12 with a base 1.5, so strokes get wider, but everything defined by dy keeps the same distance, so it looks like it moves relative to another object which hasn't the same dy value.
#40
Quote from: michaelbechtold on October 11, 2016, 09:37:35
Bitte mit dem Skalpell arbeiten, und NUR dort die display="always" (mit dem Skalpell) einsetzen wo es für Dich Sinn macht.
Ich habe den ganzen Abschnitt kopiert, damit Du die Stelle in dem Dir vorliegenden Theme finden kannst.
display=always funktioniert mit Locus nicht, Du musst  force-draw="1" nehmen.

An Kachelgrenzen hilft das aber auch nicht, da hier, wenn sie ungünstig liegen, Namen und Symbole gar nicht angezeigt werden.

Leider ist force-draw/display keine gute Lösung, da es zur gleichzeitigen, überlappenden Darstellung führt. Hier hilft nur priority, was aber in Locus nicht funktioniert.

Ein drittes Problem ist bei Auflösungen ab 320ppi die kleine konstante Kachelgröße von 256px in Locus, d.h. mehr Kachelgrenzen und weniger Platz pro Zoomlevel, so dass mit größerer Schriftgröße bei höherer Auflösung alles viel dichter wird. Ich habe schon überlegt, alle Zoomlevel Grenzen in der LE Version komplett zu verschieben, um dem vorzubeugen, das kann aber auch unerwünschte Nebenwirkungen haben.
#41
Quote from: menion on May 23, 2016, 07:49:46
@Tobias: hmm so you want to say that new mapsForge may dynamically change rendered tile size based on defined parameter? So Locus should define as you wrote, till density 320dpi, use 256px, then 512px? I'll look what I may do here, thanks
I just thought that's the reason why lines are too thick in Klaus' example. All render parameters like line thickness are scaled with the device scale factor in standard mapsforge (like with "dp" in Locus fork), even if the tile size is fixed. It looks normal if tile sizes are also scaled by this factor, but more cramped with high dpi if tile sizes stays at 256px.

There is the standard model with mapsforge viewer that tile sizes are scaled by device scale factor (and rounded to a multiple of 64, see here), so it's 256px at 160dpi, 384px at 240dpi, 512px at 320dpi and so on.

But other apps are using because of compatibility reasons with their own map viewer fixed sizes at all dpi, e.g. OruxMaps 512px or BCN 256px. So the latter looks similar to Locus with ML maps, the former looks less cramped at the same zoom level.
#42
Quote from: menion on May 21, 2016, 17:03:16
Size of tiles is defined in map file itself. So Locus first get information about defined tile size from map header and then use this size to request MapsForge for rendering of tiles.
Standard mapsforge 0.4+ map viewer uses flexible tile sizes, 256px@160dpi,512px@320dpi etc. The renderer scales all elements accordingly. Apps that don't use the map viewer like OruxMaps/BCN are AFAIK using a fixed size for compatibility reasons, like 512px or 256px. That's why I was guessing that's the same with Locus.
#43


Quote from: menion on May 21, 2016, 11:45:33
@fzk: well ... and how may I help here? :). I'm just using default settings from MapsForge. Same theme + map with official sample application looks different? Width of lines should be only defined by theme.xml file, isn't it?
Are tiles scaled according to screen density or fixed at 256px? If the latter is true all sizes probably are still scaled but on not enough space, so everything looks too thick on high dpi

#44
Tested with 3.17 release in emulator @240dpi and @320dpi, seems to work perfect!
#45
Quote from: menion on May 15, 2016, 08:40:43
Ah ... give me please a suggestion how you simulate device with this DPI, thanks
With Genymotion, there's a preset for 1920*1280@480dpi