[mkgmap-dev] [PATCH v1] Support relation destination_sign
From Henning Scholland osm at aighes.de on Mon Apr 22 23:29:11 BST 2013
Am 22.04.2013 20:37, schrieb WanMil: >>> Can you implement these rules? >> It should be in relation-file: >> >> type=destination_sign { apply role=to { set >> foobar:destination=='$(foobar:destination),${destination}' | >> '${destination}' } } >> >> Now every to-way is tagged with destination-Tags of all relations >> seperated by , >> >> In lines-file you would need something like: >> >> highway!=*_link { delete foobar:destination } >> >> Maybe you would like to merge foobar:destination with an existing >> desination, but I don't know if this is a good idea. >> > Ok, it seems to be possible. (Really? is ${foobar:destination} taken > from the element or from the relation?). At the end of relation-processing foobar:destination contains a list of all relation-destination-tags. > * The --process-destination option does not know the foobar:destination > tag. So it will still ignore the tags if they are not merged with the > destination tag within the relations file. Mmh, don't know a good > solution for that. My thought was, that if there are relations, then normal destination-tag can be ignored. > * The stlye implementation seems to be quite complex to me. It may be > more useful if it's possible to add some rules in the relations file > regarding the elements, so something like > > type=destination_sign { apply role=to & member:type=way & > member:tag:destination!=* { set > destination=='$(member:tag:destination),${destination}' | > '${destination}' } } > > Could be good testcase to extend the relations file capabilities. To make it save, you'll need something like this. member:type=way shouldn't be necessary, because it doesn't harm, if its copied to a node, does it? Maybe the new filter-function can also help. Henning
- Previous message: [mkgmap-dev] [PATCH v1] Support relation destination_sign
- Next message: [mkgmap-dev] through_route relation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list