Hi Gerd
Both flags are correct - actually I should have realised this earlier
as having some content makes no difference to the reading of the
sequence of Mdr headers - sorry for wasting your time.
Ticker
On Mon, 2021-12-13 at 14:56 +, Gerd Petermann wrote:
> Hi Ticker,
>
> maybe you need
Hi Ticker,
maybe you need this?
--Analyse sections that are known--
MDR 17 len=0 next=
implied size=0 (0x0)
MDR 18 len=0 next=
implied size=0 (0x0)
MDR 19 len=0 next=
implied
Hi Gerd
It has the record size (even though pointless). Probably has
magic/header flags but can't tell absolutely because the next mdr could
start with an offset of 00 00 00 00 if empty.
Ticker
On Mon, 2021-12-13 at 13:51 +, Gerd Petermann wrote:
> Hi Ticker,
>
> not sure what you mean.
Hi Ticker,
not sure what you mean. Here is the output from MdrDisplay:
00df | 3f 23 51 00 | MDR 15 at offset 0x51233f
00e3 | d5 b3 0f 00 | MDR 15 length 1029077
| | End of section 0060d714, len 0x0fb3d5
00e7 | 01
I create a separate line for national and regional walking and cycling
routes, thus the name of the route doesn't need to go in the road name. I do
have quite complex rules to handle this as I have national routes in one
colour, cycling in another and alternating where there are both, and these
Hi Gerd
>From your example map, can you determine what settings should be used
for hasRecSize and hasMagic (MdrDisplay ~line 1351 and other modules as
well). I'd have expected (false, ?);
Ticker
On Mon, 2021-12-13 at 11:33 +, svn commit wrote:
> Version display-r572 was committed by gerd
Hi Ticker,
I am pretty sure that the original data doesn't contain lower case characters.
The characters B and b in name "Baca Pri Podbrdu" both change when the last
byte in MDR16 (0x42)
is changed.
I've looked at several suggestions how the tree could be stored, nothing seems
to match the
yes I also don't see a need for the route relation name in the search - but
I do see it as a need to see the route names on tooltip for all routes that
use a way. That's why I mean I would like to add them into non searchable
labels.
Even though for certain ways - I would like them included - e.g.
Hi Gerd
I've build and examined this. I assume that the table came from a map
that used most of the available characters, so not seeing these
precludes the theory of it being flattened shape/contents lists in any
simple representation. Can you tell if the original map was mixed case?
If it wasn't
Hi Felix,
I still don't see a use case for the route names in road labels. I've never
felt the need to find a route relation.
I am pretty sure that it can produce all kinds of confusion when you search for
an address and the result
contains lots of unrelated stuff because there is a route
okay - well I should try to find a way to put more content into the label
2-4 instead of 1 then. The cutoff is still good. Some routes have very long
names.
On Mon, 13 Dec 2021 at 12:43, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi Felix,
>
> the labels which are shown in
Hi Felix,
the labels which are shown in MapSource / Basecamp search are those which are
stored in MDR 15.
We change them already with the --mdr7-del option but that doesn't help for the
names of route relations.
mkgmap reads the full labels from the LBL file in each map tile and calculates
the
I tried a couple of places that are cut down to 170 characters - and some I
can find in Mapsource or Basecamp, Others I cannot. So 170 is definitely
too much for the search index. Is there a way to have separate label for
search vs the label on tooltip/printed out on the label? For search it
Hi Felix,
okay, I've committed the changes with r4836.
It would be good to know if these long strings cause trouble in MapSource.
I wouldn't be surprised to find that they cause buffer overflows if Garmin
doesn't expect more than N bytes, and that again can cause all kinds of trouble.
Will try to
Version mkgmap-r4836 was committed by gerd on Mon, 13 Dec 2021
Cut labels which are longer than 170 characters, but not the copyright message
or labels from ExtTypeAttributes
modified label_len170.patch
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4836
it's working fine for me too. But I haven't got around to testing if the
length should even be shorter related to search.function. Clearly anything
over 170 is not useful. Maybe it should be even shorter, but apart from the
value it works well
On Mon, 13 Dec 2021 at 10:28, Ticker Berkin wrote:
Hi Ticker,
attached is my experimental code patch for mkgmap.
It changes mkgmap to write the MDR 16 section ad MDR15 section with compression
set to 1 in the MDR header.
The Mdr15 content are the first 32 bytes of the original table.
I use it with the attached OSM file and options --index
Hi Gerd
Does Mdr16 look like some form of a flattened Huffman tree? A common
representation is a stream of bits describing the shape and a stream of
chars giving the contents.
If you send me an example + the little bit at the start of Mdr15 you've
been using I'll have a look.
Ticker
On Sun,
Hi Gerd
I don't have any problem with it
Ticker
On Mon, 2021-12-13 at 09:02 +, Gerd Petermann wrote:
> Hi all,
>
> I got no feedback on the patch label_len170.patch. Any comments?
>
> Gerd
___
mkgmap-dev mailing list
Hi Gerd
Yes, this seemed to be the result of a bit of code where someone was
starting to look at showing expansions and then stopped. The
information in this list is shown more clearly while it is being read
in the SRT 4 Character table.
Ticker
On Mon, 2021-12-13 at 09:00 +, Gerd Petermann
Hi all,
I got no feedback on the patch label_len170.patch. Any comments?
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Montag, 6. Dezember 2021 19:09
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Building display.jar fails
Hi Ticker,
the unpatched SrtDisplay shows this table at the end, the patched version
doesn't. Is that intended?
0008 prim=0,sec=0,tert=0
0009 prim=0,sec=0,tert=0
000a prim=0,sec=0,tert=0
000b prim=0,sec=0,tert=0
000c prim=0,sec=0,tert=0
000d prim=0,sec=0,tert=0
000e prim=0,sec=0,tert=0
000f
Hi Felix,
thanks for the info. I think it was the patch.
Gerd
Von: mkgmap-dev im Auftrag von Felix
Hartmann
Gesendet: Sonntag, 12. Dezember 2021 16:02
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Exception in thread "main"
23 matches
Mail list logo
