[mkgmap-dev] merge-lines and routing
From GerdP gpetermann_muenchen at hotmail.com on Sat May 4 16:03:39 BST 2013
Hi Felix, ok, so the merge-lines patch is ok. Most of the filters are disabled for resolution 24, so I have no idea why this happens. It could be an effect of the short-arc-removal process which is now only done with roads, or maybe the two ways go into different sub division, but this is a short way, so this is unlikely. I'll try to reproduce it tomorrow. Gerd Felix Hartmann-2 wrote > 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@ >> To: > mkgmap-dev at .org >> 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@ > <mailto: > wmgcnfg@ > > >> > To: > mkgmap-dev at .org >> <mailto: > mkgmap-dev at .org > > >> > 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 .org >> <mailto: > mkgmap-dev at .org > > >> > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> _______________________________________________ >> mkgmap-dev mailing list >> > mkgmap-dev at .org > <mailto: > mkgmap-dev at .org > > >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> >> _______________________________________________ mkgmap-dev mailing >> list > mkgmap-dev at .org > >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> _______________________________________________ >> mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev at .org > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > oneway_arrows_shifted.png (31K) > <http://gis.19327.n5.nabble.com/attachment/5759595/0/oneway_arrows_shifted.png> -- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913p5759611.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
- Previous message: [mkgmap-dev] merge-lines and routing
- Next message: [mkgmap-dev] merge-lines and routing
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list