Re: [Tagging] Feature Proposal - RFC - addrN:*

[Swen Wacker]

2015-01-22 19:44 GMT+01:00 fly :

> In Germany the address always belongs to the plot and not to the
> building and they are assigned in advance.
>

This is not correct. The decision is up to the local government. In most
local "Hausnummer-Satzung" (by-law about housenumber) that I've looked at
there is a preference for buildings.  German-speaking might look huere:
http://forum.openstreetmap.org/viewtopic.php?pid=472337#p472337

cu

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

Re: [Tagging] 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*=**, 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
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 12:22 AM, Никита  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 64, Issue 110

[Warin]

On 23/01/2015 10:22 AM, tagging-requ...@openstreetmap.org wrote:

Date: Thu, 22 Jan 2015 14:38:34 -0800
From: Bryce Nesbitt
To: "Tag discussion, strategy and related tools"

Subject: Re: [Tagging] Feature proposal - Voting - Water tap
Message-ID:

Content-Type: text/plain; charset="utf-8"

On Thu, Jan 15, 2015 at 7:13 AM, Kotya Karapetyan
wrote:



You're messing with existing successful tagging efforts, making it harder
for those who came before you,
and effectively asking others to clean up after you. * The "exactly how to
do it" is to address the issues and start over.*


I suggest Bryce you come up with a better tag for a water tap, drinkable 
or not or somewhere between those two, any temperature, any tap handle, 
any spigot?


As for "successful tagging efforts" .. the success may be measured by 
the resultant maps. But not by the confusion of newer mappers. I'll have 
further to say on that in my thread on tagging philosophy, much later 
when everyone has had time to make there thoughtful comments.


Thanks for your input. I look forward to a better tag for water tap. 
And, if you'd be so kind, the thinking behind it?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electronic or 'e' cigarettes?

[Andrew Errington]

How about "e-bacconist"?

Actually, I'm not seriously recommending it.  I thought I had just made up
something new and unique, albeit tongue-in-cheek.  However, I just googled
it and it appears to be a thing.

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

Re: [Tagging] Electronic or 'e' cigarettes?

[John F. Eldredge]

On 01/22/2015 08:02 AM, Dave F. wrote:

Hi

A shop that solely sells electronic cigarettes has been added locally. I
guess this type of product will be on the increase so I think it's best
to clarify unified tag, if there's ever been such a thing in OSM :-)
Checking Tag-info it's 8/6 in favour of electronic_cigarettes over
e-cigarettes.

To me, electronic_cigarettes is clearer & should be used, but I thought
it best to discuss first. I don't smoke, are all these power based?


I don't smoke either, but my understanding is that the electronic 
cigarette contains a battery-powered heater and a reservoir of 
nicotine-containing liquid.  Some are designed to be thrown away once 
the battery power and/or liquid are used up, others can have both the 
battery and liquid replaced.


--
John F. Eldredge -- j...@jfeldredge.com
"Darkness cannot drive out darkness; only light can do that.
Hate cannot drive out hate; only love can do that."
Dr. Martin Luther King, Jr.

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

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

[Tod Fitch]

On Jan 22, 2015, at 4:08 PM, Bryce Nesbitt wrote:

> . . . Or other places:
> 
> tourism=camp_site
> drinking_water=no
> toilets=yes
> 
> 
> At the first level of tagging these can be seen as attributes of the amenity, 
> much like opening hours, website, etc..
> If detailed tagging is done (e.g. individual camp pads), then the individual 
> water taps can be mapped at that time.  Until then the existing tagging works 
> just fine.
> 
> For backcountry camp sites tagging water is critical.  The first question 
> after "where is it", is "will there be water", followed by "is that water 
> potable". 
> 
> 
> Bottom line: please listen to other mappers.

For campsites there was a discussion a while back and the wiki has some of the 
results including how to tag water at an individual pitch:

http://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site#Tagging_of_individual_pitches

Potability of the water was not, however, considered.

___
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 4:03 PM, Kotya Karapetyan 
wrote:

> 7. Personally, I believe drinking_water=* is a much better solution
> than amenity=drinking_water:
> 7.1) The source of drinking water (which, I fully agree, is important
> for a lot of users) may not be a dedicated amenity, and still be very
> useful: e.g. a public toilet in a well-developed country can provide
> access to drinking water, but it's not an amenity=drinking_water, it
> is amenity=toilet. Marking one thing with two amenity nodes is
> possible but (1) it's a workaround rather than a nice solution; (2) I
> think many people, especially tourists from less developed countries,
> may not even understand such tagging and will be looking for a
> dedicated amenity.
>

A key problem with your proposal is divergent tagging with no migration
plan.

-

Double amenity was *not* in common use prior to your proposal:

amenity=toilets;drinking_water

Instead the tagging has been:

amenity=toilets
drinking_water=no

Similarly for shops:

amenity=shop
toilets=yes
toilets:wheelchair=yes
toilets:disposal=flush

Or other places:

tourism=camp_site
drinking_water=no
toilets=yes


At the first level of tagging these can be seen as attributes of the
amenity, much like opening hours, website, etc..
If detailed tagging is done (e.g. individual camp pads), then the
individual water taps can be mapped at that time.  Until then the existing
tagging works just fine.

For backcountry camp sites tagging water is critical.  The first question
after "where is it", is "will there be water", followed by "is that water
potable".


Bottom line: please listen to other mappers.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

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

Re: [Tagging] Electronic or 'e' cigarettes?

[Andreas Goss]

On 1/22/15 23:13 , fly wrote:

No, but it is common sence to introduce tags in proposal name space and
once they are in common use accept them because of it use.


Well, you can go ahead and create dozens of proposals that will go 
nowhere. I have completely given up on that process. It will be 
discussed here for 1-2 days and then will be forgotten. (I even asked 
for feedback for more feedback a few days ago... nothing). I'm not going 
to waste my time with that anymore when it's always the same few people 
who make any tag page edits in the Wiki anyway.


If someone does not like "in use" and prefers "proposed", fine go ahead 
and write it. Don't like the tag at all: Create a proposal for an 
alternative. But my time is limited and I rather have stuff documented 
so other mappers can find it and we don't have 10x different tags with 
slighly different meanings.

__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


___
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 4:03 PM, Kotya Karapetyan 
wrote:

> 2. Having said this, I would like to draw your attention to the fact
> that people who currently actively oppose the proposal have not
> participated in a 4-month discussion, where most of the current
> concerns were raised and analysed.
>

Your job as a proposer is not just to stuff something on the wiki and hope
nobody notices... you need
to *FIND* the community around the tags you are proposing.  You did not do
this.

I happened to find you AND comment in a timely manner, so your statement
above is not correct.
The goal is not to 'analyze and ignore' but rather to reach 'consensus'.
You are laser focused on mapping a specific feature, but missing the bigger
picture.

http://wetap.org/ is an example organization you should have been able to
identify and contact.
That's based on OSM data, and you are pulling the rug out from under them.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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.

http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Bryce Nesbitt]

On Thu, Jan 15, 2015 at 7:13 AM, Kotya Karapetyan 
wrote:

> Dear all,
>
> 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.
>
> I appreciate all the discussion and help from your side (it was my
> first proposal, so I didn't know exactly how it should be carried
> out).
>

I think you should take the negative feedback to heart, regardless of the
vote outcome.

You're messing with existing successful tagging efforts, making it harder
for those who came before you,
and effectively asking others to clean up after you. * The "exactly how to
do it" is to address the issues and start over.*
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Electronic or 'e' cigarettes?

[moltonel 3x Combo]

On 22/01/2015, fly  wrote:
 The wiki page is very recent with only two contributors. I wouldn't be
 surprised if "e-cigarette" in the db was also contributed by no more
 than 1-2 mappers. I suggest contacting them to make sure that they are
 ok with "e_cigarette", and then make the change to wiki and db.
>>
>> There are at least 30 mappers who have used shop=e-cigarette. Almost
>> all of them started using this tag *after* user StephaneP imported
>> about 80 e-cigarette shops in France.

My hunch about few mapper was due to the spelling looking wrong to me,
and the many variations. Thanks for checking.

>> I also think that e-cigarette would be better than e_cigarette, as the
>> - does not represent a space, and "e-cigarette" is a regular English
>> word, used for instance in newspapers.
>
> No doubt about the spelling but still prefer a tag without abbreviation
> and advertising background. So call it by proper name. In my case
> electronic_cigarette=yes.

I always spelled it "ecigarette" in my mind, but what do I know ?
Googling and duckducking show all 3 variations to be fairly common.
But they're all kind of slang/marketing terms (like "e-cig"), so I
think that electronic_cigarette is a better fit for osm. FWIW, that's
what wikipedia uses too.

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

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

[fly]

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

Re: [Tagging] Electronic or 'e' cigarettes?

[fly]

Am 22.01.2015 um 19:43 schrieb Matthijs Melissen:
> On 22 January 2015 at 18:00, fly  wrote:
>> Well the first page should be under proposal and it should not be listed
>> under shop or if only under some proposal paragraph
> 
> Only six shop types have been approved by the wiki/voting process:
> bakery, baby_care, second_hand, seafood, bookmaker, and lottery (and
> seafood is questionable due to not having the required number of
> votes).
> 
> Do you suggest to list all other shop types, including well-known ones
> such as shop=supermarket, as 'under proposal'?

No, but it is common sence to introduce tags in proposal name space and
once they are in common use accept them because of it use.

>>> The wiki page is very recent with only two contributors. I wouldn't be
>>> surprised if "e-cigarette" in the db was also contributed by no more
>>> than 1-2 mappers. I suggest contacting them to make sure that they are
>>> ok with "e_cigarette", and then make the change to wiki and db.
> 
> There are at least 30 mappers who have used shop=e-cigarette. Almost
> all of them started using this tag *after* user StephaneP imported
> about 80 e-cigarette shops in France.
> 
> I also think that e-cigarette would be better than e_cigarette, as the
> - does not represent a space, and "e-cigarette" is a regular English
> word, used for instance in newspapers.

No doubt about the spelling but still prefer a tag without abbreviation
and advertising background. So call it by proper name. In my case
electronic_cigarette=yes.

Cheers

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

Re: [Tagging] Deprecation of associatedStreet-relations

[Johan C]

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.

Cheers, Johan

2015-01-22 21:46 GMT+01:00 Michael Reichert :

> Hi,
>
> Am 2015-01-22 um 16:14 schrieb Vincent Pottier:
> > Le 22/01/2015 14:00, althio a écrit :
> >>> Hi all - does anyone know what the geographic distribution of
> >>> associatedStreet is like? taginfo doesn't render a map (it seems it
> >>> doesn't do that for relations).
> > UK 
> ~9000
> > PL  ~1700
> > CZ  ~ 100
> > HU  ~ 130
> > SE  >
> 900
> > RU  1850
> > FR is down
> > No stats for DE
> >> This shows a map, I don't know if this is what you are looking for:
> >> http://taginfo.openstreetmap.org/tags/type=associatedStreet#map
> >>
> >>
> http://taginfo.openstreetmap.org/tags/type=associatedStreet#combinations
> >> also shows that
> >> 61 307 / 218 176 = 28.10% are also tagged with ref:FR:FANTOIR=*
> >> so from France.
> > 28 % at least !
>
> Overpass-API results for Germany (count function which is marked as
> experimental): 48.732 relations (I did not count their members)
>
> housenumbers in Germany total (including those which belong to
> associatedStreet relations): 7.762.395 [1]
>
> For comparison, number of addr:housenumber (number of associatedStreet
> relations in brackets, copied from above) in
> United Kingdom: 840 437 (9000)
> Poland: 5 173 771 (1700)
> Czech Republic: 2 824 442 (100)
> Hungary: 64 276 (130)
> Sweden: 341 533 (900)
> Russia: 2 444 832 (1850)
>
> [1] data from 2015-01-11, user Gehrke,
>
> https://wiki.openstreetmap.org/wiki/User:Gehrke#Entwicklung_des_Adressbestandes
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
>
>
> ___
> 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] Wiki Edit War on using/avoiding semicolon lists

[fly]

Am 22.01.2015 um 18:08 schrieb Marc Gemis:
> 
> On Thu, Jan 22, 2015 at 4:49 PM, althio  > 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[Michael Reichert]

Am 2015-01-22 um 21:41 schrieb Michael Reichert:
> Worldwide, 3,573,027 objects are member of an associatedStreet relation
> and have the role "house". [1,2] 49,260,005 objects are tagged with
> addr:housenumber=*. That's why 7.2 % of all adresses in OSM are mapped
> using relations.


[1] https://taginfo.openstreetmap.org/relations/associatedStreet
[2] There are  7114 objects which have the role "address". But they are
only 0.2 % of all housenumber members of associatedStreet relations.
That's why ignored them in my calculation.


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[Michael Reichert]

Hi,

Am 2015-01-22 um 16:14 schrieb Vincent Pottier:
> Le 22/01/2015 14:00, althio a écrit :
>>> Hi all - does anyone know what the geographic distribution of
>>> associatedStreet is like? taginfo doesn't render a map (it seems it
>>> doesn't do that for relations).
> UK  ~9000
> PL  ~1700
> CZ  ~ 100
> HU  ~ 130
> SE  >  900
> RU  1850
> FR is down
> No stats for DE
>> This shows a map, I don't know if this is what you are looking for:
>> http://taginfo.openstreetmap.org/tags/type=associatedStreet#map
>>
>> http://taginfo.openstreetmap.org/tags/type=associatedStreet#combinations
>> also shows that
>> 61 307 / 218 176 = 28.10% are also tagged with ref:FR:FANTOIR=*
>> so from France.
> 28 % at least !

Overpass-API results for Germany (count function which is marked as
experimental): 48.732 relations (I did not count their members)

housenumbers in Germany total (including those which belong to
associatedStreet relations): 7.762.395 [1]

For comparison, number of addr:housenumber (number of associatedStreet
relations in brackets, copied from above) in
United Kingdom: 840 437 (9000)
Poland: 5 173 771 (1700)
Czech Republic: 2 824 442 (100)
Hungary: 64 276 (130)
Sweden: 341 533 (900)
Russia: 2 444 832 (1850)

[1] data from 2015-01-11, user Gehrke,
https://wiki.openstreetmap.org/wiki/User:Gehrke#Entwicklung_des_Adressbestandes

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[Michael Reichert]

Hi Dan,

Am 2015-01-22 um 13:06 schrieb Dan S:
> 2015-01-22 6:53 GMT+00:00 Marc Gemis :
>> It seems like the German community started some voting process on the
>> deprecation of the associatedStreet-relation (it was on the mailing list and
>> on the forum).
>>
>> Discussion is going on on the wiki
>> https://wiki.openstreetmap.org/wiki/DE:Relation:associatedStreet
> 
> Hi all - does anyone know what the geographic distribution of
> associatedStreet is like? taginfo doesn't render a map (it seems it
> doesn't do that for relations). I hear rumours it's mainly Germany but
> it'd be handy to know.

Worldwide, 3,573,027 objects are member of an associatedStreet relation
and have the role "house". [1,2] 49,260,005 objects are tagged with
addr:housenumber=*. That's why 7.2 % of all adresses in OSM are mapped
using relations.

Best regards

Michael





signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

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

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

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

[Martin Koppenhoefer]

> Am 22.01.2015 um 14:07 schrieb Jo :
> 
> 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.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

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

Re: [Tagging] 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




--
View this message in context: 
http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523p5831050.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

[Charles Basenga Kiyanda]

On 15-01-22 01:44 PM, tagging-requ...@openstreetmap.org wrote:
> Message: 3
> Date: Thu, 22 Jan 2015 18:08:49 +0100
> From: Marc Gemis 
> To: "Tag discussion, strategy and related tools"
>   
> Subject: Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
> Message-ID:
>   
> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - addrN:*

[fly]

Am 22.01.2015 um 04:02 schrieb John F. Eldredge:

> If you have a "strictly delimited plot of land", with no house currently
> built upon it, but which is intended for later construction, does it
> have a house number?  Or is the address only assigned once a building is
> built?

In Germany the address always belongs to the plot and not to the
building and they are assigned in advance.

cu fly



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

Re: [Tagging] Electronic or 'e' cigarettes?

[Matthijs Melissen]

On 22 January 2015 at 18:00, fly  wrote:
> Well the first page should be under proposal and it should not be listed
> under shop or if only under some proposal paragraph

Only six shop types have been approved by the wiki/voting process:
bakery, baby_care, second_hand, seafood, bookmaker, and lottery (and
seafood is questionable due to not having the required number of
votes).

Do you suggest to list all other shop types, including well-known ones
such as shop=supermarket, as 'under proposal'?

>> The wiki page is very recent with only two contributors. I wouldn't be
>> surprised if "e-cigarette" in the db was also contributed by no more
>> than 1-2 mappers. I suggest contacting them to make sure that they are
>> ok with "e_cigarette", and then make the change to wiki and db.

There are at least 30 mappers who have used shop=e-cigarette. Almost
all of them started using this tag *after* user StephaneP imported
about 80 e-cigarette shops in France.

I also think that e-cigarette would be better than e_cigarette, as the
- does not represent a space, and "e-cigarette" is a regular English
word, used for instance in newspapers.

-- Matthijs

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

Re: [Tagging] Electronic or 'e' cigarettes?

[moltonel 3x Combo]

On 22/01/2015, Andreas Goss  wrote:
>> Using "-" instead of "_" goes against a very established tagging practice.
>
> Only for whitespace as far as I know. So I don't see a issue here.

That surprises me, but looking at a dump of Ireland (taginfo search is
too coarse, so I used some local data I had) there does seem to be
some cases, namely "semi-detached" and "multi-storey". I wanted to
search the british isles extract, but that's taking ages to process.

I stand corrected.

> I would even say using _ is wrong.
>
> e_cigarette => "e cigarette"
> e-cigarette => "e-cigarette"

It's not at all clear that "e-cigarette" is more common outside osm
than "e cigarette" or "ecigarette", as a google search will show you.


On 22/01/2015, fly  wrote:
> Is it really to much typing to use electronic_cigarettes ?

I don't think so, I'd be happy to use the more verbose, less
marketing, less varied "electronic_cigarette" (singular, just because
there's no more reason to make it plural than any other shop=*
value... but it's a nitpick and I'm not going to argue about it if
people feel otherwise).

> Anyway, I do not know a single shop in my area which only sells them so
> shop=* will never fit.

I know a few that litterally sell just that. It's probably just a
trend (anyone knows of a shop that only sells cigarettes ?) but a lot
of them exist today.

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

Re: [Tagging] Electronic or 'e' cigarettes?

[panieravide]

Hello, 

Le 22/01/2015 17:50, Andreas Goss a écrit : 


I just created the page, because the tag was used (TagInfo), but not 
documented. See: 
http://wiki.openstreetmap.org/wiki/Category:Undocumented_Tags 


And I added some more explanations on it because it was marked as undocumented. 
The added elements are common sense or based on what is already present in the 
database. I don't have any opinion on if the value is correct or should be 
changed ;) 
___
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, Dmitry Kiselev  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_=*.

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

Re: [Tagging] Electronic or 'e' cigarettes?

[fly]

Am 22.01.2015 um 16:22 schrieb moltonel 3x Combo:
> On 22/01/2015, althio  wrote:
>> Existing pages: value "e-cigarette" is referenced in the wiki.
>>
>> http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette
>> http://wiki.openstreetmap.org/wiki/Key:shop#Others

Well the first page should be under proposal and it should not be listed
under shop or if only under some proposal paragraph

> Using "-" instead of "_" goes against a very established tagging practice.

already answered

> The wiki page is very recent with only two contributors. I wouldn't be
> surprised if "e-cigarette" in the db was also contributed by no more
> than 1-2 mappers. I suggest contacting them to make sure that they are
> ok with "e_cigarette", and then make the change to wiki and db.

+1

Is it really to much typing to use electronic_cigarettes ?

Anyway, I do not know a single shop in my area which only sells them so
shop=* will never fit.

cu fly

___
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 Thu, Jan 22, 2015 at 4:49 PM, althio  wrote:

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

> In this thread we are also most interested in multiple values.

I know :-)


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

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.

regards

m


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

Re: [Tagging] Electronic or 'e' cigarettes?

[Andreas Goss]

Using "-" instead of "_" goes against a very established tagging practice.


Only for whitespace as far as I know. So I don't see a issue here. I 
would even say using _ is wrong.


e_cigarette => "e cigarette"
e-cigarette => "e-cigarette"


The wiki page is very recent with only two contributors. I wouldn't be
surprised if "e-cigarette" in the db was also contributed by no more
than 1-2 mappers. I suggest contacting them to make sure that they are
ok with "e_cigarette", and then make the change to wiki and db.


I just created the page, because the tag was used (TagInfo), but not 
documented. See:

http://wiki.openstreetmap.org/wiki/Category:Undocumented_Tags

__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

Re: [Tagging] Electronic or 'e' cigarettes?

[Steve Doerr]

On 22/01/2015 15:22, moltonel 3x Combo wrote:

On 22/01/2015, althio  wrote:

Existing pages: value "e-cigarette" is referenced in the wiki.

http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette
http://wiki.openstreetmap.org/wiki/Key:shop#Others

Using "-" instead of "_" goes against a very established tagging practice.



-1

The underscore character is widely substituted for the space character 
in tag keys and values, but I think the hyphen is considered OK. For the 
avoidance of doubt, in English you would write 'electronic cigarette' 
(with a space) or 'e-cigarette' (with a hyphen), but not 'e cigarette' 
(with a space).


--
Steve

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


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

Re: [Tagging] Electronic or 'e' cigarettes?

[althio]

>> Existing pages: value "e-cigarette" is referenced in the wiki.
>>
>> http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette
>> http://wiki.openstreetmap.org/wiki/Key:shop#Others
>
> The wiki page is very recent with only two contributors. I wouldn't be
> surprised if "e-cigarette" in the db was also contributed by no more
> than 1-2 mappers. I suggest contacting them to make sure that they are
> ok with "e_cigarette", and then make the change to wiki and db.

Indeed. I wanted to point to existing pages to explain the apparent
choice of "e-cigarette" in taginfo.
Also discussion on the Talk:page should be good starting point for a
new proposal.


> Using "-" instead of "_" goes against a very established tagging practice.

I was wondering. Could you confirm that "-" is avoided in tags? It is
not referenced at
http://wiki.openstreetmap.org/wiki/Any_tags_you_like#Characters


> To me, electronic_cigarettes is clearer & should be used

You will have to decide if a common abbreviation is acceptable.
[electronic_ OR e- OR e_]
And as you noticed, singular vs plural.

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

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

[althio]

>> My little +1 for key:subkey=*
>
> New people don't know how to add new keys. So they will have problems to add
> cuisine:antwerp = yes (in case such a thing would exist :-) ).
> it's much easier to come up with cuisine=Antwerp, especially when there is
> an input field "cuisine".

New people can have problems or make mistakes and then experienced
users can help and point to recommended tagging or explain good
practices .
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?

In this thread we are also most interested in multiple values. Not
only cuisine=unique_cuisine. Even for a cuisine as unique as Antwerp
cuisine. :-)
And new people don't know how to add multiple values (well, they know
nothing, don't they?).
In the spirit of free tagging in OSM their first input of multiple
values might be:
"cuisine=antwerp and belgium"
"cuisine=Antwerp chips"
"cuisine=antwerp+fish"
"cuisine=Antwerp_waffles"
and with the automatic completion of iD for new keys (under 'all tags'
in the second part of the panel) finally:
"cuisine=antwerp"  +  "cuisine_1=mussels"

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

Re: [Tagging] Electronic or 'e' cigarettes?

[Martin Koppenhoefer]

> Am 22.01.2015 um 15:02 schrieb Dave F. :
> 
> To me, electronic_cigarettes is clearer & should be used,


+1

cheers 
Martin 

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

Re: [Tagging] Tagging road illumination quality

[Martin Koppenhoefer]

> Am 18.01.2015 um 17:21 schrieb Volker Schmidt :
> 
> Streetlamp mapping does not help.
> All our city cycleways are within the lighting radius of street lamps, but
> they are often interspersed with street-linign trees.
> lamps may be on the opposite side of the street than the cyclepath
> street lamps have illumination bodies pointing at strange angles
> some street lamps are not strong enough
> cycle ways are separated from streets by guard rails that throw a dark shadow 
> excactly on the cycle way (in more than one place)  This is admittedly the 
> most bizarre of the problems


most if not all these problems can be solved with detailed data about the 
street lamps and the interfering shading objects, but we're a very long way 
from there, so +0,9 to more detailed values in "lit"

cheers,
Martin___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electronic or 'e' cigarettes?

[moltonel 3x Combo]

On 22/01/2015, althio  wrote:
> Existing pages: value "e-cigarette" is referenced in the wiki.
>
> http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette
> http://wiki.openstreetmap.org/wiki/Key:shop#Others

Using "-" instead of "_" goes against a very established tagging practice.

The wiki page is very recent with only two contributors. I wouldn't be
surprised if "e-cigarette" in the db was also contributed by no more
than 1-2 mappers. I suggest contacting them to make sure that they are
ok with "e_cigarette", and then make the change to wiki and db.

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

Re: [Tagging] Deprecation of associatedStreet-relations

[Vincent Pottier]

Le 22/01/2015 14:00, althio a écrit :

Hi all - does anyone know what the geographic distribution of
associatedStreet is like? taginfo doesn't render a map (it seems it
doesn't do that for relations).

UK  ~9000
PL  ~1700
CZ  ~ 100
HU  ~ 130
SE  >  900
RU  1850
FR is down
No stats for DE

This shows a map, I don't know if this is what you are looking for:
http://taginfo.openstreetmap.org/tags/type=associatedStreet#map

http://taginfo.openstreetmap.org/tags/type=associatedStreet#combinations
also shows that
61 307 / 218 176 = 28.10% are also tagged with ref:FR:FANTOIR=*
so from France.

28 % at least !

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

Re: [Tagging] Tagging road illumination quality

[Kytömaa Lauri]

Volker Schmidt wrote: 
>I am very cautious about any of this kind of measurement for the following 
>reasons:
>1) the results will be very difficult to standardise
>2) the effort is far beyond that what a mapper can reasonably do.

Oh well, I guess I'll have to write a comment here, because I recently finished 
my master's thesis on a related subject in street lighting research. While I 
wrote this message in parts on several days, there might be some repetition in 
it, but I hope the ideas are comprehensible.

As a background, the eye requires a constrast between the target and the 
background before the target can be seen; the contrast can be in the colour, or 
in the luminance, or both. The eye also adapts to the prevailing luminance 
level; there's no exact model to predict the "adaptation luminance" given any 
scene, but the models of human vision take the adaptation level as a starting 
point - most scientific experiments have used a constant luminance background 
and a sufficiently long adaptation period (5+ or 20+ minutes) to fixate the 
adaptation luminance.

The road planners have several lighting classes, which apply to different types 
of roads and pedestrian environments. The classes are not globally identical, 
but the basic ideas behind those classifications should be roughly similar. 
Generally the lighting classes set minimum requirements for the average 
illuminance or luminance on the ground, and a requirement for the evenness of 
the measured value, and possibly limits for measured glare. Sometimes there is 
a requirement that in the area next to the road the luminance should be a 
percentage of the value measured on the road. Some countries require that 
pedestrian environments fulfill some luminance condition on vertical surfaces, 
too, and some lighting classes might require or favour sufficient colour 
reproduction. These are the measurable quantities, and they are quite well 
predicted already in the planning phaze.

When the lights get older and dirtier, less light reaches the road surface, so 
the new installations typically exceed the requirements. Lighting installations 
might be up to 40 years old, but some have been replaced earlier. The expected 
lifetime is often 15 to 20 years in the planner's operating cost calculations.

In practice (assuming conditions found on normal roads, i.e. normal 
cost-optimized installations) the amount of light and the lack of glare are the 
most effective predictors for the average assessed quality of lighting. On ways 
used for vehicular traffic, glare seldom is an issue (but for example some 
early LED lights had a glare problem).

There have been numerous studies, and they have compared the users' assessments 
to other attributes. When the test subjects are pedestrians, things like 
perceived openness of the area, emphasising the natural elements in the area 
with the lighting, perceived (lack of) options for escape and the ability to 
recognize other people's faces/intentions correlate with "better" lighting - 
and lighting can improve users' perceptions of those "nonlighting" attributes. 
Nobody has proposed a concrete model which could predict the "perceived 
quality" with all the recognized parameters. Such a model would require, for 
example, knowledge of the local living conditions and people's expectations of 
personal safety: there's a huge difference in what primes people into fear, 
between crime ridden environments and countries where street crime is very low.

Measuring the road luminances is standard practice. They used to have to 
position the measurement device at regular intervals for measurements, but 
nowadays they use calibrated digital cameras with special software and do the 
measurements for a stretch of road surface from one picture. The "officially 
acceptable" devices cost more than your average DSLR camera, but from what I've 
read, the results could be sufficiently accurate for this kind of tagging. 

The problem is then that the road has to be empty, the tail and headlights of 
other vehicles would distort the values, and that to get comparable results the 
street has to be dry and the height needs to be constant; the road surface 
isn't a totally diffuse reflector (and wet surface even less so) so the values 
depend somewhat on the angle between the viewing direction and the road 
surface. The measurement "grid" has to be manually positioned over the picture, 
to get a standard sample between and of the whole area between two light poles.

If, on the other hand, one were to measure "upward, i.e. the mobile device 
measured the amount of light reaching it's light sensor and not the luminance 
of the surfaces visible in the camera, there are other hindrances. The sensor 
basically integrates over the half sphere space angle (or a smaller aperture), 
and the user holding the mobile phone blocks a significant portion of that; the 
old method for road lighting measurements had the persons doing the job walk 
away fro

Re: [Tagging] Electronic or 'e' cigarettes?

[althio]

Existing pages: value "e-cigarette" is referenced in the wiki.

http://wiki.openstreetmap.org/wiki/Tag:shop%3De-cigarette
http://wiki.openstreetmap.org/wiki/Key:shop#Others


On 22 January 2015 at 15:43, Dave F.  wrote:
> Ah, As normal cigarettes are sold in multiples I didn't think of searching
> for the singular, but I guess people only buy one of these electronic types.
>
> Dave F.
>
>
> On 22/01/2015 14:16, Matthijs Melissen wrote:
>>
>> On 22 January 2015 at 14:02, Dave F.  wrote:
>>>
>>> A shop that solely sells electronic cigarettes has been added locally. I
>>> guess this type
>>> of product will be on the increase so I think it's best to clarify
>>> unified tag, if there's ever
>>> been such a thing in OSM :-)
>>
>> Yes, I also think this is one of the more common shops that has no
>> clear defined tag.
>>
>>> Checking Tag-info it's 8/6 in favour of electronic_cigarettes over
>>> e-cigarettes.
>>
>> Currently, the most common tag is shop=e-cigarette:
>>
>> e-cigarette x170
>> e_cigarette x10
>> electronic_cigarettes x8
>> electronic_cigarette x4
>> e-cigarettes x6
>>
>>> To me, electronic_cigarettes is clearer & should be used, but I thought
>>> it best to discuss first. I don't smoke, are all these power based?
>>
>> I understand your argument in favour of shop=electronic_cigarettes. If
>> you think it's worth it, feel free to start a proposal to change the
>> name.
>>
>> -- Matthijs
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> http://www.avast.com
>
>
> ___
> 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] Wiki Edit War on using/avoiding semicolon lists

[Martin Vonwald]

2015-01-22 15:48 GMT+01:00 Dmitry Kiselev :

> Anyway none of programmers couldn't be freed out of burden to support both
> of them.
> But, at least we could try to establish one delimiter.
>

Thanks for those clear and true words.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Dmitry Kiselev]

 As I think,

replace
    key=val1;val2
with
     key: val1 =*
     key: val2 =*

Is just a transposition of problem.

Yes, it's easier now to test for any particular value, 
but harder to get all the values inside category.

For  key=val1;val2 you need some kind of regex 
or smarter application which allows you to find particular value inside 
collection.

But it's harder to get all tags in category.
How would you get all the payment methods, not the exact 'ellectrico'?

/payment:(.*?).*/ 
reg. expressions, again? 


As for  for me as a programmer, both of these approaches are the same.
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

is easier than

route_ref:1=yes
route_ref:2=yes
route_ref:3=yes
route_ref:4=yes
route_ref:5=yes
route_ref:123=yes
route_ref:124=yes
route_ref:125=yes
route_ref:126=yes
route_ref:234=yes
route_ref:235=yes
route_ref:236=yes
route_ref:456=yes
route_ref:457=yes
route_ref:458a=yes

Anyway none of programmers couldn't be freed out of burden to support both of 
them.
But, at least we could try to establish one delimiter.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electronic or 'e' cigarettes?

[Dave F.]

Ah, As normal cigarettes are sold in multiples I didn't think of 
searching for the singular, but I guess people only buy one of these 
electronic types.


Dave F.

On 22/01/2015 14:16, Matthijs Melissen wrote:

On 22 January 2015 at 14:02, Dave F.  wrote:

A shop that solely sells electronic cigarettes has been added locally. I guess 
this type
of product will be on the increase so I think it's best to clarify unified tag, 
if there's ever
been such a thing in OSM :-)

Yes, I also think this is one of the more common shops that has no
clear defined tag.


Checking Tag-info it's 8/6 in favour of electronic_cigarettes over e-cigarettes.

Currently, the most common tag is shop=e-cigarette:

e-cigarette x170
e_cigarette x10
electronic_cigarettes x8
electronic_cigarette x4
e-cigarettes x6


To me, electronic_cigarettes is clearer & should be used, but I thought it best 
to discuss first. I don't smoke, are all these power based?

I understand your argument in favour of shop=electronic_cigarettes. If
you think it's worth it, feel free to start a proposal to change the
name.

-- Matthijs

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



---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


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

Re: [Tagging] Electronic or 'e' cigarettes?

[Matthijs Melissen]

On 22 January 2015 at 14:02, Dave F.  wrote:
> A shop that solely sells electronic cigarettes has been added locally. I 
> guess this type
> of product will be on the increase so I think it's best to clarify unified 
> tag, if there's ever
> been such a thing in OSM :-)

Yes, I also think this is one of the more common shops that has no
clear defined tag.

> Checking Tag-info it's 8/6 in favour of electronic_cigarettes over 
> e-cigarettes.

Currently, the most common tag is shop=e-cigarette:

e-cigarette x170
e_cigarette x10
electronic_cigarettes x8
electronic_cigarette x4
e-cigarettes x6

> To me, electronic_cigarettes is clearer & should be used, but I thought it 
> best to discuss first. I don't smoke, are all these power based?

I understand your argument in favour of shop=electronic_cigarettes. If
you think it's worth it, feel free to start a proposal to change the
name.

-- Matthijs

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

[Tagging] Electronic or 'e' cigarettes?

[Dave F.]

Hi

A shop that solely sells electronic cigarettes has been added locally. I 
guess this type of product will be on the increase so I think it's best 
to clarify unified tag, if there's ever been such a thing in OSM :-) 
Checking Tag-info it's 8/6 in favour of electronic_cigarettes over 
e-cigarettes.


To me, electronic_cigarettes is clearer & should be used, but I thought 
it best to discuss first. I don't smoke, are all these power based?


Dave F.

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


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

Re: [Tagging] Feature Proposal - RFC - addrN:*

[Dmitry Kiselev]

 Hi Friedrich.

I can't say for whole World,
as for Russia we have plots of lands having addresses without buildings.

They are not always dedicated to be build up with something.
There is three ways, (maybe more, but i don't know for sure):

1. Large landuses as landuse=industrial may have their own address, like.

Springfield, Green Road, 123.
and every building inside this territory have their own address like:
Springfield, Green Road, 123, building 2.

(Keep in mind that we traditionally have different addresses parts order).

2,3. Rather small land lots with demolished  or not yet constructed buildings.
We can say that they are dedicated to be built up with something in future,
but they may appears empty for ages.

It's rather common situation for rural areas, when owner have purchased land 
lot,
but haven't built capital house yet. 
But these lots should have addresses for mail correspondence  and fees.


Wed, 21 Jan 2015 21:02:14 -0600 от "John F. Eldredge" :
>On 01/19/2015 03:39 AM, Friedrich Volkmann wrote:
>> On 18.01.2015 22:23, Markus Lindholm wrote:
>>> I think that comes down to how addresses are viewed, either as a
>>> proper feature in their one right or as an attribute to some other
>>> feature.
>>
>> Yes, that's the crux.
>>
>>> I think addresses are proper features, so a distinct address
>>> should be found only once in the database.
>>
>> And I see it the other way. Addresses are just attributes. It may pendend on
>> the country, I don't know. In Austria and most certainly in entire central
>> Europe, an address is always bound to a building, apartment or strictly
>> delimited plot of land. An address cannot exist on its own. Every address
>> includes a housenumber, indicating that there's a house. There are no
>> addresses in the midst of a lake or somewhere in the cliffs.
>>
>
>If you have a "strictly delimited plot of land", with no house currently 
>built upon it, but which is intended for later construction, does it 
>have a house number?  Or is the address only assigned once a building is 
>built?
>
>-- 
>John F. Eldredge --  j...@jfeldredge.com
>"Darkness cannot drive out darkness; only light can do that.
>Hate cannot drive out hate; only love can do that."
>Dr. Martin Luther King, Jr.
>
>___
>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 - RFC - addrN:*

[Friedrich Volkmann]

On 21.01.2015 08:28, Markus Lindholm wrote:
> Before we get carried away by a zillion relations I think we have to
> answer the questions as to what purpose do we want to explicitly
> associate an address with a POI or a building.
> 
> Is it so that the data consumer can find her way to a POI? That's
> obviously superfluous as the POI already has a geographical location
> given.

But not the address, according to your suggestion to keep addresses in
separate nodes.

Concerning buildings, an address node is imprecise. It may be on one side of
the building, while you'd better come from the other side of the building.
Search Nominatim for my postal address Davidgasse 76-80 and click the
"House" in the search results. You couldn't achieve that with a single
address node. In fact, the address node would be at the southern end of the
building complex, while I live at the northern end, so you wouldn't find
your way to my appartement.

> The only purpose I can think of is to facilitate for the data
> consumer to send a physical letter to the POI and that is a bit of a
> fringe use case. With buildings is even murkier as to what the purpose
> would be. Is there any country where the address would be part of the
> ID for the building in the cadastre? Seems unlikely as a building can
> have many addresses.

I think that we don't need to care about the cadastre. It's something
independent from OSM.

I think we should generally not ponder about application purposes too much.
The purpose of tagging is to represent data in a clean and unambigous way.
Leave it over to applications to do something with it or not. If someone
wants to make a carnival report on whether buildings with even or odd
housenumbers are larger, why not?

> So I'm not advocating that a zillion relation be created, just that if
> you REALLY need an EXPLICIT association between an address and a
> POI/building then you should use a relation. And that addresses would
> be stored in the database in a coherent manner.

That mixes the needs of mappers and data consumers. As a mapper, I don't
need such an association at all.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

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

[Jo]

Rattling on about those bus stops, I have an other example:

https://www.openstreetmap.org/node/485938967

bus  yes  highway
 bus_stop

name  Porte de
Hal - Hallepoort  name:fr
 Porte de Hal
name:nl 
Hallepoort  network

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

platform

ref:De_Lijn 301026  ref:TECB Bsgipha1  ref:TECC Cbxhal1  route_ref
 27
route_ref:De_Lijn 136;137  route_ref:TECB W;123  route_ref:TECC 365a
zone:De_Lijn 20  zone:TEC 6220
A bus stop served by 3 operators, of which one, there are 2 entitities each
assigning their own identifier.
For operator and network there are ; in those lists and I don't see what's
the problem with those. For ref I don't want to find multivalue. For the
rare occasions where this  occurs (2 stops with different refs from the
same operator), the nodes are duplicated, then grouped together in a
stop_area.

And before anybody says: we don't want those foreign keys in OSM, well the
scripts I'm developing to assist contributors for adding route relations,
heavily depend on them.

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

Re: [Tagging] Deprecation of associatedStreet-relations

[althio]

> Hi all - does anyone know what the geographic distribution of
> associatedStreet is like? taginfo doesn't render a map (it seems it
> doesn't do that for relations).

This shows a map, I don't know if this is what you are looking for:
http://taginfo.openstreetmap.org/tags/type=associatedStreet#map

http://taginfo.openstreetmap.org/tags/type=associatedStreet#combinations
also shows that
61 307 / 218 176 = 28.10% are also tagged with ref:FR:FANTOIR=*
so from France.

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

Re: [Tagging] Feature Proposal - RFC - addrN:*

[Friedrich Volkmann]

On 22.01.2015 04:02, John F. Eldredge wrote:
> If you have a "strictly delimited plot of land", with no house currently
> built upon it, but which is intended for later construction, does it have a
> house number?  Or is the address only assigned once a building is built?

When it is already intended for later construction, it usually already has
an address (including house number or conscription number) assigned. But
again, I can only speak of Austria.

So we have three levels of estimated vs. fully surveyed address mapping:
1) address nodes: we know that the address is valid somewhere around that point
2) address as building attribute: we know at least one building where the
the address is valid
3) address as plot attribute: we know the entire area where the address is valid

Of course, the building may occupy the whole plot, especially in cities.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Deprecation of associatedStreet-relations

[Dan S]

2015-01-22 6:53 GMT+00:00 Marc Gemis :
> It seems like the German community started some voting process on the
> deprecation of the associatedStreet-relation (it was on the mailing list and
> on the forum).
>
> Discussion is going on on the wiki
> https://wiki.openstreetmap.org/wiki/DE:Relation:associatedStreet

Hi all - does anyone know what the geographic distribution of
associatedStreet is like? taginfo doesn't render a map (it seems it
doesn't do that for relations). I hear rumours it's mainly Germany but
it'd be handy to know.

Best
Dan

___
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 Thu, Jan 22, 2015 at 12:59 PM, althio althio 
wrote:

> > I even find the second example more difficult to visualize. It's just
> worse
> > than the first in every respect.
>
> From a mapper's point of view
> My little +1 for key:subkey=*
>

New people don't know how to add new keys. So they will have problems to
add cuisine:antwerp = yes (in case such a thing would exist :-) ).
it's much easier to come up with cuisine=Antwerp, especially when there is
an input field "cuisine".

regards

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

Re: [Tagging] Deprecation of associatedStreet-relations

[althio althio]

> It is not as formal as a proposal voting. I would like to know how the 
> community (those who vote) think about associatedStreet relations. I think 
> that in Germany the majority does not like them (anymore).
> I will announce a end date. This end date will be date of announcement of end 
> of voting + 14 days.
> German forum and talk-de have been notified by myself. You may notify your 
> local community if it will not read the next issue(s) of weeklyOSM.

Alright Michael, thanks for the details.
Now that the international tagging list is notified thanks to this
thread, I guess it does not really matter.
But the starting process looked biased towards the German community.

Mit freundlichen Grüssen

althio

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

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

[althio althio]

> I even find the second example more difficult to visualize. It's just
worse
> than the first in every respect.

>From a mapper's point of view
My little +1 for key:subkey=*

In free text like this thread, several key:subkey=* may look more heavy and
complicated than key=values;separated;by;semicolon.
_However_ I think this is reversed in the context of editors (iD, JOSM...)
and elements lookup [1] where key and values are presented in tables.
+ key:subkey=* tabulated is easier to read
+ key:subkey=* tags are separated, it is slightly easier to select them and
update, to delete one only, to add by copy/paste.
+ key=values;separated;by;semicolon means less typing/keystrokes but this
is much mitigated by use of presets, auto-completion or copy/paste.


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

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

[Jo]

It's an actual example:

https://www.openstreetmap.org/node/80725474
https://delijn.be/nl/haltes/halte/303059 (real time information)

121 characters... there's still some breathing room. I guess the risk of
the street getting congested is higher than hitting the 255 characters
limit.

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

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

[althio althio]

Hi Jo/Polyglot and list,

On 22 January 2015 at 12:01, Jo  wrote:
> Which too schemes? I think you'd need to be more specific.

1. key=values;separated;by;semicolon
2. several key:subkey=*

> route_ref:De_Lijn=1;2;3;4;5;6;7;8;9;284;285;310;315;316;317;333;334;335;337;351;352;358;370;371;372;373;374;380;395;520;524;525;537;586;597

I don't know if this is a real or fictitious example, but try not to
hit the limit of 255 characters for values. ;)

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

Re: [Tagging] Deprecation of associatedStreet-relations

[Michael Reichert]

Hi,


Am 22. Januar 2015 11:45:47 MEZ, schrieb althio althio :
> > Please vote here:
> > https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet
> 
> Is this a formal voting?

It is not as formal as a proposal voting. I would like to know how the 
community (those who vote) think about associatedStreet relations. I think that 
in Germany the majority does not like them (anymore).

> Is there a date for start and end vote?

No, there is no end date at the moment. Start date was yesterday. I will 
announce a end date. This end date will be date of announcement of end of 
voting + 14 days.

> It looks strange, hidden on a Talk:page without the usual template or
> RFC or call for votes on the international mailing lists.

German forum and talk-de have been notified by myself. You may notify your 
local community if it will not read the next issue(s) of weeklyOSM.

Best regards

Michael
-- 
Diese Nachricht wurde auf einem Smartphone verfasst, ist daher nicht 
GPG-signiert und enthält Tippfejler.
This message was been written on a smartphone. That's why it is not GPG-signed 
and may contain tyops.

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

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

[Jo]

Which too schemes? I think you'd need to be more specific.

As for deprecating semicolon-delimited lists. I don't think it's practical
to abolish them completely, so they'll have to stay.

I do agree that it makes sense to try and avoid them as much as possible,
but it's simply not always possible.

As for the remark that route_ref shouldn't exist, and that information
should be in route relations. Well there are bus lines which may never have
route relations. (on demand buses which don't have a fixed route, school
buses, market day buses, Sunday and Friday evening special service fares to
get students home, etc.). But it's still information which is not hard to
map when surveying, and which is good to have when no route relation has
been set up yet, or to validate the correctness of the route relation.

About the remark that it's hard to figure out whether an item is missing
from the list. I'm sorry, but it's not because 7;8;10;11 are there that 9
necessarily is missing from the list.


I deleted everything which was hidden under the three dots.

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

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

[althio althio]

First point:
It is good that several people invent, propose and use various schemes.

Second point:
At some point, unification of schemes with similar intent would be great.
As usage grows, having the same kind of data treated differently is a pain
for everyone, mappers, developers, maintainers and data consumers alike.
I don't think one of the schemes is clearly superior to the other, only I
wish that it could be open to discussion, open to improvements and settled.
Once it is agreed upon (or enforced by any committee, anyone?), people can
start to work on unified tagging, clear documentation, adapted presets and
simpler algorithms with less cases or exceptions to handle.

Or it is decided that we continue with the two schemes, that both are
valid, accepted, documented for tagging and consumption.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[althio althio]

> Please vote here:
> https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet

Is this a formal voting?
Is there a date for start and end vote?

It looks strange, hidden on a Talk:page without the usual template or
RFC or call for votes on the international mailing lists.

althio

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

Re: [Tagging] Deprecation of associatedStreet-relations

[Michael Reichert]

Hi,

Am 2015-01-22 um 07:53 schrieb Marc Gemis:
> It seems like the German community started some voting process on the
> deprecation of the associatedStreet-relation (it was on the mailing list
> and on the forum).

Right: I iniated the discussion.

> Discussion is going on on the wiki
> https://wiki.openstreetmap.org/wiki/DE:Relation:associatedStreet

Please vote here:
https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet

Best regards

Michael



-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging