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