Re: [Tagging] Deprecation of associatedStreet-relations

[Tobias Knerr]

On 23.01.2015 21:53, moltonel 3x Combo wrote:
> The counter-argument is that a novice is less likely to break the data
> when updating an area that is mapped using associatedStreet. I like
> the fact the fact that people need not even be aware of addresses in
> order to fix a street name.

That's not really true, the name tag on the relation is "recommended".
So the newbie would have to be aware of the relation to edit the name
both on the relation and the ways.

Even ignoring that, operations hindered by relations (especially mapping
new addresses, but also renaming only part of a street, changing the
street of a house's address, ...) are *a lot* more common than your
example. Even if we had mapped addresses to completion, addresses would
still change a lot more often than street names.

> Given that relations in general are not going away, the proper
> solution to the "novices have trouble with relations" problem is not
> to use less relations but to make relations easyer to edit and better
> documented.

Few are going to read documentation when they just start out editing, so
basic tasks really need to be relation-free to ensure a good experience.
Streets, buildings and addresses are some of the most basic concepts
there are, which makes associatedStreet so problematic.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

Well not perfect solution at the moment, but least I don't need to teach
somebody regexes: "color:green"=yes | "color:lightgreen"=yes | "color:
bluegreen"=yes | ...

"But how this is different from regexes?" you would say.

1. There no regexes at all
2. There should be pages about
http://wiki.openstreetmap.org/wiki/Tag:color:bluegreen=yes redirecting to
page with actual scheme or defition in user language...
3. No performance penalties from regexes

Alternatively you may always use multiple tags
color:green=yes
color:green:lightgreen=yes

Nobody restricts you with tagging precision here. Actually we don't have
such problem beoynd tagging list, our tags in OSM are way more easier:
http://wiki.openstreetmap.org/wiki/Key:fuel
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Marc Gemis]

On Sat, Jan 24, 2015 at 6:40 AM, Никита  wrote:

> Well I don't see how that becomes any easier by moving the values over to
> the keys.
> "color:green"!=* in overpass should return values without information
> about green color or "color:green"="no" will return objects without green
> color
>

But how can you find all green, lightgreen, bluegreen, etc. values (aka all
"greenish colors) in your approach ?

m.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

> That object is not part of the result set. Maybe he meant how to find out
that an item is missing from the list? Well I don't see how that becomes
any easier by moving the values over to the keys.
"color:green"!=* in overpass should return values without information about
green color or "color:green"="no" will return objects without green color

> And apparently coming up with regexes that can work with that, is even
more 'complex'.
It is not complex. It is *impossible to write presets or translations for
iD or JOSM* using name#2=green approach.

To all regex advocates, your knowledge of regexes is irrelevant to how OSM
functions. I wait for your solution how we should support name=,
name#2= name#3=
in presets or translations.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Voting system- time for reform?

[johnw]

> On Jan 24, 2015, at 11:04 AM, Richard Welty  wrote:
> 
> On 1/23/15 8:37 PM, Warin wrote:
>> 
>> Yes .. it makes the admin more complex. But it will get some to say 
>> something, and get others off the group. Flame away. 
>> 
> i do not think it appropriate for the membership of this group
> to set these sorts of parameters for controlling its membership. it
> goes against the grain of OSM as a project.

I think any body that dedicates itself to managing something aught to actually 
manage it - I think that is the reason this came up. 

But I think there is an even better reason that a lot of members don’t vote on 
proposals, besides a lack of enthusiasm in regards to what the tag fleshed out -

a Lack of domain knowledge coupled with a lack of a (somewhat) rigid tagging 
schema that can be applied across similar groups of tags. 

For example - the discussion raging over semicolon delineated tag values vs 
sub-key values is something I have no relevant experience in, and I couldn’t 
comment on it, let alone feel comfortable voting.

Similar to the water tap issue - I voted for the water tap because I want a way 
to tag taps - but the issues  coming up now about it breaking compatibility of 
the dataset is something I similarly don’t know, and I will refrain from 
commenting now.  Same with the Kiln questions in Tibet. 

But if there ware a more uniform tagging scheme then it would probably be 
obvious to a majority of the list members if a proposal *at least* properly 
fits into the format of tagging for a certain class of object  (bus routes, 
water taps, and buildings are all going to have different schema, of course) 
but there are several classes of tags where there is no set “standard” on how 
to implement the class, which makes proposals in that class a nightmare because 
it just devolves into what implementation schema should be followed. Since 
there a lot of older established tags and schemes that don’t follow more recent 
patterns, it just be comes a quagmire of what of all possible schemes something 
could fall under. 

My recent proposal of Landuse=civic is a good case in point - does everything 
get it’s specific landuse from amenity=* , like a hospital or a school? does it 
get’s a basic idea of purpose from the landuse area, like residential or 
commercial land? or is the idea of separating out governmental/civic amenities 
disliked - and the only big distinction should be between civilian and 
military? Handling police, fire, judicial, penal, and governmental building’s 
landuse becomes a fight over what scheme is better - or what key scheme is 
best, and no one can agree on that. - a courthouse isn’t commercial land - a 
police station isn’t a residence, and a City hall is more than Just a building. 

Those basic questions hamstring discussions - then coupled with how the changes 
will affect the dataset means people will inherently shy away from voting on 
proposals - or proposals will languish because there can be no definitive 
answer on something like landuse, since there are two basic kinds of tags, and 
I don’t think anyone wants to depreciate amenity=hospital from it’s landuse 
duties, nor landuse=industrial. 

And most taggers probably don’t understand the intricacies of supporting 
semicolon delineated values, nor kilns in tibet - so it makes it hard for 
everyone to vote. 

Opinions of the noob

Javbw




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Voting system- time for reform?

[Richard Welty]

On 1/23/15 8:37 PM, Warin wrote:


Yes .. it makes the admin more complex.But it will get some to say 
something, and get others off the group. Flame away.



i do not think it appropriate for the membership of this group
to set these sorts of parameters for controlling its membership. it
goes against the grain of OSM as a project.

richard

--
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Tagging Voting system- time for reform?

[Warin]

On 24/01/2015 11:51 AM, Bryce Nesbitt wrote: ON the subject of man_made=tap
On Fri, Jan 16, 2015 at 2:16 AM, Pieren > wrote:


On Thu, Jan 15, 2015 at 4:13 PM, Kotya Karapetyan
mailto:kotya.li...@gmail.com>> wrote:

> As of today, a total of 16 votes have been submitted, 11 of them are
> approvals. Since 2 weeks have passed and the required number of
votes
> (15) has been reached, I have closed the voting and will proceed
with
> clean up.


In fact, the proposal passed the wiki vote ONLY because the three 
people voted no at the
last minute.  If it were not for those 'no' votes, the proposal would 
have failed.


All that shows in part how dysfunctional the wiki vote system is.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Here here!
It also shows how dysfunctional this group is .. not many of you vote!

I would suggest
1) Continued membership of this group be conditional on voting on at 
least half the tags presented for voting over say the last year.
2) Rejoining members be conditional on voting on at least 8 of the next 
10 tags presented for voting.
3) Tag voting may only cease when at least 25%? of the tag group members 
have voted and 3? weeks have elapsed.


The old saying .. vote early, vote often springs to mind. Be carefull of 
the options in No 3 .. if you make the time short and the voting numbers 
small people may not be able to meet the conditions of No 1 or No2 


Yes .. it makes the admin more complex.But it will get some to say 
something, and get others off the group. Flame away.




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[Warin]

On 24/01/2015 11:07 AM, Christian Quest wrote:

Le 22/01/2015 22:49, Johan C a écrit :

Good to have this discussion. From a computer expert point-of-view
relations are fantastic for data integrity and to keep database size
low. From an OSM point-of-view, which includes being friendly towards
novice users, relations should be avoided whenever possible. And
associatedStreet relations are avoidable.


If simplicity is our new mantra, who will be the first propose to
deprecate the public_transport relation based tagging scheme ?


If you wait too long .. might be me :)  I've a few transport route 
around me tht need work .. but I'm yet to look into that 'feature'.


At the moment I have Consistency flagged .. 
https://www.openstreetmap.org/user/Warin61/diary/34267

And I've flagged logic next ..
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[Jo]

Not me.   Oh, that was a rethorical question.

Polyglot

2015-01-24 1:07 GMT+01:00 Christian Quest :

>
> Le 22/01/2015 22:49, Johan C a écrit :
> > Good to have this discussion. From a computer expert point-of-view
> > relations are fantastic for data integrity and to keep database size
> > low. From an OSM point-of-view, which includes being friendly towards
> > novice users, relations should be avoided whenever possible. And
> > associatedStreet relations are avoidable.
>
> A novice user will hardly break an associatedStreet relation, but will
> more often break addr:* when updating a streetname without updating
> related addresses.
> It is much harder to detect the second at the QA level.
>
> If simplicity is our new mantra, who will be the first propose to
> deprecate the public_transport relation based tagging scheme ?
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - Voting - Water tap

[Bryce Nesbitt]

On Fri, Jan 16, 2015 at 2:16 AM, Pieren  wrote:

> On Thu, Jan 15, 2015 at 4:13 PM, Kotya Karapetyan 
> wrote:
>
> > As of today, a total of 16 votes have been submitted, 11 of them are
> > approvals. Since 2 weeks have passed and the required number of votes
> > (15) has been reached, I have closed the voting and will proceed with
> > clean up.
>
> Sorry but you could extend the period of feedbacks. 7 of the 11
> positive "votes" came before the 13th january when I posted my
> comments about the possible issues (and the discussion forwarded here
> which probably drew more attention to more people).
>

In fact, the proposal passed the wiki vote ONLY because the three people
voted no at the
last minute.  If it were not for those 'no' votes, the proposal would have
failed.

All that shows in part how dysfunctional the wiki vote system is.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[Christian Quest]

Le 22/01/2015 22:49, Johan C a écrit :
> Good to have this discussion. From a computer expert point-of-view
> relations are fantastic for data integrity and to keep database size
> low. From an OSM point-of-view, which includes being friendly towards
> novice users, relations should be avoided whenever possible. And
> associatedStreet relations are avoidable.

A novice user will hardly break an associatedStreet relation, but will
more often break addr:* when updating a streetname without updating
related addresses.
It is much harder to detect the second at the QA level.

If simplicity is our new mantra, who will be the first propose to
deprecate the public_transport relation based tagging scheme ?

-- 
Christian Quest - OpenStreetMap France


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Jo]

It supports the 'java' flavour. It took me a while to figure out how to
work with those ;-delimited strings, but once I found this regex worked for
my purposes:

route_ref="(^|.+;)26(;.+|$)" inview odbl=new

I never looked back. As for Nikita's question about how to find an item
which is not in the semi-colon delimited list, the answer is: you don't
find it. That object is not part of the result set. Maybe he meant how to
find out that an item is missing from the list? Well I don't see how that
becomes any easier by moving the values over to the keys. And apparently
coming up with regexes that can work with that, is even more 'complex'.

Anyway, you don't have to be a programmer to find such solutions with
'complicated' regexes. Just do a Google search and you'll probably stumble
upon some wiki page I created where I documented the whole process.

Cheers,

Polyglot

PS: deleted the stuff under the 3 dots, thereby almost losing the message,
as backspace seems to instruct Firefox to go back one page.

>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Marc Gemis]

On Fri, Jan 23, 2015 at 6:25 PM, moltonel 3x Combo 
wrote:

> > How do you query for green in overpass? In JOSM?
>
> josm: name(#\d+)?=green
> overpass: I don't know it enough
>

is node[~"^name#.*$"~"^Green$"]; close enough? I'm not sure which regular
expressions JOSM supports

m
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New version of the API in the making? WAS Wiki Edit War on using/avoiding semicolon lists

[Jo]

Where can we find out whether a new version of the API is in the making?
One that could contain an explicit area type to replace closed ways and
multipolygon relations, so they become more robust, and which could have
multivalue fields built-in? Are there even plans to do that? All I hear are
murmurs that it'd be nice-to-have.

One thing I don 't hear about very often are route relations, which can
form a hierarchy, thus allowing reuse. It would lessen the amount of
relations ways need to be a member of and it would make maintaining routes
for public transport less of a burden. 2-50x less work.
It does add some complexity too, and tools will have to be rewritten to
support it, but I'm convinced it's not a difficult concept to grasp. It's
in use for some walking routes going across the continent, but it doesn't
seem to grasp hold for PT route relations.
When the tools don't support it, it has the disadvantage that one can not
visually check whether routes are continuous, but it should be feasible to
resolve that.

Jo
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[Jonathan Bennett]

On 23/01/2015 20:53, moltonel 3x Combo wrote:

+1 to all of that


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[Jo]

2015-01-23 21:53 GMT+01:00 moltonel 3x Combo :

> On 22/01/2015, Johan C  wrote:
> > From an OSM point-of-view, which includes being friendly towards novice
> > users, relations should be avoided whenever possible. And
> associatedStreet
> > relations are avoidable.
>
> The counter-argument is that a novice is less likely to break the data
> when updating an area that is mapped using associatedStreet. I like
> the fact the fact that people need not even be aware of addresses in
> order to fix a street name. Being able to add/fix housenumbers without
> having to worry about addr:street (which would be very cumbersome on
> mobile devices editors - editing while surveying FTW) is also a big
> plus.
>
> Given that relations in general are not going away, the proper
> solution to the "novices have trouble with relations" problem is not
> to use less relations but to make relations easyer to edit and better
> documented. FWIW, I feel there is slow but steady progress in that
> domain.
>

+1
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[Vincent Pottier]

Le 23/01/2015 21:53, moltonel 3x Combo a écrit :

Given that relations in general are not going away, the proper
solution to the "novices have trouble with relations" problem is not
to use less relations but to make relations easyer to edit and better
documented. FWIW, I feel there is slow but steady progress in that
domain.

+1
--
FrViPofm

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[moltonel 3x Combo]

On 22/01/2015, Johan C  wrote:
> From an OSM point-of-view, which includes being friendly towards novice
> users, relations should be avoided whenever possible. And associatedStreet
> relations are avoidable.

The counter-argument is that a novice is less likely to break the data
when updating an area that is mapped using associatedStreet. I like
the fact the fact that people need not even be aware of addresses in
order to fix a street name. Being able to add/fix housenumbers without
having to worry about addr:street (which would be very cumbersome on
mobile devices editors - editing while surveying FTW) is also a big
plus.

Given that relations in general are not going away, the proper
solution to the "novices have trouble with relations" problem is not
to use less relations but to make relations easyer to edit and better
documented. FWIW, I feel there is slow but steady progress in that
domain.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[moltonel 3x Combo]

On 23/01/2015, moltonel 3x Combo  wrote:
>> name=purple
>> name#2=orange
>> name#3=green
>>
>> How do you query for green in overpass? In JOSM?
>
> josm: name(#\d+)?=green
> overpass: I don't know it enough

Note that if "key#index=value" becomes commonly used, tools like josm
and overpass (and nominatim and and and...) will eventually integrate
it into their engine, so that searching for "key" will also
automatically find "key(#\d+)?".

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[moltonel 3x Combo]

On 23/01/2015, Никита  wrote:
>> the classic example being the name key.
> This is bad example. We have many tags with their own semantic:
> http://wiki.openstreetmap.org/wiki/Names#Key_Variations We don't need
> name_1, name_2 or name#1 or name#2 keys.

Of course when you can figure out names that are semantically
different, you use the specific tag. But it's not rare that a place
has two names that cannot be differentiated by semantic or popularity.
In those cases you have alt_name if you're lucky enough to only need
one extra name, and name_ if you need more values.

> There no point in using indexes in key. You need semantic subkey:
> color, length, size, visibility. Not meaningless integers. Again, my
> example several messages earlier:

Indexes and subkeys are two different usecases. Both are useful.

> name=purple
> name#2=orange
> name#3=green
>
> How do you query for green in overpass? In JOSM?

josm: name(#\d+)?=green
overpass: I don't know it enough

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[moltonel 3x Combo]

On 23/01/2015, althio  wrote:
> Visually for index I would go for "#" or "-" but I don't know if that
> is acceptable regarding special characters status.
>
> name=*
> name#2=*
> name#3=*

I really like using '#' as the index separator. It is sometimes
pronounced "number". It hasn't been used before in osm keys (AFAIK),
which is both a blessing (no clash with an existing definition) and a
curse (need to convince everybody to start using that).

'_', '-', and '' (empty string) have the drawback of being mistakable
for something else.

'[]' may appeal to some (it's the same syntax as many programming
languages), but it feels a bit verbose and it can be a pain for
regexps.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Colin Smale]

 

Tag namespaces already provide a kind of "data structure" facility. IMHO
a syntax that is close to the traditional way of representing vectors of
structures would be something like this: 

addr[1]:housenumber=1234
addr[1]:street=Main Street
addr[2]:housenumber=7654
addr[2]:street=Elm Avenue

All house numbers are called "housenumber", addr[1] and addr[2] are both
instances of an address. 

In fact, if the ":" is replaced by a ".", it starts to look very
familiar 

Is the maximum length of a value still 255 characters (or is it bytes?)?
With the ";" syntax we could easily come up against that limit, whereas
an array / key-based syntax would allow 255 for each individual value. 

Obviously (at least IMHO) the data model of OSM would benefit from
having a defined method to represent higher-level constructs. Some
people are already talking about having an "area" or a "polygon"
distinct from a "way" with start=end. Why not have a proper discussion
about how to represent lists of values? Of course it helps to have some
examples in mind, but let's step back and find a more generic solution
which will also address our current problem. 

I really don't think the fact that some people don't understand regular
expressions is a good reason to not look to the future. Once a standard
is defined, the software will soon catch up - if the standard is
well-specified. If the standard is not well-specified, poorly
documented, too many exceptions etc then it will be "ignored". 

Colin 

On 2015-01-23 17:29, Tod Fitch wrote: 

> On Jan 23, 2015, at 7:47 AM, Richard Welty wrote:
> On 1/23/15 10:13 AM, jgpacker wrote: I don't understand the insistence in 
> using regexes as some kind of argument against semicolon lists. A semicolon 
> list is an extremely simple pattern. Such a pattern can be easily parsed even 
> WITHOUT regexes. Me and other developers in this thread (Imagic, Friedrich, 
> David, Dmitry, Marc) are trying to tell you semicolons are not a problem. +1 
> competent languages provide simple mechanisms for splitting strings on single 
> characters. sometimes the function is even called "split" richard

Yes, nearly every scripting language I've used has an easy way to split
a string on a character or substring.

Is there is a value string that contains a semi-colon that is part of
the actual value rather than a delimiter between values. I can't think
of any but since for some key names the value field is free form I
suppose it could happen. A semantic solution to that would be to
document which keys may have (or maybe a shorter list of exceptions that
cannot have) multiple values separated by semi-colons.

However there is the related question of how to deal with things like
multiple addresses for one object, the subject of another current
thread. In this case you probably don't want to be dealing with:

addr:housenumber=1234;7654
addr:street=Main Street;Elm Avenue

So you will be dealing with something like:

addr:housenumber=1234
addr:street=Main Street
addr:housenumber_1=7654
addr:street_1=Elm Avenue

Coming up with a uniform way of dealing with arrays of values would mean
that a simple and consistent solution could be used for both problems.

I don't much care if the syntax of the key is "key:1", "key_1", "key#1"
or "key[1]" but I do think that something needs to be picked for sets of
keys that have related values. And once you do that the solution could
be applied as an alternative to semi-colon delimited values in the case
being discussed here.

Having one approach that solves two issues seems better to me than
having two solutions. Yes, any robust data consumer software will have
to deal with all the existing ways things are done now. But
standardizing on way to go forward should help in the future.

Cheers,
Tod Fitch

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging [1]

 

Links:
--
[1] https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Richard Welty]

i've removed prior discussion so that this can stand on its own.

i admit that the distinction between keys and values is a bit
blurry; it would be a fallacy to claim that data goes only in
values because that's obviously not completely true.

however, i will assert that for key space to be useful it needs
to be managed; pushing to much arbitrary data into the key
space reduces its utility.

from this point of view, having colour in key space makes sense
but having the actual names of colours as subkeys seems to me
to be overloading too much data value into the key side. for
every parsing problem you simplify on the value side by flipping
data into subkeys, you create additional complexity when data
consumers must navigate key space.

what we're doing now is not necessarily ideal, the fact that
we're having this discussion shows this. however, moving
a bunch of data data into key space to avoid semicolons
does not strike me as an improvement.

richard

--
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Tod Fitch]

On Jan 23, 2015, at 7:47 AM, Richard Welty wrote:

> On 1/23/15 10:13 AM, jgpacker wrote:
>> I don't understand the insistence in using regexes as some kind of argument 
>> against semicolon lists.
>> 
>> A semicolon list is an extremely simple pattern.
>> Such a pattern can be easily parsed even WITHOUT regexes.
>> 
>> Me and other developers in this thread (Imagic, Friedrich, David, Dmitry, 
>> Marc) are trying to tell you semicolons are not a problem.
>> 
> +1
> 
> competent languages provide simple mechanisms for splitting
> strings on single characters. sometimes the function is even
> called "split"
> 
> richard

Yes, nearly every scripting language I've used has an easy way to split a 
string on a character or substring.

Is there is a value string that contains a semi-colon that is part of the 
actual value rather than a delimiter between values. I can't think of any but 
since for some key names the value field is free form I suppose it could 
happen. A semantic solution to that would be to document which keys may have 
(or maybe a shorter list of exceptions that cannot have) multiple values 
separated by semi-colons.

However there is the related question of how to deal with things like multiple 
addresses for one object, the subject of another current thread. In this case 
you probably don't want to be dealing with:

addr:housenumber=1234;7654
addr:street=Main Street;Elm Avenue

So you will be dealing with something like:

addr:housenumber=1234
addr:street=Main Street
addr:housenumber_1=7654
addr:street_1=Elm Avenue

Coming up with a uniform way of dealing with arrays of values would mean that a 
simple and consistent solution could be used for both problems.

I don't much care if the syntax of the key is "key:1", "key_1", "key#1" or 
"key[1]" but I do think that something needs to be picked for sets of keys that 
have related values. And once you do that the solution could be applied as an 
alternative to semi-colon delimited values in the case being discussed here.

Having one approach that solves two issues seems better to me than having two 
solutions. Yes, any robust data consumer software will have to deal with all 
the existing ways things are done now. But standardizing on way to go forward 
should help in the future.

Cheers,
Tod Fitch


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Richard Welty]

On 1/23/15 10:13 AM, jgpacker wrote:
I don't understand the insistence in using regexes as some kind of 
argument against semicolon lists.


A semicolon list is an extremely simple pattern.
Such a pattern can be easily parsed even WITHOUT regexes.

Me and other developers in this thread (Imagic, Friedrich, David, 
Dmitry, Marc) are trying to tell you semicolons are not a problem.



+1

competent languages provide simple mechanisms for splitting
strings on single characters. sometimes the function is even
called "split"

richard

--
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[jgpacker]

I don't understand the insistence in using regexes as some kind of argument
against semicolon lists.

A semicolon list is an extremely simple pattern.
Such a pattern can be easily parsed even WITHOUT regexes.

Me and other developers in this thread (Imagic, Friedrich, David, Dmitry,
Marc) are trying to tell you semicolons are not a problem.




--
View this message in context: 
http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523p5831177.html
Sent from the Tagging mailing list archive at Nabble.com.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

> the classic example being the name key.
This is bad example. We have many tags with their own semantic:
http://wiki.openstreetmap.org/wiki/Names#Key_Variations We don't need
name_1, name_2 or name#1 or name#2 keys.

> name=*
> name#2=*
> name#3=*
There no point in using indexes in key. You need semantic subkey:
color, length, size, visibility. Not meaningless integers. Again, my
example several messages earlier:

name=purple
name#2=orange
name#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?
name=black
name#2=green
name#3=white

Again name is bad example,
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[althio]

> Also, I think that the subkey separator (':') should be different from
> the index separator (let's say '_' although that isn't fully
> standardised yet). Because I could concoct an example where "2" is a
> subkey rather than an index.

Visually for index I would go for "#" or "-" but I don't know if that
is acceptable regarding special characters status.

name=*
name#2=*
name#3=*

or

cuisine=*
cuisine-2=*
cuisine-3=*

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[althio]

While I am no skilled programmer I agree with the next points:
(any guru is welcome to disregard my following opinion if he wants to)


> Just because one can use a regular expression to grep out a certain meaning 
> doesn't mean it's a good thing to do and will always work.

Regexps are AFAIK quite controversial because they are efficient at
some tasks but also can be hard to maintain -- especially if poorly
documented.

OSM is an open project for open data and we should strive not to
create unnecessary hurdles for access and use of this data.

OSM is not only for developers but also for experts in their fields
(but not computing/programming), students, local communities and any
citizen.

Regexps should not be used or misused as peer recognition or trial to
check whether someone is worthy to access all levels of data.
"It is easy for any good enough programmer": not a good argument in my book.


> [key:subkey=*] gives the flexibility to distinguish between equal and 
> distinguished importance

I agree that it is more flexible, gives more freedom to sort and add details.
If I am not mistaken [key:subkey=*] can do everything as
[key=values;separated;by;semicolon] and more. The reverse is not true.


> [I too consider that] Using semicolon-lists for values [is] a crutch until a 
> better tagging-scheme comes along.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[moltonel 3x Combo]

On 22/01/2015, fly  wrote:
> Am 22.01.2015 um 21:32 schrieb Tod Fitch:
>> 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.

Subkeys are not always usable, the classic example being the name key.

Also, I think that the subkey separator (':') should be different from
the index separator (let's say '_' although that isn't fully
standardised yet). Because I could concoct an example where "2" is a
subkey rather than an index.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[moltonel 3x Combo]

On 22/01/2015, Tod Fitch  wrote:
> 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

3. key=value

> 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.

You've given examples yourself where the value isn't "yes". The keys
addr1:housenumber and name_1 obviously don't have "yes" as a value.

Note also that nobody ever tagged "addr=42;Backer Street". It's not
"key:value" but "key:subkey".

> 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.

Yes, I'd actually like to see this discussion happening. Seeing
"addr1" suggested when "name_1" is in use irks me (the separator isn't
the same). Another format that occasionally gets suggested is
"key[index]=value". And it might be a good idea to clarify the
interpretation with subkeys (is it "key_1:subkey" or "key:subkey_1"
?).

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[moltonel 3x Combo]

On 22/01/2015, Martin Koppenhoefer  wrote:
> a minor issue with semicolon separated lists: we don't have yet defined how
> to escape actual semicolons in values.

To me, that is actually a major issue (putting blank fields in the same basket).

Defining how litteral semicolons and blank fields should be
represented isn't that hard. But making sure that consumers (let alone
editors) all follow whatever algorythm we'd end up choosing is damn
near impossible. Even if you wave your magik wand and convert all
programs today, tomorrow 10 new program will be writen that just uses
split(value,';') because that's the obvious implementation.

That impossibility is why I'm convinced that semicolons as the only
way to support multiple values is a very bad idea, despite being often
nicer to look at. They're fine to use for simple cases, but not for
anything complex or wide-ranging.

Contrast semicolons with the key_ scheme, which can safely be
implemented universally for all keys by a consumer, or the various
key:subkey schemes which can present more subtle information. And
contrary to semicolons, both those schemes downgrade gracefuly when
the consumer doesn't handle multiple-value schemes.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[moltonel 3x Combo]

On 22/01/2015, Charles Basenga Kiyanda  wrote:
> 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.

That's probably because opening_hours is arguably *not* a
multiple-values field, so it's not very interesting to bring it into
this discussion. A bit like seamark colors, providing only part of the
information is barely usefull (which indeed makes the idea of spliting
opening_hours into multiple keys silly).

Opening_hours is complex enough that it needs its own specific parser.
You can't treat it as a generic multiple-values field. It wouldn't
make any difference if the opening_hours spec was using '&' instead of
';' for example.


> 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.

Yes, that's definitely out. Using the key to convey multiple values is
only advisable if the value is standardised. As was said earlyer,
nobody is suggesting "name:Main Street=yes" either.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Никита]

> So the data in OSM is still "color=purple;orange;green"
This data will be untranslated for iD users. It is freetext without
selectbox and prone to errors. *You have to know tags* *when you use this
approach*.

http://wiki.openstreetmap.org/wiki/Key:mtb:scale:imba is not displayed
directly as mtb:scale:imba=grade2. We have verbose strings for them:
(option #2 in selectbox, RU) "Лёгкая (зелёный круг)"

Instead of "trail_visibility"="good" you have string
(option #2 in selectbox, EN) "Good: markers visible, sometimes require
searching"

You can actually translate keys right now in iD, no change in iD code:
color:purple=yes "фиолетовый"
color:orange=yes "оранжевый"
color:green=yes "зелёный"

They are just regular tags.

This easy solution is impossible with "color=purple;orange;green". I have
no idea why there people who advocate "color=purple;orange;green" approach.
70+ messages, but only 1 argument *it is easier to enter*. Easier to enter
for the person who knows everything and uses regexes every time - yes, or
anybody else - no.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Nelson A. de Oliveira]

On Fri, Jan 23, 2015 at 10:20 AM, Никита  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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:**=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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Nelson A. de Oliveira]

On Fri, Jan 23, 2015 at 10:08 AM, Никита  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Daniel Koć]

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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging