April 2017 - mkgmap-dev - The mkgmap lists

Possible problem with global search index since r3875
by Gerd Petermann 10 Apr '17

10 Apr '17

Hi all, I've just noticed that I may have introduced a problem with r3875. Road names containing special characters 0x1e and 0x1f are treated different now. I am not sure where those characters appear in names. I think they are used to store so called double byte characters within a single byte character string, at least that's what I remember from working time with customers from Japan. In the mkgmap code it is called a prefix, so maybe something completely different. I did not yet find an input file where this occurs. Can anybody point me to one? Gerd

3 10

gaps in road and other issues with r3875
by lig fietser 09 Apr '17

09 Apr '17

Hi, Users of my OFM map have reported gaps in the roads (mainly non routable lines used for highways that are forbidden for cyclists). I've found out this is worse in the latest mkgmap releases 3875, 3880. See the screenshot, the location is https://www.openstreetmap.org/?mlat=51.59253&mlon=5.33765#map=19/51.59253/5… I have also compiled it with r3847, no gaps. There are other issues. With the default style I cannot even get a working map from the osm file. Something with the overview map is blocking it all? Really strange, if I open the img with gpsmapedit I can see it contains all the data, so something must be wrong with the index or overview files too. I have found out it makes sense if I leave the %typfile% option out or not (see java command below). With no typefile specified, mkgmap r3875 does not show a map. With some typfile behind %argsfile%, everything works as expected (default style does not show a gap). I also noticed this mkgmap version crashed on the license file, something has changed there too? It contained a ©mark. Only after replacing it with (c) mkgmap could finish the job. java -Xmx4000m -jar %MKGMAP% --product-version=%version% --output-dir=%date% --family-id=%FID% --overview-mapname=OFM_%mapname% --series-name="OFM (%mapname%v%date%)" --family-name="OFM (%mapname%)" --area-name="OFM_%mapname%(%date%)" -c %argsfile% %typfile%

3 13

Commit r3889: revert most changes from r3857, they seem to cause incorrect maps under certain circumstances
by svn commit 09 Apr '17

09 Apr '17

Version mkgmap-r3889 was committed by gerd on Sun, 09 Apr 2017 revert most changes from r3857, they seem to cause incorrect maps under certain circumstances http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3889

3 4

Commit r3890: revert unintended change in build.xml
by svn commit 09 Apr '17

09 Apr '17

Version mkgmap-r3890 was committed by gerd on Sun, 09 Apr 2017 revert unintended change in build.xml http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3890

1 0

Problem with regular expression and subst: filter
by Carlos Dávila 07 Apr '17

07 Apr '17

I want to add the following rule to my "Latin languages manage system": highway=* & name ~ "(?i)Chemin\s+d['’´]+acc[èe]s\s+[àa]\s+la\s+.*" { add streettype:movedend="${name|subst:(?i)Chemin\s+d['’´]+acc[èe]s\s+[àa]\s+la\s+~>}, Chemin d'accès"} It catches "Chemin D'Accès à la Piscine" and "Chemin D'Accès A la Piscine", but not "Chemin D'Accès À la Piscine" (note the difference in à, A or À) If I use rule highway=* & name ~ "(?i)Chemin\s+d['’´]+acc[èe]s\s+À\s+la\s+.*" { add streettype:movedend="${name|subst:(?i)Chemin\s+d['’´]+acc[èe]s\s+À\s+la\s+~>}, Chemin d'accès"} then the third form is caught, but obviously the other ones not. Any idea why first rule is not working for all forms?

2 2

new branch optimize-index
by Gerd Petermann 07 Apr '17

07 Apr '17

Hi all, I have started this branch to experiment with some optimizations regarding peak memory and index size reduction. Compared to trunk this branch produces different output, and I am not yet sure if that is good or bad, so use with care. Gerd

1 0

Commit r3880: refactoring: move field refLabels from MapObject to Polyline
by svn commit 06 Apr '17

06 Apr '17

Version mkgmap-r3880 was committed by gerd on Thu, 06 Apr 2017 refactoring: move field refLabels from MapObject to Polyline The field is only used in Polyline, so we waste its memory in class Point. There is also no need for a public getter now. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3880

1 0

Commit r3879: re-introduce flag TREAT_AS_NODE_MASK which is used by display tool
by svn commit 06 Apr '17

06 Apr '17

Version mkgmap-r3879 was committed by gerd on Thu, 06 Apr 2017 re-introduce flag TREAT_AS_NODE_MASK which is used by display tool It was removed with r3857 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3879

1 0

Re: [mkgmap-dev] [Patch v1] improve mdr7 index
by Alexandre Folle de Menezes 05 Apr '17

05 Apr '17

Hi, Em 05/04/2017 11:03, Gerd Petermann escreveu: > The removement of those strings is done from the end, it stops when a word is found that should not be deleted. This is what I described as 1a) here: > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q2/026584.html > This approach won´t work on any Latin language (Spanish, Portuguese, Italian, French), where you should start removing from the beginning instead. Alexandre

3 2

Meaning of option --x-mdr7-excl
by Gerd Petermann 05 Apr '17

05 Apr '17

Hi all, I did not yet document this option because I don't think that it is useful as it is implemented now. I think it works fine for english speeking countries with road names like "Abc Street" and "Xyz Road". Using --x-mdr7-excl=Road,Street in combination with --x-split-name-index will work fine. A different picture is a frensh country. Let's look at an example. Assume you have options --index and --x-split-name-index The road name "Chemin de Pierre Froide" is added to the index as "Chemin de Pierre Froide" and because of --x-split-name-index the following extries are also added: "de Pierre Froide" "Pierre Froide" "Froide" Now, would you expect a change if you use option --x-mdr7-excl=Chemin,Rue,Aveue ? And what would you expect with --x-mdr7-excl=de,du,la ? With the current implementation there would be no change in output, because the the check works in this way: Build the string that should be added to the index Check if that string is in the exclude list, if not, add it to the index. I might change that like this: Build the string that should be added to the index Check if the first word in that string is in the exclude list, if not, add it to the index. With this change the option --x-mdr7-excl=Chemin,Rue,Aveue would exclude the entry "Chemin de Pierre Froide" and --x-mdr7-excl=de,du,la would exclude "de Pierre Froide" Another option would be to allow regular expressions in the exclude list, but that would require more effort (input file instead of single option) and probably much more run time. I'd prefer to have a logic which first analyses all strings added by the --x-split-name-index option so that only those are generated which do not appear more than x % . Comments? Gerd

5 9