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] 4 5 ... 7
31
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.

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

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

34
Versions / Re: [APP] - version 3.17.x (16. 5. 2016+)
« on: May 23, 2016, 18:52:00 »
@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.

35
Versions / Re: [APP] - version 3.17.x (16. 5. 2016+)
« on: May 22, 2016, 10:30:15 »
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.

36
Versions / Re: [APP] - version 3.17.x (16. 5. 2016+)
« on: May 21, 2016, 16:53:38 »


@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


37
Themes - Vector maps / Re: Problems with seemless SVG patterns
« on: May 17, 2016, 21:50:13 »
Tested with 3.17 release in emulator @240dpi and @320dpi, seems to work perfect!

38
Themes - Vector maps / Re: Problems with seemless SVG patterns
« on: May 15, 2016, 08:47:56 »
Ah ... give me please a suggestion how you simulate device with this DPI, thanks
With Genymotion, there's a preset for 1920*1280@480dpi

39
Themes - Vector maps / Re: Problems with seemless SVG patterns
« on: May 15, 2016, 08:30:02 »
Hello, interesting. Are you sure you have latest Beta version from Google Play?
It says 3.16.2.12 at startup. Just checked again, it works now with 240dpi, but not with 480dpi.

40
Themes - Vector maps / Re: Problems with seemless SVG patterns
« on: May 14, 2016, 20:55:12 »
If you wanna try, since yesterday is on Google Play new Beta version ( if you use it ).
Finally found the time to test the latest beta it in an emulator @480dpi. Still same behavior as above, all patterns 8dp/16dp/32dp/64dp. Did you remove the rounding again?



41
Themes - Vector maps / Re: Problems with seemless SVG patterns
« on: May 13, 2016, 13:09:58 »
Damn, it's more then expected. Hmm ... oki, I'll have to separate it and round scaling only for images for areas ...
And lines with images :)

42
Themes - Vector maps / Re: Problems with seemless SVG patterns
« on: May 13, 2016, 13:07:48 »
Hmm, for me all Symbols and Texts are smaller. 

Left is 3.16.2, Right is 3.16.2.12

You probably have a device with an odd scale factor, something like 480 dpi. Those are affected and that's what we talked about above when rounding to integers with a power of 2 can happen if this isn't limited to svg patterns.

43
Themes - Vector maps / Re: Problems with seemless SVG patterns
« on: May 13, 2016, 09:49:04 »
Thanks, I'll look into it as soon as I find the time.

44
Themes - Vector maps / Re: Problems with seemless SVG patterns
« on: May 09, 2016, 20:43:21 »
because this task is not so simple (handle differently scale for areas and for paths)
I was afraid you would say that :-)
No need for hurry and/or special test version, I'll use fixed size patterns until it works with scalable ones.
But I think other themes (and users) will be affected if not only scaling for patterns will change. We'll see.

45
Themes - Vector maps / Re: Problems with seemless SVG patterns
« on: May 09, 2016, 17:49:39 »
To keep consistency, this change apply on all values defined with "dp" units in theme.xml file, so no worry.
So this applies to stroke-width, symbol-size etc. as well?
If yes I think it's better to keep them scaling in the normal way, which works perfect except for patterns with svg/dp.

Pages: 1 2 [3] 4 5 ... 7