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
