Support for async lines

[fzk]

I have the requirement to construct (async) lines like this one (the line with the arrows; signature for cliffs):

Such a line can be constructed with:

      <rule e="way" k="*" v="cliff">
        <line stroke="#777777" stroke-width="0.3" stroke-linecap="butt"/>
        <lineSymbol src="file:/symbols/richtungspfeil-klippe.png" align-center="false" repeat="true"/>
      </rule>

The problem: Currently it's not possible to define the gap between two symbols.

Question: Is it possible to control the gap with an additional parameter?

E.g. something like this (see parameter repeat-gap="0dp" at the end of the line):

      <rule e="way" k="*" v="cliff">
        <line stroke="#777777" stroke-width="0.3" stroke-linecap="butt"/>
        <lineSymbol src="file:/symbols/richtungspfeil-klippe.png" align-center="false" repeat="true" repeat-gap="0dp"/>
      </rule>

Cheers Klaus

PS: Screenshot (from user jusc) created with Locus Pro which has such a feature.

[Ludwig]

Could you send me the file for the symbol for testing? It should be easy to implement as fundamentally the repeat distance is just hard-coded.

Also, you could ask the author of Locus Pro for their code, after all this an LGPL project.

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/9d7bff98-fb43-4943-953c-2c2a9dc15671%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ludwig]

I have added something like this to rescue-exp, new attributes are

dy: offset to center of line

repeat-gap: gap between repeats

repeat-start: distance from start to first symbol

I have modified pedestrianized streets in Samples to show a cliff-like line with two interspaced symbols.

Let me know if there are any problems with it.

Ludwig

[Tobias]

Am Dienstag, 25. März 2014 16:05:18 UTC+1 schrieb Ludwig:

I have added something like this to rescue-exp, new attributes are

dy: offset to center of line

repeat-gap: gap between repeats

repeat-start: distance from start to first symbol

That great, could that also be added to pathText? That would solve one of the issues I mentioned here: https://groups.google.com/d/msg/mapsforge-dev/IZ8Ctnmwuv0/jyQTWk4bSxAJ

Best regards,
Tobias

[Ludwig]

dy is already a option for path texts, so it is possible to stack labels.

How do you see the other options working? There is no control over the length of a label, so I do not really understand how you would think interlacing of labels could work.

--

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/8f7d0659-cde2-4357-a20c-d1d142c45eae%40googlegroups.com.

[fzk]

Hi Ludwig,

here is the cliff icon (sag).

Link to the icon: https://dl.dropboxusercontent.com/u/1677057/cliff.svg

And that's the code in the Locus theme:

   <!-- Test cliff lines and symbols -->
    <rule e="way" k="natural" v="cliff" zoom-min="14">
        <line stroke="#404040" stroke-width="0.3" />
        <lineSymbol src="file:../V-Scale/patterns/cliff.svg"  dx="0" repeat="true"  repeat-gap="5dp" scale="0.25" scale-icon-size="15,1.1" />
    </rule>

Concerning tests I have to wait for a new cruiser beta / atlas beta version with support for this feature.

Klaus

PS: Thanks to user jusc for providing the icon.

[Ludwig]

If locus supports this feature, you have the right under the LGPL to ask for the modified source code.

--

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/6590da91-7c3f-4ffd-8f71-3cbe4ae0ba62%40googlegroups.com.

[emux]

Concerning tests I have to wait for a new cruiser beta / atlas beta version with support for this feature.

I published Cruiser Beta 1.3.5 and Atlas Beta 1.1.4 with latest mapsforge rescue-exp.

--
Emux
Cruiser - Cruiser Beta
Atlas - Atlas Beta

[Tobias]

I played a bit with dy for lines/pathText/lineSymbol. I find it quite hard to use in many cases, as dy doesn't scale with zoom as line width does.

For example if I want to make a tunnel with two parallel lines and dy, it's about the right size with this code at ZL16:

    <rule e="way" k="tunnel" v="yes">
        <rule e="way" k="highway" v="motorway">
            <line stroke="#80CCCCCC" dy="4" stroke-width="0.5" stroke-dasharray="10,2" stroke-linecap="butt" />
            <line stroke="#80CCCCCC" dy="-4" stroke-width="0.5" stroke-dasharray="10,2" stroke-linecap="butt" />
        </rule>
    </rule>
    <rule e="way" k="tunnel" v="~">
        <rule e="way" k="highway" v="motorway">
            <line stroke="#FF7700" stroke-width="2.5" stroke-linecap="butt" />
            <line stroke="#FFFF00" stroke-width="0.8" />
        </rule>
    </rule>

But the tunnel lines move farther away with lower zoom, and closer together with higher zoom. So I have to make lots of different rules for different ZL if I want to make it work.
Same goes for pathText: at one ZL it is with a close distance to the corresponding line, at another it has a far distance, at a third it's above the line (same goes for lineSymbol).

So at the moment it's nice to have, but a bit cumbersome to use. Is it possible to scale it with zoom level the same as line width scales?

Best regards,
Tobias

[Emux]

My suggestion for the future is to think about moving away from dy with fixed values, even if they are scaled.

I prefer the logic we have at symbols with positions relative to the element and the engine puts them at the right adjacent places.

--
Emux
Cruiser - Atlas

[Tobias]

Am Mittwoch, 4. Februar 2015 09:16:49 UTC+1 schrieb Emux:

My suggestion for the future is to think about moving away from dy with fixed values, even if they are scaled.

I prefer the logic we have at symbols with positions relative to the element and the engine puts them at the right adjacent places.

Fine for me, as long as consistent behavior for different zoom levels is possible.
Best regards,
Tobias

[Emux]

Nevertheless your remark Tobias seems right, we need to look after it.

[Emux]

Tobias can you open an issue about that in GitHub issues in order to not forget it?

[Ludwig]

+1

--

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/54D283B1.7020207%40gmail.com.

[Tobias]

Am Mittwoch, 4. Februar 2015 21:40:19 UTC+1 schrieb Emux:

Tobias can you open an issue about that in GitHub issues in order to not forget it?

Done: https://github.com/mapsforge/mapsforge/issues/580

[Emux]

Thanks Tobias, I confirmed that.

[Maki]

Il giorno mercoledì 4 febbraio 2015 09:16:49 UTC+1, Emux ha scritto:

My suggestion for the future is to think about moving away from dy with fixed values, even if they are scaled.

I prefer the logic we have at symbols with positions relative to the element and the engine puts them at the right adjacent places.

In this specific case, I beg to differ. This is not a text gap, it's a line offset, that we may want to be precise for whatever reason. In Tobias' case he wants to align the tunnels with the regular road. I plan to use this to border some paths and tracks on one side to highlight network relations.

Another thing I hoped to use dy for is to put a border to natural reserves, without the nasty tile border effect we got with MF 0.4. It actually mostly works at higher zoom levels, but screws up spectacularly at ZL13 and below. Test theme attached, try on any forest area.

Maki

[Emux]

On 05/02/2015 11:06 μμ, Maki wrote:

Another thing I hoped to use dy for is to put a border to natural reserves, without the nasty tile border effect we got with MF 0.4. It actually mostly works at higher zoom levels, but screws up spectacularly at ZL13 and below. Test theme attached, try on any forest area.

Maki if you mean the tile artifacts on zooms 12-13 (which I see), that's a known issue that I think it can be solved easily by using custom zoom intervals (i.e. in my maps I managed to eliminate that).

AFAIK in Mapsforge server we use the default zoom intervals.

[Ludwig]

I just pushed a change to dev that scales the dy value in line with the scale factor applied to lines in general.

https://github.com/mapsforge/mapsforge/commit/fa828cb81657dcc72f88af5aaefb5b8c97dbf78f

I think in general this looks better, but one has to keep in mind that the wider the lines get (and thus the wider dy gets) it also means that the offset lines can straddle parallel running other lines (but this is generally true for all lines as they get wider and wider).

The one thing I am just thinking about as I pushed the change is that this change will apply universally, i.e. if someone already has a different rendertheme with dy values depending on zoomlevel this will still scale those lines further. Is this an issue? I would prefer to keep the change to the library as small as possible, but an option would be to increase the version number of the rendertheme and apply the scaling conditionally on the rendertheme version number. (So we would move to rendertheme V5 and put all other rendertheme changes into this until we come to mapsforge 0.6 when rendertheme V5 would then officially be released.)

Let me know. I am not using dy much myself at the moment, so this affects me little.

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/54D3DEE0.2060301%40gmail.com.

[Tobias]

Thanks for the fix, it works great for line, but pathText and lineSymbol are still moving in distance to the original line with zooming in/out.

The one thing I am just thinking about as I pushed the change is that this change will apply universally, i.e. if someone already has a different rendertheme with dy values depending on zoomlevel this will still scale those lines further. Is this an issue? I would prefer to keep the change to the library as small as possible, but an option would be to increase the version number of the rendertheme and apply the scaling conditionally on the rendertheme version number. (So we would move to rendertheme V5 and put all other rendertheme changes into this until we come to mapsforge 0.6 when rendertheme V5 would then officially be released.)

Let me know. I am not using dy much myself at the moment, so this affects me little.

As far as I know there are very little standalone V4 themes available, I don't know about integrated ones.
So for this case it won't matter much probably if it would already be released in an 0.5.x release an no other changes. But the V5 would be the best and cleanest solution if it would be released with 0.6.

Best regards,
Tobias

[Emux]

(I also try to avoid using dy in my themes)

As Tobias mentioned the render theme v4 probably is not wide spread yet.

So you propose to keep for the time that change in dev branch and integrate it in the future at theme v5 of Mapsforge 0.6 ?

[Ludwig]

I think if there is problem with backwards compatibility, it is preferable to just push the change to master soon rather than having some rendering conditional on theme version and mapsforge version that we would need to maintain. It is not a change in the rendertheme xsd, but simply a nicer rendering of existing directives. 

If we pushed that change to master for 0.5.1, it would be the quickest way of getting the rendering change out into apps and then we can just forget about it.

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/54D760B0.4010504%40gmail.com.

[Emux]

+1

[Ludwig]

Ok, let's just wait for feedback on the second commit and then just push the stuff to master, and make a 0.5.1rc1.  

Having finally escaped the European winter, I feel like moving at a faster pace again. 

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/54D8C24A.7050001%40gmail.com.

[Emux]

On 09/02/2015 04:26 μμ, Ludwig wrote:

Ok, let's just wait for feedback on the second commit and then just push the stuff to master, and make a 0.5.1rc1.  

Sorry for not publishing yet Beta versions of Cruiser / Atlas bundle based on dev for people to test the latest changes..
I added a major new feature to the apps and I'm in the middle of making sure all work ok.

Having finally escaped the European winter, I feel like moving at a faster pace again.

:)

[Tobias]

Am Montag, 9. Februar 2015 15:33:28 UTC+1 schrieb Emux:

On 09/02/2015 04:26 μμ, Ludwig wrote:

Ok, let's just wait for feedback on the second commit and then just push the stuff to master, and make a 0.5.1rc1.  

Posted it at the issue, getting closer :-)
 

Sorry for not publishing yet Beta versions of Cruiser / Atlas bundle based on dev for people to test the latest changes..

No big problem, I used samples App from jenkins, also it's a bit less comfortable for testing theme issues.

Best regards,
Tobias