Hi Steve, good to see that you are back :-) Interesting for me: TypViewer 0.4.22 doesn't like that comment as well. I also found that the mkgmap typ compiler produces a result for the typ files in https://github.com/berndw1960/aiostyles that TypViewer doesn't like. So I leave these problems to you ;-) Gerd Steve Ratcliffe wrote

Hi Gerd

...

Maybe this is to simple, for example, you will not be able to use Strings containing a semicolon. Could this be the reason why Steve coded it more complex?

The Xpm file part is tricky because semicolons and spaces are sometimes significant.

You need to be able to handle something like this.

[_polygon] Type=0x14 Xpm="32 2 4 1" "; c #7BCA6A" "# c #7B956A" "3 c #BDCA8B" "4 c #BDCA8B" ";;;;;;;;;;;;###;;;;;;;;;;;;;;;;;" ";;;;;;;;;;;#;;##;;;;;;;;;;;;;;;;"

So I think that using setCommentChar() is out. But checking for comments only at the beginning of the line would be OK I think. Probably at the end too if it doesn't already.

..Steve _______________________________________________ mkgmap-dev mailing list

mkgmap-dev@.org

http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- View this message in context: http://gis.19327.n5.nabble.com/problem-with-TYP-compilation-tp5756635p575733... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Hi, I'm the author of TYPViewer. <<TYPViewer doesn't seem to like any comment lines except those it puts in itself>> No, this is not true, but the semicolon introduces a comment only if it is set at the beginning of the line. In your example, there is a quote before the semicolon,so it is not considered by TYPViewer as a comment. TYPViewer works on binary typ files. When it opens a text typ file, the typ file is immediately compiled in binaries and then it is translated in text for displaying in the visualisation box. In this process, all the comments are lost because, when compiling, TYPViewer ignores the commentary lines. But AFAIK, there is no problem with TYPViewer and the semicolon. Sherco40 -- View this message in context: http://gis.19327.n5.nabble.com/problem-with-TYP-compilation-tp5756635p575824... Sent from the Mkgmap Development mailing list archive at Nabble.com.

El 23/04/13 19:29, Patrick Steiner escribió:

Hi,

I currently playing around with the address index of garmin devices. I created a address index via a prebuild bounds file. But I had some problems finding streets. So I created my own osm-bounds file (with osmfilter and osmconverter). I didnt build an osm file instead of an o5m file. I loaded the file into josm and saw, that the problem is only in citys which are splitted into districts. So I tried to use the districtname as cityname and everything works fine. Is this a known problem. Or is there any workaround for this problem?

Maybe this screenshot helps ;) http://twitter.com/paaast/status/326230133012836353/photo/1 Names used by mkgmap for cities, regions, etc. are set in a file called addresses, placed in the styles/default/inc folder (if you are using default style), based on the admin_level value of boundaries. These names are configured individually for some countries and with a general rule for the rest of countries. If you find mkgmap is not using the correct city name for your country, you should tune addresses file for it (please share your values with the list if you think current default values are wrong).