May 2009 - mkgmap-dev - The mkgmap lists

maxspeed tag vs road_speed preset
by Marco Certelli 21 May '09

21 May '09

Hi First of all: great job. And now, my issue: I'm trying to make some personal styles but I encountered the following problem: if a highway has a maxspeed tag in OSM, whatever road_speed I put in the style, it seems it is ignored for a value that is decided by mkgmap based on the OSM tag. If I put some lines like those: .... highway=trunk & maxspeed>100 [0x02 road_class=4 road_speed=5 resolution 16] highway=trunk & maxspeed>80 [0x02 road_class=3 road_speed=5 resolution 16] highway=trunk & maxspeed>60 [0x02 road_class=3 road_speed=4 resolution 16] highway=trunk & maxspeed<61 [0x02 road_class=3 road_speed=3 resolution 16] highway=trunk [0x02 road_class=3 road_speed=5 resolution 16] .... it seems it is not working as I expected: if the trunk has a maxspeed tag in OSM, it always get a road_speed value that is independent by the one I've declared in the style (I don't know if it is the same for the road_class); if the trunk has not maxspeed, it takes the default row (last one) in the style. I'm sure the style row is parsed and selected correctly in accordance with the maxspeed tag, but the road_speed is not set as I would like. If this is a wanted feature of mkgmap, the relationship between the maxspeed in the OSM data and the road_speed parameter given to the way should be configurable in some way and should be configurable per highway type. Can you help me? Ciao, Marco.

3 5

Re: [PATCH v1] Re: [mkgmap-dev] maxspeed tag vs road_speed preset
by Marco Certelli 21 May '09

21 May '09

Hi Greg Troxel <gdt(a)ir.bbn.com> 1st: I do not know very well how to keep the answer in the same thread... anyway, I do not think there is a simple way to hard-code a proper speed of a road that is right for all cases (expecially if it is indifferentiated for all highway types). I can speed on a city road at 60 km/h during night and 15 km/h during day (yes, 15 km/h is the average speed in Rome, as measured by the public transportation company). Maybe only real time traffic information systems can work well in such messy cases. And of course I can just imagine the endless discussions for each road about the right value to give to an "average_speed" tag... Much better would be to automatically calculate an average_speed tag by using all information the OSM DB already have: the highway type, the maxspeed tag, the number of crosses per kilometer, the curves (radius and frequency) and also the available GPX real speed data. For now I think much simpler: a tertiary road in the countryside, maybe full of curves, slopes, narrow points, you might have a "law limit" of 90 but you will never go to 90. I'd say 60 average. In the same countryside, a primary road is wide, straight, has precedence over smaller roads, but the limit is still 90. I'd say you go 90 average. Back to the city: both tertiary and primary share a maxspeed of 50, then you go maybe at 40 on tertiary and only slighlly faster on primary. highway=tertiary & maxspeed>60 [... road_speed=3 ...] highway=tertiary & maxspeed<61 [... road_speed=2 ...] highway=primary & maxspeed>80 [... road_speed=5 ...] highway=primary & maxspeed>60 [... road_speed=4 ...] highway=primary & maxspeed<61 [... road_speed=3 ...] If you want I can post my style file (I'm still workin on it...). I think this speed differentiation would help the router to guess the right way and the right ETA both inside the city and outside. In Java, someone smarter could count crosses per kilometer or curve radius. Maybe next year... Ciao, Marco.

3 2

[PATCH v1] Re: [mkgmap-dev] maxspeed tag vs road_speed preset
by Marco Certelli 21 May '09

21 May '09

Hi, and thaks for your answer. I'm not a developer so I really have some problem in applying the patch locally... I just would like to keep control over the map generation. For example: in Italy the maxspeed out of the city is 90km/h. It applies to unclassified roads up to trunk roads (well, some trunks has 110 km/h). I would like to code in the map in a way that a tertiary with 90km/h speed limit gets road_speed 3 (i.e 60 km effective speed), while a trunk with the same 90km/h limit gets road_speed 5 (i.e 90 km/h effective speed). You can immagine for the secondary and primary. I looked at the source and you coded: if maxspeed>40 then road_speed=3 It means that in the Italian cities (limit=50) the average speed coded in the map is 60km/h. It looks strange to me and carries to very "optimistic" city ETA calculations (and maybe not optimal route selection). Moreover, I sow other map makers (DE:All_in_one_Garmin_Map) making maps including the maxspeed tag management in their styles (but maybe they use a patched mkgmap). So, if it counts I do vote for the switch --ignore-maxspeed and I vote to integrate the patch in the mainstream mkgmap (again, I'm not able to compile the code). As you may have understood, I'm using Windo.....%$&"/$£/$=)"(/$)"&)%$()"% Sorry, my PC crashed while I was writing Windo.....=)/(/£%&(/&"/(&$"/=)"30/()/&89 Ciao, Marco.

2 1

What about a Address Index?
by dom 20 May '09

20 May '09

Hi, I'm new on the mailinglist, and I'm interested in doing some development work, as far as I have enough time for doing. I'm personally missing a address index which allows do search for addresses directly and not via a workaround with different styles and maplayers. So is there anybody who has an overview how such a index is generated or is there a binary structure available? Or is there already somebody working on it? Regards, Marco

2 2

Greetings from Bratislava
by Jani Patanen 20 May '09

20 May '09

Hi. I know that pedestrian routing with garmin is not high priority, but just in case.. Visiting Bratislava I noticed some wierd route suggestions walking trough old town. The main reason seems to be that there are plazas, which are not routed trough as it's area without any road continuing trough. Have a look at http://www.openstreetmap.org/?lat=48.14347&lon=17.10748&zoom=17&layers=B000… and for example "Hlavne Nametie" (the plaza at the middle). No pedestrian routing trough that as on garmin there is no road. In OSM data, it's tagged as area=yes highway=pedestrian restriction=foot (Bad tag?) Perhaps a change where the area is still drawn as area, but the roads would be drawn too?

2 1

[PATCH v10] make maps in parallel
by Mark Burton 20 May '09

20 May '09

Changed default number of threads to be 1. If you specify --max-jobs without a value, you get one thread per core. --max-jobs=N means use N threads. With regard to comparing the output with known good maps to see if the parallel processing is corrupting anything, one problem is that the files contain timestamps. I have test code that zeros the time stamps and have been able to compare the output from different runs. What I have seen is that sometimes there are differences that appear to be due to the order in which the labels are written to the output file. If only the order is changing that is harmless but it would be nice to understand how it's happening (I have a theory about this, yet to be proven). --------- Now preserves order in which files are combined (thanks Steve for the tweak). --------- Now serialises reading of style files and map source to avoid reentrancy issue in GType. Reworked top-level loop that waits for the parallel jobs to complete. Appears to use a lot less CPU and could possibly influence the weird problems some were reporting on Windows/Mac - please retest with this version. Steve, I haven't incorporated your changed options handling stuff yet but will do in the future if (a) you don't commit it separately and (b) we can fix the reliability issues with this parallelisation code. --------- Now respects --num-jobs again (broken in last patch). --------- Now reports exceptions in the worker threads. --------- Here's a better fix than last night's effort for the problem where the mapname and description for each job were getting clobbered due to the way that the command args are processed. Each job now gets a "snapshot" of the command args so it doesn't matter if they subsequently get changed. --------- Whoops! fixed a bad bug whereby each map was being output to the same file. Not sure if the fix is very elegant but at least it's not being silly any more. Now limits the default value of max-jobs to 4 no matter how many cores you have as further testing shows that having more threads just burns CPU cycles but doesn't actually finish any quicker. I guess the memory system is limiting the performance and the CPUs are spinning waiting for access. Now showing a real speedup of around 240% (my earlier higher claim was based on CPU usage and I now realise that was erroneous, sorry). -------- Now defaults to creating a thread per core so without doing anything you should see a speedup on a SMP box when processing multiple maps. You can use --max-jobs=N to limit the concurrency - you may want to specify that if you can't increase the VM size to what is required. However, it occurs to me that if you can afford a box with more than 2 cores, then you can probably afford a reasonable amount of memory (otherwise, what's the point in having more cores?) Added help blurb. -------- OK, let it not be said that I don't listen to others! The attached patch provides support for making maps in parallel. By default, the behaviour is the same as before but if you specify --num-threads=N where N is greater than 1, it will process N maps at the same time and then combine the results (if required). Don't forget to increase the heap size appropriately. A quick test on the big box shows good speedup - specifying --num-threads=4 and 2GB VM size. I was seeing better than 380% utilisation with 8 cores in use. I suspect the performance limitation here will be VM size and memory system bandwidth. BTW - I don't think num-threads is actually the best name for the option, so please suggest alternatives. Cheers, Mark

6 15

[PATCH v1] quick distance calculation
by Mark Burton 20 May '09

20 May '09

Folks, OK, so the parallelisation code has not been very successful so far but we can still speed up mkgmap. You have probably noticed that it spends a huge proportion of its time in Math.acos() which is being called from Coord.distance(). The attached patch renames distance() to slowDistance() and introduces a new quickDistance() function that is based on the code that was in the MultipolygonRelation class. I have tested quickDistance() against slowDistance() and for maps in the UK and Germany it produces distances that are very similar (within 0.5% or better). It is substantially faster and so I believe we should change to using it as long as it doesn't introduce any issues. So please try out this patch and report: a - if any breakage is observed b - performance increase/decrease Cheers, Mark

4 8

[PATCH] - Code for Highway Symbols
by Thilo Hannemann 19 May '09

19 May '09

Attached is a patch by Toby Speight that allows to insert the code for highway symbols. I'm using it since a while with no adverse effects. Is there any chance that it gets integrated into trunk? Or if there is a problem with that code, what should be changed in order to make if fit for integration? Best regards Thilo

2 1

Splitter Problem.
by Stuart Poulton 19 May '09

19 May '09

Hi, Using the following on the GeoFabrik GB OSM file which is 1.7GB java -Xmx2000m -jar $PWD/software/splitter/splitter.jar $PWD/../data/ great_britain.osm This splits the osm file into 8 sections as follows (decompressed): 88M May 18 19:09 63240001.osm 127M May 18 19:09 63240002.osm 44M May 18 19:09 63240003.osm 154M May 18 19:09 63240004.osm 133M May 18 19:09 63240005.osm 108M May 18 19:09 63240006.osm 105M May 18 19:09 63240007.osm 119M May 18 19:09 63240008.osm I get 'Relation xxx in too many ways' for 4 relations. The above come to ~800MB whats happened to the remaining 900MB ? Full output can be seen in the following pastebin http://pastebin.ca/1426624 Can anyone provide some insight ? Cheers Stuart

3 3

[PATCH] enable xinclude in parser
by Christian Gawron 19 May '09

19 May '09

Hi, the attached patch enables the xinclude feature in the SAX parser. I found this useful to create maps with contour lines without having to merge the osm files: <?xml version='1.0' encoding='UTF-8'?> <osm version='0.5' generator='JOSM'> <xi:include href="contours.osm" xmlns:xi="http://www.w3.org/2001/XInclude"/> ... BTW: I wrote a little Java program to generate contour lines from the CGIAR GeoTIFFs. Is anyone interested in testing it? Best wishes Christian Index: src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5MapDataSource.java =================================================================== --- src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5MapDataSource.java (Revision 991) +++ src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5MapDataSource.java (Arbeitskopie) @@ -63,6 +63,8 @@ try { InputStream is = openFile(name); SAXParserFactory parserFactory = SAXParserFactory.newInstance(); + parserFactory.setXIncludeAware(true); + parserFactory.setNamespaceAware(true); SAXParser parser = parserFactory.newSAXParser(); try {

5 4