Re: [Tagging] Feature proposal - Voting - Location transitions

[Martin Koppenhoefer]

sent from a phone

> Am 09.01.2016 um 00:09 schrieb François Lacombe :
> 
> As described, location:transition=yes may enable mappers to indicate
> the location of a feature is changing without using fixme or
> approximative ways (when guessing where a feature goes underground).


this is currently proposed to be used only on nodes, but might be useful for 
polygons as well.

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

Re: [Tagging] Question reg. wheelchair mapping

[Gerd Petermann]

Andy Townsend wrote
> Have you tried contacting any of the consumers of the "access_ramp" 
> data?  I'm assuming that none (or almost none) of them will read the 
> tagging list; the DE forum will find a few, but a small portion of the 
> number internationally.

:-(
My hope was to get in contact with them via these posts.
If that doesn't work I'll try other ways.

Gerd




--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-reg-wheelchair-mapping-tp5864292p5864427.html
Sent from the Tagging mailing list archive at Nabble.com.

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

Re: [Tagging] Feature proposal - Voting - Location transitions

[François Lacombe]

Le 9 janv. 2016 10:22 AM, "Martin Koppenhoefer"  a
écrit :
>
> this is currently proposed to be used only on nodes, but might be useful
for polygons as well.
>
> cheers,
> Martin

Hi Martin

Can you provide an example for this situation please ?

I think about power=substation + substation=transition but several
different features can emerge from it and location:transition may indicate
where exactly in the given substation (which goes nowhere itself)

Cheers

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

Re: [Tagging] Feature Proposal - RFC - (Street Parking Restrictiion)

[Paul Johnson]

On Fri, Jan 8, 2016 at 3:00 AM, Paul Simpson 
wrote:

> Dear All,
>
> I am sending this RFC in order to receive some feedback regarding my OSM
> feature proposal for Street Parking Restrictions.
>
>

Already supported in JOSM and in increasingly widespread active use under a
more comprehensive scheme.

https://wiki.openstreetmap.org/wiki/Key:parking:lane
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway = track vs. residential

[Mateusz Konieczny]

On Fri, 8 Jan 2016 10:50:37 +0100
Wolfgang Zenker  wrote:

> * Tod Fitch  [160107 23:35]:
> > My parents house is in a pretty rural part of Arizona and
> > distinguishing between tracks and driveways or even residential
> > roads can be difficult there. So my initial instinct was to say
> > leave the ways in that part of Colorado as tracks as it can be hard
> > to tell on the imagery.
> 
> > But looking at the satellite imagery in the area you linked, they
> > clearly look like unpaved residential roads and dirt driveways.
> 
> > I’d leave the driveways in but change the tagging to:
> 
> > highway=service
> > service=driveway
> > surface=unpaved
> > access=private
> 
> I would do almost the same, but would leave out the access=private,
> as this is difficult to determine from the aerial imagery, and is
> implied for service=driveway anyway.

I would strongly dispute "implied for service=driveway anyway" - in
some cases service=driveway is accessible for everybody, in
many cases it is accessible at least for foot traffic.

In case of known access=private access it should be tagged explicitly.

(I guess that it is one of so many differences between
countries/regions - my experience is based mostly on Poland).

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

Re: [Tagging] highway = track vs. residential

[Martin Koppenhoefer]

sent from a phone

> Am 09.01.2016 um 13:12 schrieb Mateusz Konieczny :
> 
> In case of known access=private access it should be tagged explicitly


+1, generally, don't rely on defaults, add known information. Defaults are for 
data consumers (i.e. they decide how to deal with cases where they miss the 
data they need, and how they try to infer/guess it from other tags and the 
context), not for mappers

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

Re: [Tagging] Feature proposal - Voting - Location transitions

[ajt1...@gmail.com]

On 08/01/2016 23:09, François Lacombe wrote:

Hi all,

The vote vote session for the location transition proposal is now open.
http://wiki.openstreetmap.org/wiki/Proposed_features/Location_transitions

As described, location:transition=yes may enable mappers to indicate
the location of a feature is changing without using fixme or
approximative ways (when guessing where a feature goes underground).

It would be great you spend a little time to write a feedback at the
bottom of the page.



Having read that page I don't really understand what the motivation for 
it is.  Maybe add a bit more information explaining how this new tag 
will provide information that isn't automatically apparent from other 
tags already present?  For example, if a road goes into a tunnel the bit 
not in a tunnel has no "tunnel" tag and the bit in the tunnel does; in 
that situation what extra information does a "location transition" provide?


Cheers,

Andy


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

Re: [Tagging] highway = track vs. residential

[Wolfgang Zenker]

* Mateusz Konieczny  [160109 13:12]:
> On Fri, 8 Jan 2016 10:50:37 +0100
> Wolfgang Zenker  wrote:

>> * Tod Fitch  [160107 23:35]:
>>> My parents house is in a pretty rural part of Arizona and
>>> distinguishing between tracks and driveways or even residential
>>> roads can be difficult there. So my initial instinct was to say
>>> leave the ways in that part of Colorado as tracks as it can be hard
>>> to tell on the imagery.

>>> But looking at the satellite imagery in the area you linked, they
>>> clearly look like unpaved residential roads and dirt driveways.

>>> I’d leave the driveways in but change the tagging to:

>>> highway=service
>>> service=driveway
>>> surface=unpaved
>>> access=private

>> I would do almost the same, but would leave out the access=private,
>> as this is difficult to determine from the aerial imagery, and is
>> implied for service=driveway anyway.

> I would strongly dispute "implied for service=driveway anyway" - in
> some cases service=driveway is accessible for everybody, in
> many cases it is accessible at least for foot traffic.

I agree that at least in most of Europe it would usually be
access=destination rather than access=private. However, I don't
think that any routing engine should route through traffic over
service=driveway.

> In case of known access=private access it should be tagged explicitly.

I agree; but we were talking about "armchair mapping" and in
that case you usually would not know what access rights applied
on the ground, so you should not add an access tag based on a guess.

Wolfgang

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

Re: [Tagging] highway = track vs. residential

[Mateusz Konieczny]

On Sat, 9 Jan 2016 15:02:19 +0100
Wolfgang Zenker  wrote:

> * Mateusz Konieczny  [160109 13:12]:
> > On Fri, 8 Jan 2016 10:50:37 +0100
> > Wolfgang Zenker  wrote:
> 
> >> * Tod Fitch  [160107 23:35]:
> >>> My parents house is in a pretty rural part of Arizona and
> >>> distinguishing between tracks and driveways or even residential
> >>> roads can be difficult there. So my initial instinct was to say
> >>> leave the ways in that part of Colorado as tracks as it can be
> >>> hard to tell on the imagery.
> 
> >>> But looking at the satellite imagery in the area you linked, they
> >>> clearly look like unpaved residential roads and dirt driveways.
> 
> >>> I’d leave the driveways in but change the tagging to:
> 
> >>> highway=service
> >>> service=driveway
> >>> surface=unpaved
> >>> access=private
> 
> >> I would do almost the same, but would leave out the access=private,
> >> as this is difficult to determine from the aerial imagery, and is
> >> implied for service=driveway anyway.
> 
> > I would strongly dispute "implied for service=driveway anyway" - in
> > some cases service=driveway is accessible for everybody, in
> > many cases it is accessible at least for foot traffic.
> 
> I agree that at least in most of Europe it would usually be
> access=destination rather than access=private. However, I don't
> think that any routing engine should route through traffic over
> service=driveway.

I would expect routers for foot and bicycle traffic to use
also ways with service=driveway (except ones explicitly tagged as
private).

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

Re: [Tagging] Feature proposal - Voting - Location transitions

[Tom Pfeifer]

ajt1...@gmail.com wrote on 2016/01/09 14:29:

On 08/01/2016 23:09, François Lacombe wrote:

Hi all,

The vote vote session for the location transition proposal is now open.
http://wiki.openstreetmap.org/wiki/Proposed_features/Location_transitions

As described, location:transition=yes may enable mappers to indicate
the location of a feature is changing without using fixme or
approximative ways (when guessing where a feature goes underground).

It would be great you spend a little time to write a feedback at the
bottom of the page.



Having read that page I don't really understand what the motivation for it is.  
Maybe add a bit more information explaining how this new tag will provide 
information that isn't automatically apparent from other tags already present?  
For example, if a road
goes into a tunnel the bit not in a tunnel has no "tunnel" tag and the bit in the tunnel 
does; in that situation what extra information does a "location transition" provide?


It appears to me a bit like noexit=yes on a road, i.e. when the visible part
of the pipeline ends the tag would indicate that the pipe indeed goes 
underground,
and the osm-way does not end just because the mapper got tired or the hires 
aerial
turned lowres.

tom

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

Re: [Tagging] Feature proposal - Voting - Location transitions

[Dominic Coletti]

Can you provide an example for this situation please ?

I think about power=substation + substation=transition but several
different features can emerge from it and location:transition may indicate
where exactly in the given substation (which goes nowhere itself)

I think one example is with subway tunnel portals.


On Sat, Jan 9, 2016 at 5:49 AM François Lacombe 
wrote:

>
> Le 9 janv. 2016 10:22 AM, "Martin Koppenhoefer" 
> a écrit :
> >
> > this is currently proposed to be used only on nodes, but might be useful
> for polygons as well.
> >
> > cheers,
> > Martin
>
> Hi Martin
>
> Can you provide an example for this situation please ?
>
> I think about power=substation + substation=transition but several
> different features can emerge from it and location:transition may indicate
> where exactly in the given substation (which goes nowhere itself)
>
> Cheers
>
> François
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-- 
Dominic Coletti
President & CEO
3Dreams Design
205 Anamoor Dr
Cary, NC 27513
(919) 463-9554

NOTICE: This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Removing name_1 and alt_name_1 from Wiki

[Hakuch]

I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.
Most mappers reject tagging with _x suffixes and it makes no sense to
have them in the wiki as a scheme for good mapping.

[I also started a discussion in the wiki:
http://wiki.openstreetmap.org/wiki/Talk:Names#Removing_Tags_name_1_and_alt_name_1_from_wiki]

**better use diverse name-tags**

Mappers should be motivated to use semantic more rich name-tags like
loc_name, old_name, short_name and so on. If theere is a name that does
not fit in this scheme, alt_name can be used. If there are multiple
names that does not fit, alt_name can be used with semicolons.

**semicolons instead of _1 suffixes**

Semicolons for multiple values have already been established even though
some mappers don't like them. Precise tags should always be preferred
(like the mentioned diverse name-tags), but we should
not use _1 suffixed tags instead of semicolons. Their only advantage is
the better legibility for human eyes, thats a reason why some people may
favour them over the semicolon. But for mechanical computation, it is
easier to regex the semicolon than crawling through all possible
existing suffixed tags. Furthermore the semicolon is already established
and has been accepted for such special cases with multiple values.

**iD-Editor problem**

unfortunately, the iD-editor is creating such prefixed tags and is
training newbies to use them as a good tagging practice. When you use
the raw-tag-editor and tries to add an already existing tag, iD does not
throw any error or information but adds the tag with a suffixed number
like _1 or higher.
It suggests to the unexperienced mapper, that this is a usable method to
add multiple values, although this suffixing is only made to prevent the
user of deleting data.
We still couldn't convince the developer, that this suffixing method
leads new mappers to bad practice
(https://github.com/openstreetmap/iD/issues/2896).

**how the name_1 and alt_name_1 came to the wiki-heaven**

But actually, my intention was to propose the removing or marking of
name_1 and alt_name_1 tags in the wiki (the iD problem should be
discussed in a new topic). Inititally, the alt_name_1 tag has been added
by a Nominatim developer in Nov'14. The origin for this decision can be
found in this discussion on talk
(https://www.mail-archive.com/talk%40openstreetmap.org/msg50648.html)
that took place in Sept'14.

There, a member of the HOT team described a problem, that their manual
massedit caused the tags alt_name:2 and alt_name_2. Now he wants to have
a mechanical edit to change all alt_name:2 to alt_name_2, preferably
worldwide. That also caused a readable discussion about the sense of
suffixed tags. But already before starting that discussion, the author
asked the nominatim team for adding the alt_name_x tags
to the nominatim search. And the Nominatim developer did so and
consequently added it two month later to the wiki.
Today there are over 5500 alt_name_1 tags. But only a few of them
outside of the mentioned HOT-area in western africa. Nearly half of
them, are NOT combinated with alt_name!

The tag name_1 was not proposed in any way, this one has only been added
in Aug'15 because it exists in the database. By comment "Document
de-facto name_N variant". That is true, currently there are about
800.000 tags with name_1. But when you look on the taginfo map, or the
combinations, you can see that almost each of them results from the
Tiger-Import (https://taginfo.openstreetmap.org/keys/name_1#map,
https://taginfo.openstreetmap.org/keys/name_1#combinations). That
tagging-scheme should not be proposed in the wiki for using.

It even makes less sense to have alt_name_1 AND name_1 because they do
not differ in any way.

**tl;dr**

I propose removing the name_1 and alt_name_1 from the Map Features or
rather marking them and to explain that and why they should not be used.
And after that we can convince iD Editor to stop creating them
automatically :)

german readers can also take a look into this discussion in forum:
http://forum.openstreetmap.org/viewtopic.php?id=53223


0x3CBE432B.asc
Description: application/pgp-keys
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - Voting - Location transitions

[Marc Gemis]

What about a pole where the cable continues both overhead and
underground ? This is a pretty common case in Belgium. The overhead
cables are on one side of the street and in order to connect the
houses on the other side of the road, the cable also continues under
the ground.

See e.g. [1], [2] where  [2] is a close up of the pole in front of the
house in [1]

regards

m

[1] https://xian.smugmug.com/OSM/OSM-2016/2016-01-01-Bekkerzeel-Asse/i-Kwh3PML
[2] https://xian.smugmug.com/OSM/OSM-2016/2016-01-01-Bekkerzeel-Asse/i-CDmDTdP

On Sat, Jan 9, 2016 at 7:47 PM, Dominic Coletti
 wrote:
>
> Can you provide an example for this situation please ?
>
> I think about power=substation + substation=transition but several different
> features can emerge from it and location:transition may indicate where
> exactly in the given substation (which goes nowhere itself)
>
> I think one example is with subway tunnel portals.
>
>
>
> On Sat, Jan 9, 2016 at 5:49 AM François Lacombe 
> wrote:
>>
>>
>> Le 9 janv. 2016 10:22 AM, "Martin Koppenhoefer"  a
>> écrit :
>> >
>> > this is currently proposed to be used only on nodes, but might be useful
>> > for polygons as well.
>> >
>> > cheers,
>> > Martin
>>
>> Hi Martin
>>
>> Can you provide an example for this situation please ?
>>
>> I think about power=substation + substation=transition but several
>> different features can emerge from it and location:transition may indicate
>> where exactly in the given substation (which goes nowhere itself)
>>
>> Cheers
>>
>> François
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> --
> Dominic Coletti
> President & CEO
> 3Dreams Design
> 205 Anamoor Dr
> Cary, NC 27513
> (919) 463-9554
>
> NOTICE: This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this email in error please notify the system
> manager. This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and delete
> this e-mail from your system. If you are not the intended recipient you are
> notified that disclosing, copying, distributing or taking any action in
> reliance on the contents of this information is strictly prohibited.
>
> ___
> 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] Removing name_1 and alt_name_1 from Wiki

[Martin Koppenhoefer]

sent from a phone

> Am 09.01.2016 um 19:50 schrieb Hakuch :
> 
> I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.


I agree, also with the change of iD to stop making indexed tags like this.

cheers 
Martin 

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

Re: [Tagging] Feature Proposal - Voting - Aquatics centre

[Matthijs Melissen]

On 5 January 2016 at 11:25, Tom Pfeifer  wrote:
> I think the proposal has been rushed into voting prematurely, with just 5
> days
> from draft on 25 Dec, during the holiday seasons where many people might be
> mapping away from home ;-)

It was in fact 7 days, but your point is still standing. Some users
have requested an extension of the voting period. I doubt an extension
will change the outcome of either of the proposals (Aquatics centre
and Discourage amenity=swimming pool), but if people prefer more time
I don't mind either. I therefore have extended the voting period for
both proposals by an additional week.

-- Matthijs

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

[Tagging] Feature Proposal - Voting (reminder) - Aquatics centre

[Matthijs Melissen]

Hi all,

Voting on the proposal for the tag leisure=aquatics_centre is still
open. You can vote here:

http://wiki.openstreetmap.org/wiki/Proposed_features/Aquatics_centre

On request, the voting period has been extended by an additional 7 days.

Thanks in advance to anybody voting on this proposal.

-- Matthijs

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

[Tagging] Feature Proposal - Voting (reminder) - Discourage amenity=swimming_pool

[Matthijs Melissen]

Hi all,

Voting on the proposal to discourage amenity=swimming_pool is now
open. You can vote here:

http://wiki.openstreetmap.org/wiki/Proposed_features/Discourage_amenity%3Dswimming_pool

On request, the voting period has been extended by an additional 7 days.

Thanks in advance to anybody voting on this proposal.

-- Matthijs

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

Re: [Tagging] Tagging tourist offices

[Matthijs Melissen]

On 1 January 2016 at 22:55, Matthijs Melissen  wrote:
> So my question is, would it make sense to propose a different tagging
> for tourist offices, for example tourism=tourist_office or
> office=tourism? Or should we stay with the current tagging? I'm myself
> quite ambivalent on this issue, and I'd like to hear your opinion.

Thanks Martin and Eugene for your comments.

There does not seem to be much interest to change the tagging, so I
will not continue with any proposal in this direction.

-- Matthijs

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

[Tagging] Public buildings

[Matthijs Melissen]

Hi all,

The tag amenity=public_building has been marked as 'Don't use' on the
wiki since 2010 (see
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_building ). As
far as I know, marking the tag as 'Don't use' has not been discussed
extensively, and the tag is still very commonly used (111 941 times
currently). I therefore think it would be worth to discuss this tag
once more.

Initially I didn't have much problems with this tag, and I have used
it commonly to mark government buildings. However, when I started
looking at how this tag is used (with Overpass), I discovered that it
is indeed use for quite a variety of things. It saw it being used for
government buildings, train stations, expo halls, art centres,
municipal sport centres, and band stands, amongst others. Nearly all
of these have more specific other tags.

In particular, potential replacement tags for government tags are
office=administrative (26 836 times in use) for central government and
office=administrative (8 725) for local government.

I think we have a choice of two options:
1. Accept the tag - in that case we'd need to come up with a clear
definition, and decide how it compares to the office=administrative
and office=administrative tags.
2. Reject the tag and mark it as discouraged on the wiki..

The tag is currently supported by JOSM, but not by iD. If we decide to
approve this tag, it would make sense to ask iD to support it. On the
other hand, if we decide to discourage it, it would make sense to ask
JOSM to remove the preset, and preferably, even add a deprecation
warning to the validator.

What do you think? Which way would you prefer to go?

-- Matthijs

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

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Marc Zoutendijk]

> Op 9 jan. 2016, om 19:50 heeft Hakuch  het volgende 
> geschreven:
> 
> I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.

I agree.

Marc.



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

Re: [Tagging] Public buildings

[Andy Townsend]

‎With a "data consumer" hat on, I did look at the usage of 
"amenity=public_building" in the UK over Christmas. I really wasn't able to 
read anything into it - its use locally included public toilets and "government 
functions" that are actually outsourced to a third-party, as well as the 
bandstands that you mention. 

What might be interesting (and what I didn't do unfortunately) would be to 
sample a bunch of them and suggest better alternatives - maybe in changeset 
discussions?

  Original Message  
From: Matthijs Melissen
Sent: Saturday, 9 January 2016 21:24
To: Tag discussion, strategy and related tools
Reply To: Tag discussion, strategy and related tools
Subject: [Tagging] Public buildings

Hi all,

The tag amenity=public_building has been marked as 'Don't use' on the
wiki since 2010 (see
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_building ). As
far as I know, marking the tag as 'Don't use' has not been discussed
extensively, and the tag is still very commonly used (111 941 times
currently). I therefore think it would be worth to discuss this tag
once more.

Initially I didn't have much problems with this tag, and I have used
it commonly to mark government buildings. However, when I started
looking at how this tag is used (with Overpass), I discovered that it
is indeed use for quite a variety of things. It saw it being used for
government buildings, train stations, expo halls, art centres,
municipal sport centres, and band stands, amongst others. Nearly all
of these have more specific other tags.

In particular, potential replacement tags for government tags are
office=administrative (26 836 times in use) for central government and
office=administrative (8 725) for local government.

I think we have a choice of two options:
1. Accept the tag - in that case we'd need to come up with a clear
definition, and decide how it compares to the office=administrative
and office=administrative tags.
2. Reject the tag and mark it as discouraged on the wiki..

The tag is currently supported by JOSM, but not by iD. If we decide to
approve this tag, it would make sense to ask iD to support it. On the
other hand, if we decide to discourage it, it would make sense to ask
JOSM to remove the preset, and preferably, even add a deprecation
warning to the validator.

What do you think? Which way would you prefer to go?

-- Matthijs

___
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] Public buildings

[Warin]

I would have the wiki page 'amenity=public_building' redirect to 
'building=public' and then any alternatives suggested on that page.


On 10/01/2016 8:54 AM, Andy Townsend wrote:

‎With a "data consumer" hat on, I did look at the usage of "amenity=public_building" in 
the UK over Christmas. I really wasn't able to read anything into it - its use locally included public 
toilets and "government functions" that are actually outsourced to a third-party, as well as the 
bandstands that you mention.

What might be interesting (and what I didn't do unfortunately) would be to 
sample a bunch of them and suggest better alternatives - maybe in changeset 
discussions?

   Original Message
From: Matthijs Melissen
Sent: Saturday, 9 January 2016 21:24
To: Tag discussion, strategy and related tools
Reply To: Tag discussion, strategy and related tools
Subject: [Tagging] Public buildings

Hi all,

The tag amenity=public_building has been marked as 'Don't use' on the
wiki since 2010 (see
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_building ). As
far as I know, marking the tag as 'Don't use' has not been discussed
extensively, and the tag is still very commonly used (111 941 times
currently). I therefore think it would be worth to discuss this tag
once more.

Initially I didn't have much problems with this tag, and I have used
it commonly to mark government buildings. However, when I started
looking at how this tag is used (with Overpass), I discovered that it
is indeed use for quite a variety of things. It saw it being used for
government buildings, train stations, expo halls, art centres,
municipal sport centres, and band stands, amongst others. Nearly all
of these have more specific other tags.

In particular, potential replacement tags for government tags are
office=administrative (26 836 times in use) for central government and
office=administrative (8 725) for local government.

I think we have a choice of two options:
1. Accept the tag - in that case we'd need to come up with a clear
definition, and decide how it compares to the office=administrative
and office=administrative tags.
2. Reject the tag and mark it as discouraged on the wiki..

The tag is currently supported by JOSM, but not by iD. If we decide to
approve this tag, it would make sense to ask iD to support it. On the
other hand, if we decide to discourage it, it would make sense to ask
JOSM to remove the preset, and preferably, even add a deprecation
warning to the validator.

What do you think? Which way would you prefer to go?

-- Matthijs

___
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] Removing name_1 and alt_name_1 from Wiki

[Dave Swarthout]

On Sun, Jan 10, 2016 at 4:32 AM, Marc Zoutendijk 
wrote:

> > I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.
>

Agree


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com

This
email has been sent from a virus-free computer protected by Avast.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Public buildings

[Daniel Koć]

W dniu 09.01.2016 23:03, Warin napisał(a):

I would have the wiki page 'amenity=public_building' redirect to
'building=public' and then any alternatives suggested on that page.


+1

--
"Завтра, завтра всё кончится!" [Ф. Достоевский]

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

Re: [Tagging] Feature Proposal - Voting - Aquatics centre

[Tom Pfeifer]

Matthijs Melissen wrote on 2016/01/09 21:38:

On 5 January 2016 at 11:25, Tom Pfeifer wrote:

I think the proposal has been rushed into voting prematurely, with just 5 days
from draft on 25 Dec, during the holiday seasons where many people might be
mapping away from home ;-)


It was in fact 7 days,


This is somehow true, but there are several excuses I could choose from:

- I'm notoriously bad in simple arithmetic, that's why I started building 
computers,
- being into computers, you can have a off-by-one-error on both ends of this 
holiday week,
- in this particular week, the movements of Santa Claus cause time-warps.

tom

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

Re: [Tagging] Public buildings

[Matthijs Melissen]

On 9 January 2016 at 23:03, Warin <61sundow...@gmail.com> wrote:
> I would have the wiki page 'amenity=public_building' redirect to
> 'building=public' and then any alternatives suggested on that page.

To me it is not clear that this is a solution, as the definition of
building=public is equally vague. Is a prison a public building? A
band stand? A theatre? A bus depot?

-- Matthijs

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

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Jo]

I agree too, FWIW.

Polyglot

2016-01-09 23:25 GMT+01:00 Dave Swarthout :

>
> On Sun, Jan 10, 2016 at 4:32 AM, Marc Zoutendijk 
> wrote:
>
>> > I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.
>>
>
> Agree
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
> 
>  This
> email has been sent from a virus-free computer protected by Avast.
> www.avast.com
> 
> <#-688897245_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> ___
> 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] Public buildings

[Tom Pfeifer]

Daniel Koć wrote on 2016/01/09 23:41:

W dniu 09.01.2016 23:03, Warin napisał(a):

I would have the wiki page 'amenity=public_building' redirect to
'building=public' and then any alternatives suggested on that page.


+1


-1

Both 'amenity=public_building' and 'building=public' are problematic,
but for different reasons. Merging their wiki representations mixes the
arguments against both, and makes improvements even more difficult.

'amenity=public_building' is an unspecific use of the amenity key, and
should be replaced with a more specific value.

'building=public' describes some form of accessibility using a key
that should describe the architectural type of a building.

tom

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

Re: [Tagging] Public buildings

[Daniel Koć]

W dniu 10.01.2016 0:20, Tom Pfeifer napisał(a):


Both 'amenity=public_building' and 'building=public' are problematic,


Sure.


but for different reasons. Merging their wiki representations mixes the
arguments against both, and makes improvements even more difficult.

'amenity=public_building' is an unspecific use of the amenity key, and
should be replaced with a more specific value.

'building=public' describes some form of accessibility using a key
that should describe the architectural type of a building.


Just for the record: "accessibility" brings some unwanted connection 
with "access" key, which we're not discussing now, as far as I 
understand.


You could be right, but IIRC when discussing church example I was once 
told that it's not that building=church+amenity=museum is about 
describing form (building) and function (amenity), as I thought. And 
indeed, we have some pretty popular tags like building=retail (~200k 
uses), which is mixing these two factors.


But if we really want to separate form and function, it would be better 
to not have something "amenity=public_building" (rather "amenity=yes" in 
general, when in doubt), while "building=public" sounds more reasonable 
for me (general category for building types other than for private 
people to live in).


--
"Завтра, завтра всё кончится!" [Ф. Достоевский]

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

Re: [Tagging] Feature proposal - Voting - Location transitions

[François Lacombe]

HI all,

2016-01-09 19:47 GMT+01:00 Dominic Coletti :
>
> Can you provide an example for this situation please ?
>
> I think about power=substation + substation=transition but several different
> features can emerge from it and location:transition may indicate where
> exactly in the given substation (which goes nowhere itself)
>
> I think one example is with subway tunnel portals.

Not exactly : to be really precise, the portal may be a man_made or
building feature and shouldn't get the location:transition tag.
The subway line way feature should (maybe this is was you thought about)
Nevertheless this example fits completely the current proposal

2016-01-09 20:10 GMT+01:00 Marc Gemis :
> What about a pole where the cable continues both overhead and
> underground ? This is a pretty common case in Belgium. The overhead
> cables are on one side of the street and in order to connect the
> houses on the other side of the road, the cable also continues under
> the ground.

Just add location:transition=yes on the pole where the underground
cable gets connected to the overhead line.
The underground cable location changes to allow a connection overhead.

You can quick map utility wires and low voltage lines along road
according to this proposal of brycenesbitt (different tagging on
highway feature itself without any location:transition usage)
http://wiki.openstreetmap.org/wiki/Proposed_features/Quickly_Marking_Utility_Wires


All the best

François

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

Re: [Tagging] Public buildings

[Warin]

On 10/01/2016 10:56 AM, Daniel Koć wrote:

W dniu 10.01.2016 0:20, Tom Pfeifer napisał(a):


Both 'amenity=public_building' and 'building=public' are problematic,


Sure.

+1
If you search on the wiki for 'public building' you get 
amenity=public_building ... I think it should suggest building=public as 
the first preference.



but for different reasons. Merging their wiki representations mixes the
arguments against both, and makes improvements even more difficult.

'amenity=public_building' is an unspecific use of the amenity key, and
should be replaced with a more specific value.

Probably more than one value!


'building=public' describes some form of accessibility using a key
that should describe the architectural type of a building.


In some parts of the world .. 'public buildings' do have an 
'architectural style'.
Just for the record: "accessibility" brings some unwanted connection 
with "access" key, which we're not discussing now, as far as I 
understand.


+1 But I think I know what Tom is getting at, Public as in open to the 
public.


You could be right, but IIRC when discussing church example I was once 
told that it's not that building=church+amenity=museum is about 
describing form (building) and function (amenity), as I thought. And 
indeed, we have some pretty popular tags like building=retail (~200k 
uses), which is mixing these two factors.


The requirements of the building occupiers do result in set 
relationships between form (how it looks) and function (what it gets 
used for).
However that are exceptions - a corner store can be used as a residence, 
resulting in building=retail, landuse=residential. Despite the 
occasional 'customer' entering the bedroom for a loaf of bread.


But if we really want to separate form and function, it would be 
better to not have something "amenity=public_building" (rather 
"amenity=yes" in general, when in doubt), while "building=public" 
sounds more reasonable for me (general category for building types 
other than for private people to live in).


building=public allows for those buildings that have some architectural 
style that says 'public building'.
amenity=public_building conveys  Here is a building .. that is 
public .. but the function (amenity) is unknown? So why not use the 
clearer building=public? 'We' may prefer more specific tagging .. but in 
some places that may not be possible. And those that want to tag more 
information will then be looking elsewhere as to what they want to tag 
... amenity=toilets for instance. Or amenity=shelter.



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

Re: [Tagging] Public buildings

[John Willis]

> On Jan 10, 2016, at 8:01 AM, Matthijs Melissen  
> wrote:
> 
> To me it is not clear that this is a solution, as the definition of
> building=public is equally vague. Is a prison a public building? A
> band stand? A theatre? A bus depot?

A building operated by a government agency or by a private operator for the 
"public use" or "public good" is my take. 

But we chop this up. 

Museums. 
City Halls
Community Centers. 
Sports centres
Stadiums and arenas 
Etc.

So having a generic definition where we all ready have more specific ones leads 
to catch-all - so some people throw everything in. 

Building=civic also exists, but has no accompanying land use (yet) for the vast 
amount of "civic administrative" centers and offices. 

If we further define these common "public" building types - true government 
stuff like tax and pension and immigration and other almost purely governmental 
facilities - not only do we get more detailed building definitions, but a 
landuse or two to accurately map the complexes they invariably are part of in 
first world nations. 

This lack of good building sets and missing landuse has, in my opinion, made 
most government and public offices/facilities unmappable in the current methods 
used by commercial/residential/industrial buildings and their complexes.  

Getting public/civic/whatever decided and fully fleshed out and a proper 
landuse(s) to go with it will really help bring them up to "first class 
citizens" - and help make a single process (landuse/building sets) work 
everywhere. 

When I first started - trying to map a train station in the same way as a 
factory or apartment complex completely flummoxed me. There were totally 
different rules for mapping the land and the station and everything.  

This is the same for civic office buildings - and since my mapping area (Japan) 
is heavily coated with government complex after government complex - being able 
to map them (and their functions) properly and in a consistent way to the other 
buildings would be appreciated. 

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

Re: [Tagging] Public buildings

[Warin]

On 10/01/2016 2:14 PM, John Willis wrote:


On Jan 10, 2016, at 8:01 AM, Matthijs Melissen  wrote:

To me it is not clear that this is a solution, as the definition of
building=public is equally vague. Is a prison a public building? A
band stand? A theatre? A bus depot?

A building operated by a government agency or by a private operator for the "public use" 
or "public good" is my take.

But we chop this up.

Museums.
City Halls
Community Centers.
Sports centres
Stadiums and arenas
Etc.

So having a generic definition where we all ready have more specific ones leads 
to catch-all - so some people throw everything in.

Building=civic also exists, but has no accompanying land use (yet) for the vast amount of 
"civic administrative" centers and offices.

If we further define these common "public" building types - true government 
stuff like tax and pension and immigration and other almost purely governmental 
facilities - not only do we get more detailed building definitions, but a landuse or two 
to accurately map the complexes they invariably are part of in first world nations.

This lack of good building sets and missing landuse has, in my opinion, made 
most government and public offices/facilities unmappable in the current methods 
used by commercial/residential/industrial buildings and their complexes.

Getting public/civic/whatever decided and fully fleshed out and a proper landuse(s) to go 
with it will really help bring them up to "first class citizens" - and help 
make a single process (landuse/building sets) work everywhere.

When I first started - trying to map a train station in the same way as a 
factory or apartment complex completely flummoxed me. There were totally 
different rules for mapping the land and the station and everything.

This is the same for civic office buildings - and since my mapping area (Japan) 
is heavily coated with government complex after government complex - being able 
to map them (and their functions) properly and in a consistent way to the other 
buildings would be appreciated.


To me an office building could be used for any administrative work.
Government department sections here change locations - the education department 
human resources can move to another location ... even swap with another section.

So the building and its land use remains the same. If the office key is used 
then that can indicate the change.. except that office=government sub key 
government is severely limited...


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

Re: [Tagging] Public buildings

[Martin Koppenhoefer]

sent from a phone

> Am 09.01.2016 um 22:22 schrieb Matthijs Melissen :
> 
> What do you think? Which way would you prefer to go?


I'd recommend to use more specific tags and discourage usage. I suspect this 
tag is basically coming from the early days, someone looking at a map where 
public buildings were highlighted in some way (eg coloured red) and so to be 
able to do the same, the tag was introduced.

The information is very rough and not fitting well into the tagging system 
(there's a lot of overlap with more specific tags, e.g. 
amenity=police/courthouse/prison/townhall/fire_station/...). There is no 1:1 
relationship between the rendered map and the tags, we don't need to tag 
amenity=public_building to be able to highlight them in the rendering if we 
wish so.

On the other hand, we are still lacking a comprehensive system for government 
offices and agencies, office=administrative is quite generic as well (you could 
also say inherently redundant, any office is about administration, isn't it?), 
and doesn't bear the public aspect that public building expresses.

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

Re: [Tagging] Public buildings

[Martin Koppenhoefer]

sent from a phone

> Am 10.01.2016 um 00:01 schrieb Matthijs Melissen :
> 
> To me it is not clear that this is a solution, as the definition of
> building=public is equally vague. Is a prison a public building? A
> band stand? A theatre? A bus depot?


+1, it's actually worse: public is referring to a function, building=* is 
referring to the architectural type, e.g. something physical.


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