Hi Gerd
In this example, choosing the correct version of the spelling doesn't
necessarily work!
To find "Alma Lane", which is in Upton=wherWell, "wherWell" must be
selected as the city.
To find "Baybridge Lane", also in Upton=wherWell, "Wherwell" must be
given.
Getting capitalisation consisten
Hi Gerd
The default inc/address rules are not very good for UK towns and
smaller - need to start from mkgmap:admin_level10. Appropriate change
is in tstStyle.zip
Nothing significant to this has changed in bounds.zip - I'm using a
version from April 2021
Ticker
On Wed, 2021-11-24 at 15:40 +000
Hi Gerd
Here it is
Ticker
On Wed, 2021-11-24 at 14:57 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I (my tools) don't know how to use default.diff. Please can you
> either create a normal svn diff or zip the complete style?
>
> Gerd
<>
___
mkgmap-
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
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 tryi
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 and
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 NR
ree. I never noticed such a problem in MapSource. Where do
> you see this problem?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 22. November 2021 12:36
> An: Development list for mkgmap
> Betreff: Re: [mkg
W: A good reason to use --lower-case in Germany are road names like
> Hauptstraße which is displayed as Hauptstrasse without that option.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 22. N
Hi Gerd
The first stages of investigation should avoid other complexities that
might be introduced by --lower-case (and --unicode). In this
environment there should be no difference between SECONDARY and
TERTIARY so the question is reduced to .equals() vs .compare() and
other flag settings / Mdr s
NDARY.
It 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 +, Ticker Berkin wrote:
> Hi Gerd
>
> I can&#x
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 d
Hi Gerd
Please ignore the CodeFunctions.java change in this patch.
A better / hybrid TableTranslitorator is needed before
SparseTranslitorator can go.
Ticker
On Thu, 2021-11-18 at 17:47 +, Ticker Berkin wrote:
> Hi Gerd
>
> For any code-page except Japanese/cp932, AnyCharS
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 inva
ap and an
> appended ignored character.
>
> Gerd
>
>
> 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
Hi Gerd
Sort and Collator with lots of ignored characters did it for me.
The new assert in Mdr29 is there to detect problems before the getting
to the stage where Mdr25 ptr needs more bytes than Mdr5 ptr.
Ticker
On Thu, 2021-11-18 at 14:28 +, Gerd Petermann wrote:
> Hi Ticker,
>
> anyhow, m
Hi Gerd
I hadn't thought of that!
Ticker
On Thu, 2021-11-18 at 13:42 +, Gerd Petermann wrote:
> Hi Ticker,
>
> If I got that right the result of the MdrCheck depends on the
> mkgmap.jar.
> This is a bit tricky when comparing the results. I'll use the patched
> binary for now.
>
> Gerd
__
.
Ticker
On Thu, 2021-11-18 at 09:21 +, Gerd Petermann wrote:
> Hi Ticker,
>
> please share your testdata so that I'm able to reproduce the
> differences.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker
for anything in
Unicode with no/0 sortOrder.
With this patch it becomes possible for Unicode to trigger the original
problem again. Attached is mdrUnicode_v9b.patch that has the fix for
this from the previous patch.
Ticker
On Tue, 2021-11-09 at 18:13 +, Ticker Berkin wrote:
> Hi Gerd
>
better handling of unmapped chars.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 17. November 2021 17:35
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New assertion, now with code-page=632 and
>
_____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 17. November 2021 15:37
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New assertion, now with code-page=632 and
> Japan tile
>
> Hi Gerd
>
> My description didn'
Hi Gerd
My description didn't quite mean what I hoped it did - sorry. I was
thinking that there would be a single attempt at encoding the whole
string, and if that fails, start again but char-by-char.
But, assuming result.length() works and charBuffer.get() and
outBuff.put() maintain positions us
; character mappings, for example there is a housenumber that contains
> "１２３７−１" instead of "1237-1".
> https://www.fontspace.com/unicode/analyzer#e=77yR77yS77yT77yX4oiS77yR
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker
r25 logic
>
> Hi Ticker,
>
> I didn't notice that the Mdr25 is the same. In that case it is really
> no help.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 15. November 2021 20:
v im Auftrag
> von Gerd Petermann
> Gesendet: Montag, 15. November 2021 17:22
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Twülpstedt, Normalisation of unicode
> strings
>
> Hi Ticker,
>
> OK, I had the same thoughts.
>
> Gerd
>
> __
an index for those tiles.
>
> 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
>
>
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 lis
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 added
dev@lists.mkgmap.org.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
Hi Gerd
I notice that Mdr8, which is commented as having the same relationship
to Mdr7 as Mdr12 does to Mdr11, is commented out.
On my test area with 2 tiles and ~40k POI, Mdr12 has 4 records.
Ticker
On Sun, 2021-11-14 at 16:21 +, Gerd Petermann wrote:
> Hi all,
>
> I think I finally foun
Hi Gerd
I'd just finished writing the following when I see your next post about
Mdr12. I'll post it anyway.
Some thoughts:
a) I'm surprised that uppercase.patch makes a difference; it's not much
different from changing the collator strength. Unless: Is there another
POI "Scuola Dell Infanzia Fon
Hi
I think this assertion could be removed from the code.
Looking through the definition of Shift-JIS, I read it as saying the
second byte shouldn't be zero, so I don't know why this happens.
As with the Chinese code-pages, mkgmap has places where multi-byte
encodings are not handled correct
r - if testing is possible - on a device.
Gerd
________
Von: mkgmap-dev im Auftrag von Ticker Berkin
Gesendet: Samstag, 6. November 2021 18:46
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4811: fix
java.lang.AssertionError while building index from u
14:33 +, Gerd Petermann wrote:
> H Ticker,
>
> but how do you know that the code in Mdr5 is right (with or without
> the patch)?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 6. Nove
it's MdrCheck which is wrong.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 6. November 2021 12:27
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r48
Hi Gerd
Splitting britain-and-ireland-latest.osm.pbf:
I get a better run-time with the new version; 19mins 36 secs down from
27mins 10 secs.
The same number of tiles, but with a slightly different layout.
About the same highest memory used.
Ticker
On Fri, 2021-11-05 at 08:57 +, Gerd Peter
t de-duped).
> Found this also with Arndts *.img data but did not yet try to find
> out if MdrCheck is right.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 5. November 2021 11:34
> An: mkgmap-
de tiles
> Changes extracted from mdrUnicode_v8.patch by Ticker Berkin
>
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4811
> ___
> mkgmap-svn mailing list
> To unsubscribe send an mail to mkgmap-svn-le...@lists.m
Hi Gerd
Just rebuilt this with Java 11 and after a warning about use of
depreciated features, added
to build.xml (same as mkgmap and splitter). There were 3 problem file.
Ticker
On Fri, 2021-11-05 at 07:46 +, svn commit wrote:
> Version display-r559 was committed by g
toring
> and OK.
> Mdr25 could better use Mdr5Record.isSameByName() (although the method
> name is a bit confusing)
> Mdr29 should probably use strength TERTIARY for the collator instead
> of SECONDARY, or there should be a comment why a different strength
> is needed.
>
> Gerd
>
up last weeks like weird code in Mdr25 or the obsolete sort
> for mdr20.
>
> Gerd
>
>
>
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 4. November 2021 14:34
> An: Development list for
tile.
Ticker
On Thu, 2021-11-04 at 13:15 +, Gerd Petermann wrote:
> Hi Ticker,
>
> why collator.setStrength(Collator.SECONDARY); in Mdr29?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donn
he assertion with Arndts data was caused by
> your patch (r4809) and everything worked fine with r4808 / r4810.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 4. November 2021 11:55
> A
Hi Gerd
Here is a minimal patch to stop the 2 assertion crashes:
1/ unspecified sort for some blocks of Unicode chararacters.
2/ inconsistent MDR20 city positions that could result from city names
with different case or use of non-unicode multi-byte codepage
For 2/ with option --lower-case, th
s justified
> to use only one.
> We have more code which tries to ignore case, e.g. for --housenumbers
> I often use String.equalsIgnoreCase() to work around different
> spelling in road names and addr:street or place names and addr:place.
>
> Gerd
>
> _____
the
> code just tries to avoid duplicated entries in the LBL file?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 2. November 2021 19:31
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] MDR and
Hi Gerd
Actually, a major part of my problem is probably app/lbl/PlacesFile
with its toUpperCase()
Ticker
On Tue, 2021-11-02 at 16:52 +, Ticker Berkin wrote:
> Hi Gerd
>
> I've been checking the street list in the Mdr20 index to make sure
> they
> are attached to the c
Hi Gerd
I've been checking the street list in the Mdr20 index to make sure they
are attached to the correct city (as part of checking case-significance
for the unicode/mdr errors) and finding discrepancies.
I think this is because combiners/MdrBuilder, on a tile by tile basis
takes the POI city l
Hi Gerd
I agree, sort of. Use of some unicode chars exposed a problem of
inconsistent sizes of mdr5/25 due to collator vs compare. Making these
consistent exposed another problem with case-differences.
My attempt at grouping case-variants of the same name and, if in same
region/country, consideri
t; (calcMdr20SortPos() only takes a fraction of a second with nrw++
> data) but I think the code is much clearer. Maybe you already hit
> memory limits on your 32-bit JRE?
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Tic
bout the
> mix of String.equals() and collator.compare().
> I have to run a few tests to understand the meaning of the change.
>
> Any chance to create unit tests for this? I got the impression that
> the indexes work quite well in the past, at least for latin1.
>
> Gerd
>
or a different
> result. Maybe I didn't do it right?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 1. November 2021 11:29
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgm
Hi Gerd
Looking at what Mdr5::calcMdr20SortPos() is doing, can't it be
simplified away to just an extra call in genCitiesAndMdr20s():
... around line 106
if (!c.isSameByName(collator, lastCity))
mdr20count++;
patches was that they have no influence on the map tiles, only on the
> mdr file (as long as --latin1 is used).
>
> I can upload the three img files if you don't have them.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Tick
tor.compare().
> I have to run a few tests to understand the meaning of the change.
>
> Any chance to create unit tests for this? I got the impression that
> the indexes work quite well in the past, at least for latin1.
>
> Gerd
>
>
>
Hi Gerd
After considering all places where the createSortKey strength must be
set I've decided it isn't a good approach:
1/ It needs changes in NET and LBL as well as MDR.
2/ Because case-differences are not sorted, an apparently sorted and
unique list of city/region/country could be out of order
NDARY matching now that the inconsistencies have been removed from
elsewhere.
Ticker
On Wed, 2021-10-27 at 14:18 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I suspect none, but I'll have a search and see if there are any
> places
> that don't set the collator to SECONDARY
the comparison with TERTIARY
> strength?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 27. Oktober 2021 14:35
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit
__
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 27. Oktober 2021 13:41
> An: mkgmap development
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4810: revert changes
> from r4809 for now, they caused more trouble
>
> H
Yes, a typo - sorry for any confusion
Ticker
On Wed, 2021-10-27 at 10:07 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I can't say much about the code but I wonder why you talk about cp836
> while Carlos reported to use --code-page=936.
>
> Probably just a typo in your posts?
>
> Gerd
__
Hi Gerd
Attached is version 3 of the patch.
The significant problem was the logic (in Mdr5) where change in sortKey
only was used to make unique lists, implying TERTIARY differences. The
related structures had been processed with a Collator with SECONDARY
strength. I've added an option to set the
ing structures.
The fix I'm working on for "r4809 crashes by buildung mdr" will stop
this crash, but won't change any of the above.
I don't know if there has ever been an attempt to make mkgmap indexing
work for character sets like cp836.
Ticker
On Sun, 2021-10-24 at 18:0
t; I think it's nearly impossible to reproduce the problem with the
> > scripts. Best would be if Arndt could post a link to the zipped *.img
> > files.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
&g
h to know the details of the entries between the
> from (f) and the to (t) position in the corresponding list to get a
> hint about the involved strings (or map tiles)?
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
>
pBuilder.onFinish(GmapsuppBuil
> der.java:174)
> at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:690)
> at
> uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.ja
> va:126)
> at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:147)
> at uk.me.par
0200, Carlos Dá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 Ca
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 t
os Dávila wrote:
> 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&#x
t;
> https://files.mkgmap.org.uk/download/524/31177013.o5m
>
> El 22/10/21 a las 9:42, svn commit escribió:
> > Version mkgmap-r4809 was committed by gerd on Fri, 22 Oct 2021
> >
> > fix java.lang.AssertionError while building index from unicode
> > tiles
> > mdrU
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®ion but in different countries - this
is very unlikely. An additional test for this would clarify; maybe
starting off as
gt; so far I don't understand most of the 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"?
>
u describe it "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
> Gesende
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
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 w
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
cussed them with
> 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 mkgm
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
mentione
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
_
e same
> problem for other 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:
to be consistent with the sort 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
&g
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
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
wrote:
> > 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
> >
> >
n. What's
> > 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
> > A
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 "x"
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
mkgmap-dev@lists.mk
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 --
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"
" c
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 la
, 23. Juli 2021 20:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Echange .typ-file in gmapsupp.img on Mac OS
> x 11 or newer?
>
> oh - well compared to gmt which does it in a second that's a big
> difference...
>
> On Fri, 23 Jul 2021
add
> here ot have the most needed functionality of gmt for end users
> available for Mac?
>
> On Fri, 23 Jul 2021 at 19:06, Ticker Berkin
> wrote:
> > Hi
> >
> > The mkgmap / display tool has a function to extract all the
> > components
> > fro
Hi
The mkgmap / display tool has a function to extract all the components
from a gmapsupp.img and another function to take components and build a
composite image.
You'll need to get the sources from svn - see:
https://www.mkgmap.org.uk/mkgmap/display
and build it.
In an empty directory, my un
Hi Karl
polygons near here, eg
https://www.openstreetmap.org/way/215482946
https://www.openstreetmap.org/way/215482937
look to be a bit of a mess - one shows a big spike. If you go to
40.777236,0.641794 and query features at this point, the hover previews
don't correspond very well.
Ticker
Hi Gerd
Is this of any relevance -
https://en.wikipedia.org/wiki/Branch_and_bound
Ticker
On Wed, 2021-06-30 at 16:08 +, Gerd Petermann wrote:
> Hi all,
>
> I've started this branch to further improve the split results.
> Splitter has two different algorithms to find good splits.
> 1) Alg
4.
> If this loops doesn't filter duplicate points it should be fixed.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 17. Juni 2021 13:06
> An: Development list for mkgmap
> Betreff
ould
> be fixed in general, not just for this very special case.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 17. Juni 2021 12:27
> An: Development list for mkgmap
> Betreff: Re: [mkgmap
a
fix again.
Ticker
On Thu, 2021-06-17 at 09:57 +, Gerd Petermann wrote:
> Hi Ticker,
>
> that's clear. I just don't see in what situation this can happen.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Ber
think it
> would mean that the previous loop doesn't work.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 16. Juni 2021 12:41
> An: mkgmap development
> Betreff: [mkgmap-dev] Remove
Hi Gerd
Here is a slight enhancement to low-res-opt RemoveObsolete. It is
possible that this case (a b c c b a) will never happen because "c"
will probably be de-duped.
Ticker
Index: src/uk/me/parabola/mkgmap/filters/RemoveObsoletePointsFilter.java
===
201 - 300 of 1134 matches
Mail list logo
