April 2015 - mkgmap-dev - The mkgmap lists

address search and case significance of street name
by Gerd Petermann 19 Apr '15

19 Apr '15

Hi all, in some areas, esp. in CZ, I see quite a lot of houses where the addr:street name is slightly different to that of the nearest road. Sample: http://www.openstreetmap.org/way/296555634 has name="K Zahrádkám" (with capital "Z") while some houses, e.g. http://www.openstreetmap.org/way/53658380 have addr:street="K zahrádkám" I thought that this is handled by a bot, but this difference exists now for quite a while. I assume that mkgmap should always ignore case when it compares these tags? Or should that depend on the option "--lower-case" ? Gerd

4 9

incompatibility with Garmin eTrex 30
by Hadmut Danisch 17 Apr '15

17 Apr '15

Hi, I have a question about Garmin device compatibility. I'm generating maps from openstreetmap for my garmin devices, using the workflow * download several pbf map segments as needed for the next trip (usually from www.geofabrik.de ) * combining them into one pbf file with osmosis * split it with splitter * convert the split fragments into garmin format with mkgmap The resulting gmapsupp.img works well on my very old Garmin eTrex Venture Cx , all functions as expected including address search. But on my new Garmin eTrex 30, the address search does not find streets (sometimes 3 or 4 of them). It does display streets in the map view including their correct street names. You can point onto a street and it mentions it's correct name. But address search does not find Streets in most cases. Only a very little number of streets gets known to the device. Any hint or idea about the problem or how to fix it? regards Hadmut

1 0

inc/address and --housenumbers
by GerdP 17 Apr '15

17 Apr '15

Hi all, the default style uses the include inc/address in the finalize rules for points and lines. That means that OSM elements which are not added to the map do not have corresponding tags like mkgmap:city. The problem: For the --housenumber option we want to analyse all elements with addr:housenumber, we don't care if the house is displayed as a polygon or as a point or not at all. With the current default style most houses (= elements with addr:housenumber) do NOT have a tag like mkgmap:city or mkgmap:country. Now, this isn't a big problem in most cases because mkgmap has to attach the address information to a road, and the road is added to the map and therefor is passed through the inc/address rules. I faced two situations where this is not sufficient: 1) A road can connect two or more cities. The current code doesn't care about that. In the LocationHook we set the tags like mkgmap:admin_level8 only once for the road (typically for a point near the middle of the road), we don't recognize the case that different points on the roads are in different cities. A possible solution would be to call the LocationHook for each point on the road and split the road into parts before style processing. 2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works. The problem: With the default style most houses do not have the mkgmap:city tag because no map object is created for them. I think a quick and clear solution would be to add a tag mkgmap:execute_finalize_rules=1 to each element with addr:housenumber to tell mkgmap that even if no map element is created the finalize rules should be executed. I'll implement that in the housenumber2 branch. Please let me know when you see a better solution. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/inc-address-and-housenumbers-tp5840656.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

7 27

change inc/address to be a standalone ?
by Gerd Petermann 16 Apr '15

16 Apr '15

Hi experts, I am not happy with the current code regarding address data. My understanding so far: - we have the --bounds option to specify precompiled bounds - we have the LocationHook that is used to assign tags mkgmap:admin_level2 to. mkgmap:admin_level10 and mkgmap:postcode. - we have inc/address to which uses either the data from the LocationHook or that from the OSM element to set mkgmap:city, mkgmap:region etc. The file inc/address in the default style doesn't care about any other tags, means, the result doesn't depend on the exstence of a highway tag or whether the element is a node, way, or polygon. I think we should change that. My proposal: Instead of inc/address we have a file address (on the same level like points, lines, etc) this file is evaluated before the rules in points/lines/polygons when it exists. Probably the class RuleFileReader should make sure that the files points/lines/polygons do not include another inc/address. Gerd

3 10

housenumbers like 1a
by Gerd Petermann 15 Apr '15

15 Apr '15

Hi Steve, I see that you already started to change display tool. Maybe you can also find out whether the img format supports to distinguish numbers like 1a and 1b ? This is frequently used in Germany and I was surprised to see that Garmin ignores it. Typically one can assume that 1a and 1b are close together, but sometimes they are not. Gerd

3 2

Commit: r3539: Be less sensitive to extra spaces and case differences in the Polish format.
by svn commit 15 Apr '15

15 Apr '15

Version mkgmap-r3539 was committed by steve on Wed, 15 Apr 2015 Be less sensitive to extra spaces and case differences in the Polish format.

1 0

Backtrace with housenumber branch
by Thorsten Kukuk 14 Apr '15

14 Apr '15

Hi, with the latest releases of the housenumber branch, including r3535, I get the following backtrace when building my bicycle map (the trunk version is fine and works): java.lang.NullPointerException at uk.me.parabola.imgfmt.app.net.RoadNetwork.addThroughRoute(RoadNetwork.java:651) at uk.me.parabola.mkgmap.general.MapDetails.addThroughRoute(MapDetails.java:135) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:658) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:250) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:130) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:253) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:249) at java.util.concurrent.FutureTask.run(FutureTask.java:274) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627) at java.lang.Thread.run(Thread.java:863) Exiting - if you want to carry on regardless, use the --keep-going option Number of ExitExceptions: 1 It's the bicycle style from my web page, and I call mkgmap with: mkgmap --style-file=bicycling --family-name=TK-DACH-Bicycling --country-name=DACH --country-abbr=DACH --area-name=DACH --latin1 --license-file=TK-DACH-Bicycling_license.txt '--copyright-message=OpenStreetMap contributors, ODbL. See: http://www.openstreetmap.org/copyright. TK-DACH-Bicycling based on data from 2015-04-13.' --series-name=TK-DACH-Bicycling --product-version=150414 --add-pois-to-areas '--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance' --reduce-point-density=4 --reduce-point-density-polygon=8 --min-size-polygon=8 --polygon-size-limits=24:8,18:4,17:2,16:0 --make-opposite-cycleways --name-tag-list=name,place_name,loc_name --transparent --no-poi-address -c mkgmap.cfg --gmapsupp -c maps.cfg --description=TK-DACH-Bicycling TK_DACH.TYP Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

2 4

r3535 with improved addr:place support
by Gerd Petermann 14 Apr '15

14 Apr '15

Hi all, I think addr:place is now also working well, so please test it. See also the description of changes in the svn log: http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3535 If you think that numbers with addr:housenumber=* & addr:street=* & addr:place=* should not be treated as described, feel free to delete the addr:place tag. I still don't fully understand the special cases in CZ, the page http://wiki.openstreetmap.org/wiki/Cs:WikiProject_Czech_Republic/Address_sy… is not available in english and the Google Translator doesn't help me much, so experts for this area: Please double check. Gerd

1 1

Options
by Gerd Petermann 14 Apr '15

14 Apr '15

Hi all, I'd like to change some defaults. My understanding so far is that most people want a routable map with address search and housenumber search. So, I think the following options should be on by default: --route --net --index --housenumbers --x-split-name-index --link-pois-to-ways --drive-on=detect We (the programmers) have to make sure that --no-xyz really disables these options. These are also candidates, but I think we can leave them optional: --make-opposite-cycleways --process-destination --process-exits Did I find a good selection? @Steve: I tried to implement this but found that some unit tests fail, e.g. TdbTest fails when I just add --net to the default options. Can you have a look at this, please?

4 8

r3527
by Gerd Petermann 10 Apr '15

10 Apr '15

Hi all, I've added addr:place support with r3527. Please note that this required some hacks like duplicating roads where the copies are not routable and adding/changing labels. I did not find routing or rendering problems, but I would not be surprised to hear about them. Please test and let me know. TODO : cleanup and improve code that splits intervals and the methods to find close objects. Gerd

2 8