Re: [mkgmap-dev] java.lang.AssertionError while building index from unicode tiles

Hi Ticker > Problem is that resources/sort/cp65001.txt doesn't give ordering to > lots of characters; it looks like it covers only about 10,500 of the > 1,112,064 possible code-points. Many of these non-ordered characters > are being used by the names in the tile in question. I used the program

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

Hi Gerd Ticker is right about the reasoning. Perhaps if I had chosen a completely different name with the family id such as 'mkg6324.typ' no one would have thought it was so weird. You are right that it probably should be created in the output-dir like all the other compilation steps. You

Re: [mkgmap-dev] Minor spelling bug

On 28/06/2021 22:09, Manfred Haiduk wrote: Hi all as i have just opened the url https://www.mkgmap.org.uk/download/mkgmap.html i found a minor spelling bug. Instead of writing "--precomp-sea option" someone has omitted one letter "p" and there is written "--precom-sea option" If someone has

[mkgmap-dev] Fwd: Yet More Logging

[Forwarding a message that should have gone to the list] Forwarded Message Subject:Re: [mkgmap-dev] Yet More Logging Date: Fri, 16 Apr 2021 12:23:09 +0100 From: Mike Baggaley Reply-To: Development list for mkgmap To: 'Development list for mkgmap'

[mkgmap-dev] Please note when replying to messages

Hi everyone, For a day or so, messages have had a reply to address of mkgmap-dev@*www*.mkgmap.org.uk instead of the correct mkgmap-dev@*lists*.mkgmap.org.uk. This should be fixed now, but please check that you are sending messages to the correct address when replying. Steve

Re: [mkgmap-dev] remainder of logging changes

Hi Gerd please have a look. Seems the build hangs again or the patch doesn't work on unix. It works well on my machine. What is happening is that the automatic builds set _JAVA_OPTIONS=-Duser.home=/home/dir/to/use This causes every java process to output "Picked up _JAVA_OPTIONS: ..." to

Re: [mkgmap-dev] remainder of logging changes

Hi Gerd > please comment what you think about the trick with > TestUtils.runAsProcess(). I think it might not work on the build > server since ant clean test doesn't build \dist\mkgmap.jar. > Of course we can add target dist as a depency in build.xml to fix that, but I think > you had reasons

Re: [mkgmap-dev] rules test

On 29/03/2021 22:47, Mike Baggaley wrote: I have been having difficulties with the mkgmap test code which uses the discontinued javax.xml.bind.DatatypeConverter for a single function printHexBinary. Despite downloading a copy of the library and telling Eclipse to use it, it doesn't seem to

Re: [mkgmap-dev] Error in mkgmaps logging class?

Hi Gerd I've noticed that log.isLoggable(Level.WARNING) always returns true when I don't use the -Dconfig.logging option for JRE . This is unexpected as calls to log.warn(...) don't produce any output in this case. The attached simple patch seems to fix this but I don't really understand the

Re: [mkgmap-dev] Splitter download broken

Hi Download for splitter r597 (and all older versions) is broken. Please check. Thanks for reporting, I have rebuild the latest release. It was removed because it is over a year old! Best wishes Steve ___ mkgmap-dev mailing list

Re: [mkgmap-dev] Embedding raster maps

Hi Oliver > thanks for the file. On my device nothing is visible at all. But > that's kind of an information, too. There is no way to circle down > bugs by simply skipping the extended part. To be clear, nothing is visible on my device either with that polygon type. Only if I change the type

Re: [mkgmap-dev] Embedding raster maps

On 04/01/2021 13:07, Oliver Eichler wrote: Hi Steve, I tested your map. It's not listed either. I have a GPSMap64s and placed it into the internal as well as into the external memory. Attempting to use the old code was probably a mistake, I've uploaded an empty map using a modern version of

Re: [mkgmap-dev] Embedding raster maps

Hi Oliver > What is the minimum data an IMG file has to contain to be listed > on the device? Its an interesting question. I don't remember having too many problems getting a map recognised in the beginning. At r20 it worked according to the commit comment but I only added the test map

Re: [mkgmap-dev] mkgmap-r4589 download

Hi Thank you for mkgmap-r4589 release. The archive is not available to download on the website. Thanks for reporting this. The download is now available. Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Crash in NodCheck

Hi Gerd With current mkgmap the nodes in one route center are sorted by position. NodCheck doesn't seem to verify this so I assume there is no need for this order. I've looked at this again. There was code to check the sorting, but I didn't give an error because it wasn't working out.

Re: [mkgmap-dev] Crash in NodCheck

Hi > the current code in NodCheck (NodFile.java) stops reading route nodes when > if (low == 0 && flags == 0) > return null; Yes your right that check is not needed, because we know the correct size of the section. Sorry this is wrong; we know the size of the section

Re: [mkgmap-dev] Crash in NodCheck

Hi Gerd > the current code in NodCheck (NodFile.java) stops reading route nodes when >if (low == 0 && flags == 0) >return null; Yes your right that check is not needed, because we know the correct size of the section. I've found a few cases where it is wrong since

Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

Hi > Update, previous version had some errors, conclusion is the same OK, Thanks that is great. So I don't think that there wasn't really intended to be a change to routing in that branch, but there was an experimental option that was added, and then removed, with a couple of lines of code

Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

Hi Joris > Based on the versions supplied I could bring it down to 4373 still being > OK and 4384 reveals the problem Thanks for narrowing it down. There was a large change not long before that in version 4360 with the merge of the NET-no-NOD branch that did affect the routing a lot. It

Re: [mkgmap-dev] Documentation build processes - Question for Steve Ratcliffe

Hi Ticker > What software does the mkgmap server use to display html from the > mediaWiki .txt files? For testing changes to options.txt etc it would > handy to to run the same thing. It uses the same library, you just need to specify the html output-type option. mwconv -t html

Re: [mkgmap-dev] Documentation build processes - Question for Steve Ratcliffe

Hi Ticker Yes, should all be fixed now during the build. Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Documentation build processes - Question for Steve Ratcliffe

On 22/06/2020 11:16, Ticker Berkin wrote: > is mwtext https://pypi.org/project/mwtext/ ? No it isn't - unfortunately. I did not realize that it was not on pypi and now someone else has grabbed the name. I'm going to call it mwconv instead. That is not the bug though as it is picking up a

Re: [mkgmap-dev] Documentation build processes - Question for Steve Ratcliffe

Hi Ticker > The process for converting files like {svn}/doc/typ-compiler.txt to > mkgmap-r.zip:doc/typ-compiler.txt are failing. > > For a while the resultant typ-compiler.txt has been chopped off after > 8193 bytes. tuning.txt is zero bytes. I'm looking into that failure. Running the

Re: [mkgmap-dev] Splitter Build Failure

Hi I didn't fix any thing before you sent this message, but I found I needed to upgrade ivy for it to work. So I've committed that now. mkgmap already used a later version. Steve On 30 January 2020 13:45:55 GMT, Gerd Petermann wrote: >Hi all, > >I just tried again after renaming .ivy cache

Re: [mkgmap-dev] Branch is_in ready for a first test

Hi all > mkgmap.org.uk seems to be defect - there is no Sorry about that; it should be OK again now. Let me know if anything is not working. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] typfile curiosity

Hi i just stumbled again about a curious effect of the built-in typ-compiler from mkgmap. Just figured out that hex-ids for points, which are built in the way Type = 0x108, SubType = 02 or equal are mixed up after the compile to 0x00102 ? I can avoid this by building the hex-id only in one

Re: [mkgmap-dev] MDR 9 & 10 groups

Hi Ticker So, the first question is, does anyone know why 0x28 was given it's own group. I've no idea why, but that is the way it is as far as I could determine. The second problem is that the code that builds up the group start indexes into Mdr10 for Mdr9 assumes that the type ranges of

Re: [mkgmap-dev] Building map with Hebrew characters

Hi There is a problem that is specific to cp1255 in that there is a primary character with more than 15 secondary variations. I've split the first line up in cp1255.txt for lack of any better idea of what to do. The attached patch fixes both 1255 and unicode. Steve Index:

Re: [mkgmap-dev] Building map with Hebrew characters

Hi I'll be able to take a look later this evening. I think it is just all sign extension problems. Steve On 8 April 2019 11:50:58 BST, Gerd Petermann wrote: >Hi Ticker, > >sorry, can't help with this part of the source. > >@Steve: Please help > >Gerd >

Re: [mkgmap-dev] Fail automatic builds ?

On 06/02/2019 09:54, Waxy wrote: Hi, No build of mkgmap since version r4262 on the website… A problem within the automatic build ? Thanks for noticing this problem. The tests were failing to build with java 11, since that version removes a package that was being used. I've included the

Re: [mkgmap-dev] Update of typ with correct codepage and special chars

Hi Gerd do you mean like in the attached patch? I was wrong. The TYP file is created with the code page as specified on the command line, overriding the code-page in the typ text file. If there is no --code-page (or --latin1) then the code page in the file is used. This probably needs

Re: [mkgmap-dev] Update of typ with correct codepage and special chars

On 28/01/2019 06:43, Gerd Petermann wrote: WARNING: SortCode in TYP txt file different from command line setting ... The warning disappears when I remove the --latin1 option. What is this about? I suppose that warning should be removed. That's assuming that it is OK to have a TYP file with

Re: [mkgmap-dev] Not-equal compare bug?

Hi Gerd yes, I think this is a bug. In opposite to the previously posted rules your rules should work. @Steve: If I got that right the ExpressionArranger kicks in too early. It should only be called when the if-stack is empty (again). Can you have a look at it? If you have: if

Re: [mkgmap-dev] Not-equal compare bug?

Hi Rules that would match an element without any tags are not allowed. It might be possible to allow that, but I think that it would be slow. Most nodes have no tags and are just part of some way, any rule that matches on the absence of a tag would select almost all of the nodes. If anyone

Re: [mkgmap-dev] Not-equal compare bug?

Hi Gerd @Steve: If I got that right the ExpressionArranger kicks in too early. It should only be called when the if-stack is empty (again). Can you have a look at it? Yes, that does not look right, I shall have a look at it. Steve ___ mkgmap-dev

Re: [mkgmap-dev] Commit r4251: Check size of TYP polygon bitmap

Hi Nick Another issue is that at the moment TYP compiler does not support codepage 65001. OK thanks, please try the attached patch. Steve Index: src/uk/me/parabola/mkgmap/main/TypCompiler.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

Re: [mkgmap-dev] Commit r4251: Check size of TYP polygon bitmap

On 13/11/2018 10:46, osm@pinns wrote: I forgot to check this with r4251 which indeed reports wrong linewidth! Are you sure? I don't think it does! You are right and it needs a check as the width is not saved anywhere so it must be 32. Here is a patch to add the check. Steve Index:

Re: [mkgmap-dev] TYP compiler problems

Hi Ticker I'm having problems with the TYP file appearing corrupt. A simple file was working as expected, but adding a bit more caused very strange display properties in unrelated items on the Garmin device - eg, an area showed as a pattern never seen before, and, when selected, claimed to be

Re: [mkgmap-dev] Lake Garda... is empty

Hi Gerd @Steve: I don't know why you created these includes. I also think it would be easier to have the rules within the polygons file. No problem - if it is easier to have them within the file, then move them. Steve ___ mkgmap-dev mailing list

Re: [mkgmap-dev] probably dumb question about style type

Hi Marc I managed to get a camera icon using 0x5201 No idea why it works though… I tried every not-completely-silly combination until I got something:) Does that mean you do not get a camera with 0x5200? I do get a camera on (an old) mapsource. It is possible that 0x52 with no sub-type

Re: [mkgmap-dev] probably dumb question about style type

Hi Andrzej I think that safe limit for subtype is 0x1F, but for many types values up to 0x3F can be used. Are the ones above 0x1f different though? Or is it just ignoring the top bits? Is 0x3f a different icon to 0x1f for example? Steve ___

Re: [mkgmap-dev] probably dumb question about style type

Hi Nick [Check max sub-type of 0x2f (or 1f?)] The way multiple types with the same draworder in a TYP file are saved relies on subtypes being no higher than 1f. The POI types wiki page I was looking at claimed sub-types up to 2f, but I am sure you are right and that 0x1f is the correct

Re: [mkgmap-dev] probably dumb question about style type

Hi Marc From the code, I think 0x1f. I still don't get what I'm supposted to use in my style though to display those non extended values:) In my opinion the way you wrote it is correct, and mkgmap should not be giving an error for it. That should be fixed, but in the mean time,

Re: [mkgmap-dev] Compiling Typ-Files with mkgmap Version 4214

Hi Manfred i have just noticed, that compiling style txt files with mkgmap version 4214 will result in a typ-file just double the size of necessary. Thanks for finding this. It is indeed being written twice. The attached patch fixes this. Best whises Steve Looking into the resulting file

Re: [mkgmap-dev] methods to write signed / unsigned integers

On 14/05/18 12:42, Gerd Petermann wrote: I am not sure what to do with NodConvert. I think the code is wrong, it fails on NOD with restrictions, but I never use the program so I don't want to invest the time to fix it. @Steve: What do you think? I have no interest in NodConvert, if it not

Re: [mkgmap-dev] patch to improve style throughput

Hi Gerd, thanks for testing. I think your idea would require more work with little gain: 1) We have to make sure that no action deletes a. This information is not available now. 2) We have to know much more info about the rules than what we get in keystring. 3) We have to change the way how

Re: [mkgmap-dev] patch to improve style throughput

Hi Gerd, @Steve: Please let me know if you can think of a case that might not work. It looks good, I couldn't find anything that didn't work. It may not be possible or worth doing this, but if a rule can resolve, then its actions can be ignored unless continue with_actions/propagate is

Re: [mkgmap-dev] patch to improve style throughput

Hi Gerd here is the improved version of the patch. It reduces the number of rules to be checked a bit more. Thanks, that seems to work well. Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] patch to improve style throughput

Hi Gerd, thanks for review, I've added a unit test to show why your version doesn't work. Yes, that doesn't work. Well, I'll just say what I was trying to do. With these rules: a=* {set b=2} b=1 [0x10404 resolution 24] and an element with a=1, it is not possible to match

Re: [mkgmap-dev] patch to improve style throughput

Hi Gerd I don't think I understand any of this any more :( It didn't seem right to extract the key from the keystring so I tried without and the attached patch also passes all the tests - I make no other claim! Steve Hi Steve, I think I found a simple patch to improve the rule index. I've

Re: [mkgmap-dev] methods to write signed / unsigned integers

Hi Gerd, Ticker sorry for that. I waited for a comment from Steve and forgot about it. I'd still prefer that Steve gives an OK because he wrote most of the code that the patch changes. I read through the patch and done some very simple tests and it looks OK to me. Hope someone has tested

Re: [mkgmap-dev] area size in r4160

Hi I've executed the tests with the patched version a few times and it found no more errors, so I think you should commit it. This is now committed as r4165 which everyone affected by the issue should update to. Steve ___ mkgmap-dev mailing list

Re: [mkgmap-dev] area size in r4160

Hi Gerd thanks, tried it with expr4.patch and option --rand and got some errors: ERROR: Syntax: $b~2 & length()>=1 {name 'n195'} [0x2] Message: Error: (lines:1): Expression cannot be indexed This rule works for me on the patched code base, and fails on trunk. Could you check you are

Re: [mkgmap-dev] area size in r4160

Hi Gerd I think you mentioned this before but I can't find it. What / where is the RulesTest program? It is test/main/RulesTest.java I run it something like: java -cp build/test:build/classes:lib/test/* main.RulesTest --use-length There are useful options such as --errors to only show

Re: [mkgmap-dev] area size in r4160

Hi The attached patch fixes this properly I believe. Also includes a test for your particular rule. ..Steve I have this rule in my style (polygons-file): area_size() < 25000 & (fixme = * | FIXME=* |Fixme=*) {name '${fixme}' | '${FIXME}' | '${Fixme}' } [0x53 resolution 24] It gives an

Re: [mkgmap-dev] area size in r4160

Hi Harri I have this rule in my style (polygons-file): area_size() < 25000 & (fixme = * | FIXME=* |Fixme=*) {name '${fixme}' | '${FIXME}' | '${Fixme}' } [0x53 resolution 24] It gives an error: Error in style: Error: (polygons:8): Expression cannot be indexed Thanks for reporting this. I

Re: [mkgmap-dev] Error in my style with Version mkgmap-r4136

Hi Gerd looks good for me, although you may simplify the code in isIndexable(): a) The expression ((ValueOp) op.getFirst()).isIndexable() appears three times b) the term (op.getSecond().isType(VALUE) || op.getSecond().isType(FUNCTION) appears two times and I wonder why it is needed. Do you

Re: [mkgmap-dev] Error in my style with Version mkgmap-r4136

Hi Who can help me. Since Version mkgmap-r4136 i get a error with my style. Error in style: Error: (points:179): Invalid rule expression: $mkgmap:admin_level2!=DEU & $name:en=$name:de This is a bug in mkgmap. The attached patch fixes it. Thanks for reporting this problem. Steve Index:

Re: [mkgmap-dev] methods to write signed / unsigned integers

Hi Ticker Sounds good, yes please send the patch. Cheers Steve Starting from Steve's patches (getting.patch, msg.patch and img -write.patch), I've changed mkgmap+test to have/use: int get1s(), get2s(), get3s(), get4() ing get1u(), get2u(), get3u(), getNu() put1s(int), put2s(int),

Re: [mkgmap-dev] line rule not being triggered

Hi Gerd Thanks Gerd, that should be commited. I tried adding a test for isSolved() at the end of the ExpressionArranger and several tests failed. So there may be other problems, but it seems to me that it is isSolved() that has the problem. Needs more investigation. The current problem was

Re: [mkgmap-dev] methods to write signed / unsigned integers

Hi And here is the patch for just the reading side. I decided that it was best to leave in 'byte get()' as there are many places where a byte is used to hold the result and a cast would be needed for 'int get1()'. The tests pass, but there is more scope for getting this patch wrong so

Re: [mkgmap-dev] methods to write signed / unsigned integers

Hi Gerd thanks, I think that this improves the code. Small problem: I think you forgot to remove / adapt some comments in BufferedImgFileWriter, e.g. for put1 and put2. Thanks for reminding me. Attached patch for the messages. Are there any more? Steve # HG changeset patch # Parent

Re: [mkgmap-dev] bug into the style file: default\inc\compat_lines

On 21/02/18 20:40, Ataro wrote: the default style file:? default\inc\compat_lines have a bug into the line 124:? { setaccess=no; have to be changed as follows: { setaccess no; That is true, thanks. I've fixed this now. Best wishes Steve ___

Re: [mkgmap-dev] Line TYP Collision between two different maps

Hi Scott Interesting observations on how Garmin selects the TYP file to use, and I think you have come to the correct conclusion that this this happens when family/product id's are the same. Another thought I had is that since both my maps share the same family id and product id, could this be

Re: [mkgmap-dev] methods to write signed / unsigned integers

Hi Gerd, Ticker For ImgFileWriter I think we should just have put1(int), put2(int), put3(int) and put4(int) and remove put(byte), putChar(char) and putInt(int). So each method takes an int, so no casting is needed. There is no difference between writing unisigned and signed for any value

Re: [mkgmap-dev] --route and --transparent

On 15/02/18 11:04, Gerd Petermann wrote: 1) it sets the flag in the TRE field at offset 0x3f 2) it disables the additional 0x4b background polygons Maybe only the combination of both actions causes trouble in the PC programs? cgpsmapper had the option to do 2) without doing 1) which it calls

Re: [mkgmap-dev] Heureka!

Hi Gerd okay, so maybe we should set the bit for all maps which are not overview maps? Yes, I think so. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Heureka!

Hi Gerd I think I found the flag that has to be set to avoid the crash: The 1st bit at offset 0x3F in TRE must be 1, not 0. I've just looked at various maps. It seems that bit is always set in detail maps from Garmin and also cgpsmapper created maps regardless of whether it contains a DEM

Re: [mkgmap-dev] Strange error in mkgmap

Hi Andrzej The SRT determines the sort order of names in the MDR and also within the IMG file. So it seems to me that one is always required. I assumed that the MDR file was just a convenient place to put it. When you create a gmapsupp from a map with a MDR, there is only a single SRT file

Re: [mkgmap-dev] max-jobs patch

Hi Mike I could take out that bit of code, which is just determining how much physical memory is installed, so that mkgmap won't suggest that the user increases the available heap too much. It isn't used in determining a value for maxjobs. Since it is just used for an informational message,

Re: [mkgmap-dev] Strange error in mkgmap

Hi Franco a resulting bad map : bad_gmapsupp.img Just one tile less - no problem - good_gmapsupp.img Thanks for providing this useful test case. This is a bug in the recent

Re: [mkgmap-dev] order of subfiles in tdb and hasDem flag

Hi Here is a patch to order the entries in the TDB file the same way as in the .img file. ..Steve Index: src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8

Re: [mkgmap-dev] order of subfiles in tdb and hasDem flag

Hi Gerd I've noticed that mkgmap writes the sub files (DEM, TRE, NOD,... ) in a different order compared to the Garmin maps . Garman uses various different orders, we use the same order of sub files (in the .img) as maps available when mkgmap was started, including MetroGuide Europe and maps

Re: [mkgmap-dev] Commit r4106: Better detect errors in action command lists.

Hi Gerd you changed the lines file in the default style (removed lots of now obsolete semicolons) I did, I've reverted that part of the change. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] MapSource crash with DEM: Maybe tdb file needs changes?

Hi It seems that mkgmap writes some constants that might be important, e.g. MapDetailBlock.java contains //01 c3 00 ff os.write4(0xff00c301); os.write(0); os.write(0); os.write(0); I've just

Re: [mkgmap-dev] Error in style file relations?

Hi Gerd I did not understand the exact meaning of the error message Error in style: Error: (inc/compat_lines:124): Unrecognised command 'no' I guess there is some room for a better message there. The problem is that setaccess takes one argument, so that setaccess=no is really:

Re: [mkgmap-dev] Problem with an empty CodePage key in TYP.txt

Hi Bernd TYPwiz creates an empty key 'CodePage=' in my styles_typ.txt every time i had changed this file, this leads to an error message at the end of the build process. The error can be fixed in mkgmap and I've attached a patch to do so. I will commit this tomorrow as it is fairly

Re: [mkgmap-dev] Error in style file relations?

Hi Gerd line 124 is: mkgmap:carpool_compat=yes { setaccess=no; set mkgmap:bus=yes; set mkgmap:emergency=yes; set mkgmap:carpool=yes } I assume it should be mkgmap:carpool_compat=yes { setaccess no; set mkgmap:bus=yes; set mkgmap:emergency=yes; set mkgmap:carpool=yes } but maybe WanMil

Re: [mkgmap-dev] Error in style file relations?

Hi Here is a patch to fix the problem where commands that are not separated by a semi-colon are not ignored. Various possible errors are now caught instead of being silently ignored. In the original relation file that Gerd fixed, there was the following: $route=road & $network='e-road' {

Re: [mkgmap-dev] Build instructions

Hi Jeremy I maintain the mkgmap and splitter packages in the Arch Linux AUR. [1] [2] As far as I can tell, both of these applications require Java 8. For example, if splitter is executed with Java 7, it will throw a java.lang.UnsupportedClassVersionError. [3] Consequently, I've set both

Re: [mkgmap-dev] Error in style file relations?

Hi Sorry about the duplicate message. I'll take a look when I get home This problem can be fixed so that semicolons are not needed, I will produce a patch tomorrow. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Error in style file relations?

Hi Gerd I would have expected it to either work as if the semi colon was there, or give an error. I'll take a look when I get home Steve > >@Steve: I was a bit surprised that the wrong rule still sets network to >'e-road' and not to something like >"e-road add mkgmap:fast_road=yes" > >

Re: [mkgmap-dev] Error in style file relations?

Hi Gerd I would have expected it to either work as if the semi colon was there, or give an error. I'll take a look when I get home Steve > >@Steve: I was a bit surprised that the wrong rule still sets network to >'e-road' and not to something like >"e-road add mkgmap:fast_road=yes" > >

Re: [mkgmap-dev] gmapi reader?

Hi Gerd I'd like to merge first and do any optimisation later. OK, that's good. I've done a few tests reg. memory. I think we should not care much. It would be easy to free the resources allocated in DEMTile directly after the data was written. I think peak memory is reached when

Re: [mkgmap-dev] gmapi reader?

Hi Gerd Is this something that needs to be done before the merge? the DEM header structures are quite special, the headers of the sections are written at the very end of the DEM file, and they point to data that follows the main header. This is probably not mandantory but it's the way

Re: [mkgmap-dev] gmapi reader?

Hi Gerd A new fs sounds good to me, would be great if you could do that, I am always unsure where to call close(). OK Reg. FileCopier: I have to read the DEM file to make sure that it matches, I just If I didn't miss anything you just need to read the header to do the check. I would do

Re: [mkgmap-dev] gmapi reader?

Hi Gerd I would use a new implementation of FileSystem, named GmapFS or similar, which would go in package .imgfmt.sys Then add the trait FileSystem.openFS() which will return the correct ImgFS or GmapFS. Then your code would be roughly: fs = FileSystem.openFS(demReuseDir); // Will

Re: [mkgmap-dev] missing link

On 24/01/18 22:20, Steve Ratcliffe wrote: On 24/01/18 21:49, Gerd Petermann wrote: now I get a 502 (Bad gateway) forhttp://files.mkgmap.org.uk/ All should be normal again. Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http

Re: [mkgmap-dev] missing link

On 24/01/18 21:49, Gerd Petermann wrote: now I get a 502 (Bad gateway) forhttp://files.mkgmap.org.uk/ Thanks, working on it... ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] missing link

Hi Nick Just to say that clicking on 'mkgmap' gives me a 404 : http://files.mkgmap.org.uk/ Thanks, now fixed. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] documentation patch

Hi Just a note - I think the term mapset comes from Garmin but as far as I can tell they always spell it as two words "map set". For example in Mapsource (early versions at least) they use the term "Map Set Name". Also see https://buy.garmin.com/en-GB/GB/p/506564 which uses the term "map

Re: [mkgmap-dev] Automatic block-size setting

Hi Andrzej I have looked at block sizes and all is reasonable. Tiles are usually 2k or 4k, ovm_* are 512 or 1k, MDR are 8k or bigger. I guess you have set some preference for bigger blocks in case of MDR. I read your post where you noted that often bigger block sizes lead to a smaller file,

[mkgmap-dev] Automatic block-size setting

Hi The branch auto-block contains changes to automatically find a suitable value for the --block-size option. Previously the default block size was almost always OK, but with the DEM changes the tiles are larger and a larger block size is sometimes required. All kinds of .img file (tiles,

Re: [mkgmap-dev] DEM file and the block-size option

Hi Gerd @Steve: I see you are making progress in the auto-block branch. Please stop me if this patch causes trouble when merging. It is not a problem for me. It may be a while before the auto-block code is fully working and tested, so the patch will be useful in the mean time. ..Steve

Re: [mkgmap-dev] DEM file and the block-size option

Hi Andrzej - // There are 2 slots for the header itself. + // There are 2 slots for the header itself. (slots or blocks? code adds blocks) int blocksRequired = 2 + headerSlotsRequired * 512 / blockSize; It should be slots, the code is wrong. Also

Re: [mkgmap-dev] DEM file and the block-size option

Hi Gerd not sure what to do here. I agree that 2048 looks like a good default, at least for DEM tiles. I am looking at this. I am going to remove all the existing code that writes the FAT tables as that needs to the block size before you start. The new code will calculate the best block

Re: [mkgmap-dev] DEM file and the block-size option

Hi Gerd It would be a lot better and that is what happens for the gmapsupp file. I should be able to make the code work for all IMG files. Steve > >@Steve: >If I got that right we should be able to calculate the optimal >block-size >as we do know the number of bytes that we will write to the

Re: [mkgmap-dev] DEM size in Garmin Basemap > 16MB

On 22/12/17 16:44, Gerd Petermann wrote: @Steve: The value is coded in BufferedImgFileWriter: // The maximum allowed file size. private long maxAllowedSize = 0xff; True, and you can just use setMaxSize() if the limit doesn't apply for a particular file. Looks like you did

Re: [mkgmap-dev] a new DEM-File Option

Hi Gerd I hoped that Steve would jump on this;-) OK I shall give it a go. I've just added printing out the DEM entries in the TdbDisplay. Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Rule not working consistently

On 13/09/17 18:17, Felix Hartmann wrote: Anyone got any idea why the following rule is not working as expected? name:int!=* & ( name:en=* | int_name=* | name:fr=* | name_en=* | name_int=* | name:es=* | name:pt=* | name:de=* | name:it=* | name:nl=* | name:dk=* ) {set name:int='${name:en}' |

  1   2   3   4   5   6   7   8   9   10   >