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

Reply via email to