slowly I seem to get closer to a solution for the crash problem.
I've re-activated the dem-tdb branch to test some changes.
With r4111 I've implemented a special option to force the problem case,
so that the crash doesn't depend on the content of the hgt file or the dem-poly,
When the extra flag is set, the crash is related to the position of the tile
the height and width - and therefore the overlaps - of the DEM area(s),
the dem-dists values, the length of the route,
the place where the route starts and ends, maybe more. I assume that MapSource
makes certain assumptions about these values when the extra flag is set AND
"something else" is true or false. This something might be a value in TRE or
for example I've calculated a map for some tiles with the same (?) boundaries
as in the Garmin map TopoGuide Hungary 2.12c.
I've calculated some routes in the Garmin map and stored them in a *.gdb file.
(no crashes with "Show profile..." button, data looks reasonable)
I've used the same routes for the map calculated by mkgmap, I see crashes for
I replaced the *.DEM data in the Garmin map by that from mkgmap and I see no
(I made sure that I see the data calculated by mkgmap)
It is difficult to create tiles with exactly the same boundary values in TRE
and DEM and *.tdb,
so maybe I still have to improve the code regarding rounding errors or
calculation of the position.
That's what I've done so far and I am still making progress...
Another explanation is my conspiracy theory:
It might be that MapSource is much more restrictive when the tdb file says
that the map is not from Garmin, e.g. it is not lockable or whatever MapSource
to detect that. Let's hope that this is not the case.
BTW: Reg. "Show Profile.." /Graph I've learned that both MapSource and Basecamp
use different DEM levels depending on the overall length of the route.
the DEM level 0 (5520) is used for routes < ~ 29 km, 16560 is used for 29..86
km, y >= 87
the DEM level 0 (3312) is used for routes < ~ 17,4 km
The ratios show a constant value : 17,4 / 3312 ~ 29/5520 ~ 87 / 16560 ~ 190
The odd numbers are probably caused by different units (feet / metres).
mkgmap-dev mailing list