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