Yes, that's from 
which André Pirard linked to just recently here.

Personally, I'm not a huge fan of the syntax. I would prefer the use of 

You would then have a type=defaults relation, with apply_to members that 
specify the areas where the rules apply and match:(condition) members that 
refer to type=default relations which can simply contain a set of plain 
key=value tags (and don't need to have any members, they are just containers 
for tags).

If the same bunch of default values applies to different things with different 
matching rules, you can just refer to the same sub-relation multiple times.

One issue with all this is that while you can encode a lot of useful 
information this way, it doesn't help cases like the "it's not legal by default 
to make u-turns at signal controlled intersections" in Queensland. As such 
things can not be expressed with just a tag or two as default values on 
existing objects. They require specific coded support in router engines.

For that I would suggest something like

rule:no_u_turn_at_signals=yes on the defaults relation, and the router engines 
need to know what these mean then.


> -----Original Message-----
> From: Frederik Ramm <>
> Sent: Friday, 6 April 2018 16:39
> To:
> Subject: Re: [Tagging] no_u_turn restrictions for every entry/exit
> into a roundabout when the way is split because of physical
> separation?
> Hi,
> On 04/06/2018 05:26 AM, wrote:
> > Putting information about the legal default into OSM is not the
> problem.
> > It’s just that nobody has developed a schema for it yet.
> The French have invented something: Check the "Part of..." listing
> here
> It seems that a couple more of these exist, e.g.
> I don't know if anyone actually uses them.
> Bye
> Frederik
> --
> Frederik Ramm  ##  eMail  ##  N49°00'09"
> E008°23'33"
> _______________________________________________
> Tagging mailing list

Tagging mailing list

Reply via email to