Hi Gerd
Wouldn't it be more efficient to choose a point within a each polygon
and then use IsInUtils.isPointInShape and the relative areas to test if
this polygon is in others. The point could be the centre of the
polygon, after checking isPointInShape == IN on itself, and, if not,
make do with
lations like insideness or outsideness: Allows to
> remove a lot of complex code but might be slower in some cases.
>
> Hi Ticker,
>
> yes, that's what I plan to do. Right now I try to understand what is
> done with the data in collection intersectingPolygons.
>
> Gerd
>
I meant intersecting polygons
Ticker
On Thu, 2021-04-01 at 12:08 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I agree that calcContains should be changed as you suggest.
>
> My view otherwise is that the code should be as simple as possible
> for
> "correct"
Hi Gerd
2 more thoughts:
For elements from Polish input, set a distinct role. This can be
spotted early and either the order rule or direction rule can be
applied (they are closed, so the area/direction can be calculated
immediately). This then allowed OSM data with a blank role to be
handled as
Hi Gerd
I think the extra testing should be removed and the logic should work
on the assumption of correct data; just emitting warning/errors when
problems are found during the normal processing.
It also has extra complexity due to early versions of the splitter not
keeping relations/polygons
imply ignore incomplete MP after logging a warning.
>
> Gerd
>
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 13. März 2021 12:21
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] tile takes very long time to generate
>
> Hi Ge
Hi
I think this is more an interpretation of what a Bay means and it being
an inner of a relation isn't relevant. Islands shouldn't be cut-out of
Bays with a MP relation. It is expected that they are rendered as
transparent rather than blue and mapnik.txt does this.
There was a thread about this
Hi Gerd
Some possible test cases:
Looking at the problems my code is detecting, the complicated cases are
when possible polygons share 2 or more end-points with other possibles;
for instance:
http://www.openstreetmap.org/relation/5329106
adjacent buildings, touching each other, are mapped as a
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Mike Baggaley
> Gesendet: Mittwoch, 17. März 2021 15:18
> An: 'Ticker Berkin'; 'mkgmap development'
> Betreff: Re: [mkgmap-dev] Removal of floodblocker generate-sea option
>
>
Hi all
I think it is time that that the floodblocker logic is removed.
I doubt if anyone uses it.
The recommended way to have sea is to use --precomp-sea and
floodblocker is irrelevant to this.
Using the coastline data from the normal OSM input, the common sea
problems are in tiles that extend
=sea or place=island MPs or maybe add a tag to tell mkgmap
> that only a POI is needed. No idea how much work that would be or
> what side effects it would have.
>
> I've not yet checked why the mentioned MP takes s long, maybe
> it's because the MP contains some errors.
>
&
Hi
I'm not sure of all the rules regarding relations and resultant
polygons and some of the MultiPolygonRelation.java code defeat me but
some thoughts:
Even though the relation might not have any relevant tags, it is what
causes all the significant inner and/or outer polygons to be create by
Hi Gerd
You might consider the some of the ideas here as improvements to the
initial parts of MP processing.
This is a patch based on trunk rather than the new branch. It isn't
structured as for final usage, rather for minimising the spread of
changes, working in parallel with the existing code
Hi Vuki
>From the code, it looks like the command line option
--[overview-]levels=...
is used in preference to the style/options file
[overview-]levels=...
line
This could be make cleared in the style manual section 3.4 and the
command line options description.
Ticker
On Mon, 2021-03-01 at
Hi Mike
Does this work? There is no information about the tagging when the
elements are read back from the ovm_ file.
In MapBuilder I think you have to test for isOverviewComponent rather
than isOverviewCombined and I don't think changes to
OverviewMapDataSource make any difference to anything.
Hi
I can't remember all the details of this message, but what has happened
is a tile needs 3-byte references to a city index and this will force
the full MDR for all tiles to use 3-byte city references, so growing
the index structure a lot. So, probably not relevant for overview.
Ticker
On Sun,
Hi
The default style has 5 levels of overview map! This seems excessive.
I'd have thought 2 or 3 would be acceptable and save a lot of space
The only contents is larger and larger cities, fast trunk roads and
motorways, some boundaries, sea and, at 3 of the 5 levels, coastline.
I don't think
; calculated but I still think that your version is even more
> confusing.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 8. April 2021 17:34
> An: Development list for mkgmap
> Betreff: Re:
gt; Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 8. April 2021 18:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Polyline base optimisation
>
> Hi Gerd
>
> It needs to know if there are deltas < 0, deltas > 0, and number o
Hi Gerd
If starting with unsigned deltas in polyline encoding, and attempting
to reduce the length by testing reduced x/yBase values, there isn't any
point in testing Base-1, as the normal number of bits will be the same
(added sign bit) and there will be some overflows.
Patch attached to change
Hi Gerd
Problem is that IdentityHashMap is the ideal solution, but ordering
behaviour depends on internal java object handles. A solution to this
stability issue would be to rotate joinedWays.originalWays so, say, the
one with the lowest ID is first, doing this just before the full point
-list is
will never find a better
> encoding?
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 8. April 2021 13:58
> An: mkgmap development
> Betreff: [mkgmap-dev] Polyline base optimisation
>
&g
s assumes that you don't use a
> generic typ code for several different objects. Or am I missing
> something?
>
> Regards,
> Mike
>
> -----Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 15 February 2021 09:16
> To: Development list
Hi Mike & Gerd
No problems with this.
Concerning *-sea-sectors. My reading of the documentation implies
extend-sea-sectors and no-sea-sectors are alternatives. The
comprehension difficulty is because of the naming of 'extend-sea
-sectors', which are very different from the 'sea-sectors' that
to
> trunk or
> 2) Ticker and Joris create their own branch(es), either in the mkgmap
> svn repo or somewhere else.
>
> ciao,
> Gerd
>
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 12.
t; other than e.g. 2a-2f, which only appear at kind of 24+, no matter
> what resolution is given.
> Even if both ranges are styled to resolution 24: 2a-2f will always
> appear a bit later.
> I suspect that´s what Gerd found to be confusing.
>
> Jan
>
>
> > Am 1
Hi Jan
I'm slightly confused as to what you are trying to do here when you say
it works for nodes but not polygons.
After you've output a POI from the first rule what are you trying to
do?
Ticker
On Sun, 2021-02-21 at 10:42 +0100, jan meisters wrote:
> Hi Gerd,
>
> my first impression didn´t
im inside except for the areas:
> wrong.
>
> What I expect is this: 2-expected.jpg
> Left as before, but In the right pois for all swim inside including
> areas.
>
> Hope I made it clearer
> Jan
>
>
> > Am 21.02.2021 um 13:01 schrieb Ticker Berkin <
> >
I dropped the corresponding naming
> actions for simplification, and the mopup at the end also ;-)
>
> Jan
>
>
> > Am 21.02.2021 um 22:32 schrieb Ticker Berkin <
> > rwb-mkg...@jagit.co.uk>:
> >
> > Hi Jan
> >
> > I don't think you'll b
uot;
> or "lift_gate" popping up in the map on my Oregon. I think they might
> be useful for mappers but they are not very useful for the normal
> user. Maybe it is only on my device but I don't see any need for
> this.
>
> Gerd
>
> ___
.
Ticker
On Thu, 2021-02-11 at 18:05 +0100, Carlos Dávila wrote:
> Regarding your extra comment on #3, would it be really the case for
> bridges? What about any connected highway=* + bridge=yes?
>
> No objection for new additional changes
>
> El 11/2/21 a las 15:57, Ticker Berki
Hi
My understanding of Felix's problem and a possible enhancement to solve
it:
Splitting a country... into a number of .osm.pfb files. Almost all of
these are processable by mkgmap to produce tiles, but one or two exceed
some .img limits.
Rather that resplitting the whole country with a lower
I find that only POI 0x2f01, 0x2f16 and 0x2e06 are searchable as fuel
services.
0x44xx and 0x23xx (I use 0x230f) show a petrol pump icon and the 0x23
show at a lower resolution than many other POI
Ticker
___
mkgmap-dev mailing list
> the difference between a fixed *.typ file and one that is freshly
> > compiled from *.txt?
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Sonntag, 19. September 2021 13:25
> > An: Development list
Hi
If you don't use --output_dir but have map sources (.osm.pbf) and
results (.img) all in the same place, and you specify a pre-built
TYPfile with extension .typ, but it has the wrong family/product,
mkgmap can adjust these, but is then stuck as to what to do with the
fixed version, hence the
t; > Hi Ticker,
> >
> > OK, I agree that it isn't the best idea to modify a source file.
> > So, maybe mkgmap should stop with an error message if that would
> > happen?
> >
> > Gerd
> >
> > ____
> > Von:
Hi Karl
The type I use for Bridge is 0x10107. This is a marine extended line
type and my eTrex HCx describes it as "Bridge" if I don't supply a TYP.
For the TYP I have:
[_line]
Type=0x10107
String=Bridge
; lines either side of transparent
UseOrientation=N
Xpm="32 7 2 1"
"- c #00"
"
Hi Aleksandar & Dimitar
The files that control the transliteration are in mkgmap.jar:
chars/latin1/row*.trans and chars/ascii/row*.trans
and these are gathered from {mkgmap}/resources/chars/... in the build
process.
If you are using latin1/code-page=1252, it looks up the unicode
character in
generally case-insensitive"?
>
> This doesn't seem to be related to unicode maps only, so I wonder what
> side effects this has.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Mittwoch, 20. Oktober
Hi
It is most likely that this problem is because Chinese requires 2 UTF16
chars to encode many of its characters - see
https://softwareengineering.stackexchange.com/questions/102205/should-utf-16-be-considered-harmful
I think it is only --index processing where this is a problem mkgmap.
I'll
Hi Gerd
Here it is
Ticker
On Tue, 2021-10-19 at 09:22 +, Gerd Petermann wrote:
> Hi Ticker,
>
> yes, please remove all unrelated optimizations.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesend
Hi Gerd
I didn't understand this either - Mdr29 with lowest refs to Mdr17,
Mdr22, Mdr24, Mdr25 and Mdr26 is beyond me so I thought it best leave
that part untouched.
Ticker
On Wed, 2021-10-20 at 07:59 +, Gerd Petermann wrote:
> Hi Ticker,
>
> please double check Mdr25:
> I just wonder why
Hi
In the changes I've just made, I hope I've been consistent and fixed
all instances to use collator.compare() where scanning the results of a
sort on the same table for a change. Also consistently setting strength
to SECONDARY (generally case-insensitive).
There may be places where an indirect
h
> patch mdrSort.patch in May, subject "MDR building out-of-memory".
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 18. Oktober 2021 16:36
> An: Development list for mkgmap
> Betreff
and verify that
the size of mdr5 is >= mdr25 so this type problem is detected before it
is exposed when mdr25 indexes can't be represented in the same number
of bytes as mdr5 indexes.
Ticker
On Sun, 2021-10-17 at 11:16 +0100, Ticker Berkin wrote:
> Hi
>
> It is most likely that
ther names like those for highways, POI etc?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 18. Oktober 2021 09:58
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] java.lang.As
Hi Gerd
In imgfmt/app/srt/Sort.java around line 853:
// Get the first non-ignorable at this level
int c = chars[pos++ & 0xff];
if (!hasPage(c >>> 8)) {
I'm at a loss to understand the 0xff mask! am I missing something?
Ticker
Hi Gerd
Here is first version of the changes to improve MDR unicode and stop
the crash.
It always provides a PRIMARY strength sort value, both in the key for
sorting and direct comparison when using the collator. Previously
neither of these would have anything for a unicode character not
Hi
I can also reproduce this. I'll investigate, but am no expert on java
sort/collation.
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Brad
This is typical behaviour with Garmin devices. The POIs shown at a
given zoom level depends on the POI, Device and, possibly, some "Map"
options like "Detail", "Text Size" and "Zoom Ranges" > "Zoom Levels" >
"Map Points" - Your device will probably have a different set of
options.
Ticker
:
> using copy from JOSM/paste into BaseCamp, I could test address
> searches
> and they seem to work.
>
> El 23/10/21 a las 23:50, Ticker Berkin escribió:
> > Hi Carlos
> >
> > mkgmap doesn't have a resources/sort for code-page 936 (Microsoft's
> > charac
Hi Arndt
What code-page are you using?
Does this happen with the default style?
Where do you mean by nrw & countrys around?
I'll try and reproduce
Ticker
On Sun, 2021-10-24 at 17:59 +0200, Arndt Röhrig wrote:
> Hi @all,
>
> mkgmap r4809 crashes with an error message. the error happens at
vila wrote:
> The reason for using code-pages other than 65001 is that many Garmin
> here:
> https://openmtbmap.org/download/odbl/#Compatibility_-_Unicode_vs_Non_Unicode_cannot_authenticate_maps
>
> El 24/10/21 a las 18:14, Ticker Berkin escribió:
> > Hi Carlos
> >
Hi Gerd
Mdr25 is effectively sorting by country, city, region. However it only
detects changes in city or region. This would only be a problem if
there were adjacent equal city but in different countries - this
is very unlikely. An additional test for this would clarify; maybe
starting off as a
e changes in mdrUnicode_v2.patch
>
> Setting strength to SECONDARY (instead of the default TERTIARY) means
> that e.g. a and ä (German umlaut) are treated the same, right? Why do
> you describe it "generally case-insensitive"?
>
> This doesn't seem to be related to uni
Hi Gerd
Something here upsets a bunch of tests.
Ticker
On Tue, 2021-11-30 at 15:34 +, svn commit wrote:
> Version mkgmap-r4822 was committed by gerd on Tue, 30 Nov 2021
>
> - use StandardCharsets.US_ASCII instead of "ascii" parameter where
> possible
> - stop with error when --code-page
be the combination never works well. Needs more testing.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 30. November 2021 12:15
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] F
does make sense to show on the
> map, but
> given your explenation i will keep it in my style only.
>
>
> Regards
> Karl
>
>
> On fredag 3 december 2021 11:30:44 CET Ticker Berkin wrote:
> > Hi
> >
> > When the emergency phone issue cropped
Hi Gerd
It looks like the order of the letter patterns approaches canonical
Huffman (but not quite as far as I can see). With this, only the number
of codes of each length is required to form the tree.
The "struct for {level}" looks like 2 numbers. Both increasing as
levels go from 20 to 6. The
1-12-20 at 09:18 +, Gerd Petermann wrote:
> Hi Ticker,
> please explain. What counters do you see? What do they mean?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Montag, 20. Dezember 2021 09:49
&g
at the 1-bits might represent
> the position of leafs, but
> the bit counts don't match.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Sonntag, 19. Dezember 2021 10:12
> An: Development list for mkg
Hi Gerd
I'm amazed at how they've made something that could be simple and
expressed with a few byte of control, around 140 bits for tree
structure and 80 or so bytes of characters so big and complex!
Maybe the few (5) layers closest to the root somehow hard coded.
Where a node has a sub-tree on
Looks like uft16 surrogate pair chars are being separated by the
substr.
Ticker
On Mon, 2021-12-27 at 19:28 +0100, Arndt Röhrig wrote:
> ...mayby is in the osm data a kryptic text like this:
>
> https://www.openstreetmap.org/node/9115233473
>
and that will fail.
> I guess that Garmin produces an empty level in that case...
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 31. Dezember 2021 10:57
> An: mkgmap development
> Bet
Hi Gerd
Some thoughts on this:
Dividing the \0 count by some factor between 3 and 6 should reduce the
overall length of the strings. This is because there will be 0..7 bits
free after each string
To make the canonical tree: after using the standard algo to make a
normal tree, just remember the
Hi all style users
I've noticed that the code and style manual differ in the meaning of
the highway-symbol max-length parameters.
The manual says the text is truncated to this length.
In the code: if the text is longer than the length it is left
untouched. No shield is added, spaces are not
be used to
> find the correct entry
> in the byte array with the characters.
>
> So, maybe the stat value should be shifted to the right to make some
> sense.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
Hi Gerd
I'm working through your codebook discoveries but finding the patches
hard to undo/redo with other changes happening to display. I'd much
prefer you just committing all display changes as you go and I'll
update. I doubt if this will inconvenience anyone else at the moment.
Thanks
Ticker
_________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 27. Dezember 2021 20:06
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] r4836 stops Hungary & Romania
>
> Looks like uft16 surrogate pair chars are being separated by t
Hi Gerd
Sorry about that - had been copy strange chars but it wasn't
from here! The Oracle java documentation has this character between:
int offsetByCodePoints
and
(int index, int codePointOffset)
Ticker
On Thu, 2021-12-30 at 15:26 +, Gerd Petermann wrote:
> Hi Ticker,
>
> please
Hi Gerd
In the resource/sort/cp*.txt sort definitions, I notices that all but
cp1252.txt/Western European and cp65001.txt/unicode don't handle "#"
correctly and cp1252.txt/Western European and cp1254.txt/Turkish don't
add expansions for all their double-characters.
Patch attached that fixes
Hi Karl
1. include inc/name processing happens at the point of inclusion
2. I don't think variable expansion works within the context of filter
parameters - your difficulties suggest it really doesn't.
3. {set name= ... probably works correctly, but it is the
{name ...} statement that sets
Hi Karl
I suspect this won't work directly, the ":" you want to look for is
being taken as the operator. Maybe you can subst it first
name='{name|subst:":=>#"|part:"#:-1"}'
Ticker
On Sun, 2022-01-02 at 19:58 +0100, 7770 wrote:
> Hi.
>
> On page 16 and 17 in the styles manual the part
ow it works. if name is set to anything, what will {name
> '$
> {name}'} actually do?
>
> add and set are described in the style manual, but not the case
> without add or
> set (or i don't understand where to look for it).
>
>
> Regards
> Karl
>
>
> On s
Hi Gerd
On my eTrex 30x:
Same --lower-case map as before. Also loaded is GB map that is disabled
in Setup>Map; it uses same charset & sort, sort has same id1 but
different id2.
Where To? > Cities > Spell Search > "VOS" gives "No Results Found"
Spell Search has option to change the keyboard
Hi Gerd
That's great.
I don't have any maps with compression/Mdr16 or Mdr30-3.
http://gis.19327.n8.nabble.com no longer seems to work for me.
I found possible links to maps at:
http://www.garniak.pl/viewtopic.php?f=9=398
but interesting links were dead or went to generic page.
I suspect the
his patch.
>
> So, besides the fields with ??? the only open question is the meaning
> of the struct bytes in the first table.
> I guess it will become clear when I try to use the lookup table in
> the decoder.
>
> Gerd
>
>
> ________
>
Hi Gerd
I guessed that it was the \0 that cut the file off.
You mean something like answer 5 here:
https://stackoverflow.com/questions/759707/efficient-way-of-storing-huffman-tree
I looked at this earlier trying to work out if it was relevant but
didn't make it fit - I should have tried
Hi Arndt
As a matter of interest, does any text show for
https://www.openstreetmap.org/node/9122388694
or
https://www.openstreetmap.org/node/9115233473
The text is mostly 'Old Hungarian' and I wonder if the java encoder
tries any transliteration. What code-page are you using?
Ticker
On Tue,
Hi Gerd
I'll look at this sometime. I while ago I found something in one of the
MDR sections (probably the short strings) that handled something like
this.
Ticker
On Tue, 2021-12-28 at 13:22 +, Gerd Petermann wrote:
> Hi Ticker,
>
> okay, maybe you find time to implement a better
Hi Nick
Thanks.
Interesting, but not maybe not relevant to the Huffman stuff, in
mdr16austria.txt the MDR headers go out of sync after MDR30
Ticker
On Tue, 2021-12-28 at 18:28 +, nick wrote:
> Hi Gerd
>
> OK thanks will check that tomorrow.
>
> I think it's amazing how far both of you
others will cause problems. There might just be a few str.length() and
str.charAt() or other indexing that might need attention but this would
require a lot more searching. I've left the handling for
MALFORMED_INPUT so these shouldn't matter.
Ticker
On Wed, 2021-12-29 at 09:16 +, Ticker Berkin
9:17 +0000, Ticker Berkin wrote:
> 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 ta
Hi Gerd
Sorry - I hadn't noticed these changes. They don't show up with
$ svn log resources/sort/cp1252.txt or cp1254.txt
All the other mkgmap sort files have all the expansions possible
including the eszett and diphthongs if applicable.
The two non-mkgmap sort files (848.SRT/Turkey and
Petermann wrote:
> Hi Ticker,
>
> here it is.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 4. Januar 2022 11:20
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Error
4 | 04 | 01 00 | id2 1
> 0046 | 06 | e4 04 | codepage 1252
>
> Maybe I should repeat those tests with the mdr2 branch?
>
> Gerd
>
>
>
>
>
> Von: mkgmap-dev im Auftrag
Hi Gerd
Can you send me the Mdr16 display of some of the other maps you've been
looking at. I'd like to try and find some meaning for bytes 0..2 and
the prefix before the level 5 data.
Thanks
Ticker
On Wed, 2021-12-22 at 08:43 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I also thought that
Hi Gerd
Some of the old maps don't have Mdr sections after 19 and 29. Also some
code didn't spot it should test after Mdr19, so Summary, Display and
Check could give errors. I've added logic to stop getting sections
after all the header lengths I've found in the various samples.
Patch attached.
iles.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Montag, 15. November 2021 19:24
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] change mdr25 logic
>
> Hi Gerd
>
> How do you make it
Hi
I'd vote for normalisation when the label is generated.
If the un-normalised string can be represented in the target charset,
no need for normalisation.
I don't see that styles should be testing names like this, and, if they
really need to, clauses for alternate representations could be
Hi Gerd
How do you make it do this?
Ticker
On Fri, 2021-10-22 at 09:06 +, Gerd Petermann wrote:
> Hi Ticker,
>
> just learned (again) that MapInstall fills Mdr25 when it writes a
> gmapsupp. That should help.
>
> Gerd
___
mkgmap-dev mailing
.uk
> Betreff: Re: [mkgmap-dev] New assertion, now with code-
> page=632 and Japan tile
>
> Hi Ticker
>
> Not sure if relevant, but note in this case assertion occurs while
> compiling the tile, not the index. In fact, --index is not included
> in
> the command.
&g
Hi Gerd
How did you get a Mdr3?
I've been using MapInstall then running various display modes on the
gmapsupp and MdrSummary reports
initial values72e
MDR 1 NR=2 (02) RS=4 magic=0x0
MDR 4 NR=117 (75) RS=3 magic=0x0
MDR 5 NR=17164 (00430c) RS=8 magic=0x151
MDR 6
Hi Gerd
I'm not ignoring this, but trying to put the essence of my renames into
the default style and testing with a r4810 and --lower-case I find
MapSource isn't giving me a Find > Address option and BaseCamp doesn't
find any streets and once said "Doesn't support Address Search"
So I'll try
Hi Gerd
I can't look at this in detail at the moment but:
Lower case and indexing behaviour is affected by the tile processing
stages deduping using upper case on country/region/city when loading
MDR data (mainly from mkgmap:country/region/city). I seem to remember
that explicit city POI behave
is possible that MapInstall, having access to all the case variants
via the LBL section, might rebuild a case-sensitive index.
Was hoping to get mdrUnicode_v9p.patch out of the way before this.
Ticker
On Sat, 2021-11-20 at 17:27 +0000, Ticker Berkin wrote:
> Hi Gerd
>
> I can't look at this in
Wherwell
Chant Close Wherwell Wherwell
Bigpath LaneUpton Either as crosses tile
Church Street BothEither, finds expected one
Ticker
On Tue, 2021-11-23 at 11:03 +, Ticker Berkin wrote:
> Hi Gerd
>
> I'm not ignoring this, but trying to
Hi Karl
What code-page are you using for this. "ł" from Małopolska is unicode
U+0142 LATIN SMALL LETTER L WITH STROKE and isn't representable in
cp1252, but is in cp1250 and unicode/cp65001
Ticker
On Tue, 2021-11-23 at 08:08 +, Gerd Petermann wrote:
> Hi Karl,
>
> maybe you have different
erd
>
> ____
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Donnerstag, 18. November 2021 15:37
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4811: fix
> java.lang.AssertionError while building
Hi Gerd
For any code-page except Japanese/cp932, AnyCharSetEncoder takes
anything that can't be represented, tries to find a reasonable ascii
representation or "?", then writes this to the output. This is a big
assumption for far-eastern charsets, most likely generating garbage
with possible
801 - 900 of 1100 matches
Mail list logo
