October 2011 - mkgmap-dev - The mkgmap lists

Defer relations does not work with PBF
by WanMil 21 Oct '11

21 Oct '11

Marko, you have commited the defer relation lookup feature (r1466). It is not implemented for the PBF loader. Do you still use this feature? Can you give an example where this feature is useful? I have the feeling that it might not be used because otherwise someone should have complained that it is not working for pbf files?!? WanMil

2 3

Perculiar index search concerning bus_stops
by toc-rox 21 Oct '11

21 Oct '11

It seems that the index search doesn't work correct for POIs which occur very often. Remarks: - Haltestelle (german) = bus stop - Compiler = r2049 Screenshot (BaseCamp OS X) - result OK (many bus_stops available): http://gis.638310.n2.nabble.com/file/n6892353/Haltestellen-OSX.png Screenshot (Dakota 20, FW 4.70) - result NOK (only a few bus_stops available): http://gis.638310.n2.nabble.com/file/n6892353/Haltestellen-Dakota20.bmp Questions: - Has someone observed similar effects? - Has someone an idea concerning the reason? Regards Klaus PS: I have the same effect for power towers. -- View this message in context: http://gis.638310.n2.nabble.com/Perculiar-index-search-concerning-bus-stops… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 2

Commit: r2050: Add option pois-to-area-placement to configure the placement of POIs created from areas
by svn commit 21 Oct '11

21 Oct '11

Version 2050 was commited by wanmil on 2011-10-19 19:56:55 +0100 (Wed, 19 Oct 2011) Add option pois-to-area-placement to configure the placement of POIs created from areas The options defines an ordered tag-value list to configure which node of a polygon tagged with one of the tags from the list is used as POI. This is an addition to the add-pois-to-area option.

3 3

Patch to reduce memory usage by interning strings.
by Kristen Eisenberg 20 Oct '11

20 Oct '11

On 31/03/10 14:56, Scott A Crosby wrote: > I noticed that mkgmap does not intern any strings. In particular, this This is true. There is a pending patch that deals with excessive memory use in a slightly different way which is on the style-speed branch, with a pre-built one available at the bottom of the mkgmap download page. I drops all tags that are not used by the current style and as an extra feature it ensures that there is only copy of all the strings on the key side. Could you try it out please. It may be worth also interning the values but when I was looking at it there was much less benefit for the maps I was looking at (but it might vary with the input). I'd be happy to apply a patch that interned the values too if there was a decent memory saving without a significant performance drop. I think the point that Chris brought up applies mostly in cases where there is a lot of contended access between threads. If that is the case then it won't matter much for us as reading the input files is currently single threaded. Kristen Eisenberg Billige Flüge Marketing GmbH Emanuelstr. 3, 10317 Berlin Deutschland Telefon: +49 (33) 5310967 Email: utebachmeier at gmail.com Site: http://flug.airego.de - Billige Flüge vergleichen

2 1

[PATCH v1] Further reduction of the builtin-tag-list
by WanMil 20 Oct '11

20 Oct '11

The patch removes the two tags "type" and "maxspeed" from the builtin-tag-list. This reduces memory requirements (a few) if these tags are not required. Tag "type": The tag is mandatory for relations. So I think it's ok to implement a rule in the relation loader that keeps the "type" tag. For nodes and ways the type tag is used only if it is referenced in the style file. Tag "maxspeed": In case the ignore-maxspeeds option is set the maxspeed tag is loaded anyhow. The new MaxspeedHook adds the maxspeed tag to the used tags only if the ignore-maxspeeds option is not set. Any objections or comments? WanMil

5 5

Commit: r2052: Country names are assigned by the name-tag-list option when using precompiled bounds
by svn commit 19 Oct '11

19 Oct '11

Version 2052 was commited by wanmil on 2011-10-19 20:32:35 +0100 (Wed, 19 Oct 2011) Country names are assigned by the name-tag-list option when using precompiled bounds The precompiled bounds contain the country names in many languages. When using them the name-tag-list option is now used to retrieve the normalized country name.

1 0

Commit: r2051: Boundary precompiler uses a finer detection if a boundary is usable
by svn commit 19 Oct '11

19 Oct '11

Version 2051 was commited by wanmil on 2011-10-19 20:17:17 +0100 (Wed, 19 Oct 2011) Boundary precompiler uses a finer detection if a boundary is usable The detection if a boundary is usable now checks also if a name tag (a tagname containing the string 'name') is set which is mandatory to be used by the LocationHook. Otherwise the boundaries blow up the precompiled bounds but must be sorted out by the LocationHook. When doing this in the precompilation step it saves time while generating the real map.

1 0

[PATCH v1] Extend tags for poi placement for the add-pois-to-areas option
by WanMil 19 Oct '11

19 Oct '11

Because I know lots of you want to configure the placement behaviour of the add-pois-to-areas option I have implemented a small patch for it. The patch adds a new option "pois-to-areas-placement". This option defines on which node the POI generated from a polygon is placed preferrably. Example: pois-to-areas-placement=entrance=main;entrance=yes;building=entrance means: The POI node is placed to the first node with entrance=main or if it does not exists at the first node with entrance=yes or if that does not exist at the first node with building=entrance. If no rule matches the POI is generated at the center of the polygon. It's also possible to use wildcards like: pois-to-areas-placement=entrance=*;building=entrance Maybe someone can read my awful help text in the options file and can improve that? It would be good to have a better text to commit :-) Have fun! WanMil

2 2

Strange routing issue when joining a "through_route"
by Steve Hosgood 19 Oct '11

19 Oct '11

The following oddity happens around node 86872929 (lat 51.448272, lon 3.49579W): I've got yesterday's maps running on a Streetpilot i3. I approach the problem area from the west on unclassified road (way 22883317) expecting to go south on the secondary route B4270 (way 4597013). Normally I'd expect to be routed onto the short link of unclassified road (way 22883320), so I'd expect the driving instructions "turn right, then turn right" as I approach node 246057790. What I actually got on approach was "in 100m, turn left". Looking at the Garmin's screen (which was already at full-zoom) it seemed that the machine wanted to turn me north on the B4270 and do a u-turn at node 86872929. Normally a Streetpilot will try and do everything it can to avoid u-turns, but not in this case. It seems as if way 4597013 (which happens to be part of a "through_route" relation) is being treated as a one-way street going north for the purposes of junctions that meet with it. Node 86872929 (where the u-turn is flagged) is also in that relation with the role of "junction". The "direction" of way 4597013 is however being shown as north to south, so treating it as a one-way in the opposite direction would be a bit weird. This "through_route" info may be a red herring, but I've never seen such behaviour elsewhere, and it's the only unusual feature of this junction that I can see. Steve

1 1

Routing with the eTrex 30
by Frank Fesevur 19 Oct '11

19 Oct '11

Hi all, A couple of weeks ago some of you asked me about the routing capabilities of the new eTrex 30 model. First of all, as I said before. My previous model was a Venture HC, so without routing. I had nothing to compare to, when it comes to routing on an eTrex. Today I finally had time to do some tests. So I downloaded a fresh copy from garmin.openstreetmap.nl of The Netherlands with the Mapnik TYP file and put the gmapsupp.img on my gps. I made sure the routing was set to car and went of for a short trip of geocaching in the neighborhood on my bike. My conclusion is that car navigation does send me over cycleways and footways. It also sends you the wrong way in a oneway street. Some foot/cycleways I was send over: http://www.openstreetmap.org/?way=123268791 http://www.openstreetmap.org/?way=38227297 http://www.openstreetmap.org/?way=124617312 The street it send me the opposite way was http://www.openstreetmap.org/?way=111853421 When it did, it showed "Hofzicht (Cycleway)" in the display. That "Cycleway" was in English even with Dutch language settings in the gps. Regards, Frank

5 8