On 25.04.2014 12:26, Gerd Petermann wrote:
Hi Felix,

okay, I think that this explains your problems. The current code in mkgmap simply doesn't
expect lines based on the same OSM way to go in different directions.
I am pretty sure that you get unpredictable results when doing that.

In most places I don't see a problem to support that, but I fear that the
code for restriction relations will be a problem.
Thinking about it...
Well I'm still using --no-turn-restrictions anyhow....

However I would see a second possibility. Create another file in the style-file called direction-dependent-lines
where one lists all types
(0x?????
0x??
0x????
....
)
that mkmgap may not reverse because the outcome is dependent on the direction of the way due to the layout chosen in the typfile.

Or add all tags - but that would be less reliable.


Anyhow - the turn-restrictions are still a mystery to me - both in mkgmap as well as in OSM. I'm pretty sure 50% of the turn restrictions in OSM will not be followed by cyclists (either they actually don't have to, or there are quicker possibilities (e.g. using the footway crossing) or simply knowing that noone cares what cyclists do in that case... Especially I would say no cyclists respects right turn restriction in drive-right countries (and some vice-versa for drive-left).
Therefore for now I still prefer to completly disrespect them in the map.



Gerd

------------------------------------------------------------------------
Date: Fri, 25 Apr 2014 09:30:54 +0800
From: [email protected]
To: [email protected]
Subject: Re: [mkgmap-dev] oneway reverse patch

Oh forgot to mention. I also sometimes set oneway yes. Then continue and oneway -1 then contune. All non routable. I don't use continue with actions so I depend on strict work down of lines file as routable non oneway road copies follow

On Apr 25, 2014 9:25 AM, "Felix Hartmann" <[email protected] <mailto:[email protected]>> wrote:

    Oh and I of course also add multiple routable lines sometimes. Up
    to 6 per way in osm as 7 produces crashes on garmins side. Often
    one routable line has direction but no oneway while the copy is
    higher importance for routing and oneway (and might be reversed).
    I need to reverse sometimes to save on the number of lines in type
    file too - other times its about routing!

    On Apr 25, 2014 9:19 AM, "Felix Hartmann" <[email protected]
    <mailto:[email protected]>> wrote:

        Yes I both add opposite oneway on the same road as well as
        only one oneway or no oneway. It is highly important that the
        order is followed strictly and continue vs continue with
        actions is strictly enacted in order. All reversing should
        happen at the time its placed in the style. !!

        Sometimes I reverse a way 3 times during processing. All I can
        say right now its a bit of a mess

        On Apr 25, 2014 2:24 AM, "Gerd Petermann"
        <[email protected]
        <mailto:[email protected]>> wrote:

            Hi Felix,

            if your style interprets a tag like a oneway=yes you
            should add
            that tag. This might prevent problems caused by the
            RoadMerger,
            which might reverse lines which are not oneways.
            If you find or set oneway=-1, the current implementation
            will reverse the way.
            If you add multiple routable lines for one OSM
            way, one with, one without the oneway tag,
            you will see unpredictable directions if such a way
            is modified by the WrongAngleFixer and the type
            is direction dependent.
            The WrongAngleFixer assumes that the points in
            all ways with the same OSM id are equal, so
            it optimizes one way and copies the points to the others.
            This will fail if they have different oneway attributes.
            If you think this could be the cause of the problem,
            I should be able to provide a fix.

            Gerd

            
------------------------------------------------------------------------
            Date: Fri, 25 Apr 2014 01:00:18 +0800
            From: [email protected] <mailto:[email protected]>
            To: [email protected]
            <mailto:[email protected]>
            Subject: Re: [mkgmap-dev] oneway reverse patch

            Ups - but forgot to say. I think in 99% of all cases -
            cycleway:left and cycleway:right are used on streets which
            feature oneway=yes... less often oneway=-1 and even less
            often no oneway at all.
            Streets with oneway=yes are fine. I'm talking about no
            oneway tag from OSM data at all, or oneway=-1 set in style
            (but no oneway from OSM data) or no oneway at all. Only on
            those there are problems - so you're not likely to notice
            them I think....


            On 25 April 2014 00:39, Minko <[email protected]
            <mailto:[email protected]>> wrote:

                Yes I render cycleway:left and cycleway:right too.
                And as you say, they are always on the wrong side on
                the GPS.
                Interesting to know that Garmin uses asymmetric lines
                independent of the road direction. If we only could
                find out how they do this...

                Felix wrote
                > I don't think that Minkos style shows cycleways on
                the left/right side
                > of a road - am I wrong? - Anyhow they would usually
                have a oneway tag
                > already in OSM data.
                > Also definitely no uphill/downhill arrows - which
                nearly never
                > actually have a oneway tag (and only sometimes I add
                one during
                > processing).
                _______________________________________________
                mkgmap-dev mailing list
                [email protected]
                <mailto:[email protected]>
                http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



            _______________________________________________ mkgmap-dev
            mailing list [email protected]
            <mailto:[email protected]>
            http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

            _______________________________________________
            mkgmap-dev mailing list
            [email protected]
            <mailto:[email protected]>
            http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Reply via email to