There is a substantial difference between tagging a limited set of physical properties (and yes clearly some of this could have been done as a list too) that are known in advance vs. moving an essentially unbounded list of fantasy names in to key space.
The argument that semi-colons shouldn't be used is specious, what is correct is that the semantics of a key with a list should be documents, but once that has been done there is no reason not to do so. As to the argument with recording non-supported vendors 99.9% of this is simply whataboutism, if you can really make a case that you need to explicitly record that instead of relying on default semantics, you can simply add a key for that. Am 26.12.2018 um 16:46 schrieb Martin Koppenhoefer: > > sent from a phone > >> On 26. Dec 2018, at 15:08, Stefan Keller <[email protected]> wrote: >> >> Tag-proposals in the form >> <tag_attr_name>:<type_value->[:<subtype_value>]=yes/no should be >> avoided. It's shifting values to attribute names! > > it’s not a value, it‘s a property ;-) > it depends on your interpretation, e.g. motorroad=yes > oneway=yes > > aren’t these values and we should tag them > road_restrictions=motorroad;oneway? > > > top_up:phone=yes > means: provides phone top up. > For practical reason, I would expect a scheme > characteristic_I_need_to_know=yes/no > > much easier to evaluate than one like: > some_services=foo;characteristic_I_need_to_know;bar This is being directly disingenuous, because what is a actually being proposed is characteristic_I_need_to_know:random_string=yes .... 1000+ more random strings. > > > Cheers, Martin > _______________________________________________ > Tagging mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/tagging
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
