Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Mateusz Konieczny]

23 May 2019, 01:15 by tagging@openstreetmap.org:

>   I find it strange/worrying he makes these far reaching decisions
> unilaterally
>
Note that JOSM also is doing this but in cases of unwanted or broken validation
it gets fixed/changed/rolled back.

I think that main difference between JOSM validation (that is not causing 
repeated complaints, 
at least on this mailing list) and iD validation is that JOSM devs have no 
trouble 
with reverting or fixing changes that are not actually wanted (or are better on 
judging what 
is wanted by community).

I think it is fine to make such changes without checking every single one with 
wider community, 
as long as unwanted ones get rolled back.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Martin Koppenhoefer]

sent from a phone

> On 22. May 2019, at 21:16, Nick Bolten  wrote:
> 
> Ah, I see. Would you envision the only value for crossing:markings be "no", 
> or would it potentially have yes/no/{type}, where mappers use it at their 
> discretion - such as in this example?


yes/no/type 
preferably no/{type}


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

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Martin Koppenhoefer]

sent from a phone

> On 23. May 2019, at 09:21, Mateusz Konieczny  wrote:
> 
> I think that main difference between JOSM validation (that is not causing 
> repeated complaints, 
> at least on this mailing list) and iD validation is that JOSM devs have no 
> trouble 
> with reverting or fixing changes that are not actually wanted (or are better 
> on judging what 
> is wanted by community).


a big difference is that in Josm there is a team, where different opinions can 
be discussed, while in iD it is Bryan who has the whole burden on his shoulders 
to decide alone about raised issues.

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

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Tobias Zwick]

I like your wording. It is a burden. He also takes all the complaints for bugs 
and when iD steps on someone's shoes. This is a very stressful position to be 
in.

Am 23. Mai 2019 09:38:06 MESZ schrieb Martin Koppenhoefer 
:
>
>
>sent from a phone
>
>> On 23. May 2019, at 09:21, Mateusz Konieczny
> wrote:
>> 
>> I think that main difference between JOSM validation (that is not
>causing repeated complaints, 
>> at least on this mailing list) and iD validation is that JOSM devs
>have no trouble 
>> with reverting or fixing changes that are not actually wanted (or are
>better on judging what 
>> is wanted by community).
>
>
>a big difference is that in Josm there is a team, where different
>opinions can be discussed, while in iD it is Bryan who has the whole
>burden on his shoulders to decide alone about raised issues.
>
>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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Mateusz Konieczny]

This is a change on the OSM website that updates iD version so all changes are 
bundled as one.

For more gradual commits/issues see https://github.com/openstreetmap/iD


23 May 2019, 01:39 by graemefi...@gmail.com:

>
>
> On Thu, 23 May 2019 at 09:10, marc marc <> marc_marc_...@hotmail.com 
> > > wrote:
>
>>
>> I may have missed the last iD update announcement announcing this,
>>  what this transparent or discovered by chance?
>>
>
> This one, which includes heaps of changes!?
>
> https://github.com/openstreetmap/openstreetmap-website/pull/2231 
> 
>  
> Thanks
>
> Graeme
>

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

Re: [Tagging] Definition of Sport

[Mateusz Konieczny]

23 May 2019, 01:26 by 61sundow...@gmail.com:

> So there are various definitions. Which one should OSM use? 
>
I would rather ask which one OSM is using now.


>From mentioned following seems to fit quite well:

1. an activity pursued for exercise or pleasure, usually requiring some degree 
of physical prowess


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

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Markus]

I agree that adding highway=footway to platforms is not only
redundant, but (as pointed out by Michael) is bad because platforms
often have different access restrictions than highway=footway. iD's
validation rule should be removed.

Regards

Markus

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

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Dave F via Tagging]

Don't you think, with his refusal to participate in discussions about 
raised issues, that it's often self inflicted?


On a couple of occasions he's said he ignores these forums & note how 
often github threads are instantaneously closed.


DaveF

On 23/05/2019 09:16, Tobias Zwick wrote:

I like your wording. It is a burden. He also takes all the complaints for bugs 
and when iD steps on someone's shoes. This is a very stressful position to be 
in.

Am 23. Mai 2019 09:38:06 MESZ schrieb Martin Koppenhoefer 
:


sent from a phone


On 23. May 2019, at 09:21, Mateusz Konieczny

 wrote:

I think that main difference between JOSM validation (that is not

causing repeated complaints,

at least on this mailing list) and iD validation is that JOSM devs

have no trouble

with reverting or fixing changes that are not actually wanted (or are

better on judging what

is wanted by community).


a big difference is that in Josm there is a team, where different
opinions can be discussed, while in iD it is Bryan who has the whole
burden on his shoulders to decide alone about raised issues.

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] Opening hours syntax for non Gregorian calendar

[Philip Barnes]

On Thursday, 23 May 2019, Paul Allen wrote:
> On Thu, 23 May 2019 at 00:06, Graeme Fitzpatrick 
> wrote:
> 
> >
> > But what are Christmas & Easter if they're not religious holidays? :-)
> >
> 
> Not all religious holidays are created equal.  Many cafes and restaurants
> in tourist areas are
> closed on Christmas Day/Boxing day but are open on Good Friday/Easter
> Monday.
Easter Monday is not actually a religious holiday, its only the day off in-lieu 
of Easter Sunday being a none working day.

Good Friday in the Midlands at least is not equal, many businesses such as many 
factories are open and buses run a normal service. There are no buses here on a 
normal bank holiday Monday.

Phil (trigpoint) 

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - rejected - camp_site=camp_pitch

[marc marc]

Le 23.05.19 à 12:22, Joseph Eisenberg a écrit :
>> tourism=camp_pitch (not because I like this, but because fixing one issue 
>> (avoid conflit with tourism=camp_site + 
>> camp_site=basic/standard/serviced/deluxe) is better than fixing none of them.

> Please do not retag features to an unapproved, undocumented tag.

no coherent documented tag exist for pitch, what do you propose ?
freeze until an approved proposal ?
some propals are outstanding since years

we hesitate to create/document new/temporary tags
for the 2 usecases discovered so far.
we thought, however, that this would add further confusion
to the confusion given the too many proposals and different
tags for the same thing.
which would result in https://imgs.xkcd.com/comics/standards.png
it will not be an issue to tag them with the final schema when it exists

> Mechanical edits are discouraged, even if you are doing them by hand.

we didn't made a mechanical edits, we have loaded them,
check the context, check imagery, check other tag.
it's how 2 differents usecase have been found.

> I'd be willing to make a proposal page for tourism=camp_pitch 
> it sounds like you don't actually like this tag?

right now I think the situation is too confusing
how do you decide the meaning of current tourism=camp_pitch objects? 
it's impossible without reviewing a large number of them to see what 
they correspond to. it's the goal of our approach. except that
we didn't just look, we improved what we thought could be easily
improved (toilets, entrances, camp_site=* approved meaning, ...)
no one imagined anyone would disapprove that...

but I'll pass on your opinion that you don't like our use
of tourism=camp_pitch until it's voted on.
we can create/modify wiki page with all the different meanings 
encountered for every tag if you want, I think however that documenting 
the magnitude of the problem will be an additional argument against
what seemed to be the only solution, if done step-by-step, with human
review due to the multi-meaning that currently exist in all tag/value.

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

Re: [Tagging] ID is not a king and final arbiter of OSM (was: iD adding highway=footway to all railway/public_transport=platform ways and relations)

[Mateusz Konieczny]

Though repeated attempts by @bhousel and @quincylvania to declare themselves as 
final arbiters of OSM tagging and dismissing everybody else is certainly not 
helping. 

That is really not going to work, and it is a pity because plenty of work done 
of him is really great
but it is tainted by ignoring arguments of critics. No one is right all the 
time.

To directly quote part of
https://github.com/openstreetmap/iD/issues/6409#issuecomment-495231649 


"Some things that don't really factor at all into our decision:

    how long a tag with implicit semantics has been in use
    how many softwares (renderers / routers or whatever) already support the 
implicit rule
    how frequently the tag is used
    what a handful of people on a mostly dormant mailing list think
    what one person has written on the osm wiki
    how many downvotes you encourage people to put on our issue list
    what they are saying about us in the weekly osm tabloid"
So someone is dismissing what everybody else thinks and at the same time 
expects everybody
to accept his own opinions?

Some ideas from tagging mailing list and OSM wiki (even after limiting to 
popular ones
or "approved") are pointless/harmful but that is not a valid reason to simply 
ignore all of them.

23 May 2019, 10:16 by o...@westnordost.de:

> I like your wording. It is a burden. He also takes all the complaints for 
> bugs and when iD steps on someone's shoes. This is a very stressful position 
> to be in.
>
>

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

Re: [Tagging] Opening hours syntax for non Gregorian calendar

[Andy Mabbett]

On Wed, 22 May 2019 at 13:31, Paul Allen  wrote:

> The problem with that is the same problem as allowing every language on the 
> planet to
> use their own abbreviations for month names.  Only worse.
>
> For better or worse, we standardized on three-letter abbreviations for 
> English month names.
> opening_hours to keep things simple and to prevent a problem in one affecting 
> all of them.

If only there was some sort of ISO standard for representing dates...

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Tagging a site with "Luxury Lodges"

[Clifford Snow]

I the US we call them manufactured homes. They are trucked to the site,
often split lengthwise into two pieces. Once on site, they place them on a
foundation then remove the wheels from underneath. Most are relatively
inexpensive to purchase. The real money make is the owner of the land that
rents out the tiny lot.

These communities can be a mix of mobile home, aka caravans, and
manufactured homes. From aerial imagery the individual units the only real
difference is usually the roof. Manufactured home may have a peaked roof
where the mobile homes are usually flat.

I've tagged both a building=static_caravan

Best,
Clifford

On Thu, May 23, 2019 at 2:56 AM Paul Allen  wrote:

> On Thu, 23 May 2019 at 06:41, Martin Koppenhoefer 
> wrote:
>
>>
>> While they might be called „house“, why not „building=lodge“? The fact
>> they are poorly insulated, prefabricated wooden single floor structures is
>> better reflected by that word.
>>
>
> building=luxury_shanty
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

That's not an example of a trick question, just a normal question with
clear implications. I'd be happy to see examples of linear platform
features that aren't footways and have my intuition proven incorrect.

Are there any other outdoor linear features with primary pedestrian access
that aren't footways?

On Thu, May 23, 2019, 9:35 AM Jmapb  wrote:

> On 5/23/2019 12:26 PM, Nick Bolten wrote:
> > I'm confused, because these two statements seem incompatible. If it's
> > redundant, how can it also have a conflict like different address
> > restrictions? I'd like to know how, as a data consumer, I should
> > reliably interpret existing platforms without the tag added by iD.
> >
> > Taking a step back, can anyone name an instance where a linear transit
> > platform is not a footway?
>
> This reads like a trick question.
>
> - "All platforms are, in some sense, footways."
> - "So we should tag them as footways!"
>
> or
>
> - "Here's an example of a weird platform that certainly isn't a footway!"
> - "Aha, interesting! Clearly this shows the necessity of tagging the
> *other* 100,000 platforms as footways, to show the difference!"
>
> J
>
>
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

The only coherent rule I can surmise based on how footways are mapped "in
the wild" is that it's an outdoor linear feature and it's primarily
intended for pedestrians. Linear transit platforms people walk to, from,
and on seem to fit the other uses of the tag, hence my questions.

The rendering example posted earlier is a good example where it seems an
awful lot like a footway and a platform at the same time. Perhaps the
platform should be a polygon and the path to and on it a footway?

On Thu, May 23, 2019, 9:56 AM Andy Townsend  wrote:

> On 23/05/2019 17:45, Tobias Zwick wrote:
> > "Redundant" is perhaps not the best way to describe the problem. I'd go
> about this like this:
> >
> > A "highway=footway" is a footway, a "public_transport=platform" is a bus
> stop (platform). These are simply two different things. They *share*
> certain properties, for example, they are accessible both by pedestrians,
> but that does not make a bus stop platform a footway.
> > Giving an extreme example: Paved brownfields and parking lots are not
> footways. But following the argument of the iD developers, they probably
> should.
> >
> That's an excellent summary.  I can think of a few railway platforms
> that also form part of footpath routes, but must do not.  Having an
> editor automatically add "highway=footway" to all platforms devalues the
> work of all those who've used the tag explicitly in the past.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

I'm confused, because these two statements seem incompatible. If it's
redundant, how can it also have a conflict like different address
restrictions? I'd like to know how, as a data consumer, I should reliably
interpret existing platforms without the tag added by iD.

Taking a step back, can anyone name an instance where a linear transit
platform is not a footway?

On Thu, May 23, 2019, 12:49 AM Markus  wrote:

> I agree that adding highway=footway to platforms is not only
> redundant, but (as pointed out by Michael) is bad because platforms
> often have different access restrictions than highway=footway. iD's
> validation rule should be removed.
>
> Regards
>
> Markus
>
> ___
> 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] ID is not a king and final arbiter of OSM (was: iD adding highway=footway to all railway/public_transport=platform ways and relations)

[Tobias Zwick]

I simply have the feeling that we are heading straight for an escalation course 
here. I already see it looming that some day the plug might be pulled on iD 
(being hosted on openstreetmap.org) and I really really don't want this to 
happen, lest even to think about it makes me sick.

Undoubtedly, the developers behavior is not helping there. I have the 
impression that they have almost given up on the OSM community. But this 
doesn't come out of nowhere.  I think it is important to understand their side 
of the story if we were to reverse this development.

I had to rewrite this last paragraph several times, but, well, I hope this does 
not come across the wrong way...
it can certainly not continue like this, so ... why not interview him, honestly 
and with open outcome, how should the collaboration and communication in OSM 
happen in the future from his point of view? Would he rather feel relieved or 
rather feel betrayed if the gatekeeping (~deployment) is done by other people? 
Does he really feel alienated (because I assumed it) from the community and if 
yes, why? And most importantly, what would it take to reverse this? 

Tobias

On 23/05/2019 17:15, Mateusz Konieczny wrote:
> Though repeated attempts by @bhousel and @quincylvania to declare themselves 
> as
> final arbiters of OSM tagging and dismissing everybody else is certainly not 
> helping.
> 
> That is really not going to work, and it is a pity because plenty of work 
> done of him is really great
> but it is tainted by ignoring arguments of critics. No one is right all the 
> time.
> 
> To directly quote part of
> https://github.com/openstreetmap/iD/issues/6409#issuecomment-495231649
> 
> "Some things that don't really factor at all into our decision:
> 
>     how long a tag with implicit semantics has been in use
>     how many softwares (renderers / routers or whatever) already support the 
> implicit rule
>     how frequently the tag is used
>     what a handful of people on a mostly dormant mailing list think
>     what one person has written on the osm wiki
>     how many downvotes you encourage people to put on our issue list
>     what they are saying about us in the weekly osm tabloid"
> 
> So someone is dismissing what everybody else thinks and at the same time 
> expects everybody
> to accept his own opinions?
> 
> Some ideas from tagging mailing list and OSM wiki (even after limiting to 
> popular ones
> or "approved") are pointless/harmful but that is not a valid reason to simply 
> ignore all of them.
> 
> 23 May 2019, 10:16 by o...@westnordost.de:
> 
> I like your wording. It is a burden. He also takes all the complaints for 
> bugs and when iD steps on someone's shoes. This is a very stressful position 
> to be in.
> 
> 
> 
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Tobias Zwick]

"Redundant" is perhaps not the best way to describe the problem. I'd go about 
this like this:

A "highway=footway" is a footway, a "public_transport=platform" is a bus stop 
(platform). These are simply two different things. They *share* certain 
properties, for example, they are accessible both by pedestrians, but that does 
not make a bus stop platform a footway.
Giving an extreme example: Paved brownfields and parking lots are not footways. 
But following the argument of the iD developers, they probably should.

Tobias

On 23/05/2019 18:26, Nick Bolten wrote:
> I'm confused, because these two statements seem incompatible. If it's 
> redundant, how can it also have a conflict like different address 
> restrictions? I'd like to know how, as a data consumer, I should reliably 
> interpret existing platforms without the tag added by iD.
> 
> Taking a step back, can anyone name an instance where a linear transit 
> platform is not a footway?
> 
> On Thu, May 23, 2019, 12:49 AM Markus  > wrote:
> 
> I agree that adding highway=footway to platforms is not only
> redundant, but (as pointed out by Michael) is bad because platforms
> often have different access restrictions than highway=footway. iD's
> validation rule should be removed.
> 
> Regards
> 
> Markus
> 
> ___
> 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] ID is not a king and final arbiter of OSM

[marc marc]

Le 23.05.19 à 18:32, Tobias Zwick a écrit :
> what would it take to reverse this?

what may help in to keep some thread here on topic and make a summary at 
the end of a long thread... or maybe always made a summary like
subject : [solved] previous subject
a short summary

I am even someone who writes messages that are too long. so I understand 
that not everyone necessarily wants or has the time to read the hundreds 
of messages on some topics spread over several months

the last problem is that some dev (but also some users of a publisher) 
have to accept that sometimes discussing a problem will not be done in a 
few hours.
a community project does not have the same tempo as managing a bug by 
deciding on its own
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Tagging buildings that people work in

[ET Commands]

In the course of my mapping I sometimes encounter buildings that I know 
people work in, but I don't know what kind of business is being 
conducted in the building.  These buildings could contain offices, or 
medical facilities, or factories, or warehouses, or retail, or just 
about anything else, other than storage buildings or abandoned buildings 
or something like that, where people are not normally present.  (Of 
course this is somewhat subjective, I realize.)  To distinguish these 
buildings from the ones that are tagged with "building=yes" I like to 
use a different tag.  I have been using "building=occupied" for lack of 
a better tag.  This tag, of course, is meant to be temporary until 
someone determines the proper nature of the use of the building.  In the 
meantime, this helps to distinguish "occupied" buildings on maps from 
generic ones.  What do you think?


Mark


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

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Jmapb]

On 5/23/2019 12:26 PM, Nick Bolten wrote:

I'm confused, because these two statements seem incompatible. If it's
redundant, how can it also have a conflict like different address
restrictions? I'd like to know how, as a data consumer, I should
reliably interpret existing platforms without the tag added by iD.

Taking a step back, can anyone name an instance where a linear transit
platform is not a footway?


This reads like a trick question.

- "All platforms are, in some sense, footways."
- "So we should tag them as footways!"

or

- "Here's an example of a weird platform that certainly isn't a footway!"
- "Aha, interesting! Clearly this shows the necessity of tagging the
*other* 100,000 platforms as footways, to show the difference!"

J


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

Re: [Tagging] ID is not a king and final arbiter of OSM

[Jmapb]

On 5/23/2019 12:32 PM, Tobias Zwick wrote:

Undoubtedly, the developers behavior is not helping there. I have the 
impression that they have almost given up on the OSM community. But this 
doesn't come out of nowhere.  I think it is important to understand their side 
of the story if we were to reverse this development.


Would anyone care to summarize the developers' side of the story? Maybe,
I dunno, one of the iD developers?

J

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

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

Ah, I see! That all makes sense.

On Thu, May 23, 2019, 10:42 AM Markus  wrote:

> On Thu, 23 May 2019 at 18:28, Nick Bolten  wrote:
> >
> > I'm confused, because these two statements seem incompatible. If it's
> redundant, how can it also have a conflict like different address
> restrictions? I'd like to know how, as a data consumer, I should reliably
> interpret existing platforms without the tag added by iD.
>
> Please excuse the bad wording. I meant that even if platforms had the
> same access restrictions as footways, they should not additionally be
> tagged highway=footway, because this were redundant. But as platforms
> often have different access restrictions (e.g. you cannot enter w/o a
> ticket), adding highway=footway is conflicting.
>
> Regards
>
> Markus
>
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Allroads]

For me it is highway=platform, ID, is doing it wrong.

In a discussion, I drawn out a visualisation.

https://i.postimg.cc/wxJcG6bH/bushaltehaltekominvulling1.png

Allroads.

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

Re: [Tagging] ID is not a king and final arbiter of OSM

[Dave F via Tagging]

If they'd wanted to do that the github thread wouldn't have been locked.

He's never been good at taking criticism.

He confesses *all* responses will be critical, but still thinks he's right.

DaveF

On 23/05/2019 18:26, Jmapb wrote:

On 5/23/2019 12:32 PM, Tobias Zwick wrote:
Undoubtedly, the developers behavior is not helping there. I have the 
impression that they have almost given up on the OSM community. But 
this doesn't come out of nowhere.  I think it is important to 
understand their side of the story if we were to reverse this 
development.


Would anyone care to summarize the developers' side of the story? Maybe,
I dunno, one of the iD developers?

J

___
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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[marc marc]

Le 23.05.19 à 18:26, Nick Bolten a écrit :
> I'd like to know how, as a data consumer, I should reliably interpret 
> existing platforms without the tag added by iD.

without explicit value, it is impossible to say whether the platforms
is a public path, a public footway, or none of them.

improving this situation would be :

in a editor :
- if a highway crosses the polygon of a platform in the wanted 
direction, don't ask for access on it, use that highway
- otherwise, editor can ask the user: does a sign restrict access?
if so, enter the value access
- otherwise, do not add anything to osm, don't map the legislation
on each osm object !

for data consumer :
- use a default value depending on the country (in some countries you 
can walk, in other countries you can walk with a dismounted bike,
in others you can stay on your bike)
- a good well formated wiki page and/or a type=default relation help
to have access to the data need for a preprocessor.
- pooling contributions/code/rules to make a preprocessor that add
in legislation on osm objects of a pdb could make sense

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

Re: [Tagging] Tagging buildings that people work in

[marc marc]

Le 23.05.19 à 18:57, ET Commands a écrit :
> building=occupied

building=* is about what the building look like
a industrial-look building with a residential use, is still a 
industrial-look and is mapped with :
building=industrial building:use=residential

following that, building=yes building:use=yes is better
yes can be improved when you'll known that's the current use,
if it not the same as what is excepted for this building look
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Tobias Zwick]

I'd say so. 

On 23/05/2019 19:03, Nick Bolten wrote:
> So would it be fair to say that a linear *=platform implies foot=yes and can 
> be tagged with reasonable tags for a footway such as width, incline, surface, 
> tactile paving, etc?
> 
> On Thu, May 23, 2019, 9:46 AM Tobias Zwick  > wrote:
> 
> "Redundant" is perhaps not the best way to describe the problem. I'd go 
> about this like this:
> 
> A "highway=footway" is a footway, a "public_transport=platform" is a bus 
> stop (platform). These are simply two different things. They *share* certain 
> properties, for example, they are accessible both by pedestrians, but that 
> does not make a bus stop platform a footway.
> Giving an extreme example: Paved brownfields and parking lots are not 
> footways. But following the argument of the iD developers, they probably 
> should.
> 
> Tobias
> 
> On 23/05/2019 18:26, Nick Bolten wrote:
> > I'm confused, because these two statements seem incompatible. If it's 
> redundant, how can it also have a conflict like different address 
> restrictions? I'd like to know how, as a data consumer, I should reliably 
> interpret existing platforms without the tag added by iD.
> >
> > Taking a step back, can anyone name an instance where a linear transit 
> platform is not a footway?
> >
> > On Thu, May 23, 2019, 12:49 AM Markus    >> wrote:
> >
> >     I agree that adding highway=footway to platforms is not only
> >     redundant, but (as pointed out by Michael) is bad because platforms
> >     often have different access restrictions than highway=footway. iD's
> >     validation rule should be removed.
> >
> >     Regards
> >
> >     Markus
> >
> >     ___
> >     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
> 
> 
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Dave F via Tagging]

Please see the discussion on the Transit forum.
Platform should only be tagged when their is a *physical* object of a 
raise platform, not just an imaginary area of pavement.


From OSM's Welcome page:
"OpenStreetMap is a place for mapping things that are both /real and 
current/ "

"What it /doesn't/ include is... hypothetical features"

There is a call to greatly simplify the ever expanding, confusing public 
transport schema. This ID proposal only muddies the waters further.


DaveF

On 23/05/2019 18:49, Allroads wrote:

For me it is highway=platform, ID, is doing it wrong.

In a discussion, I drawn out a visualisation.

https://i.postimg.cc/wxJcG6bH/bushaltehaltekominvulling1.png

Allroads.




___
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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Jo]

a platform, whether tagged as public_transport=platform, highway=platform
or railway=platform is always accessible and routeable for pedestrians. So
no need to explicitly tag them with highway=footway or foot=yes or
something of that nature.

Polyglot

On Thu, May 23, 2019 at 6:28 PM Nick Bolten  wrote:

> I'm confused, because these two statements seem incompatible. If it's
> redundant, how can it also have a conflict like different address
> restrictions? I'd like to know how, as a data consumer, I should reliably
> interpret existing platforms without the tag added by iD.
>
> Taking a step back, can anyone name an instance where a linear transit
> platform is not a footway?
>
> On Thu, May 23, 2019, 12:49 AM Markus  wrote:
>
>> I agree that adding highway=footway to platforms is not only
>> redundant, but (as pointed out by Michael) is bad because platforms
>> often have different access restrictions than highway=footway. iD's
>> validation rule should be removed.
>>
>> Regards
>>
>> Markus
>>
>> ___
>> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Andy Townsend]

On 23/05/2019 17:45, Tobias Zwick wrote:

"Redundant" is perhaps not the best way to describe the problem. I'd go about 
this like this:

A "highway=footway" is a footway, a "public_transport=platform" is a bus stop 
(platform). These are simply two different things. They *share* certain properties, for example, 
they are accessible both by pedestrians, but that does not make a bus stop platform a footway.
Giving an extreme example: Paved brownfields and parking lots are not footways. 
But following the argument of the iD developers, they probably should.

That's an excellent summary.  I can think of a few railway platforms 
that also form part of footpath routes, but must do not.  Having an 
editor automatically add "highway=footway" to all platforms devalues the 
work of all those who've used the tag explicitly in the past.


Best Regards,

Andy



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

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

So would it be fair to say that a linear *=platform implies foot=yes and
can be tagged with reasonable tags for a footway such as width, incline,
surface, tactile paving, etc?

On Thu, May 23, 2019, 9:46 AM Tobias Zwick  wrote:

> "Redundant" is perhaps not the best way to describe the problem. I'd go
> about this like this:
>
> A "highway=footway" is a footway, a "public_transport=platform" is a bus
> stop (platform). These are simply two different things. They *share*
> certain properties, for example, they are accessible both by pedestrians,
> but that does not make a bus stop platform a footway.
> Giving an extreme example: Paved brownfields and parking lots are not
> footways. But following the argument of the iD developers, they probably
> should.
>
> Tobias
>
> On 23/05/2019 18:26, Nick Bolten wrote:
> > I'm confused, because these two statements seem incompatible. If it's
> redundant, how can it also have a conflict like different address
> restrictions? I'd like to know how, as a data consumer, I should reliably
> interpret existing platforms without the tag added by iD.
> >
> > Taking a step back, can anyone name an instance where a linear transit
> platform is not a footway?
> >
> > On Thu, May 23, 2019, 12:49 AM Markus  > wrote:
> >
> > I agree that adding highway=footway to platforms is not only
> > redundant, but (as pointed out by Michael) is bad because platforms
> > often have different access restrictions than highway=footway. iD's
> > validation rule should be removed.
> >
> > Regards
> >
> > Markus
> >
> > ___
> > 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Markus]

On Thu, 23 May 2019 at 18:28, Nick Bolten  wrote:
>
> I'm confused, because these two statements seem incompatible. If it's 
> redundant, how can it also have a conflict like different address 
> restrictions? I'd like to know how, as a data consumer, I should reliably 
> interpret existing platforms without the tag added by iD.

Please excuse the bad wording. I meant that even if platforms had the
same access restrictions as footways, they should not additionally be
tagged highway=footway, because this were redundant. But as platforms
often have different access restrictions (e.g. you cannot enter w/o a
ticket), adding highway=footway is conflicting.

Regards

Markus

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

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Mateusz Konieczny]

23 May 2019, 18:32 by o...@westnordost.de:

> reverse this development.
>
Yes, it would be great. There is plenty of negative emotion on both sides and it
would be great to reverse this (for example title that I used was frankly stupid
what I realized after sending the message).

> I had to rewrite this last paragraph several times, but, well, I hope this 
> does not come across the wrong way...
> it can certainly not continue like this, so ... why not interview him, 
> honestly and with open outcome, how should the collaboration and 
> communication in OSM happen in the future from his point of view? Would he 
> rather feel relieved or rather feel betrayed if the gatekeeping (~deployment) 
> is done by other people? Does he really feel alienated (because I assumed it) 
> from the community and if yes, why? And most importantly, what would it take 
> to reverse this?
>
+1, though it would be tricky to find someone both interested in doing this, 
with time to do that,
and not already involved in a poor way
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

That segment of platform by the bus shelter is both a footway and a
platform. In many scenarios, the "platform" might be distinguished by
nothing but some paint on a curb - clearly it's just a part of the sidewalk
where a bus stops.

We shouldn't ask mappers to decide how platform-ie or footway-ie that
segment of infrastructure is and only choose one based on subjective
priorities: they should be able to clearly describe both simultaneously.

highway=platform effectively rules out highway=footway, hence the conflict.

I have never seen *=platform features consumed for any purpose other than
being a destination in routing software. Does anyone have examples of other
use cases?

On Thu, May 23, 2019, 10:50 AM Allroads  wrote:

> For me it is highway=platform, ID, is doing it wrong.
>
> In a discussion, I drawn out a visualisation.
>
> https://i.postimg.cc/wxJcG6bH/bushaltehaltekominvulling1.png
>
> Allroads.
>
>
> ___
> 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] solving iD conflict (was: pointlessly inflamatory title)

[Valor Naram]

> +1, though it would be tricky to find someone both interested in doing this, with time to do that, and not already involved in a poor wayI can do that but I am not quite sure about my social skills. But I will take it seriously as I always do when I am moderating or organising.CheersSören alias Valor Naram Original Message Subject: Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)From: Mateusz Konieczny To: CC: "Tag discussion, strategy and related tools" 
  

  
  
23 May 2019, 18:32 by o...@westnordost.de:reverse this development.Yes, it would be great. There is plenty of negative emotion on both sides and itwould be great to reverse this (for example title that I used was frankly stupidwhat I realized after sending the message).I had to rewrite this last paragraph several times, but, well, I hope this does not come across the wrong way...it can certainly not continue like this, so ... why not interview him, honestly and with open outcome, how should the collaboration and communication in OSM happen in the future from his point of view? Would he rather feel relieved or rather feel betrayed if the gatekeeping (~deployment) is done by other people? Does he really feel alienated (because I assumed it) from the community and if yes, why? And most importantly, what would it take to reverse this?+1, though it would be tricky to find someone both interested in doing this, with time to do that,and not already involved in a poor way  

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

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Graeme Fitzpatrick]

On Fri, 24 May 2019 at 04:49, Dave F via Tagging 
wrote:

>
> Platform should only be tagged when their is a *physical* object of a
> raise platform, not just an imaginary area of pavement.
>

Sorry, but do you mean that this:
https://www.google.com/maps/@-28.0841684,153.4150288,3a,75y,46.69h,72.55t/data=!3m6!1e1!3m4!1s4hTF-eOoQp3yhcCIfyJelw!2e0!7i13312!8i6656
is *not* a public_transport=platform, which iD defines highway=bus_stop as?

If not, then what is it?

Thanks

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

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Jo]

Indeed not a platform, just a bus stop with a bench and maybe a shelter,
not sure. If the kerb were a bit higher where the bus halts, I'd say
platform, but this is just a sidewalk.
That we map such a node with public_transport=platform/bus=yes doesn't make
it a platform. That's just convention since the PT v2 scheme appeared.

Polyglot

On Fri, May 24, 2019 at 12:20 AM Graeme Fitzpatrick 
wrote:

>
>
> On Fri, 24 May 2019 at 04:49, Dave F via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>> Platform should only be tagged when their is a *physical* object of a
>> raise platform, not just an imaginary area of pavement.
>>
>
> Sorry, but do you mean that this:
> https://www.google.com/maps/@-28.0841684,153.4150288,3a,75y,46.69h,72.55t/data=!3m6!1e1!3m4!1s4hTF-eOoQp3yhcCIfyJelw!2e0!7i13312!8i6656
> is *not* a public_transport=platform, which iD defines highway=bus_stop
> as?
>
> If not, then what is it?
>
> Thanks
>
> Graeme
> ___
> 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 buildings that people work in

[Warin]

On 24/05/19 10:24, Kevin Kenny wrote:

On Thu, May 23, 2019 at 1:07 PM marc marc  wrote:

following that, building=yes building:use=yes is better
yes can be improved when you'll known that's the current use,
if it not the same as what is excepted for this building look

I'm even fine with 'building=yes note=*'. A data consumer isn't likely
to be able to do much with any invented tagging for the partial
information - a note is about as good as any kind of structured data
here.


Good idea - use of the tag note=* should attract attention of other mappers and 
they might be able to improve the tagging.


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

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Nick Bolten]

> Every person on this mailing list participates in many of these kinds of
discussions (...)

I have never seen one where there was someone suggesting a change to a tag
and at least some of those negative bullet points didn't apply.

> I think you should attempt to apply a little of that "acknowledging the
other point of view" (...)

I understand becoming frustrated with repetition and bad data. That
frustration should be channeled into fixing the UX problem that leads to
it, such as discoverability of import documents. I don't understand the
habit of lashing out at new members and/or new ideas, given the goal of
making a community-focused project.

> That is often repeated and I guess most people can confirm that people
act differently in person than on mailing lists.

I've also communicated via direct emails and via slack. This is the only
place where it gets toxic almost immediately.

> if you go around telling everyone what a snake pit "the mailing lists"
are then people will either not join them, or join them just waiting to see
their expectations confirmed.

I've personally talked to more people who avoid the mailing lists,
particularly this one, than those who generally respond here. The sentiment
is popular and it's not great for community building.

> In general, our project isn't a top-down strictly managed project with a
controlled decision-making process. This means that many things have to
be discussed over and over, and the community generally doesn't speak with
one voice.

This is how it should theoretically work. I don't think it's how it
actually works. It's driven by editing software and targeted mapping
efforts, not mailing list discussions of which most mappers are unaware.

But I don't mind discussing things over and over - that wasn't one of the
negatives list.

> Now you're going off on a tangent. Passwords are not required at all to
use the mailing list.

Serious technical issues with the mailing list isn't a tangent, the topic
is mailing list vs. an editor's decisions. It undermines the credibility of
this mailing list when its use involves terrible security practices.
Registering for the mailing list, which is required for real-time
participation, sends passwords in plain text. This is a massive security
issue and the entire process feels unprofessional and dodgy. When I've
recommended subscribing to others, I always remind them of this problem.

> The current forum system works and has moderators and etiquette
guidelines (this depends on each sub-forum, they are not global).
Discoverability isn't much better than mailing lists IMHO.

Discoverability is very bad all over the place for OSM - there is a
desperate need for a "get involved" link on the landing page that orients
the community.

But discoverability is far better for the forums than here, as they are
crawled by search engines. Whenever I see someone suggest reviewing a
discussion from 9 months ago, I'm reminded of Douglas Adams: "It was on
display in the bottom of a locked filing cabinet stuck in a disused
lavatory with a sign on the door saying ‘Beware of the Leopard.'"

Anywho, I think the length of my replies have distracted from my point:
what is the goal of this mailing list and how do these threads serve it,
given these behaviors? Surely there is a better way to collaborate.

On Thu, May 23, 2019 at 4:39 PM Frederik Ramm  wrote:

> Hi,
>
> On 5/23/19 21:58, Nick Bolten wrote:
> > OSM needs an alternative for community tagging discussions outside of
> > these mailing lists.
>
> It might; that doesn't invalidate points made on these mailing lists
> though!
>
> > # My experiences with OSMers in other contexts:
> > - Very friendly, all focused on making maps better, highly motivated to
> > donate their time to help others via the map.
> > - Disagreements are pleasant. Both sides acknowledge the other point of
> > view and usually come around to a compromise.
> > - There is interest in knowing more: lots of questions back and forth.
> > - Objections are qualified and polite.
> > - 10s-100s of people giving feedback on a single idea.
>
> Every person on this mailing list participates in many of these kinds of
> discussions, in addition to being on the mailing list (just in case you
> were thinking there were two different kinds of people, the friendly
> people and the mailing list people; this is not the case).
>
> > When I was mentoring a group of students a few years ago, several were
> > offended by the condescending and insulting responses they received on
> > this mailing list, all because they suggested making a coherent way of
> > combining existing tags into a pedestrian schema and doing a
> > carefully-vetted import.
>
> I think you should attempt to apply a little of that "acknowledging the
> other point of view" that you lauded above to such situations. Every day
> brings new broken imports to OpenStreetMap. All of them are done with
> the best intentions. Very many of them are done by people with little
> 

Re: [Tagging] solving iD conflict

[marc marc]

Hello,

Le 23.05.19 à 21:58, Nick Bolten a écrit :
> My experience with this mailing list:

the current situation have several issues, indeed
but I think you should confuse this mailing with somewhere else,
because I don't recognize the majority of abstract examples
you're talking about.

> offended by the condescending and insulting responses they received 
> on this mailing list, all because they suggested making a coherent  
> way of combining existing tags into a pedestrian schema and doing 
> a carefully-vetted import

an example among many others, can you provide the link to the archive
of this problematic discussion?

technology is one thing, it's not everything.
you can read the mailing wuth a forum interface (see nabble),
you can participate without a password, there are moderators, etc
moving people from one tools to another rarely solves human problems.
the app we are talking about recently does not use a mailing list
and yet same problems you describe are present there.

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

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Michael Reichert]

Hi Nick,

Am 23.05.19 um 21:58 schrieb Nick Bolten:
> # My experience with this mailing list:
> - Quick to exasperate.
> - You will be assumed to be coming to the table in bad faith.
> - You will probably be insulted at some point, potentially sworn at.
> - The same 8 or so people respond to posts out of a community of tens of
> thousands of people, companies, non-profits, etc.
> - The odd situation of absolute certainty in completely incompatible
> opinions from those that do respond.
> - Difficult for people to discover. How do we know that the opinions shared
> here are in any way representative of the community, given that so few
> discover + participate in it?
> - Difficult to filter for relevance. Have to set up email filters and/or
> specialized search queries.
> - Zero real synchronization with OSM editors, the only way people add data
> to the map. Blame doled out everywhere, but very little in the way of
> collaboration, no real venue for doing so (see previous bullet points).
> 
> Focusing on the idea of being an "arbiter", does that sound like a good way
> to figure out which tags are good/acceptable?
> 
> When I was mentoring a group of students a few years ago, several were
> offended by the condescending and insulting responses they received on this
> mailing list, all because they suggested making a coherent way of combining
> existing tags into a pedestrian schema and doing a carefully-vetted import.
> The import was so carefully-vetted that we later realized it wasn't even
> really an import, but this didn't stop there being several insulting
> accusations from several long-term OSMers on these lists. Those students
> were motivated by helping other people and spent literal months attempting
> to gather enough information from underspecified tagging standards and
> would have been put off the community entirely if it weren't for the
> project's momentum and much more productive and friendly interactions with
> local OSMers. I think it's probably a good thing that it's so hard to even
> know that there is a mailing list, as users have a negative experience.

Your criticism might have some true points and I am happy that is a bit
more elaborated than a simple "mailing lists are bad and a toxic space".
Don't you think that an accusation without a proof (link to mailing list
archive where I can re-read the discussion that happened at that time)
makes your claims more substantial?

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Definition of Sport

[Graeme Fitzpatrick]

On Thu, 23 May 2019 at 09:37, marc marc  wrote:

>
> there is no rule defining how to swim as a hobby,
> swim like a dog if you want, it's still swimming
>

It certainly is, but is it then a "sport", or just having fun / relaxing /
cooling down? :-)

Thanks

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

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Snusmumriken]

On Fri, 2019-05-24 at 08:18 +1000, Graeme Fitzpatrick wrote:
> 
> 
> On Fri, 24 May 2019 at 04:49, Dave F via Tagging <
> tagging@openstreetmap.org> wrote:
> > Platform should only be tagged when their is a *physical* object of
> > a raise platform, not just an imaginary area of pavement.  
> > 
> 
> Sorry, but do you mean that this: 
> https://www.google.com/maps/@-28.0841684,153.4150288,3a,75y,46.69h,72.55t/data=!3m6!1e1!3m4!1s4hTF-eOoQp3yhcCIfyJelw!2e0!7i13312!8i6656
> is not a public_transport=platform, which iD defines highway=bus_stop
> as? 
> 
> If not, then what is it?

I see a hedge, a bench, a sidewalk and a bus stop. But no platform.


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

Re: [Tagging] Tagging buildings that people work in

[Warin]

On 24/05/19 03:05, marc marc wrote:

Le 23.05.19 à 18:57, ET Commands a écrit :

building=occupied


Homes and apartments are also 'occupied'. So that is not what you are after.

Humm .. 'productive'???



building=* is about what the building look like
a industrial-look building with a residential use, is still a
industrial-look and is mapped with :
building=industrial building:use=residential

following that, building=yes building:use=yes is better
yes can be improved when you'll known that's the current use,
if it not the same as what is excepted for this building look


But the mapper says the use cannot be determined by them as yet. Possibly this 
is a life cycle aspect?

building:activity=occupied/productive where occupied is for living and 
productive is for 'in operation of some productive effort'???


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

Re: [Tagging] Opening hours syntax for non Gregorian calendar

[Kevin Kenny]

On Wed, May 22, 2019 at 10:10 AM Simon Poole  wrote:
> That is not really correct as written, OH has the concept of variable dates 
> which are based on some external definition of when they exactly are, 
> currently the only one defined is "easter".  Typically you would use these to 
> start/end date ranges or a single date that is on or can be defined relative 
> to such a date. So adding "ramadan" or any other, externally defined date of 
> note is not really an issue as long as the string used doesn't conflict with 
> anything else.

'easter' suffices for the entirety of the Christian calendar[1].  All
of the movable observances, from Septuagesima to Corpus Christi
(including well-known ones such as Ash Wednesday, Good Friday,
Ascension Thursday and Pentecost) are specified as a particular number
of days before or after Easter.

I'd be fine with adding such things as Ramadan, Eid al-Fitr, and
Muharram to the schema. Since it's easiest to consider fixed points of
the calendar, Hilal ar-Ramadan would most likely be the anchor point
for Laylat al-Qadr. Eid al-Fitr would have to be a separate point,
since it's determined by its own astronomical observation. (Ramadan
runs an extra day in most localities if clouds prevent the observation
of Hilal as-Shawwal.)

[1] Strictly speaking, the Feast of St Leander - a minor observance -
also is variable, observed on 27 February in common years and 28
February in leap years. This inconsistency arises because in the Roman
calendar, the days counted from the *end* of the month, and Leap Day
was done by repeating the _sextilis_ of February. (A leap year may
still be called a 'bissextile' year.) As far as I know, he's the only
saint on the modern calendar to have been martyred in the last five
days of February of a leap year. But I don't know of anything whose
opening hours are tied to the Feast of St. Leander. There's also a
complicated set of precedences and special cases for when movable
observances collide with fixed ones (e.g. what happens when Good
Friday falls on the Feast of the Annunciation), or when certain fixed
obervances fall on a Sunday, but I haven't heard any call to model
those, either.

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

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Nick Bolten]

> Yes, it would be great. There is plenty of negative emotion on both sides
and it would be great to reverse this (for example title that I used was
frankly stupid what I realized after sending the message).

OSM needs an alternative for community tagging discussions outside of these
mailing lists. Ones that people will actually use and that have a
reasonable, community-oriented code of conduct. I have talked to 10X more
people about my `crossing` proposals outside of this mailing list
(in-person, personal emails, slack, etc.) and the differences could not be
more stark:

# My experiences with OSMers in other contexts:
- Very friendly, all focused on making maps better, highly motivated to
donate their time to help others via the map.
- Disagreements are pleasant. Both sides acknowledge the other point of
view and usually come around to a compromise.
- There is interest in knowing more: lots of questions back and forth.
- Objections are qualified and polite.
- 10s-100s of people giving feedback on a single idea.

# My experience with this mailing list:
- Quick to exasperate.
- You will be assumed to be coming to the table in bad faith.
- You will probably be insulted at some point, potentially sworn at.
- The same 8 or so people respond to posts out of a community of tens of
thousands of people, companies, non-profits, etc.
- The odd situation of absolute certainty in completely incompatible
opinions from those that do respond.
- Difficult for people to discover. How do we know that the opinions shared
here are in any way representative of the community, given that so few
discover + participate in it?
- Difficult to filter for relevance. Have to set up email filters and/or
specialized search queries.
- Zero real synchronization with OSM editors, the only way people add data
to the map. Blame doled out everywhere, but very little in the way of
collaboration, no real venue for doing so (see previous bullet points).

Focusing on the idea of being an "arbiter", does that sound like a good way
to figure out which tags are good/acceptable?

When I was mentoring a group of students a few years ago, several were
offended by the condescending and insulting responses they received on this
mailing list, all because they suggested making a coherent way of combining
existing tags into a pedestrian schema and doing a carefully-vetted import.
The import was so carefully-vetted that we later realized it wasn't even
really an import, but this didn't stop there being several insulting
accusations from several long-term OSMers on these lists. Those students
were motivated by helping other people and spent literal months attempting
to gather enough information from underspecified tagging standards and
would have been put off the community entirely if it weren't for the
project's momentum and much more productive and friendly interactions with
local OSMers. I think it's probably a good thing that it's so hard to even
know that there is a mailing list, as users have a negative experience.

To boot, there are technical problems solved by virtually every other
messaging system:
- Difficult to discover.
- Virtually impossible for new users to join recent discussions - they need
to have subscribed to the list first.
- Discovering old discussions is difficult, requires some nerdy prowess.
- Terrible security practices. Passwords sent in plain text over email. No
encryption. I was almost put off the mailing list entirely when I saw this.
Completely unacceptable.

Gripes aside, I have a suggestion: move these discussions to a real forum
system, properly organized around regional/topic-specific/tagging
discussions. It could be a revamped https://forum.openstreetmap.org/ or
something fancier and slack-like (like riot chat). Have actual moderators
and code of conduct. The current mode of communication is systematically
flawed.

On Thu, May 23, 2019 at 12:06 PM Mateusz Konieczny 
wrote:

> 23 May 2019, 18:32 by o...@westnordost.de:
>
> reverse this development.
>
> Yes, it would be great. There is plenty of negative emotion on both sides
> and it
> would be great to reverse this (for example title that I used was frankly
> stupid
> what I realized after sending the message).
>
> I had to rewrite this last paragraph several times, but, well, I hope this
> does not come across the wrong way...
> it can certainly not continue like this, so ... why not interview him,
> honestly and with open outcome, how should the collaboration and
> communication in OSM happen in the future from his point of view? Would he
> rather feel relieved or rather feel betrayed if the gatekeeping
> (~deployment) is done by other people? Does he really feel alienated
> (because I assumed it) from the community and if yes, why? And most
> importantly, what would it take to reverse this?
>
> +1, though it would be tricky to find someone both interested in doing
> this, with time to do that,
> and not already involved in a poor way
> 

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

[Joseph Eisenberg]

We cannot use the key “type=*”. This is reserved to define the type of
relation, e.g. “type=multipolygon”.

(FYI, I restarted this proposal process for camp_site=camp_pitch because I
wanted to see if we could render the ref for pitches in the
Openstreetmap-Carto style, but it looks like there will not be a consensus
on the right tag for these features any time soon)

On Fri, May 24, 2019 at 6:07 AM Graeme Fitzpatrick 
wrote:

>
>
> On Thu, 23 May 2019 at 09:31, marc marc  wrote:
>
>>
>> Le 23.05.19 à 00:19, Graeme Fitzpatrick a écrit :
>>  > then for each site
>>
>> so no main tag/value at all ? that avoid any bad tag/value :)
>>
>
> Well, yes!
>
>
>> but it is a radical change to have objects that only have subtags
>> that exist elsewhere and no main tag describing what the object.
>>
>
> But all these sites / pitches are within the bounds of a camp / caravan
> site.
>
> What are they likely to be confused with?
>
> This:
> ref=15
> type=caravan;camper_trailer
> power=yes
> water=yes
> sullage=yes
> surface=grass
> slab=yes
> fire=no
> inside a camp_site, is hardly going to be confused with Highway 15, a
> caravan shop, power supply, a river or dam & so on, is it? :-)
>
> practical problem: counting or render or finding those objects
>> becomes very complicated since there is no longer any specific tag
>>
>
> But the main =camp_site tag "should" also say that there are 110 sites /
> pitches, so you could count them that way.
>
> As for rendering, I would think that the Ref # would render as a number so
> that the map shows that Site 1 is here, 15 is over there & so on, & you
> should then be routed from the front gate along here, turn left here, right
> here, left here & 110 is half way along on the left side.
>
> Thanks
>
> Graeme
> ___
> 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 - camp_site=camp_pitch

[Warin]

On 22/05/19 18:02, Martin Koppenhoefer wrote:


sent from a phone


On 20. May 2019, at 18:19, Markus  wrote:

I prefer the camp_site:part=camp_pitch because the :part suffix is
already in use in building:part=* and could become a standard suffix
for parts of other objects, such as named parts of forests or lakes,
numbered grave fields of cemeteries or thematic parts of botanical
gardens or parks (e.g. medicinal herbs, asian plants, succulents).


While it somehow works for buildings where the sum of all building:parts make 
up the whole building, and the parts may „exist“ in the real world as concept 
(have a name, be functionally defined), the same concept works less for camping 
sites, because you won’t generally be able to divide it into parts with the sum 
of them making the whole campsite (many components are already tagged 
differently, like leisure pitches, beaches, paths, shops, bathrooms, ...). And 
the pitch as part of a campsite is much less a common concept in the real 
world. There is already the spatial and semantic relation of the pitches inside 
the campsite so that it is not useful to restate this in the key. 
camp_site:part=yes would not make a lot of sense, would it? We also have 
examples where the parts are classified as their own class aside the 
“container”, e.g. place=city and suburb, quarter, neighborhood
or amenity=bank, atm
“Things inside things” is one of the core concepts which is inherent to 
OpenStreetMap and making a map in general, there are no tags needed for mapping 
it.

Forest names (and geographic regions in general) are another issue that we have 
not solved thoroughly, because there are actually different types of “forests”: 
there are many small parts, often with names in densely populated places, which 
together form bigger areas with their own name (often/generally), which may 
form bigger parts again with a distinct name, and so on. Some names refer only 
to a patch of land with trees growing on them (and these can be represented 
well in osm), but the bigger they become, the more areas will be included where 
there aren’t actually trees growing. Those bigger entities aren’t “forests” in 
the osm sense, they are geographic regions with typically soft boundaries, for 
which we haven’t established any concept or convention yet. Adding a “:part” 
component does not solve these cases, it would again just be repeating with 
words what is already in the spatial structure.

On top of these points, the key
camp_site:part=camp_pitch
is inconveniently long and ugly, featuring a colon and two underscores in the 
same tag ;-)
If for some reason we don’t want to use the tourism key for these, the tag 
could still be much more simple, e.g.
camping=pitch


That looses a lot of information for simplicity.

A compromise?

camp:part=pitch ???

Then
pitch=caravan/trailer/tent/caravan;trailer




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

Re: [Tagging] Feature Proposal - RFC - changing table - self referencing description

[Warin]

On 23/05/19 18:51, Valor Naram wrote:
I have changed the description for the proposal at 
https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table 
as suggested.



 Original Message 
Subject: Re: [Tagging] Feature Proposal - RFC - changing table - self 
referencing description

From: marc marc
To: tagging@openstreetmap.org
CC:


Le 23.05.19 à 01:03, Warin a écrit :
> https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table
> 'self referencing description'
> So what is a better description for OSM use?
> "an aid to replacing human, usually babies, nappies/diaper"

someone in the profession pointed out that there is no adult table,
even in a specialized environment, I don't see the point
in keeping a confusion in the description.

proposal:
an infrastructure adapted to change nappies/diapers for babies
or young children



It may not be 'adapted' but purpose built.

Possibly ?
"provision to replace nappies/diapers for babies or young children" 

This removes;
 the self reference to "change"

the reference to a physical object of "infrastructure"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Nick Bolten]

> The talk ML might be a better spot for this, this topic has already
strayed quite far from the original topic. (And maybe start the topic on a
more positive prospect instead of with a rant ;-)

So far as I can tell, the topic on this mailing list (as it often is) is to
gripe about how the iD editor isn't listening to this mailing list (and
sometimes on Github issues). I've listed some reasons as to why someone
might not listen to this mailing list. Reasons that I've heard echoed many
times in various venues...

On Thu, May 23, 2019 at 3:05 PM Tobias Zwick  wrote:

> These are some valid points, and I also have some input to that, but are
> you sure you want to discuss this on the tagging ML? The talk ML might be a
> better spot for this, this topic has already strayed quite far from the
> original topic. (And maybe start the topic on a more positive prospect
> instead of with a rant ;-)
>
> Tobias
>
> On 23/05/2019 21:58, Nick Bolten wrote:
> >> Yes, it would be great. There is plenty of negative emotion on both
> sides and it would be great to reverse this (for example title that I used
> was frankly stupid what I realized after sending the message).
> >
> > OSM needs an alternative for community tagging discussions outside of
> these mailing lists. Ones that people will actually use and that have a
> reasonable, community-oriented code of conduct. I have talked to 10X more
> people about my `crossing` proposals outside of this mailing list
> (in-person, personal emails, slack, etc.) and the differences could not be
> more stark:
> >
> > # My experiences with OSMers in other contexts:
> > - Very friendly, all focused on making maps better, highly motivated to
> donate their time to help others via the map.
> > - Disagreements are pleasant. Both sides acknowledge the other point of
> view and usually come around to a compromise.
> > - There is interest in knowing more: lots of questions back and forth.
> > - Objections are qualified and polite.
> > - 10s-100s of people giving feedback on a single idea.
> >
> > # My experience with this mailing list:
> > - Quick to exasperate.
> > - You will be assumed to be coming to the table in bad faith.
> > - You will probably be insulted at some point, potentially sworn at.
> > - The same 8 or so people respond to posts out of a community of tens of
> thousands of people, companies, non-profits, etc.
> > - The odd situation of absolute certainty in completely incompatible
> opinions from those that do respond.
> > - Difficult for people to discover. How do we know that the opinions
> shared here are in any way representative of the community, given that so
> few discover + participate in it?
> > - Difficult to filter for relevance. Have to set up email filters and/or
> specialized search queries.
> > - Zero real synchronization with OSM editors, the only way people add
> data to the map. Blame doled out everywhere, but very little in the way of
> collaboration, no real venue for doing so (see previous bullet points).
> >
> > Focusing on the idea of being an "arbiter", does that sound like a good
> way to figure out which tags are good/acceptable?
> >
> > When I was mentoring a group of students a few years ago, several were
> offended by the condescending and insulting responses they received on this
> mailing list, all because they suggested making a coherent way of combining
> existing tags into a pedestrian schema and doing a carefully-vetted import.
> The import was so carefully-vetted that we later realized it wasn't even
> really an import, but this didn't stop there being several insulting
> accusations from several long-term OSMers on these lists. Those students
> were motivated by helping other people and spent literal months attempting
> to gather enough information from underspecified tagging standards and
> would have been put off the community entirely if it weren't for the
> project's momentum and much more productive and friendly interactions with
> local OSMers. I think it's probably a good thing that it's so hard to even
> know that there is a mailing list, as users have a negative experience.
> >
> > To boot, there are technical problems solved by virtually every other
> messaging system:
> > - Difficult to discover.
> > - Virtually impossible for new users to join recent discussions - they
> need to have subscribed to the list first.
> > - Discovering old discussions is difficult, requires some nerdy prowess.
> > - Terrible security practices. Passwords sent in plain text over email.
> No encryption. I was almost put off the mailing list entirely when I saw
> this. Completely unacceptable.
> >
> > Gripes aside, I have a suggestion: move these discussions to a real
> forum system, properly organized around regional/topic-specific/tagging
> discussions. It could be a revamped https://forum.openstreetmap.org/ or
> something fancier and slack-like (like riot chat). Have actual moderators
> and code of conduct. The current mode of communication is 

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Nick Bolten]

> Don't you think that an accusation without a proof (link to mailing list
archive where I can re-read the discussion that happened at that time)
makes your claims more substantial?

Yes, it would substantiate the claim. It would also increase tensions, so
I'm not going to dive into that unless it's absolutely necessary.

On Thu, May 23, 2019 at 2:43 PM Michael Reichert 
wrote:

> Hi Nick,
>
> Am 23.05.19 um 21:58 schrieb Nick Bolten:
> > # My experience with this mailing list:
> > - Quick to exasperate.
> > - You will be assumed to be coming to the table in bad faith.
> > - You will probably be insulted at some point, potentially sworn at.
> > - The same 8 or so people respond to posts out of a community of tens of
> > thousands of people, companies, non-profits, etc.
> > - The odd situation of absolute certainty in completely incompatible
> > opinions from those that do respond.
> > - Difficult for people to discover. How do we know that the opinions
> shared
> > here are in any way representative of the community, given that so few
> > discover + participate in it?
> > - Difficult to filter for relevance. Have to set up email filters and/or
> > specialized search queries.
> > - Zero real synchronization with OSM editors, the only way people add
> data
> > to the map. Blame doled out everywhere, but very little in the way of
> > collaboration, no real venue for doing so (see previous bullet points).
> >
> > Focusing on the idea of being an "arbiter", does that sound like a good
> way
> > to figure out which tags are good/acceptable?
> >
> > When I was mentoring a group of students a few years ago, several were
> > offended by the condescending and insulting responses they received on
> this
> > mailing list, all because they suggested making a coherent way of
> combining
> > existing tags into a pedestrian schema and doing a carefully-vetted
> import.
> > The import was so carefully-vetted that we later realized it wasn't even
> > really an import, but this didn't stop there being several insulting
> > accusations from several long-term OSMers on these lists. Those students
> > were motivated by helping other people and spent literal months
> attempting
> > to gather enough information from underspecified tagging standards and
> > would have been put off the community entirely if it weren't for the
> > project's momentum and much more productive and friendly interactions
> with
> > local OSMers. I think it's probably a good thing that it's so hard to
> even
> > know that there is a mailing list, as users have a negative experience.
>
> Your criticism might have some true points and I am happy that is a bit
> more elaborated than a simple "mailing lists are bad and a toxic space".
> Don't you think that an accusation without a proof (link to mailing list
> archive where I can re-read the discussion that happened at that time)
> makes your claims more substantial?
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
> ___
> 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 a site with "Luxury Lodges"

[Joseph Eisenberg]

I personally would not tag a >20 foot wide manufactured home as a static
caravan

I thought that building=static_caravan was meant for (single-wide) trailers
/ “mobile homes” without permanent foundations, since these could still be
moved without demolishing a foundation or breaking the building into pieces.

If a manufactured home is placed on a permanent foundation, on land that is
owned rather than rented, then it is just a different way of building a
house, no?

Similarly, a fancy modern house or apartment building might be built out of
prefab modules or modified shipping containers.

I’d say the defining difference is whether or not there is a permanent
foundation

But I confess this is not my area of expertise

On Fri, May 24, 2019 at 12:09 AM Clifford Snow 
wrote:

> I the US we call them manufactured homes. They are trucked to the site,
> often split lengthwise into two pieces. Once on site, they place them on a
> foundation then remove the wheels from underneath. Most are relatively
> inexpensive to purchase. The real money make is the owner of the land that
> rents out the tiny lot.
>
> These communities can be a mix of mobile home, aka caravans, and
> manufactured homes. From aerial imagery the individual units the only real
> difference is usually the roof. Manufactured home may have a peaked roof
> where the mobile homes are usually flat.
>
> I've tagged both a building=static_caravan
>
> Best,
> Clifford
>
> On Thu, May 23, 2019 at 2:56 AM Paul Allen  wrote:
>
>> On Thu, 23 May 2019 at 06:41, Martin Koppenhoefer 
>> wrote:
>>
>>>
>>> While they might be called „house“, why not „building=lodge“? The fact
>>> they are poorly insulated, prefabricated wooden single floor structures is
>>> better reflected by that word.
>>>
>>
>> building=luxury_shanty
>>
>> --
>> Paul
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> 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 buildings that people work in

[Kevin Kenny]

On Thu, May 23, 2019 at 1:07 PM marc marc  wrote:
> following that, building=yes building:use=yes is better
> yes can be improved when you'll known that's the current use,
> if it not the same as what is excepted for this building look

I'm even fine with 'building=yes note=*'. A data consumer isn't likely
to be able to do much with any invented tagging for the partial
information - a note is about as good as any kind of structured data
here.

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

Re: [Tagging] Opening hours syntax for non Gregorian calendar

[Graeme Fitzpatrick]

On Thu, 23 May 2019 at 22:27, Andy Mabbett 
wrote:

>
> If only there was some sort of ISO standard for representing dates...
>

Yep, especially when you get those pesky Americans involved :-)

Is 5/6, the 5th of June or the 6th of May?

Thanks

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

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Mateusz Konieczny]

23 May 2019, 21:58 by nbol...@gmail.com:

> in-person
>
Well, it is hard to beat in-person contact.

> , personal emails, slack, etc.
>
My experience with both and mailing lists is very similar as far as quality of 
conversation goes.

For:

> - The same 8 or so people respond to posts out of a community of tens of 
> thousands of people, companies, non-profits, etc.
> - The odd situation of absolute certainty in completely incompatible opinions 
> from those that do respond.
> - Difficult for people to discover. How do we know that the opinions shared 
> here are in any way representative of the community, given that so few 
> discover + participate in it?
> - Difficult to filter for relevance. Have to set up email filters and/or 
> specialized search queries.
> - Zero real synchronization with OSM editors, the only way people add data to 
> the map. Blame doled out everywhere, but very little in the way of 
> collaboration, no real venue for doing so (see previous bullet points).
>
I see no difference between slack, personal emails and mailing list for this 
points.

Though personal emails are even worse in category "to discover" and 
in managing separate conversations.

Though I am confused what you mean by "Zero real synchronization with OSM 
editors"

> Gripes aside, I have a suggestion: move these discussions to a real forum 
> system, properly organized around regional/topic-specific/tagging 
> discussions. It could be a revamped > https://forum.openstreetmap.org/ 
> 
>
What is wrong with a current forum?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Tobias Zwick]

These are some valid points, and I also have some input to that, but are you 
sure you want to discuss this on the tagging ML? The talk ML might be a better 
spot for this, this topic has already strayed quite far from the original 
topic. (And maybe start the topic on a more positive prospect instead of with a 
rant ;-)

Tobias

On 23/05/2019 21:58, Nick Bolten wrote:
>> Yes, it would be great. There is plenty of negative emotion on both sides 
>> and it would be great to reverse this (for example title that I used was 
>> frankly stupid what I realized after sending the message).
> 
> OSM needs an alternative for community tagging discussions outside of these 
> mailing lists. Ones that people will actually use and that have a reasonable, 
> community-oriented code of conduct. I have talked to 10X more people about my 
> `crossing` proposals outside of this mailing list (in-person, personal 
> emails, slack, etc.) and the differences could not be more stark:
> 
> # My experiences with OSMers in other contexts:
> - Very friendly, all focused on making maps better, highly motivated to 
> donate their time to help others via the map.
> - Disagreements are pleasant. Both sides acknowledge the other point of view 
> and usually come around to a compromise.
> - There is interest in knowing more: lots of questions back and forth.
> - Objections are qualified and polite.
> - 10s-100s of people giving feedback on a single idea.
> 
> # My experience with this mailing list:
> - Quick to exasperate.
> - You will be assumed to be coming to the table in bad faith.
> - You will probably be insulted at some point, potentially sworn at.
> - The same 8 or so people respond to posts out of a community of tens of 
> thousands of people, companies, non-profits, etc.
> - The odd situation of absolute certainty in completely incompatible opinions 
> from those that do respond.
> - Difficult for people to discover. How do we know that the opinions shared 
> here are in any way representative of the community, given that so few 
> discover + participate in it?
> - Difficult to filter for relevance. Have to set up email filters and/or 
> specialized search queries.
> - Zero real synchronization with OSM editors, the only way people add data to 
> the map. Blame doled out everywhere, but very little in the way of 
> collaboration, no real venue for doing so (see previous bullet points).
> 
> Focusing on the idea of being an "arbiter", does that sound like a good way 
> to figure out which tags are good/acceptable?
> 
> When I was mentoring a group of students a few years ago, several were 
> offended by the condescending and insulting responses they received on this 
> mailing list, all because they suggested making a coherent way of combining 
> existing tags into a pedestrian schema and doing a carefully-vetted import. 
> The import was so carefully-vetted that we later realized it wasn't even 
> really an import, but this didn't stop there being several insulting 
> accusations from several long-term OSMers on these lists. Those students were 
> motivated by helping other people and spent literal months attempting to 
> gather enough information from underspecified tagging standards and would 
> have been put off the community entirely if it weren't for the project's 
> momentum and much more productive and friendly interactions with local 
> OSMers. I think it's probably a good thing that it's so hard to even know 
> that there is a mailing list, as users have a negative experience.
> 
> To boot, there are technical problems solved by virtually every other 
> messaging system:
> - Difficult to discover.
> - Virtually impossible for new users to join recent discussions - they need 
> to have subscribed to the list first.
> - Discovering old discussions is difficult, requires some nerdy prowess.
> - Terrible security practices. Passwords sent in plain text over email. No 
> encryption. I was almost put off the mailing list entirely when I saw this. 
> Completely unacceptable.
> 
> Gripes aside, I have a suggestion: move these discussions to a real forum 
> system, properly organized around regional/topic-specific/tagging 
> discussions. It could be a revamped https://forum.openstreetmap.org/ or 
> something fancier and slack-like (like riot chat). Have actual moderators and 
> code of conduct. The current mode of communication is systematically flawed.
> 
> On Thu, May 23, 2019 at 12:06 PM Mateusz Konieczny  > wrote:
> 
> 23 May 2019, 18:32 by o...@westnordost.de :
> 
> reverse this development.
> 
> Yes, it would be great. There is plenty of negative emotion on both sides 
> and it
> would be great to reverse this (for example title that I used was frankly 
> stupid
> what I realized after sending the message).
> 
> I had to rewrite this last paragraph several times, but, well, I hope 
> this does not come across the wrong way...
>  

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Nick Bolten]

That bus stop has essentially the same surface conditions as the picture
for `highway=platform`. Who wants to update the wiki?

On Thu, May 23, 2019 at 3:46 PM Jo  wrote:

> Indeed not a platform, just a bus stop with a bench and maybe a shelter,
> not sure. If the kerb were a bit higher where the bus halts, I'd say
> platform, but this is just a sidewalk.
> That we map such a node with public_transport=platform/bus=yes doesn't
> make it a platform. That's just convention since the PT v2 scheme appeared.
>
> Polyglot
>
> On Fri, May 24, 2019 at 12:20 AM Graeme Fitzpatrick 
> wrote:
>
>>
>>
>> On Fri, 24 May 2019 at 04:49, Dave F via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>>
>>> Platform should only be tagged when their is a *physical* object of a
>>> raise platform, not just an imaginary area of pavement.
>>>
>>
>> Sorry, but do you mean that this:
>> https://www.google.com/maps/@-28.0841684,153.4150288,3a,75y,46.69h,72.55t/data=!3m6!1e1!3m4!1s4hTF-eOoQp3yhcCIfyJelw!2e0!7i13312!8i6656
>> is *not* a public_transport=platform, which iD defines highway=bus_stop
>> as?
>>
>> If not, then what is it?
>>
>> Thanks
>>
>> Graeme
>> ___
>> 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] solving iD conflict (was: pointlessly inflamatory title)

[Frederik Ramm]

Hi,

On 5/23/19 21:58, Nick Bolten wrote:
> OSM needs an alternative for community tagging discussions outside of
> these mailing lists.

It might; that doesn't invalidate points made on these mailing lists though!

> # My experiences with OSMers in other contexts:
> - Very friendly, all focused on making maps better, highly motivated to
> donate their time to help others via the map.
> - Disagreements are pleasant. Both sides acknowledge the other point of
> view and usually come around to a compromise.
> - There is interest in knowing more: lots of questions back and forth.
> - Objections are qualified and polite.
> - 10s-100s of people giving feedback on a single idea.

Every person on this mailing list participates in many of these kinds of
discussions, in addition to being on the mailing list (just in case you
were thinking there were two different kinds of people, the friendly
people and the mailing list people; this is not the case).

> When I was mentoring a group of students a few years ago, several were
> offended by the condescending and insulting responses they received on
> this mailing list, all because they suggested making a coherent way of
> combining existing tags into a pedestrian schema and doing a
> carefully-vetted import. 

I think you should attempt to apply a little of that "acknowledging the
other point of view" that you lauded above to such situations. Every day
brings new broken imports to OpenStreetMap. All of them are done with
the best intentions. Very many of them are done by people with little
prior experience. Therefore, when a group of students pops up and
suggests to do an import, this already sets some alarm bells ringing
(carefully vetted or not). Your project is to be applauded to even come
here - as you rightly say, the lists are not necessarily easy to
discover and a large percentage of problematic imports have never been
discussed with anyone before they are attempted.

Everyone on this mailing list has likely seen many buggy imports.
Imagine being at a party and someone steps on your shoe. They say sorry,
you say no problem. Five minutes later another person steps on your
shoe. Again, a friendly sorry, a friendly no problem. By the time the
10th person steps on your shoe you might shout out "WHAT THE FUCK IS
WRONG WITH THIS PARTY" even if that person is totally innocent. It's not
right, it's not polite, but it is somewhat understandable.

> I think
> it's probably a good thing that it's so hard to even know that there is
> a mailing list, as users have a negative experience.

That is often repeated and I guess most people can confirm that people
act differently in person than on mailing lists. However, many mailing
lists in OSM are vibrant meeting places for many more than 8 community
members, and spreading negative opinions about mailing lists reinforces
problems instead of solving them - if you go around telling everyone
what a snake pit "the mailing lists" are then people will either not
join them, or join them just waiting to see their expectations confirmed.

In general, our project isn't a top-down strictly managed project with a
controlled decision-making process. This means that many things have to
be discussed over and over, and the community generally doesn't speak
with one voice. But this also gives us some resilience; there's no one
"tag central command" that someone could take over and dictate what we
are to do.

> - Terrible security practices. Passwords sent in plain text over email.
> No encryption. I was almost put off the mailing list entirely when I saw
> this. Completely unacceptable.

Now you're going off on a tangent. Passwords are not required at all to
use the mailing list. Of course, email in general is not a secure medium
since you can easily impersonate others. Then again, if we judge the
merit of contributions by their content and not by who wrote them,
impersonating someone doesn't even give you much of an advantage.

> Gripes aside, I have a suggestion: move these discussions to a real
> forum system, properly organized around regional/topic-specific/tagging
> discussions. It could be a revamped https://forum.openstreetmap.org/ or
> something fancier and slack-like (like riot chat). Have actual
> moderators and code of conduct.

The current forum system works and has moderators and etiquette
guidelines (this depends on each sub-forum, they are not global).
Discoverability isn't much better than mailing lists IMHO. In my country
(Germany), OSMers are neatly split between forum and mailing list, most
using just one or just the other, some using both. Nothing wrong with
that IMHO; smaller groups form better bonds.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

[marc marc]

Le 23.05.19 à 23:05, Graeme Fitzpatrick a écrit :

>> no main tag/value at all ? that avoid any bad tag/value :)

> Well, yes! What are they likely to be confused with?

tagging a camp_pitch without any additional tag 'll
be a polygon with no tag, that's a little light :)
at least one tag is needed, camp_pitch=yes for example.

Le 24.05.19 à 01:27, Warin a écrit :

 >> camp_site:part=camp_pitch is inconveniently long

 > A compromise? camp:part=pitch ???

but we lost : a part of what (link the part with the main tag) ?
so camp_site:part=pitch if you wish to be short.

well I fine with camp_site:part=pitch camp_site:part=camp_pitch 
camp_pitch=yes tourism=camp_pitch
maybe the easiest is a single propal with the 3 choices,
the choice that receives the most votes is approved.
does anyone object to it because it's not a conventional proposal ?

 > Then pitch=caravan/trailer/tent/caravan;trailer

no new tag needed for that, let's use the same tags as listed on
https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcamp_site
you don't even need to include sub-tags in the proposal,
so you don't have vote against them
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

[Graeme Fitzpatrick]

On Thu, 23 May 2019 at 09:31, marc marc  wrote:

>
> Le 23.05.19 à 00:19, Graeme Fitzpatrick a écrit :
>  > then for each site
>
> so no main tag/value at all ? that avoid any bad tag/value :)
>

Well, yes!


> but it is a radical change to have objects that only have subtags
> that exist elsewhere and no main tag describing what the object.
>

But all these sites / pitches are within the bounds of a camp / caravan
site.

What are they likely to be confused with?

This:
ref=15
type=caravan;camper_trailer
power=yes
water=yes
sullage=yes
surface=grass
slab=yes
fire=no
inside a camp_site, is hardly going to be confused with Highway 15, a
caravan shop, power supply, a river or dam & so on, is it? :-)

practical problem: counting or render or finding those objects
> becomes very complicated since there is no longer any specific tag
>

But the main =camp_site tag "should" also say that there are 110 sites /
pitches, so you could count them that way.

As for rendering, I would think that the Ref # would render as a number so
that the map shows that Site 1 is here, 15 is over there & so on, & you
should then be routed from the front gate along here, turn left here, right
here, left here & 110 is half way along on the left side.

Thanks

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

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Kevin Kenny]

On Thu, May 23, 2019 at 7:39 PM Frederik Ramm  wrote:
> In general, our project isn't a top-down strictly managed project with a
> controlled decision-making process. This means that many things have to
> be discussed over and over, and the community generally doesn't speak
> with one voice. But this also gives us some resilience; there's no one
> "tag central command" that someone could take over and dictate what we
> are to do.

I think at the root of the complaints in this thread is the idea -
justified or not - that the maintainers of iD are attempting to
arrogate that role unto themselves.

To the extent that they are, it is probably because the discussion
forums on tagging - at least, this list - are too cacophonous to
inform their decisions about what tags to present in iD.  Where
consensus fails here - as, in my experience, it almost always does for
any question that isn't answerable by tagging that was well
established years before I got here - the iD developers are really
faced with the decision: implement some arbitrary choice that makes
sense to them, or do nothing about helping iD users to map the feature
in question.

That matches my experience with mapping. On the few occasions that
I've asked a tagging question in here, any useful answers are lost in
a din of conflicting opinions. That's fine if the sole purpose of the
mailing list is to explore the tagging strategy - it is by talking
these things to death, over and over, that consensus is built -
painfully slowly. In the meantime, I run the opinions through the
mental filters of "what do they have in common" and "what from among
the rest makes sense to *me*?" and map my feature accordingly. I'd
imagine that the iD team is forced to employ a similar process.

So far I've gotten away with it. If anyone complains, I can retag. If
anyone reverts, I can leave the feature unmapped. Obviously, though,
my tagging affects only the relatively small fraction of OSM's
features that I map, while iD's tagging has a much bigger impact.
That's why nobody takes me to task for rogue tagging, while iD appears
constantly to be under fire.

I'm not sure it's fixable. We need both the passionate argument about
the right way to do things, and someone who can decide for each tool
what that tool will consider to be the best current practice. Those
who get angry at not getting their way will get angry. If the mailing
list is to serve as a debating forum for what tagging practice ought
to be in the medium or far future - a function that is needed - it
will not be very effective at informing anyone of best
_current_practice. They're slightly different jobs, and we're not very
good at separating them. Even Overpass and taginfo queries seem to be
more effective at determining whether a tag is accepted in current
practice, and of course we all know that has to be taken with a grain
of salt.

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

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

[Joseph Eisenberg]

Re: offer several tag options, and “the choice that receives the most votes
is approved.”

That’s not how the current approval guideline is set. There needs to be 75%
votes for approval. This is to prevent a tag from being approved with just
51% yes votes.

This is why it can be difficult to reach approval when there are several
competing tags.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours syntax for non Gregorian calendar

[Paul Allen]

On Thu, 23 May 2019 at 00:06, Graeme Fitzpatrick 
wrote:

>
> But what are Christmas & Easter if they're not religious holidays? :-)
>

Not all religious holidays are created equal.  Many cafes and restaurants
in tourist areas are
closed on Christmas Day/Boxing day but are open on Good Friday/Easter
Monday.

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

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

[Joseph Eisenberg]

>  tourism=camp_pitch (not because I like this, but because fixing one issue 
> (avoid conflit with tourism=camp_site + 
> camp_site=basic/standard/serviced/deluxe) is better than fixing none of them.

Please do not retag features to an unapproved, undocumented tag.
Mechanical edits are discouraged, even if you are doing them by hand.

I'd be willing to make a proposal page for tourism=camp_pitch if there
is sufficient support for this tag, but it sounds like you don't
actually like this tag?

I'm not sure that there will be sufficient support for
tourism=camp_pitch to win approval. It's always hard to guess.

On 5/23/19, marc marc  wrote:
> sumary :
> imho, this thread is trying to solve all issues in one shoot,
> and this nearly always fail.
> it seems better to cut this into several parts from the simplest to the
> most complicated (retag camp_site=* objects that have already a more
> suitable tags such as toilets, depreciated one by one the most
> problematic values of camp_site) in order to clarify the final solution.
> that's what I proposed on the french-speaking list, no one is against
> it, no public reaction, but taginfo shows that there are people
> working to improve the situation
>
> Le 22.05.19 à 03:26, Tod Fitch a écrit :
>  > If the tourism=camp_site has only one place to camp:
>  > tourism=camp_site
>  > camp_site=camp_pitch
>  > camp_pitch:type=tent
>  > camp_pitch:fire=ring
>
> that doesn't solve the double (hidjack) meaning of camp_site
> and to avoid unneeded namespace and use as often existing tags,
> I prefer somethink like :
> tourism=camp_site
> camp_site=basic/standard/serviced/deluxe
> camp_pitch:count=1 or camp_pitch=1
> tents=yes/only
> fireplace=yes/ring
>
>  > https://wiki.openstreetmap.org/wiki/Proposed_features/Key:camp_pitch
>
> this propal over-use the namespace
> for ex drinking_water=yes/no is enought, no namespace needed
>
> Le 22.05.19 à 06:09, Tod Fitch a écrit :
>  > a site with only one place for tent/caravan
>  > list the detailed characteristics (table, fire ring, etc.).
>
> I don't understand the issue.
> just add the detailed characteristics to tourism=camp_site
> like it's already done for a lot of them.
> and add camp_pitch:count=1 or camp_pitch=1
>
> Le 22.05.19 à 06:09, Tod Fitch a écrit :
>  > What we’d call a “campground” is apparently called a “campsite” in
>  > British English and somehow turned into “camp site” in OSM. And what
>  > we’d call an individual place within a campground would be “camp site”
>  > but is apparently a “pitch” in BE.
>
> it's probably a good idea to inform about the risk of confusion
> on the wiki
>
>  > camp_site=pitch [5] was not well accepted by people on these mailing
> lists because “pitch” is more associated with fields for sports.
>
> I have review 100+ of them yesterday, I have found 2 usecases :
> - some are a camp_pitch in camp_site that have several camp_pitch".
> Those can be fixed with tourism=camp_pitch (not because I like this,
> but because fixing one issue (avoid conflit with tourism=camp_site +
> camp_site=basic/standard/serviced/deluxe) is better than fixing none
> of them. camp_pitch=yes is also a tmp fix due you dislike
> tourism=camp_pitch, or part=camp_pitch
> - some are a "part" of camp_site grouped because of a common caracts
> like a camp_site tents=yes caravans=yes with a part for tents=yes and a
> part for caravans=yes
> all tag/value currently in use are imho wrong. I have fixed those with
> tourism=camp_pitch the existing least bad solution we currently have in
> use. camp_pitch=many or part=yes may also be a tmp fix to find those later.
>
> that said, the problem of camp_pitch is general, values are drowned with
> item that have other more suitable tags. somes examples found :
> camp_site=entrance on a node of the outer -> entrance=yes
> camp_site=toilets -> amenity=toilets (sometime with access=customers)
> camp_site=shower -> amenity=shower (sometime with access=customers)
> camp_site=caravan -> caravans=yes/designated
>
>  > Proposed for a pitch within a campsite: camp_site:part=camp_pitch
>
> I agree with that, but some find it too long.
> so maybe it's better to cut issues in 3 :
> - fix camp_site= value when a better tag exist (toilets, shower,
> entrance, ...)
> - move camp_site=pitch camp_site=camp_pitch out of camp_site=* to solve
> the double meaning of this tag (a camp_site with one-only camp_pitch <>
> a camp_pitch in a camp_site with severals camp_pitch). we can tmp use
> tourism=camp_pitch or camp_pitch=yes or whatever to move out the
> approved tourism=camp_site camp_site=* tag linking.
> - find what the best schema could be for : a camp_pitch in a whole camp,
> a part of a whole camp used to add a subtag for this part
>
> Le 22.05.19 à 10:02, Martin Koppenhoefer a écrit :
>  > the sum of all building:parts make up the whole building
>
> you may add a part just to describe that a caract of a part
> that the usecase I have found by looking at the current usage
>
> Le 22.05.19 à 

Re: [Tagging] iD update [was: iD adding highway=footway to all railway/public_transport=platform ways and relations]

[marc marc]

Le 23.05.19 à 11:46, Paul Allen a écrit :
> On Thu, 23 May 2019 at 09:46, marc marc wrote:
> 
> previous updates were announced by email
> I missed this one and/or no announcement for this one.
> 
> Maybe your browser works differently to mine.

it isn't my nor your browser that send the email
wrote by the iD team :)

last one [Tagging] iD news - 2.12.0 released
https://lists.openstreetmap.org/pipermail/tagging/2018-December/041434.html
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] iD update [was: iD adding highway=footway to all railway/public_transport=platform ways and relations]

[Paul Allen]

On Thu, 23 May 2019 at 11:26, marc marc  wrote:

>
> it isn't my nor your browser that send the email
> wrote by the iD team :)
>

I didn't get that email either.  I've never received an email from the iD
team about upgrades.  Yet
I learn of the upgrades as soon as they happen.  Because iD tells me that
there's been an
upgrade as soon as I start to use it.

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

Re: [Tagging] Definition of Sport

[Hufkratzer]

On 23.05.2019 01:36, marc marc wrote:

Le 23.05.19 à 01:26, Warin a écrit :

A) A physical competition played according to rules.

B) As for A) but includes practising for the sport

c) as for B) but includes non competitive physical activity.

Thoughts?

i like C but without the "with rules" included via A :)
there is no rule defining how to swim as a hobby,
swim like a dog if you want, it's still swimming


Then hiking, walking, bathing, eating, scratching your head ... any 
physical activity would be a kind of sport.

This definition makes not much sense to me.
Compare https://wiki.openstreetmap.org/wiki/Swimming_and_bathing

Is chess a sport? Probably. Does it require considerable physical activity?

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

Re: [Tagging] Feature Proposal - RFC - changing table - self referencing description

[marc marc]

Le 23.05.19 à 01:03, Warin a écrit :
> https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table
> 'self referencing description'
> So what is a better description for OSM use?
> "an aid to replacing human, usually babies, nappies/diaper"

someone in the profession pointed out that there is no adult table,
even in a specialized environment, I don't see the point
in keeping a confusion in the description.

proposal:
an infrastructure adapted to change nappies/diapers for babies
or young children
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging a site with "Luxury Lodges"

[Paul Allen]

On Thu, 23 May 2019 at 06:41, Martin Koppenhoefer 
wrote:

>
> While they might be called „house“, why not „building=lodge“? The fact
> they are poorly insulated, prefabricated wooden single floor structures is
> better reflected by that word.
>

building=luxury_shanty

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

Re: [Tagging] iD update [was: iD adding highway=footway to all railway/public_transport=platform ways and relations]

[marc marc]

I mean that previous updates were announced by email on osm-dev
with the change log, everyone can easily see the changes.
I missed this one and/or no announcement for this one.
after reading the modification log, other changes are strange,
I will reread them again before posting specific issue

Le 23.05.19 à 09:14, Mateusz Konieczny a écrit :
> This is a change on the OSM website that updates iD version so all 
> changes are bundled as one.
> 
> For more gradual commits/issues see https://github.com/openstreetmap/iD
> 
> 
> 23 May 2019, 01:39 by graemefi...@gmail.com:
> 
> 
> 
> On Thu, 23 May 2019 at 09:10, marc marc  > wrote:
> 
> 
> I may have missed the last iD update announcement announcing this,
> what this transparent or discovered by chance?
> 
> 
> This one, which includes heaps of changes!?
> 
> https://github.com/openstreetmap/openstreetmap-website/pull/2231
> 
> Thanks
> 
> Graeme
> 
> 
> 
> ___
> 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 - changing table - self referencing description

[Valor Naram]

I have changed the description for the proposal at https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table as suggested. Original Message Subject: Re: [Tagging] Feature Proposal - RFC - changing table - self referencing descriptionFrom: marc marc To: tagging@openstreetmap.orgCC: Le 23.05.19 à 01:03, Warin a écrit :> https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table> 'self referencing description'> So what is a better description for OSM use?> "an aid to replacing human, usually babies, nappies/diaper"someone in the profession pointed out that there is no adult table,even in a specialized environment, I don't see the pointin keeping a confusion in the description.proposal:an infrastructure adapted to change nappies/diapers for babiesor young children___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] iD update [was: iD adding highway=footway to all railway/public_transport=platform ways and relations]

[Paul Allen]

On Thu, 23 May 2019 at 09:46, marc marc  wrote:

> I mean that previous updates were announced by email on osm-dev
> with the change log, everyone can easily see the changes.
>

On my browser, the version number at bottom right was replaced by a red
icon.  Clicking on it
opens a browser window onto the changelog.  That's been standard with iD
updates for as long
as I've been using it.


> I missed this one and/or no announcement for this one.
>

Maybe your browser works differently to mine.

after reading the modification log, other changes are strange,
> I will reread them again before posting specific issue
>

Many of them don't make a lot of sense unless you take a look at the issues
they reference.

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