Is it not too late to switch to fuel=* and drop fuel:*=*? Marc_marc <marc_m...@mailo.com>:
> Le 20.04.23 à 03:28, Matija Nalis a écrit : > > On Thu, 20 Apr 2023 00:47:21 +0200, Marc_marc <marc_m...@mailo.com> > wrote: > >> Le 19.04.23 à 14:19, Matija Nalis a écrit : > >>> I think that my point remains that: > >>> - one method is clear and unambiguous ("fuel:lpg=no") > >>> - one method is not clear / is ambiguous ("fuel=octane_98;diesel"). > >>> > >>> So the first one should be preferred. Does that make sense? > >> > >> - one is a nightmare for datause > >> - one isn't a nightmare for datause > >> So the 2nd one should be preferred. Does that make sense? > > > > Hmm, no, not at all (if ordering of your sentences is same as mine at > the top quote)? > > > > I'll assume that by "datause" you mean something like computer storing > > data in some kind of database for purpose of retrieving > > yes > > > - in "fuel:lpg=no" case it is VERY efficient and fast (using const lookup > > on composite index [key,value]) to look for e.g. > > > > SELECT * from t where key = "fuel:lpg" and value = "yes"; > > only if you are able to make an index on it > make a index on fuel=* is easy. > but creating an index on an unknown number of fuel:* keys is problematic > besides, this information will end up in the hstore for the same reason > > for the preset, it's the same problem: > listing all cuisine=* values is possible (iD does it very well) > propose a preset that dynamically displays a yes/no field for all > fuel:*, I've never seen this before, you're limited to hardcoding some > > it is a confusion between key and value. > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging