Re: [Tagging] Handle with care

[Kotya Karapetyan]

Hi André, all,

Shall we discuss an "object_warning" tag? To begin with, it will simply
contain information. Editors can also choose to show it when the tagged
object is about to be changed.

Kind regards,
Kotya





On Fri, Sep 18, 2015 at 12:53 AM, André Pirard <a.pirard.pa...@gmail.com>
wrote:

> On 2015-09-17 18:02, Kotya Karapetyan wrote :
>
> Hi André,
>
> I don't know why your text was removed.
>
> > It would produce a message saying something like:
> > "The coordinates you are trying to change are accurate to 25 cm.
> > You probably shouldn't change this tag, certainly not with GPS data.
> > Are you certain that you will not destroy valuable data and do you want
> to continue?".
> > And if he replies "no", his attempt is canceled.
>
> I like this approach. I wonder if it is technically feasible.
>
> Forget about my bad examples and the eagerness to pick them.
> Here is the original text.
>
> ... Despite a "don't touch" note explaining why not, a good soul passes,
> not reading note and makes a "correction".
> What is needed here is an "are you sure?" tag named such as
> [keyname:]warning="text" that the map editing softwate  uses any time a
> mapper wants to change that keyname's value  to display the message and ask
> for a confirmation (by the tag, at the time he tries to change it, not when
> he tries to upload a dozen of such changes).
> ="Reasons why you shouldn't change that tag.  Do you really want to
> change it?"
> Replying "no" cancels the attempt.
> Or should it be [keyname:]note:warn="text" and spare another wiki page?
> keyname can be "geometry" as in source:geometry.
> Et voilà.  An all-purpose simple guardrail, a small update to the wiki and
> passing the word to the editors.
>
>
> My point was that to make it generic may be more difficult than creating a
> very specific tag/function for survey-based data.
>
> IMHO it may be simpler that some specific implementations and certainly
> when their numbers reaches 2.
> The answer will be given by JOSM et al.
> It doesn't address "mechanical" updates, but the persons doing them are
> supposed to know what they're doing, aren't they?
>
> And I didn't understand the benefit for your other examples. But otherwise
> I support it.
>
> Those examples forgotten, other voices are needed, the wiki update has
> almost been written.
>
>
> Cheers,
> Kotya
>
> General tip: Kotya, do you know that you can have your
> kotya.li...@gmail.com account use filters to store messages in
> by-the-list folders and access those folders using IMAP with software like
> Thunderbird and do things like answering to ancient mail?
>
> Cheers
>
> André.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Handle with care (was: Accuracy of survey)

[Kotya Karapetyan]

Hi André,

I don't know why your text was removed.

> It would produce a message saying something like:
> "The coordinates you are trying to change are accurate to 25 cm.
> You probably shouldn't change this tag, certainly not with GPS data.
> Are you certain that you will not destroy valuable data and do you want
to continue?".
> And if he replies "no", his attempt is canceled.

I like this approach. I wonder if it is technically feasible.

My point was that to make it generic may be more difficult than creating a
very specific tag/function for survey-based data.
And I didn't understand the benefit for your other examples. But otherwise
I support it.

Cheers,
Kotya




On Fri, Sep 11, 2015 at 7:16 PM, André Pirard <a.pirard.pa...@gmail.com>
wrote:

> On 2015-09-09 23:39, moltonel wrote :
>
> On 9 September 2015 21:46:54 GMT+01:00, "André Pirard" 
> <a.pirard.pa...@gmail.com> <a.pirard.pa...@gmail.com> wrote:
>
> There are various reasons for warning other mappers to be careful about
> their updates.
> I once temporarily overlaid two walking routes to show the effect of
> displaying two sorts of icons.
> Or I left in for a while drawing errors of a plugin as the best way to
> show the author what I talk about.
> Despite a don't touch note explaining why, a good soul passes, not
> reading note and makes a "correction".
>
> Please run experiments like this on a test db, not on the main one. It's easy 
> to point your editor to dev.openstreetmap.org for example (quoting from 
> memory, not 100% sure). You never know when a data consumer will stumble upon 
> your experiment, live or in a downloaded snapshot. Nobody expects osm data to 
> be perfect all the time, but there's no point in knowingly making it worse.
>
> You are off topic, as well as the following messages.
> While I admit that my examples are suboptimal, the matter is extending
> very simply to other tags the idea of preventing to replace precisely
> triangulated coordinates by loose GPS ones.
> Let us, for a better example, say that someone tagged a strange looking
> name and that he knows for sure that the spelling is correct.  After the
> third time the name was changed to a apparently better but wrong spelling,
> he will want to enforce reading the note that nobody reads. That's all
> there is to the suggestion you removed from this message.
>
> Now responding to your accusations.
> What big sin is that to discover errors and leave them a few more days on
> the map for the developer of the tool that produced them to have a look at
> them?  Is there a prescribed time limit?
> Like you, I have always advocated a sandbox, especially for helping
> novices. I've never heard of one and it's the first time I do. But JOSM
> says "The server responds with the return code 404 instead of 200. " when
> trying to validate http://dev.openstreetmap.org/ as well as
> http://api06.dev.openstreetmap.org/
> Thanks, but please give correct information.
> But a sandbox wouldn't help with the first bad example because it's to be
> looked at on Waymarked trails and that program does not display sandbox
> data.  And as we're told that those URL if they worked wouldn't have a
> renderer, they wouldn't be very convenient to use.
> Please make practical suggestions !!!
>
> On 2015-09-10 18:41, Kotya Karapetyan wrote :
>
> But otherwise I think there is a difference between a general warning or
> message from one mapper to another (which in its own is an interesting idea
> but can lead to dialogues and discussions) and a specific technical feature
> that would prevent moving an accurately positioned tag.
>
> Imagine there is a real-world marker at 50.000° N:
> http://www.dieweltenbummler.de/geografisches/geografische-besonderheiten/50-breitengrad/
> Someone draws it in OSM at 50° N. Then I come there with a smartphone,
> measure the location, find it at 49.9° and edit the OSM accordingly. It is
> wrong by definition (providing that the real-world marker location is known
> precisely), but there is no mechanism to prevent such editing.
>
> I think it's a very specific and relevant gap, and would love seeing it
> solved elegantly.
>
> That is what my suggestion does and I wonder why the heck it has been
> removed from this message !!!
> It would produce a message saying something like:  "The coordinates you
> are trying to change are accurate to 25 cm.  You probably shouldn't change
> this tag, certainly not with GPS data.  Are you certain that you will not
> destroy valuable data and do you want to continue?".
> And if he replies "no", his attempt is canceled.
> This kind of message would be possible for any tag and I don't understand
> why you want it

Re: [Tagging] Handle with care (was: Accuracy of survey)

[Kotya Karapetyan]

Hi André,

I agree with moltonel.

But otherwise I think there is a difference between a general warning or
message from one mapper to another (which in its own is an interesting idea
but can lead to dialogues and discussions) and a specific technical feature
that would prevent moving an accurately positioned tag.

Imagine there is a real-world marker at 50.000° N:
http://www.dieweltenbummler.de/geografisches/geografische-besonderheiten/50-breitengrad/
Someone draws it in OSM at 50° N. Then I come there with a smartphone,
measure the location, find it at 49.9° and edit the OSM accordingly. It is
wrong by definition (providing that the real-world marker location is known
precisely), but there is no mechanism to prevent such editing.

I think it's a very specific and relevant gap, and would love seeing it
solved elegantly.

Kind regards,
Kotya


On Wed, Sep 9, 2015 at 11:39 PM, moltonel  wrote:

>
>
> On 9 September 2015 21:46:54 GMT+01:00, "André Pirard" <
> a.pirard.pa...@gmail.com> wrote:
> >There are various reasons for warning other mappers to be careful about
> >their updates.
> >I once temporarily overlaid two walking routes to show the effect of
> >displaying two sorts of icons.
> >Or I left in for a while drawing errors of a plugin as the best way to
> >show the author what I talk about.
> >Despite a don't touch note explaining why, a good soul passes, not
> >reading note and makes a "correction".
>
> Please run experiments like this on a test db, not on the main one. It's
> easy to point your editor to dev.openstreetmap.org for example (quoting
> from memory, not 100% sure). You never know when a data consumer will
> stumble upon your experiment, live or in a downloaded snapshot. Nobody
> expects osm data to be perfect all the time, but there's no point in
> knowingly making it worse.
> --
> Vincent Dp
>
> ___
> 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 - reception_point

[Kotya Karapetyan]

Hi,

I wonder: Could we try to slightly change the proposal/RFC process to make
the community develop the good solution?
It is obvious that only a small amount of people voted against the proposal
as such, thinking it's not useful.
The majority complained about the specific wording.
We could put several voting sections in one wiki-page, something like this:

  Reception point/desk/facility proposal

  Reception provides a place where people arrive to be greeted...

  Proposed tagging:

  amenity = reception_point
  yes
  yes
  no
  no
  ...

  amenity = reception_desk
  yes
  no
  yes
  no
  ...

People would be able to add their own versions, and vote. The winning
suggestion becomes the final wording.
It would also have the advantage of keeping comments next to the votes
rather than in this mailing list. The mailing list is clearly good for
discussion, but not so much for the final stage, when the proposer needs
the community feedback. At that moment suddenly those who haven't heard
arguments are asked for their opinion.

Cheers,
Kotya



On Wed, Jun 24, 2015 at 1:20 AM, Warin 61sundow...@gmail.com wrote:

 Hi,

 Following the unsuccessfull proposal of 'reception_desk' this new proposal
 following the suggestion of some of the voters.


 https://wiki.openstreetmap.org/wiki/Proposed_features/reception_point

 A Reception provides a place where people (visitors, patients, or
 clients) arrive to be greeted, admitted to an organisation (e.g. camp
 site, hotel, school, business).
 The use of the word 'point' is to reduce the possibility that
 this tag is misused for 'wedding reception', and that it identifies the
 place where the greeting/reception takes place rather than a large area
 usually set aside for waiting.




 ___
 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 - Reception Desk.

[Kotya Karapetyan]

It's really a pity if the proposal will be rejected. Its need is clear,
even though the exact wording may not be perfect. But do we need to have a
*perfect* proposal before we can get anything? I would suggest to those who
oppose it to accept it and then propose a modification. Otherwise we'll
stay where we are forever. No proposal can be perfect.

That said, I do agree that a *reception_facility* option is not a bad idea
at all. If the majority of those opposing this proposal do so because of
the word desk, I would suggest replacing it and voting once again. I
agree with Warin's argument that area (another proposed wording) is not a
good option, also because of the mapping ambiguity (what to include—the
thing with the word reception above it or the whole area from which this
word can be seen?)

Cheers,
Kotya

On Sun, Jun 21, 2015 at 2:52 AM, Warin 61sundow...@gmail.com wrote:

 Hi,

 I will close this proposal on Tuesday 23 June unless more votes come in. A
 the moment it is rejected by 11 approved votes to 5 opposed votes (68%). To
 be approved would require 4 more approval votes without any more opposed
 votes.

 If you have not voted .. vote.


 https://wiki.openstreetmap.org/wiki/Proposed_Features/amenity%3Dreception_desk

 If rejected I will probably pursue other related reception_desk proposals.
 Your help and patience is appreciated.

 Possible forth coming proposals? amenity=reception, amenity=reception_area
 (I would vote against both these), amenity=reception_point (I think this
 came from Bryce?).

 I may run these concurrent so votes can take place at the same time. What
 ever one gets the most number of approvals I'd make a page for, no matter
 the 'rules' for 'approved' or 'rejected'.



 ___
 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 - Reception Desk.

[Kotya Karapetyan]

On Sun, Jun 21, 2015 at 5:33 PM, Chris Hill o...@raggedred.net wrote:

 Voting is a pointless, broken process that means absolutely nothing.


I think voting is a good indicator of the community opinion. As such, it is
useful. I agree of course that we are not bound by the outcome, but it does
introduce some uniformity IMO.

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

Re: [Tagging] RFC Reception_desk Mk2

[Kotya Karapetyan]

On Thu, May 21, 2015 at 12:34 AM, pmailkeey . pmailk...@googlemail.com
wrote:

 If they need a map to find the place, the need any reception for newbies.
 Tag the appropriate entrances with ent/ext tags - all those entrances
 suitable for newbies.



I believe we should simply map the reality. So a reception should be called
a reception, and an entrance (independent from its appropriateness)—an
entrance.
If a company decides to move the reception from one entrance to another,
does it mean we should erase the previous entrance?
My university has the reception at the back entrance, the main entrance
being used for official delegations only (that don't need reception) and
for students and staff who have badges. And they are 10 minutes walk from
each other, so it's important to know.


 Hospitals tend to have multiple entrances - so tag them appropriately such
 as A+E(ED) , main, outpatient or even named department. Schools have many
 entrances too but the general public don't need to know about them all.


OSM is a database database of things on the planet, not an information
centre for general public. There are restricted roads, and they are still
mapped. So should by the entrances that are not for public access.


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

Re: [Tagging] RFC Reception_desk Mk2

[Kotya Karapetyan]

 One node, all tags is the gut feeling I get. Put all the tags on one and
 if two are the same key with different values, add the values separated by
 semicolons.

 If in doubt, create two nodes and use iD to combine them ;) by (shift)
 selecting both and use the + symbol to combine.


+1, but probably will be left up to the mapper, as usual.



 Re reception desk - sounds useful but in the meantime I'm making use of
 the entrance/exit tag to indicate main entrance - where a reception desk
 would be found.


For simple situations it works. Sometimes however the reception desk may
appear elsewhere (not at the main entrance) as well, and there may be more
entrances too.
Example: my company campus has 3 main receptions (I am aware of), one main
entrance (for the visitors who don't know where to go; however they can go
to other receptions too), and dozens of entrances without receptions.

A hospital nearby has at least 2 entrances, one being the main one, with a
reception at each entrance.

That's why this proposal is so valuable.

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

Re: [Tagging] Sector, section, and cemetery

[Kotya Karapetyan]

 You could evaluate the tagging already in use in different cemeteries
 around the world and see which tags are used for similar objects, then
 proposing some system to unify the situation.
 Well mapped cemeteries you can find in Poland, Pere Lachaise in Paris,
 Staglieno in Genoa, and so on.


Good point, thanks! For reference, here are the links:
Poland:
http://www.openstreetmap.org/edit?way=25439265#map=18/50.07478/19.95037 —
cemetery=sector, name=xx
France:
http://www.openstreetmap.org/edit?way=13859706#map=18/48.86089/2.39262 —
name=Division xx
Italy:
http://www.openstreetmap.org/edit?way=10045286#map=19/44.43158/8.94833 —
cemetery=sector, name=Campo xx, ref=xx

Looks like
1) people really prefer to use name instead of or together with ref—and
I can well understand them, since ref is not displayed.
2) cemetery=sector is used in some places but not everywhere. While
landuse=cemetery is used 200k times, cemetery=sector is only used 2.5k
times.

Could someone explain to me how one can detect mass retagging please?

As for proposing something new, I'll first get in touch with the author of
the current proposal and see what he's up to. Will post here once I've
heard from him.

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

Re: [Tagging] Sector, section, and cemetery

[Kotya Karapetyan]

On Fri, May 15, 2015 at 6:32 PM, pmailkeey . pmailk...@googlemail.com
wrote:

 How about mapping a cemetery with connected smaller cemeteries ? That's
 what I've done to distinguish different areas and names.


Though you are of course free to do it anyway you find reasonable, I don't
think it's a good solution: If there is only one cemetery, it should be
mapped as one. It's about semantics:
— How many cemeteries do you have in your city
— 5.
— How many sectors (sections)?
— 154.

In your case you'll get as many cemeteries as sectors. I don't think it's
what you mean. Also, for a cemetery that has a name, it would mean you have
several cemeteries with the same name. Again, suboptimal.

I prefer to map it the way it is: a single cemetery with multiple composing
areas


Cheers,
Kotya




 --
 Mike.
 @millomweb https://sites.google.com/site/millomweb/index/introduction -
 For all your info on Millom and South Copeland
 via *the area's premier website - *

 *currently unavailable due to ongoing harassment of me, my family,
 property  pets*

 TCs https://sites.google.com/site/pmailkeey/e-mail

 ___
 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] Tagging FOR the renderer

[Kotya Karapetyan]

On Sat, May 16, 2015 at 7:42 PM, Richard Welty rwe...@averillpark.net
wrote:

  On 5/16/15 1:19 PM, Kotya Karapetyan wrote:

 Though I strongly disagree to the idea of mapping for the renderer, I
 agree that there is a huge problem: a lot of data available in OSM database
 is effectively lost because the renderers do not show it.

 on the other hand, demanding that the rendering on www.openstreetmap.org
 be all things to all people is actually pretty unreasonable. the current
 architecture which separates data from style is well considered and in line
 with modern best practices; i haven't yet seen an argument that would
 persuade me otherwise.


The idea of mixing style and data was not implied! They are separate and
should remain such. I was only complaining about inability to see the data,
in whichever usably form. Currently there are two ways I can see some data:
switch on editing (bad, because I can screw data up) or use the query tool
(bad, because I cannot see the presence of a feature, I need to click the
map to find it).

Also I didn't mean that www.osm.org should be the place to show all data.
It can well be a separate site.

what we could use are more people doing projects like opencyclemap and
 openfiremap and the like to bring out the data they care about in formats
 that they like.


Good idea. Though, for the sake of usability, it would be great to have a
single site capable of showing everything. The problem is of course that
OSM doesn't restrict tagging in any way, meaning that it's barely possible
to create layers for different tags.



 my presentation at SOTM US will include examples of using leaflet, jquery
 and overpass to create mashups of OHM and OSM data, and i'll be making
 my javascript available on the ohm github repository under a 3 clause BSD
 license for anyone who wants to play.


I will be very much interested in having a look.

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

Re: [Tagging] Tagging FOR the renderer

[Kotya Karapetyan]

Though I strongly disagree to the idea of mapping for the renderer, I
agree that there is a huge problem: a lot of data available in OSM database
is effectively lost because the renderers do not show it. Right now there
is a question whether we should use ref or name to tag parts of the
cemeteries. Logically, it's clearly a ref. But refs are not rendered, so
no use to the map users, so why would I tag so? Just for the sake of making
database clean?

Through 20 years of effort, we've successfully trained everyone to use
passwords that are hard for humans to remember, but easy for computers to
guess. (https://xkcd.com/936/)

I would like to ask you: is there a web-site and a smartphone app where I
could see all OSM data and switch things on and off?
That would probably be the answer to the question.

@Dave Swarthout: Have you by chance described your effort anywhere?


Cheers,
Kotya


On Sat, May 16, 2015 at 12:03 AM, pmailkeey . pmailk...@googlemail.com
wrote:

 I don't know whether this has been discussed or even mooted before...

 Tagging for the renderer is natural. Mappers, especially newbies will be
 disappointed their pet new feature they've just added to the db does not
 appear on the map. This situation is no use to anyone but has been allowed
 to continue and 'enforced' with wiki et al going against the notion of
 tagging for the renderer. The problem was likely there in the beginning and
 is still there now - several years later - unresolved. In fact, the way OSM
 is put together, it's completely unresolvable - as people are free to tag
 how they like and the map shows only what the renderers choose to show. I
 have considered that what we see in the editors is the real map and true
 OSM isn't. If the editors had a 'read-only' mode, they'd be far more use
 than OSM proper and mappers would be happier to see their work on the 'map'.

 I therefore want to air the view that 'mapping for the renderer' is no
 longer 'wrong' by actually adding a good set of basic tags for areas, lines
 and points (simple English as opposed to technical English of 'nodes' and
 'ways') so that when a mapper invents something new, they can add tags for
 colour, opacity, line colour, line width, line opacity - for areas and
 similar attributes for lines and points (colour, opacity, size etc.) and
 obviously tags for name and description etc. What do people think to this ?

 --
 Mike.
 @millomweb https://sites.google.com/site/millomweb/index/introduction -
 For all your info on Millom and South Copeland
 via *the area's premier website - *

 *currently unavailable due to ongoing harassment of me, my family,
 property  pets*

 TCs https://sites.google.com/site/pmailkeey/e-mail

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


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

[Tagging] Sector, section, and cemetery

[Kotya Karapetyan]

Hi everybody,

I was mapping cemeteries recently, and I stumbled over a couple of
confusing points. I would like to know your opinion.

1) There is landuse=cemetery and amenity-grave_yard. Could someone explain
the difference please? Is it that graveyard is always at a place of worship
territory? I find it quite confusing: most big cemeteries in Moscow have
started as such graveyards, but are now much more known than those old
churches or monasteries (which may even be non-functional by now). Also, at
every cemetery, there is a place of worship. But its only purpose is often
to hold a burial service at that cemetery.

2) For large cemeteries, mapping of sections/sectors is essential for the
map to be of any use. There is a proposal for this
https://wiki.openstreetmap.org/wiki/Proposed_features/Cemetery_sector, but
it seems to be abandoned. I would restart it, but I have a doubt: do we
want a specific cemetery-related tag only? I would rather introduce
something like a section that could be used elsewhere too (e.g. for a
large parking, beach, etc.) The fact that it's a cemetery section can be
derived from geometry.

3) A good alternative could be a subtag:
cemetery:section=xxx,
where I would make xxx the name of the section (aka ref and name).

4) Ref seems to be a good tagging for the cemetery section number, but it
doesn't show up on the map, unlike the name (e.g.
https://www.openstreetmap.org/way/345082198). Is ref still a preferred tag?

5) Is it more correct to use section or sector for cemeteries? The
proposal is for sector but I think it should actually be section.

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

Re: [Tagging] Sector, section, and cemetery

[Kotya Karapetyan]

  4) Ref seems to be a good tagging for the cemetery section number,
  but it doesn't show up on the map, unlike the name (e.g.
  https://www.openstreetmap.org/way/345082198). Is ref still a
  preferred tag?

 it does not render as sole argument is not a good argument. Mappers
 should not care too much during mapping whatever tags are rendered (in
 extreme it leads to
 http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer ).


Awesome! :) I didn't know of this article.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Administration building tag

[Kotya Karapetyan]

Great, office=administrative will do. Thanks!

Cheers,
Kotya

On Fri, May 15, 2015 at 5:17 PM, Martin Koppenhoefer dieterdre...@gmail.com
 wrote:





  Am 15.05.2015 um 16:49 schrieb Kotya Karapetyan kotya.li...@gmail.com:
 
  Is there a tag for an administration building of a large campus/site?
 Specifically, I would like to tag the administration location of a cemetery.


 maybe office fits for you?

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

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

[Tagging] Administration building tag

[Kotya Karapetyan]

Hi again,

Is there a tag for an administration building of a large campus/site?
Specifically, I would like to tag the administration location of a
cemetery. There is an abandoned proposal (
https://wiki.openstreetmap.org/wiki/Proposed_features/Administration) but
its examples imply something very different.

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

Re: [Tagging] Highway barrier

[Kotya Karapetyan]

I wonder if we want to limit it to spikes only. What about these things:

http://www.siapress.ru/images/news/main/24438.jpg

http://park-ur.ru.images.1c-bitrix-cdn.ru/upload/medialibrary/bee/beebb476f5dc4c2cccedd1ab6f41.jpg?142435251415224

My proposal would be to add oneway to the existing barrier.


On Tue, 14 Apr 2015 08:08 Janko Mihelić jan...@gmail.com wrote:

Well, the street is likely already tagged with oneway=yes, so we know the
direction of spikes. I'll throw out a suggestion: barrier=one_way_spikes.


Janko

uto, 14. tra 2015. 07:47 Dave Swarthout daveswarth...@gmail.com je
napisao:

Take a look at this nasty device that prevents traveling the wrong way on a
oneway street. I've seen several of these here in Istanbul. Some have signs
to alert motorists but this one does not. It is unmarked in any way.

https://commons.wikimedia.org/wiki/File:One-way_barrier_IMG_7111.JPG

It is surely a barrier of some sort yet it does allow traffic to flow
unimpeded in one direction. Traffic_calming doesn't quite get it either.
LOL

How should I tag this?

Regards,

Dave

-- 

Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Reception Desk

[Kotya Karapetyan]

I agree with fly that it would be good to actually change the proposal page
to make it closer resemble the tag description page. Currently it mainly
addresses the RFC process and questions. As the result, there is no good
page for which we could vote. All discussion could be moved to the Talk
subpage.

Cheers,
Kotya

On Sun, Apr 5, 2015 at 10:55 PM, fly lowfligh...@googlemail.com wrote:

 Nice that you follow the new, unwritten rules.

 Sorry, but I usually only vote by using the tag and not on the wiki,
 still I would say, give it more time and improve the documentation as we
 will need it anyway (both the tag and its docu).

 Cheers fly


 Am 01.04.2015 um 03:02 schrieb Warin:
  Hi,
 
  I have taken this back to the Draft status/stage.
 
  There is not much of a change to the basic proposal
 amenity=reception_desk.
 
  There is a much more verbose explanation of things .. like what key to
 use.
 
  Summary of voting ..
 
  Thank you all for voting. 38 votes is I hope a good representation.
 
  21 for
 
  17 against.
 
  Of those against;
  10 state it should not be an amenity key and most of those are for it
  being in the tourism key.
  My failing there for not explaining that it has applications to offices,
  industries and educational areas where tourism is not an appropriate key.
 
  1 says it needs more time.
 
 
  1 says it is not necessarily a desk.
  I have never come across one that was not a desk - telephone, public
  address system and sign in in all housed on a desk.
 
  2 (with another supportive comment from someone else) says it should
  embedded in 'the indoor tagging scheme'.
  The 'indoor tagging scheme'? That is going to have the same kind of
  problems with the tags for toilets, telephones, shops swimming pools,
  etc etc. The problem posed by this tag exists for many others and will
  need to be addressed by the indoor tagging system NOT by this tag
  alone.  The 'indoor tagging system' looks to be in evolution ... and
  will probably take some time before being generally accepted.
 
  How is reception desk shown to be part of another feature? By its
  location in most instances. It has also been suggest that a site
  relation could be used. The site relation looks to be in some state of
  'proposed'... I could not hazard a guess as to when it will progress
  onwards.
  (proposed) relation
  https://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature
 
  Also note the other proposal
 
  https://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster
 
  I don't see how the problem can be addressed by the simple value of the
  proposed reception_desk .. particularly as it is a problem/solution for
  other things too?
 
 
 
  ___
  Tagging mailing list
  Tagging@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/tagging


 ___
 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 - Discussion - Reception Desk

[Kotya Karapetyan]

 Warin,


 Maybe there needs to be a wiki page on the subject?
 Associating one feature (a 'parent') with another feature (a 'child')?
 More of a guide as to how OSM 'does' it?

 Or may be it needs to be added to some already existing guide...


I would propose to word it as belongs-to. However, once again, I would
separate it from the reception desk tag proposal. In most cases, we would
like to be able to tag the reception location(s) on a large campus: That's
where this tag is most valuable. If there are multiple organizations in a
limited space, there will often be just one reception. Otherwise finding *any
*reception already helps a visitor a lot. Therefore I would first go on and
finalize the reception tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Reception Desk

[Kotya Karapetyan]

Hi Warin,



 10 state it should not be an amenity key and most of those are for it
 being in the tourism key.
 My failing there for not explaining that it has applications to offices,
 industries and educational areas where tourism is not an appropriate key.


In my opinion, it depends on personal experience. For me the value of this
tag for company, hospital, university and other non-touristic facilities is
clear. For someone the word reception may only associate with hotels.

 1 says it is not necessarily a desk.

 I have never come across one that was not a desk - telephone, public
 address system and sign in in all housed on a desk.


It's true that it's not always a desk and usually is much more than a desk.
However it's still called a desk :)
I am not a native speaker, but I think it's a standard term for a reception
facility.



 2 (with another supportive comment from someone else) says it should
 embedded in 'the indoor tagging scheme'.
 The 'indoor tagging scheme'? That is going to have the same kind of
 problems with the tags for toilets, telephones, shops swimming pools, etc
 etc. The problem posed by this tag exists for many others and will need to
 be addressed by the indoor tagging system NOT by this tag alone.  The
 'indoor tagging system' looks to be in evolution ... and will probably take
 some time before being generally accepted.


I think there are some keen proponents of indoor tagging. There is
definitely an advantage of being able to specify where the desk is located
exactly. Moreover, it's kind of natural, since that's the implicit reason
for your proposal: to specify where one can find the reception.

How is reception desk shown to be part of another feature? By its location
 in most instances. It has also been suggest that a site relation could be
 used. The site relation looks to be in some state of 'proposed'... I could
 not hazard a guess as to when it will progress onwards.
 (proposed) relation
 http://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature

 Also note the other proposal

 http://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster

 I don't see how the problem can be addressed by the simple value of the
 proposed reception_desk .. particularly as it is a problem/solution for
 other things too?


This is the only critically important aspect IMO. For a building hosting
multiple organizations, there should be a way to attribute the reception
properly. In many cases it logically follows from the location. Not in all
probably. My suggestion would be to introduce the tag as is, and add a
relation when possible. The tag definitely adds value in many cases even
without the relation.


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

Re: [Tagging] Loomio evaluation

[Kotya Karapetyan]

Hi Andre,

I am not sure what point you are trying to make.

 You should say what you mean when you speak of e-mail (not being the
best tool).
 If you mean that a plain mail server or list server is insufficient, one
can agree.
 But if you say that the user shouldn't use e-mail, that is wrong.

1) I didn't say that people shouldn't *use* email. I only think that a
mailing list is not the best tool for decision preparation discussions.
Why? Because there is absolutely no structure implied or enforced. If you
have a meeting without an agenda, without *any* rules, without a chairman,
without time limits, with participants joining in the middle of a
discussion and leaving before it's over—what's the probability of having a
successful meeting and getting some decisions prepared?

 You seem to consider including an image as an achievement.

2) I don't consider embedding an image an achievement. Loomio has a pretty
primitive interface, e.g. no buttons (like at StackExchange) to do
formatting. Therefore there was a valid question asked whether it's
possible to embed images. Note that it was not about being WYSIWG or able
to to do rich text. For discussions, we really need to be able to share
photos and screenshots.
I have checked and posted that it was possible, both in the topic and in
individual comments. I just answered the question.

 There is more than that to support: links, lists, tables, titles etc...

3) I am not sure you really need it, but Loomio supports further formatting
that you mention.


However I think that your position is more interesting for this discussion
than just arguing about the functionality and usability of email and
whatever-other-tool. You have a rather strong opinion and I think, whatever
the functionality, you will present a strong opposition to switching.
Therefore I would be interested in knowing *if* it is possible to make you
*want* to switch. Not just to Loomio but to any other tool. Is there such a
thing at all? Is there something you don't like about emails as the
decision preparation tool?

Cheers,
Kotya




On Thu, Mar 26, 2015 at 11:11 AM, André Pirard a.pirard.pa...@gmail.com
wrote:

  Hi,

 So, the conclusion of my Loomio test is that it does not let the user
 choose which Google account it uses during account creation, it uses the
 connected account and, despite the user cancels the Login operation, Loomio
 continues to try to use the unwanted account. I tried disconnecting the
 account and removing the cookies in vain.
 I was asked to open a Loomio ticket and, although I'm not here to debug
 Loomio, I'm helpful and I did.
 But no one popped up, ad so, Loomio must be seen as unsupported software.
 I could not make actual tests.

 On 2015-03-23 19:07, Kotya Karapetyan wrote :

 Now I am missing the like link :)

  We'll definitely need to find a smart and soft way to attract people to
 a different platform.
 However, though I agree that email is not the best tool, we need a very
 good alternative rather than a marginally better option first.

  You should say what you mean when you speak of e-mail (not being the
 best tool).
 If you mean that a plain mail server or list server is insufficient, one
 can agree.
 But if you say that the user shouldn't use e-mail, that is wrong.
 Users complain about the difficulties of composing wiki text or similar
 because it's not wysiwyg and because a Web interface is not adequate.
 E-mail programs are good, basic HTML editors and the best idea is to use
 that same HTML for both forum articles and wiki pages. The said articles
 are easily converted to wiki pages, something that should be more often in
 certain countries.

 Personally, I archive the messages I receive in an MAP server that I can
 access with my e-mail program.
 If you add list management functions to that, the more the better, you
 make an excellent Loomio.
 The list servers we use have 2 big shortcomings: 1) limiting message size,
 2) considering messages as text with HTML attachment.
 They should use a readonly IMAP server.

 Loomio test page https://www.loomio.org/d/1E3YAaz0/test-images
 To answer the Ralph’s question in the mailing list, this thread is an
 attempt to embed an image:

 You seem to consider including an image as an achievement.
 There is more than that to support: links, lists, tables, titles etc...

 I have copied and pasted to this message the page of the test test you
 made on Loomio.
 Below that, I made a fancier image with the text wrapping to the left,
 just for show.
 Belox that, I copied from the main map the tags of Elisabeth Tower, the
 one supporting Big Ben.
 It contains titles, links, a table and a list.

   André.

OSM tagging https://www.loomio.org/g/tknueHrw/osm-tagging
   Test images

 To answer the Ralph’s question in the mailing list, this thread is an
 attempt to embed an image:

Started 1 hour ago by Kotya Karapetyan
 https://www.loomio.org/u/2r5uoFXS/kotya-karapetyan
 Edited https://www.loomio.org/d/1E3YAaz0

Re: [Tagging] Accepted or rejected?

[Kotya Karapetyan]

 Please also have in mind the amount of traffic between plain text and html.


I actually wonder how relevant this is. In general, I am a proponent of
saving resources, so the less transmitted data the better. But with the
increase of internet bandwidth and the speed of available hardware, the
situation is not frozen. E.g. a good UI of a tool can reduce the time you
actually need to spend looking at the screen, reducing the amount of energy
your device consumes. Thus it may be beneficial to transmit larger chunks
of data but show information in a well-formed way. Unless someone is still
connected with a 56k modem and actually needs to wait to download data, I
don't think the size is an issue. We are not tagging videos :)

We did not talk about security issues and scripts, yet.


Where do you see a potential problem in Loomio (or another similar tool) as
compared to plain email?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Accepted or rejected?

[Kotya Karapetyan]

On Mon, Mar 23, 2015 at 9:55 AM, Paul Johnson ba...@ursamundi.org wrote:


 On Wed, Mar 18, 2015 at 4:50 PM, Warin 61sundow...@gmail.com wrote:

 I agree that a 'forum' is far better at engaging a community ... keeps
 topics more organised as replies are localised (that are no isolated
 branches for instance), avoids the 'digest mode' problem, some even have a
 system of not viewing post by someone they don't like!


 It's 2015 and people still struggle with how threading and filters work?
 Just because someone couldn't pass a middle school basic computer skills
 course is no fault of the technology.


Paul has just emphasized an important advantage of using mailing list as
compared to forums or other moderated platforms:
Anywhere else he would have just run the risk of being banned. An open
mailing list is the most democratic discussion platform.

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

Re: [Tagging] Loomio evaluation

[Kotya Karapetyan]

 Question:... Can you include pictures or diagrams as visual arguments to
 support your reasoning?


 Doesn't seems to be possible.



I was too quick. It *is* possible. Here is an example.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Loomio evaluation

[Kotya Karapetyan]

Now I am missing the like link :)

We'll definitely need to find a smart and soft way to attract people to a
different platform. However, though I agree that email is not the best
tool, we need a very good alternative rather than a marginally better
option first.

On Mon, Mar 23, 2015 at 9:40 AM, Dan S danstowell+...@gmail.com wrote:

 OSM is a very large community with much accumulated knowledge and
 skill - it's bound to be quite conservative, and for good reason. The
 challenge is to allow experimental innovations to breathe without
 disrupting the community. We'll never be able to organise a vote (ha!)
 to switch to loomio all at once. But if we decide Loomio is worth
 trying, maybe we can experimentally agree to use it to negotiate some
 small tagging subproject, in a particular tag namespace. (indoor
 tagging might be a good example?) Then inch by inch we see what works.

 Dan


 2015-03-23 0:18 GMT+00:00 Dave Swarthout daveswarth...@gmail.com:
  I'll second the notion that we need something better than the current
  system. It is an anachronism!
 
  My first look at Loomio was good, I was impressed, but my immediate
 thought
  was, it'll never get accepted into OSM
 
  On Mon, Mar 23, 2015 at 5:57 AM, Dan S danstowell+...@gmail.com wrote:
 
  It's interesting. I hadn't realised it's open-source too, so osm could
  run its own version of it if we wanted to.
 
  Dan
 
  2015-03-20 22:38 GMT+00:00 Kotya Karapetyan kotya.li...@gmail.com:
   Dear all,
  
   In an attempt to find a better tool for our proposal discussions,
 Loomio
   has
   been mentioned. At the very first glance it looks like a feasible
   alternative to the mailing list and the forum.
  
   Let's take a look together:
   https://www.loomio.org/g/tknueHrw/osm-tagging
  
   And let me know if you want to check the coordinator role.
  
   Cheers,
   Kotya
  
   ___
   Tagging mailing list
   Tagging@openstreetmap.org
   https://lists.openstreetmap.org/listinfo/tagging
  
 
  ___
  Tagging mailing list
  Tagging@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/tagging
 
 
 
 
  --
  Dave Swarthout
  Homer, Alaska
  Chiang Mai, Thailand
  Travel Blog at http://dswarthout.blogspot.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

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

Re: [Tagging] Loomio evaluation

[Kotya Karapetyan]

On Mon, Mar 23, 2015 at 5:42 PM, AYTOUN RALPH ralph.ayt...@ntlworld.com
wrote:

 Well, I guess I am also out of this. Needs me to log in to make a comment
 but appears I have done something wrong because it just does not work for
 me. I do not have a Google account and my Virgin email is unacceptable.

 So I cannot comment.


That's a shame. What do you mean by unacceptable? It complains about it?



 Question:... Can you include pictures or diagrams as visual arguments to
 support your reasoning?


Doesn't seems to be possible.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Loomio evaluation

[Kotya Karapetyan]

 I was *too* quick. Here is an example:
 https://www.loomio.org/d/1E3YAaz0/test-images

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

Re: [Tagging] List v Forum - was Accepted or rejected?

[Kotya Karapetyan]

On Fri, Mar 20, 2015 at 12:57 PM, Dan S danstowell+...@gmail.com wrote:

 2015-03-20 11:50 GMT+00:00 althio althio.fo...@gmail.com:
  Maybe it was Loomio?

 That was it! Thanks




Shall we take a look at it all together?

https://www.loomio.org/g/tknueHrw/osm-tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Loomio evaluation

[Kotya Karapetyan]

Dear all,

In an attempt to find a better tool for our proposal discussions, Loomio
has been mentioned. At the very first glance it looks like a feasible
alternative to the mailing list and the forum.

Let's take a look together: https://www.loomio.org/g/tknueHrw/osm-tagging

And let me know if you want to check the coordinator role.

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

Re: [Tagging] List v Forum - was Accepted or rejected?

[Kotya Karapetyan]

On Thu, Mar 19, 2015 at 11:28 PM, Dan S danstowell+...@gmail.com wrote:

 I use Stack Exchange a lot and it's great, very well designed for its
 purpose. BUT Stack Exchange is not designed for community decision
 making. There are tools/forums that are actually designed for that
 purpose.

 Also I don't think Stack Exchange themselves would want to host an OSM
 tagging area, it's not what they're about. Maybe someone has in mind a
 stack-exchange-like system rather than Stack Exchange itself. In fact
 https://help.openstreetmap.org/ uses http://www.osqa.net/ which is
 a Stack Exchange clone. But I repeat, it's not designed for
 consensus/decision-making, it's designed for QA, which has
 superficial similarities (voting etc) but it's not the same thing.


Dan, all true.
1) Can you point in the direction of the tools you mean (designed for that
purpose)? Do you know a good one?
2) I know that SE as not designed for lengthy discussions. (It provides the
meta and chat though.) I was thinking more in the direction of proposing a
tag like a question. Then people can edit/comment/vote. It's a very
different approach, but I am not sure we need the current one with so much
text and noise.
3) My main point was actually not to say that SE is the best solution, but
to emphasize to the forum proponents that forums are far from ideal too.

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

Re: [Tagging] List v Forum - was Accepted or rejected?

[Kotya Karapetyan]

 I'm starting to think a Forum is a good idea.  But Stack Exchange is a
 bigger decision, I have not used it, who has ?


I have :) Also participated in the proposal phase for a couple of sites.

I am wondering: If so many people think that forum is better, and if OSM
actually provides a forum (http://forum.openstreetmap.org/), how comes that
we have this discussion? Why hasn't it died out long ago and why don't we
discuss tags in the forum? Isn't it an indicator that something important
is better in the mailing list? Is it maybe a pure quantity thing (the
majority actually prefers the list)? Then this discussion is of little use:
people will go on using the mailing list, whatever a dozen people here
agrees on.

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

Re: [Tagging] Revisiting proposal/voting scheme

[Kotya Karapetyan]

On Thu, Mar 19, 2015 at 10:41 AM, Martin Koppenhoefer 
dieterdre...@gmail.com wrote:


 2015-03-19 0:56 GMT+01:00 David Bannon dban...@internode.on.net:

 * Once on the wiki, instead of a formal vote period, users (eg) click a
 like or dislike button and aggregate score is shown. For some time
 (?). Obviously they can also edit content to say why.



 I believe the current requirement to add a reason for a dislike is
 important and should not be dropped by substituting it with a simple click
 mechanism.


Think StackExchange.

Example:
---
Tag bla-bla.
*Pro's *
- Adds additional information wrt tag bla. [20 likes, 5 dislikes]
- Makes tagging more explicit. [30 likes, 2 dislikes]
*Contra's *
- Clashes with existing tag bla-bla-bla. [25 likes, 15 dislikes]
 Comment: -1 because the existing tag is historic and we may to
deprecate it. [10 likes]
*Current usage*
1234 nodes
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Revisiting proposal/voting scheme

[Kotya Karapetyan]

  Think StackExchange.
 
 Nice. But practicable ?


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

Re: [Tagging] Accepted or rejected?

[Kotya Karapetyan]

Dear all,

We have enough support to change the current math and no dramatic
opposition.
I will do it in the wiki now. If you feel I haven't taken something
critically important into account and this change is for the worse, not
better, please roll back.

The discussions on the more global change of the proposal/voting process
and on how to carry out discussions goes on :)

Cheers,
Kotya

On Wed, Mar 18, 2015 at 4:23 PM, Tobias Knerr o...@tobias-knerr.de wrote:

 On 17.03.2015 15:04, Kotya Karapetyan wrote:
  I propose to clarify it by changing the recommended number of votes
  in
 https://wiki.openstreetmap.org/wiki/Proposed_features#Approved_or_rejected
  from .../8 unanimous approval votes/ /or //15 total votes with a
  majority approval.../
  to /...8 or more //unanimous approval votes or 10 or more total votes
  with more than 74 % approval...//./
  This will not change anything in terms of the ongoing discussion of
  /how/ the approval influences other things. So the discussion can
  continue. But we'd introduce some mathematical logic in the process.

 +1

 I think it's not ideal that this would make it easier to accept
 proposals with very few voters (e.g. a 8:2 majority), so I would prefer
 a higher quorum (e.g. 15). But in my opinion it's still acceptable, and
 better than no change.


 ___
 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] Revisiting proposal/voting scheme

[Kotya Karapetyan]

OK, I see the difference between our approaches. I still don't see the
problem though:

 If you convert that to a Key:Smoothness page, the wiki becomes
 completely disconnected from the db.

Sorry, I don't understand it. Do you mean the OSM database? How is it
connected now and why will a change of a word in the wiki page break any
connections?



On Thu, Mar 19, 2015 at 10:10 AM, moltonel 3x Combo molto...@gmail.com
wrote:

 On 18/03/2015, Kotya Karapetyan kotya.li...@gmail.com wrote:
  On Wed, Mar 18, 2015 at 11:00 PM, moltonel 3x Combo molto...@gmail.com
   wrote:
  Why should the page be converted to a feature page ?
 
  Because I would mark a proposal page as such in some place. Otherwise a
  stable 10 year-old feature page cannot be easily distinguished from a
  proposal created yesterday. I see something like moving the page to a
  different namespace or removing a proposal status. Not changing the
  content or rewriting the page.

 Ok, I understand better where you're coming from. But this doesn't
 gain anything compared to the current workflow. You still have a flag
 day when the proposal is deemed done/accepted. You're losing the
 information that it's a design doc under consideration (in my view,
 tagging schemes remain under consideration until they get widely
 used in the db, regardless of their approved/rejected status).

 Let's take an example. Somebody writes a proposal about the smoothness
 key that finally solves all the problems and has unanimous acceptance.
 If you convert that to a Key:Smoothness page, the wiki becomes
 completely disconnected from the db. If instead you keep the proposal
 page as-is, but add links on the key pages with conforms to /
 contradicts proposal foo links for each value, you get the best of
 both worlds.



  Feature pages and proposals should be writen in parallel, not one
  after the other.
 
  I am promoting writing a single feature proposal page, which, after the
  initial discussion, is made just a feature page. So nothing is written
  one after another.

 It may be just editing/moving an existing page rather than creating a
 new one, but you still have one after the other. At no point do you
 have both the feature page and the proposal available at the same
 time.

 Remember that, in my initial suggestion, the feature page and the
 proposal serve two different purposes : to document existing practices
 and to document desired practice. I think it's important to clearly
 distinguish the two in the wiki. The wiki is here to guide, not to
 direct.

 ___
 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] Accepted or rejected?

[Kotya Karapetyan]

I didn't mean to break the rules :) I thought I did count 8 +1's, plus the
discussion shifted to other topics, so no strong opposition was expressed.
If Pieren and you really see more harm than improvement in what I've done,
please feel free to roll back.

I have a general impression that democracy should sometimes be a little
helped by a strong opinion, when it minimizes damage. If you foresee a
damage—feel free to undo.

On Thu, Mar 19, 2015 at 11:50 AM, Martin Koppenhoefer 
dieterdre...@gmail.com wrote:


 2015-03-19 11:37 GMT+01:00 Kotya Karapetyan kotya.li...@gmail.com:

 Dear all,

 We have enough support to change the current math and no dramatic
 opposition.
 I will do it in the wiki now.



 FWIW, I didn't even count 8 positive votes that you said would be required
 when cast unanimously, but at least one clear opposition (Pieren) plus my
 comment that you couldn't change the rules this way.

 ___
 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] Accepted or rejected?

[Kotya Karapetyan]

Martin,

Though Bryce introduced the abstain option with a nice pictogram :) I
don't remember seeing it used in any proposals. Therefore currently there
is no mathematical difference. Therefore I suggest that you just change the
rule from 74 % approval to not more than 25 % objection. Since we are
in the process of discussing abandoning the approval process all together,
we can revisit the numbers. But since you seem to have a strong opinion and
sound reasoning, I'd just implement the change you suggest now and wait for
someone to tell you why it's a bad idea.

Cheers,
Kotya

On Thu, Mar 19, 2015 at 11:41 AM, Martin Koppenhoefer 
dieterdre...@gmail.com wrote:


 2015-03-18 21:05 GMT+01:00 Kotya Karapetyan kotya.li...@gmail.com:

 Do we have abstention possible at all? The voting system currently only
 implements yes and no:
 https://wiki.openstreetmap.org/wiki/Template:Vote.
 If we had abstention, I would have rather counted it as non-supporting. A
 proposal where people don't care or object is not a good one IMO.

 However, I wouldn't mind changing it, since, as it is, there would be no
 difference. To not re-vote this change, let's accept it first, and then we
 can improve it further.





 Yes, we do have abstentions, basically everything that is neither a yes
 nor a no is an abstention. I'd prefer to not count them as opposing, as
 they usually make comments like I don't care for voting or it doesn't
 matter to me, why should those count against a proposal (like it is now)?
 You chose your words cleverly, because I agree, they are also
 non-supporting, but still, you can't see them as objecting neither.

 Cheers,
 Martin

 ___
 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] Accepted or rejected?

[Kotya Karapetyan]

On Thu, Mar 19, 2015 at 4:36 PM, Jan van Bekkum jan.vanbek...@gmail.com
wrote:

 Correct, but the forums are easier to scan through and search,


Jan, I wonder if you've ever had a question, googled for an answer and
landed in a forum thread with 50+ pages with 10 posts per page.
Personally, I dislike forums even more than mailing lists. But evil are
both. It's very easy to create noise, and pretty difficult to find and
create the actual content.

That's why StackExchange is such a success and why it's also pretty
unique—it was not easy to find a really working solution. Even at SE some
questions get half a dozen very technical answers and it's not easy to
check and understand each of them. However a few important ideas were
implemented:
1) Good and consistent text formatting.
2) Voting for questions, answers and comments.
3) Reputation indication.
4) Editing of questions and answers.
5) Search that actually works
6) Tagging and suggestion of similar topics
7) Moderation.
8) Discrete ads.
9) Excellent user interface, making it easy to ask, easy to answer and
challenging to mess things up.

All of these are missing in mailing lists and most are missing in forums.

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

Re: [Tagging] Accepted or rejected?

[Kotya Karapetyan]

On Thu, Mar 19, 2015 at 6:34 PM, Tod Fitch t...@fitchdesign.com wrote:

 My issue with email lists is that for most emails I delete after reading.
 If at some time later, I come across a tagging situation that I recall
 being previously discussed I need to go into the mail archives at
 https://lists.openstreetmap.org/listinfo find the list (probably tagging
 but maybe others) and then find which month of which year it was discussed.

 Most forums I have seen and used have a much better search setup than that.


Enter Google :) You type site:
https://lists.openstreetmap.org/pipermail/tagging; and then your request
and you probably get what you want.



 Also, if I need or want to resurrect the thread, that it typically trivial
 on a forum as you just post a reply. But if I’ve pulled up the old thread
 out of the list archive I will have broken the message ID information in
 the email headers that make threading options on a mail reader work well.


That's true. Therefore forums *are *better than mailing lists. But they are
still not good enough to make a discussion easy to follow, if it tends to
split up or causes a lot of opinions.

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

Re: [Tagging] Accepted or rejected?

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 11:51 AM, Pieren pier...@gmail.com wrote:

 -1
 The main criticism about votes is the approved status and the
 small amount of participants, not percentage of approvals. So change
 the status name and increase the quorum, not the opposite. It's also
 not a problem to keep the vote open for a long time.


The voting time is a separate discussion all together. In principle, we
could replace the approved/rejected status with supported/not-supported.
When a mapper is looking for a tag, he will see not only the amount of
uses, but also the level of support (and also for the negative votes—the
reasoning). This will make him able to decide whether or not he wants to
use that tag.

We can therefore do three things now:
- Leave everything as is and continue the discussion.
- Correct the math by voting for my proposal and then continue the
discussion
- Develop a new formula first.

The current situation is that there are open proposals, so in my opinion it
would help to at least resolve the unclarity we agreed on.

So just to repeat: I agree with the whole argument about the drawbacks of
the current discussion and voting system. But until we have a better one
let's at least make the current one not self-contradictory. The discussion
may take forever and not actually result in anything. Let's make the first
change for the better now, and then try to make it great.

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

Re: [Tagging] Language - was Accepted or rejected?

[Kotya Karapetyan]

Having lived in Russia and Germany for quite a while, I can confirm that
the language barrier definitely plays a strong role. A lot of people in
Russia will never use the English-language internet at all. I think the
same holds for France, Spain and Italy, to a lesser extent for Germany. In
the Netherlands where I live now the average level of English is very good;
however a lot of people (even working in international companies) still
barely speak English and will definitely find it hard to participate in
non-Dutch discussions.

Regarding the culture, I don't think it makes participation difficult due
to understanding. However, each culture will have mapping-relevant
differences. In that respect, it would be difficult for people from other
cultures to follow.

A good example would be a Russian-OSM discussion of how to tag street names
in terms of the word order. It would be irrelevant in English or German,
but in Russian you can say Улица Пушкина and Пушкина улица. Both are
perfectly understandable for a Russian speaker, the difference is also
clear and relevant for sorting and search. However both are translated the
same into English or German.

Besides that, some things probably only exist in some countries. Say,
discussing volcano tagging in German may be less relevant than doing the
same in Icelandic.

Note that now we are approaching the OSM internationalization consequences
rather than just the question of mailing list discussions.

Cheers,
Kotya


On Wed, Mar 18, 2015 at 7:54 AM, Marc Gemis marc.ge...@gmail.com wrote:


 On Wed, Mar 18, 2015 at 7:44 AM, David Bannon dban...@internode.on.net
 wrote:

 Marc, do you find the English speakers here anything less than
 supporting ?  What about use of expressions or references to popular
 culture, does that make it harder do you think ?


 No, I have no problems with the English speaking community myself, but I'm
 lucky to be rather fluent in English. And I learn new words as I follow the
 mailing lists :-).
 On the other hand, I also follow lists in German and French, but I am very
 reluctant to participate in those discussions, as my language skills are
 not good enough for that.
 So I imagine that this is the case for other people and English.

 | And thats a pretty good point. But to fork off each discussion onto a
 | new language list would fracture the discussion. We'd need a person

 totally agree with that. But right now, you also see that proposals are
 made in local communities that never make it to the general mailing list.
 The Lübeck bicycle tagging scheme comes to mind.
 and look at the wiki pages in German. I took a lot of historic or animal
 related tagging from there, because there is no English page for those
 topics.

 Unfortunately I have no solution for this, I can only regret that
 participation to the tagging mailing list is for some limited by language
 knowledge.

 regards

 m

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


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

[Tagging] Revisiting proposal/voting scheme

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 3:06 PM, Martin Vonwald imagic@gmail.com
 wrote:

 Very good ideas and it would bring the original intention of OSM back into
 the play: the numbers count and not the two-and-a-half people putting a
 line starting with yes somewhere in the wiki.


I think some opposition to a proper voting mechanism is concentrating too
much on the numbers. Indeed, we can have just 1 person proposing a tag, 20
people voting about it, and thousands actually using (or miusing) it.
However:

1) As mentioned elsewhere, the discussion process accompanying the voting
is valuable for the tagging improvement. There would be less interest in
the discussion *and improvement* if we remove the competition and the
question will my proposal get approved by the community?

2) When a potential user sees the positive and negative votes (which,
ideally, summarize the discussion), he may decide for himself whether or
not to use a tag. If there is no voting, there is no such digest of the
in-depth consideration by those who took care to get involved.


I see however a problem in the fact that the proposal page, with its voting
section, is not present in the final feature page. There is just an
approved status, and most people wouldn't care to take a look at *how* the
thing was approved. An 8:2 vote thus results in exactly the same perception
of a tag as a 50:0 one.

The current system of a clear separation of the proposal and feature pages
actually makes the closed voting necessary*. That *is why we need to agree
on the numbers.

Taking into account everything said in the (now multiple) threads on the
topic here, would it make sense to *change the current proposal/voting
mechanism like follows*?

- Author proposes a feature as now.
- RFC period with simultaneous page revision follows
- Opinions for and against are expressed in the discussions and
summarized at the top of the page (e.g. advantages and disadvantages of
a tag) together with the current usage
- When the discussion calms down (which can even be defined mathematically
if needed), this very page is converted into a feature page. It is never
approved or rejected, but the opinions are made clear.
- People can add their concerns later just by editing the page. Thus there
is no closing of the proposal phase. A feature can even get deprecated with
time if the usage is low and too many issues became apparent. This would
make discussions a bit more relaxed and positive.


The advantage of such approach would be:
- Adherence to the wiki idea, when the community develops a good page by
working on it more than by discussing it;
- Matching the OSM logic where numbers matter
- The majority of concerns regarding the discussion, voting, and
approval/rejection mechanism are addressed
- The system is even i18n-friendly, because such a top-of-the-page summary
can be easily translated, unlike a discussion in a mailing list
(potentially several of them).

Please comment.

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

Re: [Tagging] Revisiting proposal/voting scheme

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 9:46 PM, Bryce Nesbitt bry...@obviously.com wrote:

 +1 on showing the vote and discussion in the final page.

 And I guess +1 on the lack of a vote.  The ugly proposals DO look ugly.

 ---
 This works well for single proposals, but fails to capture *competing
 proposals *or* subsequent proposals.*


Can you explain how it fails to capture *competing proposals *or* subsequent
proposals*?

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

Re: [Tagging] Revisiting proposal/voting scheme

[Kotya Karapetyan]

To make it clear:

On Wed, Mar 18, 2015 at 11:00 PM, moltonel 3x Combo molto...@gmail.com
 wrote:
 Why should the page be converted to a feature page ?

Because I would mark a proposal page as such in some place. Otherwise a
stable 10 year-old feature page cannot be easily distinguished from a
proposal created yesterday. I see something like moving the page to a
different namespace or removing a proposal status. Not changing the
content or rewriting the page.


 A good proposal

should already be nicely usable as documentation of the desired
 tagging schema.


Fully agree.


 Note also that the feature - proposal relation is not one to one but
 many to many. Any nontrivial proposal will link to multiple tags, and
 a particular tag may link back to multiple competing proposals


Yes, and the combined pages can be linked just like that.


 Feature pages and proposals should be writen in parallel, not one
 after the other.


I am promoting writing a single feature proposal page, which, after the
initial discussion, is made just a feature page. So nothing is written
one after another.

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

Re: [Tagging] Revisiting proposal/voting scheme

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 11:39 PM, David Bannon dban...@internode.on.net
wrote:

 On Wed, 2015-03-18 at 22:21 +, Dan S wrote:
 
  So here's how I would answer your question of how would an interested
  party [...] objectively determine what the discussion concluded:
  instead of approved/rejected, some sort of visual widget on the wiki
  page which summarised the {{yes}} and {{no}} with something like 76%
  support [out of 98 opinions]. The poll would give a quick guide to
  mappers, and encourage others to chip in with their opinion - any user
  could add or remove their {{yes}}/{{no}} at any point.
 

 Certainly a different approach !



Ahhm, not sure how it is different, but never mind. I will be happy if we
all agree on a good solution, and I definitely don't claim the authorship
of all the good ideas that have popped up here over the last couple of
days. I just tried to summarize it in something that looked to me like a
working solution. Dan, thanks for making a good illustration :)


 Quite a good one really. It meets my
 criteria  of giving a new mapper some guidance on what he/she should
 use.


Good to hear :)


 Add in taginfo data.


Yes: *Opinions for and against are expressed in the discussions and
summarized at the top of the page (e.g. advantages and disadvantages of
a tag) together with the current usage*


 And maybe a list of competing approaches so, again, its clear to a new
 user what the options are.


It clearly belongs a see also section IMO.



 I do think we'd need to have some (usage determined ?) end point
 however. Who is going to register their approval of, eg, highway= this
 far down the track ?

 I think data consumers also need a bit of certainty too.


End of what?
Usage, as discussed in another thread, is a vague criterion. Two tags may
have a full support of the community, one having thousands of uses and
another (for a rare feature) ten.
For data consumers---definitely yes, and I suggest it being the moment when
we remove the proposal status, so the page becomes a feature page. The
moment can be w*hen the discussion calms down (which can even be defined
mathematically if needed**)*.

Sorry guys, no more spamming today :) Hopefully we'll converge to something
good, so these discussions won't be in vain :)

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

Re: [Tagging] Language - was Accepted or rejected?

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 3:58 PM, Martin Koppenhoefer dieterdre...@gmail.com
 wrote:

 I believe it is generally difficult to decide on English tags when you
 don't speak English.


I tend to disagree. A lot of people would be able to use the words
temperature or reception desk. The same people however may not feel
comfortable following an extensive discussion let alone contributing to it.
Programmers use a lot of English words in their code, which doesn't mean
they can use the very same words in real life.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Accepted or rejected?

[Kotya Karapetyan]

On Wed, Mar 18, 2015 at 1:13 PM, Martin Koppenhoefer dieterdre...@gmail.com
 wrote:

 I'd prefer to require something like not more than x percent negative
 votes rather than at least y percent positive votes, because when
 requiring a percentage of positive votes all abstentions count like
 negative votes.



Martin,

Do we have abstention possible at all? The voting system currently only
implements yes and no: https://wiki.openstreetmap.org/wiki/Template:Vote
.
If we had abstention, I would have rather counted it as non-supporting. A
proposal where people don't care or object is not a good one IMO.

However, I wouldn't mind changing it, since, as it is, there would be no
difference. To not re-vote this change, let's accept it first, and then we
can improve it further.

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

Re: [Tagging] Accepted or rejected?

[Kotya Karapetyan]

On Tue, Mar 17, 2015 at 4:05 PM, Martin Koppenhoefer dieterdre...@gmail.com
 wrote:

 I also don't think there is a procedure to change the proposal voting
 system and how votes are counted. 8 votes in favor of a change seem too
 few, and besides this, IMHO this is not something we should vote on the
 tagging mailing list, I suggest to announce it more broadly, eg on the
 national lists and on talk.


Hi Martin,

I proposed 8 votes because this is how the proposals are approved :) I
couldn't come up with a higher number, for the same reason why we have such
a low number of voters for proposals.
As for where to discuss it: If we discuss the proposals on this list, isn't
it a natural place to discuss how we vote for them as well?
If all people interested in proposing things or voting for them are present
here, then this is the right place to agree how we vote for them.
If interested people are not reading this list, then how are they supposed
to join the tagging discussion?

I agree though that it should be at least mentioned in the page talk. Will
do.

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

Re: [Tagging] Accepted or rejected?

[Kotya Karapetyan]

Hi Jan,

Your rule would mean that with 7/3 would be a rejection while 8/7 an
approval.
I suggest to not only bring the logic back but also address this issue.

I agree that it changes the rules, but why not try to improve them?

Cheers,
Kotya


On Tue, Mar 17, 2015 at 5:30 PM, Jan van Bekkum jan.vanbek...@gmail.com
wrote:

 I would like to stick to my original proposal. It brings the logic back,
 but doesn't change the rules.


 *enough support is 8 approval votes on a total of 14 votes or less and a
 majority approval otherwise.*

 On Tue, Mar 17, 2015 at 4:07 PM Martin Koppenhoefer 
 dieterdre...@gmail.com wrote:





 Am 17.03.2015 um 15:04 schrieb Kotya Karapetyan kotya.li...@gmail.com:

 I don't think there is a procedure to vote on such proposals, so please
 just give it +1 here if you agree. We change it when we have 8+ plus ones
 if there are no significant objections to *this* change.

 Once again, please note: we are not discussing the consequences of
 approval/rejection, we just change the rule of thumb recommendation to a
 mathematically more sound one.



 I also don't think there is a procedure to change the proposal voting
 system and how votes are counted. 8 votes in favor of a change seem too
 few, and besides this, IMHO this is not something we should vote on the
 tagging mailing list, I suggest to announce it more broadly, eg on the
 national lists and on talk.

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


 ___
 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] Accepted or rejected?

[Kotya Karapetyan]

Dear all,

I think we deviated from the original question quite a bit. The point was
that the current number of votes proposed in the wiki for accepted/rejected
decision was self-contradicting. Even if there may be different opinions on
that, the very discussion shows that the situation is not clear.

I propose to clarify it by changing the recommended number of votes in
https://wiki.openstreetmap.org/wiki/Proposed_features#Approved_or_rejected
from ...*8 unanimous approval votes* *or **15 total votes with a majority
approval...*
to *...8 or more **unanimous approval votes or 10 or more total votes with
more than 74 % approval...**.*
This will not change anything in terms of the ongoing discussion of *how* the
approval influences other things. So the discussion can continue. But we'd
introduce some mathematical logic in the process.

I don't think there is a procedure to vote on such proposals, so please
just give it +1 here if you agree. We change it when we have 8+ plus ones
if there are no significant objections to *this* change. Once again, please
note: we are not discussing the consequences of approval/rejection, we just
change the rule of thumb recommendation to a mathematically more sound one.

Cheers,
Kotya


On Tue, Mar 17, 2015 at 7:35 AM, Marc Gemis marc.ge...@gmail.com wrote:


 On Mon, Mar 16, 2015 at 10:04 PM, Warin 61sundow...@gmail.com wrote:

 inscription

 note (not rendered .. for use by mappers to make notes to other mappers ?
 thus not required to be rendered?)


 Visible in a popup in geschichtskarten for historical items.

 But you were talking about all renderers I thought. Now you seem happy
 that there is 1 renderer showing the feature/data ?
 I'm still convinced that features that people want to map will be mapped,
 regardless of the state of the tagging proposal.


 m.

 ___
 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] Accepted or rejected?

[Kotya Karapetyan]

Proposal: let's change it to 8 unanimous approval votes or 10 or more
votes with at least 74 % approval ones?

I agree that the current situation looks funny pretty often.

On Sat, Mar 14, 2015 at 6:46 PM, Bryce Nesbitt bry...@obviously.com wrote:

 On Sat, Mar 14, 2015 at 5:47 AM, Friedrich Volkmann b...@volki.at wrote:

 As you are already indicating, 15 is too low a quorum in that case. We
 cannot considering 8:7 votes an approval when we cosider 8:1 votes an
 approval. That would mean that more negative votes would turn a rejection
 to
 an approval, which is absurd.


 Exactly that happened.  There was a proposal with 7 votes, some positive
 some negative.
 3 more people voted no, flipping it to approval.


 If the purpose of the wiki procedure is to find consensus, a bare 50%
 majority indicates
 a near complete failure.

 ___
 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 - Temperature=

[Kotya Karapetyan]

Warin, you have a 50/50 split.

Maybe it's better to try to address the issues and re-vote the proposal? We
could have a good tag, but we are going towards a barely accepted one.

My main concern is not even that we don't have the vast majority support,
but that the proposal hasn't provided a clear answer to some open questions.

Cheers,
Kotya

On Thu, Mar 12, 2015 at 1:57 AM, Warin 61sundow...@gmail.com wrote:

 Well a summary at ~ 2 weeks

 Total votes 15.
 Approvals 7.

 So it is close.

 Please vote!

 In another week I've evaluate the votes and proceed from there.



 ___
 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 - Reception Desk

[Kotya Karapetyan]

 Also I believe most of the time you'll be more interested in the entrance,
 the reception desk will very likely be close to it.


On our campus, we have a couple of dozens of entrances for employees but
only three of four receptions where a non-employee can enter. So mapping a
reception definitely provides added value.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Reception Desk

[Kotya Karapetyan]

I believe it depends on the facility. My company has 3 receptions, and they
are called officially Reception 7, 4 and 8; these are the names
appearing on the phone when I receive a call to collect a visitor. I will
use that as the names.

On Sat, Mar 7, 2015 at 3:57 PM, Andreas Goss andi...@t-online.de wrote:

 Well, I think it depends on what kind of visitor you are. For the plant
 tour there is probably just one meeting and entrance point. But for
 suppliers, constuction workers, people from the same company who don't work
 at that plant I don't think it matters.

  Then that would be 3 reception desks with 3 different names.


 And how do I tag them? name= OpenStreetMap Plant Springfield - Gate 1,
 OpenStreetMap Plant Springfield - Gate 2 etc.?



  You have visitor reception at all gates? Visitor badging and everything?

 I assume there is security there letting people in (gate)  but are there
 3 areas for a person to be badged and wait for their visitee to come down
 and pick them up?

 3 places to sign up for the tour of the facility? 3 places vendors come
 to register to meet with buyers?

 Then that would be 3 reception desks with 3 different names.

 Javbw


  I approve this proposal. Also very useful for big industrial areas.
 [...] --Mapper999 (talk) 15:58, 2 March 2015 (UTC)


 So how do you tag it on a industrial complex when you have it at let's
 say Gate 1, Gate 2 and Gate 3?

 https://wiki.openstreetmap.org/wiki/Tag:amenity%
 3Dreception_desk#Comments



 ___
 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 - Reception Desk

[Kotya Karapetyan]

On Sat, Mar 7, 2015 at 10:24 PM, Andreas Goss andi...@t-online.de wrote:

 And if I'm a visitor how would for example a OSM based navigation system
 figure out to which company or facility they belong?


I think it's a relevant point. I would include the
company/hospital/university etc. name in the reception name. Similar to how
it's done to the building names in our campus:
http://osm.org/go/0EujzVLy6?node=2727694798. Then the routing softawre can
indeed find the correct way to the needed reception.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Reception Desk

[Kotya Karapetyan]

On Sat, Mar 7, 2015 at 11:50 PM, Warin 61sundow...@gmail.com wrote:

  Do you 'navigate' to 'drinking water' or simply look for the closest
 one?

 Most would navigate to an address .. then look on the map for parking,
 then look on the map for the closest reception desk ..


I think there is a difference between getting to a specific address and
getting to a reception of the building located at that address. A building
can be huge, or it can be surrounded with one-way or pedestrian streets.
It's really useful to know the location of the reception well in advance.



 some of them are for all the firms in that location.


I know from experience 3 distinct situations:
1) A large campus belonging to one organization has one or more receptions.
In that case a reception can usually be identified by some name.
2) A large campus belongs to one organization but lends location to smaller
companies (e.g. a start up company in a university). In that case a visitor
will usually get an instruction to get to the reception of the larger
campus, so that name helps again.
3) Many companies are hiring space in an office building, with a common
reception. In that case, unless the building has a name, it's indeed
challenging to name the reception, and it should be mapped without the name.

Anyway, IMHO we don't need to agree on this. The mappers must be able to
find a reasonable solution in each specific case. Situations can be pretty
different, and naming may or may not be helpful. I would add a
recommendation to name the reception in the wiki, but the final decision
should be left to the mapper.

In any case, being able to know where the reception is located is better
than not having that possibility at all, even if routing is not supported.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Temperature=

[Kotya Karapetyan]

Hi Warin,

Why rush? I don't think it's a question of how long the discussion
took. The proposal still has open issues, some of which are even
mentioned in the proposal page itself. So what are we voting for? It
would be better to close the open issues (or at least remove the
options that cause them), and vote for something definite.

I vote against, not because I am against the proposal, but because it
is not finished yet.

Cheers,
Kotya

On Tue, Feb 24, 2015 at 10:43 PM, Warin 61sundow...@gmail.com wrote:
 Hi,
 Well it has been 3 weeks for the comments .. a few changes/modifications,
 thanks for those.

 Time now to vote...

 Review the whole page - from the top
 https://wiki.openstreetmap.org/wiki/Proposed_features/Temperature


 Or go straight to voting
 https://wiki.openstreetmap.org/wiki/Proposed_features/Temperature#Voting


 =
 amenity=reception_desk voting in 2 days time
 waste_collection voting in 8 days time



 ___
 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 - temperature

[Kotya Karapetyan]

Hi all,

I wonder: shouldn't we separate a conditioned room air in a hotel and
an object temperature? I get the feeling that this discussion on a
useful tag (how to denote the temperature of an object where it is
needed) is slowly drifting away to defining about everything related
to temperature.

I would concentrate on a set of specific examples (where are
mappers/data users likely to want to tag/know the temperature?) and
just define the set of the tag values for them. The cases that are not
explicitly temperature-related shouldn't be covered by this tag in my
opinion.


An air-conditioned hotel room is a good counter-example for this tag.
It's the comfort level rather than the temperature that is the goal. A
temperature of the room is the secondary parameter here. Everyone
would understand what an air-conditioned hotel is, but I would
struggle to know whether +25 °C in July is comfortable for South Korea
or not if I see it in the map.

On the other hand, there may be a good exception. The American
consulate in Moscow is notoriously known for overusing air
conditioning and causing severe colds. People are advised to take
pullovers and scarves with them in summer. I've experienced the same
in McDonald's in Hungary. +20 °C may be a comfortable temperature but
not when it's +35 °C outside and the conditioner is blowing like hell
onto your head to keep the temperature down. For such cases, one could
tag the place as AC-ed and cold.

Summary: I suggest to use this tag (and discuss the recommended values
for it) only for the temperature specific cases, not for the whole set
of objects having some temperature.

Cheers,
Kotya

On Wed, Feb 11, 2015 at 10:59 PM, Warin 61sundow...@gmail.com wrote:
 On 12/02/2015 3:45 AM, Bryce Nesbitt wrote:

 On Tue, Feb 10, 2015 at 9:04 PM, Warin 61sundow...@gmail.com wrote:

 A hotel room that has air conditioning may be both heated or cooled
 depending on the desired temperature and the ambient temperature (and the
 air conditioner). It usually supplies a measure of fresh air too. I think
 that this should be considered as part of the building .. and a sub tag
 developed for that?


 In fact I think this is the key interesting characteristic to map:  does it
 have a chiller or heater at all?
 The specific temperature is likely set by the user, or varies by the season,
 and thus is a poor choice for a database key value.


 Either the substance is supplied at local ambient, or a facility is made to
 raise or lower the temperature:

  heated=yes
  cooled=no


 Most air conditioners here have the ability to both heat and cool at least
 here and in the UK.

 The temperature in large offices, hotels here are usually set centrally ..
 not by the guest or local worker.

 Why do you consider heated and cooled an 'interesting characteristic' and
 how do you see it being rendered on to a map? Is it more
 'important/significant' than the suggested temperature values? If so .. why
 has it not been proposed?

 I'd think that the vast majority will be interested in;
 showers that are 'adjustable' in the conventional sense (yet to come across
 a chilled water facility on a shower),
 the temperature of water that comes out of a tap (hot, 'cold' or boiling).
 Note thta boiling is different to hot, boiling can be used to make
 tea/coffee, hot is not good for making tea/coffee.





 A heated pool would be warm, cooled would be cool? Same with spars and
 taps..

 If adjustable, e.g. as most showers are, then the tag
 'temperature=adjustable' is part of this proposal...


 Frequently it's adjustable just one way.  For example we have water heaters
 for showers, but a water chiller is exceptionally rare.

 'temperature=adjustable' does not capture it really.  A hotel room with a
 heater but no cooler for example is adjustable, but
 not a good place to go when it's 100F and humid.


 Usually the adjustably provides for local conditions .. it would be rare to
 want to reduce a showers temperature below the ambient. In some parts of
 Asia the locals don't use showers for this reason - they use a scoop of
 water to wet the body, the interval between scoops provide a time where
 water evaporates thus providing cooling. Cheap, effective and efficient.
 Would you label this 'cooled=yes'? I note that OSM does not have a tag for
 this kind of washing facility.



 ___
 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 - Reception Desk

[Kotya Karapetyan]

 Amenity is the best fit for this tag.


 I disagree. (Usually that just means I didn't find anything better)

+1
Amenity is very vague in general (), and a lot of things can be
marked as such. So I'd prefer to use it only when it's an obvious
choice or there is nothing better.
What about using office?
I was also surprised to discover that there was not key for booth in
OSM. (And of course all currently available booths ended in amenity
:) ) Shall we maybe introduce it?

 As
 this tag is always going to be used within another entity I think we should
 rather look towards something like indoor tagging or other subtags. In
 addition using amenity for reception desk would for example prevent you from
 placing it on the node of the amenity and use one node for both.

Not to defend the amenity key, but I wonder if there is a need to tag
the reception if the whole object (including the reception) deserves
just a single node.

Cheers,
Kotya

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

Re: [Tagging] Feature Proposal - RFC - Reception Desk

[Kotya Karapetyan]

I think this proposal is very relevant for some larger hotel and
resorts. I've been myself a few times in a situation when I had to
search for the reception over a large area. It can be a trouble if you
simultaneously have to get rid of your car in a parking restricted
area. Same for multi-entrance campuses where only one door can be used
by guests (has a reception).

On Fri, Feb 6, 2015 at 6:18 AM, Paul Johnson ba...@ursamundi.org wrote:
 This seems to have a bit of overlap with information to a large extent.
 Most have tourism information for the area they're located and vicinity and
 can provide a lot of the same stuff as a general tourism information office
 would.  They just also rent space to park an RV (or even an RV or cabin), or
 throw up a tent.

 On Feb 5, 2015 8:07 PM, Warin 61sundow...@gmail.com wrote:

 Hi,

 Request for comment on new tag 'amenity=reception_desk'

 https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk

 This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a
 sub key of camp_site=reception.

 As 'Receptions' are numerous outside of camp sites I think it is best to
 have them available for use under other things - like hotels. So the new
 tag.

 'reception_desk' .. should separate it from other types of receivers ..
 like radio receivers.

 Amenity is the best fit so amenity=reception_desk.

 what do you think?





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


 ___
 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 - temperature

[Kotya Karapetyan]

1) +1 to drop Kelvins.

2) heated/cooled is a nice idea, but I wouldn't like seeing too many
top level tags.

temperature=heated
temperature=cooled
would be my preferred way to go.

I don't like :hvac too much either, because then what do I do if I
have AC + fireplace + central heating and use all of them for heating?
I would rather, if needed, use
temperature=heated
temperature:heated=fireplace|HVAC

3) +1 for having mild added. It is not the same as ambient and is useful.

Cheers,
Kotya

On Thu, Feb 5, 2015 at 9:14 PM, Warin 61sundow...@gmail.com wrote:
 On 5/02/2015 1:02 AM, fly wrote:

 Am 04.02.2015 um 10:56 schrieb Kotya Karapetyan:

 Hi,

 +1 for the proposal as such.

 I have suggestions for some parts of the proposal though.

 1) I would discourage specification of the temperature without the
 scale indication. I have never lived in the US but I see from the Web
 that Americans like specifying temperature in degrees Fahrenheit
 without mentioning it (the same way as we in Europe use centigrade
 without underlying it). Taking into account the international nature
 of the OSM community, I foresee a significant risk that the map will
 get populated with invalid values. Warin is right about SI units, but
 SI is not even strictly followed in the technical and scientific
 community, not to mention the general public. Obviously, Americans in
 general ignore it by using inches, miles and degrees Fahrenheit :) I
 am afraid many people will not have heard about SI guidelines and will
 not have read the wiki page in significant detail.

 Therefore, for the sake of clarity, I suggest always specifying F or
 C with the temperature value.

 +1
 Units for temperature are really wired and obviously Kelvin which I
 would suspect to be the default is not really used in real live as
 Celsius has the better scale for real life usage.


 I'm inclined to drop the Kelvin. Unlikely to be used, anyone using the
 Kelvin can easily convert it to degrees Celsius.

 2) I suggest clarifying the verbal specification of the temperature.
 - Replace chilled with cool (by analogy with warm) and also
 because chilled actually assumes that I know that the object was
 purportedly cooled down, which adds yet another uncertainty and is
 usually not very relevant;
 - remove the definition of substantially colder etc., because it
 doesn't add any clarity. I agree that it is important to distinguish
 between safe and unsafe situations, so let's just do that:


 I put that in to cover the 'chilled water' that some might have or come
 across. Maybe more of a hot climate thing? I think the users may include it
 anyway so I covered it in the documentation.

 freezing
 cold — may be unsafe to handle
 cool
 warm
 hot — may be unsafe to handle
 boiling
 adjustable — the object temperature can be changed by consumer/user
 variable — the object temperature can vary on its own
 ambient — the object always remains at ambient temperature (note that
 this may include the object being cold and warm, including being
 unsafe to handle, depending on the ambient temperature; think about
 water in Siberia rivers in January)

 Only two values I could live with are cold and hot. Generally these
 values are too ambiguous and an estimated value is much better.


 I think I said this .. but here it is again with some more thoughts?

 The proposal only tags 3 conditions;
 adjustable - box outline around the originally rendered symbol - red at the
 top fading to blue at the bottom
 hot - box outline around the originally rendered symbol - red
 cold -box outline around the originally rendered symbol - blue

 For the numerical data rendered as above for hot if over 55 C and blue if
 under 0 C ??

 3) For the numeric specification, I suggest adding:
 - above/below options
 - approximate value
 - range of temperatures (using above/below)

 E.g.
 temperature:circa = 80 C
 temperature:above[:circa] = 300 C
 temperature:below[:circa] = 1000 C

 I would add this in the value like:

 temperature =  10 C
 temperature =  300 C


 Nice idea. But;
 How many object in OSM need that kind of information? If the usage is low
 then it probably wont be rendered.
 How many data entry people will know the max/mins for an OSM object?
 And how would it be rendered?

 Possibly a better tag for this would be temperature_maximum= and
 temperature_minimum=

 ___
 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

[Kotya Karapetyan]

 have you checked your spam folder? sometimes gmail tends to label as
 spam a number of mailing list posts; periodically going through the spam
 folder and marking them as not-spam seems to reduce the problem, at
 least for a while.


Yes, I have and do it regularly. Also the all mail folder, since
some emails get there without appearing in the inbox. Also just
searched for the messages. All in vain :(

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

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

[Kotya Karapetyan]

Hi all,

1. I apologize for closing the proposal during this discussion. It was
not due to ignorance. For some reason, Gmail doesn't show all emails
from this mailing list. (I Googled for it a couple of times, but
couldn't find anything. Does anyone have a clue?) The last email I saw
was Warin's answer to Pieren's questions from 13 January. No response
appeared in my Gmail, so I went on with the standard procedure and
closed the proposal. Today, after reading a seemingly disconnected
post from althio, I went to check the tagging list archive and
discovered all emails from yesterday and today.

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. At the same time, those who
participated earlier don't join the current discussion. I could
understand if they found it a waste of time and, honestly, I don't
understand why you guys were silent for so long. Pieren indeed posted
one comment in the discussion page, to which I answered and haven't
received any further feedback until now (3 months later).

3. Someone mentioned that other discussions took more than a year. I
haven't decided to close the discussion after 4 months. It simply
converged and actually someone else proposed to go for voting (thus
the group was 1 person, Marc :)).

So this discussion once again shows the problems in the current
proposal process.

4. To cool things down: Even if the participants of the re-started
discussion all vote against the proposal, it will still leave the
result intact (it would add Marc, Althio and Janko if they haven't
voted and bring the result to 11:8). However, if a better solution is
proposed, I'll be happy to go on and vote for deprecating the current
tag and introducing a better one.

That was on the process. Now, to the actual discussion:

5. If I understand right, the main concern of the water_tap opponents
is the conflict between man_made=water_tap and amenity=drinking_water.
I wonder why no concern is raised about the drinking_water key. It
provides the full functionality of amenity=drinking_water and more
(since it allows the no and conditional values as well as the
legal subtag). So there is a direct conflict but I haven't seen any
proposal to deprecate drinking_water=*.

6. I find amenity=non_drinking_water a poor solution in general: it
implies that the mapper knows that water is non-potable. This is not
always the case. Not only it may not be known (marked); people may
have different attitude to the same kind-of-potable water source.
Non_drinking_water also doesn't indicate whether the water may be made
potable. Note that this is asymmetric to amenity=drinking_water, which
is *always* potable.

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.
7.2) Drinking water may come in a huge variety of forms, for many of
which there are dedicated tags. If you care about water-deprived
tourists or NGOs, you should also think about water_well, water_point,
spring, toilet, water and landuse tags. All of them are potentially
hiding potable water from users, and most of them are not amenities.
This means that if a tourist wants to find the nearest source of
potable water, all these objects should be tagged with
drinking_water=yes and the map users should search for this tag rather
than for amenity=drinking_water. Therefore I would start a separate
discussion on how to make sure that all sources of potable water are
tagged with drinking_water=yes.

8. Most importantly: The water_tap tag was initiated to solve a
specific problem without causing any additional conflicts, namely to
provide the means to tag water taps *independent* from whether water
is potable or not. That is to map an object, for which there is
currently no means in OSM at all. After some discussion and attempts
to find alternative tagging, the current proposal was found to be an
optimal compromise because:
8.1) it is under man_made (there was a suggestion to make it an
amenity), meaning that it can be used together with
amenity=drinking_water to specify the type of the source;
8.2) it is very similar in all ways to man_made=water_well (again, I
haven't seen any doubts on that one), so it should look logical to
mappers;
8.3) it provides good means to tag a water source where there 

Re: [Tagging] Basic philosophy of OSM tagging

[Kotya Karapetyan]

Now that the water_tap proposal discussion is over, I'd like to join
this important discussion.

My opinion: Since OSM is a *map*, we should *map* things. That means,
we should tag what actually exists on the planet, not what is implied.
Sometimes things are tagged in real life. For example, motorways are
marked with special traffic signs, therefore we can tag a road as
motorway. In other cases, we should use common sense to call the
things by their names. I am usually asking myself: How would I explain
to a tourist how to find his way? I will use something like Pass by
... or You will see  This ... is then the name (hence tag) to
be used.

A good example of the contrary is amenity=drinking_water. Though the
original intention is clear, I believe the solution is suboptimal: a
tourist wouldn't know what to search for (since it is not drinking
water but rather its source that is actually visible in a given
place). A mapper may also have hard times identifying whether a
specific water source provides potable water or not.

So, my answer would be we should map what the things *appear to be*.
Taking the example of Japanese roads, I would also add with
reasonably common knowledge. It does leave some space for
uncertainty, but this uncertainty is also present in real life, so it
can appear in OSM as well.


Warin's question also identifies a problem I'd like to discuss. There
seem to be no formal agreements on how to create OSM. Things are
documented in the wiki, which is subject to uncontrolled changes and
no review and which is not always read by the mappers. Data is then
used by software development companies in the way they find
reasonable, without any foundation for consistency. It may be cultural
but I am looking for some sort of more robust, maybe even enforced,
agreements. They may be subject to changes, but their mere existence
would help. What do you think?


Cheers,
Kotya




On Wed, Jan 14, 2015 at 1:28 AM, Warin 61sundow...@gmail.com wrote:
 This comes from the tap discussion but has implications elsewhere.

 What is the basic philosophy of OSM tagging at the top level?

 Are 'we' tagging for

 What things are? eg highways

 OR

 What things are used for? eg amenity

 
 Explanation? By example;

 Highways are used for transport so would be better tagged as
 transport=motorway, sub tags for vehicles etc.

 OR

 amenity=drinking_water would be better tagged as water=blubber

 --
 Is there an FAQ on this? Or has this never been documented/though of?
 Have fun with this  :)




 ___
 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

[Kotya Karapetyan]

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

To those who voted against the proposal: Thanks to you too for
consideration. There was a bunch of remarks concerning the clash
between amenity=drinking_water and this proposal. As the discussion in
this list has shown, those who voted in support of this proposal have
been aware of the clash. The reason to introduce the new value was not
to solve all water-related problems but to close the unfortunate gap
provoking incorrect or improvised tagging. No better solution could
have been identified during the extended and long discussion. So
please consider this situation as a compromise.

There was also a remark that the water tags should be reviewed. I
fully support this idea. Let's start at the current Warin's discussion
https://lists.openstreetmap.org/pipermail/tagging/2015-January/020941.html.

Cheers,
Kotya



On Sun, Jan 11, 2015 at 11:58 AM, Kotya Karapetyan
kotya.li...@gmail.com wrote:
 Dear all,

 This is a kind reminder that the voting is ongoing at
 https://wiki.openstreetmap.org/wiki/Proposed_features/water_tap#Voting

 Cheers,
 Kotya

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

Re: [Tagging] Basic philosophy of OSM tagging

[Kotya Karapetyan]

Hi Marc,

 By forced rules: you mean a committee that decides what gets mapped and how
 ?
 So when I want to map something now, I have to file a request to the
 committee to start looking for a new tag. And if they like the request they
 come back within a few months with a proposal. And this committee is
 all-knowing, so they know all the exceptions in the different countries ? So
 I don't have to ask for an update when they misunderstood me ?

My vision was more along these lines. There will be a tagging
committee: It will maintain the official OSM tagging scheme. Mapping
will not be changed w.r.t. the current situation. The tagging
functionality as such will remain as it is, however:
1) Software designers can use the official scheme to implement tools
for mapping, display, and routing.
2) The committee will review the existing tags to avoid conflicts, and
decide what tags are to be deprecated, where to adjust official
definition etc.
3) The short formal description of the tags is included in the scheme.
4) The committee has the final word in approving the tags (just to
remove the mess with existing discussion-voting process).
5) Mappers can still implement and use tags as now, however they
should be reviewed by the committee to get into the official scheme.

So something similar to how HTML standard is maintained by W3C:
Google, Microsoft and Mozilla can do and do whatever they like in
their browsers and online tooling, but there is an official standard
based on some proposals. The software developers do not have to stick
to the official scheme, but it helps make things more consistent.

Cheers,
Kotya

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

Re: [Tagging] Basic philosophy of OSM tagging

[Kotya Karapetyan]

On Thu, Jan 15, 2015 at 6:07 PM, Michał Brzozowski www.ha...@gmail.com wrote:
 Also, I think that editor presets makers should really implement *all*
 approved tags (barring some specialized stuff like OSM-3D, indoor
 mapping etc) because not featuring a tag makes some people tag things
 not exactly correctly, just to map it.

+1.

I would also like us to discuss a possibility of making the tagging
scheme more error-proof. A couple of issues to address:
1) Conflicting tags should be prevented by means of software.
2) Suggested tags functionality should be implemented.
3) Official tag description should be automatically taken from the
formal approved tagging scheme and shown in the mapping tool, to
minimize misunderstanding. Full tag description stays in the wiki to
include examples, photos, context etc.
4) Invalid tag values should be automatically identified and warnings
should be shown.

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

[Tagging] Feature proposal - Voting - Water tap

[Kotya Karapetyan]

Dear all,

This is a kind reminder that the voting is ongoing at
https://wiki.openstreetmap.org/wiki/Proposed_features/water_tap#Voting

Cheers,
Kotya

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

Re: [Tagging] Feature Proposal - RFC: Reverse Vending Machine

[Kotya Karapetyan]

I like the proposal. In Germany and in the Netherlands these machines
are common and it is indeed important to know where one can find the
nearest one. They are usually not operator-specific, though the
voucher they issue can be redeemed only within the operator shop (or
network).

I have no clue how these machines are called in English, but
refund_machine sounds generic enough.

Remark 1: I wonder if we also want to indicate whether the machine is
inside or outside the shop and if it is accessible outside working
hours.

Remark 2: Also some shops have multiple such machines (e.g. for glass
and plastic), and OSM tagging scheme doesn't allow assigning the same
key twice to one node. As a suggestion, we could ignore the fact that
these are two (or more) separate machines and map it as one.

Cheers,
Kotya

On Sun, Jan 11, 2015 at 12:58 PM, makko ma...@brainscorch.net wrote:
 On 11.01.2015 12:50, SomeoneElse wrote:

 In the UK, it isn't common - at least, I'd not heard of it before this
 thread.

 Interestingly, one of the links from the WP page is to a UK company that
 claims to have a trademark on the term.


 I see. Perhaps then it would better to use:

 amenity:refund_machine

 Since the term might be very broad, it would also fit with the other
 proposed tags to be used in the future, if there might be other sorts of
 refund machines.


 ___
 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] Defining genre for public bookcases

[Kotya Karapetyan]

I agree with Craig concerning the use of word literature and suggest
simply using books:genre, to make use of the existing key. Having two
keys book and books would be confusing. Besides, the current tag
seems to me to be overlapping with what is proposed. It is now indeed
used for types of books, but I don't see any harm in using it for the
type or for the genre, whatever applicable.

On Wed, Jan 7, 2015 at 3:11 PM, Craig Wallace craig...@fastmail.fm wrote:
 On 2014-12-27 17:34, Guillaume Pratte wrote:


 This could give:

literature:genre=science-fiction
literature:genre=mystery
literature:genre=cookbook
literature:genre=comedy
…

 What do you think?


 I think 'literature' is not the best word for this.
 Yes, literature can refer to any written works. But it often has a more
 restricted definition. eg from
 http://dictionary.cambridge.org/dictionary/british/literature
 written artistic works, especially those with a high and lasting artistic
 value:
 So that would exclude cookbooks for example, as well as many fiction books
 if they don't have enough 'artistic value'.

 I suggest keeping it simple, ie tag it as book:genre

 This tag could also be used for bookshops or libraries that specialise in a
 particular genre.
 I notice there is already a tag for books, which has some use:
 http://wiki.openstreetmap.org/wiki/Key:books
 But that seems to be more about the type of books, not the genre.

 Craig

 ___
 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 - Water tap

[Kotya Karapetyan]

Hi Martin and all,

It seems to me we can discuss it in great detail and agree on something,
but the users will understand—and use—the proposed (or even non-existing)
tags it in their own way. They will not have followed this discussion and
many will not even read the corresponding wiki-page. Therefore I would try
to assume as little information as possible and still introduce some
improvement. Specifically:

 what exactly is a water_tap? Does it require that you can shut it down
or open it (i.e. are always on taps also taps?)? Are particular
interface specifications possible/required (e.g. standard plug to attach
a tube, diameter for the tube). Around here the typical settings for water
flow are: always on or 3 types of devices to turn it on: a push button (you
have to hold to get water flow), another kind of push button (you press
once and get flow for some time without having you to continue to push) or
a turning handle to open/close the valve.

- Button, pedal, valve, IR-sensor are all possible, as is an internal (not
easily accessible or requiring a special key) valve
- Permanently running water tap is also OK. As long as a common person
would describe the water source as a water tap, this tag will be fine.
- A connection interface is possible (just like in home water taps) but is
not assumed and is not specified in the current proposal.

 I find this sentence strange in the definition: Unlike a water well,
water tap usually connects to water pipes rather than to a natural source
of water. Isn't a tap the final interface to who needs water, usually
with a valve to open and close flow? How would that relate to a water well
(a device to pump water from the ground)? I thought a water well could have
just as well a water tap at the end of its pipes to control the flow.

- I agree, it's not very well phrased and will be improved. A water well
gives access to groundwater, while a water tap is a technical device. So
you're right, they don't really compete. *A water tap however is a good tag
for a POI when the source of water is unknown.*
- Some confusion between a water tap and a water well is definitely
possible in real life. What is this for example:
https://en.wikipedia.org/wiki/Tap_(valve)#mediaviewer/File:Basic,_Surmi,_Tulgit_(13369732263).jpg
?

We can introduce yet another more generic water source, as discussed
before. However it goes more in the direction of changing the whole tagging
system. Though I would definitely be in, let's address the specific problem
first and discuss more general options later. *I just want people to stop
inventing the ways to tag a water tap, independent from in-depth discussion
whether the thing actually is a water tap. *

So the present proposal's goal is to merely close the gap with some water
sources having no reasonable tag at all, as well as to
introduce potentially some uniformity in tagging water sources and prevent
unfortunate situations like amenity=drinking_water +
drinking_water=now/unknown or using name=water_tap.

 Also I wonder if we should have tags for hot/cold water and those taps
that mix hot and cold in the same tap?

I haven't seen many hot water taps in the streets, but it definitely
welcomes another discussion. What shall we call hot and cold? Shall it
be rather heated and cooled? I would leave it to sub-tagging, and
again, let the people bring it in. I think the majority of use cases will
be addressed with a single simple tag.

*The main use case is when the water source is not clearly a water well
(thus not man_made=water_well) and, at the same time, when potability
cannot be assumed (thus not amenity=drinking_water).*


 I would also change public to publicly usable (or publicly
accessible), because this is what does matter (and we don't want to exclude
privately owned, but publicly usable taps in this generic proposal, do
we?).

Agree.

I hope I've addressed your concerns and you can vote now :)

Cheers,
Kotya

On Fri, Jan 2, 2015 at 11:31 AM, Martin Koppenhoefer dieterdre...@gmail.com
 wrote:


 2014-12-30 21:33 GMT+01:00 Kotya Karapetyan kotya.li...@gmail.com:

 I agree.

 Voting page:
 https://wiki.openstreetmap.org/wiki/Proposed_features/water_tap#Voting

 Thanks everyone for the in-depth consideration.




 now, that this has fortunately become something more simple (e.g. not
 implying that the water is not drinkable, not replacing
 amenity=drinking_water etc.), I have some additional questions:

 what exactly is a water_tap? Does it require that you can shut it down
 or open it (i.e. are always on taps also taps?)? Are particular
 interface specifications possible/required (e.g. standard plug to attach
 a tube, diameter for the tube). Around here the typical settings for water
 flow are: always on or 3 types of devices to turn it on: a push button (you
 have to hold to get water flow), another kind of push button (you press
 once and get flow for some time without having you to continue to push) or
 a turning handle to open/close

Re: [Tagging] Feature Proposal - RFC - Water tap

[Kotya Karapetyan]

Einverstanden :)
Please vote:
https://wiki.openstreetmap.org/wiki/Proposed_features/water_tap#Voting

Cheers,
Kotya

On Tue, Dec 30, 2014 at 11:08 AM, Friedrich Volkmann b...@volki.at wrote:

 On 04.12.2014 10:31, Kotya Karapetyan wrote:
  For me, English common sense says a 'water source' could be a river,
  lake, spring etc...
  the portability of water is not a measure of its source (where it
 comes
  from) but its purity...
 
  So I'd think the key should be
 
  Water_purity  with the key values 'potable', 'nonpotable' and
 'unknown'
  ('yes' does not imply anything in the context of water purity nor
 water
  source).
 
  That key can be added to rives, lakes, drinking fountains etc etc ..
 no
  changes are required for present tags. Simply the additional
 information
  can be added.
 
 
  Warin, I don't know if you followed the discussion and saw the proposal
 in
  the wiki.
  In short, it all started with the lack of good option to map a source of
  non-potable water, like a water tap. It evolved from there to the current
  state. The proposal from the last email reflects  to ~90 % everything
  suggested as the discussion proceeded.

 In German, we have a verb verschlimmbessern, which means to make
 something
 worse by improving it. I agree with Warin that water_source=potable does
 not
 seem right. It mixes source (origin) and target (use). water_source=* may
 be
 fine with another set of values, and *=potable may be fine with another key
 (drinkable=* and drinking_water=* are in use, and water:quality=* and
 water_purity=* were suggested in this discussion).

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

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

Re: [Tagging] Feature Proposal - RFC - Water tap

[Kotya Karapetyan]

I agree.

Voting page:
https://wiki.openstreetmap.org/wiki/Proposed_features/water_tap#Voting

Thanks everyone for the in-depth consideration.

Cheers,
Kotya



On Mon, Dec 29, 2014 at 12:01 PM, Warin 61sundow...@gmail.com wrote:

 On 29/12/2014 9:33 PM, tagging-requ...@openstreetmap.org wrote:

 Message: 8
 Date: Mon, 29 Dec 2014 02:18:28 -0800
 From: Bryce Nesbittbry...@obviously.com
 To: Tag discussion, strategy and related tools
 tagging@openstreetmap.org
 Subject: Re: [Tagging] Feature Proposal - RFC - Water tap (Kotya
 Karapetyan)
 Message-ID:
 CAC9LFPe1V1VMf=wJzs_HxE-cuL9HO4XE0_Zx1UH_MO-aCABZrQ@
 mail.gmail.com
 Content-Type: text/plain; charset=utf-8

 On Thu, Dec 4, 2014 at 4:22 AM, Martin Koppenhoeferdieterdreist@
 gmail.com
 wrote:

 
 not sure if purity is a good choice. Completely pure water is not
 potable (distilled water), you'd die if you drank too much (OK, you'll
 also
 die when drinking too much normal water [1], but the second too
 much is
 much more than the first).
 

 purity is a judgement call.
 Generally those don't go well in OSM.

 How about tags for signage, e.g. It's marked as potable, it's marked as
 untested, it's marked as non-potable.
 -- next part --
 An HTML attachment was scrubbed...
 URL:http://lists.openstreetmap.org/pipermail/
 tagging/attachments/20141229/8e58bbdf/attachment-0001.html

 --


 I suggest the tag for taps go ahead for voting. But remove all the
 purity/potable things .. just vote on the tap. I don't see any problem
 there.

 The sub tag for potable can then be raised as a separate wiki entry .. and
 discussion on 'portable' continued. Such as when the tap carries no
 marking; I'd think this will be country sepcific .. some countries will
 have unmarked taps as potable, other countries as non-potable, and others
 as 'unknown'. Note that this sub tag can be applied to things other than
 taps... springs, fountains ...

 ___
 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] Accuracy of survey

[Kotya Karapetyan]

Hi Warin and all,

I am not sure what you dislike in accuracy. Accuracy is how far the
measured mean value is from the actual value (
http://en.wikipedia.org/wiki/Accuracy_and_precision). However we can start
calling it a trueness, to follow the ISO definition. If you mean
something else, please explain, and I believe it would deserve a page in
OSM wiki.

Now, I am talking about the absolute trueness. That is, how far a POI is
according to the map from its actual position on the planet. No, I don't
forget that the planet surface is moving relative to the GPS coordinates.
Even more so, there are local surface movements, especially if the survey
marker is located, say, on a bridge or close to an excavation site. It
should be considered when defining this non-movable POIs.

Taking into account the inherent precision of the survey marker position
(they are designed to have a well-defined position), it does make sense to
have OSM data for them defined better than for all usual elements.

At the same time, if you are talking about common use, these POIs are of
little interest to normal users. So their specific properties will not
disturb anyone.
However, some mappers may be in possession of the surveying tools allowing
them to have better trueness than possible with a GPS, provided that they
have some good reference points. Survey markers are designed just for that.
For these mappers, the absolute location of the survey markers is
important, and I see no reason to prevent them from having it in OSM.

 OSM renders distort road widths according to their classification .. that
is normal mapping for road navigation. If you wanted air navigation then
the actual road width would be better to render, with runways having more
emphasis.

True. However the underlying data is independent from how a specific
renderer represents each element. A street is usually just a line, thus
having no width.

Cheers,
Kotya



On Tue, Dec 30, 2014 at 12:50 AM, Warin 61sundow...@gmail.com wrote:

  On 30/12/2014 6:41 AM, tagging-requ...@openstreetmap.org wrote:

 Date: Mon, 29 Dec 2014 15:27:23 +0100
 From: Kotya Karapetyan kotya.li...@gmail.com kotya.li...@gmail.com
 To: Rainer Fügenstein r...@oudeis.org r...@oudeis.org, Tag discussion, 
 strategy and
   related tools tagging@openstreetmap.org tagging@openstreetmap.org
 Subject: Re: [Tagging] Accuracy of survey
 Message-ID:
   cak2dj-whwqajz+0-oxjue9bhn-w1eldcypm4am4xidn2fp5...@mail.gmail.com 
 cak2dj-whwqajz+0-oxjue9bhn-w1eldcypm4am4xidn2fp5...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8


 Since such reference points are quite common, I would support the idea of
 creating a special tag for them, requiring that they are not moved. However
 we need a clear consensus on how we define the sufficient accuracy and
 how the data for such points will be updated.

  Ultimate 'accuracy'? You do realise that the tectonic plates are moving?
 So your reference points need to include a date so they can be corrected
 for the drift. You'll find that data is available for those survey
 reference points .. together with their precision. Do you want to update
 these points to maintain their 'accuracy'? How often?
 Survey reference points are 'quite common' in built up areas ... but not
 in remote locations. And depending an the age and how precise the survey
 was will have some effect on their 'accuracy'. One surveor in Australia
 forget to allow for the temperature effect on this measurement chain 
 back when chains were used.


 I disagree with the point of view that an accuracy sufficient for consumer
 GPS devices is sufficient for OSM and therefore there is no problem here.
 Nobody ever declared that OSM is for smartphone users. We are trying to map
 the world, and accuracy should be of primary interest for this project.



 Again the word 'accuracy'.

 Context 1.
 I have advised one mapper in their diary that most, if not all, users will
 be using their data entry with similar equipment to what they have .. so
 any 'inaccuracy' will also be present for the other users. Thus what they
 map should represent what is there and should be usable as a map ..
 considering that the GPS information may be very vague under the tree cover
 present and the local cliffs etc.

 Context 2
 I will be mapping a track that is covered in a few places  .. by an over
 hanging cliff. As such it is not visible by satellite .. nor will the GPS
 track be that 'accurate'. So I'll be mapping it from the available
 information that I have then - a few photos, my track and the satellite
 image. It will take me about a week to traverse the area. No shops etc.

 I would rather have the less 'accurate' representation of what is there
 compared to a blank area. I've plotted one track that goes from one place
 to another (personal knowledge).. where it is not visible on the satellite
 view I've plotted it as a straight line.. I know it is not a straight line
 but it is the best I can do and conveys

Re: [Tagging] Accuracy of survey

[Kotya Karapetyan]

Happy holidays and 2015 everyone!

 what is needed here is some tag, saying don't touch these
 coordinates, they've been surveyed with high(est) accuracy.

I second this idea.

Just recently I discovered that something in this direction already exists:
https://wiki.openstreetmap.org/wiki/WikiProject_France/Rep%C3%A8res_G%C3%A9od%C3%A9siques#Permanence_des_rep.C3.A8res
Example: https://www.openstreetmap.org/edit#map=23/43.42272/6.76665
However it seems to be France-specific. I don't know if a similar thing
exists e.g. for Germany.

Since such reference points are quite common, I would support the idea of
creating a special tag for them, requiring that they are not moved. However
we need a clear consensus on how we define the sufficient accuracy and
how the data for such points will be updated.

I disagree with the point of view that an accuracy sufficient for consumer
GPS devices is sufficient for OSM and therefore there is no problem here.
Nobody ever declared that OSM is for smartphone users. We are trying to map
the world, and accuracy should be of primary interest for this project.

Cheers,
Kotya

On Thu, Dec 25, 2014 at 7:16 PM, Rainer Fügenstein r...@oudeis.org wrote:


 TP It was not clear if the OP indeed wants to map pipelines,
 TP or was just quoting the pipeline expert for his opinion about
 TP surveying methods.
 the latter. I'm referring to all nodes, not just pipelines  marker.
 Just used the conversation I had some time ago as an example.

 W Terms !!
 W In Metrology (http://en.wikipedia.org/wiki/Metrology) the words
 W accuracy, error, etc have specific meaning ..

 please forgive my ignorance - let the experts decide on a proper term
 to be eventually used as tag. dilution comes to mind, but that's GPS
 specific, if I'm not mistaken.

 FV Even if you collect plenty of GPS traces with no systematic error,
 these
 FV still cannot beat a theodolite triangulation.

 when specifying accuracy, the source of the coordinates shouldn't
 matter. It could be GPS, DGPS, theodolite triangulation, a file
 provided by officials or companies ...

 FV I used estimated_accuracy=* or gps_accuracy=* a couple of times,
 IMHO, that's the way to go. would recommend against gps_*, see above.
 also, there should be a distinction between estimated and actual
 accuracy.

 FV but I doubt
 FV that it prevents other mappers from moving or even deleting them. Some
 use
 FV editors like Potlatch, so they are not aware of tags. Some do
 thousands of
 FV edits, all of which are validator based corrections. They do not ask
 nor
 FV think nor look at tags, except at those reported by the validator.

 software evolves; if such a tag is considered useful and widely used,
 it may eventually be supported by the developers. of course, there'll
 always be the black sheep ...

 FV Also, there is no clear line between high and low precision data.
 Should an
 FV editor warn when the precision is better than 1m, but ignore a
 precision of
 FV 2m? This all depends on the precision of the new data, which the
 editor does
 FV not know.

 for starters, I'd begin with a general warning if the precision of the
 existing node is less or equal than 2m (thats better than what the
 average consumer receiver can achieve). to draw a line between high
 and low precision, this article [1] may be helpful.

 some GPS receivers show the current precision in meters; GPX files
 contain HDOP/VDOP/PDOP if provided by the receiver. In theory and if
 provided, when a GPX file is used as source for nodes, precision could
 be derived from this information (by whatever means).

 FV There are no GPS traces for pipeline markes.
 actually, there are ;-) I just didn't upload mine. but apart from
 that, pipeline mapping seems to be a few-(wo)men show, therefore it's
 more likely that pipeline operators may release their (high precision)
 data [2] before there are enough GPS traces to significantly increase
 precision via interpolation.

 cu

 [1] http://en.wikipedia.org/wiki/Global_Positioning_System
 (section Augmentation f.)

 [2]
 https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/PipelineExtension#status_update.2F1


 ___
 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 - Water tap

[Kotya Karapetyan]

 ? On the Keep It Simple Stupid theory?

 water_potable = yes/no
 If not known you don't tag. Then it will some default action possibly based 
 on location. Some may want tags 'boil', 'filter','filter+boil' ...


What would be the difference from the existing drinking_water=*?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Water tap

[Kotya Karapetyan]

 For me, English common sense says a 'water source' could be a river, lake,
 spring etc...
 the portability of water is not a measure of its source (where it comes
 from) but its purity...

 So I'd think the key should be

 Water_purity  with the key values 'potable', 'nonpotable' and 'unknown'
 ('yes' does not imply anything in the context of water purity nor water
 source).

 That key can be added to rives, lakes, drinking fountains etc etc .. no
 changes are required for present tags. Simply the additional information
 can be added.


Warin, I don't know if you followed the discussion and saw the proposal in
the wiki.
In short, it all started with the lack of good option to map a source of
non-potable water, like a water tap. It evolved from there to the current
state. The proposal from the last email reflects  to ~90 % everything
suggested as the discussion proceeded.

I agree that water_purity sounds better than many other combinations
though. So if you could suggest how to tag a tap with non-potable water, we
can reconsider it.

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

Re: [Tagging] Feature Proposal - RFC - Water tap

[Kotya Karapetyan]

 water_source:sparkling=yes | no | unknown



 in analogy: water:effervescent (or ~:sparkling)


 I don't mind using the word effervescent; however: is there any
 recommendation that we should use as simple words as possible, to achieve
 the above goals 1 and 3? I know this for scientific papers and am trying to
 stick to it in all inherently international situations.



 I believe that water_source:sparkling is not the same as
 water:sparkling, because it is the water that is sparkling, not the water
 source.


I get your point. However, I don't think that switching the namespace is a
good solution since it breaks encapsulation. Interesting, you didn't make
this remark about water_source=potable, though it's similar. Anyway, what
about adding

water_source:water_property = sparkling,

and allow a combination similar to multiple highway lanes, e.g.

water_source:water_property = sparkling | radioactive ?


Again, I'd like to go level-wise:
 what is it? water source is it potable? yes/no/conditional why is it
 non-potable? compromised/designated why conditional? needs boiling etc.



 needs boiling is not the next sublevel of
 1 potable=no
 2 why-non-potable=compromised

 it is another way of looking at this (how can the water be made potable)

 3 would be something like: what is the concentration of the contamination,
 what type of contamination is there, etc.


Sorry, I think I expressed myself badly by having mixed alternatives and
levels. needs boiling should explain the value conditional, not
why-non-potable. Similarly, your data about concentration and type of the
contamination would explain the value potable=no

In principle, details regarding the kind of water source could be provided
 here as well, to free up the top level a bit and help data users:
 water_source:type = tap | fountain | well | spring



 or have this inherited from the main tag (e.g. amenity=fountain,
 man_made=water_tap, natural=spring, man_made=water_well


 I agree in general, but I do not know how inheritance works in OSM. Where
 can I read about it?


 it doesn't work in OSM, it works at the data consumer side by
 interpretating the data, when there is an object amenity=fountain than it
 is clear that the water_source:type is a fountain, no need to duplicate
 this information in a nested water_source sub-tag.



Clear. However what if another top-level tag is missing? One could use
water_source alone (if I understand correctly, OSM doesn't enforce any
combination of tags). Therefore it should be possible to write all
properties within this tag. But of course, the software can help the mapper
by adding the reasonable tags when the user chooses amenity=fountain.


It looks like we have covered most of the necessary topics. I still see one
gap: what about water drinkable for animals but unsuitable for humans? I
suggest adding another value like water_source=conditional +
water_source:conditional=animals_only. However I suggest discussing the
remaining questions during voting and or later. The main conclusions I
propose to vote on are:

- deprecate the tag amenity=drinking_water
- introduce new top-level key water_source
- the values will be potable, nonpotable, yes (for unknown potability)
- introduce the optional subkey water_source:potable with the values
yes, conditional
- introduce the optional subkey water_source:water_properties with the
combinable values sparkling, radioactive, contaminated
- introduce the optional subkey water_source:type with the values well,
tap, spring etc. Its use is discouraged in case another top-level tag
is used, which sufficiently defines the type of the water source
(water_well, fountain etc.).

Further subtags and values may be added as needed.

- keep in use the tags:
natural=spring
natural=water
amenity=water_point
man_made=water_well
waterway=water_point
and recommend to amend them with water_source if appropriate.

Unless there are serious objections (I'll wait a couple of days), I suggest
to start the voting, and we can discuss additional subkeys and values
later, once the key is introduced. During voting, we can also clarify some
things on the main proposal, by removing/replacing some values and wording.

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

Re: [Tagging] Feature Proposal - RFC - Water tap

[Kotya Karapetyan]

On Tue, Nov 18, 2014 at 11:11 AM, Martin Koppenhoefer 
dieterdre...@gmail.com wrote:


 2014-11-17 23:26 GMT+01:00 Kotya Karapetyan kotya.li...@gmail.com:

 What about introducing a name space:
 water_source:potable=designated | mineral | heilwasser (I failed to find
 a good English-language analogue, could someone help please?)



 I'd make this water:quality and values potable | mineral | de:heilwasser
 (or an English correspondent if available, or DE:heilwasser because it
 refers to German legislation)
 maybe also add toxic / contaminated(?), non-potable
 not sure about radioactive?


If we agree for a change, I would like to make the new tags
- as easy as possible to map: if only minimum information is available,
it's still mappable;
- as easy as possible to use: even if information is limited, it's still
clear; programs would have something meaningful to show in any case;
- as difficult as possible to make mistakes: no unclear information for
users, tag logic clear for mappers.

I see hierarchy and encapsulation of tags as the means to achieve these
three goals. That's why I also would like to avoid going outside the tag
by using water:* and stick to water_source:*




 water_source:sparkling=yes | no | unknown



 in analogy: water:effervescent (or ~:sparkling)


I don't mind using the word effervescent; however: is there any
recommendation that we should use as simple words as possible, to achieve
the above goals 1 and 3? I know this for scientific papers and am trying to
stick to it in all inherently international situations.





 water_source:nonpotable=compromised | designated



 could maybe be integrated in the quality-tag?


Could you give an example? Again, I'd like to go level-wise:

what is it? water source
is it potable? yes/no/conditional
why is it non-potable? compromised/designated
why conditional? needs boiling
etc.

Thereby everyone will find the water (useful at least to wash a car / water
the flowers, but also could usually be drunk after proper treatment). Then
we clearly indicate the most critical parameter. And we go on. If at any
level the data is not available or the data user cannot use it, integrity
is not violated. Basically, it's the XML approach, and it seems to work
fine.






 In principle, details regarding the kind of water source could be
 provided here as well, to free up the top level a bit and help data users:

 water_source:type = tap | fountain | well | spring



 or have this inherited from the main tag (e.g. amenity=fountain,
 man_made=water_tap, natural=spring, man_made=water_well


I agree in general, but I do not know how inheritance works in OSM. Where
can I read about it?

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

Re: [Tagging] semantic issue with genus in the wiki, wetland, plant nursery, ...

[Kotya Karapetyan]

 I think this is an inconsistency in tagging and would be interested to
 hear if you believe the recommendation should be changed. E.g. we could
 have a plant:genus to explicitly state that the genus refers to the
 plants rather than the nursery.


I agree about the inconsistency. In general I prefer the
hierarchical approach (so with plant:genus), rather than numerous top-level
tags.

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

Re: [Tagging] Feature Proposal - RFC - Water tap

[Kotya Karapetyan]

What about introducing a name space:
water_source:potable=designated | mineral | heilwasser (I failed to find a
good English-language analogue, could someone help please?)
water_source:sparkling=yes | no | unknown
water_source:nonpotable=compromised | designated

In principle, details regarding the kind of water source could be provided
here as well, to free up the top level a bit and help data users:

water_source:type = tap | fountain | well | spring

Please comment.

Cheers,
Kotya



On Thu, Nov 13, 2014 at 5:07 PM, Martin Koppenhoefer dieterdre...@gmail.com
 wrote:


 2014-11-13 6:50 GMT+01:00 Bryce Nesbitt bry...@obviously.com:

 Let's start with the cases:

 * Designated potable, as in from a city tap.
 * Designated non-potable, as in from a farm ditch, or purple pipe (USA).
 This would include designated irrigation water of most sorts.
 * Potable but with a known defect such as high mineral content.
 * Unspecified.  This may cover most backcountry springs where no testing
 is done, but no promises are made.
 * Compromised.  For example a muddy spring or clearly impacted water
 source usable only in dire emergencies.




 there are more types of water that might be interesting to people:

 - mineral water  http://en.wikipedia.org/wiki/Mineral_water
 - sparkling attribute (if it is naturally effervescent)
 - in Germany there is a subclass of mineral water (~healing water in
 German Heilwasser) which has positive physiologic effects.

 cheers,
 Martin

 ___
 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 - Water tap

[Kotya Karapetyan]

Mateusz, I agree. A mapper should never introduce, even by implication,
information he doesn't possess. This water is non-potable is very
different from I am not sure you can drink it. This is why I tend to go
for a generic water source tag with an additional potability
specification.

Taking into account everything said, I would propose:
1) To introduce a key water_source.
2) The values will be: potable, nonpotable, yes (or is potability_unknown
better?)
3) Deprecate amenity=drinking_water in favour of water_source=potable
4) All other related tags remain as is:
natural=spring
natural=water
amenity=water_point
man_made=water_well
waterway=water_point
and define the type of water source with more detail.
5) Man_made=water_tap can still be introduced, to accompany
man_made=water_well. However, the main purpose of this proposal is served
by the most general water_source tag.

I do understand that this goes somewhat out of the existing scheme. However:
- Can you propose a better solution, not just criticise the proposal
(criticism is very welcome, but please try to bring the discussion closer
to the agreement)?
- I think that the existing situation with the top-level
amenity=drinking_water is a rather poor solution, even if widely used.
Once again, please take into account that OSM was originally introduced in
developed countries, thus the established tagging system comes from their
realities. OSM is now gaining popularity in developing countries, and the
tagging system is bound to be dynamic if we don't want to end up with a
very low quality map (with either non-tagged features or with dozens of
custom or wrong tags). Also keep in mind that mappers from developing
countries are not extremely likely to participate in this English-language
discussion.

Finally, I would advocate the start of discussion to standardize the
tagging system, make it more uniform and thus mapper- and
consumer-friendly. Just keep it in mind please when considering this
specific proposal.

Cheers,
Kotya

On Thu, Nov 13, 2014 at 8:33 AM, Mateusz Konieczny matkoni...@gmail.com
wrote:

 If you can only chose between potable and non-potable - in this case
 tagging scheme is bad and should be changed to default to unknown value.

 2014-11-12 23:44 GMT+01:00 Warin 61sundow...@gmail.com:

  On 12/11/2014 8:34 PM, tagging-requ...@openstreetmap.org wrote:

 Message: 5
 Date: Wed, 12 Nov 2014 09:06:15 +0100
 From: Pieren pier...@gmail.com pier...@gmail.com
 To: Tag discussion, strategy and related tools
  tagging@openstreetmap.org tagging@openstreetmap.org
 Subject: Re: [Tagging] Tagging Digest, Vol 62, Issue 31
 Message-ID:
  capt3zjr3gsqafyxewxvnuyc2n_7tr-git3jpuortmauf2a1...@mail.gmail.com 
 capt3zjr3gsqafyxewxvnuyc2n_7tr-git3jpuortmauf2a1...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8

 On Wed, Nov 12, 2014 at 8:50 AM, Mateusz Konieczny matkoni...@gmail.com 
 matkoni...@gmail.com wrote:

   No, unknown should be tagged as unknown. Even better - not tagged.

  +1 We don't tag what is unknown. Pierre


 'We' know there is water there. That water can be used.

 If you can only chose between potable and non-potable, then you should
 chose non-potable. Filtering and treating non-potable water makes it
 potable .. I do this when in remote areas for my safety, particularly if
 I'm uncertain of the quality of the water. In some cases acess to water can
 be a life saver - thus it should be mapped no matter what the quality.

 =
 Note change in Subject title - my appoliges for my error there.

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



 ___
 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 - Water tap

[Kotya Karapetyan]

Bryce,

Thanks for your comments.

Tagging amenity=drinking_water + drinkable=no makes, at least, the WeTap
 Android application show a false source of drinkable water.
 It renders on many maps indistinguishable from potable water.


As I already said in the previous email, I think the only solution to such
situations is a tag standardization activity, clearly developed and
publicized. As long as tagging and tag documentation is completely free,
left to the logic and good will of each individual mapper, you cannot
expect the software to behave reasonably on each tag combination. The tag
combination you mention is an obvious conflict, but the software probably
cannot analyse each combination of tags, however clear it may be to a human.

Let's park this discussion for the moment.

*I see the breakdown:*

  amenity=drinking_water
 for dogs
 for filling bottles
 for humans without bottles

 amenity=fountain
Assumed decorative unless also tagged as drinking_water

 amenity=nonpotable_water
 with a hose size specified (e.g. MHT or GHT for the United States, BSP
 elsewhere)

 drinking_water=yes/no
 an attribute on something else, such as a campsite, cabin or toilet


OK, so where does a water tap with unknown water quality land in your
breakdown?


 Far better to use nonpotable_water.


A non-potable water introduces two problems:
1) a mapper may not know if the water is potable or not; there may be no
way to check it or he may not be able to do it; still adding a water source
is useful;
2) I don't like creating too many top-level tags. I could live with it,
however, as long as we don't have a better defined tagging system. But the
previous item is still an issue.


  nonpotable_water and drinking_water also have no overlap, which is
 good.
 drinking_water and water_tap overlap.


So what's your suggestion for a water source of unknown potability?


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

Re: [Tagging] Feature Proposal - RFC - Water tap

[Kotya Karapetyan]

Hi Martin and all,


On Mon, Oct 20, 2014 at 12:41 PM, Martin Koppenhoefer 
dieterdre...@gmail.com wrote:


 2014-10-18 23:20 GMT+02:00 Konstantin Karapetyan kotya.li...@gmail.com:

 I have already corrected the proposal from man_made to amenity following
 the suggestion at
 https://help.openstreetmap.org/questions/27869/how-to-tag-water-taps-not-intended-for-drinking-water.
 So this is fixed.



 IMHO this doesn't fix it, because it now becomes incompatible to be tagged
 on a node with amenity=drinking_water. If the value shall remain a generic
 water_tap I'd stick to man_made to keep these compatible (see also
 man_made=water_well for instance, which is a similar feature somehow).
 Please note that amenity=drinking_water is highly introduced and used by
 many data consumers. This is an established tag that is used for almost
 seven years now.


1) Looks like there is a divide between the proponents of the two options
(amenity and man_made). Honestly, I don't care because I see the need in
water_tap whatever category it falls into and because I think that the
whole OSM tagging system needs revision, so it is hard to find a good
solution. I see your point though. I have added it to the discussion page,
and during voting both options can be considered separately.

2) Your remark about high usage of amenity=drinking_water caused a long and
confusing chain of thoughts in my mind.

In principle, it is probably easy to automatically change any OSM tag in
the database. It looks like the best solution would be to have
amenity=water, drinkable=*, type=fountain|tap|water_well. However, we
cannot simply change the data, since the data consumers would then loose
this feature suddenly.

This makes me wonder: Is there any commitment or agreement between OSM and
third parties, that the tagging should be maintained in some form? I've
read that some big data users are correcting the OSM raw data, because it's
so, well... raw. To make it usable for navigation for example, they have to
do post-processing and close the gaps. I wonder what they do with
non-standard (although what is standard? let's say, less common) tags for
example.

A good solution in my opinion could lie in the direction of some form of
standardization work. A group of OSMers could form a working tagging
group and, say, once a year review the current tags and make sure that the
whole system is in good order (no obvious contradictions, everything well
documented, also for automatic use, the system is clear...). The data
consumers could then rely on the output of this working group and update
their software accordingly (and also plan the updates). Most importantly,
this group could not only clear up tagging (make some tags obsolete,
change/introduce categories and subtags etc.) but also issue
recommendations on *how* to tag: what combinations are recommended, what
should be avoided. The software authors could then make sure that the
programs support these recommendations (in the editors) or show the data in
the most appropriate way (in the viewers).

Open tagging system of OSM is vital because otherwise we wouldn't be able
to map a lot of things; our planet is very diverse, and this non-potable
water tap is a good example. However as it is, a lot of confusion exists,
which is especially bad for the beginners. Being unable to find the right
tags immediately, they map something somehow, reducing the overall data
quality. There is a couple of places where they can ask, but they may not
even know it. The experienced users may also contribute to the confusion,
since they have no restrictions to implement in the map whatever they deem
reasonable. The lack of proper review process prevents feedback.



 most cases I am aware of are indeed taps, because fountains are in the
 amenity namespace as well and will likely be tagged as such with
 drinkable=yes, a well would be man_made=water_well and could have
 amenity=drinking_water as combination (but there would be no need to
 clarify, it would already be clear that it is a well).


This is another good example to support my point 2 above: Why is a fountain
an amenity and a water-well a man_made? Isn't fountain man-made? Can't
we call a water-well a community facility (i.e. amenity as per
http://wiki.openstreetmap.org/wiki/Amenity)? Both can be debated, but an
agreement based on some organized discussion and a uniform approach
*throughout* the tagging system would be beneficial.

The wiki discussion page updated.

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

[Tagging] Review of water_tap proposal

[Kotya Karapetyan]

Dear all,

This is a kind reminder that the water_tap proposal (
http://wiki.openstreetmap.org/wiki/Proposed_features/water_tap) is in the
RFC stage at the moment. Please comment here or at the discussion page:
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/water_tap.

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

[Tagging] Feature Proposal - RFC - Water tap

[Kotya Karapetyan]

Dear all,

I would hereby like to propose a new value for the man_made tag:

man_made=water_tap

The proposal page is:
http://wiki.openstreetmap.org/wiki/Proposed_features/water_tap

Thanks for comments in advance!

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