Re: [Tagging] Tagging of State Parks in the US

[Kevin Kenny]

On Mon, Jul 29, 2019 at 6:02 PM Martin Koppenhoefer
 wrote:
> > On 29. Jul 2019, at 16:37, Kevin Kenny  wrote:
> > There are other historic sites embedded in the park
> are all these sites mentioned to be part of the state park, or do they simply 
> happen to be within the boundaries?

I'm not sure what you mean by the question.

Many parks over here have 'inholdings', which are other land in the
parks not owned or managed by the park administration. I'm consistent
about mapping those, which is why park boundaries are usually
multipolygons.

The sites that I mentioned in Bear Mountain are mostly administered by
the park administration. The inns are operated by a contractor (but
the operator is responsible to the park management), the hiking trails
are maintained by an NGO, and the research reserve is some sort of
cooperative arrangement with NYS Department of Environmental
Conservation and a couple of other government agencies, and I don't
know the all the details. To a visitor, all but the last are 'part of'
the park. (The research reserve has more restricted access, but is
still managed in part by the park under the cooperative agreement.)

The park's boundaries are exactly (well, to within the limits of the
data source, which is not 100% trustworthy, but I verified against
highway, railroad and river alignment, and against a couple of other
data sources for the boundary with West Point) as shown by the
multipolygon https://www.openstreetmap.org/relation/6467468. The
rights-of-way for the railroad and the highways, and both of the
settlements that I mentioned, are not part of the park, and are cut
out of the multipolygon. I didn't need to use inner ways for those,
simply because they all connect to the world outside, but we do have
protected areas with quite complex topologies indeed:
https://www.openstreetmap.org/relation/6365096 is an example and
https://www.openstreetmap.org/relation/6362702 is a worse one that
took many hours to map. even with the aid of an import. (I *don't*
just drop imported data in blindly!)  The Fort Montgomery historic
site is technically a separate site (Fort Clinton *is* part of Bear
Mountain State Park), and is mapped thus - but it, Bear Mountain, and
Harriman and Sterling Forest to the west are under common management.

Yes, one of the inn buildings encroaches on the Palisades Parkway
right-of-way. The agencies that administer those two objects are
friendly.

The concessionaires rent their stalls.

The rest of the historic sites, I've not done the research to see if
they're listed. Many of them are off limits - you're supposed to stay
on trail in the backcountry in that park (because many of the old
industrial sites are still hazardous - they don't want people falling
down mine shafts or being injured by abandoned and decaying
machinery). Doodletown has interpretive signs at a lot of its ruins,
so I wouldn't be surprised to find NRHP listings there, but I haven't
yet looked.

I'm not sure what I'd do with a site relation here. I'd use it, if for
instance, the park had an office occupying part of a building that
wasn't in the park, so I'd need a node for that. I've done site
relations for urban universities that have outreach programs in
off-campus space, but why bother with a site when a multipolygon will
do?

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

Re: [Tagging] Charging stations: socket::output -- which format for the value?

[Warin]

The use of 'multipliers' is common ..

As well as kilometers per hour (100 kmh would be come 100,000 mh without 
the multiplier) there is mass kg and tonnes .. (10kg would be come 
10,000 g with the multiplier) , elevation in meters and kilometers etc.


Preference should be for what is commonly used for that particular 
amount and feature.


I would leave this alone - let the mapper use that thing that should be 
applied - common sense.


On 29/07/19 21:00, dktue wrote:
I'd vote for kW aswell (and a value of "22" then), since we're not 
always using SI and not always base-unit-values (see kilometers per hour).


Am 29.07.2019 um 12:53 schrieb Martin Koppenhoefer:



Am Mo., 29. Juli 2019 um 12:39 Uhr schrieb dktue 
mailto:em...@daniel-korn.de>>:


Hello,

the OSM-Wiki-page on charging stations [1] defines the tag
socket::output=watt

wheres the examples contain values like "22 kW".

What would the preferred format be? "22000" or "22 kW"? I would
like to
clearify this on the wiki-page.

Personally I would prefer "22000" as it fits with other
OSM-values (no
units).



generally people are encouraged to add units for disambiguation 
reasons and to use locally used units and preferably SI units.


For power, no default units are currently specified on this page:
https://wiki.openstreetmap.org/wiki/Map_Features/Units

And it doesn't even mention horsepower for power, a unit that for 
many people may be more evocative than Watt (everybody can imagine 30 
horses, but how much are 22 kW?) ;-)


Personally, if we were to set up a default for power units, I would 
prefer kW, because if we'd use Watt we will get very high numbers for 
MW (e.g. needed for power generators). Presuming, we would have the 
same standard unit for all things power, and not different defaults 
for socket and say power stations.


Cheers,
Martin



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

Re: [Tagging] Tagging of State Parks in the US

[Joseph Eisenberg]

-1 to a site relation for an area with a defined outer boundary.

Relation = boundary (and =multipolygon) works fine for defining an area,
and you can make holes to exclude at my “outparcels” or villages which are
not part of the official protected area.

Mappers don’t need to add things to relations when the geometry is enough
to show that node A isi side of area B.

Joseph



On Tue, Jul 30, 2019 at 7:02 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 29. Jul 2019, at 16:37, Kevin Kenny  wrote:
> >
> > There are other historic sites embedded in the park
>
>
> are all these sites mentioned to be part of the state park, or do they
> simply happen to be within the boundaries?
> If the definition of the park is a list of areas and sites, maybe a site
> relation would be appropriate: you can specify a perimeter and also add
> stuff inside (not only polygons but also nodes and ways). If legislation
> said the park is made up of A, B, C, D and E, it would be comprehensive if
> we modeled it as an object with A, B, C, D and E as members.
>
> 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] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Warin]

On 30/07/19 02:55, Dave F via Tagging wrote:
I believe the main reason isn't (& probably shouldn't) deprecated is 
that it allows entities which are unused but still physically there, 
to be rendered. disused:*=* aren't rendered on the 'standard' render.


That is a problem with that particular render. It is not a tagging problem.

If that particular render failed to display some other feature .. would 
mappers then resort to tagging it some other way so it renders on that 
particular render???


It appears that in order to get mappers to use the correct tagging one 
particular render has to stop showing the 'obsolete' and 'depreciated' tags.

Similarly for incorrect mapping of relations with shared ways etc etc.


Mean while I am using tags that simply don't render on that particular 
render .. because they are the absolutely correct tags to use for those 
features.

I think too many are 'tagging for one renderer'.



Davef

On 29/07/2019 07:23, Joseph Eisenberg wrote:

I was going to fix the status of abandoned=yes which is currently
incorrectly listed as "obsolete". I thought it was probably
deprecated, since the wiki page was deleted when Key:abandoned:*
(namespaced) was made in 2015, but it's still used 40,000 times.

The key disused (mainly disused=yes) is also used 60,000 times, even
though the situation is the same: no wiki page, and the Key:disused:
page suggests it is deprecated.

Should these two be added to deprecated features, or should I recreate
the deleted pages and change the status to something other than
obsolete/deprecated?

I see that there was just a mention added that landuse=quarry plus
disused=yes might be more sensible than disused:landuse=quarry.

Joseph




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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Kevin Kenny]

On Mon, Jul 29, 2019 at 4:20 PM Mateusz Konieczny
 wrote:
> I would say that use is deprecated for things like shop=* and in use
> for things like quarries, buildings, adits, bunkers etc

I wind up using a lifecycle prefix mostly when the former use is
recognizable, but there is another tag for what the thing has become.

Hence, combinations like 'highway=footway
abandoned:railway=narrow_gauge' (where aspects of the railroad can
still be seen) or 'landuse=brownfield disused:amenity=prison' (a
closed prison that the state is trying to redevelop for other uses),
or 'tourism=attraction historic=ruins ruins:building=hotel"
(historically important, burnt to the ground about eighty years ago,
the remaining stonework is architecturally interesting, and it's a
popular hiking destination)

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Joseph Eisenberg]

I think you might be referring to this proposal from Zverik last
summer, which suggests stopping using
public_transport=stop_position/platform/station, but keeps the
relations:
https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport

- =stop_position is not really needed for routing; doubles work for mappers
=platform is ambiguous; use =bus_stop, highway=platform (if the bus
stop has a physical platform) railway=platform etc
= public_transport=station is not specific, use amenity=bus_station,
railway=station etc).

re: > "It's hard to ascertain precisely why PT was originally created"

According to this comment, it started with imports, and a dispute
between English mappers and a few Central European mappers (or just
one?): back in 2010 there were 200,000 highway=bus_stop mapped beside
the road in England, at the location of the bus stop sign. But there
was data available in Switzerland that could be imported that had the
node in the center of the highway, probably for bus operator purposes,
and a mapper started importing these and changed the wiki to say this
was better. There was a dispute about this. To resolve it, the
proposal that was eventually approved created specific tags for
stop_position (on the highway) which could use access tags like
"bus=yes" to specify the vehicle and "platform" (for the bus stop),
and a stop_area relation.

This wasn't sufficient information to render bus stops differently
than tram / light rail platforms, so the original tagging method
remained more common up until now.

This hasn't stopped some mappers  from claiming that there is a
"version 2" of mapping for transit which should replace the "old"
tags, and editing the wiki pages to put this view at the forefront,
going so far as to suggest public_transport=platform and =station for
ferry terminals and taxi stops, where this tagging is very rare.

I've made to various wiki pages to describe the current situation. I'm
also working on making specific wiki pages for tags like bus=yes (used
for both access restrictions and to specify the type of public
transport vehicle at a feature).

Joseph

On 7/30/19, Dave F via Tagging  wrote:
> Hi
>
> This is not a criticism of Joseph.
>
> This post confirms what I've been saying for the past year - PT tags add
> nothing but confusion to OSM, which directly leads to errors.
>
> highway=bus_stop is a completely separate tag to any in the PT schema.
> It was created long before the invention of the PT schema and is the
> original & the most popular, accurate way to map a bus stop.
>
> The PT schema purely duplicates existing, well used, clearly defined
> tags. It adds no extra detail or information.
>
> A platform is a raised physical object compared to the surrounding area
> to aid vehicle boarding. Popular tags such as railway=platform,
> tram=platform are used for such entities.
> Public_transport=platform has been hijacked by PT to falsely represent a
> bus stop as an imaginary area on a pavement. As defined in OSM's welcome
> page: "OpenStreetMap is a place for mapping things that are both /real
> and current/ ".
>
> It's hard to ascertain precisely why PT was originally created but it
> appears to be that the existing tags weren't complete. However instead
> of adding that missing data, somebody though it would be a great idea to
> start from the very beginning with a completely new set of tags & try to
> paper over the gaps. The irony is that, after a lot of discussion over
> tag names & locations & quickly waning enthusiasm for adding them to the
> database,  PT is *less* complete than the original data. What a waste of
> time. It's a mess.
>
> Over on the transit forum the PT schema has become so convoluted even
> those who helped create it are baffled. At least one is advocating its
> removal.
>
> It's time for the PT schema to be redacted.
>
> DaveF
>
>
>
> On 29/07/2019 15:29, Joseph Eisenberg wrote:
>> I read up on the rather exhausting history of public transport tagging.
>>
>> The strange thing is that the approved proposal which introduced
>> public_transport=* and the current public_transport pages suggest
>> using bus=yes only for public_transport=stop_position. In contrast,
>> public_transport=platform doesn't have bus=yes added.
>>
>> Does this mean that tagging highway=bus_stop on the same node as
>> public_transport=platform is the approved way to specify that a
>> certain "platform" is a bus stop?
>>
>> It certainly looks that way. Does this mean that tagging
>> public_transport=platform + highway=bus_stop was the tagging that was
>> intended by the proposal to specify bus stops, and
>> public_transport=platform + railway=platform for train platforms, etc?
>>
>> It appears that the proposal specifically said that the existing tags
>> like highway=bus_stop were not deprecated. Current usage confirms
>> this: in the past year just as many (or perhaps slightly more?)
>> highway=bus_stop have been added as a public_transport=platform -
>> about 

Re: [Tagging] Charging stations: socket::output -- which format for the value?

[brad]

I don't have an opinion about kw or w, but if the value is only a 
number, then to prevent confusion and reduce mistagging the key should 
specify, output-kw=22 .



On 7/29/19 5:00 AM, dktue wrote:
I'd vote for kW aswell (and a value of "22" then), since we're not 
always using SI and not always base-unit-values (see kilometers per hour).


Am 29.07.2019 um 12:53 schrieb Martin Koppenhoefer:



Am Mo., 29. Juli 2019 um 12:39 Uhr schrieb dktue 
mailto:em...@daniel-korn.de>>:


Hello,

the OSM-Wiki-page on charging stations [1] defines the tag
socket::output=watt

wheres the examples contain values like "22 kW".

What would the preferred format be? "22000" or "22 kW"? I would
like to
clearify this on the wiki-page.

Personally I would prefer "22000" as it fits with other
OSM-values (no
units).



generally people are encouraged to add units for disambiguation 
reasons and to use locally used units and preferably SI units.


For power, no default units are currently specified on this page:
https://wiki.openstreetmap.org/wiki/Map_Features/Units

And it doesn't even mention horsepower for power, a unit that for 
many people may be more evocative than Watt (everybody can imagine 30 
horses, but how much are 22 kW?) ;-)


Personally, if we were to set up a default for power units, I would 
prefer kW, because if we'd use Watt we will get very high numbers for 
MW (e.g. needed for power generators). Presuming, we would have the 
same standard unit for all things power, and not different defaults 
for socket and say power stations.


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] Tagging of State Parks in the US

[Martin Koppenhoefer]

sent from a phone

> On 29. Jul 2019, at 16:37, Kevin Kenny  wrote:
> 
> There are other historic sites embedded in the park


are all these sites mentioned to be part of the state park, or do they simply 
happen to be within the boundaries? 
If the definition of the park is a list of areas and sites, maybe a site 
relation would be appropriate: you can specify a perimeter and also add stuff 
inside (not only polygons but also nodes and ways). If legislation said the 
park is made up of A, B, C, D and E, it would be comprehensive if we modeled it 
as an object with A, B, C, D and E as members.

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

Re: [Tagging] Specific tag for Satellite Dishes

[Joseph Eisenberg]

I looked into this myself, back when I noticed that some large dishes
were mistagged as radio telescopes.

For huge communications dishes, there is tower:construction=dish to be
used with man_made=tower and we even have a satellite-dish style
rendering for this at Openstreetmap-carto, for some reason. This
should probably only be used for "tower"-sized dishes, not small
household ones?

For smaller satellite dishes, there is man_made=satellite_dish -
documented at https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsatellite_dish
- but note it is suggested that "This attribute is not suitable for
private house antennas". I think this tag might be suitable for very
large dishes too.

Joseph

On 7/29/19, Warin <61sundow...@gmail.com> wrote:
> On 29/07/19 15:03, Enock Seth Nyamador wrote:
>> Hello,
>>
>> Sorry for cross posting.
>>
>> I am looking for specific tags for Satellite Dish [1]. I haven't found
>> anything near so far. May be am missing something, else it doesn't
>> exist and might be useful to propose and come handy in some cases.
>>
>> Ever mapped something like this or any idea will be great.
>>
>> 1. https://www.wikidata.org/wiki/Q253843
>
> See
> https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use#Values
> for some ideas.
>
> Note the use of antenna:type=* is used for everything, frequency band,
> configuration, application. It is a bit of a mess.
>
> ___
> 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] New page "Approval status" for "de facto", "in use", "approved" etc

[Tobias Zwick]

One or several wiki edits should stand at the end of every tagging discussion, 
to document the conclusions made.

Tobias 

On July 29, 2019 8:37:25 AM GMT+02:00, Warin <61sundow...@gmail.com> wrote:
>Err .. sent to tagging list, so response here. Not to worry, a little
>more chatter.
>(Should there be a wiki edit list? Or would 'we' all then have to join
>that well as the tagging list? Anyone not want to be part of the
>discussions on wiki edits possibly of relevance to tagging? )
>
>On 29/07/19 16:13, Joseph Eisenberg wrote:
>
>> (Not sent to tagging list)
>>
>> I think the idea was that a tree with a proper name is an important /
>> landmark tree?
>>
>> Perhaps you crazy Europeans name your special trees, eg King George's
>Oak?
>>
>> The other suggestion was to use "landmark=yes" but this key is also
>> not recommended. Someone needs to check how denotation=cluster is
>> actually used now days.
>
>Correct. I looked it up.  :)
>
>The key denotation is meant for special trees .. see
>https://wiki.openstreetmap.org/wiki/Key:denotation
>
>So I have changed the wiki again . to simply direct 'special tree'
>tagging to that page.
>https://wiki.openstreetmap.org/wiki/Tag:denotation%3Dcluster
>
>If people want to mention names .. the denotation page would be the
>better place for it.
>
>>
>> Joseph
>>
>> On 7/29/19, Warin <61sundow...@gmail.com> wrote:
>>> On 29/07/19 15:26, Joseph Eisenberg wrote:
 I've edited the page:

 1) I reworded some of the helpful changes that Mateusz Konieczny
>just
 made, for better English style.

 2) I've removed the implication that de facto / approved are
 "recommended" and that "deprecated" / "discardable" etc. are "not
 recommended".

 I also removed the suggestion that "de facto" tags are supported by
 rendering / routing / editing software - while this is usually
>true,
 it isn't what determines if a tag is given "de facto" status.

 3) I removed "obsolete" status from the list with
>deprecated/discouraged.

 However, I now think I figured out what this status is supposed to
 mean: it's supposed to be used for tags that were deprecated, but
>now
 no longer even appear in the database, so the wiki page is only for
 historical information.

 Do we really need a special status for this, or should is it ok if
>I
 retag the 6 tags with this status to "deprecated"?


>https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22obsolete%22

 - Tag:abandoned=yes - recommended replacement abandoned:*=* - used
>34,000
 times
 - Tag:amenity=Kneippbecken - approved replacement is
 amenity=kneipp_water_cure - used 0 times
 - Tag:man_made=power_hydro / Tag:man_made=power_nuclear /
 Tag:man_made=power_wind - use  power=generator, generator:source=*
 instead - used a couple of times only.
 - Tag:denotation=cluster - for special trees. Recommend to use
>name=*
 instead with natural=tree. Had been down to 0 uses at one point,
>but
 now there are a few hundred?
>>> Gah! use name=* for something other than the name? No. Use the
>description
>>> key for that.
>>> Edited wiki to remove this suggestion.
>>>
 So only amenity=Kneippbecken and man_made=power_* really fit the
 "obsolete" status, though there are a number of tags currently with
 "deprecated" that are also no longer found in the database.

>>> Once something has been 'depreciated' but now has little to no
>presence then
>>> 'obsolete' is a good status for it.
>>>
>>>
>
>
>___
>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] New page "Approval status" for "de facto", "in use", "approved" etc

[Warin]

Err .. sent to tagging list, so response here. Not to worry, a little more 
chatter.
(Should there be a wiki edit list? Or would 'we' all then have to join that 
well as the tagging list? Anyone not want to be part of the discussions on wiki 
edits possibly of relevance to tagging? )

On 29/07/19 16:13, Joseph Eisenberg wrote:


(Not sent to tagging list)

I think the idea was that a tree with a proper name is an important /
landmark tree?

Perhaps you crazy Europeans name your special trees, eg King George's Oak?

The other suggestion was to use "landmark=yes" but this key is also
not recommended. Someone needs to check how denotation=cluster is
actually used now days.


Correct. I looked it up.  :)

The key denotation is meant for special trees .. see 
https://wiki.openstreetmap.org/wiki/Key:denotation

So I have changed the wiki again . to simply direct 'special tree' tagging to 
that page.
https://wiki.openstreetmap.org/wiki/Tag:denotation%3Dcluster

If people want to mention names .. the denotation page would be the better 
place for it.



Joseph

On 7/29/19, Warin <61sundow...@gmail.com> wrote:

On 29/07/19 15:26, Joseph Eisenberg wrote:

I've edited the page:

1) I reworded some of the helpful changes that Mateusz Konieczny just
made, for better English style.

2) I've removed the implication that de facto / approved are
"recommended" and that "deprecated" / "discardable" etc. are "not
recommended".

I also removed the suggestion that "de facto" tags are supported by
rendering / routing / editing software - while this is usually true,
it isn't what determines if a tag is given "de facto" status.

3) I removed "obsolete" status from the list with deprecated/discouraged.

However, I now think I figured out what this status is supposed to
mean: it's supposed to be used for tags that were deprecated, but now
no longer even appear in the database, so the wiki page is only for
historical information.

Do we really need a special status for this, or should is it ok if I
retag the 6 tags with this status to "deprecated"?

https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22obsolete%22

- Tag:abandoned=yes - recommended replacement abandoned:*=* - used 34,000
times
- Tag:amenity=Kneippbecken - approved replacement is
amenity=kneipp_water_cure - used 0 times
- Tag:man_made=power_hydro / Tag:man_made=power_nuclear /
Tag:man_made=power_wind - use  power=generator, generator:source=*
instead - used a couple of times only.
- Tag:denotation=cluster - for special trees. Recommend to use name=*
instead with natural=tree. Had been down to 0 uses at one point, but
now there are a few hundred?

Gah! use name=* for something other than the name? No. Use the description
key for that.
Edited wiki to remove this suggestion.


So only amenity=Kneippbecken and man_made=power_* really fit the
"obsolete" status, though there are a number of tags currently with
"deprecated" that are also no longer found in the database.


Once something has been 'depreciated' but now has little to no presence then
'obsolete' is a good status for it.





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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Peter Elderson]

ym to document the date when total disagreement was reached, the number of
days that took and how many mails were sent?

Vr gr Peter Elderson


Op ma 29 jul. 2019 om 08:49 schreef Tobias Zwick :

> One or several wiki edits should stand at the end of every tagging
> discussion, to document the conclusions made.
>
> Tobias
>
> On July 29, 2019 8:37:25 AM GMT+02:00, Warin <61sundow...@gmail.com>
> wrote:
> >Err .. sent to tagging list, so response here. Not to worry, a little
> >more chatter.
> >(Should there be a wiki edit list? Or would 'we' all then have to join
> >that well as the tagging list? Anyone not want to be part of the
> >discussions on wiki edits possibly of relevance to tagging? )
> >
> >On 29/07/19 16:13, Joseph Eisenberg wrote:
> >
> >> (Not sent to tagging list)
> >>
> >> I think the idea was that a tree with a proper name is an important /
> >> landmark tree?
> >>
> >> Perhaps you crazy Europeans name your special trees, eg King George's
> >Oak?
> >>
> >> The other suggestion was to use "landmark=yes" but this key is also
> >> not recommended. Someone needs to check how denotation=cluster is
> >> actually used now days.
> >
> >Correct. I looked it up.  :)
> >
> >The key denotation is meant for special trees .. see
> >https://wiki.openstreetmap.org/wiki/Key:denotation
> >
> >So I have changed the wiki again . to simply direct 'special tree'
> >tagging to that page.
> >https://wiki.openstreetmap.org/wiki/Tag:denotation%3Dcluster
> >
> >If people want to mention names .. the denotation page would be the
> >better place for it.
> >
> >>
> >> Joseph
> >>
> >> On 7/29/19, Warin <61sundow...@gmail.com> wrote:
> >>> On 29/07/19 15:26, Joseph Eisenberg wrote:
>  I've edited the page:
> 
>  1) I reworded some of the helpful changes that Mateusz Konieczny
> >just
>  made, for better English style.
> 
>  2) I've removed the implication that de facto / approved are
>  "recommended" and that "deprecated" / "discardable" etc. are "not
>  recommended".
> 
>  I also removed the suggestion that "de facto" tags are supported by
>  rendering / routing / editing software - while this is usually
> >true,
>  it isn't what determines if a tag is given "de facto" status.
> 
>  3) I removed "obsolete" status from the list with
> >deprecated/discouraged.
> 
>  However, I now think I figured out what this status is supposed to
>  mean: it's supposed to be used for tags that were deprecated, but
> >now
>  no longer even appear in the database, so the wiki page is only for
>  historical information.
> 
>  Do we really need a special status for this, or should is it ok if
> >I
>  retag the 6 tags with this status to "deprecated"?
> 
> 
> >
> https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22obsolete%22
> 
>  - Tag:abandoned=yes - recommended replacement abandoned:*=* - used
> >34,000
>  times
>  - Tag:amenity=Kneippbecken - approved replacement is
>  amenity=kneipp_water_cure - used 0 times
>  - Tag:man_made=power_hydro / Tag:man_made=power_nuclear /
>  Tag:man_made=power_wind - use  power=generator, generator:source=*
>  instead - used a couple of times only.
>  - Tag:denotation=cluster - for special trees. Recommend to use
> >name=*
>  instead with natural=tree. Had been down to 0 uses at one point,
> >but
>  now there are a few hundred?
> >>> Gah! use name=* for something other than the name? No. Use the
> >description
> >>> key for that.
> >>> Edited wiki to remove this suggestion.
> >>>
>  So only amenity=Kneippbecken and man_made=power_* really fit the
>  "obsolete" status, though there are a number of tags currently with
>  "deprecated" that are also no longer found in the database.
> 
> >>> Once something has been 'depreciated' but now has little to no
> >presence then
> >>> 'obsolete' is a good status for it.
> >>>
> >>>
> >
> >
> >___
> >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] Specific tag for Satellite Dishes

[Enock Seth Nyamador]

>
> *This attribute is not suitable for private house antennas.*
>
Apparently this caveat prevented us from using all above tags since we want
to use it in this regard. See screenshot [1]

1. https://imgur.com/tyXnMtJ


Le lun. 29 juil. 2019 à 06:23, Topographe Fou  a
écrit :

> Look at this recent page:
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsatellite_dish
>
> Note that this tag is 'in use' and has few usage. You can make/revive a
> proposal in order to approve it (together with
> man_made=communication(s)_dish?)
>
> LeTopographeFou
> *De:* enocks...@gmail.com
> *Envoyé:* 29 juillet 2019 7:04 AM
> *À:* tagging@openstreetmap.org
> *Répondre à:* tagging@openstreetmap.org
> *Cc:* t...@openstreetmap.org; talk...@openstreetmap.org
> *Objet:* [Tagging] Specific tag for Satellite Dishes
>
> Hello,
>
> Sorry for cross posting.
>
> I am looking for specific tags for Satellite Dish [1]. I haven't found
> anything near so far. May be am missing something, else it doesn't exist
> and might be useful to propose and come handy in some cases.
>
> Ever mapped something like this or any idea will be great.
>
> 1. https://www.wikidata.org/wiki/Q253843
>
> --
> Best,
> -Enock
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Best,
-Enock
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Specific tag for Satellite Dishes

[Warin]

On 29/07/19 15:03, Enock Seth Nyamador wrote:

Hello,

Sorry for cross posting.

I am looking for specific tags for Satellite Dish [1]. I haven't found 
anything near so far. May be am missing something, else it doesn't 
exist and might be useful to propose and come handy in some cases.


Ever mapped something like this or any idea will be great.

1. https://www.wikidata.org/wiki/Q253843


See 
https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use#Values 
for some ideas.


Note the use of antenna:type=* is used for everything, frequency band, 
configuration, application. It is a bit of a mess.


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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Warin]

On 29/07/19 15:26, Joseph Eisenberg wrote:

I've edited the page:

1) I reworded some of the helpful changes that Mateusz Konieczny just
made, for better English style.

2) I've removed the implication that de facto / approved are
"recommended" and that "deprecated" / "discardable" etc. are "not
recommended".

I also removed the suggestion that "de facto" tags are supported by
rendering / routing / editing software - while this is usually true,
it isn't what determines if a tag is given "de facto" status.

3) I removed "obsolete" status from the list with deprecated/discouraged.

However, I now think I figured out what this status is supposed to
mean: it's supposed to be used for tags that were deprecated, but now
no longer even appear in the database, so the wiki page is only for
historical information.

Do we really need a special status for this, or should is it ok if I
retag the 6 tags with this status to "deprecated"?

https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22obsolete%22

- Tag:abandoned=yes - recommended replacement abandoned:*=* - used 34,000 times
- Tag:amenity=Kneippbecken - approved replacement is
amenity=kneipp_water_cure - used 0 times
- Tag:man_made=power_hydro / Tag:man_made=power_nuclear /
Tag:man_made=power_wind - use  power=generator, generator:source=*
instead - used a couple of times only.
- Tag:denotation=cluster - for special trees. Recommend to use name=*
instead with natural=tree. Had been down to 0 uses at one point, but
now there are a few hundred?


Gah! use name=* for something other than the name? No. Use the description key 
for that.
Edited wiki to remove this suggestion.



So only amenity=Kneippbecken and man_made=power_* really fit the
"obsolete" status, though there are a number of tags currently with
"deprecated" that are also no longer found in the database.


Once something has been 'depreciated' but now has little to no presence then 
'obsolete' is a good status for it.


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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Tobias Zwick]

Sounds to me that those pages were incorrectly deleted. Only because someone 
can tag the abandonedness of a single tag of a feature, doesn't mean that the 
tag that applies to the whole feature is deprecated.

Actually, sine best practice is to map each feature as an own element (unless 
maybe both features encompass the whole element, i.e. a building), the plain 
non-namespace tag would probably be used in the vast majority of cases.

Even in cases where two or more features encompass the whole object, I can't 
really think of a use case where the namespacing made sense: For example a 
disused hotel in a stately building may be mapped on one element, but then, 
wouldn't the whole building not also be diused?

Tobias 

On July 29, 2019 8:23:42 AM GMT+02:00, Joseph Eisenberg 
 wrote:
>I was going to fix the status of abandoned=yes which is currently
>incorrectly listed as "obsolete". I thought it was probably
>deprecated, since the wiki page was deleted when Key:abandoned:*
>(namespaced) was made in 2015, but it's still used 40,000 times.
>
>The key disused (mainly disused=yes) is also used 60,000 times, even
>though the situation is the same: no wiki page, and the Key:disused:
>page suggests it is deprecated.
>
>Should these two be added to deprecated features, or should I recreate
>the deleted pages and change the status to something other than
>obsolete/deprecated?
>
>I see that there was just a mention added that landuse=quarry plus
>disused=yes might be more sensible than disused:landuse=quarry.
>
>Joseph
>
>___
>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] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Frederik Ramm]

Hi,

On 29.07.19 08:23, Joseph Eisenberg wrote:
> I was going to fix the status of abandoned=yes which is currently
> incorrectly listed as "obsolete". I thought it was probably
> deprecated, since the wiki page was deleted when Key:abandoned:*
> (namespaced) was made in 2015, but it's still used 40,000 times.
> 
> The key disused (mainly disused=yes) is also used 60,000 times, even
> though the situation is the same: no wiki page, and the Key:disused:
> page suggests it is deprecated.

Frankly, I am worried about the obsession with tag "statuses". I
couldn't care less whether "abandoned=yes" was obsolete, deprecated, in
use, or even voted on; "negating tags" like this is are dangerous and
problematic and the wiki should educate people about this, full stop.

If we explain to people why negating tags are problematic then they will
understand and not use them; this is far better than telling them "uh-oh
you've used a tag that is classified as a type-X tag under section Y of
the tag classification regulations, don't do it!"

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] New page "Approval status" for "de facto", "in use", "approved" etc

[Joseph Eisenberg]

(Not sent to tagging list)

I think the idea was that a tree with a proper name is an important /
landmark tree?

Perhaps you crazy Europeans name your special trees, eg King George's Oak?

The other suggestion was to use "landmark=yes" but this key is also
not recommended. Someone needs to check how denotation=cluster is
actually used now days.

Joseph

On 7/29/19, Warin <61sundow...@gmail.com> wrote:
> On 29/07/19 15:26, Joseph Eisenberg wrote:
>> I've edited the page:
>>
>> 1) I reworded some of the helpful changes that Mateusz Konieczny just
>> made, for better English style.
>>
>> 2) I've removed the implication that de facto / approved are
>> "recommended" and that "deprecated" / "discardable" etc. are "not
>> recommended".
>>
>> I also removed the suggestion that "de facto" tags are supported by
>> rendering / routing / editing software - while this is usually true,
>> it isn't what determines if a tag is given "de facto" status.
>>
>> 3) I removed "obsolete" status from the list with deprecated/discouraged.
>>
>> However, I now think I figured out what this status is supposed to
>> mean: it's supposed to be used for tags that were deprecated, but now
>> no longer even appear in the database, so the wiki page is only for
>> historical information.
>>
>> Do we really need a special status for this, or should is it ok if I
>> retag the 6 tags with this status to "deprecated"?
>>
>> https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22obsolete%22
>>
>> - Tag:abandoned=yes - recommended replacement abandoned:*=* - used 34,000
>> times
>> - Tag:amenity=Kneippbecken - approved replacement is
>> amenity=kneipp_water_cure - used 0 times
>> - Tag:man_made=power_hydro / Tag:man_made=power_nuclear /
>> Tag:man_made=power_wind - use  power=generator, generator:source=*
>> instead - used a couple of times only.
>> - Tag:denotation=cluster - for special trees. Recommend to use name=*
>> instead with natural=tree. Had been down to 0 uses at one point, but
>> now there are a few hundred?
>
> Gah! use name=* for something other than the name? No. Use the description
> key for that.
> Edited wiki to remove this suggestion.
>
>>
>> So only amenity=Kneippbecken and man_made=power_* really fit the
>> "obsolete" status, though there are a number of tags currently with
>> "deprecated" that are also no longer found in the database.
>>
> Once something has been 'depreciated' but now has little to no presence then
> 'obsolete' is a good status for it.
>
>
> ___
> 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] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Joseph Eisenberg]

I was going to fix the status of abandoned=yes which is currently
incorrectly listed as "obsolete". I thought it was probably
deprecated, since the wiki page was deleted when Key:abandoned:*
(namespaced) was made in 2015, but it's still used 40,000 times.

The key disused (mainly disused=yes) is also used 60,000 times, even
though the situation is the same: no wiki page, and the Key:disused:
page suggests it is deprecated.

Should these two be added to deprecated features, or should I recreate
the deleted pages and change the status to something other than
obsolete/deprecated?

I see that there was just a mention added that landuse=quarry plus
disused=yes might be more sensible than disused:landuse=quarry.

Joseph

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

Re: [Tagging] Specific tag for Satellite Dishes

[Topographe Fou]

 Look at this recent page:https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsatellite_dishNote that this tag is 'in use' and has few usage. You can make/revive a proposal in order to approve it (together with man_made=communication(s)_dish?) LeTopographeFou   De: enocks...@gmail.comEnvoyé: 29 juillet 2019 7:04 AMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgCc: t...@openstreetmap.org; talk...@openstreetmap.orgObjet: [Tagging] Specific tag for Satellite Dishes  Hello,Sorry for cross posting. I am looking for specific tags for Satellite Dish [1]. I haven't found anything near so far. May be am missing something, else it doesn't exist and might be useful to propose and come handy in some cases.Ever mapped something like this or any idea will be great. 1. https://www.wikidata.org/wiki/Q253843-- Best,-Enock
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Martin Koppenhoefer]

sent from a phone

> On 29. Jul 2019, at 08:13, Joseph Eisenberg  
> wrote:
> 
> Someone needs to check how denotation=cluster is
> actually used now days.


this tag was introduced through an automated edit many years ago with the 
reasoning that natural=tree should only be used for “special” and alone 
standing trees, so that all other trees which were standing in groups had 
gotten the cluster tag. Meanwhile the saner approach is to tag special trees 
with additional tags and accept that natural=tree has no other implications 
than “a tree”. IMHO it is ok to see denotation=cluster as deprecated.

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Martin Koppenhoefer]

Am Mo., 29. Juli 2019 um 11:14 Uhr schrieb Simon Poole :

> Am 29.07.2019 um 10:44 schrieb Martin Koppenhoefer:
> >
> > this tag was introduced through an automated edit many years ago with
> the reasoning that natural=tree should only be used for “special” and alone
> standing trees, so that all other trees which were standing in groups had
> gotten the cluster tag. Meanwhile the saner approach is to tag special
> trees with additional tags and accept that natural=tree has no other
> implications than “a tree”. IMHO it is ok to see denotation=cluster as
> deprecated.
>
> That is a mischaracterisation of what actually happened. Originally
> (pre-mass imports of trees) natural=tree was intended only for notable
> trees (as landmarks, or for other reasons) and there was only a small
> number of them in the data. The mass-imports without further
> qualification lost that semantic information, which led to a longer
> conflict trying to undo the damage (which was already hopeless IMHO).
> The correct approach would have been to address the problem before the
> imports.
>


I would question that those "normal" trees that hid the "special" trees
have all been introduced through mass imports. IIRR in some "pioneer" areas
(e.g. Berlin, where no tree import has taken place, AFAIK) mappers had
already started mapping "any" tree even before the mass imports (e.g.
Girona, which had taken place shortly before SOTM July 2010). What I can
confirm is that the wiki stated at that time that natural=tree was for
special trees. But the wiki stated a lot of things in these days that had
to be dynamically adjusted to the actual evolvement of common consensus.
>From a general consideration, using a "normal"/generic tag to mean
something "special" is always asking for trouble.

Btw.: the automatic edit which introduced denotation was heavily disputed
at the time and had not been discussed anywhere before it was uploaded.

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

Re: [Tagging] Specific tag for Satellite Dishes

[Joseph Eisenberg]

I agree; I spent a few minutes trying to improve the page a bit.

However, I don't see much benefit from mapping private household
satellite antennas: the dishes in the linked picture above are only 90
cm across, and they are on just about every house.

Maybe there are more useful things to map in Ghana before adding these
minor features?

On 7/29/19, Martin Koppenhoefer  wrote:
> Am Mo., 29. Juli 2019 um 09:36 Uhr schrieb Enock Seth Nyamador <
> enocks...@gmail.com>:
>
>> *This attribute is not suitable for private house antennas.*
>>>
>> Apparently this caveat prevented us from using all above tags since we
>> want to use it in this regard. See screenshot [1]
>>
>> 1. https://imgur.com/tyXnMtJ
>>
>>
>
>
> the man_made=satellite_dish tag is poorly defined anyway, the short
> definition speaks about "ground stations": "A ground station is a
> terrestrial radio station designed for extraplanetary telecommunication
> with spacecraf."
>
> Probably most satellite dishes are set up for communication with
> satellites, generally most of them being only receivers.
> The whole page should likely be rewritten, as it does not focus on the
> feature (satellite dish) but on other features (ground station, radio
> telescope, etc.). It isn't clear why this should not be used for private
> satellite dishes, and there should probably be some discussion on this list
> and improvement of the wiki page.
>
> Cheers,
> Martin
>

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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Paul Allen]

On Mon, 29 Jul 2019 at 07:24, Joseph Eisenberg 
wrote:

>
> I see that there was just a mention added that landuse=quarry plus
> disused=yes might be more sensible than disused:landuse=quarry.
>

It applies to more than just quarries.  The problem is that the namespaced
version, when
applied to physical objects, renders them invisible (on standard carto).

It's fine with usages.  I've mapped pubs that have recently closed and it
is uncertain if they
will re-open as a pub, re-open as something else, be turned into a
residence or the
building itself become disused.  I've been tagging them as
disused:amenity=pub
Some people with what I view as an over-strict interpretation of rules may
say that's
mapping the history of the thing and OSM doesn't map history, but I ignore
them.

However, there are several buildings in my town that are clearly disused.
Peeling paintwork,
broken windows, no sign of activity for many years.  If I use
disused:building=yes they
vanish from the map but they're observable in reality, which means the map
doesn't
show something that is physically present.  Using disused=yes is a way
around this.
Call it tagging for the renderer if you want, but it's not lying for the
renderer.

So I'd argue these are not obsolete, should get their pages back, and both
their pages and
the namespaced equivalents should get a brief note saying in which
situation the namespaced
version may or may not be preferred.

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Simon Poole]

Am 29.07.2019 um 10:44 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> On 29. Jul 2019, at 08:13, Joseph Eisenberg  
>> wrote:
>>
>> Someone needs to check how denotation=cluster is
>> actually used now days.
>
> this tag was introduced through an automated edit many years ago with the 
> reasoning that natural=tree should only be used for “special” and alone 
> standing trees, so that all other trees which were standing in groups had 
> gotten the cluster tag. Meanwhile the saner approach is to tag special trees 
> with additional tags and accept that natural=tree has no other implications 
> than “a tree”. IMHO it is ok to see denotation=cluster as deprecated.

That is a mischaracterisation of what actually happened. Originally
(pre-mass imports of trees) natural=tree was intended only for notable
trees (as landmarks, or for other reasons) and there was only a small
number of them in the data. The mass-imports without further
qualification lost that semantic information, which led to a longer
conflict trying to undo the damage (which was already hopeless IMHO).
The correct approach would have been to address the problem before the
imports.

Unluckily, not only, but particularly here, it is clear that the lessons
from this specific disaster have not been learnt.

Simon


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



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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Martin Koppenhoefer]

Am Mo., 29. Juli 2019 um 09:26 Uhr schrieb Frederik Ramm <
frede...@remote.org>:

>
> Frankly, I am worried about the obsession with tag "statuses". I
> couldn't care less whether "abandoned=yes" was obsolete, deprecated, in
> use, or even voted on; "negating tags" like this is are dangerous and
> problematic and the wiki should educate people about this, full stop.
>


yes, generally yes, although there may be exceptions. E.g. landuse=quarry.
An abandoned or disused quarry may still be seen as a quarry by the people
living there. In this case, abandoned=yes doesn't negate the tags, it is a
qualifier about activity.




> If we explain to people why negating tags are problematic then they will
> understand and not use them; this is far better than telling them "uh-oh
> you've used a tag that is classified as a type-X tag under section Y of
> the tag classification regulations, don't do it!"
>
>

+1

By the way, it seems the wiki does not show "statuses" correctly for
historic page revisions: it shows a status (the current one?) where there
is none set in the template, and it shows statuses that haven't been in
existence when the revision was published.

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Joseph Eisenberg]

In Italy, are all of the trees with designation=natural_monument the
officially protected ones, or are there others that are old or historic but
not official?

On Mon, Jul 29, 2019 at 6:29 PM Martin Koppenhoefer 
wrote:

> Am Mo., 29. Juli 2019 um 11:11 Uhr schrieb Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> But then I checked the other values of denotation=, eg
>> denotation=urban, denotation=avenue, =landmark, =natural_monument.
>> Boy, that's a mess. The whole key was poorly thought out.
>>
>> It looks like many mappers don't realize that database users can find
>> natural=tree within landuse=residential/commercial/retail to find
>> urban trees, or within leisure=park for park trees, or search within
>> 10 m of a highway, etc.
>>
>
>
> I am adding denotation=avenue to trees that are planted to form an avenue,
> because you can filter trees within some distance from a road, but not all
> of them are there to form an avenue, they could simply be trees close to a
> road (but a human would not regard them as part of an avenue). Species,
> size and position come into play, something that might be automatically
> recognizable with an elaborated system, but it would have to be more
> complex than just "within x meters from a road".
>
> Landmark and natural_monument can probably only with additional knowledge
> be tagged correctly.
> Urban may seem kind of superfluous, agreed (in theory it allows for
> detailed mapping of urban trees even in the absence of landuse, roads and
> other features, but in reality this will hardly ever happen).
>
>
>
>>
>> I've added some comments about the necessity and verifiability of
>> these tags (landmark and natural_monument seem to be subjective
>> opinions about the importance of a tree, unless in some places there
>> are official landmark or monument trees, but this isn't possible to
>> tell).
>>
>
>
> I can confirm that in Italy and Germany (and likely elsewhere) there are
> individual trees which are designated natural monuments (by "law") and
> which are mapped with these tags.
>
> 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] Charging stations: socket::output -- which format for the value?

[dktue]

Hello,

the OSM-Wiki-page on charging stations [1] defines the tag 
socket::output=watt


wheres the examples contain values like "22 kW".

What would the preferred format be? "22000" or "22 kW"? I would like to 
clearify this on the wiki-page.


Personally I would prefer "22000" as it fits with other OSM-values (no 
units).


Cheers,
dktue

[1] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcharging_station

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

Re: [Tagging] Specific tag for Satellite Dishes

[Enock Seth Nyamador]

> However, I don't see much benefit from mapping private household
> satellite antennas: the dishes in the linked picture above are only 90
> cm across, and they are on just about every house.

> Maybe there are more useful things to map in Ghana before adding these
> minor features?

I agree with you but in our case for the fact that this a slum. We thought
this will serve a purpose. Yes many more useful things will be mapped soon
:). Not 90cm across dishes into OSM this time. Thanks for comments.

Le lun. 29 juil. 2019 à 10:18, Joseph Eisenberg 
a écrit :

> I agree; I spent a few minutes trying to improve the page a bit.
>
> However, I don't see much benefit from mapping private household
> satellite antennas: the dishes in the linked picture above are only 90
> cm across, and they are on just about every house.
>
> Maybe there are more useful things to map in Ghana before adding these
> minor features?
>
> On 7/29/19, Martin Koppenhoefer  wrote:
> > Am Mo., 29. Juli 2019 um 09:36 Uhr schrieb Enock Seth Nyamador <
> > enocks...@gmail.com>:
> >
> >> *This attribute is not suitable for private house antennas.*
> >>>
> >> Apparently this caveat prevented us from using all above tags since we
> >> want to use it in this regard. See screenshot [1]
> >>
> >> 1. https://imgur.com/tyXnMtJ
> >>
> >>
> >
> >
> > the man_made=satellite_dish tag is poorly defined anyway, the short
> > definition speaks about "ground stations": "A ground station is a
> > terrestrial radio station designed for extraplanetary telecommunication
> > with spacecraf."
> >
> > Probably most satellite dishes are set up for communication with
> > satellites, generally most of them being only receivers.
> > The whole page should likely be rewritten, as it does not focus on the
> > feature (satellite dish) but on other features (ground station, radio
> > telescope, etc.). It isn't clear why this should not be used for private
> > satellite dishes, and there should probably be some discussion on this
> list
> > and improvement of the wiki page.
> >
> > Cheers,
> > Martin
> >
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Best,
-Enock
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Charging stations: socket::output -- which format for the value?

[dktue]

I'd vote for kW aswell (and a value of "22" then), since we're not 
always using SI and not always base-unit-values (see kilometers per hour).


Am 29.07.2019 um 12:53 schrieb Martin Koppenhoefer:



Am Mo., 29. Juli 2019 um 12:39 Uhr schrieb dktue >:


Hello,

the OSM-Wiki-page on charging stations [1] defines the tag
socket::output=watt

wheres the examples contain values like "22 kW".

What would the preferred format be? "22000" or "22 kW"? I would
like to
clearify this on the wiki-page.

Personally I would prefer "22000" as it fits with other OSM-values
(no
units).



generally people are encouraged to add units for disambiguation 
reasons and to use locally used units and preferably SI units.


For power, no default units are currently specified on this page:
https://wiki.openstreetmap.org/wiki/Map_Features/Units

And it doesn't even mention horsepower for power, a unit that for many 
people may be more evocative than Watt (everybody can imagine 30 
horses, but how much are 22 kW?) ;-)


Personally, if we were to set up a default for power units, I would 
prefer kW, because if we'd use Watt we will get very high numbers for 
MW (e.g. needed for power generators). Presuming, we would have the 
same standard unit for all things power, and not different defaults 
for socket and say power stations.


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] Tagging of State Parks in the US

[Martin Koppenhoefer]

sent from a phone

On 29. Jul 2019, at 01:18, Kevin Kenny  wrote:

>> Putting on my cynic hat, I'd say you'll probably get too many objections for 
>> it to happen:
>> people will say you have to manually ensure area=yes is actually valid in 
>> each situation;
> 
> Yeah. Although, how can a protected_AREA be anything but an area? 


+1, I don’t see why we would need area=yes on boundary=protected_area

It also seems weird that a node is suitable according to the wiki:
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area

but this is a general semantic problem we have with all boundaries (a boundary 
is a linear object, what it delimits is an area, which is somehow implicit 
through the boundaries, but when we describe the area inside with tags we add 
these directly to the boundary object, rather than to an area object with the 
boundaries as limits).

Anyway, area=yes seems superfluous as we are always speaking about areas in 
this context, even if they are represented as a node.

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

Re: [Tagging] Charging stations: socket::output -- which format for the value?

[Martin Koppenhoefer]

Am Mo., 29. Juli 2019 um 12:39 Uhr schrieb dktue :

> Hello,
>
> the OSM-Wiki-page on charging stations [1] defines the tag
> socket::output=watt
>
> wheres the examples contain values like "22 kW".
>
> What would the preferred format be? "22000" or "22 kW"? I would like to
> clearify this on the wiki-page.
>
> Personally I would prefer "22000" as it fits with other OSM-values (no
> units).



generally people are encouraged to add units for disambiguation reasons and
to use locally used units and preferably SI units.

For power, no default units are currently specified on this page:
https://wiki.openstreetmap.org/wiki/Map_Features/Units

And it doesn't even mention horsepower for power, a unit that for many
people may be more evocative than Watt (everybody can imagine 30 horses,
but how much are 22 kW?) ;-)

Personally, if we were to set up a default for power units, I would prefer
kW, because if we'd use Watt we will get very high numbers for MW (e.g.
needed for power generators). Presuming, we would have the same standard
unit for all things power, and not different defaults for socket and say
power stations.

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Martin Koppenhoefer]

Am Mo., 29. Juli 2019 um 11:11 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> But then I checked the other values of denotation=, eg
> denotation=urban, denotation=avenue, =landmark, =natural_monument.
> Boy, that's a mess. The whole key was poorly thought out.
>
> It looks like many mappers don't realize that database users can find
> natural=tree within landuse=residential/commercial/retail to find
> urban trees, or within leisure=park for park trees, or search within
> 10 m of a highway, etc.
>


I am adding denotation=avenue to trees that are planted to form an avenue,
because you can filter trees within some distance from a road, but not all
of them are there to form an avenue, they could simply be trees close to a
road (but a human would not regard them as part of an avenue). Species,
size and position come into play, something that might be automatically
recognizable with an elaborated system, but it would have to be more
complex than just "within x meters from a road".

Landmark and natural_monument can probably only with additional knowledge
be tagged correctly.
Urban may seem kind of superfluous, agreed (in theory it allows for
detailed mapping of urban trees even in the absence of landuse, roads and
other features, but in reality this will hardly ever happen).



>
> I've added some comments about the necessity and verifiability of
> these tags (landmark and natural_monument seem to be subjective
> opinions about the importance of a tree, unless in some places there
> are official landmark or monument trees, but this isn't possible to
> tell).
>


I can confirm that in Italy and Germany (and likely elsewhere) there are
individual trees which are designated natural monuments (by "law") and
which are mapped with these tags.

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Martin Koppenhoefer]

Am Mo., 29. Juli 2019 um 11:33 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> In Italy, are all of the trees with designation=natural_monument the
> officially protected ones, or are there others that are old or historic but
> not official?
>


you'd have to check all of them to be sure, but generally the consensus is
to only tag officially protected trees with this tag. The trees are also
released as open data, but for a systematic approach to compare official
lists with our data the license is not compatible (cc-by-4.0).
https://www.politicheagricole.it/flex/cm/pages/ServeBLOB.php/L/IT/IDPagina/11260

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

Re: [Tagging] Specific tag for Satellite Dishes

[Martin Koppenhoefer]

Am Mo., 29. Juli 2019 um 09:36 Uhr schrieb Enock Seth Nyamador <
enocks...@gmail.com>:

> *This attribute is not suitable for private house antennas.*
>>
> Apparently this caveat prevented us from using all above tags since we
> want to use it in this regard. See screenshot [1]
>
> 1. https://imgur.com/tyXnMtJ
>
>


the man_made=satellite_dish tag is poorly defined anyway, the short
definition speaks about "ground stations": "A ground station is a
terrestrial radio station designed for extraplanetary telecommunication
with spacecraf."

Probably most satellite dishes are set up for communication with
satellites, generally most of them being only receivers.
The whole page should likely be rewritten, as it does not focus on the
feature (satellite dish) but on other features (ground station, radio
telescope, etc.). It isn't clear why this should not be used for private
satellite dishes, and there should probably be some discussion on this list
and improvement of the wiki page.

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

Re: [Tagging] Specific tag for Satellite Dishes

[Jean-Marc Liotier]

On Mon, July 29, 2019 7:03 am, Enock Seth Nyamador wrote:
> I am looking for specific tags for Satellite Dish [1]. I haven't found
> anything near so far. May be am missing something, else it doesn't exist
> and might be useful to propose and come handy in some cases.

Prior discussion about that:
http://gis.19327.n8.nabble.com/quot-satellit-quot-td5934448.html -
inconclusive because there is no consensus about granularity

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Joseph Eisenberg]

Thanks, that makes sense now. Should probably be deprecated then, not
obsolete since there are some uses.

But then I checked the other values of denotation=, eg
denotation=urban, denotation=avenue, =landmark, =natural_monument.
Boy, that's a mess. The whole key was poorly thought out.

It looks like many mappers don't realize that database users can find
natural=tree within landuse=residential/commercial/retail to find
urban trees, or within leisure=park for park trees, or search within
10 m of a highway, etc.

I've added some comments about the necessity and verifiability of
these tags (landmark and natural_monument seem to be subjective
opinions about the importance of a tree, unless in some places there
are official landmark or monument trees, but this isn't possible to
tell).

Joseph

On 7/29/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 29. Jul 2019, at 08:13, Joseph Eisenberg 
>> wrote:
>>
>> Someone needs to check how denotation=cluster is
>> actually used now days.
>
>
> this tag was introduced through an automated edit many years ago with the
> reasoning that natural=tree should only be used for “special” and alone
> standing trees, so that all other trees which were standing in groups had
> gotten the cluster tag. Meanwhile the saner approach is to tag special trees
> with additional tags and accept that natural=tree has no other implications
> than “a tree”. IMHO it is ok to see denotation=cluster as deprecated.
>
> 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] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Joseph Eisenberg]

>> By the way, it seems the wiki does not show "statuses" correctly for 
>> historic page revisions: it shows a status (the current one?) where there is 
>> none set in the template, and it shows statuses that haven't been in 
>> existence when the revision was published.
>
>

This might be related to the new wikibase system?

Now missing things like status are pulled form the wikidata, and it
may not work properly for the page history?

I don't quite understand how it all works

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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Joseph Eisenberg]

Yes, buildings are a good example of a feature that can be disused or
even abandoned, but remain a building=house or building=barn.

I've recreated the pages. Please check them and make or suggest any
improvements needed:

https://wiki.openstreetmap.org/wiki/Tag:disused=yes

https://wiki.openstreetmap.org/wiki/Tag:abandoned=yes

On Mon, Jul 29, 2019 at 9:07 PM Paul Allen  wrote:
>
> On Mon, 29 Jul 2019 at 07:24, Joseph Eisenberg  
> wrote:
>>
>>
>> I see that there was just a mention added that landuse=quarry plus
>> disused=yes might be more sensible than disused:landuse=quarry.
>
>
> It applies to more than just quarries.  The problem is that the namespaced 
> version, when
> applied to physical objects, renders them invisible (on standard carto).
>
> It's fine with usages.  I've mapped pubs that have recently closed and it is 
> uncertain if they
> will re-open as a pub, re-open as something else, be turned into a residence 
> or the
> building itself become disused.  I've been tagging them as disused:amenity=pub
> Some people with what I view as an over-strict interpretation of rules may 
> say that's
> mapping the history of the thing and OSM doesn't map history, but I ignore 
> them.
>
> However, there are several buildings in my town that are clearly disused.  
> Peeling paintwork,
> broken windows, no sign of activity for many years.  If I use 
> disused:building=yes they
> vanish from the map but they're observable in reality, which means the map 
> doesn't
> show something that is physically present.  Using disused=yes is a way around 
> this.
> Call it tagging for the renderer if you want, but it's not lying for the 
> renderer.
>
> So I'd argue these are not obsolete, should get their pages back, and both 
> their pages and
> the namespaced equivalents should get a brief note saying in which situation 
> the namespaced
> version may or may not be preferred.
>
> --
> Paul
>
> ___
> 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 of State Parks in the US

[Kevin Kenny]

On Mon, Jul 29, 2019 at 4:22 AM Martin Koppenhoefer
 wrote:
> I didn’t know we were bound to IUCN classes. IMHO we can have our own system, 
> while it should ideally allow to distinguish all the IUCN classes, it doesn’t 
> mean we cannot have more qualifiers, if they seem useful.

We return to the original idea proposed at the very start of this
thread: 'protect_class=21 protection_object=recreation' for these
features. Except for the ugliness of using numeric values for
protect_class, it sounds as if you might agree with the original idea?

> For the Italian situation, a distinction for many protected areas by 
> national, regional (al 4), provincial (al 6) and municipal (al 8) seems to 
> make a lot of sense. If it doesn’t apply (e.g. not a protected area by the 
> competent government), don’t put admin_level.

Sure. I have no problem with admin_level. If you want to tag,
admin_level=4 on state parks, be my guest! It's just a little
distracting, because it doesn't actually address the issue (a area
protected for diverse recreational uses, partaking of park,
recreation_ground, nature_reserve, and a few other things) but with a
single enclosing boundary, and a single name.

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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Mateusz Konieczny]

To be more exact someone decided to delete content and document prefix on the 
same page
instead of creating new one.

See 
https://wiki.openstreetmap.org/w/index.php?title=Key:disused:=878757=862845


29 Jul 2019, 08:45 by o...@westnordost.de:

> Sounds to me that those pages were incorrectly deleted.
>

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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Paul Allen]

On Mon, 29 Jul 2019 at 13:54, Mateusz Konieczny 
wrote:

Is there a case where making it visible would actually be useful?
>

Yes, I would argue that disused physical objects should be rendered.  A
disused:building=house
is still a house.  An abandoned:building=house is still a house.  Even
ruins:building=house may
still be visible.  Disused non-physical objects should not be rendered: a
disused:amenity=pub
is no longer a pub.  Except there are grey areas, such as disused sports
pitches which are
maintained to some degree (weeds cut down occasionally) but no longer
used.  They could
be re-activated for their original purpose.  Abandoned railway lines pose
yet other problems.

For quarries or buildings disused/abandoned status is a property and is not
> changing
> feature so it makes sense to use disused=yes and abandoned=yes.
>

Which we do only because (currently, on standard carto)
disused:building=yes doesn't render.

In case of shops it is fundamentally different - disused shop is no longer
> a shop.
> If someone really wants to tag it (may to protect against accidental
> remapping
> then disused:shop=* is preferable (and it makes no sense to render it in
> most cases)
>

Depends.  It might be preferable to use shop=vacant is there is a strong
probability (such
as zoning restrictions) which mean that it won't be converted into a
domestic residence.

Is there some trace of the pub (maybe sign?) or danger of incorrect
> remapping?
>
Then it makes sense to keep it.
>

In one case I've mapped, yes.  It's a listed building with a distinctive
old pub sign which
cannot be removed (because it's a listed building).  It closed a couple of
years ago and
as far as I can tell is now a domestic residence.  A mapper passing by
would assume it
is still a pub.  https://goo.gl/maps/nf3S2MfjjV12tqAaA

Though in cases where no trace is left I would delete it (yes, OSM doesn't
> map history).
>

Again, near me there are several pubs that have closed but there is a
prospect they will
re-open under new ownership.  One recently had a bad fire 6 or 7 months ago
but has
just re-opened.

And then there are churches and chapels which have closed but not, as yet,
been repurposed.
So building=chapel + disused:amenity=place_of_worship.

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

Re: [Tagging] Specific tag for Satellite Dishes

[Martin Koppenhoefer]

Am Mo., 29. Juli 2019 um 15:51 Uhr schrieb Kevin Kenny <
kevin.b.ke...@gmail.com>:

> To an American engineer (I can speak with some authority, *being* an
> American holder of an MSEE degree ;) ) 'communication' comprises
> either transmission or reception, or both, and 'spacecraft' includes
> 'satellite'. In each case, a more general term was chosen over a
> less-general one.
>


thank you for explaining spacecraft, I wasn't clear about this (while for
communication it is clear that one-way communication is still
communication).



> I don't mind mapping any sort of satellite_dish, but the attributes
> would have to depend on what you're mapping them _for_. Using them as
> landmarks ("turn right just past the building with six huge satellite
> dishes on the roof") is surely different from using them as amenities
> ("this neighbourhood has a communal satellite dish over *here* where
> you can see news"), and of course the attributes would differ.
>


sure. I read this as agreement to use the basic term also for "small"
household dishes?

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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Andy Townsend]

On 29/07/2019 13:05, Paul Allen wrote:


It applies to more than just quarries.  The problem is that the 
namespaced version, when

applied to physical objects, renders them invisible (on standard carto).


Please let's just stop worrying about just that one renderer...


It's fine with usages.  I've mapped pubs that have recently closed and 
it is uncertain if they
will re-open as a pub, re-open as something else, be turned into a 
residence or the
building itself become disused.  I've been tagging them as 
disused:amenity=pub
Some people with what I view as an over-strict interpretation of rules 
may say that's
mapping the history of the thing and OSM doesn't map history, but I 
ignore them.


It's perfectly possible for renderers to make sense of namespaced tags 
(and even, with a bit more difficulty, tags such as "landuse=quarry; 
disused=yes") and do whatever they want with them (obligatory example 
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L1496 
and 
https://map.atownsend.org.uk/maps/map/map.html#zoom=20=53.9994944=-1.136121 
).


As already mentioned the tricky bit is working out what "disused" means 
for e.g. a quarry.  A map that wanted to show actual places where rock 
was extracted wouldn't show an inactive hole in the ground, whereas one 
that wanted to show holes in the ground would still show them.




However, there are several buildings in my town that are clearly 
disused.  Peeling paintwork,
broken windows, no sign of activity for many years.  If I use 
disused:building=yes they
vanish from the map but they're observable in reality, which means the 
map doesn't
show something that is physically present.  Using disused=yes is a way 
around this.
Call it tagging for the renderer if you want, but it's not lying for 
the renderer.


A building that isn't used for anything is still in actuality a building 
(until it falls or is knocked down), so I probably wouldn't use that tag 
personally, although there is mid-level usage in e.g. the UK: 
https://overpass-turbo.eu/s/L9H .


Best Regards,

Andy


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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Mateusz Konieczny]

29 Jul 2019, 14:05 by pla16...@gmail.com:

> On Mon, 29 Jul 2019 at 07:24, Joseph Eisenberg <> joseph.eisenb...@gmail.com 
> > > wrote:
>
>>
>> I see that there was just a mention added that landuse=quarry plus
>>  disused=yes might be more sensible than disused:landuse=quarry.
>>
>
> It applies to more than just quarries.  The problem is that the namespaced 
> version, when
> applied to physical objects, renders them invisible (on standard carto).
>
Is there a case where making it visible would actually be useful?

For quarries or buildings disused/abandoned status is a property and is not 
changing
feature so it makes sense to use disused=yes and abandoned=yes.

Disuses building is still a building, only once it starts turning into ruin it
gets more questionable.

In case of shops it is fundamentally different - disused shop is no longer a 
shop.
If someone really wants to tag it (may to protect against accidental remapping
then disused:shop=* is preferable (and it makes no sense to render it in most 
cases)

> Some people with what I view as an over-strict interpretation of rules may 
> say that's
> mapping the history of the thing and OSM doesn't map history, but I ignore 
> them.
>
Is there some trace of the pub (maybe sign?) or danger of incorrect remapping?
Then it makes sense to keep it.

Though in cases where no trace is left I would delete it (yes, OSM doesn't map 
history).

> However, there are several buildings in my town that are clearly disused.  
> Peeling paintwork,
> broken windows, no sign of activity for many years.  If I use 
> disused:building=yes they
> vanish from the map but they're observable in reality, which means the map 
> doesn't
> show something that is physically present.  Using disused=yes is a way around 
> this.
> Call it tagging for the renderer if you want, but it's not lying for the 
> renderer.
>
I would argue that disused=yes is preferable tagging for such feature and that 
it
is desirable for renderers and editors to encourage it.

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

Re: [Tagging] Specific tag for Satellite Dishes

[Martin Koppenhoefer]

sent from a phone

> On 29. Jul 2019, at 14:17, Paul Allen  wrote:
> 
>   I could see where it might be useful to somebody to map
> them to show the uptake of the technology in given areas


it could also show the level of cooperation/coordination: one dish per 
household or a better one shared among the residents?

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

Re: [Tagging] Tagging of State Parks in the US

[Paul Allen]

On Mon, 29 Jul 2019 at 00:08, Kevin Kenny  wrote:

There are no sizable cities in the park, but dozens of towns and
> villages of a few thousand inhabitants each.
>

I can think of only one city in the Pembrokeshire Coast National Park (but
I'm not that
familiar with it) and that's the second-smallest city in the UK by
population: St David's
with 1,841 people in 2011).  Note that, in the UK, official city status
must be conferred
by Mrs Betty Windsor or her predecessors.  Unofficially, some very large
towns
describe themselves as cities without having that status officially.

I tagged the things 'boundary=national_park' and I'm not apologizing.
>

+1 for the tag.  +1 for not apologizing.

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

[Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Joseph Eisenberg]

I read up on the rather exhausting history of public transport tagging.

The strange thing is that the approved proposal which introduced
public_transport=* and the current public_transport pages suggest
using bus=yes only for public_transport=stop_position. In contrast,
public_transport=platform doesn't have bus=yes added.

Does this mean that tagging highway=bus_stop on the same node as
public_transport=platform is the approved way to specify that a
certain "platform" is a bus stop?

It certainly looks that way. Does this mean that tagging
public_transport=platform + highway=bus_stop was the tagging that was
intended by the proposal to specify bus stops, and
public_transport=platform + railway=platform for train platforms, etc?

It appears that the proposal specifically said that the existing tags
like highway=bus_stop were not deprecated. Current usage confirms
this: in the past year just as many (or perhaps slightly more?)
highway=bus_stop have been added as a public_transport=platform -
about 350,000 each - though the latter tag also can be used for
railways, trams, etc.

Joseph

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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Paul Allen]

On Mon, 29 Jul 2019 at 13:43, Andy Townsend  wrote:

> On 29/07/2019 13:05, Paul Allen wrote:
>
>
> It applies to more than just quarries.  The problem is that the namespaced
> version, when
> applied to physical objects, renders them invisible (on standard carto).
>
> Please let's just stop worrying about just that one renderer...
>

There are other renderers to worry about, certainly.  But...

1) Not all of us have the luxury of running our own renderer which we can
customize to
match our own requirements.

2) When I look at what other renderers do in comparison to standard carto,
I find them lacking
in various different ways.  I don't think standard carto is perfect, but I
find the others a lot
worse.  Especially the commercial ones that boast how much better they are
than standard
carto, which generally put cosmetics (drop-shadowed buildings) ahead of
presenting useful
information (house names/numbers).

As already mentioned the tricky bit is working out what "disused" means for
> e.g. a quarry.  A map that wanted to show actual places where rock was
> extracted wouldn't show an inactive hole in the ground, whereas one that
> wanted to show holes in the ground would still show them.
>

Another map might even show the two situations differently, in some way.
So that people who
wanted only to look for active quarries could find them whilst others who
wanted to be warned
of dangerous holes in the ground in an area they intended to ramble would
be happy.

A building that isn't used for anything is still in actuality a building
> (until it falls or is knocked down), so I probably wouldn't use that tag
> personally, although there is mid-level usage in e.g. the UK:
> https://overpass-turbo.eu/s/L9H .
>

This is where I think standard carto gets it wrong.  A disused:building=yes
ought to be rendered
as a building but a disused:amenity=pub should not be rendered as a pub.
Instead a disused:
or abandoned: prefix renders everything it is applied to invisibly. Such
things are fixable in theory,
but in practice they aren't.  The result is that mappers do what mappers
do...

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

Re: [Tagging] Tagging of State Parks in the US

[Paul Allen]

On Mon, 29 Jul 2019 at 13:52, Kevin Kenny  wrote:

>
> We return to the original idea proposed at the very start of this
> thread: 'protect_class=21 protection_object=recreation' for these
> features. Except for the ugliness of using numeric values for
> protect_class, it sounds as if you might agree with the original idea?
>

I don't know if I would or not because I didn't examine it in any detail
after seeing the
numeric values.  The numeric values convinced me it was a non-starter, so I
didn't
investigate further.

I have no objection to using it as optional, supplemental information about
an object tagged
in some other way.  Much the same as opening_hours or the UK Food Hygiene
Rating Scheme
ID with fhrd:id=n.  I can add those, but I don't have to.  With that sort
of usage I could even
live with numeric values for protect_class (I doubt I'd ever add one
because it's too much
like hard work figuring out what number to use, but if I encountered one
I'd not remove it).

I have a problem with the numeric values if you intend this to be a
top-level tag for an object,
replacing other ways of tagging such an object.  In that situation, numeric
values are (for me) a
no-go.

I suspect whatever you come up with may have to be usable as both top-level
and supplemental,
to cater for all sorts of existing objects which already have existing
schemes but which also
fall under an IUCN class.  In the UK, Areas of Outstanding Natural Beauty,
Nature Reserves,
Sites of Special Scientific Interest and Registered Historic Landscapes
come to mind.  There
are others.

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

Re: [Tagging] Specific tag for Satellite Dishes

[Kevin Kenny]

On Mon, Jul 29, 2019 at 6:06 AM Martin Koppenhoefer
 wrote:
> the man_made=satellite_dish tag is poorly defined anyway, the short 
> definition speaks about "ground stations": "A ground station is a terrestrial 
> radio station designed for extraplanetary telecommunication with spacecraf."
>
> Probably most satellite dishes are set up for communication with satellites, 
> generally most of them being only receivers.
>
> The whole page should likely be rewritten, as it does not focus on the 
> feature (satellite dish) but on other features (ground station, radio 
> telescope, etc.). It isn't clear why this should not be used for private 
> satellite dishes, and there should probably be some discussion on this list 
> and improvement of the wiki page.

To an American engineer (I can speak with some authority, *being* an
American holder of an MSEE degree ;) ) 'communication' comprises
either transmission or reception, or both, and 'spacecraft' includes
'satellite'. In each case, a more general term was chosen over a
less-general one.

I don't mind mapping any sort of satellite_dish, but the attributes
would have to depend on what you're mapping them _for_. Using them as
landmarks ("turn right just past the building with six huge satellite
dishes on the roof") is surely different from using them as amenities
("this neighbourhood has a communal satellite dish over *here* where
you can see news"), and of course the attributes would differ.

I have mapped such things, but never tried to upload the data to OSM -
it was proprietary to the customer, and of considerably less interest
to the world at large.

[OSM-related information ends here. Feel free to stop reading]

(All this was twenty years ago, by the way.) I don't think I'm
breaking a confidence to say that significant attributes were the
capabilities of the station:

   - transmit-capable, or receive-only (referring to data transmission
*through* the spacecraft, not command of the spacecraft)
   - uplink power
   - able to command the spacecraft
   - able to BE commanded remotely through the satellite network. Most
stations were not always staffed but were commanded from a central
location. Some simply monitored a particular channel on a particular
spacecraft, and needed a visit from a technician to change the antenna
pointing, frequency or polarization. Some could be commanded
out-of-band by telephone modem, and most had modems available as a
backup command channel in case antenna pointing was lost; this
included a "phone home" function if a "heartbeat" command was missed
too many times in a row.
   - pointing capability: single-spacecraft; multiple geostationary
spacecraft (longitude range(s) specified); inclined-orbit
geosynchronous spacecraft; Molniya-orbit spacecraft. (The network in
question used no other orbits. There are many, but most others would
have to be described in terms of altitude/azimuth ranges and slew
rates.)
  - number of receive channels

There were also a lot of attributes relating to connection to
terrestrial networks (microwave and optical), operational status, and
of course a whole pile of related attributes - name, contact
information (both for the modem and for "get a human over there"),
several identifiers for addressing equipment on the network, a lot of
information relating to maintenance of the station (including
information such as who the service contractor was), ...  it turned
into a Big Complicated Messy SQL Database, as so many operational
databases do.

The project, of course, was building the network operations center for
this particular network. We did have a big screen with a map of the
network and real-time status display of the operations, but that was
mostly to impress visitors. The operators found that an alphabetized
list of the station identifiers with "drill down" into detailed status
available with one click was considerably more useful; with about 400
fixed and half a dozen mobile ground stations, the displays just got
too busy otherwise.

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

Re: [Tagging] Tagging of State Parks in the US

[Kevin Kenny]

On Mon, Jul 29, 2019 at 9:44 AM Martin Koppenhoefer
 wrote:
> Maybe you can see (and map) the state park as one thing and the nature 
> reserve within it as another? For the state park you would need to say it is 
> a state park and has this name and or number (usually there will be an 
> identifier, maybe it’s not strictly necessary). The nature reserve within 
> would already be spatially connected, but if it is an explicit constituent 
> part of the park that would maybe be too weak? Is the nature reserve managed 
> by the state or a different government level?

Sure, detailed mapping inside the parks is possible and encouraged!
The fundamental problem has been how to tag the whole park - because
that's what the name is bound to, and many of the areas inside are
less formal - the parks department has decided to keep the 'nature
reserve' part in a natural state for hiking and bird watching, but
it's not otherwise a 'nature reserve' with formal protection. They
hypothetically could choose a different management strategy under a
different administration. (In practice, they don't. You can't turn
that ship very fast.)

In an earlier message (I see that you've not been following the whole
thread, which is getting pretty long so I don't blame you) I mentioned
Bear Mountain State Park
https://www.openstreetmap.org/relation/6467468 as being fairly typical
of a 'complex' example, where the larger-scale mapping is starting to
come along. (With many of these parks, we're still doing well just to
get them on the map in the right places!) Most State Parks are
simpler, but I choose this example because it's the sort that appears
to have nearly "one of everything."

It's a complex object; 'park', 'nature_reserve', 'recreation_ground',
'national_park' are all inaccurate. It's best to give it a border, a
name, a protection status, and call it a day. I contend that the
current tagging of https://www.openstreetmap.org/relation/6467468 is
close to 'best current practice'. It's important to emphasize
'current' here - the numeric protection classes are what the Wiki
currently recommands, and what New York currently uses. That's subject
to change, and the other posters in this thread are demanding such
change. (That's fine, but my original objective was to clarify best
*current* practice!)

(Details follow. Stop here if not interested, but a few paragraphs
detailing the sort of complexities encountered are probably in order.)

The park's border is complex, because the village of Fort Montgomery
and the hamlet of Jones Point are 'inside' the park. (Not quite
inside, topologically, and not owned or administered by the park, but
you have to drive on roads with park land on either side to get to
them)

The parts of the park that see the greatest number of visitors are the
developed sections - the northeast area, near the bridge over the
Hudson, and the scenic drive and observation tower on Bear Mountain
itself (the peak west of Hessian Lake). The main developed area
includes two formal historic preserves (Fort Clinton and Fort
Montgomery - note the 'museum' icons at high zoom levels), a zoo,
swimming and boating facilities, a large grassy area for informal
athletic events, a carousel, several playgrounds, two inns (one of
which also offers group accommodations in large cabins), a ranger
station and various other PoI's. It disallows camping, but camping is
available at the larger Harriman State Park, coterminuous to the west.
(The nearest authorized 'back country' campsite is West Mountain, in a
cutout from the park on the southwest side. The nearest 'front
country' camping is at Silver Mine and Lake Tiorati, a short distance
to the southwest on Seven Lakes Drive (Road, Parkway; it's the same
road, and the signage is inconsistent). The park also embeds an
ecological research reserve (Iona Island - on the Hudson River, on the
east side of the rail grade.

There are other historic sites embedded in the park, such as the ghost
town of Doodletown (the last inhabitants were finally forced out in
the 1960's; the cemeteries are still maintained, and the waterworks
still serve Jones Point, Iona Island and Buckberg), the
never-completed Dunderberg Spiral Railway
https://www.openstreetmap.org/relation/2138097 (an insane
nineteenth-century plan to build what would have been the world's
longest roller-coaster right to the present day; the plan was
torpedoed when the Columbian Exposition of 1892 went to Chicago
instead of New York), and many abandoned mines, including a failed
attempt by Thomas Edison at electromagnetic refinement of iron ore.

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

Re: [Tagging] Specific tag for Satellite Dishes

[Paul Allen]

On Mon, 29 Jul 2019 at 11:18, Joseph Eisenberg 
wrote:

However, I don't see much benefit from mapping private household
> satellite antennas: the dishes in the linked picture above are only 90
> cm across, and they are on just about every house.
>
> Maybe there are more useful things to map in Ghana before adding these
> minor features?
>

I don't know about the situation in Ghana, but I can conceive of
communities where it's one
satellite dish per village with public access (or nearly so) to the TV.
"Here is where you
get to watch the news about the rest of the world," "Here is where you
watch the broadcast
educational stuff," kind of thing.  But that's probably better handled as
some sort of
amenity tag (here is where you can watch TV) rather than a physical mapping
of dishes.

That said, as you observed, there seem to be a lot of dishes in that image
so I wouldn't map
them as they're not for the public.  I could see where it might be useful
to somebody to map
them to show the uptake of the technology in given areas, but that's what
uMap is for.  If
that's why Enock wants to do it, I might be amenable to a new tag that
doesn't get rendered
which could be picked up on uMap automagically with an overpass-turbo
query, but maybe
the db guys would object to that level of clutter.

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Mateusz Konieczny]

No, summary of discussion
with reference to the thread -
to avoid rediscussing the same thing in 
a future using the same arguments
and spending time on rediscovering
the same facts.

29 Jul 2019, 09:20 by pelder...@gmail.com:

> ym to document the date when total disagreement was reached, the number of 
> days that took and how many mails were sent? 
>
> Vr gr Peter Elderson
>
>
> Op ma 29 jul. 2019 om 08:49 schreef Tobias Zwick <> o...@westnordost.de 
> > >:
>
>> One or several wiki edits should stand at the end of every tagging 
>> discussion, to document the conclusions made.
>>  
>>  Tobias 
>>  
>>  On July 29, 2019 8:37:25 AM GMT+02:00, Warin <>> 61sundow...@gmail.com 
>> >> > wrote:
>>  >Err .. sent to tagging list, so response here. Not to worry, a little
>>  >more chatter.
>>  >(Should there be a wiki edit list? Or would 'we' all then have to join
>>  >that well as the tagging list? Anyone not want to be part of the
>>  >discussions on wiki edits possibly of relevance to tagging? )
>>  >
>>  >On 29/07/19 16:13, Joseph Eisenberg wrote:
>>  >
>>  >> (Not sent to tagging list)
>>  >>
>>  >> I think the idea was that a tree with a proper name is an important /
>>  >> landmark tree?
>>  >>
>>  >> Perhaps you crazy Europeans name your special trees, eg King George's
>>  >Oak?
>>  >>
>>  >> The other suggestion was to use "landmark=yes" but this key is also
>>  >> not recommended. Someone needs to check how denotation=cluster is
>>  >> actually used now days.
>>  >
>>  >Correct. I looked it up.  :)
>>  >
>>  >The key denotation is meant for special trees .. see
>>  >>> https://wiki.openstreetmap.org/wiki/Key:denotation 
>> 
>>  >
>>  >So I have changed the wiki again . to simply direct 'special tree'
>>  >tagging to that page.
>>  >>> https://wiki.openstreetmap.org/wiki/Tag:denotation%3Dcluster 
>> 
>>  >
>>  >If people want to mention names .. the denotation page would be the
>>  >better place for it.
>>  >
>>  >>
>>  >> Joseph
>>  >>
>>  >> On 7/29/19, Warin <>> 61sundow...@gmail.com 
>> >> > wrote:
>>  >>> On 29/07/19 15:26, Joseph Eisenberg wrote:
>>   I've edited the page:
>>  
>>   1) I reworded some of the helpful changes that Mateusz Konieczny
>>  >just
>>   made, for better English style.
>>  
>>   2) I've removed the implication that de facto / approved are
>>   "recommended" and that "deprecated" / "discardable" etc. are "not
>>   recommended".
>>  
>>   I also removed the suggestion that "de facto" tags are supported by
>>   rendering / routing / editing software - while this is usually
>>  >true,
>>   it isn't what determines if a tag is given "de facto" status.
>>  
>>   3) I removed "obsolete" status from the list with
>>  >deprecated/discouraged.
>>  
>>   However, I now think I figured out what this status is supposed to
>>   mean: it's supposed to be used for tags that were deprecated, but
>>  >now
>>   no longer even appear in the database, so the wiki page is only for
>>   historical information.
>>  
>>   Do we really need a special status for this, or should is it ok if
>>  >I
>>   retag the 6 tags with this status to "deprecated"?
>>  
>>  
>>  >>> 
>> https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22obsolete%22
>>  
>> 
>>  
>>   - Tag:abandoned=yes - recommended replacement abandoned:*=* - used
>>  >34,000
>>   times
>>   - Tag:amenity=Kneippbecken - approved replacement is
>>   amenity=kneipp_water_cure - used 0 times
>>   - Tag:man_made=power_hydro / Tag:man_made=power_nuclear /
>>   Tag:man_made=power_wind - use  power=generator, generator:source=*
>>   instead - used a couple of times only.
>>   - Tag:denotation=cluster - for special trees. Recommend to use
>>  >name=*
>>   instead with natural=tree. Had been down to 0 uses at one point,
>>  >but
>>   now there are a few hundred?
>>  >>> Gah! use name=* for something other than the name? No. Use the
>>  >description
>>  >>> key for that.
>>  >>> Edited wiki to remove this suggestion.
>>  >>>
>>   So only amenity=Kneippbecken and man_made=power_* really fit the
>>   "obsolete" status, though there are a number of tags currently with
>>   "deprecated" that are also no longer found in the database.
>>  
>>  >>> Once something has been 'depreciated' but now has little to no
>>  >presence then
>>  >>> 'obsolete' is a good status for it.
>>  >>>
>>  >>>
>>  >
>>  >
>>  >___
>>  >Tagging mailing list
>>  >>> Tagging@openstreetmap.org 
>>  >>> 

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Dave F via Tagging]

Hi

This is not a criticism of Joseph.

This post confirms what I've been saying for the past year - PT tags add 
nothing but confusion to OSM, which directly leads to errors.


highway=bus_stop is a completely separate tag to any in the PT schema. 
It was created long before the invention of the PT schema and is the 
original & the most popular, accurate way to map a bus stop.


The PT schema purely duplicates existing, well used, clearly defined 
tags. It adds no extra detail or information.


A platform is a raised physical object compared to the surrounding area 
to aid vehicle boarding. Popular tags such as railway=platform, 
tram=platform are used for such entities.
Public_transport=platform has been hijacked by PT to falsely represent a 
bus stop as an imaginary area on a pavement. As defined in OSM's welcome 
page: "OpenStreetMap is a place for mapping things that are both /real 
and current/ ".


It's hard to ascertain precisely why PT was originally created but it 
appears to be that the existing tags weren't complete. However instead 
of adding that missing data, somebody though it would be a great idea to 
start from the very beginning with a completely new set of tags & try to 
paper over the gaps. The irony is that, after a lot of discussion over 
tag names & locations & quickly waning enthusiasm for adding them to the 
database,  PT is *less* complete than the original data. What a waste of 
time. It's a mess.


Over on the transit forum the PT schema has become so convoluted even 
those who helped create it are baffled. At least one is advocating its 
removal.


It's time for the PT schema to be redacted.

DaveF



On 29/07/2019 15:29, Joseph Eisenberg wrote:

I read up on the rather exhausting history of public transport tagging.

The strange thing is that the approved proposal which introduced
public_transport=* and the current public_transport pages suggest
using bus=yes only for public_transport=stop_position. In contrast,
public_transport=platform doesn't have bus=yes added.

Does this mean that tagging highway=bus_stop on the same node as
public_transport=platform is the approved way to specify that a
certain "platform" is a bus stop?

It certainly looks that way. Does this mean that tagging
public_transport=platform + highway=bus_stop was the tagging that was
intended by the proposal to specify bus stops, and
public_transport=platform + railway=platform for train platforms, etc?

It appears that the proposal specifically said that the existing tags
like highway=bus_stop were not deprecated. Current usage confirms
this: in the past year just as many (or perhaps slightly more?)
highway=bus_stop have been added as a public_transport=platform -
about 350,000 each - though the latter tag also can be used for
railways, trams, etc.

Joseph

___
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] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Joseph Eisenberg]

Ok, it's clear that these tags are not deprecated.

Are they "in use" then?

According to https://taghistory.raifer.tech they've both increased in
number by about 3500 features in the past 12 months. In comparison,
disused:shop=* has been added about 3000 times in the same time
period.

On 7/29/19, Martin Koppenhoefer  wrote:
> Am Mo., 29. Juli 2019 um 14:43 Uhr schrieb Andy Townsend >:
>
>> On 29/07/2019 13:05, Paul Allen wrote:
>>
>>
>> It applies to more than just quarries.  The problem is that the
>> namespaced
>> version, when
>> applied to physical objects, renders them invisible (on standard carto).
>>
>> Please let's just stop worrying about just that one renderer...
>>
>
>
> it is not just one renderer, OSM-Carto is often seen as standard
> implementation and a lot of people are taking it as template when they
> develop their own style. Generally the vast majority of data consumers does
> neither look at disused / abandoned=yes qualifiers, nor at them as
> prefixes. This applies to routing engines, rendering rules and all other
> kind of data consumers. Maybe there is someone looking at these "details",
> but most don't.
>
>
> As already mentioned the tricky bit is working out what "disused" means for
>> e.g. a quarry.  A map that wanted to show actual places where rock was
>> extracted wouldn't show an inactive hole in the ground, whereas one that
>> wanted to show holes in the ground would still show them.
>>
>
>
> that's a problem of tagging then. "landuse" is not suitable to represent a
> business. You need an additional tag for this. It might work as a shortcut
> in simple cases, but it is not generally working and is not in analogy to
> how we map factories or other industrial landuses for example.
>
> Cheers,
> Martin
>

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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Dave F via Tagging]

I believe the main reason isn't (& probably shouldn't) deprecated is 
that it allows entities which are unused but still physically there, to 
be rendered. disused:*=* aren't rendered on the 'standard' render.


Davef

On 29/07/2019 07:23, Joseph Eisenberg wrote:

I was going to fix the status of abandoned=yes which is currently
incorrectly listed as "obsolete". I thought it was probably
deprecated, since the wiki page was deleted when Key:abandoned:*
(namespaced) was made in 2015, but it's still used 40,000 times.

The key disused (mainly disused=yes) is also used 60,000 times, even
though the situation is the same: no wiki page, and the Key:disused:
page suggests it is deprecated.

Should these two be added to deprecated features, or should I recreate
the deleted pages and change the status to something other than
obsolete/deprecated?

I see that there was just a mention added that landuse=quarry plus
disused=yes might be more sensible than disused:landuse=quarry.

Joseph

___
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] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Mateusz Konieczny]

29 Jul 2019, 18:34 by joseph.eisenb...@gmail.com:

> Ok, it's clear that these tags are not deprecated.
>
> Are they "in use" then?
>
I would say that use is deprecated for things like shop=* and in use
for things like quarries, buildings, adits, bunkers etc

>
> According to https://taghistory.raifer.tech they've both increased in
> number by about 3500 features in the past 12 months. In comparison,
> disused:shop=* has been added about 3000 times in the same time
> period.
>
https://taginfo.openstreetmap.org//search?q=disused%3A 


Not sure about growth, but usage for disused:railway and disused:amenity
is higher than of disused=shop.

There is also disused:highway, disused:aeroway, disused:landuse with a decent 
use.

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