October 2013 - mkgmap-dev - The mkgmap lists

german umlauts äöü in style files
by joern de 19 Oct '13

19 Oct '13

Hi @ all, since a couple of months I struggle with german umlauts äöü in style files. My task is: man_made=windmill [0x2c04 level 0 default_name 'Windmühle'] man_made=watermill [0x2c04 level 0 default_name 'Wassermühle'] The code-page in my args-file is set to 1252, the style is saved with WinXPs notepad as ANSI and as UTF-8; both produce the same unexpected output: the "ü" becomes always a "?". Same happens when I set the name explicitly {name 'Windmühle'}. My TYP.txt is saved as ANSI as well and the "äöü" works as expected. I'm not able to patch the mkgmap sources to apply other people's patches to run own tests, so I ask goggle and bing for solutions for ages. But all I get is Ulf's mail from 2009 ( http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001436.html) Hopefully someone has a clue, joern.de

2 1

mergeroads branch - how to set street labels in style files
by WanMil 18 Oct '13

18 Oct '13

Hi all, I am thinking about how to simplify setting the four possible labels of streets / POIs. This is what I think how it works: Each street and POI can have four different labels. At the moment the following procedure is used to assign them: All labels are filled with the values of name mkgmap:display_name mkgmap:ref (splitted by ";") This means in detail: 1st label: highway shield for the first reference. Usually the name of the street is added separated with a space. Some Garmins display the whole label shielded, some show only the part until the first whitespace. Some Garmins show this as street name when the street is selected and they show the 2nd when the details of the street are shown (Oregon 400 behaviour). 2nd-4th label: in case mkgmap:display_name is set it is used as second label. The value of mkgmap:ref is splitted by separator ";" and fills the rest of the available labels. In case the 1st label starts with a shield the 2nd label is usually displayed in routing instructions. Street search indexes all four labels. So a street with the following labels: 1st: <shield>L276 Laacher Straße 2nd: Laacher Straße (L276) 3rd: L276 can be searched via all three labels (except the shield character in the 1st label). =========================== My questions: - Do you think the current behaviour is useful? - @Steve: Would it be possible to index not all labels? Change the upper example to: 1st: <shield>L276 Laacher Straße 2nd: Laacher Straße (L276) 3rd: L276 4th: Laacher Straße In case the first label starts with a shield and there are at least three labels, then start indexing at the 3rd label. In any case skip the shielded label. This removes all strings with a shield which I think are not useful for address search. I am not sure if that really makes sense but just let us thinking around ... :-) - Should we change the usage of the labels to the following algorithm: Use: name mkgmap:display_name mkgmap:streetname mkgmap:ref (splitted by ";") Only add labels if they don't equal the labels before. So if mkgmap:streetname is the same like the name of the street it will not be used as label. I am happy to hear about your opinions and ideas! Have fun! WanMil

5 15

display tool: NodDisplay
by Gerd Petermann 18 Oct '13

18 Oct '13

Hi Steve, if I got this right, the NOD file format is not designed to be read sequentially, at least not the NOD 1 part. My understanding is this: We write one NOD 1 section for each RouteCenter instance. The offset to the beginning of such a section is only (?) stored in NET, and it is difficult to calculate it. All offsets to nodes are stored in NOD 2, except for the 1st ones, which are stored in NET only(?). Is this true for all maps? If yes, NodDisplay should rather use these offsets to display NOD 1 data, this would avoid lines like 00001334 | 0012a7 | f2 | low f2 | | | lost sync calc-end=4fcd, should be=2bcd and 0000c950 | 00c8c3 | 00 | low 0 | | | spurious 0? | | | | | | New node 0000c951 | 00c8c4 | 00 | low 0 | | | spurious 0? | | | | | | New node If you agree I'll create a patch to implement that. Gerd

2 2

Commit: r2765: use MapLine.copy() so that MapRoad is not changed to MapLine
by svn commit 18 Oct '13

18 Oct '13

Version 2765 was committed by gerd on Fri, 18 Oct 2013 use MapLine.copy() so that MapRoad is not changed to MapLine

1 0

Are there also possibilities to set more name fields for points?
by Felix Hartmann 17 Oct '13

17 Oct '13

I would love to have any city/point to be searchable by a) it's local name b) it's international name if it exists. Currently I just double all cities and put them with the name:int or name:en again as a city into the map. However it would be much better if I could simply add additional name fields to each, and be sure that they are also searchable. Also - would this only apply to city search, or could the general address search even be made multilingual? E.g. doesn't matter if you type Germany or Deutschland for country name when searching for an address. -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

2 1

replace mkgmap:bike with mkgmap:bicycle for merge-roads branch
by Felix Hartmann 17 Oct '13

17 Oct '13

It's really unlogical why mkgmap expects the access restriction mkgmap:bike instead of mkgmap:bicycle... (a it has always been bicycle=no, b) the osm tag is bicycle not bike, c) all other tags are using the standard garmin names.... Overall I must say I'm still not too happy with the results of the branch right now. It's now much slower (about 15%), the access rules are difficult to handle in style (I can see that they are needed, but that only no is accpeted is not really useful ), bugs in reading added values and checking for them is really painful. E.g. if I add oneway=-1 to something, then I need to check for highway=* & oneway=-1 in order to get it. I'm not sure if this bug also exists in trunk - as I just rather recently 3-4 weeks ago deleted all (if mkgmap was working correctly) highway=* usages out of my style - because I thought I could speed up mkgmap by doing it. I don't really understand how the different name fields work right now, well and for what they can be applied (points only, or also polygons and lines...). -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

2 1

Commit: r2762: Changes to code-page and TYP .txt files.
by svn commit 17 Oct '13

17 Oct '13

Version 2762 was committed by steve on Thu, 17 Oct 2013 Changes to code-page and TYP .txt files. If the .txt file begins with a BOM character, then the file is in utf-8 (or -16, but we don't support that) so do not try to read it in the CodePage character set and encoding. Also the --code-page option completely overrides any CodePage directive in the file. The advice now is that .txt files should be in utf-8 and there is no need for a CodePage directive.

1 0

typ file editor
by Marek Greško 16 Oct '13

16 Oct '13

Hello, I would like to edit my typ files, but online editor at ati.land.cz is no longer available. As I found it was perl script with BSD license but I cannot find any sources. Does anybody have link to the sources? I have also additional question. Does mkgmap need the typ file to be in the same code page as the map will be? I. E. will it convert the typ file code page to the map code page while creating img file? Thank you Marek

2 2

Commit: r2761: Re-enable testAllRuleFiles from ScriptedStyleTest.
by svn commit 16 Oct '13

16 Oct '13

Version 2761 was committed by steve on Wed, 16 Oct 2013 Re-enable testAllRuleFiles from ScriptedStyleTest. It currently fails in more ways than it did when it was disabled.

1 0

Re-enable test, so no new trunk builds until it is fixed
by Steve Ratcliffe 16 Oct '13

16 Oct '13

Hi I am going to re-enable the ScriptedStyleTest so that it can be fixed. As a result there will be no new trunk builds on the website until this test is fixed. The branch builds will not be affected, since the tests are not required to pass before adding them. ..Steve

1 0