Wiki Edit War on using/avoiding semicolon lists

classic Classic list List threaded Threaded
124 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

moltonel 3x Combo
On 22/01/2015, Dmitry Kiselev <[hidden email]> wrote:
>  As I think,
>
> replace
>     key=val1;val2
> with
>      key: val1 =*
>      key: val2 =*

key:subkey=* is only usable (or even recomended) for standardized
subkeys. If instead you have a random value (like a road reference or
a street name), another scheme is necessary: key_<number>=*.

This has been debated (yet again) on this list not long ago for the
"name" key. The usual arguments followed. There are enough proponents
of both styles (each with good arguments) that both styles are clearly
here to stay (unless maybe the code data model gets updated to support
multi-value tags).

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Charles Basenga Kiyanda-4
In reply to this post by NopMap


On 15-01-22 01:44 PM, [hidden email] wrote:
> Message: 3
> Date: Thu, 22 Jan 2015 18:08:49 +0100
> From: Marc Gemis <[hidden email]>
> To: "Tag discussion, strategy and related tools"
> <[hidden email]>
> Subject: Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
> Message-ID:
> <CAJKJX-S3rCtHqSH+22+zrn0H5k6_ATTTOcmZmdcESYeK6k=[hidden email]>
> Content-Type: text/plain; charset="utf-8"


>> > In this thread we are also most interested in multiple values.
> I know :-)
>
>

I have to add fuel to a heated discussion, but in the whole exchange on
whether or not semicolon lists should be allowed/used, the most obvious
example (to me) that requires semicolon lists was not mentionned,
namely: opening hours.

http://wiki.openstreetmap.org/wiki/Key:opening_hours

I've tried before to collect data on parking restrictions in the city of
montreal (Canada). Parking restricted/allowed times are an example of
geographical data that requires a time description.

I don't think the problem can be solved by relations. Simply because
parking is allowed on two different streets between 2 and 3 pm, does not
mean they're "related". As noted on the wiki:

http://wiki.openstreetmap.org/wiki/Relation#Types_of_relation

"They are not designed to hold loosely associated but widely spread
items. It would be inappropriate, for instance, to use a relation to
group 'All footpaths in East Anglia'." Similarly, holding "all street
segments for which parking is allowed between 2 and 3pm on the island of
montreal" in a relation strikes me as a bad idea.

Substituting

opening_hours = Mo-We 08:00-17:00; Th-Fr 08:00-21:00

to

opening_hours:Mo-We 08:00-17:00 = yes
opening_hours:Th-Fr 08:00-21:00 = yes

would in my opinion lead to an inordinate number of subkeys. For
example, in montreal alone, there are about 65000 different types of
city parking signs. Let's say the number of individual distinct parking
restrictions is only 10% of that, there would still be 6500 different
subkeys (looking only at my city only).

To make a long story short, this example, to me, shows that semicolon
lists should stay in the tagging scheme.

I would suggest discussing:

A) For which keys and/or type of data are semicolon lists pertinent?
B) How can semicolon lists be handled better in the different editors?

as separate topics. Right now the two topics seem intertwined, which
strikes me as less productive.

With nothing but regards to all,

Charles

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

jgpacker
A) For which keys and/or type of data are semicolon lists pertinent?
For keys that can logically have multiple values and that are not the main/defining key of the object.

B) How can semicolon lists be handled better in the different editors?
If you are using a tag from a preset, iD theorically can create the tag from any kind of interface.
Not sure about JOSM, but I don't think this would be a show-stopper as long as semicolons is a better alternative.


By the way, as far as I can tell people here wouldn't say that "always avoiding semicolons whenever possible" is good practice, correct? [1][2]

[1]: http://wiki.openstreetmap.org/w/index.php?title=Good_practice&diff=next&oldid=1128365
[2]: http://wiki.openstreetmap.org/wiki/Special:WhatLinksHere/Avoid_semi-colon_value_separator


Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

dieterdreist
a minor issue with semicolon separated lists: we don't have yet defined how to escape actual semicolons in values.

cheers
Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
dieterdreist
In reply to this post by Jo-2




Am 22.01.2015 um 14:07 schrieb Jo <[hidden email]>:

network DLVB;IBXL;TECB;TECC;IBXL
operator De Lijn;STIB/MIVB;TEC;STIB/MIVB






I'd completely refrain in this case from tagging these to one object and use relations instead.
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Tod Fitch
In reply to this post by jgpacker
I've been following this and the addrN thread with a mixture of amusement and irritation.

Lots of the arguments come down to how easy it is to parse using some tool or another. Or whether the problem the original poster was trying to address actually exists.

With respect objects that have multiple values for a key, the arguments seem to come down to either:

1. key=value1;value2;. . . ,valueN
2. key:value1=yes + key:value2=yes + . . . + key:valueN=yes

As a programmer I can parse either set using any number of different methods.

I am not against using a ":' in the key string to create name spaces and for grouping related keys. I think that is a very useful construct.

But from a purely logical point of view, I'd say the second way misses the concept of "key=value" and is using "key:value" with a noise suffix of "=yes". Typically missing keys should be treated as having a value of either "no" or "unknown". Unless you can show me where key:value1="is something other than yes" then I may suspect you of putting values into the key field of the data.

Might I suggest that a convention for keys that may contain multiple values that the ":" delimiter be used in the key but rather than putting arbitrary (data) values after the colon, use an numeric index:

key:1=value1
key:2=value2
key:3=value3
.
.

At present we have approached each case on an ad hoc basis. Sometimes using a number suffix by itself (addr2), sometimes preceded by a underscore (name_1) and sometimes by using a semicolon delimited list in the value field. By setting a simple convention for key with an array of values I think many of these cases could be handled in a simple, easy to remember unified manner.

Cheers,
Tod Fitch


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

fly high
In reply to this post by Marc Gemis
Am 22.01.2015 um 18:08 schrieb Marc Gemis:
>
> On Thu, Jan 22, 2015 at 4:49 PM, althio <[hidden email]
> <mailto:[hidden email]>> wrote:

Well at least iD knows quite well about the semi-colon:
Just merge two ways together and you might get access=no;yes
highway=primary;path without any warning.


>> New people can have problems or make mistakes and then experienced
>> users can help and point to recommended tagging or explain good
>> practices .
>
> Not everybody reaches out to community for help. Probably many just stop
> mapping, requiring them to create a new key, instead of typing something
> in a free text field is not going to help IMHO.

That is why I would be interested to mention the semi-colon on tag-pages
where it is in common use. This helps in general for question about list
or array, order or not.

>> Or do you refer to iD (as the main editor for new people) where it is
>> not possible to override presets to edit keys on the first part of the
>> tag panel?
>
>
> What I tried to explain is that when you go for a tagging scheme where only
> cuisine:xxx=yes is allowed, the editor (iD) should offer a simple UI
> that allows people to create new "values". In this case that means keys,
> since the values are actually in the  keys.
>
> At this moment, it is also not possible to create JOSM presets that
> generates keys based on user input AFIAK.

+1

> Using a xxx:yyy schema also requires checkboxes besides every existing
> value in JOSM presets.
> So I don't see how it is any easier for new mappers or preset creators.

Presets are a problem [1],[2] and it is not easy to present tag list
with more than 50 tags per object.


Cheers fly


[1] https://josm.openstreetmap.de/ticket/6268
[2] https://josm.openstreetmap.de/ticket/8993


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

fly high
In reply to this post by Tod Fitch
Am 22.01.2015 um 21:32 schrieb Tod Fitch:

> I've been following this and the addrN thread with a mixture of amusement and irritation.
>
> Lots of the arguments come down to how easy it is to parse using some tool or another. Or whether the problem the original poster was trying to address actually exists.
>
> With respect objects that have multiple values for a key, the arguments seem to come down to either:
>
> 1. key=value1;value2;. . . ,valueN
> 2. key:value1=yes + key:value2=yes + . . . + key:valueN=yes
>
> As a programmer I can parse either set using any number of different methods.
>
> I am not against using a ":' in the key string to create name spaces and for grouping related keys. I think that is a very useful construct.
>
> But from a purely logical point of view, I'd say the second way misses the concept of "key=value" and is using "key:value" with a noise suffix of "=yes". Typically missing keys should be treated as having a value of either "no" or "unknown". Unless you can show me where key:value1="is something other than yes" then I may suspect you of putting values into the key field of the data.
>
> Might I suggest that a convention for keys that may contain multiple values that the ":" delimiter be used in the key but rather than putting arbitrary (data) values after the colon, use an numeric index:
>
> key:1=value1
> key:2=value2
> key:3=value3

No not at all, this makes it worse. Numbers are way to general and you
gain little.

: is usualy used for subkeys so key1, key2 would even be better.

fly


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Никита
Propaganda. Propaganda. Propaganda. 

But it's harder to get all tags in category. How would you get all the payment methods, not the exact 'ellectrico'?
Why normal person need to know about all payments methods if he/she only have mastercard/ellectrico/coins?

You probably never use data at all. DATA against your words: http://taginfo.openstreetmap.org/search?q=payment. People prefer complex tagging schemes because they can actually use this data and not to write long post about regexes at tagging list.

But for mappers, who are normal people, not the crazy data miners route_ref=1;2;3;4;5;123;124;125;126;234;235;236;456;457;458a

How you search for ref=127? You are the crazy who want to use regexes. STOP.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Никита
Presets are a problem [1],[2] and it is not easy to present tag list with more than 50 tags per object.
This is irrelevant to multivalued keys or multiple subkeys problem actually.

You need to organize 50 variants under some checkboxes or select lists. It will be hard regardless if we decide to ban semicolon in value or not.

People like to build heiraries in keys, not in values. This was since early days of OSM, I have countless links at wiki as evidence.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Никита
opening_hours:Mo-We 08:00-17:00 = yes
> opening_hours:Th-Fr 08:00-21:00 = yes
>  would in my opinion lead to an inordinate number of subkeys.

If you were reading other people messages you would probably notice that opening_hours=* tag was mentioned as minor exception to general rule not to use semicolon in value.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Никита
Using a xxx:yyy schema also requires checkboxes besides every existing value in JOSM presets. So I don't see how it is any easier for new mappers or preset creators.
Problem in multiple values in value part in key=value.

How iD should parse cuisine=mexican;japanese?

This work repeated every time by wiki editors, by iD developers, by JOSM preset developers. There no point for this. Just ban semicolon and write actual page about
whatever:mexican=yes
whatever:japanese=yes

We don't have native arrays right now. We have to decide which part of key=value will be ugly for some time so we can re-tag them back using real arrays.

 xxx:yyy=yes / semantic subtags are ugly, this is terrible for absolutely new to OSM people the same way key=value tags are terrible, but 
  • we can provide newbies them with link to wiki. 
  • we don't need to teach every person how to parse "japanese" from cuisine=mexican;japanese using f#$% regexes
  • we can provide clear definition at wiki page for iD or JOSM developers with description of tag instead of guessing by taginfo stats EVERY time they want to adjust something in presets
  • custom strings in editors or JOSM presets are easier to add
  • we get benefits from taginfo stats by using xxx:yyy=yes
  • advanced set querying for users, 
  • reduced cpu load for database because there no need to compute smart regexes

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Marc Gemis

On Fri, Jan 23, 2015 at 12:22 AM, Никита <[hidden email]> wrote:
we don't need to teach every person how to parse "japanese" from cuisine=mexican;japanese using f#$% regexes

In my code editor I can search for "complete word" by ticking a checkbox, how simple is that ? It will not match japaneseinword or wordaroundjapaneseword when the checkbox is ticked and I search for "japanese", but it will find japanese in "chinese;japanese; korean"
Just provide the users a tool with a checkbox "complete word"  or make it the default if you wish. People writing software for "dummies" will use this kind of techniques all the time. Hide the internals from the end-users.

regards

m



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Никита
I cannot understand your example without illustration.

Hide the internals from the end-users.
We can easily hide 
something:japanese=yes
something:korean=yes

under single field something=<traditional semicolon presentation>, but not vice versa. I suggested plugin for JOSM that will present multiple subkeys as text field or as multiple checkboxes, it will be not so hard to implement for JOSM.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Daniel Koć
In reply to this post by moltonel 3x Combo
W dniu 22.01.2015 19:15, moltonel 3x Combo napisał(a):

> This has been debated (yet again) on this list not long ago for the
> "name" key. The usual arguments followed. There are enough proponents
> of both styles (each with good arguments) that both styles are clearly
> here to stay (unless maybe the code data model gets updated to support
> multi-value tags).

What are the chances than to update our data model to support it? Is it
just a loose expectation (as in a "would be nice") or something more
concrete?

I also think tools can deal with semicolon-delimited lists just by
internally converting:

key=value1;value2

to a temporary array:

key[1]=value1
key[2]=value2

and returning to the semicolon mode on the output again. That would
probably help avoid too much regexping.

--
Mambałaga

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Никита
> key[1]=value1 key[2]=value2
> and returning to the semicolon mode on the output again. That would probably help avoid too much regexping.

I see your point, but sadly this is not solution. I was always mentioning xxx:yyy scheme as semantic subkeys, there no semantic in:
key[1] - what does 1 mean? nothing. There no wiki page about it. Even there page for it, how do you memorize them?

In contrast to this, my suggestion work decently, but it may look too verbose at first:
color:yellow=yes
color:red=yes

Back your example, how do you query for yellow?
key[1]=*?
key[2]=*?

Okay you know the answer, this is your indexes. But how do you know that? At first it seems like good idea, but sadly not solution to the question, instead of regexes you have to deal with meaningless numeric indexes in keys.

PS. We need arrays/native multivalued support for values in key=value tags anyway. There native arrays in PostgreSQL but I'm not sure if it will be good idea to adapt them, this will be only up to back-end developers, not about tagging.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Никита
Or wait, I actually misunderstood you, my point is still valid. Did you mean
color[1]=yellow?
color[2]=red?

But again, how do you query then? Query for red? color[*]=red? Regexes again.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Nelson A. de Oliveira
On Fri, Jan 23, 2015 at 10:08 AM, Никита <[hidden email]> wrote:
> But again, how do you query then? Query for red? color[*]=red? Regexes
> again.

He is representing an array where [1] is the first position. There is
no need for regexes.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Никита
Agree, there no regexes at first. But is it possible to query this tagging scheme? Lets say you have
color[1]=purple
color[2]=orange
color[3]=green

How do you query for green in overpass? In JOSM?

And what if for another object you will have different set of tags with different order?
color[1]=black
color[2]=green
color[3]=white

Thats why I was always suggesting this approach:
color:<actualcolorvalue>=yes

This is not array, but set. There semantic in key part of key=value. I.e. this is very similar to what OSM was always doing, no need for numeric indexes in keys IMO. It was mentioned in this discussion already.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Wiki Edit War on using/avoiding semicolon lists

Nelson A. de Oliveira
On Fri, Jan 23, 2015 at 10:20 AM, Никита <[hidden email]> wrote:
> Agree, there no regexes at first. But is it possible to query this tagging
> scheme? Lets say you have
> color[1]=purple
> color[2]=orange
> color[3]=green
>
> How do you query for green in overpass? In JOSM?

What he said:

=====
I also think tools can deal with semicolon-delimited lists just by
internally converting:

key=value1;value2

to a temporary array:

key[1]=value1
key[2]=value2
=====

So the data in OSM is still "color=purple;orange;green" but
represented to the end user as a color[] array.

If the client implements a semicolon to array converter then probably
it will also have some way to query it without using a regex
(something like python's "in")

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
1234567