[PATCH v1] Support relation destination_sign
For all those who like the --process-destination option I have added another feature. The patch analyses the relations with type=destination_sign and adds its destination and/or ref/destination_ref/destination:ref tag to the "to" members of the relations. This is performed in case the to member is a oneway way with highway=*_link. The destination tag is copied from the relation if the "to" member does not already have a destination tag. The same happens with the ref/destination_ref/destination:ref tags. They are set as destination:ref tag in case the "to" way does not already have a ref tag. Afterwards the ways are processed by the common --process-destination algorithm. Sounds great espacially because the number of destination_sign relations is growing quite well. But: the effect of the patch is quite small. I have compiled a map of germany. Destination_sign relations: 3677 Destination tags copied to _link ways: 121 Destination:ref tags copied to _link ways: 41 Examples: http://www.openstreetmap.org/browse/way/213248346 gets a destination:ref tag. http://www.openstreetmap.org/browse/way/194845924 gets a destination tag. Most of copied destination tags are the name of exits. (I didn't measure the values but a small sample showed this). Anyhow try yourself with your data and let me know if it should be commited. WanMil
Hi WanMil, in general it would be great to have a style-feature in relationsfile to create a tag based on the rule of the relationmember. Like: type=route & route=bicyle { apply_to:<role> { set foo=bar } }
Hi Henning, that's already possible: type=route & route=bicyle { apply role=forward { set foo=bar } } WanMil
Hi WanMil, in general it would be great to have a style-feature in relationsfile to create a tag based on the rule of the relationmember.
Like: type=route & route=bicyle { apply_to:<role> { set foo=bar } }
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 18.04.2013 20:15, schrieb WanMil:
Hi Henning,
that's already possible:
type=route & route=bicyle { apply role=forward { set foo=bar } }
Oh...I missed it. But then it shouldn't be necessary to use special code, because you can manage it via style, or am I wrong?
Henning
Maybe. Can you implement these rules? The destination tag is copied from the relation if the "to" member is a link and does not already have a destination tag. The same happens with the ref/destination_ref/destination:ref tags. They are set as destination:ref tag in case the "to" way does not already have a ref tag. WanMil
Am 18.04.2013 22:30, schrieb WanMil:
Am 18.04.2013 20:15, schrieb WanMil:
Hi Henning,
that's already possible:
type=route & route=bicyle { apply role=forward { set foo=bar } }
Oh...I missed it. But then it shouldn't be necessary to use special code, because you can manage it via style, or am I wrong?
Henning
Maybe.
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. Henning
The destination tag is copied from the relation if the "to" member is a link and does not already have a destination tag. The same happens with the ref/destination_ref/destination:ref tags. They are set as destination:ref tag in case the "to" way does not already have a ref tag.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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?). Anyhow I still see some problems: * The relations style file is processed after the --process-destination option has been processed. This might be fixed by executing the relations file earlier. * 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. * 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. WanMil
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
participants (2)
-
Henning Scholland -
WanMil