Refactor types system for access= and fee= OSM tags

[vng]

Take out access=, fee= from classificator types and replace with separate tag types like hwtag now.

Advantages:

• apply this tag-types to any classificator object easily
• combine drawing styles (draw non-accessible or paid objects with some transparency)

[biodranik]

@pastk are there any other OSM tags that should be refactored in the same manner?

[pastk]

@pastk are there any other OSM tags that should be refactored in the same manner?

Lifecycle tags and prefixes like abandoned/disused/proposed etc. #1038

Bridges and tunnels? Can use for better PP display. Otherwise not needed?

Access-related separate tags like foot/bicycle/horse/etc.=yes/no/designated/etc. to help with proper routing and rendering #1796

sac_scale=* and trail_visibility=* for hiking paths and footways. Display in PP, use for route estimations, render differently too.
Also for MTB mtb:scale=*
And for winter sports: piste:difficulty=*

incline=* for routing, but maybe not used widely enough (need to filter out highway=steps or incline=up/down as not useful).

[AntonM030481]

if possible add also:

• language:= to indicate the languages offered or taught at a POI (e.g. educational amenities).
• operator:type=* to indicate if POI is a private or public entity (again e.g. educational amenities).

[biodranik]

What about the limit of 7 types per feature?

[vng]

Don't see problems here. We add 1-2 tag types to the POIs.
More questions with cuisine and recycling.

[AntonM030481]

It will be great to use such approach for sport tag.

[vng]

Sport already works like this. You can add sport=* type to any POI.

[AntonM030481]

Theoretically it means that we can show show sport as it was suggested here.

[TheAdventurer64]

takeaway=yes/no/only and delivery=yes/no as well.

[biodranik]

A better idea could be to collect info from all issues and make "meta" issues like this:
"Improve restaurants and cafes Place Page"

[RedAuburn]

+1 for this, I'm trying to improve parking icons & defining types with access results in a mess:

amenity|parking
  amenity|parking|fee
  amenity|parking|private
  amenity|parking|permissive
  amenity|parking|permissive|fee
amenity|parking|surface
  amenity|parking|surface|fee
  amenity|parking|surface|private
  amenity|parking|surface|permissive
  amenity|parking|surface|permissive|fee
amenity|parking|street_side
  amenity|parking|street_side|fee
  amenity|parking|street_side|private
  amenity|parking|street_side|permissive
  amenity|parking|street_side|permissive|fee
amenity|parking|lane
  amenity|parking|lane|fee
  amenity|parking|lane|private
  amenity|parking|lane|permissive
  amenity|parking|lane|permissive|fee
amenity|parking|underground
  amenity|parking|underground|fee
  amenity|parking|underground|private
  amenity|parking|underground|permissive
  amenity|parking|underground|permissive|fee

etc...

with a system for handling access & fee internally, this would be reduced to

amenity|parking
amenity|parking|surface
amenity|parking|street_side
amenity|parking|underground
amenity|parking|lane

for #3896

From pastk:

Unfortunately nor kothic, neither core renderer work with such a configuration at the moment. In its current form kothic can possibly match only one type from mapcss-mapping.csv and produce drules for it (it can't combine rules from several types).

[pastk]

Don't see problems here. We add 1-2 tag types to the POIs. More questions with cuisine and recycling.

@biodranik
Hmm, I remember there was a further discussion on issues with 7 types limit? I couldn't find it..

[biodranik]

The current encoding supports only max 7 types per feature. Increasing types count may unnecessary increase files size and reduce rendering speed.

We can invent some hacky ways to store more than 7 types, but ideally it would be way easier to support max 7 types.

[vng]

Also location=underground (or similar)

[pastk]

Classification:

• base types - rendered, translated and searched as standalones
• attributes - applicable to multiple base types, make no sense standalone, but modify rendering, translations, routing, search; e.g. fee=*, access=*, location=*

Note that e.g. parking=surface/multi-storey/street_side/underground/etc. is applicabe to amenity=parking only so is better considered as a part of base type: amenity-parking-street_side/underground etc.

ATM we have some special OM-invented types like hwtag=lit/oneway/private/etc and psurface=paved_good/unpaved_good/etc. They could be left as special cases or re-considered as attributes.

Also we have "dynamic/run-time" tags like "name/population/bbox". At least presence of "name=*" could be considered an attribute. "population/bbox" (potentially "density" for dynamic styling in future) work much like attributes too (especially if we consider using pre-defined ranges like population=huge/big/medium/small).

Requirements:

• no necessity for manual definitions of all sub-type combos (in mapcss-mapping, styles, translations..)
• ability to search for attributes
• rendering & search should remain fast
• ability to modify base type's styling and translations depending on attributes

Sample cases we'd like to support:

[access=private]
e.g. highway-service[private], amenity-parking-street_side[private]
trans: add "Private" to the subtitle
style: change color/opacity for lines and areas, change icon for POIs; reduce visibility and priority

[fee=yes/no]
e.g. amenity-parking-street_side[fee], amenity-toilets[fee]
trans: add "Paid"/"Free" to the subtitle
style: change icon

[disused:*]
e.g. amenity-cafe[disused], railway-rail-branch[disused]
trans: add "Disused" to the subtitle
style: change color/opacity; reduce visibility and priority

[wheelchair=*]
e.g. amenity-bank[wheelchair]
trans: add a wheelchair icon to the subtitle

[name=yes]
e.g. waterway-waterfall[name]
style: increase visibility and priority

[sac_scale=*]
e.g. highway-path[sac_scale]
trans: add "Mountain Trail / Alpine Route / etc." and difficulty rating to the subtitle
style: change line style

[route=hiking/foot/mtb/etc.]
e.g. highway-path[route]
trans: add "Route" to the subtitle
style: increase visibility, change line style

[tunnel=yes/culvert/etc]
e.g. highway-primary[tunnel], waterway-stream[tunnel]
trans: add "Tunnel / Culvert" to the subtitle
style: change line style (might be different for waterways, highways, railways?)

[bbox=huge/small/etc]
e.g. natural-water-lake[bbox]
style: change visibility of area and caption

[bicycle=yes/no/designated]
e.g. barrier-gate, highway=path
trans: add "No bicycles" / "Cycling designated" / etc. to the subtitle

[organic=yes/no/only]
e.g. amenity-supermarket
trans: add to the subtitle

[sport=*]
e.g. leisure=stadium, leisure=pitch
trans: add sport name to the subtitle
style: use sport-specific icon

[cuisine=*]
e.g. amenity-restaurant
trans: add cuisine type to the subtitle

Implementation thoughts:

A big advantage of the current rendering system is that drawing rules are pre-defined for each type so there is no need to construct a rendering style for each attribs combination at the runtime.

I'm not sure if an overhead of constructing a rendering style at runtime will be significant or not. Maybe I'm overestimating it.
Maybe we can re-use / improve the current "dynamic/run-time" tags styling mechanism for that. What is the runtime overhead of the current implementation?

There is another option of keeping the fast-rendering advantage for the most common attribs combinations at least.

E.g. [access=] + [fee=] attribs generate a limited number of combinations, so we can pre-generate feature sub-types and drules for e.g. all amenity-parking[access/fee] style combos. But it should be automated as the current manual process is too tedious.
(The most of current uses of "dynamic" tags could be better implemented as pre-defined feature sub-types too (e.g. natural-peak / natural-peak[name], place-city[population=huge] / place-city[population=small] / etc), if those sub-types will be generated automatically.)

Another advantage of having pre-defined feature sub-types for attribs combos is that this approach doesn't increase types storage size: atm most types use 2 bytes for storage which is 16k possible values, but atm we have 1.6k types only, so we can easily inflate number of types 10-fold without adding any extra bytes.

[cuisine=*] generates too many combinations, so its not feasible to store as a part of feature type id.
Its good to have a fast search ability though, so storing in metadata is suboptimal too. Another option is to increase the current 8-types limit or use a special trick to store many cuisine values in a compact way, but it'll require mwm format change.