- mkgmap-dev - The mkgmap lists

POI Index
by Mike Baggaley 06 Feb '15

06 Feb '15

Hi, does anyone know whether it is possible to create POIs, but not have them listed in the Find Points of Interest list? I have things like gates and barriers displayed on my map, but if possible want them to not be searchable. Alternatively, is there another way of displaying these on the map? Thanks, Mike

3 5

point.getPOIRecord
by Mike Baggaley 06 Feb '15

06 Feb '15

Hi, in looking into a possible code change to handle mkgmap:add-to-index=no, I came across what looks like an error in point.getPOIRecord. The code is currently: public POIRecord getPOIRecord() { if (poi == null) return new POIRecord(); return poi; } Which means if getPOIRecord is called twice, it will return a new POIRecord each time. I suspect the code should be: public POIRecord getPOIRecord() { if (poi == null) poi = new POIRecord(); return poi; } However, there may be a valid reason for the code being as it is. Any thoughts? Regards, Mike

2 1

Public transport
by A drian 05 Feb '15

05 Feb '15

I posted to the list last April http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q2/020800.html and there was no response. It seems that, although the post appeared on the mkgmap web site, most subscribers did not receive it because of the Yahoo! problem http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q4/022204.html Therefore I am reposting the message, updated as necessary: I have entered some public transport data into OSM. I have made every effort to enter the data in accordance with the new public transport schema. Some 'old' tags are also present because I started mapping the data before the new schema was approved. For testing purposes I used the extract from Geofabrik of the Languedoc-Roussillon region of France. I used r3433 with the default style and these options: --max-jobs --code-page=1252 --add-pois-to-areas --route --link-pois-to-ways --precomp-sea=sea-20150123211701.zip --generate-sea --index --bounds=bounds_20150129.zip --location-autofill:bounds,is_in,nearest --housenumbers. Looking at the results, I noticed a number of things. (1) Names of railway stations The names of many railway stations appear in the form SNCF: Agde. https://www.openstreetmap.org/way/72614628 This is the result of generic processing of names in the style file inc/name. There are about 3500 railway stations in France and more than half of them are tagged operator=SNCF. I would prefer to see the name in the form Agde SNCF, which was produced by earlier versions of the default style, before the file inc/name was introduced. This is more convenient for searching on a device. (2) Names of bus stops This is an example of the name of a bus stop as it appears in the generated map: Agglo Hérault Méditerranée: (1;2;3;4;5,4,4,3,3)(1;2;3;4;5,4,4,3,3)++ Gare SNCF https://www.openstreetmap.org/node/1424432523 The Garmin software and the device will only display the first part of the string. I used QLandkarte GT to see the complete string. (For legibility, I have used lower case in the strings, although they are in upper case in the generated map.) Earlier versions of the default style produced the result Gare SNCF (1;2;3;4;5,4,4,3,3)+Agglo Hérault Méditerranée, which I prefer. "Gare SNCF" is the name of the bus stop. The earlier version would be essential, to allow you to see the name of the bus stop on a device. What do others think? The solution which I use for my own maps, is as follows. Before line 16 of file inc/name ref=* & (operator!=* & brand!=*) { name '${ref} ${name}' | '${ref}' } insert this line ref=* & (operator!=* & brand!=*) & (highway=bus_stop | railway=tram_stop | railway=halt | railway=station) { name '${name} ${ref}' | '${ref}' } Before line 27 of file inc/name operator=* & brand!=* { insert these 6 lines operator=* & brand!=* & (highway=bus_stop | railway=tram_stop | railway=halt | railway=station) { name '${name} ${ref} ${operator}' | '${name} ${operator}' | '${ref} ${operator}' | '${operator}' } The text 1;2;3;4;5,4,4,3,3 can be changed to 1;2;3;4;5 by using the new not-contained filter as proposed in another thread. The doubling-up of the route_ref and the shelter indicator (+, - or *) is a bug. I will address this in a separate thread. I will leave a further question about public transport for another thread. Adrian

2 3

How to add millions of addresses to your garmin maps of France
by Paco Tyson 05 Feb '15

05 Feb '15

Hi map makers, The french OSM community has recently created an address database for France, under the ODbL licence. By using this database, we can build Garmin maps with 6 times more addresses than only OSM data. It's built from various sources besides OSM data. Thanks to the land tax administration, we french OSM mappers have access to the complete "cadastre" (i.e. building shapes, street names and addresses) covering the entire country. This information, with OpenData adresses and OSM data on the side, is now mashed up into the "BANO" database. 11+ million addresses have been matched to a street name in OSM, 1.4 million addresses are gathered from the OpenData files of several cities, 2.6 million come from OSM. Those numbers will improve over time, as this DB is not complete yet. See a map at [1], green dots are OSM addresses, blue ones addresses matched to a street name, yellow dots are from OpenData files and red are addresses not yet matched to an existing street name. How to add the addresses when creating Garmin maps ? The data is available in CSV format, geographically split following the "département" boundaries (admin_level 6). The steps are : Download a fresh .pbf Geofabrik file of France (admin_level 2) or one of its "région" (admin_level 4) Download the BANO CSV files covering the previously downloaded area Merge the CSV files. Filter address source to keep only matched addresses and OpenData addresses (blue and yellow dots). Convert the CSV format to OSM format. Merge the .osm file to the Geofabrik file. Launch your usual map generation workflow with this new file. I wrote a shell script that does all of the above. It's published on https://github.com/PacoTyson/bano2garmin/ and attached as a zip archive. The prerequisites are awk, wget or curl and osmconvert ( http://wiki.openstreetmap.org/wiki/Osmconvert ). You'll have to edit the script to configure it to your installation : BANODIR=directory where the script will download and store the BANO files PBFDIR=directory where the .pbf files are read and written BINDIR=directory where osmconvert is stored Usage : add-bano-addresses.sh region where region can be france or any of those listed on http://download.geofabrik.de/europe/france.html [1] : http://layers.openstreetmap.fr/?zoom=6&lat=46.4&lon=2.3508&layers=B0000FFFF… Cheers, Paco

5 11

Commit: r3436: use not-contained filter to avoid duplicated values in route_ref,
by svn commit 03 Feb '15

03 Feb '15

Version mkgmap-r3436 was committed by gerd on Mon, 02 Feb 2015 use not-contained filter to avoid duplicated values in route_ref, use semicolon instead of comma to separate the values. Proposed by A drian: "I have chosen the semicolon because it is the recommended separator in OSM https://wiki.openstreetmap.org/wiki/Semicolon Also, using a comma as separator would not fix my example. Another possibility might be to recognise multiple characters as separators, e.g. the semicolon and the comma would both be treated as a separator. This would depend on whether it is feasible to extend Maxim's patch to recognise multiple separators."

2 1

Re: [mkgmap-dev] FW: Lines distorted
by Gerd Petermann 02 Feb '15

02 Feb '15

Hi Dave, I agree that these options are difficult to understand. The options -- polygon-size-limits and -- min-size-polygon use the size of the bounding box of an object. The size is measured in Garmin units. With the style rules you specify the resolutions at which an object should be drawn. For each resolution besides 24 several filters are used to do the rounding of coordinates and smothing of lines for the lower resolution for each object. One of the filters is the SizeFilter which is configured with the above options. If the larger value of width and height is smaller than the given value in NUM scaled by the resolution, the element is dropped before more complex filters are used. So, if you change the value to e.g. 50 you may not find as many small parks or forest polygons at resolution 22 as with the default. The --polygon-size-limits option works similar, but allows to specify different NUM values for the different levels. Gerd From: daveswarthout(a)gmail.com Date: Mon, 2 Feb 2015 19:11:36 +0700 Subject: Re: [mkgmap-dev] FW: Lines distorted To: gpetermann_muenchen(a)hotmail.com Well, it's probably mostly because I'm not at all familiar with the operations required to produce these maps. AFAIK, the options file is the only place some of these parameters are described. For example, --min-size-polygon=NUM Removes all polygons smaller than NUM from the map. This reduces map size and speeds up redrawing of maps. Recommended value is 8 to 15, default is 8. See also polygon-size-limits. What does this mean? "removes all polygons smaller than NUM". Is NUM a length, the number of sides, or what? What effect does it have on the outputted map with a setting of 8 as opposed to 15? I was really hoping there was a manual of some sort that described the processing, the options, etc., with some nice examples and explanatory text. If there is not, I'll just have to learn a little bit every day until I'm up to speed <g> If I ever reach a point where I'm knowledgeable enough to help with the documentation, I would certainly be willing to do that. Thanks, Dave On Sun, Feb 1, 2015 at 4:39 PM, Gerd Petermann <gpetermann_muenchen(a)hotmail.com> wrote: Hi Dave, not sure how to help you. You say that you have a lot of open questions. after reading the docu. Please post them if they are still open or help to improve the documentation. Gerd From: daveswarthout(a)gmail.com Date: Sun, 1 Feb 2015 13:04:45 +0700 To: mkgmap-dev(a)lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] FW: Lines distorted I'm still reading this thread but haven't tried the new mkgmap.jar yet. I was hoping for a way to smooth polygons and Gerd's reply to Enrico indicates that the patch and new binary only help smoothing lines, so I stopped paying attention. But I'm interested in learning more about mkgmap and the map making process in general. I saw another post a while back where Gerd says something along the lines of "people still don't know how to use a patch". The documentation for mkgmap itself is pretty thin. There's the style manual, and the little blurb about TYP files but nothing to tie it all together. And I've not found anything about how to use mkgmap other then the options text file. The explanatory statements in there are helpful but leave a lot unsaid. A careful reading of the "Optimization Options", for example, left me with more questions than answers. You are the developers of the program, so many of these things must seem glaringly obvious. But they are not. How is one supposed to know how to utilize a patch? Is there a users manual somewhere? Thanks, Dave On Sat, Jan 31, 2015 at 4:41 PM, Gerd Petermann <gpetermann_muenchen(a)hotmail.com> wrote: Hi Enrico, I fear I can't change mkgmap to fix this problem. The problem is more or less bad luck. In some cases, you have placed the points of the ways more or less exactly between the points of the Garmin grid, others are very near to the grid points. If I got it right, we can only produce a straight line in the garmin format when we allow to move certain points by more than 2 metres, and in that case the WrongAngleFixer will prefer the correct position to the bad angle. I''ve attached the grid as a gpx file, if you load that into JOSM you probably see what I mean. If you prefer "nicer" rendering on the Garmin map you may move some points closer to the grid to solve the problem. Gerd > Date: Fri, 30 Jan 2015 09:40:37 -0700 > From: e.rossini73(a)alice.it > To: mkgmap-dev(a)lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] FW: Lines distorted > > yes you'are right, I'm interested to straight out the line "Via Ronchi Di San > Francesco Di Paola". > would be great if you'll find something to do this. > THANKS. > --enrico > > > > > -- > View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831971.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

1 0

Bug in handling of bus stops
by A drian 02 Feb '15

02 Feb '15

This bug was highlighted in r3334 when the test public_transport=platform was added to these four rules in the default points style file (lines 45-63): (public_transport=platform | highway=bus_stop | railway=tram_stop | railway=halt | railway=station) & (ref=* | route_ref=*) { set ref='${ref|def:}(${route_ref})'; } (public_transport=platform | highway=bus_stop | railway=tram_stop | railway=halt | railway=station) & lit=yes & (shelter=yes | covered=yes) { set ref='${ref|def:}*'; } (public_transport=platform | highway=bus_stop | railway=tram_stop | railway=halt | railway=station) & lit!=yes & (shelter=yes | covered=yes) { set ref='${ref|def:}+'; } (public_transport=platform | highway=bus_stop | railway=tram_stop | railway=halt | railway=station) & (shelter=no | covered=no) { set ref='${ref|def:}-'; } What happens is that if a node has two of the tags in the list public_transport=platform | highway=bus_stop | railway=tram_stop | railway=halt | railway=station then the node is processed twice by each rule, so the route_ref and the shelter marker (*, + or -) are doubled-up. Looking at https://www.openstreetmap.org/node/1424432523 - this node is tagged public_transport=platform and highway=bus_stop. Prior to r3334, the node had only one tag that matched and there was no doubling-up. From r3334 onwards, there are two tags that match and the result is Agglo Hérault Méditerranée: (1;2;3;4;5,4,4,3,3)(1;2;3;4;5,4,4,3,3)++ Gare SNCF. I believe it is not intended that style rules should work in this way, therefore it is a bug in the code. In which case it is a question for the Java experts. Adrian

4 8

[Patch v2] avoid duplicate evaluation of rules
by Gerd Petermann 02 Feb '15

02 Feb '15

Hi all, cosmetic change : always report the new rule-id field in the style stats. binary: http://files.mkgmap.org.uk/download/245/mkgmap.jar Gerd

1 0

Copyright message not showing up starting 3433
by Ervin Malicdem 01 Feb '15

01 Feb '15

Hi I believe we had a change regarding copyright messages on 3430. It seems on 3433, Copyright message is no longer shown on the device (About page or About>Detailed Maps page) I am only using license text and copyright message but not copyright file. License text is showing up without problems on Basecamp but Copyright Message is no longer seen on the device. I test it on Nuvi 1360 and GPSMap 62s. Thanks. Ervin M. *Schadow1 Expeditions* - A Filipino must not be a stranger to his own motherland. http://www.s1expeditions.com

2 2

Commuter rail stations
by Brian Egge 01 Feb '15

01 Feb '15

When I look at POIs with a Garmin map, I have a category for 'Suburban Rail Station'. In the NYC area, there are hundreds of commuter rail stations and a handful of regional stations. Having the two listed separately in the POI search is useful, as usually you are searching for one or the other. When using an mkgmap, it only has the single railway station type. I believe the suburban railway stations can be tagged with commuter=yes, but I do not know what Garmin hex code causes this category to appear. Any idea what the code is or how to figure it out? Brian

2 1