[mkgmap-dev] oneway reverse patch

Fri Apr 25 02:30:54 BST 2014

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" <extremecarver at gmail.com> 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" <extremecarver at gmail.com> 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" <
>> gpetermann_muenchen at hotmail.com> 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: extremecarver at gmail.com
>>> To: mkgmap-dev at lists.mkgmap.org.uk
>>> 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 <ligfietser at online.nl> 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
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>>
>>>
>>> _______________________________________________ mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140425/8df933e3/attachment-0001.html>