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.


Messages - Tobias

Pages: [1] 2 3 ... 6
1
"P" Icon shows at ZL15, not at ZL16, but again at ZL17. This is the joys I try to prevent :D
As I wrote above - tile borders are with V4+ maps the only problem. The more you zoom in, the more map tiles are used, the more borders you get with the possibility of missing icons. As long as there are the tiny 256px map tiles in Locus there are a lot tile borders. When map tiles are scaled according to display pixel density, you will have e.g. 768px map tiles (for e.g. 480ppi displays), but this is work in progress (and works already fine in other apps).

My current tests with mf4 (I use Voluntary Mapsforge for this) and Locus were rather bad. E.g., I increased a bench size, want to see it from ZL14 onwards and stay on top no matter what, so I added priority. It does not display often. Quite a few ZL>14 where benches will not display at all. Not sure if it is a tile size problem.
No, benches are in the map from ZL17 on (see https://www.openandromaps.org/map-basics-2/tag-mapping), so changing this via theme doesn't work (exceptions may occur when a different tag with an lower zoom appear is on the same node).
Quote
Or, on new mapsforge maps, does Locus not know about priority yet?
With current mapsforge engine (at the moment hard coded to V4+ maps) it does, but not with Locus own engine (hard coded to V3 maps).


2
The only remedy is when Menion not only takes the mapsforge library as such as a base for the Locus core, but in addtion applies the concept of its "Label Layer" (like Cruiser does).
MF alone, w/o LL, is crappy, too, when it comes to labels.
Current mapsforge (not the Locus fork, so in Locus with V4 maps) is quite fine with labels (and priorities), except on tile borders. Only this last issue is solved with the label layer. It's not very likely that the label layer will be included in Locus soon, but at least larger tile sizes will come very soon, and therefore a lot less of those problematic tile borders:
https://forum.locusmap.eu/index.php?topic=6434.msg53911
A solution for me that I can see can only be a massively stripped down theme. Where I can turn off display of almost anything except the stuff I mentioned. But oh, the xml is not easy to handle.
This is already implemented in Elevate, just switch of every other overlay than "Car"; it will work better with V4 maps though.

3
Discussion/New features / Re: MapsForge maps V4/V5
« on: January 04, 2019, 14:10:45 »
@Tobias
excellent description I needed, thanks :).

About themes: Currently, all V3 maps use Locus-MapsForge rendering system, V4+ maps use than MapsForge 0.10.0. So what I may do: allow all V3 and higher themes for V4+ maps oki? I'll look at it.
Allowing all V3 themes might make problems with V4+ maps when locus extended tags are used. V3 maps on the other hand won't make problems with mapsforge 0.10. So checking for locus-extended might make sense.

Another issue: on tile borders labels and symbols aren't rendered reliably. Using larger tiles with device depedent scaling helps a bit, but the only solution which completely solves this that I know of is the label layer of mapsforge. But I think the mapsforge maps viewer is necessary for this. More here: https://github.com/mapsforge/mapsforge/blob/master/docs/LabelLayer.md

4
Discussion/New features / Re: MapsForge maps V4/V5
« on: January 03, 2019, 21:02:14 »
"Device screen scaling": I already read the post from Tobias, but I'm not too clever from this. What is the main issue he tries to describe except lack of interest in compatibility?
That post was more my tiredness of only limited support of new mapsforge features in various apps (not just Locus, but this was the app John came up with) which limit app-independent development as we do at OpenAndroMaps. In an older discussion I got the impression that LoMaps have a bigger priority than compatibility, but this new thread let's me hope for a change :-)

But as far as device screen scaling is concerned - as a cross-app-theme-developer this is the most important issue. It was introduced with mapsforge 0.4 in 2014, at first I was a bit sceptical but with very high ppi nowadays it's a must for good rendering, as far as I'm concerned.

Here's a description of the problem I posted in a different forum:
Quote
Mapsforge maps are meant to be scaled to screen density of the device, so that a map at 160ppi looks exactly the same as with 480ppi. To do that, not only symbols and line width are scaled, but also map tile size. So if you have a map tile size of 256px at 160ppi, you get 768px at 480ppi.
Locus uses a mod of a very old mapsforge version with no scaled tiles. So with modern devices with very high pixel density, you still get 256px like for devices years ago. The only thing that is scaled is line width and symbols. But as these grow larger (3x as large at 480ppi), the space on a 256px map tile gets more crowded, and less can be displayed. So when looking at the same zoom level, less and coarse information is shown.

Here are some comparison of a densely mapped are at zoom level 17:


At first, it looks as if Locus shows more - but this isn't the case, as the area is only larger as the tile sizes are smaller. The same area can achieved by OruxMaps by using the zoom button.

Now here you can see what details are available if tile size is adjusted:

In Locus, streets are rendered much too fat, so they overlap and swallow too much space. Only a few symbols are displayed, as most are eliminated because of too little space.

So the scaling policy of OruxMaps is true to how the maps are meant to be displayed and can be scaled to every pixel density without loss of details. The only disadvantage is that with larger tile size direct comparison to online maps with old 256px tile size is not possible (although there are more HD maps coming with larger tile size as it's necessary to keep the legible on high density devices).

On my to-do-list for the Locus version right now is the idea of moving all zoom-appears 1-2 levels as this is the only possibility right now to get it a bit better, but with other disadvantages.

Other issues:
- Folder structure for themes: only one theme xml per folder is allowed, and folder are also needed. Any other app with theme support allows xml files in base folder and graphics whereever the xml points to. So a special Locus format is always necessary. I get the one folder, one theme policy, but why not two or more xml files?
- Forced connection of V4 maps with V4 themes - it should be possible to use V3 maps with V4/V5 themes, or V3 maps and V3 standard mapsforge themes etc. Maybe use standard-mapsforge for all themes, whatever version, and locus-mapsforge-fork for those themes with locus-extended="1" in the rendertheme tag? That would solve the issues of the two posts above.

Best regards,
Tobias

5
Discussion/New features / Re: Mapsforge 0.5
« on: January 03, 2019, 20:40:17 »
And now Tobias announced that "OpenAndroMaps will switch to Multilanguage “V4” Maps mid of 2019.".
That was Christian, not me. But of course I support this :-)

6
The theme used is a pretty current version of Elevate, not Andromaps, and the map is also one of OpenAndroMaps, as surface is rendered.
But the symbols/text size shouldn't be reduced by zooming, and also aren't in all but one example - that's just an optical illusion. As everything around is enlarged it seems that they are smaller, but they aren't. In the first example it seems like the text size is reduced via a Locus setting (or some bug), because in the theme code the size is constant.

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

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

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

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.

10
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 ;-)

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

12
Themes - Vector maps / Re: Scaling of dy displacement with zoom
« on: December 19, 2016, 14:05:17 »
I finally came around to test it, works great for me in the latest beta. No more "moving" ways.
Thanks menion!

13
Themes - Vector maps / Re: Scaling of dy displacement with zoom
« on: November 12, 2016, 16:05:07 »
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?

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

15
Themes - Vector maps / Re: Scaling of dy displacement with zoom
« on: October 12, 2016, 10:30:27 »
+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.

Pages: [1] 2 3 ... 6