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 <mailto:wmgcnfg@web.de> > To: mkgmap-dev@lists.mkgmap.org.uk <mailto: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 <mailto: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 <mailto: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
