[mkgmap-dev] merge-lines and routing

Sat May 4 12:29:13 BST 2013

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 at gmail.com
> To: mkgmap-dev at 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 at web.de <mailto:wmgcnfg at web.de>
>     > To: mkgmap-dev at lists.mkgmap.org.uk
>     <mailto:mkgmap-dev at 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 at lists.mkgmap.org.uk
>     <mailto:mkgmap-dev at lists.mkgmap.org.uk>
>     > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>     _______________________________________________
>     mkgmap-dev mailing list
>     mkgmap-dev at lists.mkgmap.org.uk  <mailto:mkgmap-dev at lists.mkgmap.org.uk>
>     http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
> _______________________________________________ mkgmap-dev mailing 
> list mkgmap-dev at lists.mkgmap.org.uk 
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130504/a7ec4945/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oneway_arrows_shifted.png
Type: image/png
Size: 23165 bytes
Desc: not available
Url : http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130504/a7ec4945/attachment-0001.png 