[mkgmap-dev] Problem in AngleFixer?
From Thorsten Kukuk kukuk at thkukuk.de on Thu Aug 15 15:17:34 BST 2024
Am 2024-08-15 15:49, schrieb Ticker Berkin: > Hi Thorsten > > Apart from moving and adding diagnostics, the only significant change I > made was > to remove a test for the arcs on either side of a sharp angle being the > same > road, and, if so, not widen the angle. This didn't occur in your > example. The > other changes were cosmetic. > > With this latest version/build, have all your wrong turn-instructions > gone? I don't have currently the time to test all examples, but the few I tested seems to be Ok now. Instead of wrong "turn right" for straight forward I have now no message for it or "turn left" for the left way. In some cases I get "keep right" and "keep left" (assumes "Y" junction), which is Ok in that cases. > Do you use option --preserve-element-order? Elsewhere in the code quite > a lot of > effort has been taken to avoid java constructs with unpredictable > ordering. No, I'm not using "--preserve-element-order". Regards, Thorsten > > Regards > Ticker > > On Thu, 2024-08-15 at 14:24 +0200, Thorsten Kukuk wrote: >> Hi Ticker, >> >> Am 2024-08-14 17:48, schrieb Ticker Berkin: >> > Hi Thorsten >> > >> > I can't explain the turn instructions being in the wrong direction for >> > some >> > ranges of angles. What are you seeing this on - Basecamp / MapSource / >> > Garmin >> > Device? >> >> I see this on BaseCamp, Garmin GPSMap 66sr, Garmin Edge 1030+ and >> 1050. >> >> I have only tested a few junctions with the Garmin devices, the ones >> in >> the near, >> but the result was always identical. >> >> > Can you send me the same sections of the log file, the first should >> > look like >> > this: >> >> fixSharpAngles_v4 at 49.478507,10.942814 mask 2 smallestAngle >> 15.375715 >> nArcs 3 nDirectArcs 3 nGroups 3 >> Arc heading -32.3756 328° angToPrev 166.0431 class 2 speed 2 way >> 144732811 isFake false rdDef -2042305213 name null paved true >> Arc heading -16.999884 343° angToPrev 15.375715 class 1 speed 2 way >> 36138336 isFake false rdDef -485064406 name null paved false >> Arc heading 161.5813 162° angToPrev 178.58118 class 1 speed 2 way >> 36138336 isFake false rdDef -485064406 name null paved false >> Angle 15.375715 between -32.3756 and -16.999884 minAngle 46.0 >> wantedInc >> 30.624285 deltaPred 120.043106 deltaNext 132.58118 >> decreasing arc with heading 328° by 30.624285 >> modInitialHeading arc from -32.3756 by -30.624285 to -62.999886 >> join angle 8.872055 ° at 49.483048,10.932943 increased by 37.127945 >> >> > If, in this example, way 36138338 has been split, I need to see if >> > there is any >> > way of finding the associated bits of road >> >> But with this build, the "wrong" turn instructions are gone! >> This time the 328° heading was used, not the 343°. If you haven't done >> any other changes to your patch except debugging code (I haven't >> looked >> at the patch yet), then I'm afraid we have somewhere an unstable sort >> or >> use a hash table, which will not give reproducable results. >> >> Regards, >> Thorsten >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev at lists.mkgmap.org.uk >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev at lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
- Previous message: [mkgmap-dev] Problem in AngleFixer?
- Next message: [mkgmap-dev] Problem in AngleFixer?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list