Hi Gerd
I got confused between Mdr15 (full string for gmapi) and Mdr17 (partial
string for device), so what I wrote here makes little sense.
I need to think about it more. Sorry for wasting your time.
Ticker
On Thu, 2022-01-20 at 20:42 +, Ticker Berkin wrote:
> Hi Gerd
>
> It could be
Hi Gerd
It could be trying to represent something as follows:
For a device, there is no MDR17 string, so no possibility of using this
to have index entries for parts of the street name.
A street LBL can have any number of prefix / suffix chars.
Multiple mdr7 repeat records can be generated for
Hi Ticker,
I also wondered why these lines still exist:
int bitsPrefix = (maxPrefixCount == 0) ? 0 :
Integer.numberOfTrailingZeros(Integer.highestOneBit(maxPrefixCount)) + 1;
int bitsSuffix = (maxSuffixCount == 0) ? 0 :
Hi Gerd
I'm struggling to understand the possibilities of Mdr7 (ordering,
partialInfo, nameOffset, string different to label, etc etc)
My initial thought about nameOffset was that it was for skipping over
the shield prefix or text before the 0x1b marker.
partialInfo is very strange; it seems
Hi Ticker,
It seems that we must write an Mdr7Record with outNameOffset==0 if we also want
to write other entries with outNameOffset>0.
If that is the case MdrCheck should verify that.
Another problem with the mdr7-del4.patch:
The code for --split-name-index logic doesn't only split at ' '
Hi Ticker,
sorry, it seems I still haven't understood how the index structure works.
With the patch mdr7-del4.patch mkgmap creates an index which makes MdrCheck
happy,
but MapSource typically says "no item found"
when I pick one of the entries that start with a word which appears in the
Hi Ticker,
thought again about the remark reg. MDR7_HAS_STRING.
With the mdr7-del4.patch we can add strings to Mdr15 section which may never
used because no index entry will show the corresponding label.
So, mdr7-del4.patch is too simple as it wastes space in the PC index.
Also I have big
Thanks Gerd, it is what it is. Then I'll stick with brouter or rwgps to make
more accurate elevation profiles.
Van: mkgmap-dev namens Gerd Petermann
Verzonden: donderdag 20 januari 2022 00:44
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev]
Hi Minko,
there is no special flag for tunnel/bridge in the IMG format, at least we don't
know any. So, Garmin software cannot detect the special case.
Gerd
Von: mkgmap-dev im Auftrag von lig
fietser
Gesendet: Donnerstag, 20. Januar 2022 09:41
An:
Thanks Gerd,
It's a pity that this cannot be corrected. I thought the route could look where
a tunnel/bridge section is (based on OSM tags) and just ignore all elevation
data and starts reading it where there is no tunnel or bridge tag?
Van: mkgmap-dev namens
Hi all,
I also don't like the wrong profile for bridges and tunnels, but there is
nothing we can do about this so far.
The other routers know that the have to treat bridges and tunnel special, but
Garmin software doesn't have this information.
We also cannot manipulate the elevation data
Hi Craig,
ok, fine. Thanks for the feedback.
Gerd
Von: mkgmap-dev im Auftrag von Craig
Durkin
Gesendet: Donnerstag, 20. Januar 2022 05:34
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] How to display administrative boundaries / shade
I've put an example on this forum (in Dutch). The brouter route
(https://tinyurl.com/3nt27szy) shows a profile that is more accurate than the
route in Basecamp.
https://forum.wereldfietser.nl/viewtopic.php?f=3=30684=412494#p412494
Van: mkgmap-dev namens lig
13 matches
Mail list logo
