Re: [mkgmap-dev] Help with registry for Basecamp

If you use gmapi format there are however also many disadvantages. Cannot quickly create a gmapsupp.img with mkgmap. Export of gmapsupp.img with MapInstall is slower while some other things are just different. It's more complicated to find bugs with multiple maps (if for example you do not move the

[mkgmap-dev] Farsi conversion/codepage - Iran 1256 v 1256 extended

In Iran there are a few characters that are super common but not in codepage 1256. It's characters that belong to ARABIC LETTER FARSI YEH Below is an example https://r12a.github.io/app-analysestring/?chars=%D9%86%DB%8C%D8%A7%D8%B4 نیایش character: U+06CC

Re: [mkgmap-dev] Deathloop on splitting file created by splitter if using argentina.poly --polygon-file

the polygon which contains large, almost empty areas. I think > you should never use it when you re-split. > > Gerd > > ____ > Von: Felix Hartmann > Gesendet: Sonntag, 18. Dezember 2022 12:14 > An: Gerd Petermann > Betreff: Re: [mkgma

[mkgmap-dev] Deathloop on splitting file created by splitter if using argentina.poly --polygon-file

Hi, I tried resplitting a file that was too big for the map creation using splitter - and if I use the boundary file splitter.jar is getting stuck finding a solution (until killed). Command: start /belownormal /b /wait java -XX:+AggressiveHeap -Xms5000M -Xmx4m -jar C:\openmtbmap\splitter.jar

Re: [mkgmap-dev] Test if POI is part of a line

Not sure which Felix you meant. For me it was not about that poi influencing the routing, but the opposite. If mkgmap created a reputable line only then display the gate. E.g. if excluded using semi-connected marker, then also remove the gate. Typical scenario a highway=path entering a residence g

Re: [mkgmap-dev] Test if POI is part of a line

I won't be able to test anything the next 2 weeks however. Traveling in Nepal On Tue, 1 Nov 2022, 15:29 Felix Hartmann wrote: > Not sure which Felix you meant. For me it was not about that poi > influencing the routing, but the opposite. If mkgmap created a reputable >

Re: [mkgmap-dev] Test if POI is part of a line

On Mon, 10 Oct 2022 at 22:05, ael wrote: > On Mon, Oct 10, 2022 at 09:39:11PM +0200, Felix Herwegh wrote: > > > I have mapped gates in a fence/wall which are not on routable lines. > These are very important if you are to find your way out of an enclosure > or field. I am thinking of just such a

Re: [mkgmap-dev] Test if POI is part of a line

generated points from ways > with highway=* and a tag barrier=gate on the node. > > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Montag, 10. Oktober 2022 11:47 > An: Development list for mkgmap > Betre

Re: [mkgmap-dev] Test if POI is part of a line

h tells > Garmin > that it must not route the given vehicles through the barrier. Older > implementations created a short stub close to the barrier node. > > Gerd > > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Ge

Re: [mkgmap-dev] Test if POI is part of a line

, and show the gate that is blocking the road. I think this is better that deleting that road because of the gate. On Mon, 10 Oct 2022 at 11:47, Felix Hartmann wrote: > Hi Gerd, > > No --*add-poi-to-lines* creates points from a line that has certain > tags. What I try to achieve

Re: [mkgmap-dev] Test if POI is part of a line

is that the current > implementation in mkgmap processes > (tagged) nodes before lines. I can't remember exactly why but a change > probably causes side effects. > > Gerd > > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartm

[mkgmap-dev] Test if POI is part of a line

I read through the old poi-tagged-v3.patch is_in()function for point on line discussion - but what I want is actually different and should be much easier? Could there be a solution to check if a point is a single point vs if it is part of a open/closed line? Why? I would only like to display bar

Re: [mkgmap-dev] Building display.jar fails

nds of confusion when you > search for an address and the result > contains lots of unrelated stuff because there is a route relation that > has a word in its name which starts > with the same word. > > Gerd > > ____ > Von: mkgmap-dev

Re: [mkgmap-dev] Building display.jar fails

ber code sometimes adds labels > so that addresses can be found. > > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Montag, 13. Dezember 2021 12:29 > An: Development list for mkgmap > Betreff: Re: [mk

Re: [mkgmap-dev] Building display.jar fails

; doesn't expect more than N bytes, and that again can cause all kinds of > trouble. > Will try to reproduce the problem with a modified default style ... > > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet:

Re: [mkgmap-dev] Building display.jar fails

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: >

Re: [mkgmap-dev] Exception in thread "main" java.lang.ArithmeticException: / by zero

t; gmapi folder shows a file with 0 bytes. > > Just starting to understand that part of the program ... > > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Freitag, 10. Dezember 2021 13:10 > An: Developmen

Re: [mkgmap-dev] Exception in thread "main" java.lang.ArithmeticException: / by zero

es reach the 2G barrier. > Don't use the overflow2.patch, it might be part of this problem. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Freitag, 10. Dezember 2021 12:35 > An: Development list f

Re: [mkgmap-dev] Exception in thread "main" java.lang.ArithmeticException: / by zero

error occurs while the gmapsupp.img is written, the routine that fails > is called for each sub file. > Is it possible to share the input data and style? > If not I can try to add logging statements. > > Gerd > > > > Von: mkgmap

[mkgmap-dev] Exception in thread "main" java.lang.ArithmeticException: / by zero

Any idea what is going wrong here? I think the result is actually okay... Command: C:\openmtbmap\maps>start /belownormal /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=103 -Xmx43000M C:\openmtbmap\mkgmap.jar --max-jobs=12 --order-by-decreasing-area --code-page=65001 "--style-file=C

Re: [mkgmap-dev] PATCH reduce index size

he > --split-name-index option. I also tried to remove the full entry but then > the search didn't work any more. > > Check what happens when you remove the clause "st.getNameOffset() > 0 && " > . > > Gerd > > _____

Re: [mkgmap-dev] PATCH reduce index size

are you sure this works fully? I still have some strings in the display.jar output. I updated the gmapsupp.img here: https://openmtbmap.org/gmapsupp.img The log file from display.jar decreased by around 15% in size - but there are still entries like: 00036727 | 00300e | 4d 30 2e 20 | [

Re: [mkgmap-dev] Building display.jar fails

. Just clipping at 170 characters will remove some wasted space. And thanks for the patch. on the new thread. On Sun, 5 Dec 2021 at 10:58, Felix Hartmann wrote: > I simply add all route names to the name. Actually mkgmap should cut after > XX characters. > > I will count the max for

Re: [mkgmap-dev] Building display.jar fails

should have done this anyway) > - add a new option which tells mkgmap that --mdr7-del should remove all > substrings, not only suffixes (the effect will be rather small, looking at > those long names) > > Gerd > > > Von: mkgmap-dev im Au

Re: [mkgmap-dev] Building display.jar fails

Sorry, the slash at the end should not be there: https://openmtbmap.org/gmapsupp.img On Sat, 4 Dec 2021, 19:16 Gerd Petermann wrote: > Hi Felix, > > the link doesn't work. > > Gerd > > > Von: mkgmap-dev im Auftrag von

Re: [mkgmap-dev] Building display.jar fails

d by > mkgmap. Please post a link to a small one that shows this problem. Or does > it only happen with very large files? > > The name "T3 pth" should not appear in Mdr 7 if both t3 and pth are given > in --mdr7-del. In my test that worked well. > If the string "T3 pth&q

Re: [mkgmap-dev] Building display.jar fails

ave to use parameter --print=15 for this section, it is > ommitted by default. > > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Donnerstag, 2. Dezember 2021 19:44 > An: Development list for mkgmap > Betreff:

Re: [mkgmap-dev] Building display.jar fails

____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Donnerstag, 2. Dezember 2021 17:46 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Building display.jar fails > > still the same problem if I don't link the build folder o

Re: [mkgmap-dev] Building display.jar fails

\lib\compile > execute ant dist > Compile works with one warning. > ant -version says > Apache Ant(TM) version 1.10.8 compiled on May 10 2020 > javac -versio says > javac 1.8.0_272 > > Gerd > > ____ > Von: mkgmap-dev im Auftrag

Re: [mkgmap-dev] Building display.jar fails

^ On Thu, 2 Dec 2021 at 16:54, Gerd Petermann wrote: > Hi Felix, > > please try svn up. > Maybe the change in > https://www.mkgmap.org.uk/websvn/revision.php?repname=display&rev=565 > helps. > > Gerd > > ____ > Von:

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

. mkgmap:noaddress=yes/1 On Thu, 2 Dec 2021 at 16:49, Gerd Petermann wrote: > Hi Felix, > > don't understand what you mean. What mdr7 code could be adapted? > Strings in MDR15 are deduplicated. > > Gerd > > > Von: mkgmap-dev im Auftrag

[mkgmap-dev] Building display.jar fails

I can actually avoid it by placing mkgmap.jar into the display tool folder - however then the display.jar is not working and ends with the notice: "no main manifest attribute, in C:\openmtbmap\display.jar" I get the following error I don't know how to solve when building the display.jar display

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

e "G3 TRK" is not changed at alll because g3 and trk are > both in your list and thus the algo finds no part that should be kept and > stops. > Maybe not the best idea. > > Gerd > > > > Von: mkgmap-dev

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

d this to the dok. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Donnerstag, 2. Dezember 2021 13:27 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Exception in thread "main"

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

pressed format for the string table (Mdr 15) but we don't > know how the compression works. > I guess we could add code to omit the string table. It's probably not > mandantory. On the other hand I see no need for a detailed map > of whole Europe anyway. > > Gerd > >

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

alone. On Wed, 1 Dec 2021 at 18:07, Felix Hartmann wrote: > It's still crashing also with patch v2. > The full map of Europe serves one need - it is simpler than say creating 5 > maps of Europe with an Overlap. But yes I will simply create the continent > maps of Europe and A

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

ickly). On Wed, 1 Dec 2021 at 17:44, Felix Hartmann wrote: > yes it is some sort of overflow - if I do the map in two runs (1500 tiles > approx) > with 65500* > and 65501* > it compiles fine. > That's why I use a pretty long exclusion list - but this is not enough. > The in

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

ember 2021 17:16 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Exception in thread "main" > java.lang.IllegalArgumentException . on Europe extract > > I found out that if I remove --split-name-index then it compiles fine. I'm > just trying a minimal setup o

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

). On Wed, 1 Dec 2021 at 13:08, Felix Hartmann wrote: > Hi Gerd, > > here is the log - hope you can find out something with it - but I think it > is missing the problem - there are only 3 lines before the crash - all else > is many minutes before. > > 2021/12/01 12:55:08 I

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

tached patch changes something. > > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Dienstag, 30. November 2021 13:23 > An: Development list for mkgmap > Betreff: [mkgmap-dev] Exception in thread "main" > java

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

Tue, 30 Nov 2021 at 13:23, Felix Hartmann wrote: > Using mkgmap version 4808 - when compiling Europe. It went through fine on > all geofabrik country extracts. > I then upgraded to mkgmap 4819 and yesterday downloaded a new europe > extract (4 days newer) from geofabrik to see if I can

[mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

Using mkgmap version 4808 - when compiling Europe. It went through fine on all geofabrik country extracts. I then upgraded to mkgmap 4819 and yesterday downloaded a new europe extract (4 days newer) from geofabrik to see if I can reproduce it again - and the error message is identical. I'm going to

Re: [mkgmap-dev] Failure to understand apply logic in relations - or failure in the logic

Ah sorry - I missed the entry about that point in the style manual Now I understand it. On Thu, 25 Nov 2021 at 18:00, Felix Hartmann wrote: > Oh sorry - no my mistake was different - I used the wrong brackets. > However I could not find anywhere where this is documented. > worki

Re: [mkgmap-dev] Failure to understand apply logic in relations - or failure in the logic

ue inside the apply action? Usually for referencing a value we need to use curly {} brackets... On Thu, 25 Nov 2021 at 16:17, Felix Hartmann wrote: > I think there is a bug in mkgmap. > > This line works as intended: > set route_name_hiking1 = '${route_name_hiking1} + ${name|not-co

Re: [mkgmap-dev] Failure to understand apply logic in relations - or failure in the logic

the not-contained filter ithe relations file is actually adding the names of the routes after each other - while they are not added without such a filter. On Wed, 24 Nov 2021 at 10:45, Felix Hartmann wrote: > I will try your example to see where it goes wrong. Apply_once is about > forward and

[mkgmap-dev] Failure to understand apply logic in relations - or failure in the logic

route=hiking { apply { set route=hiking; set route_name = '${route_name} & ${name}' | '${name}'; add route_ref = '${ref}'; } } I would expect that this rule if several relations are matching one line, adds all names of route=hiking relations to the route_name variable separated by "&". However it

Re: [mkgmap-dev] New assertion, now with code-page=632 and Japan tile

O5m is always faster, but needs more disk space. Converting geofabrik osm.pbf to o5m makes sense however (especially if you can write to Ramdisk or slow Harddisk) On Wed, 10 Nov 2021, 17:38 Carlos Dávila wrote: > I'm aware of the supposed advantages of pbf, but I did some tests in the > past and

Re: [mkgmap-dev] New assertion, now with code-page=632 and Japan tile

Only as input for splitter it changes a lot. As input for mkgmap it's very little difference. On Wed, 10 Nov 2021, 17:38 Carlos Dávila 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

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

The current version is perfect. Avoids all those unnecessary writes and no need to go crazy on symbolic links anymore for preventing them. Files that should be overwritten - are overwritten. On Sun, 19 Sept 2021 at 15:03, Felix Hartmann wrote: > first of all I need all info.xml files - beca

Re: [mkgmap-dev] The x prepended to the *.typ file

I think - modify source file if .typ is in the output directory. Do not modify but write a new typfile (same name) if not in output directory. For me that makes most sense. But anything is fine - also the current behaviour. On Sun, 19 Sept 2021 at 19:56, Gerd Petermann < gpetermann_muenc...@hotmai

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

; An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to > disk if used with --gmapi option > > On Wed, Sep 08, 2021 at 02:10:52PM +0300, Felix Hartmann wrote: > > > > Yes on an nvme disk you barely notice the conversion -

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

more files which are overwritten even if they already exist. > Regarding linking: OK, you just want a new tdb file containing all listed > input files? No check if the output file really exists? > > Gerd > > ____ > Von: mkgmap-dev im Au

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

Info.xml will contain all files listed as input > > So, either just --gmapi-minimal or --gmapi-minimal[= which should overwritten>] > > Would that work well for all? > > Gerd > > > ____ > Von: mkgmap-dev im Auftrag von > Fe

Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null

until you find time to look at the server or should it work in > long terms? If you resplit more and more tiles I don't see how it will > improve the map or the resource usage. > > Gerd > > > Von: mkgmap-dev mkgmap-dev-boun...@lis

Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null

d it work in > long terms? If you resplit more and more tiles I don't see how it will > improve the map or the resource usage. > > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Dienstag, 14. September 20

Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null

> 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-

Re: [mkgmap-dev] mkgmap doing excessive writing

I just answered in the old topic - but it would make it very complicated if you had some tiles that you need to split again. I feel --gmapi converts everything - while --gmapi-minimal only converts input given in .o5m/osm.pbf/osm is the much better approach. The first time you use --gmapi - all sub

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

Contourlines or > other static content. > > Thomas > > Am 13.09.2021 um 15:38 schrieb Felix Hartmann: > > Hi Gerd, yes exactly. I have a large collection of .img files of > contourlines. When I realized that I trash my NVME disk very fast if I > continue the way I did I got

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

that's the normal way to do it, so I try to support that way. > > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Montag, 13. September 2021 12:28 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev]

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

idn't try it. Does it make sense? > > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Montag, 13. September 2021 12:09 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

Oh - but data was certainly written - A rename will not show as data written in both Task manager on Windows, as well as in the smart data (I'm using Windows 10 pro not Windows server however - maybe that functionality is limited to windows server?) On Mon, 13 Sept 2021 at 13:06, Felix Har

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

2:59, Felix Hartmann wrote: > Thanks Gerd, > > but that is just removing the warning if it cannot overwrite, correct? > If it can overwrite the gmap file it will still overwrite it as I see.. So > in essence just a bit more intelligent then my disabling that line. > > I think it sh

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

12/9/21 a las 21:16, Gerd Petermann escribió: > > Hi Felix, > > > > so you just want a new option so that mkgmap doesn't fail if it cannot > overwrite (write-protected) files in the output directory, right? No need > to verify the content of the exiting file(s)? > > &

Re: [mkgmap-dev] How to create an empty overview map (for transparent maps)

also simply reduce severity to warning or remove it for good. > > Gerd > > > > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Mittwoch, 1. September 2021 12:18 > An: Development list for mkgmap > Betreff:

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

- but that could have been fixed easily by changing order of commands too). On Sun, 12 Sept 2021 at 20:04, Felix Hartmann wrote: > because you need to do it if you want to show contourlines. Now compiling > the worldwide contourlines each time again - would burn SSD as well - > besides taki

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

the same input files. So the question is: Why do you do that? > > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Freitag, 10. September 2021 00:02 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev]

Re: [mkgmap-dev] custom style

Check with gpsmapedit On Sun, 12 Sep 2021, 08:56 7770 <7...@foskan.eu> wrote: > Hi. > > As a test i once once added a specific condition for fuels so that the > points > style file contains these two rows: > (amenity=fuel & fuel:e85=yes) [0x4401 resolution 22] > amenity=fuel [0x2f01 resolution 22

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

... On Wed, 8 Sept 2021 at 17:07, Felix Hartmann wrote: > Well I could give it 20 GB ram disk, maybe 32 but then I need to render on > less than 12 processes 64GB ram available). But that is not enough for Asia > continent map, and I guess super tight for Europe... > > Mkgmap could

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

oh sorry - made a typo at the first number. (there was no error in the SMART data I just somehow wrote 3 instead of 6. Those 30TB of writes did not suddenly disappear). On Wed, 8 Sept 2021 at 22:36, Felix Hartmann wrote: > so continued.. > 33659 GB > After Step 1: > new 33663 GB &

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

they are out of the way - the rest will do on the RAMDISK. Again would be much easier if those symlinks are not needed because mkgmap behaves SSD friendly and does not write those files in first place. I have come down from 14GB to 8GB of writes for the Alps. Maybe only 7.5GB (sound more pl

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

-- So let's try something new - we move the gmap 6* folder after the first compile and put a hardlink (mklink) back so mkgmap cannot fuss around with them anymore. Yeah we're using croutches so to say. I will post again the results if I can

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

files not needeed to be written Also would save quite some CPU time. On Wed, 8 Sep 2021, 14:31 ael wrote: > On Wed, Sep 08, 2021 at 02:10:52PM +0300, Felix Hartmann wrote: > > > > Yes on an nvme disk you barely notice the conversion - it's really quick. > > BUT it is

[mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

Quite a few people do not compile the contourlines each time they update a map, but reuse the old contourlines. This works fine if you insert them as say 1234*img (and they are named 1234.img 12340001.img and so on). However this does not work when providing the --gmapi option. Actually mkgmap

Re: [mkgmap-dev] Error when running splitter with several input files, could there be keep-complete=single mode?

of these broken tiles into a separate process for splitting. On Tue, 31 Aug 2021 at 12:23, Felix Hartmann wrote: > That step is very easy. > > You feed %FID% (if you use fid for first 4 numbers of mapid) and the new > template.args to mkgmap.jar. No need to recreate the .img files

Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null

Okay - this error can be solved by removing the "Input that do not exist from the template.args input file. - e.g. if 85610002.o5m does not exist need to remove the line input-file: 85610002.o5m from the template.args file. On Tue, 31 Aug 2021 at 21:11, Felix Hartmann wrote: > Partly re

[mkgmap-dev] How to create an empty overview map (for transparent maps)

If you create a separate map for buildings or contourlines only - usually there is no need for an overview map - or better no need for any content in the overview map - or am I missing something? Because those maps sometimes may have very large tiles, but very few levels (maybe only 24) - mkgmap c

[mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null

Partly related to the other problem - if I run mkgmap on the splitted files - I get this error. All .img files seem to be fine, but the gmpsupp.img is created with 0 bit size. This is not happening every time I resplit tiles. In this case two tiles were joined by osmconvert - and splitter splits i

Re: [mkgmap-dev] Error when running splitter with several input files, could there be keep-complete=single mode?

by needed attention time. > Don't shut down PC and tomorrow my new maps have been created somewhere > between 06:00 and 09:00 AM or they failed. > > A one time problem is resolved by a new procedure for next occurrence. > One time problems don't exist 😝 > > AnkEric (Eric) >

Re: [mkgmap-dev] Error when running splitter with several input files, could there be keep-complete=single mode?

yes - exactly what Ticker wrote is my intention. It seems fine using o5m and merging with osmconvert however for right now If it's only a single tile no problems, but if its 2-X files - then you can only use keep-complete=false - or instead of using osm.pbf output in splitter o5m, and then merg

Re: [mkgmap-dev] Error when running splitter with several input files, could there be keep-complete=single mode?

this all works fine. Seems I have to beef up my server by another NVME disk to accommodate for the larger o5m vs osm.pbf files. I need to store all splitter created files - because I run mkgmap several times... Just convenience. On Mon, 30 Aug 2021 at 12:50, Felix Hartmann wrote: > Well I&#x

Re: [mkgmap-dev] Error when running splitter with several input files, could there be keep-complete=single mode?

te.franceb1 input file option). Google spits out no mention at all concerning this error. I would guess there is an error in the --gmapi file? On Mon, 30 Aug 2021 at 12:38, Felix Hartmann wrote: > okay - well the only working solution to this problem is to use o5m output > format with mkgmap

Re: [mkgmap-dev] Error when running splitter with several input files, could there be keep-complete=single mode?

hdd space, and mkgmap.jar is only marginally faster with 05m input vs osm.pbf (splitter works quite a lot faster on big o5m files vs osm.pbf - but small input files make not much time difference)... On Mon, 30 Aug 2021 at 02:25, Felix Hartmann wrote: > I split france.osm.pbf with D:\openmtb

[mkgmap-dev] Error when running splitter with several input files, could there be keep-complete=single mode?

I split france.osm.pbf with D:\openmtbmap\maps>if france == legend start /belownormal /b /wait java -jar -XX:+AggressiveHeap -Xms1000m -Xmx3800m C:\openmtbmap\splitter.jar --max-nodes=960 --max-threads=12 --search-limit=100 --output=pbf "--keep-complete" --max-areas=1024 --geonames-file=D:

Re: [mkgmap-dev] signed maps / new device

Just make a map of Cyprus and check if you get greek in the South, and Turkish special characters in the north. The Latin alphabet without special characters like ö or accents is covered in nearly all codepages. On Wed, 4 Aug 2021, 07:15 7770 <7...@foskan.eu> wrote: > Hi. > i have made maps using

Re: [mkgmap-dev] signed maps / new device

of course - any new device needs hacked firmware or non unicode maps. 1251 or whatever works however. I explained it above - tested that many times. If we cannot come up how to digitally sign a map (maybe any code signing certificate would be fine? but I have no clue how they signed the maps and wh

Re: [mkgmap-dev] Improper transliteration of Bulgarian text

The transliteration is never good. So either use cyrillic codepage or Unicode without transliteration. Do not transliterate at all - that*s the best solution. Essentially you have 4 options: local codepage - no transliteration using name key - transliterate other letters into cyrillic unicode usin

Re: [mkgmap-dev] signed maps / new device

If you have a code signing certificate, would it be possible to add that digital signature to Unicode maps? Every codepage works on the newer devices - as long as the codepage is supported by the device - even codepages like Simplified or Tradition chinese Characters. For some languages however no

Re: [mkgmap-dev] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?

e. I know that your installation > routine allows to choose a typ file. Do you plan to distribute mkgmap and a > full JRE with each installation package? > > Gerd > > > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Sonnt

Re: [mkgmap-dev] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?

@ andrzej, could you maybe add that functionality to mkgmap? It would be great to have On Sun, 25 Jul 2021, 15:37 Andrzej Popowski wrote: > Hi, > > actually gmaptool doesn't split and merge img, when replacing typ. It > overwrites old data with a new one. If new typ is longer then the old

Re: [mkgmap-dev] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?

> Ticker > > On Fri, 2021-07-23 at 19:24 +0300, Felix Hartmann wrote: > > Hi Ticker, > > > > thanks for your answer > > If the gmapsupp.img is 2GB - will this be kinda instant or will it > > rewrite the full gmapsupp.img from scratch? > > > > It would

Re: [mkgmap-dev] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?

st.ZipFile ../newgmap.img * > > This will probably change the order of the components and I've no idea > if this matters, but, if it does, give an explicit list, derived from > the output of ExtractFile, instead of * > > Ticker > > On Fri, 2021-07-23 at 16:08 +0300, Fe

[mkgmap-dev] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?

Hi - is there any tool available to change the .typ-file in a gmapsupp.img on the Mac OS X Big Sur or newer? As gmt_osx is not gonna be updated to x64 - I wonder if there is an alternative. Or maybe could this function be added to mkgmap? I would imagine a call java mkgmap.jar --change-typ gmapsu

Re: [mkgmap-dev] Change in Garmin IMG format?

an example of what you mean by "changing the > types"? Having the option to use the high-contrast maps would be great, > even though it's not my first choice.. > > Thanks, > Craig > > On Mon, Jul 19, 2021 at 4:30 AM Felix Hartmann > wrote: > >> The .typ-

Re: [mkgmap-dev] Change in Garmin IMG format?

The .typ-file does not matter - you need to change the types if you want to use the high-contrast rubbish... On Mon, 19 Jul 2021 at 06:05, Craig Durkin wrote: > Has anyone had to make changes to their TYP file to make things look > better with the high-contrast map? I make maps where I draw a bu

Re: [mkgmap-dev] Change in Garmin IMG format?

No they haven't changed the img format, what they did is that for years they designed the maps in layout for desktop size displays, and finally discovered maps should be much higher contrast on small displays. So they introduced (already sind 2-3 years) a high contrast layout that is more and more

Re: [mkgmap-dev] new splitter branch solve-parallel

Hi Gerd, well setting initial search limit to 100 solves already loads of bad solutions and is still quite fast. Albeit using v 408 it was the best universal value I felt. Not much slower but in many cases getting better results. Going for much bigger initial value actually then caused also wor

Re: [mkgmap-dev] splitter r609 released

cnt0 = 227" "for greenland use polygon-file - cnt1 = 4 cnt0 = 2" "for mexico use polygon-file - cnt1 = 44 cnt0 = 42" "for reunion do not use polygon-file - cnt1 = 3 cnt0 = 5" On Wed, 30 Jun 2021 at 12:30, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote

Re: [mkgmap-dev] new splitter branch solve-parallel

I feel of all tiles are 85 percent of max then stop. If 5percent of tiles are less the 75 percent max then maybe stop after 30 seconds. If more then 10 percent AND more then 10 tiles are less then 75 percent continue. On Wed, 30 Jun 2021, 19:09 Gerd Petermann wrote: > Hi all, > > I've started th

Re: [mkgmap-dev] splitter r609 released

don't expect to always get fewer tiles when you use a polygon-file ;) > > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Mittwoch, 30. Juni 2021 10:10 > An: Development list for mkgmap > Betreff

Re: [mkgmap-dev] splitter r609 released

; I'll try to find a fix so that splitter doesn't try to fit the tiles into > the polygon when this happens... > > Gerd > > > Von: mkgmap-dev im Auftrag von > Felix Hartmann > Gesendet: Mittwoch, 30. Juni 2021 08:55 >

  1   2   3   4   5   6   7   8   9   10   >