logo separator

[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


More information about the mkgmap-dev mailing list