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 do this?
Ticker
On Fri, 2021-10-22 at 09:06 +, Gerd Petermann wrote:
> Hi Ticker,
>
> just learned (again) that M
.
The proportion of input tag values that never make it into the final
.img must be quite high, so doing it early could be costly.
Ticker
On Mon, 2021-11-15 at 11:01 +, Gerd Petermann wrote:
> Hi all,
>
> see also https://forum.openstreetmap.org/viewtopic.php?id=74231
> mkgmap sometimes fai
Hi all,
> Maybe we should simply stop transliteration when this happens and return an
> empty string for the label?
any thoughts on this?
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Mittwoch, 10. November 2021 11:17
An: Devel
Hi all,
see also https://forum.openstreetmap.org/viewtopic.php?id=74231
mkgmap sometimes fails to encode correct strings for a given codepage like 1252
(latin1).
I've uploaded a file that contains an area in Germany where the u-umlaut in
name
Twülpstedt is encoded in two different ways,
Hi Ticker,
a) probably clear with uppercase3.patch
b) won't work, I think the entries in Mdr15 can contain more or less anything
c) probably vice versa, Mdr15 should contain what is displayed to the user on
the PC, other index entries always seem to be uppercase.
d) Yes, that's a strange
-14 at 16:21 +, Gerd Petermann wrote:
> Hi all,
>
> I think I finally found what's wrong. MapSource doesn't like the
> Mdr12 index which contains a few pointers with the first 4 characters
> of a POI name. The funny thing is that MapSource works well when this
> section isn't wri
understand what's wrong.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Samstag, 13. November 2021 11:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with global index POI search
Hi,
this problem is possibly related
alternatives with Collator.setStrength() and
similar but nothing fixed the search. I guess we really need a very small set
of tiles with only a few strings to fully understand what's wrong.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Samstag, 13
Hi,
this problem is possibly related to --lower-case.
Both attached mini-patches seem to fix the problem (but may introduce others).
No idea yet if this is the right way to tackle this problem.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
on
Hi.
I treid renaming, but it did not help. Like somebody mentioned, it seems to be
something that Garmin changed in the search alogorythm. Perhaps not much that
one can do to when generating the map.
Thanks anyhow!
Karl
On torsdag 11 november 2021 19:43:47 CET Gerd Petermann wrote:
>
Hi devs,
Enrico has contacted me in a PM about a rendering problem with his maps and
while analysing that I found an obvious bug searching for e.g.
"Scuola Dell Infanzia Fondazione Pietro Caprettini" as name of the POI without
filling any further fiels in MapSource.
When I start to type that
Hi Karl,
I've seen this problem on my Oregon when another map was installed (but not
activated).
The map was the Bicycling-Layer for Europe from http://osm.thkukuk.de/
I did not find out why it caused problems, but after renaming the corresponding
*.img file the search was fast again.
Gerd
la
> mailto:car...@alternativaslibres.org>>
> wrote:
>
> I'm aware of the supposed advantages of pbf, but I did some tests
> in the
> past and I found o5m to be quite faster than pbf, but I'll test again.
>
> El 10/11/21 a las 9:43, Gerd Petermann escribió:
>
von Gerd
Petermann
Gesendet: Mittwoch, 10. November 2021 09:43
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] New assertion,now with code-page=632 and
Japan tile
Hi Carlos,
I'll try to debug this.
BTW: I see you use *.o5m for the tiles (output from splitter). I th
Hi Carlos,
I'll try to debug this.
BTW: I see you use *.o5m for the tiles (output from splitter). I think this is
no longer a good choice, pbf is a lot smaller and almost as fast. Esp. when it
comes to the goal of reducing disk I/O (as with --gmapi-minimal)
Gerd
but, for European names at
least, I presume it has been used quite a lot and no complaints.
If the default strength for a Collator is TERTIARY, there is no logical
change in behaviour to Mdr5 with this patch.
Ticker
On Sat, 2021-11-06 at 14:33 +, Gerd Petermann wrote:
> H Ticker,
>
> b
about how to tackle the case-differences in city names and what
MdrCheck is reporting.
Ticker
On Sat, 2021-11-06 at 14:10 +, Gerd Petermann wrote:
> Hi Ticker,
>
> ok, so let's wait for that crash to get an example. I really have no
> idea how to force it :(
> According to Mdr
to be much more difficult.
Ticker
On Fri, 2021-11-05 at 11:00 +, Gerd Petermann wrote:
> Hi Ticker,
>
> sorry for my reluctance. I simply have no test case that shows an
> error (search for xyz not working). If you have one please share it
> so that I can understand the importance of t
Hi Ticker,
sorry for my reluctance. I simply have no test case that shows an error (search
for xyz not working). If you have one please share it so that I can understand
the importance of the patch.
I would also be happy if you could create a new branch to test further changes
reg.
Hi all,
see https://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=643
I've merged the branch now although the branch version sometimes produces
slightly worse results compared to r642.
As Felix pointed out one general problem with splitter is that the results for
some countries or
ountries don't cause a problem because they
> (almost always) originate from --bounds and go through
> PlacesFile.createRegion() / createCountry() which stops any case
> difference within a tile.
>
> Ticker
>
> On Thu, 2021-11-04 at 13:15
Hi Carlos,
please try the branch version
https://www.mkgmap.org.uk/download/splitter-solve-parallel-r641.zip
I never found the time to complete the work on this.
Would also be good to have the densities-out.txt file.
Gerd
Von: mkgmap-dev im Auftrag von
case
difference within a 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
: revert changes from r4809
for now, they caused more trouble
Hi Gerd
Yes, patch r4809 caused the crash with Arndt's data (--lower-case and
differently cased city names).
Ticker
On Thu, 2021-11-04 at 11:11 +, Gerd Petermann wrote:
> Hi Ticker,
>
> thanks, will have a closer later. Jus
Hi Ticker,
thanks, will have a closer later. Just to make sure:
My understanding is that the 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
Hi Manfred,
I assume you refer to https://www.osm.org/way/136793805
Maybe the tag barrier=fence makes the difference?
Gerd
Von: mkgmap-dev im Auftrag von Manfred
Haiduk
Gesendet: Mittwoch, 3. November 2021 13:44
An: Development list for mkgmap
y as a new issue.
Ticker
On Wed, 2021-11-03 at 14:27 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> yes, might be better to change that to be more precise. Question is
> if Aa and AA are two different cities or just different spellings of
> the same city. The latter is much more like
ue) will return the same City record for
both "Aa" and "AA" so I propose to remove the toUpperCase() from it
when --lower-case (unless ascii/cp0 which forces upper case)
Ticker
On Wed, 2021-11-03 at 09:17 +, Gerd Petermann wrote:
> Hi Ticker,
>
> no idea what yo
Hi Ticker,
no idea what your problem is.
Address search seems to work fine without any city POI. I think the code just
tries to avoid duplicated entries in the LBL file?
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Dienstag, 2.
have 3G memory) to a 64-
bit OS and Java 11, but generally the performance is worse.
The 21 seconds for either version of calcMdrSortPos() is doing all 232
tiles of NRW+.
Ticker
On Tue, 2021-11-02 at 08:39 +, Gerd Petermann wrote:
> Hi Ticker,
>
> here's the new version. No idea what
++;
c.setMdr20Index(mdr20count);
add this: c.setMdr20SortPos(mdr20count);
Ticker
On Sat, 2021-10-30 at 09:16 +, Gerd Petermann wrote:
> Hi Ticker,
>
> attached is a patch that simplifies calcMdr20SortPos(), no change in
> output intended.
> Does it
n MapSource the results are similar, but it doesn't suggest "De
> Wijk" as city name, only "de Wijk".
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Freitag, 29. Oktober 2021 09:13
> An: Development list for m
if (!c.isSameByName(collator, lastCity))
mdr20count++;
c.setMdr20Index(mdr20count);
add this: c.setMdr20SortPos(mdr20count);
Ticker
On Sat, 2021-10-30 at 09:16 +, Gerd Petermann wrote:
> Hi Ticker,
>
> attached i
Hi Ticker,
attached is a patch that simplifies calcMdr20SortPos(), no change in output
intended.
Does it help?
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Freitag, 29. Oktober 2021 14:10
An: Development list for mkgmap
Betreff: Re
case-sensitivity to cities to give the old
behaviour, but this may be avoiding the real issue. It seems wrong that
device/basecamp/mapsource should present multiple "identical" cities
and the correct one needs to be selected to find its streets.
Ticker
On Fri, 2021-10-29 at 08:35 +,
______
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Freitag, 29. Oktober 2021 09:13
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4810: revert changes from r4809
for now, they caused more trouble
Hi Ticker,
OK, patch looks more
Hi Ticker,
OK, patch looks more consistent then v2 where I wondered about 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
this, but it adds extra cost, whereas changing
the key reduces cost.
Ticker
On Wed, 2021-10-27 at 11:57 +, Gerd Petermann wrote:
> Hi Ticker,
>
> if I got that right the method Sort.setKeyStrength() changes the Sort
> instance that is also used in other classes?
> This
containing maybe 0/1 city and so it could
be
very sensitive to the exact contents of the map.
I used the splitter on europe-latest.osm.pbf with
will have a slightly different content to cutting with a different
tool
(osmosis) @Arndt - how do you do this? and also the areas.list
It also might be sens
Hi Ticker,
if I got that right the method Sort.setKeyStrength() changes the Sort instance
that is also used in other classes?
This looks confusing if not dangerous.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Mittwoch, 27. Oktober
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
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Mittwoch, 27. Oktober 2021
w I have a set of .img files and the MDR, I'll try as you
suggest and see what is the structures are around these indices.
Ticker
On Tue, 2021-10-26 at 07:17 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> I also failed to reproduce the crash with an older download of
> Europe. I'll try t
Hi Ticker,
I also failed to reproduce the crash with an older download of Europe. I'll try
to download a new one today.
An alternative might be to add more logging data.
The assert message says
changed f=369297 t=369312 count=7092
Wouldn't it be enough to know the details of the entries between
Hi Ticker,
just learned (again) that MapInstall fills Mdr25 when it writes a gmapsupp.
That should help.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Freitag, 22. Oktober 2021 10:53
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap
Hi Ticker,
attached are two slightly different patches for Mdr25 which I think make the
code more plausible. v2 would be my choice.
I've not yet tried to find out (again) how the sort works regarding strength.
In my maps I see that Mdr25 contains fewer records than Mdr5 (e.g. 7609 of 8275
or
analyse the content
further.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Donnerstag, 21. Oktober 2021 15:48
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] java.lang.AssertionError while building index from
unicode tiles
Hi
Von: Gerd Petermann
Gesendet: Donnerstag, 21. Oktober 2021 11:21
An: Development list for mkgmap
Betreff: AW: [mkgmap-dev] java.lang.AssertionError while building index from
unicode tiles
Hi Ticker,
so far I don't understand most of the changes in mdrUnicode_v2.patch
rally case-insensitive).
There may be places where an indirect test should also use
collator.compare(). Maybe this should be tackled next.
I didn't look at MdrCheck.
Ticker
On Wed, 2021-10-20 at 08:24 +0000, Gerd Petermann wrote:
> Hi Ticker & Steve,
>
> I don't understand the mixed
heck and the classes in mkgmap.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Mittwoch, 20. Oktober 2021 09:59
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] java.lang.AssertionError while building index from
unicode tiles
Hi Ticker,
pl
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] java.lang.AssertionError while building index from
unicode tiles
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.
shared as fully as
possible.
The other changes (LargeListSorter) are slight improvements to memory
usage and/or processing time - I can remove them if you want.
Ticker
On Tue, 2021-10-19 at 08:13 +, Gerd Petermann wrote:
> Hi Ticker,
>
> please remove the unrelated changes. I think we
Hi Ticker,
please remove the unrelated changes. I think we discussed 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:
Hi Ticker,
I've never tried to understand that code, but yes, masking a position looks
wrong.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Montag, 18. Oktober 2021 10:52
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev]
Hi Ticker,
thanks for looking into this. I have no clue how to test if the index really
works with those characters as I don't know how to type them. If I got you
right mkgmap isn't able to sort the city names so I wonder how the index can be
of any use? I assume we have the same problem for
Hi Carlos,
no, the index is probably wrong for the other tiles as well. Just the special
case that causes the exception doesn't occur when e.g. the list of Mdr5 entries
has more than 256 items.
Gerd
Von: mkgmap-dev im Auftrag von Carlos
Dávila
cities), not 25 (cities with country).
The comment already shows that this is probably only correct when boths lists
have the same number of entries.
I hope Steve or Ticker have an idea what's wrong.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Ge
Hi Carlos,
I can reproduce the crash. Not sure where to fix this yet...
Gerd
Von: mkgmap-dev im Auftrag von Carlos
Dávila
Gesendet: Donnerstag, 14. Oktober 2021 18:33
An: Development list for mkgmap
Betreff: [mkgmap-dev] java.lang.AssertionError while
Hi Thorsten,
new test with r4808 against latest land-polygons-split-4326 from today found no
problems.
Maybe use the downloaded shapes for now until you found out what's wrong?
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Donnerstag
Hi again,
sorry, I tested with old shapes from 2014. Have to redo my tests...
Gerd
Von: Gerd Petermann
Gesendet: Donnerstag, 14. Oktober 2021 17:49
An: Development list for mkgmap
Betreff: AW: [mkgmap-dev] Problems with SeaGenerator
Hi Thorsten,
I
von
Thorsten Kukuk
Gesendet: Donnerstag, 14. Oktober 2021 17:11
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problems with SeaGenerator
On Thu, Oct 14, Gerd Petermann wrote:
> Hi Thorsten,
>
> did not see a warning for tile 2654208_-163840 in my quick check, runnin
Von: Gerd Petermann
Gesendet: Donnerstag, 14. Oktober 2021 16:39
An: Development list for mkgmap
Betreff: AW: [mkgmap-dev] Problems with SeaGenerator
Hi Thorsten,
seems you missed the changes in r4689?
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4689
reg. compile: I
Hi Thorsten,
seems you missed the changes in r4689?
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4689
reg. compile: I think these hints are still correct:
https://wiki.openstreetmap.org/wiki/Mkgmap/help/options#generating_precompiled_sea_yourself
I use open jdk (from
Hi Nop,
a missing resource file is caused by a wrong build. I don't know how to fix
that in IntelliJ. In Eclipse I just have to rebuild.
Maybe try to build with ant on the command line first.
Gerd
Von: mkgmap-dev im Auftrag von Nop
Gesendet: Samstag,
Hi Nop,
I suggest a new option like --dem-file-pattern or something similar.
Or maybe simply add the hardcoded prefix to the code which tries to find the
file for the given lat/lon pair in HgtReader, we already have a few different
versions reg. zipped files.
Gerd
Hi Nop,
the easiest way to contribute is to attach a patch to your post.
I don't know about IntelliJ, I can only help with Eclipse, but the resource
/help/en/options just tells mkgmap which options are documented. If you
experiment with a new option you can use the prefix "x-". So, if you want
http://www.openstreetmap.org/?mlat=-21.620439=47.791359=17
1836.osm.pbf: Similar arcs
(http://www.openstreetmap.org/way/868771618) and
(http://www.openstreetmap.org/way/873394563) found at
http://www.openstreetmap.org/?mlat=-21.750576=47.798070=17
Number of MapFailedExceptions: 0
Number o
FileHandler.pattern=mkgmap.log
java.util.logging.FileHandler.append=false
Just tested a compil for Mayotte… all fine!
Le 28/09/2021 à 10:26, Gerd Petermann a écrit :
> Hi Steph,
>
> this looks as if mkgmap crashed silently? No output to stderr?
>
> Gerd
>
> ___
6,0M steph 28 sept. 08:20 1833.osm.pbf
.rw-r--r-- 6,1M steph 28 sept. 08:20 1834.osm.pbf
.rw-r--r-- 6,4M steph 28 sept. 08:20 1835.osm.pbf
.rw-r--r-- 6,4M steph 28 sept. 08:20 1836.osm.pbf
Le 28/09/2021 à 10:08, Gerd Petermann a écrit :
> Hi Steph,
>
> the log doesn
Hi Steph,
the log doesn't show any failure. Similar arcs are quite normal even with the
default style. What makes you think that mkgmap failed?
Gerd
Von: mkgmap-dev im Auftrag von
Stéphane MARTIN
Gesendet: Dienstag, 28. September 2021 07:39
An:
Auftrag von Gerd
Petermann
Gesendet: Samstag, 18. September 2021 10:33
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk
if used with --gmapi option
Hi Felix,
maybe another speed improvement is possible. I've noticed that each *.img
: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Montag, 20. September 2021 08:57
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file
Hi all,
to avoid both the prepended "x" and stopping with an error message mkgmap could
write the modified copy
t; generates. How that plays in this scenario I have no idea.
>
> On Sun, Sep 19, 2021 at 9:56 AM Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
> > Hi Ticker,
> >
> > OK, I agree that it isn't the best idea to modify a source file.
> > So, mayb
enerates. How that plays in this scenario I have no idea.
>
> On Sun, Sep 19, 2021 at 9:56 AM Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> > Hi Ticker,
> >
> > OK, I agree that it isn't the best idea to modify a s
but I think it should be got rid of.
>
> Thanks for clearing up the mystery!
>
> Dave
>
> On Sun, Sep 19, 2021 at 4:30 AM Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
> > Hi Ticker,
> >
> > please explain why mkgmap is "stuck&quo
ename.
This doesn't effect me as I always use mkgmap to generate the .typ from
the .txt as part of the final map generation process.
Ticker
On Sun, 2021-09-19 at 10:22 +, Gerd Petermann wrote:
> Hi all,
>
> I think there is an old rather confusing glitch in mkgmap class
> TypSaver wh
Hi all,
I think there is an old rather confusing glitch in mkgmap class TypSaver which
it is used with a *.typ file as input, as in
java -jar mkgmap.jar --output-dir= --family-id=4711 ... -c
splitter-dir\template.args ..\typfiles\existing.typ
to make sure that family-id and product-id are
Hi ael,
>It seems to be profligate in its use of disk cycles.
Any further prove for this despite the gmapi directory?
While I do agree that the whole tool chain (download complete *.osm.pbf, maybe
convert to *.o5m, maybe mix with contour data, splitter, and finally compile
with mkgmap) is very
of just * and ? as in
--x-gmapi-minimal=**4711.img
However, that's just my opinion, let me know what you prefer and I change the
code.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Samstag, 18. September 2021 10:33
An: Development
it before Monday afternoon...
But I think it will do everything that is needed to write much less and speedup.
On Fri, 17 Sept 2021 at 13:11, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi all,
attached is a new patch which implements experimental option
--x-gmapi-m
for rendering the maps (and you do not need to create 0byte files to link so
they cannot be overwritten as an alternative).
On Thu, 16 Sept 2021 at 15:19, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,
what do you mean with exclude list? I suggested a possible includ
don't see a usecase for an exclude list.
On Thu, 16 Sep 2021, 11:11 Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi all,
OK, I think I can add code to detect the img files which were compiled in the
same call of mkgmap. So, with option --gmapi-minimal
- Files in thi
ldings - if buildings are shown only at resolution 24)
On Mon, 13 Sept 2021 at 14:24, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,
I have no clue how exactly your scripts work, how you manage to reuse *.img
files and so on. Also, I want to find a solution that w
nodes else your .img tiles get smaller and smaller. I had been using the
same --max-nodes values for years (with lower values if a country failed) and
noticed I could double, sometimes tripple them without any failed tiles.
On Tue, 14 Sept 2021 at 12:09, Gerd Petermann
mailto:gpetermann_muenc...@hot
turn value of
"uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null
yeah that makes resplits easier. You do not need to go into the template.args
file anymore and comment out missing tiles. So it's enough to just delete those
input tiles that were too big.
On Tue, 14 Sept 2021 at 1
Hi Felix,
I've added a null check with r4807.
Gerd
Von: mkgmap-dev im Auftrag von Felix
Hartmann
Gesendet: Donnerstag, 2. September 2021 01:45
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke
Hi Thomas,
yes, I also thought about something like that. I still have to learn some
details of the gmapi format and the generated files and dependencies between
them.
Gerd
Von: mkgmap-dev im Auftrag von Thomas
Morgenstern
Gesendet: Montag, 13.
the
contourlines. Same principle as in offering the contourlines as a separate
gmapsupp.img file. so you have maps.img contourlines10m.img contourlines20m.img
buildings.img
On Mon, 13 Sept 2021 at 13:17, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,
sorry, th
ave to move away the files and link them back to the original
folder).
On Mon, 13 Sept 2021 at 10:43, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi all,
attached is a quick patch that implements experimaltal option --x-gmapi-minimal.
If used instead of --gmapi mkgmap wi
Hi,
yes, I think that message makes no sense in this situation. I am not sure why I
decided to log this as an error.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3679
I've attached a patch to suppress the message if the input file is a ovm_*.img.
I could also simply reduce
: Sonntag, 12. September 2021 22:45
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk
if used with --gmapi option
I think it's a good idea if mkgmap checks the required files are present.
El 12/9/21 a las 21:16, Gerd Petermann
lready. For .img files they
aren't overwritten either...
On Sun, 12 Sept 2021 at 18:40, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,
did not read all the posts in detail. I understand that mkgmap is neither
burning SSDs nor doing any excessive writing unless you call
Hi Felix,
did not read all the posts in detail. I understand that mkgmap is neither
burning SSDs nor doing any excessive writing unless you call it multiple times
for the same input files. So the question is: Why do you do that?
Gerd
Von: mkgmap-dev
Hi Felix,
I did not yet try to unterstand what your goal is but it sounds wrong to merge
files produced by spltter. This can only work well when the merged tiles form a
rectangular area without gaps.
Gerd
Felix Hartmann schrieb
Sorry - the last error was a bug in my script. I
Hi Enrico,
mkgmap does not store the meta info and spltter doesn't write it, so there is
no way to do this. Maybe you can use osmfilter for that?
cioa, Gerd
Enrico Rossini schrieb
Hi, there is a way to extract in the files style the name of the mapper (user)
of an element (simply a
Hi Brad,
yes, this isn't supported. I can't estimate how much work it would be to
support this.
Gerd
Von: mkgmap-dev im Auftrag von brad
Gesendet: Donnerstag, 19. August 2021 17:49
An: Development list for mkgmap
Betreff: [mkgmap-dev] using wildcard
Hi Minko,
I expected this question ;)
The change was introduced with r4656:
https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4656
I don't know for sure why Mike added this line. I think I asked that before but
I can't find my post. Maybe I never sent it...
Is it difficult to
Hi Karl,
>is it possible to ask the line style to programmatically ...
No, so far this is not possible. In fact, the points rules are executed before
the lines/polygon rules.
It might be possible to reduce the number of generated points though. E.g. we
might add an option to generate POI only
as well, and by adding this it was
solved. Does this make sense Gerd?
Mfrgr, Minko
Van: mkgmap-dev namens Gerd Petermann
Verzonden: zaterdag 7 augustus 2021 08:51
Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] Bad tile around East London
Hi Minko,
I just tried with the latest version of the OFM style and I can still reproduce
the problem with r4802.
I adapted he paths in Jans args and commented only the DEM options.
I can also reproduce it with these few options:
java -jar mkgmap.jar --route --link-pois-to-ways
Hi Jan,
I think r4805 fixes the problem. I've not analysed why the default style
doesn't show the problem. The routing data is very different.
It seems that the OFM style produces a lot more restrictions.
Gerd
Von: Gerd Petermann
Gesendet: Samstag, 7
401 - 500 of 4859 matches
Mail list logo
