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

[Steve Ratcliffe]

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 in extra/src/uk/me/parabola/util/CollationRules.java
to generate some of the tables.

This uses the file "allkeys.txt" which can be obtained
from https://www.unicode.org/Public/UCA/latest/allkeys.txt

The document explaining the unicode collation rules that references
that file is: http://www.unicode.org/reports/tr10/ It includes a
section for programmatically deriving the weights for characters that
do not have explicit entries in the table.

> Assuming the actual ordering of unspecified code-points doesn't really
> matter, I propose to change the logic slightly so undefined Unicode is
> sorted on its 16-bit value after the range of known sorts.

I think that is a good initial approach to get things working.

Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 could avoid changing the file base name if it is writing to
a different directory than the input file.

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Minor spelling bug

[Steve Ratcliffe]

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 time and could change this ? 😁


Hi Manfred

Thanks, this now fixed.

Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Fwd: Yet More Logging

[Steve Ratcliffe]

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



Hi Gerd,

Attached is a patch for CommandArgs that functions as you suggest.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 11 April 2021 16:58
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Yet More Logging



Hi Mike,



not sure about the changes in CommandArgs. I'd prefer an info message for
the new directory and exit with error if output-dir is not OK.

For me it's normal to remove the directory and let mkgmap create it. If that
fails for whatever reason mkgmap should just stop.

Rest looks good.



Gerd





Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgm
ap.org.uk>> im Auftrag von Mike Baggaley
mailto:m...@tvage.co.uk>>

Gesendet: Sonntag, 11. April 2021 17:44

An: 'Development list for mkgmap'

Betreff: [mkgmap-dev] Yet More Logging



Hi Gerd,



Here's the next patch. Hopefully should only need a couple more patches to

package up the remainder of the changes.



Cheers,

Mike





CommandArgs.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-...@www.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Please note when replying to messages

[Steve Ratcliffe]

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

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] remainder of logging changes

[Steve Ratcliffe]

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

So the tests that check for no stderr fail.

I can only suggest filtering out that line as in the attached patch.

Steve


Index: test/func/lib/Outputs.java
===
--- test/func/lib/Outputs.java	(revision 4656)
+++ test/func/lib/Outputs.java	(working copy)
@@ -16,6 +16,11 @@
  */
 package func.lib;
 
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
+import java.util.stream.Collectors;
+
 import static org.junit.Assert.*;
 
 /**
@@ -37,7 +42,9 @@
 	}
 
 	protected String getErr() {
-		return err;
+		return Arrays.stream(err.split("\n"))
+.filter(line -> !line.contains("_JAVA_OPTIONS"))
+.collect(Collectors.joining("\n"));
 	}
 
 	/**
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] remainder of logging changes

[Steve Ratcliffe]

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 to avoid that?

It doesn't work in Linux for the reasons you mentioned.  You can
probably just use "java" and it will work for both? (I can't test
on Windows at the moment).  The backslash doesn't work on Linux,
but I believe that forward slash will work on both.  If not, then you
can use File.separator.

I probably didn't build dist just because there was no need to, its
no big deal to add it, but you can avoid doing so by using
-classpath instead of -jar if you wish.

The following that works on Linux and I believe it would work on windows
too:

List args = new ArrayList<>(Arrays.asList(
"java",
"-classpath",
"build/classes" + File.pathSeparator + "lib/compile/*",
"uk.me.parabola.mkgmap.main.Main",
Args.TEST_STYLE_ARG
));
args.addAll(Arrays.asList(in));

> Do you think this is the right way to go? Doesn't it somehow bypass
> the junit stuff?  Would it help to move to JUnit 5?

I do not see anything wrong with doing it that way as long as it works
in all environments.

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] rules test

[Steve Ratcliffe]

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 want to work. I found a replacement
bit of code on the Internet, but as I can't compare the two outputs I can't
confirm its output is identical. Can you take a look at the attached patch
which does away with the dependency on javax and allows the tests to run
under the latest version of Eclipse?



So java 1.11 has removed all of the javax.* classes, so we need a 
replacement.


The patch is fine and gives the same results, but since we are
now using java 1.8 you can do this in one line like so:

   String s = String.format("%032x", new BigInteger(1, 
digest)).substring(0, 8);


[You can add '.toUpperCase(Locale.ROOT)' if you want to preserve the 
uppercase names which I don't think is important.]


Cheers,
Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 
code.
Maybe you forgot this change in 
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=233 ?


Yes that sounds right, the level should be set to SEVERE


In class MultiPolygonRelation we have quite a lot of methods which is meant to 
be skipped if logging is not enabled but because of this bug(?) the code is 
executed sometimes, maybe with side effects that I don't yet fully understand.


There shouldn't be any extra side effects, but it may be a little quicker.

Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Splitter download broken

[Steve Ratcliffe]

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
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Embedding raster maps

[Steve Ratcliffe]

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 to something else (I used 0x10101) do I see
anything.  As far as I know extended polygons work in mkgmap and
I just assumed that it is a reserved type for the images or something
similar.

> Probably it is still some missing encoding. In the Isle of Man map
> (and others) there is much more information in the RGN header. Note
> the values in the "filling bytes". And there seems to be an
> additional section after the extended point2 section. I called it
> offset1/length2.

mkgmap sets all of these to zero and seems to work.  Of course it may
not work for your purpose with the images.  I would try taking a
copy of a working map and zeroing out some of the unknown things
until it stops working. You will then know if something is essential
or not.

I have no ideas about what byte0x0025_0x0038 could be.  They
look like bitmaps or flags to me.

> Maybe one of you has an idea what it's about. I also uploaded my

I've had a go at displaying this section and I have uploaded
a sample to:
http://files.mkgmap.org.uk/detail/497

There is an initial part followed by two lists, the first has
five byte records and the second 4 bytes.  My guess is that
the first one is related to polygon types and the second
is some kind of index sorted by type or by zoom and/or division.

Presumably it points into the extended polygon section, but I do not
have anything that displays that section at the moment so I can't
yet match anything up.

The code I used is in the method RngDisplay::displayRgn5() in the 
display project.
(The particular file is at 
https://svn.mkgmap.org.uk/mkgmap/display/trunk/src/test/display/RgnDisplay.java)

This works with the files that are available to me, maybe not on
anything else :)

Cheers,
Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Embedding raster maps

[Steve Ratcliffe]

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

  http://files.mkgmap.org.uk/detail/495

This is also in the proper gmapsupp format unlike the previous one.


I made a minimum test.img, too. It contains no points, lines or areas. It has 3 
zoom levels 22..24 with a sub-division each. I also uploaded a log from my test 
decoder.



Maybe you can cross check if your device is willing to list them.


My etrex30 does not list either of them.

Re-packing the GMP file into a gmapsupp using mkgmap did not get it
listed either.

I believe that the byte at 0x40 is the start block of the FAT so in
test.img it should be 2.  Patching that byte did not make it load
though.

Cheers,
Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Embedding raster maps

[Steve Ratcliffe]

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
builder at r24.

However on my etrex 30 the map produced by r24 does not work.

The first one that does work is r79.  With a bit of experimenting
I discovered that adding a sufficiently large gap between the
end of the TRE header and the first data would make r78 work too.

Going back to r24 and adding more padding also produced a map that
was recognized.  I was able to remove the second copyright message
too and all map data.

The required gap was between 40 and 101, depending on the rest of
the code.

So this all makes very little sense and it is possible that this is
covering for something else that we don't understand.

I've uploaded the minimal IMG file at:
  http://files.mkgmap.org.uk/download/494/gmapsupp.img

(After this I also managed to remove the first copyright message, so
you do not need any copyright messages and the label section can be
empty)

With this version there is no message displayed on startup, which is
something that was fixed in r79 I think.

There is just a single zoom and subdivision in the TRE section and
no points, line or polygons.

Cheers,
Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap-r4589 download

[Steve Ratcliffe]

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
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Crash in NodCheck

[Steve Ratcliffe]

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.


Changing the check to be only on longitude does work out though, so I 
will change the NodCheck code to check that.


Sorting by latitude as well maybe harmless, unless there is another 
secondary sort that we don't know about.


Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Crash in NodCheck

[Steve Ratcliffe]

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 but the entries are 
variable size and there has to be a way to know when we have found the 
last one.


I think that flags==0 is the marker.  Have you seen any Garmin map with 
flags==0?


It seems to me that a node is either on the boundary or has arcs, or 
else it is not a routing node.


Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Crash in NodCheck

[Steve Ratcliffe]

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  there is only a single spare zero byte at the end of
the center.

> The code in mkgmap may write route nodes where both values are 0. If 
I got that right this happens when the node is (one of) the last nodes 
in a route center.


On the other hand I couldn't find any cases in my maps of flags being
0x00.  In fact none with the top nibble as 0.

> 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.
> Maybe the nodes in Garmin maps have a different order? For example, 
nodes with flags == 0 could come first?


Garmin maps appear to sorted by position - at least by longitude,
although maybe not latitude as mkgmap does.  It is possible that there
is some secondary sort condition that we have not found yet.

From what I've just found there seems to be some kind of sorting
on destclass.  The first center tends to be all destclass=0 and the
last one destclass=4.

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 omitted,
probably unintentionally.  This is what causes the failure in NodCheck
and maybe causes the failure on the device too.

The attached patch restores the functionality and NodCheck does not
crash on the result

There is a pre-compiled jar there: 
http://files.mkgmap.org.uk/download/484/mkgmap.jar


It may interact or interfere with the routing island removal code that
was also made in that branch.  I've no idea if it does or not, it is
just something to check.

Steve
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
diff --git a/trunk/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/trunk/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
--- a/trunk/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java	(revision 4555)
+++ b/trunk/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java	(working copy)
@@ -1499,6 +1499,13 @@
 	 */
 	private void addRoadAfterSplittingLoops(ConvertedWay cw) {
 		Way way = cw.getWay();
+		
+		if (routable) {
+			// make sure the way has nodes at each end
+			way.getPoints().get(0).incHighwayCount();
+			way.getPoints().get(way.getPoints().size() - 1).incHighwayCount();
+		}
+
 		// check if the way is a loop or intersects with itself
 
 		boolean wayWasSplit = true; // aka rescan required
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 causes the NodCheck utility to crash, I don't know why yet.

I've put all precompiled jar files at: http://www.mkgmap.org.uk/jars/

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

[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 typ-compiler.txt

[html is the default so there is no need for the -t]

If you want to check the exact same look as the website, then you can
include the css file from the website by replacing the html header of
the result down to the first  with:





	href="http://www.mkgmap.org.uk/static/css/bundle.css";>








The text should now be identical at all browser widths

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

[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

[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 local copy.

The bug has probably existed since Oct 2016. The fix is trivial (not
closing the output, as you may have guessed by the fact that the sizes
are 4k block sizes) but I need to rename everything.  I'll reply again once
it is all sorted out.

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

[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 commands locally gives me a 
typ-compiler.txt of size 15402 which looks correct, and tuning.txt is ok 
too.


> Also, what are the tools used to build the .txt and html versions of
> these files.

The documentation is created by running the script:

scripts/download/mkdoc

To successfully run the script you first need to install asciidoc 
(https://asciidoc.org/) and fop (https://xmlgraphics.apache.org/fop/).


The following python packages are also required:

mwtext mkgmap-pygments pygments-xslfo-formatter


In case it matters the actual versions in use are:

	fop 1.1: 
http://mirror.ox.ac.uk/sites/rsync.apache.org/xmlgraphics/fop/binaries/fop-1.1-bin.tar.gz


asciidoc is https://asciidoc.googlecode.com/hg/#7c0bc8eacba9 but that
url no longer exists.

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Splitter Build Failure

[Steve Ratcliffe]

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 directory with a clean checkout 
>of spliter and mkgmap and both builds worked. A few minutes ago it didn't.
>Maybe Steve has already fixed something. I've never cared much about the ivy 
>stuff.
>
>Gerd
>
>
>Von: mkgmap-dev  im Auftrag von DD8KQ 
>
>Gesendet: Donnerstag, 30. Januar 2020 14:44
>An: Development list for mkgmap; News
>Betreff: Re: [mkgmap-dev] Splitter Build Failure
>
>I have a short look to your failures. For me, it looks like you have to
>change the url-requests form http to https. But i don't know, where you
>have to change it. 'repo1.maven.org' don't want to communicate with
>unsecure http anymore.
>
>Am 30.01.2020 um 14:04 schrieb News:
>> Hi Gerd
>>
>> Sorry. This still fails. Full info below
>>
>> [ivy:configure] impossible to define new type: class not found:
>> org.apache.ivy.plugins.signer.bouncycastle.OpenPGPSignatureGenerator
>> in [] nor Ivy classloader
>> [ivy:configure] :: Apache Ivy 2.3.0-local-2017090712 -
>> 2017090712 :: http://ant.apache.org/ivy/ ::
>> [ivy:configure] :: loading settings :: file =
>> /home/miscellaneous/Maps/tile-splitter/splitter/ivysettings.xml
>>
>> resolve-compile:
>> [ivy:retrieve]
>> [ivy:retrieve] :: problems summary ::
>> [ivy:retrieve]  WARNINGS
>> [ivy:retrieve]  module not found: xpp3#xpp3;1.1.4c
>> [ivy:retrieve]   local: tried
>> [ivy:retrieve] /home/user/.ivy2/local/xpp3/xpp3/1.1.4c/ivys/ivy.xml
>> [ivy:retrieve]    -- artifact xpp3#xpp3;1.1.4c!xpp3.jar:
>> [ivy:retrieve] /home/user/.ivy2/local/xpp3/xpp3/1.1.4c/jars/xpp3.jar
>> [ivy:retrieve]   shared: tried
>> [ivy:retrieve] /home/user/.ivy2/shared/xpp3/xpp3/1.1.4c/ivys/ivy.xml
>> [ivy:retrieve]    -- artifact xpp3#xpp3;1.1.4c!xpp3.jar:
>> [ivy:retrieve] /home/user/.ivy2/shared/xpp3/xpp3/1.1.4c/jars/xpp3.jar
>> [ivy:retrieve]   public: tried
>> [ivy:retrieve]
>> http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.pom
>> [ivy:retrieve]    -- artifact xpp3#xpp3;1.1.4c!xpp3.jar:
>> [ivy:retrieve]
>> http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.jar
>> [ivy:retrieve]   mkgmap: tried
>> [ivy:retrieve]
>> http://ivy.mkgmap.org.uk/repo/xpp3/xpp3/1.1.4c/ivys/ivy.xml
>> [ivy:retrieve]    -- artifact xpp3#xpp3;1.1.4c!xpp3.jar:
>> [ivy:retrieve]
>> http://ivy.mkgmap.org.uk/repo/xpp3/xpp3/1.1.4c/jars/xpp3.jar
>> [ivy:retrieve] ::
>> [ivy:retrieve]  ::  UNRESOLVED DEPENDENCIES ::
>> [ivy:retrieve] ::
>> [ivy:retrieve]  :: xpp3#xpp3;1.1.4c: not found
>> [ivy:retrieve] ::
>> [ivy:retrieve]  ERRORS
>> [ivy:retrieve]  SERVER ERROR: HTTPS Required
>> url=http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.pom
>> [ivy:retrieve]  SERVER ERROR: HTTPS Required
>> url=http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.jar
>> [ivy:retrieve]
>> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
>>
>> BUILD FAILED
>> /home/miscellaneous/Maps/tile-splitter/splitter/build.xml:113:
>> impossible to resolve dependencies:
>> resolve failed - see output for details
>>
>> Thanks
>>
>> Paul
>>
>> On 30/01/2020 13:10, Gerd Petermann wrote:
>>> Hi Paul,
>>>
>>> please update, see
>>> http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&rev=596
>>>
>>> Gerd
>>>
>>> 
>>> Von: mkgmap-dev  im Auftrag
>>> von News 
>>> Gesendet: Donnerstag, 30. Januar 2020 13:05
>>> An: 'Development list for mkgmap'
>>> Betreff: [mkgmap-dev] Splitter Build Failure
>>>
>>> I recently clean reinstalled my PC (openSuSE Leap 15.1) and today was
>>> the first time I tried to build splitter and received the following
>>> errors
>>>
>>> BUILD FAILED
>>> /home/miscellaneous/Maps/tile-splitter/splitter/build.xml:95: Can't get
>>> http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.2.0/ivy-2.2.0.jar to
>>> /home/miscellaneous/Maps/tile-splitter/splitter/lib/build/ivy-2.2.0.jar
>>>
>>> I changed the line in build.xml to use https instead of http and I then
>>> got past this error and received the following error snippet
>>>
>>> [ivy:retrieve] ::
>>> [ivy:retrieve]  ::  UNRESOLVED DEPENDENCIES ::
>>> [ivy:retrieve] ::
>>> [ivy:retrieve]  :: xpp3#xpp3;1.1.4c: not found
>>> [ivy:retrieve] ::
>>> [ivy:retrieve]  ERRORS
>>> [ivy:retrieve]  SERVER ERROR: HTTPS Required
>>> url=http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.pom
>>> [ivy:retrieve]  S

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

[Steve Ratcliffe]

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
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] typfile curiosity

[Steve Ratcliffe]

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 line, i.e Type = 0x10802. Its not for all of the ids,
may be only for points with ids > 0x100. Any idea ?


When a type is written as 0x10802 it doesn't mean that the type is
0x108, since types are one byte.  The first '1' means that it is
an extended (also called marine) type, with type=0x8 and subtype=0x2.

When you write Type=0x102 then that means Type=0x1, SubType=0x02, just
as Type=0x411 means Type=0x4, SubType=0x11

The original way of writing it would be:

Type=0x08
SubType=0x02
Marine=Y

The Marine=Y isn't supported in the TYP compiler, since I don't think
anyone write TYP files using that notation.  It could be added if
there really are lots of TYP files out there using it.

I'd recomend always using the single line form.

Steve


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 the POI
allocated for a group are in the same order as the groups, so, if you
actually have a POI of type 0x28 then, because it has a lower type but
a higher group than the 0x2a..30 range/groups, mdr9 is wrong.


I don't see where that happens but that would be wrong and mdr9
should be ordered by group.

Cheers
Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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: src/uk/me/parabola/imgfmt/app/srt/Sort.java
===
--- src/uk/me/parabola/imgfmt/app/srt/Sort.java	(revision 4285)
+++ src/uk/me/parabola/imgfmt/app/srt/Sort.java	(working copy)
@@ -135,7 +135,7 @@
 			for (int i = 0; i < 256; i++) {
 if (((p.flags[i] >>> 4) & 0xf) == 0) {
 	if (p.getPrimary(i) != 0) {
-		byte second = p.getSecondary(i);
+		int second = p.getSecondary(i);
 		maxSecondary = Math.max(maxSecondary, second);
 		if (second != 0) {
 			maxTertiary = Math.max(maxTertiary, p.getTertiary(i));
@@ -361,7 +361,7 @@
 		// We need +1 for the null bytes, we also +2 for a couple of expanded characters. For a complete
 		// german map this was always enough in tests.
 		byte[] key = new byte[(chars.length + 1 + 2) * 4];
-		int needed = 0;
+		int needed;
 		try {
 			needed = fillCompleteKey(chars, key);
 		} catch (ArrayIndexOutOfBoundsException e) {
@@ -597,7 +597,7 @@
 
 	/**
 	 * Allocate space for up to n pages.
-	 * @param n
+	 * @param n Number of pages
 	 */
 	public void setMaxPage(int n) {
 		pages = Arrays.copyOf(pages, n + 1);
@@ -634,8 +634,8 @@
 			primary[ch & 0xff] = (char) val;
 		}
 
-		byte getSecondary(int ch) {
-			return secondary[ch & 0xff];
+		int getSecondary(int ch) {
+			return secondary[ch & 0xff] & 0xff;
 		}
 
 		void setSecondary(int ch, int val) {
@@ -642,8 +642,8 @@
 			secondary[ch & 0xff] = (byte) val;
 		}
 
-		byte getTertiary(int ch) {
-			return tertiary[ch & 0xff];
+		int getTertiary(int ch) {
+			return tertiary[ch & 0xff] & 0xff;
 		}
 
 		void setTertiary(int ch, int val) {
@@ -850,7 +850,7 @@
 		}
 
 		// Get the first non-ignorable at this level
-		int c = chars[(pos++ & 0xff)];
+		int c = chars[pos++ & 0xff];
 		if (!hasPage(c >>> 8)) {
 			next = 0;
 			continue;
Index: resources/sort/cp1255.txt
===
--- resources/sort/cp1255.txt	(revision 4285)
+++ resources/sort/cp1255.txt	(working copy)
@@ -5,7 +5,8 @@
 
 characters
 
-=0008=000e=000f=0010=0011=0012=0013=0014=0015=0016=0017=0018=0019=001a=001b=001c=001d=001e=001f=007f=00ad=05bd=200e=200f,0001,0002,0003,0004,0005,0006,0007 ; 05b0 ; 05b1 ; 05b2 ; 05b3 ; 05b4 ; 05b5 ; 05b6 ; 05b7 ; 05b8 ; 05b9 ; 05bb ; 05c2 ; 05c1 ; 05bc ; 05bf
+=0008=000e=000f=0010=0011=0012=0013=0014=0015=0016=0017=0018=0019=001a=001b=001c=001d=001e=001f=007f=00ad=05bd=200e=200f,0001,0002,0003,0004,0005,0006,0007 
+ < 05b0 ; 05b1 ; 05b2 ; 05b3 ; 05b4 ; 05b5 ; 05b6 ; 05b7 ; 05b8 ; 05b9 ; 05bb ; 05c2 ; 05c1 ; 05bc ; 05bf
  < 0009
  < 000a
  < 000b
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
>
>
>Von: mkgmap-dev  im Auftrag von
>Ticker Berkin 
>Gesendet: Montag, 8. April 2019 12:38
>An: Development list for mkgmap
>Betreff: Re: [mkgmap-dev] Building map with Hebrew characters
>
>Hi Gerd and Nick
>
>@nick, when you say it works on 4143 but not on 4179, did you test code
>-page=1255 on 4143, or just unicode?
>
>It looks like there are 2 problems.
>
>The --unicode assertion error is a 'byte' to 'int' sign-extension
>problem, introduced in r4167 or r4168 and I've attached a patch that
>fixes this and also removes some other confusing/obscuring type
>representation changes in this area of the code.
>
>The patch also has 4 commented out (because not appropriate for -
>-unicode) asserts that seem to point to the Hebrew/1255 problem being
>in imgfmt/app/srt/Sort.java:finish():
>
>$ java -ea -jar /mkgmap/mkgmap.jar --code-page=1255 --gmapsupp test
>-map:all-elements
>
>Time started: Mon Apr 08 09:30:06 BST 2019
>Exception in thread "main" java.lang.AssertionError: 16
>at
>uk.me.parabola.imgfmt.app.srt.Sort$Page.setSecondary(Sort.java:642)
>at uk.me.parabola.imgfmt.app.srt.Sort.finish(Sort.java:161)
>at
>uk.me.parabola.mkgmap.srt.SrtTextReader.read(SrtTextReader.java:182)
>at
>uk.me.parabola.mkgmap.srt.SrtTextReader.(SrtTextReader.java:117)
>at
>uk.me.parabola.mkgmap.srt.SrtTextReader.(SrtTextReader.java:106)
>at
>uk.me.parabola.mkgmap.srt.SrtTextReader.sortForCodepage(SrtTextReader.j
>ava:141)
>at uk.me.parabola.mkgmap.main.Main.getSort(Main.java:764)
>at
>uk.me.parabola.mkgmap.main.Main.processFilename(Main.java:283)
>at
>uk.me.parabola.mkgmap.CommandArgsReader$Filename.processArg(CommandArgs
>Reader.java:272)
>at
>uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java
>:125)
>at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143)
>at uk.me.parabola.mkgmap.main.Main.main(Main.java:114)
>
>this is corresponds to:
>} else {
>
>p.setSecondary(i,
>p.getSecondary(i) + maxSecondary);
>
>   }
>
>where this increase in the secondary value is governed by some bits in
>the pages.flags and the flags testing was changed in r3968, along with
>the introduction of the original assert that was failing
>(SRTFile.java:117) and quite a few other changes in srt.
>
>@gerd, I'm afraid I don't understand the srt logic so can you have a
>look at it
>
>Regards
>Ticker
>
>On Sat, 2019-04-06 at 08:16 +, Gerd Petermann wrote:
>> Hi,
>> maybe a regression from r4167?
>> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4167
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev  im Auftrag
>> von osm@pinns 
>> Gesendet: Samstag, 6. April 2019 10:01
>> An: mkgmap-dev@lists.mkgmap.org.uk
>> Betreff: Re: [mkgmap-dev] Building map with Hebrew characters
>>
>> Have done some checking using older versions
>>
>> It works on 4143 but not on 4179
>>
>> I'm afraid I don't have anything in between
>>
>> r
>>
>> Nick
>>
>> On 05/04/2019 21:25, Carlos Dávila wrote:
>> > I'm trying to build a map of Israel with Hebrew characters, but
>> > using
>> > --code-page=1255 a get the following assertion:
>> >
>> > at
>> > uk.me.parabola.imgfmt.app.srt.SRTFile.writeWeights(SRTFile.java:117
>> > )
>> > at
>> > uk.me.parabola.imgfmt.app.srt.SRTFile.writeSrt4Chars(SRTFile.java:9
>> > 9)
>> > at
>> > uk.me.parabola.imgfmt.app.srt.SRTFile.write(SRTFile.java:63)
>> > at
>> > uk.me.parabola.mkgmap.combiners.MdrBuilder.init(MdrBuilder.java:117
>> > )
>> > at
>> > uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:605)
>> > at
>> > uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.
>> > java:128)
>> > at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143)
>> > at uk.me.parabola.mkgmap.main.Main.main(Main.java:114)
>> >
>> > With --unicode I also get an assertion:
>> > Exception in thread "main" java.lang.AssertionError: -125
>> > at
>> > uk.me.parabola.imgfmt.app.BufferedImgFileWriter.put1u(BufferedImgFi
>> > leWriter.java:154)
>> > at
>> > uk.me.parabola.imgfmt.app.SectionWriter.put1u(SectionWriter.java:78
>> > )
>> > at
>> > uk.me.parabola.imgfmt.app.srt.SRTFile.writeWeights(SRTFile.java:113
>> > )
>> > at
>> > uk.me.parabola.imgfmt.app.srt.SRTFile.writeSrt8(SRTFile.java:166)
>> > at
>> > uk.me.parabola.imgfmt.app.srt.SRTFile.write(SRTFile.java:68)
>> > at
>> > uk.me.parabola.mkgmap.combiners.MdrBuilder.init(MdrBuilder.java:117
>> > )
>> > at
>> > uk.me.parabola.mkgmap.main.Main.endOptions(Mai

Re: [mkgmap-dev] Fail automatic builds ?

[Steve Ratcliffe]

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 package in the 
dependencies.


This only affects the tests.  The new jar file is not included in the
normal builds.

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 to change so that a code-page in the file overrides
the command line option, instead of the other way round.

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 a different code-page to the map tiles?


Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 (railway=*) then
  if (tunnel=no) then
railway=rail  [0x14 resolution 21]
() { set tunnel = yes }
railway=tram  [0x15 resolution 21]
  end
end

This is converted (correctly) to:

$tunnel=no {set mkgmap:if:2='true';}
$tunnel=no & $railway=rail & $railway=* [0x14 level 2]
$tunnel=no & $railway=* {set tunnel='yes';}
$mkgmap:if:2=true & $railway=tram & $railway=* [0x15 level 2]

But with tunnel!=no instead, this becomes:

$tunnel!=no {set mkgmap:if:2='true';}
$tunnel!=no & $railway=rail & $railway=* [0x14 level 2]
$tunnel!=no & $railway=* {set tunnel='yes';}
$mkgmap:if:2=true & $railway=tram & $railway=* [0x15 level 2]

and so fails on the first statement.

The only way to fix this that springs to mind is to instead convert
this to:

railway=* && $tunnel!=no {set mkgmap:if:2='true';}
$tunnel!=no & $railway=rail & $railway=* [0x14 level 2]
$tunnel!=no & $railway=* {set tunnel='yes';}
$mkgmap:if:2=true & $railway=tram [0x15 level 2]

Steve


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 wants to experiment then please go ahead, it could be that I
am wrong and it can be done reasonably quickly.

As things are however, it is intentional that the rules you are trying
do not work.


Line:  ( highway!=* | oneway!=*) { deletealltags }


This would match a way with no tags, so is not allowed.

Similar error is given when comparing expression with this line: 
oneway!=* { deletealltags }


This too.

Tt seems != works fine but only if there is an equal comparision first 
like in this line that gives no error:

   highway=* & oneway !=* { deletealltags }


Adding the highway=*, means that it could not match a way without tags, 
and is therefore allowed.


Cheers
Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
===
--- src/uk/me/parabola/mkgmap/main/TypCompiler.java	(revision 4251)
+++ src/uk/me/parabola/mkgmap/main/TypCompiler.java	(date 1542135591000)
@@ -26,6 +26,7 @@
 import java.nio.charset.CharacterCodingException;
 import java.nio.charset.Charset;
 import java.nio.charset.CharsetEncoder;
+import java.nio.charset.StandardCharsets;
 import java.nio.file.StandardOpenOption;
 
 import uk.me.parabola.imgfmt.ExitException;
@@ -211,8 +212,13 @@
 		}
 
 		private void setCodePage(String codePage) {
-			this.codePage = codePage;
-			this.encoder = Charset.forName(codePage).newEncoder();
+			if ("cp65001".equalsIgnoreCase(codePage)) {
+this.codePage = "utf-8";
+this.encoder = StandardCharsets.UTF_8.newEncoder();
+			} else {
+this.codePage = codePage;
+this.encoder = Charset.forName(codePage).newEncoder();
+			}
 		}
 
 		private String probeCharset(String file) {
Index: src/uk/me/parabola/mkgmap/typ/LineSection.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/typ/LineSection.java	(revision 4251)
+++ src/uk/me/parabola/mkgmap/typ/LineSection.java	(date 1542116445000)
@@ -12,6 +12,7 @@
  */
 package uk.me.parabola.mkgmap.typ;
 
+import uk.me.parabola.imgfmt.app.typ.ColourInfo;
 import uk.me.parabola.imgfmt.app.typ.TypData;
 import uk.me.parabola.imgfmt.app.typ.TypLine;
 import uk.me.parabola.mkgmap.scan.SyntaxException;
@@ -62,4 +63,14 @@
 		current.finish();
 		data.addLine(current);
 	}
+
+	protected void xpmCheck(TokenScanner scanner, ColourInfo colourInfo) {
+		int width = colourInfo.getWidth();
+
+		if (width == 0)
+			return;
+
+		if (width != 32)
+			throw new SyntaxException(scanner, "Line bitmaps must be 32 bits wide");
+	}
 }
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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: src/uk/me/parabola/mkgmap/typ/LineSection.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/typ/LineSection.java	(revision 4251)
+++ src/uk/me/parabola/mkgmap/typ/LineSection.java	(date 1542116445000)
@@ -12,6 +12,7 @@
  */
 package uk.me.parabola.mkgmap.typ;
 
+import uk.me.parabola.imgfmt.app.typ.ColourInfo;
 import uk.me.parabola.imgfmt.app.typ.TypData;
 import uk.me.parabola.imgfmt.app.typ.TypLine;
 import uk.me.parabola.mkgmap.scan.SyntaxException;
@@ -62,4 +63,14 @@
 		current.finish();
 		data.addLine(current);
 	}
+
+	protected void xpmCheck(TokenScanner scanner, ColourInfo colourInfo) {
+		int width = colourInfo.getWidth();
+
+		if (width == 0)
+			return;
+
+		if (width != 32)
+			throw new SyntaxException(scanner, "Line bitmaps must be 32 bits wide");
+	}
 }
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] TYP compiler problems

[Steve Ratcliffe]

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


The troublesome polygon is this one:


[_polygon]
Type=0x58
; crashes with: String=County
; corruption with:
String=Countyx
Xpm="16 16 2 1"
". c none"
"1 c #FF"
""
""
 [ ... ]


It has a size of 16x16, but polygon bitmaps must be 32x32.

Although documented (at http://www.mkgmap.org.uk/doc/typ-compiler),
this restriction is not checked by the code, sorry about that.

I've attached a patch to check this.  There are other possible
checks so this may be expanded before committing.

Steve
Index: src/uk/me/parabola/imgfmt/app/typ/ColourInfo.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/imgfmt/app/typ/ColourInfo.java	(revision 4248)
+++ src/uk/me/parabola/imgfmt/app/typ/ColourInfo.java	(date 1541776316000)
@@ -282,7 +282,7 @@
 			// in each of the day/night sections.
 
 			if (numberOfColours > 4)
-return ("Too many colours for a line or polygon");
+return "Too many colours for a line or polygon";
 			if (numberOfColours == 0)
 return "Line or polygon cannot have zero colours";
 
Index: src/uk/me/parabola/mkgmap/typ/CommonSection.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/typ/CommonSection.java	(revision 4248)
+++ src/uk/me/parabola/mkgmap/typ/CommonSection.java	(date 1541777584000)
@@ -369,6 +369,8 @@
 	 */
 	protected Xpm readXpm(TokenScanner scanner, String header, boolean simple) {
 		ColourInfo colourInfo = readColourInfo(scanner, header);
+		xpmCheck(scanner, colourInfo);
+
 		String msg = colourInfo.analyseColours(simple);
 		if (msg != null)
 			throw new SyntaxException(scanner, msg);
@@ -404,4 +406,12 @@
 		if (!hasXpm)
 			throw new SyntaxException(scanner, "No XPM tag in section");
 	}
+
+	/**
+	 * Check the colourInfo against any restrictions that apply to the element type.
+	 *
+	 * Subtypes make checks as appropriate, there are no common restrictions.
+	 */
+	protected void xpmCheck(TokenScanner scanner, ColourInfo colourInfo) {
+	}
 }
Index: src/uk/me/parabola/mkgmap/typ/PolygonSection.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/typ/PolygonSection.java	(revision 4248)
+++ src/uk/me/parabola/mkgmap/typ/PolygonSection.java	(date 154177741)
@@ -12,8 +12,10 @@
  */
 package uk.me.parabola.mkgmap.typ;
 
+import uk.me.parabola.imgfmt.app.typ.ColourInfo;
 import uk.me.parabola.imgfmt.app.typ.TypData;
 import uk.me.parabola.imgfmt.app.typ.TypPolygon;
+import uk.me.parabola.mkgmap.scan.SyntaxException;
 import uk.me.parabola.mkgmap.scan.TokenScanner;
 
 /**
@@ -45,4 +47,30 @@
 		validate(scanner);
 		data.addPolygon(current);
 	}
+
+	/**
+	 * Check xmp restrictions for polygons.
+	 *
+	 * The main one is that bitmaps must be 32x32.  Only certain numbers of colours are
+	 * allowed as well.
+	 */
+	protected void xpmCheck(TokenScanner scanner, ColourInfo colourInfo) {
+		int width = colourInfo.getWidth();
+		int height = colourInfo.getHeight();
+
+		switch (colourInfo.getNumberOfColours()) {
+		case 1:
+		case 2:
+		case 4:
+			break;
+		default:
+			throw new SyntaxException(scanner, "Polygons must have 1, 2 or 4 colours");
+		}
+
+		if (width == 0 && height == 0)
+			return;
+
+		if (height != 32 || width != 32)
+			throw new SyntaxException(scanner, "Polygon bitmaps must be 32x32");
+	}
 }
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 and 0x52 with subtype 0x00
are different to Garmin devices.  Although I believed that they were
the same, or that a sub-type of zero was not allowed or useful when I
wrote the code, perhaps incorrectly.

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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

..Steve

In other words, if sub types were given a value >1f then  typ files are 
unable to give accurate draworders for types with the same draworder.


Extra pois (as found in city navitgator & NT maps) do not have this 
restriction and and can have a 4byte value.


HTH

Nick



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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, everything in the first
table with type 0x00 at
https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types should
be regarded as having a type with no subtype.  So column "Sub-type" in
that table is better thought of as being the type and 0xYY can be
written as 0xYY00.

So you can write 0x5200 instead of 0x0052.  They (should) mean exactly
the same thing to mkgmap.  Removing the check allows both to be used
and give the same results.

I'm not sure what the correct check is, perhaps:

if (type >= 0x100) {
// This a type and sub-type. Check max sub-type of 0x2f (or 1f?)
if ((type & 0xff) > 0x2f)
return false;
} else if (type > 0x7f) {
// But, perhaps all types are allowed and this
// is not needed?
return false;
}

Best wishes,
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 with a hex-editor i really saw, that all
data is stored twice after another. See the attached files. The file
mystyle-new.typ is the result of the compilation, the files "first half"
and "second half" are the result of my separation of the mystyle-new.typ
file with a hex editor.

Any thoughts ?



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



Index: src/uk/me/parabola/imgfmt/app/ImgFile.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/imgfmt/app/ImgFile.java	(revision 4233)
+++ src/uk/me/parabola/imgfmt/app/ImgFile.java	(date 1535029457000)
@@ -41,11 +41,6 @@
 	private boolean writable;
 
 	public void close() {
-		try {
-			sync();
-		} catch (IOException e) {
-			log.debug("could not sync file");
-		}
 		Utils.closeFile(writer);
 		Utils.closeFile(reader);
 	}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 useful just delete it.use.

NodConvert is from 2008/9. When we improved routing in 2014 I used
the test.svg.nod program to visualise the routing network.  That is far
more complete and useful.

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 we access the index.
We only gain a smaller set of rules but we would still evaluate the same amount 
of rules.


Yes, fair enough.  It works well as it is.

Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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


So in the following, rules 2 and 4 can never match with a=1.

0: a=* {set b='${something}'}
1: b=2 {set c=2} [0x1]
2: c=* {set a=2}
3: c=1 {set d=2}
4: c=2 {set d=1}
5: d=1 [0x10401 resolution 24]
6: d=2 [0x10402 resolution 24]
7: b=1 [0x2]

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 the b=1 rule, but it is still tried anyway.
In this case changeableTags contains the full b=2 keystring
so it ought to be possible to recognise that the
second rule cannot match.

..Steve


I see no simple way to improve the index much more. I thought about a different 
approach:
Instead of doing all the calculations before any rule is really executed we 
might do this dynamically.
Each rule which changes or adds tags would point to a list of further rules 
which are to be checked. Only when such
a change really happens the additional rules are checked.
No idea if this can be implemented more efficiently than the current static 
index.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 noticed that the 
unpatched version often returns far more rules to check than expected.
e.g. if an element has the tag a=3 and we have these 3 rules
a=1 {...}
a=2 & b=1 {...}
a=3 & c=1 {...}

all three are evaluated, in fact all rules which have a keystring beginning 
with a= are returned by the index. The patch changes this so that rules which 
cannot match are not
returned. This makes style evaluation a bit faster.  I've tried it with a few 
styles and some input files and found no changes in the output, also all unit 
tests pass, so I hope I did not miss something.  What do you think?

Gerd



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



Index: src/uk/me/parabola/mkgmap/osmstyle/RuleIndex.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/osmstyle/RuleIndex.java	(revision 4175)
+++ src/uk/me/parabola/mkgmap/osmstyle/RuleIndex.java	(date 152460368)
@@ -171,6 +171,8 @@
 		// Maps a rule number to the tags that might be changed by that rule
 		Map> changeTags = new HashMap>();
 		
+		Set possiblyChangedOrAdded = new HashSet<>();
+		
 		// remove unnecessary rules
 		filterRules();
 		
@@ -185,13 +187,13 @@
 addNumberToMap(tagnames, key, ruleNumber);
 			} else {
 addNumberToMap(tagVals, keystring, ruleNumber);
-int ind = keystring.indexOf('=');
-if (ind >= 0) {
-	String key = keystring.substring(0, ind);
-	addNumberToMap(tagnames, key, ruleNumber);
-} 
+if (possiblyChangedOrAdded.contains(keystring)) {
+	int ind = keystring.indexOf('=');
+	addNumberToMap(tagnames, keystring.substring(0, ind), ruleNumber);
+}
 			}
 			addChangables(changeTags, changeableTags, ruleNumber);
+			possiblyChangedOrAdded.addAll(changeableTags);
 		}
 		
 		for (Map.Entry> ent : changeTags.entrySet()) {
@@ -358,6 +360,8 @@
 	 * @param ruleNumber The rule number.
 	 */
 	private static void addChangables(Map> changeTags, Set changeableTags, int ruleNumber) {
+		if(changeableTags.isEmpty())
+			return;
 		List tags = changeTags.get(ruleNumber);
 		if (tags == null) {
 			tags = new ArrayList();
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 some really big maps.

I think we should remove the commented out code and I noticed
a few unneeded casts remaining (some maybe not actually as a result
of the patch), and some javadoc errors.

I've attached an incremental patch of the things I did, which
you can take or leave as you wish.

Lets get it committed.

Its a big patch, thanks for going through all the cases and
completing it.

Steve
diff -r eebe2c5e70b3 src/uk/me/parabola/imgfmt/app/BufferedImgFileReader.java
--- a/src/uk/me/parabola/imgfmt/app/BufferedImgFileReader.java	Tue Apr 17 22:22:25 2018 +0100
+++ b/src/uk/me/parabola/imgfmt/app/BufferedImgFileReader.java	Tue Apr 17 22:26:11 2018 +0100
@@ -104,7 +104,7 @@
 	 * @return int sign-extended value that was read.
 	 */
 	public int get1s() throws ReadFailedException {
-		return (int)get();
+		return get();
 	}
 
 	/**
diff -r eebe2c5e70b3 src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java
--- a/src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java	Tue Apr 17 22:22:25 2018 +0100
+++ b/src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java	Tue Apr 17 22:26:11 2018 +0100
@@ -107,7 +107,7 @@
 	/**
 	 * Write out a single byte.
  	 * Should not be used for writing numbers, use put1s/u instead.
-	 * %%% temporary
+	 *
 	 * @param b The byte to write.
 	 */
 	public void put(byte b) {
@@ -137,7 +137,7 @@
 
 	/**
 	 * Write out int in range -0x80..0x7f in little endian byte order.
-	 * @param int The value to write.
+	 * @param val The value to write.
 	 */
 	public void put3s(int val) {
 		assert val >= -0x80 && val <= 0x7f : val;
diff -r eebe2c5e70b3 src/uk/me/parabola/imgfmt/app/FileBackedImgFileWriter.java
--- a/src/uk/me/parabola/imgfmt/app/FileBackedImgFileWriter.java	Tue Apr 17 22:22:25 2018 +0100
+++ b/src/uk/me/parabola/imgfmt/app/FileBackedImgFileWriter.java	Tue Apr 17 22:26:11 2018 +0100
@@ -105,7 +105,7 @@
 
 	/**
 	 * Write out a single byte.
-	 * %%% temporary
+	 *
 	 * @param b The byte to write.
 	 */
 	public void put(byte b) {
@@ -145,7 +145,7 @@
 
 	/**
 	 * Write out int in range -0x80..0x7f in little endian byte order.
-	 * @param int The value to write.
+	 * @param val The value to write.
 	 */
 	public void put3s(int val) {
 		assert val >= -0x80 && val <= 0x7f : val;
diff -r eebe2c5e70b3 src/uk/me/parabola/imgfmt/app/ImgFileReader.java
--- a/src/uk/me/parabola/imgfmt/app/ImgFileReader.java	Tue Apr 17 22:22:25 2018 +0100
+++ b/src/uk/me/parabola/imgfmt/app/ImgFileReader.java	Tue Apr 17 22:26:11 2018 +0100
@@ -67,19 +67,12 @@
 	 */
 	public int get3s() throws ReadFailedException;
 
-// don't think needed:
-//	public int getNs(int nBytes) throws ReadFailedException;
-
 	public int get1u() throws ReadFailedException;
 
 	public int get2u() throws ReadFailedException;
 
 	public int get3u() throws ReadFailedException;
 
-//	public default long get4u() throws ReadFailedException {
-//		return get4() & 0x_L;
-//	}
-
 	/**
 	 * Read a variable sized integer.  The size is given.
 	 * @param nBytes The size of the integer to read. Must be 1 to 4.
diff -r eebe2c5e70b3 src/uk/me/parabola/imgfmt/app/ImgFileWriter.java
--- a/src/uk/me/parabola/imgfmt/app/ImgFileWriter.java	Tue Apr 17 22:22:25 2018 +0100
+++ b/src/uk/me/parabola/imgfmt/app/ImgFileWriter.java	Tue Apr 17 22:26:11 2018 +0100
@@ -53,7 +53,7 @@
 
 	/**
 	 * Write out a single byte.
-	 * %%% temporary
+	 *
 	 * @param b The byte to write.
 	 */
 	public void put(byte b);
@@ -72,7 +72,7 @@
 
 	/**
 	 * Write out int in range -0x80..0x7f in little endian byte order.
-	 * @param int The value to write.
+	 * @param val The value to write.
 	 */
 	public void put3s(int val);
 
@@ -112,10 +112,6 @@
 	 */
 	public void put4(int val);
 
-// 	public default void put4u(long val) {
-//		put4((int) val);
-//	}
-
 	/**
 	 * Write out an arbitrary length sequence of bytes.
 	 *
diff -r eebe2c5e70b3 src/uk/me/parabola/imgfmt/app/dem/DEMTile.java
--- a/src/uk/me/parabola/imgfmt/app/dem/DEMTile.java	Tue Apr 17 22:22:25 2018 +0100
+++ b/src/uk/me/parabola/imgfmt/app/dem/DEMTile.java	Tue Apr 17 22:26:11 2018 +0100
@@ -310,7 +310,7 @@
 	 * Write an unsigned binary value with the given number of bits, MSB first. 
 	 * @param val
 	 * @param hunit
-	 * @param type 
+	 * @param maxZeroBits
 	 * @return 
 	 */
 	private boolean writeValHybrid(int val, int hunit, int maxZeroBits) {
diff -r eebe2c5e70b3 src/uk/me/parabola/imgfmt/app/lbl/ExitFacility.java
--- a/src/uk/me/parabola/imgfmt/app/lbl/ExitFacility.java	Tue Apr 17 22:22:25 2018 +0100
+++ b/src/uk/me/parabola/imgfmt/app/lbl/ExitFacility.java	Tue Apr 17 22:26:11 2018 +0100
@@ -51,8 +51,6 @@
 		word |= type << 24;	 // 24:27 = 4 bit type
 		// 28 = unkn

Re: [mkgmap-dev] area size in r4160

[Steve Ratcliffe]

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
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] area size in r4160

[Steve Ratcliffe]

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 running with the patch.

When running with --rand, there will be a "Seed was 1523871038110" at
the end of the status line that is printed.  If you save
that value then we can reproduce the test run with --seed 1523871038110

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] area size in r4160

[Steve Ratcliffe]

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

Ignore the help text that says that there may be errors when
using the --use-length option.  This is no longer true and there
should be no errors ever.
The options should be on by default.  I will fix that.

Steve



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] area size in r4160

[Steve Ratcliffe]

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 error:
Error in style: Error: (polygons:8): Expression cannot be indexed

I think this has started in last dev version (or at least within a day 
or so)


--
Harri



Index: src/uk/me/parabola/mkgmap/osmstyle/ExpressionArranger.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/osmstyle/ExpressionArranger.java	(revision 4163)
+++ src/uk/me/parabola/mkgmap/osmstyle/ExpressionArranger.java	(date 1523740568000)
@@ -106,8 +106,7 @@
 			break;
 
 		default:
-			// Should not happen
-			assert false;
+			break;
 		}
 
 		return op;
@@ -375,13 +374,16 @@
 	 * common tag, it would be better to push it behind other tags.
 	 */
 	private int selectivity(Op op) {
+		// Operations that involve a non-indexable function must always go to the back.
+		if (op.getFirst().isType(FUNCTION)) {
+			if (!((ValueOp) op.getFirst()).isIndexable())
+return 1000;
+		}
+
 		switch (op.getType()) {
 		case EQUALS:
-			// Non-indexable functions must go to the back.
-			if (!isIndexable(op))
-return 1000;
-
 			return 0;
+
 		case EXISTS:
 			return 100;
 
Index: test/uk/me/parabola/mkgmap/osmstyle/ExpressionArrangerTest.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- test/uk/me/parabola/mkgmap/osmstyle/ExpressionArrangerTest.java	(revision 4163)
+++ test/uk/me/parabola/mkgmap/osmstyle/ExpressionArrangerTest.java	(date 152372585)
@@ -195,6 +195,16 @@
 		assertTrue(op.getFirst().getType() != NodeType.FUNCTION);
 	}
 
+	@Test
+	public void testExistsAndFunctionWithOr() {
+		Op op = createOp("area_size() < 25000 & (fixme = * | FIXME=*) [0x2]");
+		System.out.println(fmtExpr(op));
+		op = arranger.arrange(op);
+		System.out.println(fmtExpr(op));
+		assertTrue(isSolved(op));
+		assertTrue(op.getFirst().getType() != NodeType.FUNCTION);
+	}
+
 	@Test
 	public void testEqualTagValue() {
 		Op op = createOp("c!=d & a=$b");
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] area size in r4160

[Steve Ratcliffe]

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 should have caught it as the RulesTest
program finds it.

Looking for a fix now.

Best wishes
Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 have an example? The unit tests don't fail when I remove it.


OK a lot of that is not needed any more.

The attached patch returns isIndexable() to its simplest form and
all the other code is changed to fit.

Steve


Index: src/uk/me/parabola/mkgmap/osmstyle/ExpressionArranger.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/osmstyle/ExpressionArranger.java	(revision 4141)
+++ src/uk/me/parabola/mkgmap/osmstyle/ExpressionArranger.java	(date 1522250497000)
@@ -399,13 +399,16 @@
 			return 501;
 
 		// Everything else is 200+, put regex behind as they are probably a bit slower.
+		case GT:
+		case GTE:
+		case LT:
+		case LTE:
+			return 200;
 		case REGEX:
-			return 201;
+			return 210;
+
 		default:
-			// Non-indexable functions must go to the back.
-			if (!isIndexable(op))
-return 1000;
-			return 200;
+			return 1000;
 		}
 	}
 
@@ -429,6 +432,8 @@
 			if (first.isType(EQUALS)) {
 keystring = first.getFirst().getKeyValue() + "=" + first.getSecond().getKeyValue();
 			} else if (first.isType(EXISTS)) {
+if (!isIndexable(first))
+	throw new SyntaxException(scanner, "Expression cannot be indexed");
 keystring = first.getFirst().getKeyValue() + "=*";
 			} else if (first.isType(NOT_EXISTS)) {
 throw new SyntaxException(scanner, "Cannot start rule with tag!=*");
@@ -485,13 +490,12 @@
 	 *
 	 * This is done if the first term is not by itself indexable, but could be made so by pre-pending an EXISTS clause.
 	 */
-	private Op prepareWithExists(Op op) {
+	private static Op prepareWithExists(Op op) {
 		Op first = op;
 		if (first.isType(AND))
 			first = first.getFirst();
 
-		if (NEED_EXISTS.contains(first.getType()) && isIndexable(first)
-|| first.isType(EQUALS) && first.getSecond().isType(FUNCTION))
+		if (NEED_EXISTS.contains(first.getType()) || first.isType(EQUALS) && first.getSecond().isType(FUNCTION))
 			return combineWithExists((BinaryOp) op);
 		else
 			return op;
@@ -502,7 +506,7 @@
 	 *
 	 * This is done if the first term is not by itself indexable, but could be made so by pre-pending an EXISTS clause.
 	 */
-	private AndOp combineWithExists(BinaryOp op) {
+	private static AndOp combineWithExists(BinaryOp op) {
 		Op first = op;
 		if (first.isType(AND))
 			first = first.getFirst();
@@ -515,26 +519,28 @@
 
 	/**
 	 * True if this expression is 'solved'.  This means that the first term is indexable or it is indexable itself.
+	 *
+	 * This is only used in the tests.
 	 */
 	public static boolean isSolved(Op op) {
 		switch (op.getType()) {
 		case NOT:
 			return false;
 		case AND:
-			return isIndexable(op.getFirst());
+			return isAndIndexable(prepareWithExists(op.getFirst()));
 		case OR:
 			Op or = op;
 			boolean valid = true;
 			do {
-if (!isAndIndexable(or.getFirst()))
+if (!isAndIndexable(prepareWithExists(or.getFirst(
 	valid = false;
 or = or.getSecond();
 			} while (or.isType(OR));
-			if (!isAndIndexable(or))
+			if (!isAndIndexable(prepareWithExists(or)))
 valid = false;
 			return valid;
 		default:
-			return isIndexable(op);
+			return isIndexable(prepareWithExists(op));
 		}
 	}
 
@@ -553,11 +559,7 @@
 	 * True if this operation can be indexed.  It is a plain equality or Exists operation.
 	 */
 	private static boolean isIndexable(Op op) {
-		return op.isType(EQUALS)
-&& ((ValueOp) op.getFirst()).isIndexable() && op.getSecond().isType(VALUE)
-|| NEED_EXISTS.contains(op.getType()) && ((ValueOp) op.getFirst()).isIndexable()
-	&& (op.getSecond().isType(VALUE) || op.getSecond().isType(FUNCTION))
-|| op.isType(EXISTS) && ((ValueOp) op.getFirst()).isIndexable();
+		return (op.isType(EQUALS) || op.isType(EXISTS)) && ((ValueOp) op.getFirst()).isIndexable();
 	}
 
 	/**
Index: test/uk/me/parabola/mkgmap/osmstyle/ExpressionArrangerTest.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- test/uk/me/parabola/mkgmap/osmstyle/ExpressionArrangerTest.java	(revision 4141)
+++ test/uk/me/parabola/mkgmap/osmstyle/ExpressionArrangerTest.java	(date 1522249961000)
@@ -28,6 +28,7 @@
 import static org.junit.Assert.*;
 import static uk.me.parabola.mkgmap.osmstyle.ExpressionArranger.fmtExpr;
 import static uk.me.parabola.mkgmap.osmstyle.ExpressionArranger.isSolved;
+import static uk.me.parabola.mkgmap.osmstyle.eval.NodeType.AND;
 import static uk.me.parabola.mkgmap.osmstyle.eval.NodeType.EQUALS;
 
 
@@ -193,7 +194,18 @@
 		assertTrue(isSolved(op));
 		assertTrue(op.getFirst().getType() != No

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

[Steve Ratcliffe]

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: src/uk/me/parabola/mkgmap/osmstyle/ExpressionArranger.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/osmstyle/ExpressionArranger.java	(revision 4140)
+++ src/uk/me/parabola/mkgmap/osmstyle/ExpressionArranger.java	(date 1521717514000)
@@ -553,8 +553,7 @@
 	 * True if this operation can be indexed.  It is a plain equality or Exists operation.
 	 */
 	private static boolean isIndexable(Op op) {
-		return op.isType(EQUALS)
-&& ((ValueOp) op.getFirst()).isIndexable() && op.getSecond().isType(VALUE)
+		return op.isType(EQUALS) && ((ValueOp) op.getFirst()).isIndexable() && (op.getSecond().isType(VALUE) || op.getSecond().isType(FUNCTION))
 || NEED_EXISTS.contains(op.getType()) && ((ValueOp) op.getFirst()).isIndexable()
 	&& (op.getSecond().isType(VALUE) || op.getSecond().isType(FUNCTION))
 || op.isType(EXISTS) && ((ValueOp) op.getFirst()).isIndexable();
Index: test/uk/me/parabola/mkgmap/osmstyle/ExpressionArrangerTest.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- test/uk/me/parabola/mkgmap/osmstyle/ExpressionArrangerTest.java	(revision 4140)
+++ test/uk/me/parabola/mkgmap/osmstyle/ExpressionArrangerTest.java	(date 152171489)
@@ -28,6 +28,7 @@
 import static org.junit.Assert.*;
 import static uk.me.parabola.mkgmap.osmstyle.ExpressionArranger.fmtExpr;
 import static uk.me.parabola.mkgmap.osmstyle.ExpressionArranger.isSolved;
+import static uk.me.parabola.mkgmap.osmstyle.eval.NodeType.AND;
 import static uk.me.parabola.mkgmap.osmstyle.eval.NodeType.EQUALS;
 
 
@@ -193,7 +194,18 @@
 		assertTrue(isSolved(op));
 		assertTrue(op.getFirst().getType() != NodeType.FUNCTION);
 	}
-	
+
+	@Test
+	public void testEqualTagValue() {
+		Op op = createOp("c!=d & a=$b");
+		op = arranger.arrange(op);
+		Iterator it = arranger.prepareForSave(op);
+		op = it.next();
+		assertEquals(AND, op.getType());
+		assertEquals("$a=* & $a=$b & $c!=d", op.toString());
+		System.out.println(op.toString());
+	}
+
 	private Op createOp(String s) {
 		TokenScanner scanner = new TokenScanner("test.file", new StringReader(s));
 		ExpressionReader er = new ExpressionReader(scanner, FeatureKind.POLYLINE);
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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), put3s(int), put4(int)
   put1u(int), put2u(int), put3u(int), putNu(nBytes, int)
throughout almost all of imgfmt.

putX{s/u} assert the correct range and the getX{s/u} sign-extend or not
as appropriate. assert and sign-extend are meaningless for
get4()/put4() so it doesn't have the s/u variants.

In a lot of places I've changed the working variables from byte/char/short to 
int and avoided any premature range narrowing.

There are a couple of places where I've left byte get() and put(byte)
because bit fiddling makes it meaningless to consider the value as a
number or I didn't want to touch delicate logic, but generally flags
are handled as ints.

I had some problems with test/func/files/GmapsuppTest.java where an
empty map leads to negative subdivision width/height and lat/long
values bigger than 3 bytes but I've dealt with this.

Something that confused me in imgfmt/app/trergn/TREFileReader.java,
around line 118, was the 2*width and 2*height in new SubdivData(...
As far as I can see these values have just been read from an .img and
so should be written back exactly as they were.

If/when you are interested, I'll send the patch. In the meantime I'm
running with it to see if there are any problems

I have a similar patch for Display

Ticker


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 not caught by RuleTest as there were no
tests of '=' with no-indexable functions.  I have added terms
like 'type()=way' which catches this error.

I don't see how we can make is_closed() indexable.

Steve


the problem is in the ExpressionArranger, it changes the order of the terms in
man_made=* & is_closed()=true {add area=yes; echotags 'mm'}
to
is_closed()=true & man_made=* {add area=yes; echotags 'mm'}
and thus creates an invalid input for the RuleIndex.
Attached patch fixes this problem, but I think we should add more code in 
ExpressionArranger
to make sure that it never produces such an invalid input.

@Steve: I think ExpressionArranger should call isSolved()
and stop if that returns false. In that case it would be great to print an 
error message
that shows the original expression and the file and line number of the rule 
file.
When we add a check in RuleIndex we can only print the re-arranged rule and 
that will
only confuse the user.

BTW: Maybe we can also change the code so that is_closed() is indexable?

Gerd


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 needs some good testing.

Also display project would have to be patched to match.

..Steve

Index: src/uk/me/parabola/imgfmt/app/BufferedImgFileReader.java
===
diff --git a/trunk/src/uk/me/parabola/imgfmt/app/BufferedImgFileReader.java b/trunk/src/uk/me/parabola/imgfmt/app/BufferedImgFileReader.java
--- a/trunk/src/uk/me/parabola/imgfmt/app/BufferedImgFileReader.java	(revision 4127)
+++ b/trunk/src/uk/me/parabola/imgfmt/app/BufferedImgFileReader.java	(working copy)
@@ -100,11 +100,10 @@
 	 *
 	 * @return The 2 byte integer that was read.
 	 */
-	public char getChar() throws ReadFailedException {
-		// Slow but sure implementation
+	public int get2() throws ReadFailedException {
 		byte b1 = get();
 		byte b2 = get();
-		return (char) (((b2 & 0xff) << 8) + (b1 & 0xff));
+		return (b2 << 8) + (b1 & 0xff);
 	}
 
 	/**
@@ -124,17 +123,12 @@
 ;
 	}
 
-	public int getu3() throws ReadFailedException {
-		return get3() & 0xff;
-	}
-
 	/**
-	 * Read in a 4 byte value.
+	 * Read in a 4 byte signed value.
 	 *
 	 * @return A 4 byte integer.
 	 */
-	public int getInt() throws ReadFailedException {
-		// Slow but sure implementation
+	public int get4() throws ReadFailedException {
 		byte b1 = get();
 		byte b2 = get();
 		byte b3 = get();
@@ -148,10 +142,10 @@
 
 	public int getUint(int n) throws ReadFailedException {
 		switch (n) {
-		case 1: return get() & 0xff;
-		case 2: return getChar();
-		case 3: return getu3();
-		case 4: return getInt();
+		case 1: return get1u();
+		case 2: return get2u();
+		case 3: return get3u();
+		case 4: return get4();
 		default: // this is a programming error so exit
 			throw new MapFailedException("bad integer size " + n);
 		}
Index: src/uk/me/parabola/imgfmt/app/CommonHeader.java
===
diff --git a/trunk/src/uk/me/parabola/imgfmt/app/CommonHeader.java b/trunk/src/uk/me/parabola/imgfmt/app/CommonHeader.java
--- a/trunk/src/uk/me/parabola/imgfmt/app/CommonHeader.java	(revision 4127)
+++ b/trunk/src/uk/me/parabola/imgfmt/app/CommonHeader.java	(working copy)
@@ -79,7 +79,7 @@
 	 */
 	public final void readHeader(ImgFileReader reader) throws ReadFailedException {
 		reader.position(0);
-		headerLength = reader.getChar();
+		headerLength = reader.get2u();
 		byte[] bytes = reader.get(TYPE_LEN);
 		try {
 			type = new String(bytes, "ascii");
Index: src/uk/me/parabola/imgfmt/app/ImgFileReader.java
===
diff --git a/trunk/src/uk/me/parabola/imgfmt/app/ImgFileReader.java b/trunk/src/uk/me/parabola/imgfmt/app/ImgFileReader.java
--- a/trunk/src/uk/me/parabola/imgfmt/app/ImgFileReader.java	(revision 4127)
+++ b/trunk/src/uk/me/parabola/imgfmt/app/ImgFileReader.java	(working copy)
@@ -48,11 +48,23 @@
 	 */
 	public byte get() throws ReadFailedException;
 
+	public default int get1() throws ReadFailedException {
+		return get();
+	}
+
+	public default int get1u() throws ReadFailedException {
+		return get() & 0xff;
+	}
+
+	public int get2() throws ReadFailedException;
+
 	/**
 	 * Read in two bytes.  Done in the correct byte order.
 	 * @return The 2 byte integer that was read.
 	 */
-	public char getChar() throws ReadFailedException;
+	public default int get2u() throws ReadFailedException {
+		return get2() & 0x;
+	}
 
 	/**
 	 * Get a 3byte signed quantity.
@@ -68,14 +80,20 @@
 	 * @return The value read.
 	 * @throws ReadFailedException When the file cannot be read.
 	 */
-	public int getu3() throws ReadFailedException;
+	public default int get3u() throws ReadFailedException {
+		return get3() & 0xff;
+	}
 
 	/**
-	 * Read in a 4 byte value.
+	 * Read in a 4 byte signed value.
 	 * @return A 4 byte integer.
 	 */
-	public int getInt() throws ReadFailedException;
+	public int get4() throws ReadFailedException;
 
+	public default long get4u() throws ReadFailedException {
+		return get4() & 0x_L;
+	}
+
 	/**
 	 * Read a variable sized integer.  The size is given.
 	 * @param n The size of the integer to read. Must be 1 to 4.
Index: src/uk/me/parabola/imgfmt/app/Section.java
===
diff --git a/trunk/src/uk/me/parabola/imgfmt/app/Section.java b/trunk/src/uk/me/parabola/imgfmt/app/Section.java
--- a/trunk/src/uk/me/parabola/imgfmt/app/Section.java	(revision 4127)
+++ b/trunk/src/uk/me/parabola/imgfmt/app/Section.java	(working copy)
@@ -117,10 +117,10 @@
 	}
 
 	public void readSectionInfo(ImgFileReader reader, boolean withItemSize) {
-		setPosition(reader.getInt());
-		setSize(reader.getInt());
+		setPosition(reader.get4());
+		setSize(r

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

[Steve Ratcliffe]

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  aa70a324bc002f47dc6e1e46c95d7e6c605596c6

diff -r aa70a324bc00 -r d7edc89b62d9 src/uk/me/parabola/imgfmt/app/FileBackedImgFileWriter.java
--- a/src/uk/me/parabola/imgfmt/app/FileBackedImgFileWriter.java	Mon Feb 19 21:31:24 2018 +
+++ b/src/uk/me/parabola/imgfmt/app/FileBackedImgFileWriter.java	Tue Feb 20 21:23:53 2018 +
@@ -49,7 +49,7 @@
 			tmpChannel = out.getChannel();
 			file = new BufferedOutputStream(out, 16*1024);
 		} catch (IOException e) {
-			throw new MapFailedException("Could not create mdr temporary file");
+			throw new MapFailedException("Could not create temporary file");
 		}
 
 		if (chan instanceof FileLink) {
@@ -70,7 +70,7 @@
 			channel.transferTo(0, channel.size(), outputChan);
 		} finally {
 			if (!tmpFile.delete())
-System.err.println("Could not delete mdr img temporary file");
+System.err.println("could not delete temporary file " + tmpFile.getPath());
 		}
 	}
 
@@ -99,7 +99,7 @@
 			file.flush();
 			tmpChannel.position(pos);
 		} catch (IOException e) {
-			throw new MapFailedException("Could not set position in mdr tmp file");
+			throw new MapFailedException("could not set position in temporary file " + tmpFile.getPath());
 		}
 	}
 
@@ -112,7 +112,7 @@
  		try {
 			file.write(val);
 		} catch (IOException e) {
-			throw new MapFailedException("could not write byte to mdr tmp file");
+			throw new MapFailedException("could not write to temporary file " + tmpFile.getPath());
 		}
 	}
 
@@ -126,7 +126,7 @@
 			file.write(val);
 			file.write(val >> 8);
 		} catch (IOException e) {
-			throw new MapFailedException("could not write 2 bytes to mdr tmp file");
+			throw new MapFailedException("could not write to temporary file " + tmpFile.getPath());
 		}
 
 	}
@@ -142,7 +142,7 @@
 			file.write(val >> 8);
 			file.write(val >> 16);
 		} catch (IOException e) {
-			throw new MapFailedException("could not write3 to mdr tmp file");
+			throw new MapFailedException("could not write to temporary file " + tmpFile.getPath());
 		}
 	}
 
@@ -165,7 +165,7 @@
 return;
 			file.write(val >> 24);
 		} catch (IOException e) {
-			throw new MapFailedException("could not write put3 to mdr tmp file");
+			throw new MapFailedException("could not write to temporary file " + tmpFile.getPath());
 		}
 	}
 
@@ -181,7 +181,7 @@
 			file.write(val >> 16);
 			file.write(val >> 24);
 		} catch (IOException e) {
-			throw new MapFailedException("could not write int to mdr tmp file");
+			throw new MapFailedException("could not write to temporary file " + tmpFile.getPath());
 		}
 	}
 
@@ -194,7 +194,7 @@
 		try {
 			file.write(val);
 		} catch (IOException e) {
-			throw new MapFailedException("could not write bytes to mdr tmp file");
+			throw new MapFailedException("could not write to temporary file " + tmpFile.getPath());
 		}
 	}
 
@@ -209,7 +209,7 @@
 		try {
 			file.write(src, start, length);
 		} catch (IOException e) {
-			throw new MapFailedException("could not write bytes to mdr tmp file");
+			throw new MapFailedException("could not write to temporary file " + tmpFile.getPath());
 		}
 	}
 
@@ -223,7 +223,7 @@
 			file.flush();
 			tmpChannel.write(src);
 		} catch (IOException e) {
-			throw new MapFailedException("could not write buffer to mdr tmp file");
+			throw new MapFailedException("could not write to temporary file " + tmpFile.getPath());
 		}
 	}
 
@@ -240,13 +240,13 @@
 			file.flush();
 			return tmpChannel.size();
 		} catch (IOException e) {
-			throw new MapFailedException("could not get size of mdr tmp file");
+			throw new MapFailedException("could not write to temporary file " + tmpFile.getPath());
 		}
 	}
 
 	/**
-	 * Closes this stream and releases any system resources associated with it. If the stream is already closed then
-	 * invoking this method has no effect.
+	 * Closes this stream with the result that the contents of the temporary file are written to the
+	 * real output.
 	 *
 	 * @throws IOException if an I/O error occurs
 	 */
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 causing the collision?  I cannot find 
any decent documentation on what family id and product ID are supposed 
to be.


The TYP file contains a family and product id, if you have two maps they
would normally have different family ids and the TYP with the matching 
family id would be used.


I don't think I have ever tried different product ids, but that may be 
another way of selecting the product id.


If you are creating the TYP with mkgmap, then the --family-id and 
--product-id options will also affect the TYP file.


Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
that fits into an int.

To write unsigned values greater than 2G then technically you
need a long, so an unsigned version could be added as a
default method on the interface put4u(long val) rather than
having to implement across multiple implementations.

Although I don't think it is necessary if you want to add
signed/unsigned methods that range check the value, then
again add them as default method on the interface.

I've attached a patch that implements this.

Reading is different, we do need signed/unsigned versions.
I'd suggest that again have get{1,2,3,4} and remove getChar and
getInt special cases, and then get1u() etc for unsigned results.
All of these returning int probably, depending on what results
in the best looking code.  I have not done a patch for that.

..Steve


we have various methods to write an integer with 1, 2, 3, or 4 bytes to an img 
file.
I always feel unsure what method to use because none of them makes
clear what happens with negative values.

Besides that some of the existing routines seem to throw misleading exceptions,
e.g. FileBackedImgFileWriter seems to assume that it is only used for the mdr 
tmp file and creates texts like this:
throw new MapFailedException("could not write3 to mdr tmp file");
throw new MapFailedException("could not write put3 to mdr tmp file");

Only the javadoc for put1() and put2() tell me the range (0..255 or 0..65535) .

If I got that right put3() allows negative values, so I think it is NOT 
0..16777215 but -8388608 .. 8388607 ?

I'd like to improve the readability of the code, but I don't want to mess up 
anything.
Would it be possible to add comments to all the methods?

Gerd



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



Index: src/uk/me/parabola/imgfmt/app/dem/DEMHeader.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/imgfmt/app/dem/DEMHeader.java	(revision 4123)
+++ src/uk/me/parabola/imgfmt/app/dem/DEMHeader.java	(date 1518972751000)
@@ -55,12 +55,12 @@
 		}
 		writer.position(pos);
 		
-		writer.putInt(0); // 0: elevation in metres, 1: foot
+		writer.put4(0); // 0: elevation in metres, 1: foot
 		writer.put2(zoomLevels.size());
-		writer.putInt(0); // unknown
+		writer.put4(0); // unknown
 		writer.put2(60); // size of zoom level record
-		writer.putInt(offset); // offset to first DemSection header (they appear at the end of the file!)
-		writer.putInt(1); // unknown, 0 and 1 spotted
+		writer.put4(offset); // offset to first DemSection header (they appear at the end of the file!)
+		writer.put4(1); // unknown, 0 and 1 spotted
 		
 	}
 
Index: src/uk/me/parabola/imgfmt/app/dem/DEMSection.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/imgfmt/app/dem/DEMSection.java	(revision 4123)
+++ src/uk/me/parabola/imgfmt/app/dem/DEMSection.java	(date 1518972751000)
@@ -183,28 +183,28 @@
 	}
 
 	public void writeHeader(ImgFileWriter writer) {
-		writer.put(unknown1);	//0x00 
-		writer.put1(zoomLevel);	//0x01 
-		writer.putInt(pointsPerLat);	//0x02
-		writer.putInt(pointsPerLon);	//0x06 
-		writer.putInt(nonStdHeight - 1);	//0x0A
-		writer.putInt(nonStdWidth - 1);	//0x0E 
+		writer.put1(unknown1);	//0x00
+		writer.put1(zoomLevel);	//0x01
+		writer.put4(pointsPerLat);	//0x02
+		writer.put4(pointsPerLon);	//0x06
+		writer.put4(nonStdHeight - 1);	//0x0A
+		writer.put4(nonStdWidth - 1);	//0x0E
 		writer.put2(flags1);	//0x12
-		writer.putInt(tilesLon - 1);	//0x14
-		writer.putInt(tilesLat - 1);	//0x18
+		writer.put4(tilesLon - 1);	//0x14
+		writer.put4(tilesLat - 1);	//0x18
 		
 		writer.put2(recordDesc);	//0x1c
 		writer.put2(tileDescSize);	//0x1e
-		writer.putInt(dataOffset);	//0x20
-		writer.putInt(dataOffset2);	//0x24
-		writer.putInt(left);	//0x28 
-		writer.putInt(top);	//0x2c 
-		writer.putInt(pointsDistanceLat);	//0x30
-		writer.putInt(pointsDistanceLon);	//0x34
+		writer.put4(dataOffset);	//0x20
+		writer.put4(dataOffset2);	//0x24
+		writer.put4(left);	//0x28
+		writer.put4(top);	//0x2c
+		writer.put4(pointsDistanceLat);	//0x30
+		writer.put4(pointsDistanceLon);	//0x34
 		assert minHeight >= Short.MIN_VALUE && minHeight <= Short.MAX_VALUE; 
-		writer.putChar((char) minHeight);	//0x38
+		writer.put2(minHeight);	//0x38
 		assert maxHeight >= Short.MIN_VALUE && maxHeight <= Short.MAX_VALUE; 
-		writer.putChar((char) maxHeight);	//0x3a
+		writer.put2(maxHeight);	//0x3a
 	}
 
 	public 

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

[Steve Ratcliffe]

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 a 
semi-transparent map.


I tried un-setting the flag on a transparent map and routing started 
working again in mapsource. So it is just the flag that causes the

problem.  I don't know what the flag really does.

I also noted from the documentation that cgpsmapper seems to add 32 to
the draw priority of a transparent map, which is something that we do
not do.

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Heureka!

[Steve Ratcliffe]

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!

[Steve Ratcliffe]

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 or not.

It is usually not set in a garmin basemap even when it does contain
a DEM.  Seems that cgpsmapper maps sets it in basemaps too, or at
least later versions did.

..Steve


The wiki says about the meaning of this one byte field:
Flags: 0: detailed map, 1: transparent map, 2: show street before street 
number, 3: show zip before city, 4-7: ?? When bit 0 is set routing is cancelled 
(wilpin)

Any hints where this flag might cause trouble?

Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Strange error in mkgmap

[Steve Ratcliffe]

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 which must apply to the MDR and also to the individual IMG files.


I recently noticed that some Garmin maps have the SRT file repeated for
every IMG file within the gmapsupp.img as well as a copy for the MDR.

But I don't know, perhaps when there is no MDR the SRT does not get 
picked up.  Only experiment can show what is needed.


Cheers,
Steve

what about SRT subfile? I think SRT is only a part of an MDR (or  a part 
of a tile). It is associated to MDR by its name. See code in 
GmapsuppBuilder.java:


if (createIndex) {
  MdrBuilder mdrBuilder = addMdrFile(familyId, info.getSort());
  mdrBuilder.onMapEnd(info);
}
addSrtFile(familyId, info);

Maybe it should be like that:
if (createIndex) {
  MdrBuilder mdrBuilder = addMdrFile(familyId, info.getSort());
  addSrtFile(familyId, info);
  mdrBuilder.onMapEnd(info);
}



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] max-jobs patch

[Steve Ratcliffe]

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, you could just
surround it with a try/catch block.  Then if it doesn't
exist on a particular it isn't a problem when using the
downloaded pre-compiled distribution.

Of course it would fail to compile on such a platform, but then
hopefully someone will let us know and we can decide what to do then.

Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Strange error in mkgmap

[Steve Ratcliffe]

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 code used to calculate the best block size 
to use.  It is missing a constraint on the block size to restrict the

number of blocks in the directory file.

The attached patch fixes this and I'll commit this today.

Thanks

..Steve
Index: src/uk/me/parabola/imgfmt/sys/ImgFS.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/imgfmt/sys/ImgFS.java	(revision 4111)
+++ src/uk/me/parabola/imgfmt/sys/ImgFS.java	(date 151853066)
@@ -294,6 +294,9 @@
 			log.infof("bs=%d, whole size=%d, hb=%d, fb=%d, blocks=%d\n", blockSize, size,
 	headerBlocks, fileBlocks, totalBlocks);
 
+			if (headerBlocks > SLOTS_PER_ENTRY)
+continue;
+
 			if (totalBlocks > 0xfffe)
 continue;
 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
===
--- src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java	(revision 4107)
+++ src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java	(date 1518386556000)
@@ -120,16 +120,10 @@
 		String mapdesc = finfo.getDescription();
 
 		detail.setMapName(mapname);
-		detail.setInnername(finfo.getInnername());
 
 		String desc = mapdesc + " (" + mapname + ')';
 		detail.setDescription(desc);
-		detail.setLblDataSize(finfo.getLblsize());
-		detail.setTreDataSize(finfo.getTresize());
-		detail.setRgnDataSize(finfo.getRgnsize());
-		detail.setNetDataSize(finfo.getNetsize());
-		detail.setNodDataSize(finfo.getNodsize());
-		detail.setDemDataSize(finfo.getDemsize());
+		detail.setSubFiles(finfo.subFiles());
 		if (finfo.getDemsize() > 0)
 			tdb.setHasDem();
 
Index: src/uk/me/parabola/tdbfmt/DetailMapBlock.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/tdbfmt/DetailMapBlock.java	(revision 4107)
+++ src/uk/me/parabola/tdbfmt/DetailMapBlock.java	(date 1518386918000)
@@ -17,9 +17,12 @@
 package uk.me.parabola.tdbfmt;
 
 import java.io.IOException;
+import java.util.ArrayList;
+import java.util.List;
 
 import uk.me.parabola.io.StructuredInputStream;
 import uk.me.parabola.io.StructuredOutputStream;
+import uk.me.parabola.mkgmap.combiners.SubFileInfo;
 
 /**
  * Details of a single .img file that is part of the map set.  There will be
@@ -32,19 +35,12 @@
 
 	private int tdbVersion;
 
-	private String innername;
-
-	// Sizes of the regions.  It is possible that rgn and tre are reversed?
-	private int rgnDataSize;
-	private int treDataSize;
-	private int lblDataSize;
-	private int netDataSize;
-	private int nodDataSize;
-	private int demDataSize;
+	// Sizes of the regions.
+	private List subFiles;
 
 	public DetailMapBlock(int tdbVersion) {
 		super(BLOCK_ID);
-		assert tdbVersion > 0;
+
 		this.tdbVersion = tdbVersion;
 	}
 
@@ -57,20 +53,27 @@
 		super(ds);
 
 		// First there are a couple of fields that we ignore.
-		int junk = ds.read2();
-		assert junk == 4;
-
-		junk = ds.read2();
-		assert junk == 3;
+		int n = ds.read2();
+		ds.read2();
 
 		// Sizes of the data
-		rgnDataSize = ds.read4();
-		treDataSize = ds.read4();
-		lblDataSize = ds.read4();
+		int[] sizes = new int[n];
+		for (int i = 0; i < n; i++) {
+			sizes[i] = ds.read4();
+		}
 
 		// Another ignored field
-		junk = ds.read();
-		assert junk == 1;
+		ds.read();
+		ds.read();
+		ds.read();
+		ds.read4();
+
+		subFiles = new ArrayList<>();
+		for (int i = 0; i < n; i++) {
+			String name = ds.readString();
+			SubFileInfo si = new SubFileInfo(name, sizes[i]);
+			subFiles.add(si);
+		}
 	}
 
 	/**
@@ -82,86 +85,29 @@
 	public void writeBody(StructuredOutputStream os) throws IOException {
 		super.writeBody(os);
 
-		int n = 3;
-		if (tdbVersion >= TdbFile.TDB_V407) {
-			if (netDataSize > 0)
-n = 4;
-			if (nodDataSize > 0)
-n = 5;
-			if (demDataSize > 0)
-n = 6;
-		}
-		
+		// We do not support writing a version less than v4.07
+		assert tdbVersion >= TdbFile.TDB_V407;
+
+		int n = subFiles.size();
 		os.write2(n+1);
 		os.write2(n);
 
-		os.write4(treDataSize);
-		os.write4(rgnDataSize);
-		os.write4(lblDataSize);
-		
-		if (tdbVersion >= TdbFile.TDB_V407) {
-			if (n > 3) os.write4(netDataSize);
-			if (n > 4) os.write4(nodDataSize);
-			if (n > 5) os.write4(demDataSize);
+		for (SubFileInfo si : subFiles) {
+			os.write4((int) si.getSize());
+		}
+
 //01 c3 00 ff
-			os.write4(0xff00c301);
-			os.write(0);
-			os.write(0);
-			os.write(0);
+		os.write4(0xff00c301);
+		os.write(0);
+		os.write(0);
+		os.write(0);
 
-			String mn = getInnername();
-			os.writeString(mn + ".TRE");
-			os.writeString(mn + ".RGN");
-			os.writeString(mn + ".LBL");
-			if (n > 3) os.writeString(mn + ".NET");
-			if (n > 4) os.writeString(mn + ".NOD");
-			if (n > 5) os.writeString(mn + ".DEM");
-		} else {
-			os.write(1);
+		for (SubFileInfo si : subFiles) {
+			os.writeString(si.getName());
 		}
 	}
-
-	private String getInnername() {
-		return innername;
-	}
 
-	public void setInnername(String innername) {
-		this.innername = innername;
+	public void setSubFiles(List subFiles) {
+		this.subFiles = subFiles;
 	}
-
-	public void setRgnDataSize(int rgnDataSize) {
-		this.rgnDataSize = rgnDataSize;
-	}
-
-	public void setTreDataSize(int treDataSize) {
-		this.treDataSize = treDataSize;
-	}
-
-	public void setLblDataSize(int lblDataSize) {
-		this.lblDataSize = lblDataSize;
-	}
-
-	public void setNetDataSize(int netDataSize) {
-		this.netDataSize = netDataSize;
-	}
-
-	public void setNodDataSize(int nodDataSize) {
-		this.nodD

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

[Steve Ratcliffe]

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 made with cgpsmapper.  That order
was RGN, TRE, LBL, NET, NOD.

For the TDB file, it makes sense that they should be in the same
order as in the .img file.  This is the case for both the Garmin
maps I looked at.

I don't know why we do not do that, we originally wrote them in the
same order that we wrote the sub-files, but this was changed when
net/nod support was added to the tdb file.

I am all for changing our code to write the subfiles in the TDB file
in the same order as they occur in the input files.

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 looked at this. No idea where any of those came from :)

I think those 7 bytes should be:

1 byte: unknown to me
1 byte: Maybe index into block 'S' (0x53)
1 byte: index into block 'R' (0x52) or zero if no block 'R'
4 bytes: a size that is generally related to the size of the file.

cgpsmapper and gmaptool set this size to 256 (and previously to 255)

Block R has the following structure:

  1 byte: index number, starting from 1
  n bytes: zero terminated string

There is probably only ever one of these.  Eg "Europe guide v1"
Gmaptool appears to create one of these with the name "All".


Block S has the following structure:

  1 byte: number, probably index into block R
  1 byte: number index in this block, starting from 1
  n bytes: zero terminated string name

eg: 1,1 "Region 1 - Aus/Switz/N.Italy"
1,2 "Region 2 - France"
1,3 "Region 3 - Germany/Czech Republic"
...

Unfortunately I think they have nothing to do with DEM as
maps without DEM have these.  There are lots of unknown
entries in the TDB header, there could be something there.

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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:


   setaccess =;
   no;

Probably anything that isn't 'yes' is treated as 'no', so that '=' is 
accepted without complaint and then 'no' is treated as a command which 
fails.


I shall add a check for a valid argument to setaccess.

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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

Best wishes,
Steve
Index: src/uk/me/parabola/mkgmap/main/TypCompiler.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/main/TypCompiler.java	(revision 4100)
+++ src/uk/me/parabola/mkgmap/main/TypCompiler.java	(date 1517590268000)
@@ -246,10 +246,11 @@
 	if (line.charAt(0) == 0xfeff)
 		return;
 
-	if (line.startsWith("CodePage")) {
+	if (line.startsWith("CodePage=")) {
 		String[] split = line.split("=");
 		try {
-			setCodePage("cp" + Integer.decode(split[1].trim()));
+			if (split.length > 1)
+setCodePage("cp" + Integer.decode(split[1].trim()));
 		} catch (NumberFormatException e) {
 			setCodePage("cp1252");
 		}
Index: src/uk/me/parabola/mkgmap/typ/TypTextReader.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/typ/TypTextReader.java	(revision 4100)
+++ src/uk/me/parabola/mkgmap/typ/TypTextReader.java	(date 1517591167000)
@@ -65,6 +65,9 @@
 	break;
 }
 			} else {
+if (currentSection == null)
+	throw new SyntaxException(scanner, "Missing section start");
+
 // Line inside a section
 String name = tok.getValue();
 
@@ -74,9 +77,6 @@
 
 String value = scanner.readLine();
 
-if (currentSection == null)
-	throw new SyntaxException(scanner, "Missing section start");
-
 currentSection.processLine(scanner, name, value);
 			}
 			scanner.skipSpace();
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 meant
mkgmap:carpool_compat=yes  { set access=no; set mkgmap:bus=yes; set 
mkgmap:emergency=yes; set mkgmap:carpool=yes }


Ha.. yes it could be either.  My guess would be that
it should be 'setaccess no' as it is followed by some
of the access flags.

Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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' {
  apply {
add ref='${ref}';
add int_ref='${int_ref}';
add network='e-road'# missing semi-colon
add mkgmap:fast_road='yes';
  }
}

this was being read as:

$route=road & $network='e-road' {
  apply {
add ref='${ref}';
add int_ref='${int_ref}';
add network='e-road' | 'add' | 'mkgmap:fast_road' | '=' | 'yes';
  }
}

Since 'e-road' does not contain any variables, then it was always
the value that 'network' was set to.

Now you do not need any of the semi-colons, so the original code
would be read as intended.

I don't believe that there were any more similar errors
in the style file, so this patch should have no effect for the
default style.

Of course it may find errors in custom styles, or something that did not 
work before may suddenly start to work as intended causing a difference.


..Steve
Index: src/uk/me/parabola/mkgmap/osmstyle/actions/ActionReader.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/osmstyle/actions/ActionReader.java	(revision 4100)
+++ src/uk/me/parabola/mkgmap/osmstyle/actions/ActionReader.java	(date 1517574341000)
@@ -55,6 +55,9 @@
 			if (tok.isValue(";"))
 continue;
 
+			if (tok.isValue("'") || tok.isValue("\""))
+throw new SyntaxException(scanner, "quoted word found where command expected");
+
 			String cmd = tok.getValue();
 			if ("set".equals(cmd)) {
 actions.add(readTagValue(true, changeableTags));
@@ -131,14 +134,14 @@
 	 * A name command has a number of alternatives separated by '|' characters.
 	 */
 	private Action readValueBuilder(ValueBuildedAction action) {
-		while (inActionCmd()) {
-			if (scanner.checkToken("|")) {
-scanner.nextToken();
-continue;
-			}
+		do {
+			if (!inActionCmd())
+throw new SyntaxException(scanner, "unexpected end of add/set list");
+
 			String val = scanner.nextWord();
 			action.add(val);
-		}
+		} while (hasMoreWords());
+
 		usedTags.addAll(action.getUsedTags());
 		return action;
 	}
@@ -162,7 +165,9 @@
 		scanner.nextToken();
 
 		AddTagAction action = null;
-		while (inActionCmd()) {
+		do {
+			if (!inActionCmd())
+throw new SyntaxException(scanner, "unexpected end of add/set list");
 
 			String val = scanner.nextWord();
 			if (action == null)
@@ -177,11 +182,9 @@
 			} else {
 changeableTags.add(key + "=" + val);
 			}
-			if (scanner.checkToken("|"))
-scanner.nextToken();
-		}
-		if (action != null)
-			usedTags.addAll(action.getUsedTags());
+		} while (hasMoreWords());
+
+		usedTags.addAll(action.getUsedTags());
 		return action;
 	}
 
@@ -199,7 +202,9 @@
 	 */
 	private AddAccessAction readAccessValue(boolean modify, Set changeableTags) {
 		AddAccessAction action = null;
-		while (inActionCmd()) {
+		do {
+			if (!inActionCmd())
+throw new SyntaxException(scanner, "unexpected end of access list");
 
 			String val = scanner.nextWord();
 			if (action == null)
@@ -210,17 +215,15 @@
 			// If the value contains a variable, then we do not know what the
 			// value will be.  Otherwise save the full tag=value
 			if (val.contains("$")) {
-for (String accessTag : ACCESS_TAGS.keySet())
-	changeableTags.add(accessTag);
+changeableTags.addAll(ACCESS_TAGS.keySet());
 			} else {
 for (String accessTag : ACCESS_TAGS.keySet())
 	changeableTags.add(accessTag + "=" + val);
 			}
-			if (scanner.checkToken("|"))
-scanner.nextToken();
-		}
-		if (action != null)
-			usedTags.addAll(action.getUsedTags());
+
+		} while (hasMoreWords());
+
+		usedTags.addAll(action.getUsedTags());
 		return action;
 	}
 	
@@ -233,6 +236,17 @@
 		return !scanner.isEndOfFile() && !scanner.checkToken("}");
 	}
 
+	private boolean hasMoreWords() {
+		if (scanner.checkToken("|")) {
+			scanner.nextToken();
+
+			if (!inActionCmd())
+throw new SyntaxException(scanner, "unexpected end of list");
+			return true;
+		}
+		return false;
+	}
+
 	public Set getUsedTags() {
 		return usedTags;
 	}
Index: src/uk/me/parabola/mkgmap/scan/TokenScanner.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/scan/TokenScanner.java	(revision 4100)
+++ src/uk/me/parabola/mkgmap/scan/TokenScanner.java	(date 1517571163000)
@@ -356,7 +356,9 @@
 	}
 
 	/**
-	 * Check the value of the next token without consuming it.
+	 * Check the value of the next non-space token without consuming it.
+	 *
+	 * Any white space will be consumed
 	 *
 	 * @param val String value to compare against.
 	 * @ret

Re: [mkgmap-dev] Build instructions

[Steve Ratcliffe]

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 
mkgmap and splitter to require Java 8. However, the mkgmap dev 
instructions indicate that Java 7 is supported. Is Java 7 supported?


That is correct they require Java 8.

I've fixed the development page to state that.  Thanks for letting
us know.

Best wishes
Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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"
>
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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"
>
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] gmapi reader?

[Steve Ratcliffe]

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
processing the style, not at this stage.


Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] gmapi reader?

[Steve Ratcliffe]

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 Garmin does it,
and also DemDisplay uses it to determine the length of the last bitstream.
So, to do the needed checks we have to read main header and the DEM Section 
headers at the end of the file.


OK so that is more than I thought, but still not the whole file?  If
you do have to read the whole file, then you might as well use it and
the following may not make sense.


Not sure where to place this if not in DEMFile. Where would you implement that?


I meant to move everything in DEMFile.tryCopy().

I guess it goes back to Map.addDem().  If possible you want to do
things there or in the code that calls addDem().

You may not have all the required information there, in which case I 
don't know

how to proceed.

Currently addDem() is:

demFile = new DEMFile(fileSystem.create(mapId + ".DEM"), true);

But you want either a DEMFile or a FileCopier,
you only want the demFile when you need to create it.

handle = fileSystem.create(mapId + ".DEM");

if (checkExistingDem()) {
// Can copy existing one

// Just a rough idea, many details to be filled in...
fc = FileCopier(fileContainingDem);
cl = fc.add(demFilename, handle)
handle.link(() -> demSize, cl);

// Probably would create a new constructor:
// fc = FileCopier(handle, fileContainingDem);
// fc.add(demFilename);
// When the img file is closed then the copy will happen
// automatically.

// demFile = null
} else {
// Need to create it
demFile = new DEMFile(handle, true);
}

Hope that makes some kind of sense.
There are probably a lot of details missing.


reg. FileCopier: I don't see how I can use that class outside of 
GmapsuppBuilder. Maybe you can extract it?

I've already thought about using FileBackedImgWriter. I'll do some tests to 
find out how it influences performance.


Yes it will need to be moved to a top level class and maybe some
changes as well.

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] gmapi reader?

[Steve Ratcliffe]

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 the check outside of DEMFile.

FileCopier acts like a placeholder to the existing DEM in another file
and when the IMG file is closed the data will be copied directly
to the output.

If you always want DEM files to be written to a temporary file
instead of to memory (like the .MDR file is) then you can
use FileBackedImgWriter instead of BufferedImgWriter in DEM file.


think that it would be better to store a reference to the existing file
instead of copying it into memory. The code that writes the new img file
would somehow notice that the data is not in memory but on disk.
No idea if this would really improve anything, maybe the partial reading
of DEM already requires a full copy in memory.
I'll have a closer look at this now.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] gmapi reader?

[Steve Ratcliffe]

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 return ImgFS or GmapFS
chan = fs.open(demFilename, "r")

// read DEM header to check if it can be used.

To copy without having to read it into memory, you can use
FileCopier.

I could implement GmapFS as I was already thinking of doing that so
that we would be able to convert gmapi format to gmapsupp.

Steve


Hi Steve, I hope you can help me out here.

I've implemented a new option --x-dem-reuse which allows to copy the DEM file
from an older map.
My idea is that the option specifies the path to either
1) a gmapsupp or
2) a gmap folder  or
3) a directory containing *.img files
from a previous run with similar dem-dist option and tile boundaries.

If given, mkgmap tries to find the matching *.DEM in any of these formats,
checks if the content matches the wanted boundary and dem-dist option and - if 
ok -
uses the existing file instead of doing the DEM calculations again.

At the moment I have some working quick+dirty code (see attached patch).
I assume the new code in MapBuilder should go somewhere in package 
uk.me.parabola.imgfmt.app,
maybe a new class ImgFinder or so? Or do we already have such code in mkgmap?
What I also don't like is that it copies the data from the existing file into 
memory.
Is there already an easy way to avoid that?

Gerd








___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] missing link

[Steve Ratcliffe]

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://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] missing link

[Steve Ratcliffe]

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

[Steve Ratcliffe]

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

[Steve Ratcliffe]

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 set".

On the other hand there are very few examples of Garmin using the term
and it is mainly used by Garmin users (in both the single word and two
word forms) and almost certainly pre-dates mkgmap.

[To be clear I support removing mapset from our documentation]

..Steve

On 24/01/18 11:35, Mike Baggaley wrote:

Hi Gerd, I have realised that the 3 other mapset mentions I saw were on the
OSM wiki version of the mkgmap documentation, not mkgmap's own, so
presumably an out of date copy. Mkgmap's documentation has one other mention
in my copy, but this has already been removed by the DEM changes on the live
web page. I think map is clearer - I don't have MapSource, but Basecamp's
menu allows managing and installing of maps not mapsets.

Please find attached an updated patch that includes moving the
overview-mapname sentence.

Cheers,
Mike



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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, so I made it calculate the whole file
size and then pick the smallest one.

Unless there is a bug, there should not be any special preference for
larger blocks in the MDR case,

I just did a run with trace information and I got:

INFO: bs=512, whole size=47126016, hb=386, fb=91657, blocks=92043

INFO: bs=1024, whole size=47029248, hb=98, fb=45829, blocks=45927

INFO: bs=2048, whole size=46981120, hb=25, fb=22915, blocks=22940

INFO: bs=4096, whole size=46960640, hb=7, fb=11458, blocks=11465

INFO: bs=8192, whole size=46956544, hb=2, fb=5730, blocks=5732

INFO: bs=16384, whole size=46972928, hb=1, fb=2866, blocks=2867

[ hb = number of header blocks, fb = number of file blocks ]

So the block size = 8192 does seem to give the lowest file size; only
by 4k bytes.

I was a bit suprised, but the number of header blocks needed goes down
by a quarter when the block size is doubled, and that makes up for
the wastage of bigger blocks.

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Automatic block-size setting

[Steve Ratcliffe]

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, overview, gmapsupp and mdr) now
work the same way.

Gmapsupp.img files have always selected an appropriate block size, so
there should not be much change there.  Regular tiles may be a little
bit smaller (~1%) as a larger block size sometime results in a file
that is a bit smaller and if they are large enough to require a larger
block size that will happen automatically.

The osmmap_mdr.img files will typically be a lot smaller as
previously they had a fixed block size of 16M and wasted a lot
of space.  Now the correctly block size will be selected and the
file will be as small as possible.

Currently the --block-size option still exists, but it just determines
the smallest block size that will be used - if it is not large enough
it will be increased.  I could remove the option altogether or make it
override the automatically determined value.

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 it should be 1 and not 2.

The mistake is harmless apart from the file being a little bigger than 
necessary.


..Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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

..Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 img-file
>before 
>anything is actually written to the disk. Wouldn't that be much better?
>


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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 that already :)


The default limit is just a safe value for the files that use 3 byte 
pointers.


Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Steve Ratcliffe]

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
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Rule not working consistently

[Steve Ratcliffe]

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}' | name:int='${int_name}' | 
name:int='${name_int}' |  name:int='${name_en}' | name:int='${name:de}' 
| name:int='${name:fr}' | name:int='${name:es}' | name:int='${name:pt}' 
| name:int='${name:it}' | name:int='${name:nl}' | name:int='${name:dk}' }


The syntax for set is:

  set name:int = '${name:en}' | '${int_name}' | ...

and not

  set name:int = '${name:en}' | name:int='${int_name}' | ...

Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev