Great, looking forward for this. Don't know if GPS or Mapsource/Basecamp will show everything but we'll see. At the moment I misuse addr:street tags etc to show some information of barriers but this is a bad workaround.

I am not sure about the limits in the Garmin format, but it should be easy to write a method like echotags that returns the string instead of writing it to stderr.

Gerd

I understand I'll still have to use some hacks like { add mkgmap:housenumber='(${barrier})' ; add mkgmap:street='bicycle:${bicycle}' ; add mkgmap:postal_code='open: ${opening_hours}' ; } But anyway, it will be made more easier to retrieve all tags instead of guessing which tag to print, like 'bicycle:${bicycle}' or 'motorcar:${motorcar}' etc

well, I don't know where to put the string, I just say that it is easy to calculate it ;-)

Gerd

Thanks Gerd, But how do I get all_tags() in for instance the name field?

attached is a patch that provides the all_tags() function which returns all tags of an element (in no particular order).

Complied binary based on r3116 is here: http://files.mkgmap.org.uk/download/184/mkgmap.jar

I did not test it, but I hope that's what you need.

Gerd

Hi Gerd, I tried barrier=* {set name='${all_tags}'} [0x1108 resolution 23] or { name '${all_tags()}'} but this doesnt show anything

I really don't know. Can't you use the set command?

Gerd

...

Thanks Gerd, But how do I get all_tags() in for instance the name field?

Gerd wrote:

can't try it now, but I'd say it should be barrier=* {set name = all_tags()} [0x1108 resolution 23]

This sets the name to "all_tags" ;-)

I don't see any example where the return value of a function is used to set a variable, so maybe this doesn't work at all?

I guess so. Nevermind, it's not so important so don't spend too much time on this.

Hi Andrzej, I see no hardcoded handling of highway=crossing. Do you see this problem also with the default style? If yes, please post the id of the node. Gerd popej wrote

Hi Gerd,

is there any hard-coded processing of points "highway=crossing"? I can get ride of deformation of roads at these points. I have tried:

highway=crossing {delete highway}

and compilation without link-pois-to-ways option. I use mkgmap r3116, I always get roads like on attached picture.

-- Best regards, Andrzej

_______________________________________________ mkgmap-dev mailing list

mkgmap-dev@.org

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

crossing.png (14K) <http://gis.19327.n5.nabble.com/attachment/5800562/0/crossing.png>;

-- View this message in context: http://gis.19327.n5.nabble.com/link-pois-to-ways-tags-tp5800124p5800564.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

Hi Andrzej, ah, yes, that one shows the problem. The additional cycle way is added with a different (OSM) id (osm id incremented by CYCLEWAY_ID_OFFSET (0x10000000)). Therefore all points of the original way appear on two different roads, all highway counts are incremented and thus the obsolete point is no longer considered obsolete. I see two simple fixes: 1) don't increment the id 2) consider two way ids as identical when they differ by CYCLEWAY_ID_OFFSET and follow each other. I don't know why the offset was added, so I don't dare to remove it. Attached is a patch for the 2nd approach. @Steve: svn blame says the code with the CYCLEWAY_ID_OFFSET was added by you. Please check if that is (still) needed, I think it was just added to be able to identify these special ways when debugging? Gerd Date: Fri, 21 Mar 2014 20:23:48 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] link-pois-to-ways tags Hi Gerd,

I see no hardcoded handling of highway=crossing.

My bad, wrong guess and wrong thread. Problem is due to option make-opposite-cycleway. When used, way gets additional nodes, which accidentally happen to be crossing. Without crossing tag, mkgmap behave the same. See attached sample and node: http://www.openstreetmap.org/node/2650495576 Compilation with simple command: mkgmap --route --make-opposite-cycleways crossing.osm -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Gerd,

Attached is a patch for the 2nd approach.

Unfortunately it doesn't solve the problem. See for example this node in previously provided sample: http://www.openstreetmap.org/node/2650495573 If I use whole tile from my map, then even the node, which is removed in sample, still remains. -- Best regards, Andrzej

Hi Andrzej, fine :-) The previous patch worked for me as well, but r3117 is the cleaner solution, as it is closer to the alternative that uses continue in the style to create additional ways. Gerd

Date: Fri, 21 Mar 2014 23:33:47 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] link-pois-to-ways tags

Hi Gerd,

release r3117 seems to be correct, thanks!

-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev