logo separator

[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



More information about the mkgmap-dev mailing list