[RFC] Add implied tags to presets

[taylor.smock]

I'd like to be able to get default access tags, if none exist on a highway. For example, in most countries highway=motorway implies bicycle=no, motor_vehicle=yes, foot=no, oneway=yes, and surface=paved.

So there are two methods available to get this information:
1) Hardcode it (i.e., make a java class that stores common implied information)
2) Extend the presets.xml parser to understand an implies tag

For example,

        <item name="Motorway" icon="presets/transport/way/way_motorway.svg" type="way" preset_name_label="true">
            <link wiki="Tag:highway=motorway" />
            <space />
            <key key="highway" value="motorway" />
            <text key="ref" text="Reference" />
            <optional>
                <text key="name" text="Name" />
                <reference ref="highway_base" />
                <text key="destination" text="Destination" />
                <text key="destination:ref" text="Destination reference" />
                <text key="width" text="Width (meters)" />
                <combo key="placement" text="Placement" values="left_of:1,left_of:2,left_of:3,middle_of:1,middle_of:2,middle_of:3,right_of:1,right_of:2,right_of:3,transition" />
                <checkgroup columns="4">
                    <check key="oneway" text="Oneway" default="on" />
                    <check key="bridge" text="Bridge" disable_off="true" />
                    <check key="tunnel" text="Tunnel" disable_off="true" />
                    <check key="cutting" text="Cutting" disable_off="true" />
                    <check key="embankment" text="Embankment" disable_off="true" />
                    <check key="lit" text="Lit" />
                    <check key="toll" text="Toll" />
                </checkgroup>
            </optional>
            <preset_link preset_name="Road Restrictions" />
            <implies>
                <key key="motor_vehicle" value="yes" />
                <key key="bicycle" value="no" />
                <key key="foot" value="no" />
                <key key="oneway" value="yes" />
                <key key="surface" value="paved" />
            </implies>
        </item> <!-- Motorway -->

Ideally, the implies xml tag group would also take a country code (so <implies country="US,MX,GR,GB" excludes-country="US-FL,US-CO">) for country specific regions, or applying the implied tags worldwide except for specific countries. So the default scope for an implies block would be worldwide, unless it has a country attribute, in which case the scope decreases to those countries. If there are excludes, then those countries are excluded.
The more specific country wins (so country="US-FL,Earth" excludes-country="US" would include the entire world, except for the US, with Florida still having the implies block). This does mean that there needs to be a special value for worldwide, for which I would use Earth instead World or global (this is mostly for future-proofing -- hopefully we will eventually have an OpenStreetMap for the Moon/Mars, but maybe we would want to use the global defaults for those anyway).

Alternatively, the key tags could have implied embedded in them (so <key key="motor_vehicle" value="yes" implied="true" implied-countries="US" exclude-implied-countries="US-FL" />).

Since there are some tags (highway=motorway as an example) where the default implied tags are recommended to be included due to different localities having different implied tags, so we can have a recommended=yes attribute as well, so <implied recommended=yes>.

I do have some proof of concept code to add the implies tag, but it needs significantly more work (it doesn't have include/exclude countries, check if the implied tags are recommended, and it adds the tags as if they were required tags, due to re-using the key tag).

This may also mean that we can write a validator rule to check if the implied tags have been added to a way (so if we have a way with the tags highway=residential access=yes foot=yes bicycle=yes), we can indicate that there are three unnecessary tags (access=yes is implied, as is foot=yes and bicycle=yes, but even if foot and bicycle weren't implied, access=yes also implies foot=yes and bicycle=yes).

[Klumbumbus]

I think it is not so simple to add implied tags to presets as the implied tags depend not only on the "main tag" (i.e. the one(s) in <key>) but also on the other tags of the object. With every tag more implied tags can change.

[Klumbumbus]

And for highway=motorway I don't think it is a good idea to add the implied tags as explicit tags.

[taylor.smock]

Replying to Klumbumbus:

And for highway=motorway I don't think it is a good idea to add the implied tags as explicit tags.

I wasn't necessarily intending to add the implied tags as explicit tags (the wiki explicitly points out that different localities may have different implied tags for motorways, which means that it might be a good idea to add the ones that are disputed). Ideally, we would have some way to indicate the implied tag (e.g., yellow background or another section).

As far as the cascading implied tags, I can kind of see your point.

For example, highway=motorway implies motor_vehicle=yes which in turn implies motor_cycle=yes, motorcar=yes, hgv=yes, and so on. hgv=yes in turn implies hgv_articulated=yes. motor_vehicle=no implies the reverse (hgv=no which implies hgv_articulated=no).

In the case of conflicting tags (so highway=residential + smoothness=very_horrible implies 4wd_only=yes and access=yes -- AFAICT, smoothness=very_horrible doesn't actually imply 4wd_only, but a router should probably make that assumption anyway), we can ask which is "correct" and ignore the implied tags in the validator.

There is probably a better example for conflicting tags than access values, but that is what I've been thinking about lately (see #18364 -- I want to find routing islands, and I don't think hardcoding the implied access values for highways is the right way to go about it, especially since some localities have specific implied access tags).

[Klumbumbus]

Some other example is recycling:*=*. ​osmwiki:Tag:amenity=recycling says: "If there is at least one of the following materials tagged, the default value for the rest is no. For example, if a feature is tagged amenity=recycling+recycling:glass_bottles=yes then recycling:aluminium=no is implied.
There is also implied yes value for all more detailed values for subgroups. For example amenity=recycling+recycling:scrap_metal=yes implies recycling:aluminium=yes (as subgroup) and recycling:glass_bottles=no (as not mentioned and not a subgroup)."

Anyway I think access tags is already one of the most complex topics regarding implicit tags in OSM.

[taylor.smock]

Should I just create a java class somewhere that does implicit access tagging for highways then? I do need to know the implicit access tags to find routing islands (I could just go "it connects to another highway, therefore no routing island exists", but this can run into problems where a series of highway=service roads are connected to highway=tertiary roads with highway=footway roads).

I should probably look at writing a class that takes a root access tag, and then expands it for other classes (so hgv=yes expands to hgv_articulated=yes + hgv=yes), and that would be useful if this were ever implemented as well (since the access tags could be expanded). This could then be used in validator.mapcss rules (for example, if there is a way with highway=motorway access=yes and the validator rule looks something like this way[highway=motorway][!sidewalk][access("foot")] { throwOther: "There is a motorway with foot access. Is this correct?"; })

I still think the preset xml would be a better location long term, since the unnecessary tag check would be able to look for non-conflicting implied tags and mark those as unnecessary tags. It would have to be rewritten from mapcss though.

I do agree that access tags are a pain though (JOSM doesn't point out unnecessary access tags, for example access=yes + vehicle=yes doesn't point out that vehicle=yes is unnecessary when access=yes).

[Klumbumbus]

I have no idea what would be the best approach.

Replying to taylor.smock:

(JOSM doesn't point out unnecessary access tags,

A few such warnings are in unnecessary.mapcss, but these are just some special cases.

for example access=yes + vehicle=yes doesn't point out that vehicle=yes is unnecessary when access=yes).

What should be considered for validator warnings is that in case of "conflicting" access tags often access=* is the wrong one, not the more specialized ones.

[taylor.smock]

Replying to Klumbumbus:

I have no idea what would be the best approach.

Neither do I. I think the best approach is implied (or something similar) tags in the preset xml files, since preset authors could use it then as well. But I have been wrong in the past, and I will be wrong in the future. It would also be a bit more complex to code.

for example access=yes + vehicle=yes doesn't point out that vehicle=yes is unnecessary when access=yes).

What should be considered for validator warnings is that in case of "conflicting" access tags often access=* is the wrong one, not the more specialized ones.

That is true -- I just used those since it was the first example I thought of. Another example would be vehicle=yes + motor_vehicle=yes or hgv=yes + hgv_articulated=yes. An example that would not match would be hgv=yes + hgv_articulated=designated.