Well, it doesn't happen often - and I couldn't notice a change happened due to the patch - here is a screenshot of what the problem looks like (oneway=yes arrows, created using continue - then afterwards the road you see is created) - (location - Mödling, Austria - 200m south along the rails from the Trainstation): -- the problem is that on the left road, some filter moves the arrows away from the road - as the filter is only enacted on the arrows, but not on the road... (I think though this is not merge-lines, but a reduce filter).

On 04.05.2013 03:02, Gerd Petermann wrote:
Hi Felix,

good point.
Up to now we treat a road different because we split it into pieces before we apply the filters. This is done to make
sure that no filter eliminates parts of a road which are needed for routing.
I don't understand yet in what case this might change the results of the filters, so If you see these problems with the
patched version (with or without merge-lines), please send some data to reproduce the problem (I'll try as well).
Also let us know if merge-lines changed anything besides the img size.

Gerd



Date: Fri, 3 May 2013 16:46:23 -0400
From: extremecarver@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] merge-lines and routing

I have one problem with merge-lines - I often copy a road to put non routable overlays on it. Currently I think sometimes the merge-lines or some other filters are enacted on those copies - hence stuff like oneway arrows (non routable) will be having a different shape, than the underlying road.

I think I would need to have all ways that have a highway=* tag excluded at 24 (or make sure that if the way is done by using a continue/continue with_actions command - either before or after - will not be processed, or processed the same way as the highway).

So assuming a road with highway=tertiary & oneway=yes I create to lines (0x04 and 0x10650)

1.:
oneway=yes [0x10650 resolution 24 continue]
highway=tertiary [0x04 resolution 20]

both ways should be processed equally,

2.
highway=tertiary [0x04 resolution 20 continue]
oneway=yes [0x10650 resolution 24]

both ways should be processed equally again.


3.
however a way with railway=line & oneway=yes
oneway=yes [0x10650 resolution 24 continue]
railway=line [0x10651 resolution 22 continue]

should be processed, as they don't include a routable copy/origin created using continue command.


Therefore I think exclude all filtering that is not done to highway=* (or other definable keys) also for any other line that has a highway tag.
I haven't tried the patch yet (will do now) - but I think it could make this above problem worse....
On 03.05.2013 04:20, Gerd Petermann wrote:
Hi WanMil,

okay, this will be a big change that requires a branch. So, for now,
I'd like to finish the merge-lines issue.
Attached is version 2 of the patch that allows merging lines at all resolutuions
except for roads on res 24.

Some numbers for a map of niedersachsen with default style and lots of enabled features:
(seconds run time,  gmapsupp.img size in bytes)
r2581 with merge-lines: 99s, 127.567.872
r2581 with no-merge-lines: 103s, 128.182.272
patched r2585 with merge-lines: 95s, 125.599.744
patched r2585 with no-merge-lines: like r2581

I see no good reason why merge-lines is an option. I think we should enable
it and remove the parm, or at least, make merge-lines the default and allow
to switch it off with --no-merge-lines.

Compiled binary is here:
http://files.mkgmap.org.uk/download/119/mkgmap.jar

Gerd


> Date: Thu, 2 May 2013 20:01:32 +0200
> From: wmgcnfg@web.de
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] merge-lines and routing
>
> > I'd like to move all calls to methods of RoadNetwork after the filter chain,
> > but that is not that simple. I think we have to move also all the code reg.
> > restrictions, maybe also the housenumber part.
>
> Hi Gerd,
>
> please don't mind about the housenumber part. I think it might be more
> easy to redevelop it after your changes instead of keeping the current code.
>
> WanMil
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev