February 2010 - mkgmap-dev - The mkgmap lists

Commit: r1590: Avoid adjusting the heading of an arc previously used as an outgoing arc.
by svn commit 28 Feb '10

28 Feb '10

Version 1590 was commited by markb on 2010-02-28 22:22:57 +0000 (Sun, 28 Feb 2010) Avoid adjusting the heading of an arc previously used as an outgoing arc. Now, if an arc is used as an outgoing arc, don't let its heading be changed when processing a later incoming arc. This requires that the incoming arcs are processed in decreasing order of class/speed so that the "bigger" roads are matched first.

1 0

Commit: r1589: Be more discerning when matching arcs by class/speed.
by svn commit 28 Feb '10

28 Feb '10

Version 1589 was commited by markb on 2010-02-28 22:22:54 +0000 (Sun, 28 Feb 2010) Be more discerning when matching arcs by class/speed. When matching an incoming arc to an outgoing arc by dint of the fact that they have the same class/speed, take care to avoid using an outgoing arc that has the same name/ref as another arc because they are probably the same road.

1 0

Commit: r1588: Fix test of whether a side road is to the left or the right of the main road.
by svn commit 28 Feb '10

28 Feb '10

Version 1588 was commited by markb on 2010-02-28 22:22:50 +0000 (Sun, 28 Feb 2010) Fix test of whether a side road is to the left or the right of the main road. This was failing when the side road was more than 180 degrees different from the outgoing heading (that could occur when the main road bent at the junction and the side road is almost pointing back to where the incoming road came from).

1 0

problems with POI names
by Torsten Leistikow 28 Feb '10

28 Feb '10

Moin, I have a problem with POIs, which have an ref-tag (using mkgmap-r1586). First of all, if the POI does not have a name, then the ref-tag is displayed in the map. In my lines file, I have specially a rule for adding the ref-tag to the name, so I am a little bit surprised, that this is happening for the POIs automatically. Are there some other tags wich will be used instead of the name tag? My second problem is, that I wanted to delete the reference, by adding this action part to my style rule: {set ref=""} As a result, all POIs where I wanted to delete the reference, now get their name from a totally unrelated POI. Gruss Torsten

1 0

Re: [mkgmap-dev] bug in road-name-pois
by Minko 28 Feb '10

28 Feb '10

Hi Mark, I tested the address search now on my etrex, and yes it works fine without the road-name-pois. I also tested my map on a Garmin Nuvi, but on this unit it asks 'In what State/Prov is the Address?' and then it can't find anything. Perhaps I forgot something in the mkgmap options (I didnt use --region-name)? Btw my custom map files & styles can be found at http://sites.google.com/site/openfietsmap/ Mark Burton wrote: It should be redundant now anyway if the roadname search works OK.

1 0

bug in road-name-pois
by Minko 28 Feb '10

28 Feb '10

Hi, The option --road-name-pois often creates place names that are totally wrong. Two adjacent streets in the same district can have different place names. I think it is better not to show the place name until this problem is solved? Is there a way to make these POI invisible on the map?

2 1

natural=coastline;cliff
by Steve Brophy 28 Feb '10

28 Feb '10

Hi, Someone has tagged part of the UK coastline with natural=coastline;cliff and this has broken --generate-sea=polygons,no-sea-sectors,close-gaps=1000. Is this valid syntax that mkgmap should cope with? Regards, Steve

4 9

Commit: r1587: When checking for natural=coastline, cope with compound tag values.
by svn commit 28 Feb '10

28 Feb '10

Version 1587 was commited by markb on 2010-02-28 11:27:44 +0000 (Sun, 28 Feb 2010) When checking for natural=coastline, cope with compound tag values. Don't be fooled when someone does: natural=coastline;foo We now grok the coastline and replace the tag with natural=foo.

1 0

Re: [mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
by Minko 28 Feb '10

28 Feb '10

Hi, I've tried to put in the relation file: type=multipolygon { apply role=inner { set inner=yes } } And in the polygons file: natural=water & inner=yes [0x27 resolution 14] But it seems not doing anything. Looks like the multipolygon processing is done before it reads the relation style file?

1 0

Re: [mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
by Minko 27 Feb '10

27 Feb '10

Felix, natural=water & role=inner in the polygons style file (if a rule like that would be possible at all?) will not be a solution, because then also lakes within (multipolygon) forests are tagged like this too and will be affected. For my case it only has to be applied on relations where both role=inner and role=outer are tagged with natural=water The last version of openmtbmap that worked correct for this relation was in december 2009 I guess. Radfahrers map of Europa from 09-01-2010 seems also working ok for this kind of relation. But maybe in my case its better to accept that the Dutch way of osm tagging is wrong and has to be altered instead of finding a way to solve this with mkgmap ;-) Cheers, Minko

4 3