Messages

The new converted version of Elevate 3 for Locus has been released, thanks everyone for the help:
http://www.openandromaps.org/en/legend/elevate-mountain-hike-theme

One thing I realized that is fixed in mapsforge 0.5 and not yet in Locus:
dy doesn't work for POIs which are marked on areas/ways. For example if I have an alpine hut like this:
http://www.openstreetmap.org/way/38173874
Without dy I can only show a symbol or a caption, not both.

This works fine now with mapsforge 0.5, so I removed all workarounds for showing captions for POIs on ways at very high zoom levels. This was maybe a bit premature, as now some areas are clustered with captions without symbols in Locus. But maybe this is a feature of mapsforge 0.5 which can be easier implemented and benefit the rendering of the maps in general?

I also recreated it, as well as all other weird stuff - thanks for the overview, Menion! And congrats on improving the library.
The sources weren't probably made to be used as is (as there was also lots of unnecessary tags included), so it was a good reason to make all as clean and simple as possible.

@menion: I asked above about the priority tag, does it work as in mapsforge 0.5 (only integers, negative values have the lowest priority, positive values the highest)?

Hmm thanks mainly John for testing.

I have a problems with "s_cable_car.svg" file. Three small windows are drawn as "path" where only defined parameter is opacity. But in that moment, background is already completely black and I do not understand why web browser draw these windows as grey. Any idea?

That's a result of SVG Cleaner which removes not necessary tags etc. It's probably this:
Standard value for fill is fill="#000000", so with the option in SVG Cleaner to remove attributes with standard values, this is removed. The Locus SVG renderer still assumes this value, but doesn't use opacity which is still defined. Other renderers use opacity also on not explicitly defined standard values.

Hmm generally, this is a bad solution. Solving issues in SVG files, that on other places works correctly, isn't useful solution. Soon or later, you or anyone other, will be stuck on same issue. Best and only solution, is to fix this in Locus!

Right, that's why I proposed the different library... haven't thought that it would be so complicated though.
But I also like the idea of having simple and clean SVGs, so maybe that's my personal challenge ;-).

As I got them from various sources, there are various issues. One I introduced myself when I used "convert stroke to path" in Inkscape to make outline contours possible; this sometimes introduces two nodes on the same spot (which can sometimes be solves with simplify), which caused many of the rendering issues. But this seems to be solved.

But many thanks, saves me some trouble and I'm looking forward to the next update!

BTW - I haven't found anything about how "priority" works in Locus themes, so I just kept values from mapsforge 0.5 for now - only integers, negative values have the lowest priority, positive values the highest. At the moment no issues, but does that do the job?

[2]

When I open Tobias's s_trainstation_lz.svg (from post above) in Inkscape and click on the object, the status bar says "Path 2 nodes in root", but when I use the node tool, there are four nodes. Is that not odd?
After using Simplify, the object tool reads "Path 4 nodes in root". The saved file renders fine in Locus.

Odd indeed. I made that with Inkscape, so I'm puzzled that it can fix itself by simplify. Seems like simplify also checks for oddities.

I notice though that some of Tobias's files won't load into Inkscape (s_kindergarten.svg for example).

That's because that was work in progress when I uploaded them and not the source files, I was just testing some SVG clean options if that would help with Locus. Haven't found the right ones yet, that's why I posted here.

I never used Inkspace, I use now only offical docs for SVG to understand it's format http://www.w3.org/TR/SVG/ .

Anyway @Tobias, file rendering (circle) fixed. Who is next .

Thanks, but maybe it's better if I check every icon that renders wrong and try to fix it. It's probably faster that way, and I'm already at it.

I'm now testing your icons to check, what is wrong, and seems they are missing width and height parameters.

I found that too, but there are other issues. Not only complexity (which isn't always fixable with simplify, and some even more complex svgs have no issues), sometimes a missing segment between nodes, and sometimes I have no clue - and have to redraw some parts.

Maybe the problem is with Inkscape vs. Illustrator - all Inscape SVGs render fine with mapsforge 0.5, even complex ones and with missing segments. Locus internal theme SVGs are exported with Illustrator as far as I can see.

Even very simple SVGs are not correctly rendered - example attached. Just a filled blue circle with a grey border, but in Locus it's rendered with a horizontal line. My solution here is to make two circles, grey below, blue above. So yes, it can be solved, but the library seems very picky.

So we should test it and fix it during next days, but not a few hours before I wants to publish a new version. Thanks for understanding,

No problem, too bad that there isn't one solution for all ;-)

I have just now edited Tobias's s_supermarket.svg in Inkscape as a test. I split the two grouped layers (Ctrl-Shift-G), then ran simplify (Ctrl-L) on each path once before saving. After running SVGClean on the file, I uploaded it and it worked in Locus.

Thanks John, I tried several things with Inkscape, but not simplify - would have been too easy ;-) That solves some problems. Just have to check now all symbols :-/
Seems like the library gets hickups with too many nodes.

Thanks a lot, that was very fast.

Thanks Tobias, I've changed SVG libraries and not seems to correctly parse all icons.

I hope you mean "now seems to correctly parse all icons." 

May You give me link on theme and map I may use for test? Thanks

Sure: http://www.eartrumpet.net/temp/Elevate3_Locus_SVG.zip
One thing I found - I converted most contours to shapes to make it possible to have white outlines. Maybe the shapes of the supermarket basket etc. are a bit too complex now.
Best regards,
Tobias

I just hope that other theme developers will support the Locus solution soon. However, I'm not very optimistic about the Elevate themes, as the developer already implemented MapForge 0.5, and I'm not betting on them to support two different solutions at the same time...

Good news for you, I made a script which converts Elevate 3 with mapsforge 0.5 tags to Locus, with style switcher. Works quite well, only switchable layers had to be removed and some other stuff and will be released soon. The last big problems I have are with SVG icons and Locus, probably the release will be only with PNGs.

@menion - there are strange behaviours with some icons, it's probably the SVG render engine. Some tiles aren't even rendered because of that.
The icons work fine with the one mapsforge 0.5 uses: https://code.google.com/p/androidsvg/
The former one, https://code.google.com/p/svg-android/, was replaced because of similar issues. I attached a comparison with a PNG version.

@John: You're right, can't is wrong, it can be done, but the costs would be way out of proportion of the benefits. I'd invest the time better in a Locus conversion of Elevate 3 :-)

I just hope that other theme developers will support the Locus solution soon. However, I'm not very optimistic about the Elevate themes, as the developer already implemented MapForge 0.5, and I'm not betting on them to support two different solutions at the same time...

You're right, at the moment it seems not very reasonable.
I first thought about adapting Locus styles, too, but then I would have three different versions to maintain, as there are other apps that still require regular 0.3 themes. Adding only Locus styles wouldn't be different to the variations I developed with several xml files, which are generated out of one base theme file. The only advantage would be to have only two files instead of four, as Elements can't be made in the same file.

I still hope that one day it will be easier again :-)

Best regards,
Tobias

I don´t know if users really change or (de)activate often symbols or captions.

Me neither, but I had often requests that those symbols/captions are more important than others and vice versa, so now one can choose which to show (it helps a lot with symbol/caption elimination, too). I usually assume that people know better than me what they want so having the option to get closer to it isn't hurting.
Probably most of the time users set their overlays only once, but there are other cases:
I sometimes use the routes in the maps for hiking/cycling and now can switch on strong overlays for those, and sometimes I don't and can deactivate routes altogether. Or I usually don't need to see hospitals in a city map, but in emergency I only want to see those (OK, there are other solutions for that in Locus now).

Changing the whole theme with Locus is not much more work for users. 

Depends on the user ;-)

Best regards,
Tobias

There are three possible answers to limiting the vector map symbols:

A different one is the possibility that mapsforge 0.5 style menus could be added to Locus, as discussed here:
http://forum.locusmap.eu/index.php?topic=4311.0
This allows adding different map items to categories, which can be switched on and off. Have a look at the preview version of Elevate 3, which isn't compatible with Locus (yet), but I added different groups of switchable POIs:
http://www.openandromaps.org/en/oam-forums/topic/elevate-updates-and-test-versions-news#post-4059
It can be easily tested with Atlas on the Desktop:
http://wiki.openstreetmap.org/wiki/Atlas_%28navigation_application%29
Best regards,
Tobias

I was worried you'll need this ... hmm it will be task on a longer nights.

I am worried to hear this ;-)
But it's really additional value to have this, I got really good feedback from users from the first previews for having the option to (de)activate different parts of the map (symbols, routes, captions etc.).
Best regards,
Tobias