[mkgmap-dev] merge-lines and routing

Sat May 4 08:02:11 BST 2013

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

          > To: 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

          > 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/53e84f30/attachment-0001.html 