Mapsforge 0.5.0 Release Candidate 1

[Ludwig]

I know that we have not addressed all issues and fulfilled all feature requests, but we have reached a pretty stable state with mapsforge (and even the speed is better than before) and I think it is time to make a real effort for a new official release.

I have decided to make the current master code release candidate 1 for the upcoming 0.5.0 release.

Unless we find any real show stoppers, there will be no API changes, so now is the time to test your mapsforge based apps against the 0.5.0 code. 

I have updated the tags on master to 0.5.0-rc1 and I have pushed the new libraries to maven central, so you should soon be able to build against 0.5.0-rc1 if you are using maven to manage your dependencies. 

I will look at fixing maybe a few more code quality violations, but most importantly write a bit more documentation on the new features.

Ludwig

[Emux]

I agree and I'm glad we're again near another Mapsforge release.
The feature freeze is necessary for finding any remaining critical bugs prior the official version.

There are many features to be discussed and probably be implemented.
But I support the quick release cycle if we have a complete stable bundle for the people to advance in their apps and adopt the new options.

Also I think it's very important to continue providing Maven support, as there are many who do not migrate to Gradle build system.

Ludwig I may complement at the Wiki if there are more things / features to describe for the new release.

--
Emux
Cruiser - Atlas

[Ludwig]

Also I think it's very important to continue providing Maven support, as there are many who do not migrate to Gradle build system.

Maven support will continue, of course. I have pushed 0.5.0rc1 to maven central and a test build with an app linking against the maven central provided jars seemed to work. 

For all who want to test this, the dependency in your setting needs to be like this

<dependency>

<groupId>org.mapsforge</groupId>

<artifactId>mapsforge-map-android</artifactId>

<version>0.5.0-rc1</version>

</dependency>

 

Ludwig I may complement at the Wiki if there are more things / features to describe for the new release.

I have added some info on Rendertheme V4, see here: https://code.google.com/p/mapsforge/wiki/RenderthemeV4

This will be expanded.

Ludwig

 

 

--
Emux
Cruiser - Atlas

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/542FBBF9.5040101%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Emux]

I have added some more features at changelog.

I'm thinking what we should do with Osmarender theme.
Unfortunately we don't have a new one ready for integrating it into 0.5 release.
How about modifying a bit the existing v3 theme?

In Cruiser / Atlas I already provide Osmarender modified with some v4 features, most notably the replacement of 'dy' with 'position' tags.
Additionally in Cruiser I use svg icons in Osmarender, but that's probably not advisable here as mapsforge is used also in Java.

As a side note we should add SVG support in Java too.
It will be far to easier for building SVG themes if there is the possibility to test them in desktop, directly without having first to convert svg to png.

[Ludwig]

I'm thinking what we should do with Osmarender theme.
Unfortunately we don't have a new one ready for integrating it into 0.5 release.
How about modifying a bit the existing v3 theme? 

In Cruiser / Atlas I already provide Osmarender modified with some v4 features, most notably the replacement of 'dy' with 'position' tags.
Additionally in Cruiser I use svg icons in Osmarender, but that's probably not advisable here as mapsforge is used also in Java.

That is maybe an idea, if you wanted to donate your modified osmarender to the project. I would also be against SVGs for that because I would prefer not to increase the number of resource files that we are packaging. Overall I think the fixed inclusion of a rendertheme in the main library is wrong (most as it means packaging all the resources with it) and we should discourage its use. I think using external renderthemes and external resources is way more flexible. 

I always wanted to find some time to develop some packaging mechanism for themes (as separate jars or so), but it never happened and for 0.5 I think it would bring now too much instability.

 

As a side note we should add SVG support in Java too.
It will be far to easier for building SVG themes if there is the possibility to test them in desktop, directly without having first to convert svg to png.

+1

[Emux]

I have pushed at dev an updated Osmarender theme.

I advanced its version to v4 and included some improved symbols (also in the Samples app).

I have put the 'position' tag only at peak symbols, the 'dy' is still used at 'circle' symbols (we could probably replace them too with actual icons).

Should we continue to provide two different schemas v3 and v4 together, or only a renamed v4 ?

[Emux]

I pushed an Osmarender update at dev, replacing the circles using 'dy' with icons using 'position'.

[Maki]

Il giorno sabato 4 ottobre 2014 09:54:25 UTC+2, Ludwig ha scritto:

I will look at fixing maybe a few more code quality violations, but most importantly write a bit more documentation on the new features. 

Yes, docs are very important to test new stuff. I hope to have some free time next week to do some testing.

So far I only read this page https://code.google.com/p/mapsforge/wiki/RenderthemeV4

I was convinced that it was possible to fit an SVG pattern "n" times in a tile, but if I read correctly the only option is to have it fill the whole tile. Is this right?

BTW congrats to Emux for the new membership, and thanks to all for all the work you are doing (or did in the past).

Greetings, Maki

[Ludwig]

So far I only read this page https://code.google.com/p/mapsforge/wiki/RenderthemeV4

I was convinced that it was possible to fit an SVG pattern "n" times in a tile, but if I read correctly the only option is to have it fill the whole tile. Is this right?

 

Yes, see RenderInstruction.java:132

I do not see that as a limitation as you could always multiply your pattern in it. Since the main point of this is to ensure that tile borders become seamless when areas are filled with a pattern, I think that is a sensible limitation.

Ludwig

[Emux]

It's worth mentioning that we defined as base size for the SVG resources the 20x20 px.
I put it also on the RenderthemeV4 wiki for easy reference.

[Maki]

Well, it depends from the point of view. Having a single big tile means you have more space to randomize the pattern, avoiding the obvious repetition effect that most simple patterns suffer from, that's good for sure. There are however drawbacks and missed opportunity.

The drawback is size. The average size for my patterns is 64x64, which means that to keep the current look I would have to repeat that 64 times to fill a 512x512px tile. The SVG file size, just like the cached rendered copy, grows accordingly. Multiply that for the number of patterns, that's gonna be heavy.

The missed opportunity is scaling patterns with a single file. Currently almost all of my patterns have 2 or 3 sizes to make the graphics grow with zoom level, keeping a bit of proportion with other stuff. If I recall correctly Tobias started doing the same a while ago. Right now this means supplying separate files, with SVG we could use only one file just changing the number of repetitions according to the zoom level.

Moreover we now have the variable tile size to account for. Moving to SVG is much more needed for patterns than for symbols, from this point of view. With 0.3 it was easy, you just had to divide 256 for any integer to get the right size. With 0.5 you don't know the final tile size, so with bitmaps you can never be sure that you end up with a seamless pattern.

[Maki]

I don't know if Cruiser/Atlas beta have been already updated with the RC, but linesymbols are substantially broken. Try the attached theme on any map with a motorway. The behavior is semi random, you see some symbols at one zoom level, none at the following, then again some. It gets better at higher ZL, in real-world themes symbols start to behave better above ZL16-17, but still not perfectly (often the gap is not respected); below that you are lucky if you see a symbol at all.

On a side note in Atlas-Beta-1.1.20 on Win 7 64bit I have severe problems of tiles disappearing in random fashion, during/after panning. Atlas-Beta-1.1.6 doesn't have the problem. Cruiser works, so I think this is not a problem with the library.

Maki.

[Emux]

I don't know if Cruiser/Atlas beta have been already updated with the RC

Yes, both editions (normal / beta) are using the latest mapsforge versions of master / dev respectively (i.e. RC).

On a side note in Atlas-Beta-1.1.20 on Win 7 64bit I have severe problems of tiles disappearing in random fashion, during/after panning. Atlas-Beta-1.1.6 doesn't have the problem. Cruiser works, so I think this is not a problem with the library.

Can you tell us the monitor's resolution and the size of the Atlas window (i.e. is it full screen) ?

The difference between them is the cache that's created with different way.
In Android we normally calculate a cache suitable for the device, but in Java (as seen at sample) we use a fixed cache.
It has capacity of 64 memory and 1024 file tiles. I suspect we have to perform some calculations here too.

[Ludwig]

Well, it depends from the point of view. Having a single big tile means you have more space to randomize the pattern, avoiding the obvious repetition effect that most simple patterns suffer from, that's good for sure. There are however drawbacks and missed opportunity.

The drawback is size. The average size for my patterns is 64x64, which means that to keep the current look I would have to repeat that 64 times to fill a 512x512px tile. The SVG file size, just like the cached rendered copy, grows accordingly. Multiply that for the number of patterns, that's gonna be heavy.

This is already supported as it is possible to set a tile size multiple, e.g. 64, that is then used as the size for rendering SVG files (defining a fixed multiple means that only tile sizes that are a multiple of this number will be used when calculating the tile size, e.g. if the strict calculations would arrive at a tile size of 268, using the fixed multiple means that 256 will be used. This avoids the problem that otherwise we would have tile sizes that we cannot scale into (no subpixel rendering)).

SVG tile sizes do not actually have to grow linearly with the amount of data rendered in them as you can and should reuse elements. This works correctly in the new SVG library we are using, e.g.

<?xml version='1.0' encoding='UTF-8' standalone='no'?> 

<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.0//EN' 'http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd'> 

<svg width='256' height='256' viewport-fill="#33D40B" viewport-fill-opacity="0.3" xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'> 

  <defs>

    <g id="cross">

      <rect width="24" height="96" x="20" y="2" id="rect3092" style="fill:#000000;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />

      <rect width="60" height="24" x="2" y="26" id="rect3094" style="fill:#000000;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />

    </g>

  </defs>

  <g transform="translate(0,0)"><use xlink:href="#cross"/></g>

  <g transform="translate(140,70)"><use xlink:href="#cross"/></g>

  <g transform="translate(30,140)"><use xlink:href="#cross"/></g>

</svg>

I do not think that the rendering of SVG bitmaps is an issue:

• on device storage is not really an issue any more (and certainly not when you see what maps people load onto their devices.
• as SVG files are only rendered for the resolution that is needed (and not packaged for all possible resolutions), I think this approach actually takes less space then multiple sets of PNGs.

The missed opportunity is scaling patterns with a single file. Currently almost all of my patterns have 2 or 3 sizes to make the graphics grow with zoom level, keeping a bit of proportion with other stuff. If I recall correctly Tobias started doing the same a while ago. Right now this means supplying separate files, with SVG we could use only one file just changing the number of repetitions according to the zoom level.

I think at this point you miss the goal of varying tile sizes. Varying tile sizes are used to keep the physical size of a tile (in cm) roughly the same regardless of device resolution. So the user perception should be about the same if he sees a 256 tile on a low res device or a 768 tile on a high res Nexus 5. So you should not actually change repetitions of symbols if you have a higher tile size as they will then simply become too small to be visible.

Moreover we now have the variable tile size to account for. Moving to SVG is much more needed for patterns than for symbols, from this point of view. With 0.3 it was easy, you just had to divide 256 for any integer to get the right size. With 0.5 you don't know the final tile size, so with bitmaps you can never be sure that you end up with a seamless pattern.

See above. 

Since I had myself forgotten about half of this, I have added it to the wiki at https://code.google.com/p/mapsforge/wiki/RenderthemeV4

Ludwig 

[Emux]

Since I had myself forgotten about half of this, I have added it to the wiki at https://code.google.com/p/mapsforge/wiki/RenderthemeV4

Ludwig I had made some modifications at RenderthemeV4 wiki that are now gone with the latest update.
Have you overwrite them or revert them back?
(e.g. at symbols positions section the above_right is mentioned again two times)

[Ludwig]

Sorry, I had not realized and copy and pasted in from a file. There seems to be no edit history, grrh.

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/54357043.70001%40gmail.com.

[Emux]

It's alright, I can put them again.
(you can find the wiki history here)

[Emux]

I updated slightly the RenderthemeV4 wiki.

[Maki]

Il giorno mercoledì 8 ottobre 2014 17:37:26 UTC+2, Ludwig ha scritto:

This is already supported as it is possible to set a tile size multiple, e.g. 64, that is then used as the size for rendering SVG files (defining a fixed multiple means that only tile sizes that are a multiple of this number will be used when calculating the tile size, e.g. if the strict calculations would arrive at a tile size of 268, using the fixed multiple means that 256 will be used. This avoids the problem that otherwise we would have tile sizes that we cannot scale into (no subpixel rendering)).

 An external theme developer has no control on this, AFAIK.

SVG tile sizes do not actually have to grow linearly with the amount of data rendered in them as you can and should reuse elements. This works correctly in the new SVG library we are using, e.g.

 

This is "clones" in Inkscape lingo. It can be done, but it's mostly a pain. In any case a pattern should not have repetitions in itself, it's just against the basic idea of a pattern.

 

The missed opportunity is scaling patterns with a single file. Currently almost all of my patterns have 2 or 3 sizes to make the graphics grow with zoom level, keeping a bit of proportion with other stuff. If I recall correctly Tobias started doing the same a while ago. Right now this means supplying separate files, with SVG we could use only one file just changing the number of repetitions according to the zoom level.

I think at this point you miss the goal of varying tile sizes. Varying tile sizes are used to keep the physical size of a tile (in cm) roughly the same regardless of device resolution. So the user perception should be about the same if he sees a 256 tile on a low res device or a 768 tile on a high res Nexus 5. So you should not actually change repetitions of symbols if you have a higher tile size as they will then simply become too small to be visible.

No, I know exactly the goal of varying tile sizes. In fact if you re-read you will notice that I don't want to change the repetitions according to tile size, but according to *zoom level*, it's stated two times and I'm already doing this using multiple files for the same pattern. The reason is that in most cases if you draw a pattern that looks good at ZL 16 it will look grossly oversized at ZL 14 and ridiculously small at ZL 20. The solution is simple: fit it 7x7 times at ZL 14, 6x6 times at ZL15, 5x5 at ZL 16 and so on. A *single* SVG file would scale beautifully, if you can control the number of repetitions. But you can't, either you blow it up to tile size or you have to supply a precise size that will not be seamless. So the solution with 0.3 is to have multiple files, and the solution with 0.5 is... the same.

Maki

[Maki]

Il giorno mercoledì 8 ottobre 2014 13:46:11 UTC+2, Emux ha scritto:

On a side note in Atlas-Beta-1.1.20 on Win 7 64bit I have severe problems of tiles disappearing in random fashion, during/after panning. Atlas-Beta-1.1.6 doesn't have the problem. Cruiser works, so I think this is not a problem with the library.

Can you tell us the monitor's resolution and the size of the Atlas window (i.e. is it full screen) ?

It's 1920x1200. But it always worked well.

[Emux]

It's 1920x1200. But it always worked well.

That's strange, I cannot reproduce it at FHD screens (neither other users that I asked).
And the memory cache of 64 tiles should be enough.
The issue happens with vector or online raster maps?

The map continues to work after that? I wonder if we have OutOfMemory errors.
Can you try starting Atlas with more memory?
java -Xms64m -Xmx1024M -jar Atlas.jar

[Ludwig]

On 9 October 2014 00:41, Maki <tarta...@gmail.com> wrote:

Il giorno mercoledì 8 ottobre 2014 17:37:26 UTC+2, Ludwig ha scritto:

This is already supported as it is possible to set a tile size multiple, e.g. 64, that is then used as the size for rendering SVG files (defining a fixed multiple means that only tile sizes that are a multiple of this number will be used when calculating the tile size, e.g. if the strict calculations would arrive at a tile size of 268, using the fixed multiple means that 256 will be used. This avoids the problem that otherwise we would have tile sizes that we cannot scale into (no subpixel rendering)).

 An external theme developer has no control on this, AFAIK.

No, but I understand you dilemma and I have been thinking what to do about it. 

• One option was to have an option in the rendertheme that sets this tile size multiple, but while it might be good for you, it has the drawback that it would also give rendertheme developers an override of what application developers decide is required (imagine an app which overlays maps, with multiple renderthemes or different tile size requirements, e.g. for downloaded raster tiles). Plus this option does not fit well with the architecture as the rendertheme is far from where the tile size is decided.
  
• I think the better option would be to by default set a tile size multiple of 64 in the library. This is a reasonable multiple and will not unduly interfere with what would have been the setting anyway, plus it would also fit with standard download tile sizes of 256x256. That way you could more or less rely on a multiple of 64 being set, so you could design your patterns for a 64 size tile. An app developer could still override it, should he have special requirements, but we can make clear in the documentation that this might not work well with external renderthemes.

What do you think?

 

SVG tile sizes do not actually have to grow linearly with the amount of data rendered in them as you can and should reuse elements. This works correctly in the new SVG library we are using, e.g.

 

This is "clones" in Inkscape lingo. It can be done, but it's mostly a pain. In any case a pattern should not have repetitions in itself, it's just against the basic idea of a pattern.

It is actually mostly a pain because of Inkscape, which seems to care little about the SVGs it produces (it seems to record more the drawing process rather than the result).

 

 

The missed opportunity is scaling patterns with a single file. Currently almost all of my patterns have 2 or 3 sizes to make the graphics grow with zoom level, keeping a bit of proportion with other stuff. If I recall correctly Tobias started doing the same a while ago. Right now this means supplying separate files, with SVG we could use only one file just changing the number of repetitions according to the zoom level.

I think at this point you miss the goal of varying tile sizes. Varying tile sizes are used to keep the physical size of a tile (in cm) roughly the same regardless of device resolution. So the user perception should be about the same if he sees a 256 tile on a low res device or a 768 tile on a high res Nexus 5. So you should not actually change repetitions of symbols if you have a higher tile size as they will then simply become too small to be visible.

No, I know exactly the goal of varying tile sizes. In fact if you re-read you will notice that I don't want to change the repetitions according to tile size, but according to *zoom level*, it's stated two times and I'm already doing this using multiple files for the same pattern. The reason is that in most cases if you draw a pattern that looks good at ZL 16 it will look grossly oversized at ZL 14 and ridiculously small at ZL 20. The solution is simple: fit it 7x7 times at ZL 14, 6x6 times at ZL15, 5x5 at ZL 16 and so on. A *single* SVG file would scale beautifully, if you can control the number of repetitions. But you can't, either you blow it up to tile size or you have to supply a precise size that will not be seamless. So the solution with 0.3 is to have multiple files, and the solution with 0.5 is... the same.

Ok, I misunderstood you there. But the problem is that there is no SVG rendering to the effect 'draw this SVG file x times into the space provided'. We can only render an SVG file to an integer-sized bitmap, not subpixel size, and for most tile sizes there is no common divisor for the numbers you suggest. (So we cannot draw an SVG into 256/7x256/7 bitmap for seamless composition, we can only draw into it at 36x36 and 37x37 meaning there will be ugly seams) For all practical purposes, these SVGs are different images, but you can keep their size small and their content aligned by using the cloning technique mentioned above.  

Ludwig

 

[Emux]

I vote also for the 2nd idea, of having the tile size multiple of 64 (or 32, or ?) in the library.
(And if I remember correctly we may have discussed that another time,  when the variable tile size was first introduced)

[Ludwig]

I have just committed a change to 64. I think it is a good number for area tiles (not too small, not too large).

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/5436B8E7.8080903%40gmail.com.

[Emux]

I have just committed a change to 64. I think it is a good number for area tiles (not too small, not too large).

Ludwig, at DisplayModel.getTilingSize we have a check (this.tileSizeMultiple == 1).
We should keep it as is, and not perform the check with 64 now?

[Ludwig]

I think the code is still correct for its purpose, i.e. getting the tiling size for shader bitmaps

* Returns the minimum repeating tile size > 1, used for sizing shader bitmaps

1 is kind of special value here, as it essentially means that no value is set and the size of the map tiles should be used. 

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/54378213.1010600%40gmail.com.

[Emux]

Ok thanks, that's my thoughts too studying the changes, just wanting to verify it.

[Emux]

I published new Beta versions of Cruiser / Atlas using the latest dev,
if anyone wants to play with the tile size multiple of 64 and the themes.

[Maki]

I get this (AVVERTENZA=warning in italian) and it looks slower. Still shows the problem, also with 1.1.21.

E:\Software\GIS\Atlas-Beta-1.1.20>java -Xms64m -Xmx1024M -jar Atlas-beta.jar

ott 11, 2014 9:51:34 AM java.util.prefs.WindowsPreferences <init>

AVVERTENZA: Could not open/create prefs root node Software\JavaSoft\Prefs at roo

t 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.

ott 11, 2014 9:51:35 AM b.b.b.f.b.v a

AVVERTENZA: unreachable rule (e)

ott 11, 2014 9:51:35 AM b.b.b.f.b.v a

AVVERTENZA: unreachable rule (e) 

The program works. It's just that after the screen has been completely drawn sometimes (not always, but frequently enough to be noticed), some tiles become grey. When you pan/zoom they reappear or viceversa.

[Maki]

Il giorno giovedì 9 ottobre 2014 18:14:58 UTC+2, Ludwig ha scritto:

What do you think?

In short, I think you took the worst decision, having only two choices I much prefer to fill the whole tile. I'll get back to this later in more detail, but I have now a bigger problem. I'm preparing a test-theme to show what I mean and discuss the issue better with real world data. However I can't make the stylemenus work in both Atlas and Cruiser. I paste the code below, it's actually the wiki example with two added rules. Tested both on an italian kitkat tablet and a jelly bean phone set to english, the menu is blank. What am I missing here?

 <stylemenu id="r4menu" defaultvalue="terrain" defaultlang="en">

    <layer id="shopping">

      <name lang="de" value="Shopping"/>

      <name lang="en" value="Shopping"/>

      <name lang="es" value="Tiendas"/>

      <name lang="fr" value="Shopping"/>

      <cat id="shopping"/>

    </layer>

    <layer id="terrain" enabled="true">

      <name lang="de" value="Topographischer Hintergrund"/>

      <name lang="en" value="Topographic Colours"/>

      <name lang="es" value="Colores topográficos"/>

      <name lang="fr" value="Couleurs topographiques"/>

      <cat id="topo"/>

    </layer>

</stylemenu>

 

<rule cat="topo" e="way" k="natural|landuse" v="forest|wood"><area src="file:forest.png" /></rule>

<rule cat="shopping" e="way" k="natural|landuse" v="forest|wood"><area src="file:forest.svg" symbol-scaling="tiling" /></rule>

The whole thing (to be completed)

https://app.box.com/s/mglasprgr1ic5tcwh65t

[Emux]

Thanks for the feedback Maki, I'll investigate it more.
What Java are you using, 32bit or 64bit and what version (7 or 8)?
If you're using 64bit Java, try also with 32bit (beware the full path of the java.exe).

[Emux]

About the stylemenu there is need to replace the 'enabled' with 'visible', like:
<layer id="shopping" visible="true">

I have updated the RenderthemeV4 wiki.

[Maki]

Il giorno sabato 11 ottobre 2014 10:18:30 UTC+2, Emux ha scritto:

Thanks for the feedback Maki, I'll investigate it more.
What Java are you using, 32bit or 64bit and what version (7 or 8)?
If you're using 64bit Java, try also with 32bit (beware the full path of the java.exe).

It's Java 7, but strange enough the Java control panel doesn't provide that information (32 vs 64 bit). According to JOSM it's:

Java version: 1.7.0_67, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM

Can I install both the 32 and 64 bit at the same time? I don't want to mess up with JOSM, that's a priority, I can always test in Cruiser, but I cannot map on Android.

Maki

[Emux]

Yes you can have them both, and even different versions.
I usually install the 64bit after the 32bit (I don't remember if it matters so that the 64bit to be the default one).
And you can start the apps with the proper java.exe from each distribution.

As a side note, you can use Cruiser (or other Android apps) also at desktop using the very fast Android emulator Genymotion.

[Maki]

Il giorno giovedì 9 ottobre 2014 18:14:58 UTC+2, Ludwig ha scritto:

What do you think?

Sorry, this is going to be long... take you time.

First the SVG editors. Like it or not people will use them. I work with Illustrator 7 hours per day, but used Inkscape to build my graphics and I have to say that for this kind of job it'a very good software. The fact that it inserts extra information in the file is needed for user interaction, and can be cleaned up eventually, so no complaints here. The PNG export function is fantastic. When I talk of "pain" I refer to the fact that dealing with patterns and clones is not easy as you step into editing limitations or rounding errors that show as white space at seams like the ones I describe below. And believe me, nobody will draw patterns in a text editor.

The files to test:

A test theme can be downloaded here https://app.box.com/s/39bj8ktmq62zf5xsjx8r 

I'm not sure it works with a standard Mapsfoge map, I used OpenAndroMaps. You need an area with forests and scrubs to test.

Then (optional) you can download the source SVG for all my patterns here https://app.box.com/s/degnsvmxoxjnxxrqreik

The theme is a modified version of my theme (latest beta) with all patterns and symbols except forest and scrub removed. There are 7 styles in it. Here is my experience on a Gpad 8.3 with latest Cruiser beta (512 px tiles). I couldn't test at other densities.

1) "PNG" uses 64px patterns saved as PNG

2) "Tiling (Inkscape SVG)" uses the tiling function, the patterns are in native Inkscape SVG (you guessed it, I know...). On my tablet (512px tiles) it shows a white line at seams.

3) "Tiling (Optimized SVG)" same as above, but I did a "save as" and... you guess. No white lines at seams.

If you compare the three you'll see that:

a) there is no difference (except for the glitch with the inkscape SVG) in rendering

b) the forest PNG is much smaller and we skip the rendering step. I added a vineyard pattern to the zip. It's the simplest one, and event hat is smaller (fractionally, I agree) in PNG. SVGZ would be smaller, but it's not supported. Since we zip themes for distribution no big deal, but still...

c) there is no device scale factor

I hope you agree with me that this way of using "tiling" is totally pointless, as PNGs are better from any point of view. There is however a good thing in fixing a known multiple, people working with bitmaps can have "safe values" to rely on. I think that 64 is way too small for current devices, I'd go for 128 at least.

I have to note that the forest pattern previously failed to render; gradients and transparencies seems to be correctly supported with the new library, very good news. But still no blur effect, so forget about halos and drop shadows (or use PNG for that).

Let's go on:

4)"Percent progressive scaling". That's percent scaling with growing tile size at every zoom level. It uses the optimized SVG. On my device at some zoom levels white lines appear at seams.

5) "Percent prog. scal. (bleed)", same as above but with a different file. The original forest SVG is 100x100 px and has a 100x100 px square as a background; in this one I made the square bigger than the canvas, as we do in the print industry (print larger, and crop the sides). The seam disappeared. I can't guarantee that this will work for every file.

6) "Explicit width+height" uses both symbol-width and symbol-height, and it just works

7) "Explicit width" only sets symbol-width and doesn't work. At least I would expect it to scale the height proportionally, but it doesn't and everything is painted very small. Bug?

The percent values that I used translate in tilesize/N, rounded to the closer value. The width+height values are 256/N. This turns out to work very well, the patterns behave in a seamless way even when there are rounding errors. That's because I designed them to be tolerant to small clippings. In fact I am already using most of my patterns at rounded sizes like 85 px or 43 px in MF 0.3 without issues. It's not that I'm particularly smart, looking around almost all the patterns from Elevate, OpenAndroMaps, Freizeitkarte should behave the same way, at least used at mid-high sizes. The exception is things like the crosshatch pattern typically used for private access; it's small, so it gets repeated a lot and the rounding error can accumulate, plus that kind of graphics isn't clip-tolerant at all.

So, problem solved? I don't know. In most cases by all practical purposes it's possible to seamlessly repeat a pattern "n" times in a tile. But I wonder what happens if the app fixes the tile size (Oruxmaps for example). Is the device scale factor applied? I have this doubt because I've seen odd behaviors on Oruxmaps, in particular on an GS4 the line widths (in pixels) were larger than on a Galaxy Nexus, while the length was shorter due to the fixed tile size (512 px). Can someone test this?

In the end, what to do with "tiling"? At the very least going back to blow the pattern up to tile size would be a good idea. If anything, it scales consistently across devices. But it would still be useful to have a tile-array="x,y" parameter for those particular patterns that need exact sizing. "But we have rounding errors". Ok, so 256/7=36.6. Render the pattern at 37, repeat it 7x7 times offscreen, and then scale it down to 256 px, the degradation will not be visible, I promise.

However I think we can do away from "tiling" in another much much better way. In theory it's doable and simple, in practice... you tell me, I don't know how much code needs to be modified. The problem with patterns exists because their position is relative to the tile origin. If instead you calculate the positioning relative to an absolute reference point when using symbol-width or symbol-percent the problem is solved. This is much better solution, since you are no more limited to tile/N sizes, but you can use whatever size you want.

That's all. :-)

[Emux]

Maki thanks for the large analysis and the test theme!
(It works with standard Mapsforge maps)
I'm glad we see an actual use of the style menus.

About svg you are right, the new library has great render compatibility.
I use SVG Cleaner and SVG Converter for cleaning the svg prior using them in my themes.

Quick note, I follow Orux forum (testing the Betas) and have read its explanation about the tile size.
The 2 screenshots with the lake can be seen here.

I'll study further your thoughts.

[Emux]

7) "Explicit width" only sets symbol-width and doesn't work. At least I would expect it to scale the height proportionally, but it doesn't and everything is painted very small. Bug?

Searching the code I don't think we examine the case of a missing width / height to scale it accordingly.
In that case the default svg size (scaled) is used instead.

So, problem solved? I don't know. In most cases by all practical purposes it's possible to seamlessly repeat a pattern "n" times in a tile. But I wonder what happens if the app fixes the tile size (Oruxmaps for example). Is the device scale factor applied? I have this doubt because I've seen odd behaviors on Oruxmaps, in particular on an GS4 the line widths (in pixels) were larger than on a Galaxy Nexus, while the length was shorter due to the fixed tile size (512 px). Can someone test this?

The fixed tile size is independent of the elements scale calculations e.g. symbols .
The device scale factor is always applied to the values metrics.

[Ludwig]

Maki,
The suggestion with an absolute reference point makes a lot of sense. The absolute ref point would be 0,0 and we would just have to calculate how many times we are away from that point. The tricky bit will be manipulating the paint to conform.
I will investigate later today.
Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/543A4E8C.4070600%40gmail.com.

[fzk]

> I'm glad we see an actual use of the style menus.

How to get advantage of the style menus? I tried it with Cruiser and Cruiser Beta but couldn't find the hook to activate something like a menu or layer system.

Klaus

[Emux]

You can check RenderthemeV4 wiki instructions for start and the rendertheme-v4.xml theme at Samples for a complete example.

Maki has implemented also above a fine example at its test theme (starting at line 230).

Atlas (as Cruiser) also supports style menus.

[fzk]

> Maki has implemented also above a fine example at its test theme (starting at line 230).

Yes, that's what I'm trying ... I want to play around with Maki's test theme and Cruiser Beta.

How can I activate / deactivate / choose a menu or layer within the theme?

My expectation: There must be an entry in the app? Right?

Klaus

That's in the doc:

You can think about the cat tag as a switch that switches all elements in the rendertheme below it either on or off. If a category is turned off, all elements below it become invisible. If a category is turned on, all elements below become visible (unless they are themselves controlled via a category which is turned off). 

Layers are combinations of categories that can together be toggled on and off. In general, categories are not visible to a map user, but layers are. To make layers more user friendly, they can be named with the name tag in various languages.

[Emux]

Ok I understand, the map styles can be accessed:

- Cruiser: menu Map - Render theme - Map style
- Atlas: menu Vector - Render theme - Map style (Ctrl+Shift+S)

[fzk]

Aha, there is it hidden - thanks.

Klaus

BTW: For me it was not intuitive to find the menu (named "Map style") there. Such a layer menu must be reachable very easily. The feature itself is very interesting in order to activate / deactivate elevations, buildings or what else ever.

[Maki]

Il giorno domenica 12 ottobre 2014 11:49:05 UTC+2, Emux ha scritto:

So, problem solved? I don't know. In most cases by all practical purposes it's possible to seamlessly repeat a pattern "n" times in a tile. But I wonder what happens if the app fixes the tile size (Oruxmaps for example). Is the device scale factor applied? I have this doubt because I've seen odd behaviors on Oruxmaps, in particular on an GS4 the line widths (in pixels) were larger than on a Galaxy Nexus, while the length was shorter due to the fixed tile size (512 px). Can someone test this?

The fixed tile size is independent of the elements scale calculations e.g. symbols .
The device scale factor is always applied to the values metrics.

Can this be set by the app? In any case I think that as a default behavior it should be changed. In my very small test, highways getting fatter didn't look well at all, and I remember problems with captions too. I only have 300 dpi devices handy so I can't do any extensive test. But I imagine that it can become very problematic, Oruxmaps is a rather lucky case. The choice of 512px tile size means it is in line with the specs for the current mid-range device, high end screens will see a lines 150% the size of their intended width, and low end ones will see 70%. It's noticeable but not the end of the world. However the fixed tile size will probably be used in legacy situations which means 256px. In that case, someone with a 450dpi screen would see lines 2.5x times the intended size, this is unusable. IMHO fixed size implies calculating the device scale factor considering the tile size, not the real display dpi (i.e. 512px tile = 2x device scale factor, regardless of the device), otherwise the results are unpredictable.

BTW, I agree with Klaus, the map-style menu should be more accessible than the theme chooser, I think it is supposed to be used more.

Maki

[Emux]

If I remember correctly when the automatic variable tile size was introduced the concept was that with the increase of the tile size we see all the rendered vector data larger (labels, roads, building etc.)
And that was the intended way to play with the tile size (or better to let it handle itself).

Then we starting having issues with the online raster tile sources (e.g. Mapnik) with blurry graphics at any tile size above 256. So the fixed tile size was implemented - affecting only tile size and not scaling.
e.g. at Cruiser I use fixed tile size with online raster map sources.

If I understand you propose when we set a fixed tile size to perform the same scale calculations that happen when the variable tile based on a device dpi is defined?

BTW, I agree with Klaus, the map-style menu should be more accessible than the theme chooser, I think it is supposed to be used more.

Well apparently there is need to rework Cruiser UI (I keep also your other suggestions).

[Emux]

Thinking it more..

Currently we have a one way process, the device dpi defines automatically the scaling and subsequently the tile size.

If we implement also the opposite route, we set a fixed tile size and that accordingly defines the scale factor.. then we must be careful about the side effects that are introduced.

The scale factor is used at many places in the library, e.g. in scale bar metrics.
If we set it totally free then we may have a case of very large scale bar on a device with low dpi, just because we want to set a larger tile size.

[Maki]

I don't know the internals so I cannot always follow you.

The point is that a tile should look the same at every dpi, fixed or variable. In other words a 768px tile should be identical whether if generated because of automatics tile size or fixed. And the same tile generated at 768px when downsampled to 256px should should be "identical" to one generated directly generated at 256px. On any device.

The scale bar should be proportional to the effective tile size. E.g. if the tile edge is in reality 1km, the scale bar indicates 300m at 30% of a tile, whatever the tile size is in px.

One note about the map-styles. There should be a check for the default layer to make sense. If you look at the second pattern test that I posted you'll see that at the first opening the three styles in it are drawn each on top of the other, because I misspelled the default name. Since layers are meant to be mutually exclusive drawing one on top of the other should be avoided at all cost. I'd rather have a blank screen, at least it's immediately obvious that something is going wrong.

Maki

[Emux]

The fixed tile size was not meant for the user to usually set it at vector maps.
It's still preferable to use the automatic scaling from the device dpi.

The fixed tile has very specific uses, such as raster maps (where the scaling needs not adjustments).
Now for change it and affect the scaling, let's wait also for Ludwig's thoughts.

The scale bar cannot follow strictly the tile size as it is a UI component.
It has to be compatible with device's dpi as all Android resources in an app.

About the map styles, I have not managed to use properly the 2nd test.
Yes there is need for correcting the xml, but even after that I remember seeing only empty white map.

[Maki]

Il giorno martedì 14 ottobre 2014 13:54:26 UTC+2, Emux ha scritto:

The fixed tile has very specific uses, such as raster maps (where the scaling needs not adjustments).
Now for change it and affect the scaling, let's wait also for Ludwig's thoughts.

As I said it's not a big deal with Oruxmaps due to the 512 px choice. I could test on an S4 again today, there is a difference but it's not as bad as my memory suggested, in part due to the changes I made to the theme too. Actually from a certain point of view it's good since lines remain more visible, they just touch more in case of tight hairpins or roads in proximity as buildings. As long as the density jump is one single class (233<-300->450) it still works, and Jose put enough tweaks in the settings.

I don't know other large diffusion apps using Mapsforge so it's probably not an issue at all. My worry was that the 256/N trick for patterns was going to break, but since it isn't needed any more... problem solved.

 

About the map styles, I have not managed to use properly the 2nd test.
Yes there is need for correcting the xml, but even after that I remember seeing only empty white map.

 

OpenAndroMaps put the sea below everything else, so since forests aren't a good test subject at low zoom (due to typically small size) levels I moved the pattern to the sea and removed everything else. Maybe your map hasn't the sea?

[Emux]

My worry was that the 256/N trick for patterns was going to break, but since it isn't needed any more... problem solved.

Please have a look also at AWT implementation (Atlas Beta 1.1.22) when you have time.

At Java the tile size is by default 256, but you can still change the 'display scale' at settings (as with Cruiser too) which changes tile size along with other things.

 Maybe your map hasn't the sea?

Indeed I was playing with mapsforge maps like with test 1, I'll try OpenAndroMaps too.

[Emux]

One note about the map-styles. There should be a check for the default layer to make sense. If you look at the second pattern test that I posted you'll see that at the first opening the three styles in it are drawn each on top of the other, because I misspelled the default name. Since layers are meant to be mutually exclusive drawing one on top of the other should be avoided at all cost. I'd rather have a blank screen, at least it's immediately obvious that something is going wrong.

I have looked also what happens here, where we had the misspelled 'defaultvalue'.
In that case the returned active categories set is empty/null (handled by the app).

From the source I copy the way we handle the various cat cases:
"a rule is visible if categories is not set, the rule has not category or the categories contain this rule's category"

[Ludwig]

I have just pushed a change to dev that uses the aspect ratio if only one of width or height are set in the rendertheme. I agree that makes sense and makes styles easier to write.

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/543E2EB7.8070801%40gmail.com.

[Ludwig]

> One note about the map-styles. There should be a check for the default layer to make sense. If you look at the second pattern test that I posted you'll see that at the first opening the three styles in it are drawn each on top of the other, because I misspelled the default name. Since layers are meant to be mutually exclusive drawing one on top of the other should be avoided at all cost. I'd rather have a blank screen, at least it's immediately obvious that something is going wrong.


>
> I have looked also what happens here, where we had the misspelled 'defaultvalue'.
> In that case the returned active categories set is empty/null (handled by the app).
> From the source I copy the way we handle the various cat cases:
> "a rule is visible if categories is not set, the rule has not category or the categories contain this rule's category"

I have not had time to look into this in detail, but I think the
behaviour is correct.
The reason that we display everything if the categories are not set is
to support older render themes or render themes that do not have any
styles. So if nothing is set, everything will be displayed, like
before.

Catching out semantic errors is pretty much impossible. We all would
like to have this 'do what I mean, don't do what I write' function,
but computer scientist have yet to come up with an implementation for
it.

While we could put a check for this particular problem, there will be
another thousand that are not covered and trying to anticipate them is
just not worth the time.

In this particular context I think a using a validating parser to
check against the DTD would have caught this in testing.

Ludwig

[Ludwig]

Sorry, done again. I am, yet again, in a place with wobbly internet.

Counting objects: 51, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (18/18), 1.44 KiB | 0 bytes/s, done.
Total 18 (delta 8), reused 0 (delta 0)
error: RPC failed; result=52, HTTP code = 0
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly

Thanks for the alert. 

I always push to google first before pushing to github. If you do the same, even if we push as the same time, we cannot get into the situation where one of us pushes first to one repo, the other something else to the other. 

Ludwig

On 15 October 2014 12:27, Emux <deve...@gmail.com> wrote:

I have just pushed a change to dev that uses the aspect ratio if only one of width or height are set in the rendertheme. I agree that makes sense and makes styles easier to write.

Ludwig have you pushed also at GitHub (I don't see it) ?

--
Emux
Cruiser - Atlas

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/543E3E19.4060403%40gmail.com.

[Emux]

Ok and I removed my message because I saw the changes at GitHub after some minutes.
(Yes I always push first to Google too).

[Ludwig]

The point is that a tile should look the same at every dpi, fixed or variable. In other words a 768px tile should be identical whether if generated because of automatics tile size or fixed. And the same tile generated at 768px when downsampled to 256px should should be "identical" to one generated directly generated at 256px. On any device.

I agree that that should be the goal. I know that we do not get this entirely right, the problem mainly being that certain tricks very involved to scale up text sizes and then also line width (to make space for the increased text) prior to the tiling trick being introduced. 

For setting the scale factor through a fixed tile size, yes, it should also work that way around, it is just nowhere on my list of priorities and I dread the can of worms we will be opening again. 

I will try to find some time to have a look at this in the next few days to get a clearer picture of what we really have and where the problems lie. 

It is usually best to send me screenshots to illustrate a problem. 

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/543E3FB0.2070608%40gmail.com.

[Emux]

For setting the scale factor through a fixed tile size, yes, it should also work that way around, it is just nowhere on my list of priorities and I dread the can of worms we will be opening again.

My doubts too! And it needs careful approach as we have many cases like vector maps, raster maps, library UI components etc.
Though I think that if we implement it correctly it could a useful feature.

It is usually best to send me screenshots to illustrate a problem.

Ludwig I suggest to take a look also at Orux (fixed 512px) lake screenshots and its approach.

[Ludwig]

I pushed a change to remove the tiling directive from the rendertheme-v4.xsd  and related code. 

I checked what happens if the tiling directive is present in a rendertheme and the map will still render, but the shader will be scaled to normal symbol size (so normally much smaller than with tiling). But it ensures that in transition renderthemes with the tiling directive do not crash apps.

Do will still want to set a tile size multiple of 64? It is technically not needed anymore, the only advantage being more predictable tile sizes.

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/543E4743.9060407%40gmail.com.

[Emux]

Do will still want to set a tile size multiple of 64? It is technically not needed anymore, the only advantage being more predictable tile sizes.

Well we have cases that tile sizes can have a bit strange value.
e.g. I think Nexus 7 2012 has 213dpi and 1.33 scale factor.
What tile size we prefer there?

[Maki]

Il giorno mercoledì 15 ottobre 2014 11:23:41 UTC+2, Ludwig ha scritto:

> I have looked also what happens here, where we had the misspelled 'defaultvalue'.
> In that case the returned active categories set is empty/null (handled by the app).
> From the source I copy the way we handle the various cat cases:
> "a rule is visible if categories is not set, the rule has not category or the categories contain this rule's category"

I have not had time to look into this in detail, but I think the
behaviour is correct.
The reason that we display everything if the categories are not set is
to support older render themes or render themes that do not have any
styles. So if nothing is set, everything will be displayed, like
before.

There's a catch. Things are not like before. Map-styles are not meant to turn off some categories in a theme that is normally conceived to show everything at once. The mutual exclusivity of map styles leads to alternative things present in the same theme (e.g. mtb vs hiking, public vs private transportation, detailed vs simplified landuse). So, only one layer should be enabled at once. If the default value fails there should be a fallback mechanism, for example using the first layer in the list. The same if the hosting app doesn't support style switching: only the default one should be used, and that default has to exist or there should be a fallback. If you ignore categories in such a situation it's a mess with things drawn on top of other things. If there is no <stylemenu> then ok, show everything, that's the theme intent anyway.

Maki.

[Maki]

IMHO if you can get the real dpi go for the exact value. I thought there were only density classes that encompassed broad ranges.

Some more testing this evening: using src on lines* shows seams at tile boundaries, if possible the same system used for areas should be used. Test theme attached, it draws a crosshatching on primary roads from ZL 13.

I also tested a bit the priority on symbols, and didn't find problems.

Regarding Atlas I installed Java 8 on a secondary partition and I still have the problem. 1.1.6 works fine 1.1.20+ doesn't. I missed the versions in between. Can those still be downloaded somewhere in order to find when the problem was introduced? 

Maki

* BTW, whoever invented that features is a genius

[Ludwig]

Some more testing this evening: using src on lines* shows seams at tile boundaries, if possible the same system used for areas should be used. Test theme attached, it draws a crosshatching on primary roads from ZL 13.

Thanks for spotting, I will add that. 

 

I also tested a bit the priority on symbols, and didn't find problems.

Thanks for testing.

I will have to think about the dpi issue, there are some reasons why Google has these scaling classes.

Ludwig

[Emux]

Thanks Maki for your valuable feedback regarding Mapsforge!

(About Atlas Beta I PM you)

[Ludwig]

Some more testing this evening: using src on lines* shows seams at tile boundaries, if possible the same system used for areas should be used. Test theme attached, it draws a crosshatching on primary roads from ZL 13.

Thanks for spotting, I will add that. 

This should be fixed in dev now. Thanks again.

[Emux]

I published Cruiser Beta 1.3.26 and Atlas Beta 1.1.23 with the latest dev.

Maki at Atlas Beta 1.1.23 I increased the memory cache to 128 tiles (from 64) for testing it.
Unfortunately I cannot reproduce the issue, playing with 32bit & 64bit Java.
I also see gray tiles / areas after pan (or reload) but those are always filled soon after.

[Maki]

Il giorno sabato 11 ottobre 2014 22:18:37 UTC+2, Maki ha scritto:

The files to test:

A test theme can be downloaded here https://app.box.com/s/39bj8ktmq62zf5xsjx8r 

I'm not sure it works with a standard Mapsfoge map, I used OpenAndroMaps. You need an area with forests and scrubs to test.

Did something change between the RC and the final release? I can't get the SVG forest pattern linked above work anymore.

Maki.

[Emux]

What do you mean?
I tested with "Tiling (Optimized SVG)" map style.

[Ludwig]

Remember that the svgs get cached, the samples app has in the menu something to clear the cache

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/54CD369C.2060702%40gmail.com.

[Maki]

Il giorno sabato 31 gennaio 2015 21:10:09 UTC+1, Emux ha scritto:

What do you mean?
I tested with "Tiling (Optimized SVG)" map style.

I was updating Tiramisù but couldn't get an SVG pattern to work. After a number of unsuccessful attempts I decided to try something that worked in the past. For me it isn't working anymore. Forests are drawn pure white with the SVG patterns (all of them). I tried with both OruxMaps beta and Cruiser, on a kitkat Gpad 8.3 and a Jelly Bean Galaxy Nexus. Everything stock, no root, no anything. I also tried to reset Cruiser (delete all data from the OS). Just in case my local copy got corrupted I downloaded the zip from Box. Still no joy.

Maki

[Emux]

For the record Cruiser automatically clears svg cache (along with tile cache) with any render theme change / map reload.

[Ludwig]

Maybe cannot write to disk? But then it should just rerender all the time.
Question really is what is special about maki's setup, it all works for me

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/54CD3D4B.5090109%40gmail.com.

[Emux]

Yes the above zip works for me too.

Maki has the svg creation process changed and maybe we have compatibility issues with the svg lib?

[Maki]

Il giorno sabato 31 gennaio 2015 21:44:33 UTC+1, Emux ha scritto:

Yes the above zip works for me too.

Maki has the svg creation process changed and maybe we have compatibility issues with the svg lib?

Do you have an old Cruiser APK that I can test? What puzzles me is that I have the same problem on two different devices.

[Ludwig]

Language setting ?

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/e1fc4306-d0e3-4375-a755-e64772064004%40googlegroups.com.

[Maki]

Il giorno sabato 31 gennaio 2015 22:07:45 UTC+1, Ludwig ha scritto:

Language setting ?

Italian. But I switched the phone to English and no luck, even after reboot. If it works for you both it's probably something extremely stupid on my part, I just can't figure out what. Questioning Windows I unzipped the theme on the device, but it didn't change. Maybe some sleep will help, I was just wondering if there was some later change in the SVG library.

[Maki]

Il giorno sabato 31 gennaio 2015 21:40:51 UTC+1, Ludwig ha scritto:

Maybe cannot write to disk? But then it should just rerender all the time.
Question really is what is special about maki's setup, it all works for me

I'm still having this issue. Any tip about how to debug it? It's only the forest pattern, the scrub works fine. The forest is working fine in latest Atlas Beta, but not on phone and tablet. I'd just draw another pattern, but the fact is that it worked before, so it must work.

Maki

[Emux]

Is the map file on desktop and on the mobile devices (with the issue) the same?
Maybe it's a map file without the tags for the forest defined in render theme?

[Maki]

Il giorno sabato 21 febbraio 2015 16:46:19 UTC+1, Emux ha scritto:

Is the map file on desktop and on the mobile devices (with the issue) the same?
Maybe it's a map file without the tags for the forest defined in render theme?

No, because the default map style uses a PNG and it displays fine. When I switch to the SVG the scrubs are drawn, the forests aren't. I suppose that the library throws an error when not being able to draw something. Is there a way to have a log?

[Emux]

For a log you need either to have installed the Android SDK for its Logcat or use a log viewer on the device (probably needs root from JB).

https://play.google.com/store/apps/details?id=com.nolanlawson.logcat

[Maki]

Il giorno sabato 21 febbraio 2015 17:17:54 UTC+1, Emux ha scritto:

For a log you need either to have installed the Android SDK for its Logcat or use a log viewer on the device (probably needs root from JB).

https://play.google.com/store/apps/details?id=com.nolanlawson.logcat

Yes, needs root, which means wiping the device... not now.

Anyway I played a couple of days with SVG textures, some random facts and thoughts:

a) Salamander SVG is much more robust when it comes to SVG specs support. After successfully testing in Atlas beta I moved the theme to the phone and I had to redo some, even simple ones, patterns because they didn't render. I attach one sample. Couldn't Salamander be used in Android, too?

b) I have caching issues in Atlas beta. If I modify the SVG file, just reloading (F5) isn't enough, I have to quit and reopen the app. Changes in the XML are handled fine, however.

c) reloading the map from the "tools" menu usually works fine in Cruiser, but it happened once that I had to rename the SVG file, because no matter what I did (reloading, switching maps and/or theme) it didn't see the changes I made.

Maki

[Emux]

Thanks for the feedback Maki.

Could you please repost your remarks in the Java SVG topic so that we have them together there with the other relative stuff?

[Emux]

Maki I answered here.

[Maki]

Il giorno domenica 22 febbraio 2015 13:34:44 UTC+1, Maki ha scritto:

c) reloading the map from the "tools" menu usually works fine in Cruiser, but it happened once that I had to rename the SVG file, because no matter what I did (reloading, switching maps and/or theme) it didn't see the changes I made.

I had more serious problems with OruxMaps, so I asked Jose to implement cache clearing at theme change. He did, and at the first theme change the SVG cache cleared correctly... except for one file, and that's exactly the same file that gave me exactly the same problem in Cruiser. That was yesterday, today I reloaded the theme and it worked. Could it be that the library/OS/NAND/whatever has troubles detecting the fact that the file has changed and uses a previously cached version? I mean a cached SVG, not the rendered copy.

Maki

[Emux]

Maki are you performing those actions on a device and at the same time that device is connected with your pc ?
I suspect some file system caching in that case, like when you don't see from your desktop file manager immediately the file system changes on the usb connected device.

Or maybe this svg file has any strange file name?

[Maki]

Yes, the phone is connected to the PC, it's the only way I have to upload the files. I tried several FTP/WebDAV servers (mostly to be able to work directly on the files rather than continuously replacing them) but none worked reliably with Windows. It's better with OSX, but that's at work.

If it happens again I'll try to disconnect and reconnect.

File name is p_rock.svg doesn't look too fancy.

[Emux]

On 25/02/2015 08:52 πμ, Maki wrote:

Yes, the phone is connected to the PC, it's the only way I have to upload the files. I tried several FTP/WebDAV servers (mostly to be able to work directly on the files rather than continuously replacing them) but none worked reliably with Windows. It's better with OSX, but that's at work.

You can try with AirDroid.