Re: [Tagging] "not:brand" to mark a shop that isn't part of a chain?

[Francesco Ansanelli]

Hello Joseph,

I have to say that I'm not a fan of the tag, IMHO negation is something
that will make harder to do searches...
If the burger king is not the food chain keep the brand empty and write a
note or do a Wikipedia page about it, probably an historical activity
deserve it.

About the no name, this already exists:

https://wiki.openstreetmap.org/wiki/Key:noname

Can you please point out why adopt the new syntax instead?

Cheers,
Francesco

Il sab 14 set 2019, 06:43 Joseph Eisenberg  ha
scritto:

> There's a new-ish page about the prefix "not:"
>
> https://wiki.openstreetmap.org/wiki/Key:not:
>
> It's been used with "not:name" to show that a street isn't named
> something else (e.g. for streets that had the wrong name on official
> OS maps in Britain): https://wiki.openstreetmap.org/wiki/Key:not:name
>
> Also it's been used with "not:addr:postcode" -
> https://taginfo.openstreetmap.org/keys/?key=not%3Aaddr%3Apostcode
>
> Recently there was a suggestion to use "not:brand" and
> "not:brand:wikidata" to show that a feature is not part of a chain.
> https://github.com/openstreetmap/iD/issues/6577
>
> For example, this can be used to tag the "Burger King" fast food
> restaurant in Illinois that's older than the international brand with
> the same name. This would help database users distinguish between
> places like this and the usual, popular brand, when doing searches or
> validating data.
>
> Does anyone see a problem with this?
>
> What about "not:name"? There's also a discussion about using that tag
> to check for mistakes, like when new mappers keep changing the name of
> a feature due to a misspelled or hard-to-read sign:
> https://github.com/openstreetmap/iD/issues/6411
>
> -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

[Tagging] Amenity=music_school back on Map Features

[Joseph Eisenberg]

I've added "amenity=music_school" back to the Map Features list, since
it looks like there is consensus that this is different than
amenity=college and there is not other tag for this feature at this
time. And I edited it's wiki page to mention isced:level as a possible
combination.

- Joseph

On 9/6/19, Joseph Eisenberg  wrote:
> The tag you're looking might be isced:level=0-6
>
> https://wiki.openstreetmap.org/wiki/Key:isced:level
>
> This is already used with amenity=school, which can include anything
> from Kindergarten (0) to upper secondary (3).
>
> So an amenity=music_school which only offers post-secondary education
> at a university level would be level 5, if it's post-secondary but not
> higher education it would be level 4, if it's for primary school,
> middle school and high school students (USA names), that's levels 1 to
> 3, if I understand correctly?
>
> See
> https://en.wikipedia.org/wiki/International_Standard_Classification_of_Education
> as well.
>
> On 9/6/19, Graeme Fitzpatrick  wrote:
>> On Thu, 5 Sep 2019 at 19:09, Martin Koppenhoefer 
>> wrote:
>>
>>>
>>>
>>> Am Do., 5. Sept. 2019 um 09:59 Uhr schrieb Warin
>>> <61sundow...@gmail.com>:
>>>
 Pardon me. The question is about music schools and how to tag them -
 they
 are educational facilities.
 ...
 See

 https://wiki.openstreetmap.org/wiki/Proposed_Features/Education_Reform_Alternative

 Have you considered it?

 eduction=music, max_age=*, min_age=* might be appropriate???

>>>
>>>
>>> it has a solution for the academies and conservatories, but I cannot
>>> find
>>> out how to tag the general school specialized in music and neither can I
>>> for the music school that is like a dancing school, can you?
>>>
>>
>> How about (a word something like) "level*"=basic / skilled / advanced
>>
>> * Yes, I know level is already taken in regard to levels of buildings
>> etc,
>> which is why I said "something like level" (Can't think of another word
>> at
>> the moment!
>>
>> Thanks
>>
>> Graeme
>>
>

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

[Tagging] "not:brand" to mark a shop that isn't part of a chain?

[Joseph Eisenberg]

There's a new-ish page about the prefix "not:"

https://wiki.openstreetmap.org/wiki/Key:not:

It's been used with "not:name" to show that a street isn't named
something else (e.g. for streets that had the wrong name on official
OS maps in Britain): https://wiki.openstreetmap.org/wiki/Key:not:name

Also it's been used with "not:addr:postcode" -
https://taginfo.openstreetmap.org/keys/?key=not%3Aaddr%3Apostcode

Recently there was a suggestion to use "not:brand" and
"not:brand:wikidata" to show that a feature is not part of a chain.
https://github.com/openstreetmap/iD/issues/6577

For example, this can be used to tag the "Burger King" fast food
restaurant in Illinois that's older than the international brand with
the same name. This would help database users distinguish between
places like this and the usual, popular brand, when doing searches or
validating data.

Does anyone see a problem with this?

What about "not:name"? There's also a discussion about using that tag
to check for mistakes, like when new mappers keep changing the name of
a feature due to a misspelled or hard-to-read sign:
https://github.com/openstreetmap/iD/issues/6411

-Joseph

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Joseph Eisenberg]

I agree, we shouldn’t create relations that combine 7 separate artworks
into one, or all the ways with the same street name, or all the peaks and
ridges in a mountain_range, just so that a wikidata= tag can be added to
the relation.

Relations are harder to maintain, and in the cases above are not necessary
for Openstreetmap:

1) artists often make related objects or even identical copies of
sculptures and place them in separate cities. We should map what is locally
verifiable: “there is an artwork here that looks like this”. Else what if
one of the dwarves is moved to Sydney? Is it still part of the same artwork
relation then? Such groupings are like categories.

2) a street or road made with many Openstreetmap ways can be handled by
routers and search applications just fine. And they can all be combined
into one linestring with post processing if needed, by looking at matching
“name” or “ref” fields. Adding a street relation is extra mapping and
maintenance work without adding new information

3) if it’s possible to verify the peaks and ridges of a named mountain
range, then map these as a natural=mountain_range way.

On Sat, Sep 14, 2019 at 5:07 AM Mateusz Konieczny 
wrote:

>
>
>
> 13 Sep 2019, 20:28 by a...@pigsonthewing.org.uk:
>
> On Wed, 11 Sep 2019 at 13:41, Janko Mihelić  wrote:
>
> sri, 11. ruj 2019. u 14:34 Joseph Eisenberg 
> napisao je:
>
>
> Doesn't this mean that it would be better to create separate Wikidata
> items for each separate OSM feature, rather than creating a new OSM
> tag?
>
> You have examples like tagging all ways that are a part of a street with
> the wikidata item about that street. You can't define those parts in
> Wikidata.
>
>
> Use a relation.
>
> Introducing pointless relation to satisfy unneded rule is pointless.
>
> At least I prefer to keep allowing using wikipedia=*
> and similar tags on multiple elements.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Where does it stop - RFC - Reusable packaging

[Warin]

On 12/09/19 21:52, Frederik Ramm wrote:

Hi,

  Do we really want to go
into that effort of trying to actively represent what products are sold
and under what conditions? Do we even have a remote hope of achieving a
level of completeness and timeliness that makes this usable? Where does
it stop?



It probably stops when mappers realise;

it will not get used

there are other, more important, things to map.


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

Re: [Tagging] Proposed features / landuse=open_defecation

[Warin]

On 13/09/19 12:13, Joseph Eisenberg wrote:

Thanks for working on this, Bob,

Check out the page "Proposal_process" and in particular
Proposal_process#Creating_a_proposal_page to help improve the
formatting and make sure you've included important information.

Please clarify exactly what should be mapped with this new tag. Is
going to be added to whole villages, as suggested in the section about
"open_defecation=yes?

"It would have its own sign and could be used as a node or area.
Although it may be added to small villages to indicate if it is their
primary source of human waste disposal."

This would not be a good idea, since it's not possible for mappers to
confirm that every house or a majority of houses in a village lack
latrines or toilet. But the rest of the page suggests that this tag is
supposed to be applied to areas where there are visible signs, in
other words, there's human feces exposed on the ground?

There are a couple of problems with the proposed subtags. It's not
best practice to use abbreviations or uppercase letters in tags, so
instead of "ODA_" it should be "open_defecation_" or
"open_defecation:", if need.

"ODA_Radius_.." "ODA_area_size..." - The first two subtags are not
needed - the area can be mapped instead, and this provides the shape
and size just from the position of the nodes in the database.

"ODA_survey_date=" - there is already a tag for this, survey:date=* or
source:date=* , but it is recommended to add such information to the
changeset rather than to individual OSM objects.

"ODA_responsibility=" is unclear. What would this mean, and how would
a local mapper in confirm this information?


Possibly use the tag 'operator'?
https://wiki.openstreetmap.org/wiki/Key:operator

In general would this not be some government administrative responsibility?
These can be mapped, see
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative



"ODA_proposed_solution=" - Unfortunately, this is not appropriate for
Openstreetmap. We map real, current features, not opinions, reviews or
suggestions, because such information is too subjective for individual
mappers to maintain.


There is some tagging for planed future things.
Most generally regard theses with some distaste and some things 'planned' are 
viewed as political promises that never get done.

See https://wiki.openstreetmap.org/wiki/Lifecycle_prefix#Stages_of_birth



"ODA_abandoned=yes/no" - generally features in Openstreetmap should be
current, so if an area that was used for open defecation in the past
has now been abandoned, and there are no signs "on the ground", then
it should be removed from the database. Some mappers use a prefix
"abandoned:" like "abandoned:landuse=open_defecation".

However, if the area is "disused" - not currently in use, but there
are still signs that it was recently used, and perhaps it's still a
health hazard because of the presence of decomposing human waste, this
could be tagged with "disused=yes".


Disused means it could be placed back into use with little effort.

If the OD is a disposal area and 'full' then this description does not suit.

I think if this OD is a transfer like facility then disused would suit, where 
as if it is a disposal facility then abandoned would be a better description.



ODA_survey_hazardous materials_data_weblink= - I'm not sure what is
intended by this tag. Perhaps the existing tag url=* would be
sufficient?

(I've also left these comments on the Talk page of the proposal, so we
can continue discussion there)

-Joseph Eisenberg

On 9/12/19, Bob Kerr via Tagging  wrote:

I have created a proposal page for landuse=open defecation.

https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dopen_defecation

Please review it, my wiki page editing skills have suffered from lack of use
so it could do with a little tidy if anyone wants to.

Please discuss your thoughts here. The most controversial area is I am using
the landuse tag rather than open_defication = yes. Please let me know which
you would prefer.

All the best

Bob

___
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] building typology vs usage

[Mateusz Konieczny]

13 Sep 2019, 21:37 by tagging@openstreetmap.org:

> On 13/09/2019 16:14, Wolfgang Zenker wrote:
>  
>
>>
>> That would be kind of redundant, wouldn't it? We already use other tagsfor 
>> the current function of a building,
>>
> I'm repeating much of my of my previous comment, but no, the schemawhich 
> hijacked building=* to represent the original historicalfunction of a 
> building never took off*. The vast majority ofcontributors use it for 
> it's current purpose. OSM isn't for themapping of redundant historical 
> information. 
>
(...)
>  *building:use = 628 167
>  building!=yes  = > 65 221 930
>
That is because in vast majority 
current use is the same as suggested
by how building looks like.
I also often tag building=* about its
structure without tagging building:use

Note also that building tag is not about
historical data.

Industrial buildings with fast food
inside is building=industrial

Remodeled industrial building
that lost indicators of its original
use is not building=industrial

-+--
Btw, can you link evidence that
building tag was originally for
current use, not for current appearance?

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

Re: [Tagging] Proposed features / landuse=open_defecation

[Martin Koppenhoefer]

open_defecation=yes seems a better tag for all situations where it is a 
significant phenomenon, while landuse=open_defecation would be ok for areas 
that are either designated for open defecation or are mainly used for it.


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

Re: [Tagging] building typology vs usage

[Wolfgang Zenker]

* Dave F via Tagging  [190913 21:37]:
> On 13/09/2019 16:14, Wolfgang Zenker wrote:
>> That would be kind of redundant, wouldn't it? We already use other tags
>> for the current function of a building,

> I'm repeating much of my of my previous comment, but no, the schema 
> which hijacked building=* to represent the original historical function 
> of a building never took off*. The vast majority of contributors use it 
> for it's current purpose. OSM isn't for the mapping of redundant 
> historical information.

Well, I don't know of any hijacking. This thread is the first time I
have seen people suggesting to tag the current function only in the
building=* tag. But admittedly I'm only active in OSM since 2008, so
that might have happened before that or I might have overlooked it.

>> so building=* is mostly useful
>> when the uilding does look like it was built for some other function
>> than it's current one.

> How do you know what it was originally used for just from your 
> interpretation of what a building of a certain function should look 
> like? It's just guesswork. How does tagging this perception add to, or 
> improve the quality of the OSM database?

I don't care about the buildings original function but about what it
looks like. That might or might not match its original and/or current
function. And if it looks like a run-of-the-mill nothing-special any-
purpose-at-all type of building I tag it as building=yes.

> "OpenStreetMap is a place for mapping things that are both /real and 
> current/"

I agree. I recently mapped https://www.openstreetmap.org/way/722948688
"Howard School" in rural Montana. It is a historic building originally
built as a public school, looks like a fine specimen of a schoolhouse of
it's era, has a prominent sign saying "Howard School" on the front side
and so I tagged it "building=school" even when it has not been used as a
school since 1947 but is used since for community gatherings. So I also
mapped it's current function by adding amenity=community_centre.

Of course different mappers have different opinions about what would be
the best way to tag something, but I don't see this as a weakness but a
strength of OSM. By discussing what we individually think is best and
learning from each other we collectively will arrive at better tagging
by all over time.

Wolfgang
( lyx @ osm )

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Mateusz Konieczny]

13 Sep 2019, 20:28 by a...@pigsonthewing.org.uk:

> On Wed, 11 Sep 2019 at 13:41, Janko Mihelić  wrote:
>
>> sri, 11. ruj 2019. u 14:34 Joseph Eisenberg  
>> napisao je:
>>
>>>
>>> Doesn't this mean that it would be better to create separate Wikidata
>>> items for each separate OSM feature, rather than creating a new OSM
>>> tag?
>>>
>> You have examples like tagging all ways that are a part of a street with
>> the wikidata item about that street. You can't define those parts in
>> Wikidata.
>>
>
> Use a relation.
>
Introducing pointless relation to satisfy unneded rule is pointless.

At least I prefer to keep allowing using wikipedia=* 
and similar tags on multiple elements. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building typology vs usage

[Dave F via Tagging]

On 13/09/2019 16:14, Wolfgang Zenker wrote:


That would be kind of redundant, wouldn't it? We already use other tags
for the current function of a building,
I'm repeating much of my of my previous comment, but no, the schema 
which hijacked building=* to represent the original historical function 
of a building never took off*. The vast majority of contributors use it 
for it's current purpose. OSM isn't for the mapping of redundant 
historical information.



  so building=* is mostly useful
when the uilding does look like it was built for some other function
than it's current one.


How do you know what it was originally used for just from your 
interpretation of what a building of a certain function should look 
like? It's just guesswork. How does tagging this perception add to, or 
improve the quality of the OSM database?


"OpenStreetMap is a place for mapping things that are both /real and 
current/"


*building:use = 628 167
building!=yes  = 65 221 930

DaveF

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Andy Mabbett]

On Thu, 12 Sep 2019 at 09:43, Janko Mihelić  wrote:

> Currently, the second most numerous wikidata tag in OSM
> is https://www.wikidata.org/wiki/Q2961670, an item that
> describes all the roman roads in historic Gaul in France. All
> those ways, close to 500 of them, have wikidata=Q296167.

Can we agree that these should all be removed, or replaced with
suitable sub-tag, ASAP? the sub-tag might be, say:

   historic:wikidata=Q2961670

>  I would give all these roads part:wikidata=Q29616

I would not.

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

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Paul Allen]

On Fri, 13 Sep 2019 at 19:47, Andy Mabbett 
wrote:

> On Wed, 11 Sep 2019 at 13:58, Paul Allen  wrote:
>
> > if there is a property shared by all members of a group then it MUST be
> marked on
> > the group ALONE and not also on individual members.
>
> This is not the rule on Wikidata.
>

But I was applying that rule to OSM, not wikidata.  Wikidata can do
whatever it wants.
But if there's a wikidata item for a grouping then OSM mappers should not
apply that
item to individual members of the group.

> Yes, I've been bitten by this before.  Marking up Wikimedia images as
> being listed
> > buildings.  All went fine until I happened to mark a few that were
> collected in a group
> > of "Listed buildings in ."  Those changes were reverted
> because the
> > grouping itself was flagged as being of listed buildings.
>
> Do you mean categories on Wikimedia Commons? That's not Wikidata.
>

If I recall correctly, I made that statement in the context of rules being
over-zealously
applied.  That particular case happened to me over on the commons.  Nothing
in the
template said I shouldn't do that, nothing in any documentation I could find
said I shouldn't do that, what I did was consistent and made things more
usable.
But somebody decided that, by his interpretation of some arcane rule, I was
wrong.  So be
it.  It's something that happens across many open-source projects where
anarchy
semi-rules.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Andy Mabbett]

On Wed, 11 Sep 2019 at 22:24, Janko Mihelić  wrote:

> Art or memorial installations like Stolperstein[1], which
> are distributed, but have one wikidata item.

We already cater for this, using sub-tags; say:

   project:wikidata=Q314003

or:

   memorial:wikidata=Q26703203

 (see https://www.wikidata.org/wiki/Q314003 /
https://www.wikidata.org/wiki/Q26703203 )


But perhaps this is better done through the templated link to
Q26703203 on https://wiki.openstreetmap.org and/ or Q26703203
/wiki/Tag:memorial%3Dstolperstein


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

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Andy Mabbett]

On Wed, 11 Sep 2019 at 19:48, Paul Allen  wrote:
>
> On Wed, 11 Sep 2019 at 19:43, Mateusz Konieczny  
> wrote:

>> It gets tricky where wikidata has a
>> single object for things like
>> lake and surrounding wetlands
>
>
> Then the wikidata item is for the wetlands, which happen to have a lake 
> within them.  Map
> the wetlands and add the wikidata tag to it.

..and create a Wikidata item for (just) the lake.

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

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Andy Mabbett]

On Wed, 11 Sep 2019 at 17:02, Mateusz Konieczny  wrote:

> Entries about shop brands (used in name suggestion index) got deleted.

That was over-zealous anti-spam action. Many such deletions were
challenged and reverted; any others should have been.

In such cases, including third-party identifiers (for example, Lidl
has an "EU Transparency Register ID") can help.

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

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Andy Mabbett]

On Wed, 11 Sep 2019 at 13:58, Paul Allen  wrote:
>
> On Wed, 11 Sep 2019 at 13:35, Martin Koppenhoefer  
> wrote:

>> looking at the example, it seems here is such an issue with
> the "canonization status"=catholic saint. Why do the individual
> saints not have the property, but the group has it?

> if there is a property shared by all members of a group then it MUST be 
> marked on
> the group ALONE and not also on individual members.

This is not the rule on Wikidata.

>  DRY (don't repeat yourself) is rigidly enforced.

It is not, especially in cases like the above.

> Yes, I've been bitten by this before.  Marking up Wikimedia images as being 
> listed
> buildings.  All went fine until I happened to mark a few that were collected 
> in a group
> of "Listed buildings in ."  Those changes were reverted because the
> grouping itself was flagged as being of listed buildings.

Do you mean categories on Wikimedia Commons? That's not Wikidata.

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

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Andy Mabbett]

On Wed, 11 Sep 2019 at 13:41, Janko Mihelić  wrote:

> sri, 11. ruj 2019. u 14:34 Joseph Eisenberg  
> napisao je:
>>
>> Doesn't this mean that it would be better to create separate Wikidata
>> items for each separate OSM feature, rather than creating a new OSM
>> tag?

> You have examples like tagging all ways that are a part of a street with
> the wikidata item about that street. You can't define those parts in
> Wikidata.

Use a relation.

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

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Mark Wagner]

On Fri, 13 Sep 2019 18:29:04 +0200
Janko Mihelić  wrote:

> pet, 13. ruj 2019. u 17:31 Paul Allen  napisao je:
> 
> > On Thu, 12 Sep 2019 at 09:45, Janko Mihelić 
> > wrote:
> >
> > The correct way to group them is with a relation.  If we don't have
> > a suitable type of  relation then propose one.
> >  
> 
> My idea was to expand the general "part:wikidata=*" to more specific
> tags. For example, give all peaks and ridges of a mountain the
> mountain:wikidata=* tag, instead of part:wikidata=*. Part is just the
> first, nondescript step. If we decide on a better tag, we replace the
> part:wikidata with the new XXX:wikidata=*

"Part of" is frequently ill-defined.  To take your "mountain:" example,
mountain-climbers consider Little Tahoma to be a mountain, while
geologists consider it to be a satellite peak of Mount Rainier.  Given
that, how do you decide if Fryingpan Glacier is a
"mountain:wikidata=Q1367080" or a "mountain:wikidata=Q194057"?

-- 
Mark

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Paul Allen]

On Fri, 13 Sep 2019 at 17:31, Janko Mihelić  wrote:

My idea was to expand the general "part:wikidata=*" to more specific tags.
> For example, give all peaks and ridges of a mountain the
> mountain:wikidata=* tag, instead of part:wikidata=*. Part is just the
> first, nondescript step. If we decide on a better tag, we replace the
> part:wikidata with the new XXX:wikidata=*
>

Firstly, I see no reason for mountain:wikidata=*.   It's a wikidata tag for
a wikidata item about a
mountain applied to an object which is a mountain.  So wikidata=* is fine.
The "mountain:" bit is
redundant and causes more work for data consumers that already support
wikidata.

Secondly, having interim tagging schemes is a REALLY bad idea.  I'll
explain exactly why a
little further on.

Thirdly, don't force square pegs into round holes.  If we've mapped a peak
and there's
a wikidata item for that exact peak, then wikidata=*.  If there's no
wikidata item then wait
for somebody to write it or write a stub article yourself.  If there's a
wikidata item for a
peak but it has not yet been mapped then map it (provided you can confirm
it independently
because wikipedia articles may use sources that are incompatible with the
ODbL) and add
wikidata=*.  Similarly if we've mapped a mountain range with
natural=mountain_range
and there's an exact match with a wikidata item.  Don't try to force a peak
without a
wikidata item into a range as part:wikidata=*: map the range or write a
stub wikipedia
article about the peak (or both).

[Roman roads]

> I think the only sensible solution is to delete the wikidata tags from
>> *all* of them.
>>
>
I definitely agree with this. But I'm not going to be the one who does it
> :) It's bad mapping, but it's still somewhat useful information.
>

And THAT is why interim tagging schemes are a really bad idea.  Somebody
did that, for
whatever reason, and now there is reluctance to remove or fix it.  This
would be compounded
by the fact that somebody, somewhere will announce "In my country, my local
mapping group
decided to use part:wikidata this way..."  Your ideas for part:wikidata are
so vague that it
will end up being a complete mess.  Not even useful for holding a wikidata
item pending
invention of a redundant XXX:wikidata tag (there's still no reason for the
XXX), because a
fixme would do the same and also call attention to somebody who might
actually fix it.

BTW, a better way for marking Roman roads would be to use
historic=roman_road.  It's a
lapsed proposal, and doesn't show even on lutz's historic places map, but
it would allow
a simple overpass-turbo query and might even let you map them with uMap
(going by
the amount of data in just one Roman road, that's probably impracticable,
though).  It's
been used 2000 times, so you could probably use it without a formal
proposal.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Janko Mihelić]

pet, 13. ruj 2019. u 17:31 Paul Allen  napisao je:

> On Thu, 12 Sep 2019 at 09:45, Janko Mihelić  wrote:
>
> The correct way to group them is with a relation.  If we don't have a
> suitable type of  relation then propose one.
>

My idea was to expand the general "part:wikidata=*" to more specific tags.
For example, give all peaks and ridges of a mountain the
mountain:wikidata=* tag, instead of part:wikidata=*. Part is just the
first, nondescript step. If we decide on a better tag, we replace the
part:wikidata with the new XXX:wikidata=*


> I think the only sensible solution is to delete the wikidata tags from
> *all* of them.
>

I definitely agree with this. But I'm not going to be the one who does it
:) It's bad mapping, but it's still somewhat useful information.

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

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[Paul Allen]

On Thu, 12 Sep 2019 at 09:45, Janko Mihelić  wrote:

One problem with the current system is that if you click one of those
> dwarfs in OSM, and see it's linked to an object in wikidata, you have no
> way of seeing if that is the whole wikidata object, or just a part of that
> object, unless you download the whole OSM database. Or if you are a human,
> and you look at
>
 the wikipedia article, and see there should be a whole bunch of dwarfs.
> But that example doesn't seem as important.
>

You're trying to solve the data problem (to the extent that it even is a
problem) in a defective
way.  It's defective because wikidata is not an integrated part of OSM
designed to group objects.
It's outside of our control; even if we can abuse it that way,  a random
edit to wikidata will
lose the object grouping.  The correct way to group them is with a
relation.  If we don't have a
suitable type of  relation then propose one.  Don't use wikidata as a
workaround for not having a
suitable relation type or not having a part_of_a_group=yes tag.  And even
without any of that,
an overpass query in the general area for artwork_type=statue + other tags
they have in
common will find them.

It's not a problem for humans either.  If they're not interested in looking
at the data item then
it doesn't matter if it's tagged wikidata=* or part:wikidata=* because they
won't follow it.  If
they are interested in looking at the data item then it doesn't matter if
it's tagged wikidata=*
or part:wikidata=* because they'll reach the same data item either way and
realize there
are seven dwarfs.  And won't be able to find the other six easily from
there.  So a relation
is still the best way to do it, then apply wikidata=* to the relation.

Currently, the second most numerous wikidata tag in OSM is
> https://www.wikidata.org/wiki/Q2961670, an item that describes all the
> roman roads in historic Gaul in France. All those ways, close to 500 of
> them, have wikidata=Q296167. That is obviously not good tagging. But how do
> you differentiate good wikidata tagging from bad tagging? I think this rule
> and part:wikidata are the way to clean this up. I would give all these
> roads part:wikidata=Q29616, and than that looks much closer to reality.
>

I think the only sensible solution is to delete the wikidata tags from
*all* of them.  That item is
for a category, not a unique object.  OSM relations are not categories
because we don't tag
categories (it would result in a gigantic taxonomic hierarchy of tagging).
Those road should
never have been given that wikidata tag; individual roads get a wikidata
tag only if that data
item applies solely to that particular road.

It seems to me that you're trying to find a way of mapping anything that
has a wikidata tag.
If so, that seems like a bad idea.  Use a wikidata tag to add extra
information about a unique
OSM object, don't invent OSM objects and/or ways of mapping things in order
to put every
wikidata item into OSM.  We could put wikidata=Q2 on every object,
following your line of
reasoning.  Oh, sorry, part:wikidata=Q2.

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

Re: [Tagging] building typology vs usage

[Wolfgang Zenker]

* Joseph Eisenberg  [190913 16:45]:
> I certainly recall reading about this in the wiki, but I agree that in
> common use, the building=* tag appears to be used mostly for the
> current function, rather than specifying a certain form.

That would be kind of redundant, wouldn't it? We already use other tags
for the current function of a building, so building=* is mostly useful
when the building does look like it was built for some other function
than it's current one.

Wolfgang
( lyx @ osm )

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

Re: [Tagging] building typology vs usage

[Joseph Eisenberg]

I certainly recall reading about this in the wiki, but I agree that in
common use, the building=* tag appears to be used mostly for the
current function, rather than specifying a certain form.

The most common values of building= are:

0) yes (non-specific)
1) =house - both a structural form and a function (residential)
2) =residential - function, not really a specific form of building
3) =garage - function and form
4) =apartments - function (multi-family residential)
5) =detacted - synonym for house but more specific
6) =hut - form of construction (crude/simple)
7) =industrial - function
8) =shed - form but also function ("used as storage or workshop")
9) =roof - form
10) =terrace - form but also function (residential)
11) =school - function mainly
12) =garages - form and function
13) =construction - lifecycle state
14) =retail - mainly function, because the form of retail buildings varies
15) =greenhouse - form = function here
16) =barn - form=function
17) =farm_auxiliary - function (no particular form, and this is only
the general function)
18) =church - claimed to be a form?
19) =warehouse - function (but usually has the same general form)
20) =service - function

Often the "form follows function" as they say, but it looks like
tagging the function of a building is as common as tagging the form.

- Joseph

On 9/13/19, Dave F via Tagging  wrote:
> On 11/09/2019 14:50, Paul Allen wrote:
>>
>> I said that if it was a church and looks like a church then tag the
>> building as a church even if it now functions as something else.
>
> Buildings don't have a 'type'. There's no 'class', no standard
> architectural style or size. A quick image search proves that.
>
> OSM "is a place for mapping things that are both real and current"
>
> 'building=*' is to indicate its current usage.
>
> /If/ there's an insistence on recording it's original usage, if actually
> *known*,not just observed, then an appropriate *clearly defined* tag
> should be used. Something along the lines of 'original building use".
>
> Frederik suggests "Everyone may be confused about this.". It's been
> evident for years that those who are perplexed are the ones who imagined
> a 'typology'. I believe they've based their assumptions on anecdotal
> observations around their own neighbourhoods. OSM is global.
>
> DaveF
>
> ___
> 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] building typology vs usage

[Kevin Kenny]

On Fri, Sep 13, 2019 at 9:20 AM Dave F via Tagging
 wrote:
> On 11/09/2019 14:50, Paul Allen wrote:
> >
> > I said that if it was a church and looks like a church then tag the 
> > building as a church even if it now functions as something else.
>
> Buildings don't have a 'type'. There's no 'class', no standard
> architectural style or size. A quick image search proves that.
>
> OSM "is a place for mapping things that are both real and current"
>
> 'building=*' is to indicate its current usage.
>
> /If/ there's an insistence on recording it's original usage, if actually
> *known*,not just observed, then an appropriate *clearly defined* tag
> should be used. Something along the lines of 'original building use".
>
> Frederik suggests "Everyone may be confused about this.". It's been
> evident for years that those who are perplexed are the ones who imagined
> a 'typology'. I believe they've based their assumptions on anecdotal
> observations around their own neighbourhoods. OSM is global.

In the part of the country where I live, the vernacular architecture
is based on an idea of hardline Protestantism that rejected trappings.
The older buildings tend to be symmetric boxes (albeit with
more-or-less steeply pitched roofs; it *snows* here) that give no hint
to their purpose. There's one listed historic building in my township
that in its history served as a school, a social center, and a private
house, and is now subdivided into office space. The only real
indicator of its current purpose is that the front door has a
sandstone lintel reading, 'District School Nº 4'.

Likewise, buildings may reveal obviously their complex history.
Consider the Imam al-Khoei Foundation building in Jamaica, Queens, New
York.  
https://en.wikipedia.org/wiki/Imam_Al-Khoei_Benevolent_Foundation#/media/File:Imam_Al-Khoei_Foundation_8989_Van_Wyck_jeh.jpg
https://www.flickr.com/photos/imjustwalkin/29799850223 .  It's
obviously a converted factory - and just as obviously a mosque. At
what point does the former usage become obscured enough that the
building acquires a new type?

The example that everyone loves to cite is 'building=church'. That
appears to come about because people imagine very likely a building
with a tall steeple or campanile, stained glass windows, perhaps built
in a Gothic or Romanesque style.  But a couple of centuries ago in
stern, Calvinist, North America, churches were plain affairs, with no
stained glass, no iconography, not even a cross atop the steeple:
https://www.flickr.com/photos/steveguttman/2814490383 is fairly
typical of a church of the denomination and period. Is that obviously
of the "church" type?  If so, can you say what features in particular
distinguish it from
https://www.oldhousedreams.com/wp-content/uploads/2018/07/10-21-Haskell.jpg,
which is pretty typical of a primary school of the same period? Many
of these buildings also started out their lives as government
buildings - the "meetinghouse" of a village would have been its seat
of government as well as its church, in an era before the separation
of church and state was a familiar idea. Meetinghouses were often even
plainer than the examples that I've given so far.
https://commons.wikimedia.org/wiki/File:Exterior,_Sandown_Meetinghouse.jpg
was in fact the town's meetinghouse, simultaneously its place of
worship and seat of government, but from the exterior could just have
easily have been a workshop, a school, or a boardinghouse.

If you have a high-Gothic building with twin campaniles, a magnificent
rose window, and similar trappings, that's now a banquet hall or has
been subdivided into flats, go ahead and tag it as "building=church"
if you like. I really don't care. But don't expect that every building
will fit an imagined typology. Frederik and others have told me
repeatedly, "if it still looks like a church, tag it building=church,
if it still looks like a school, tag it building=school, and so on."
But that doesn't inform me about the historic buildings that I'm most
interested in tagging. For the most part their history is complicated,
and their appearance is either likewise complicated, or else
undistinguished. What does a church, or a school, or a government
building, look like?

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] building typology vs usage

[Dave F via Tagging]

On 11/09/2019 14:50, Paul Allen wrote:


I said that if it was a church and looks like a church then tag the building as 
a church even if it now functions as something else.


Buildings don't have a 'type'. There's no 'class', no standard 
architectural style or size. A quick image search proves that.


OSM "is a place for mapping things that are both real and current"

'building=*' is to indicate its current usage.

/If/ there's an insistence on recording it's original usage, if actually 
*known*,not just observed, then an appropriate *clearly defined* tag 
should be used. Something along the lines of 'original building use".


Frederik suggests "Everyone may be confused about this.". It's been 
evident for years that those who are perplexed are the ones who imagined 
a 'typology'. I believe they've based their assumptions on anecdotal 
observations around their own neighbourhoods. OSM is global.


DaveF

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

Re: [Tagging] Feature Proposal - RFC - Reusable packaging

[Paul Allen]

On Fri, 13 Sep 2019 at 11:04, Antoine Jaury via Tagging <
tagging@openstreetmap.org> wrote:

> marc marc wrote:
>
> "well in this case, this shop isn't a bulk_purchase=yes shop
> bulk_purchase=* in osm mean that you can BUY item in bulk
> not that the shop has a stock of product that he packs for you on site.
> bulk_purchase informs how the customer can have the product and not in
> what form the stock in the shop is kept"
>
> I disagree on that definition. For me bulk purchase means that you can buy
>
>
> the exact quantity you want and is not related to the packaging even if in
>
>  most of the cases you have the opportunity to re-use a paper bag you already 
> used.
>
>
In British English (which OSM generally uses) "bulk" means "being large in
size, mass or
volume (of goods, etc.)."  See https://en.wiktionary.org/wiki/bulk

The same applies to "bulk purchasing" which means "the purchase of much
larger quantities
than the usual, for a unit price 
that is lower than the usual."  See
https://en.wikipedia.org/wiki/Bulk_purchasing

 Also, the wiki page of the tag is not clear at all about that and we can
>
>  see multiple topics where people don't have the same definition:
>
>
Then the wiki page should be fixed and, in my opinion, fixed to reflect
British English usage.

I agree that we need a tag to indicate what you think of as bulk
purchasing, that is where
you bring your own container.  I'm not sure if there's a generally-accepted
term for this
in British English yet.  I've seen "zero waste" (misleading, because it's
not zero) and
"unpackaged" (also misleading as it is in a package, just not a package
that you can
take away) as well as "bring your own container."  There are also "plastic
free"
shops, but that doesn't necessarily mean the same thing, although there is
quite
a lot of overlap.

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

Re: [Tagging] Feature Proposal - RFC - Reusable packaging

[Antoine Jaury via Tagging]

marc marc wrote:

"well in this case, this shop isn't a bulk_purchase=yes shop
bulk_purchase=* in osm mean that you can BUY item in bulk
not that the shop has a stock of product that he packs for you on site.
bulk_purchase informs how the customer can have the product and not in
what form the stock in the shop is kept"


I disagree on that definition. For me bulk purchase means that you can buy the 
exact quantity you want and is not related to the packaging even if in most of 
the cases you have the opportunity to re-use a paper bag you already used. 
Also, the wiki page of the tag is not clear at all about that and we can see 
multiple topics where people don't have the same definition:

https://wiki.openstreetmap.org/wiki/Key:bulk_purchase  says: "Tag to use for  
bulk purchasing, if a shop offers 
products/without packaging/."

But the wiki page defining the "bulk purchasing" in the link says: "Bulk purchasing 
is the purchase of much larger quantities than the usual, for a unit price that is lower than the 
usual."

The two definitions presented in the same sentence don't say the same thing. In 
some countries there are a lot of shops specialized in selling products in 
large quantity. But you almost always have a container with the product.

Another thing is that it's really rare to be able to buy products without 
packaging. It's possible for bread for example but not with most of the food 
products. In most of the cases you need a package but the package could be a 
reusable one (glass jar, reused paper bag...).

Maybe the definition of the bulk_purchase tag is not clear enough and could be 
merge with the reused_packaging one.

I just see different things here that may need to be distinguished:
- buying products in large quantity,
- buying products without packaging,
- buying products using a reused package (a package that the customer chose and 
bring to buy the product such as a reused paper bag or a package that the shop 
proposes and expects the client to bring it back later),
- buying a product in bulk in order to buy the right quantity, no more, no less.

marc marc wrote:


PS: I think your butcher is outdated, I haven't seen any refusals
for at least 2 years :) including in Carrefour-like shop


I can tell you from many feedback I heard with different members of the 
Zero Waste France organization that there are still a lot of shops that 
refuse. And that's a barrier for people who want to start to reduce 
their amount of waste. That's why Zero Waste is making stickers to 
identify the shops that accept reusable containers. There is a real need 
identified there.


marc marc wrote:


Frederik Ramm wrote:

Do we even have a remote hope of achieving a
level of completeness and timeliness that makes this usable?

no more or no less than for landuses.
in places where there are contributors interested in the subject,
applications/sites using osm are the best ones.
where no osm contributors but contributors to proprietary databases,
those are the best.


That's also why I propose to add a condition for shops for which the 
involvement is not clear enough in the long time:
A shop accepting reusable containers should physically display it on 
the shop. It could be a sticker on the shop window, a sign hand-made 
by the shop saying "here you can bring your reusable containers" or a 
shop that explicitly says "Zero waste shop" meaning that the 
philosophy is not to sell products with packaging.


This will limit the tag to shops that really want to do the involvement. And I 
think that when you start doing it and you display it it's complicated to come 
back to your decision. This won't be seen as a good change from your customers 
if you stop accepting reusable container from one day to another.


On 12/09/2019 13:18, marc marc wrote:

well in this case, this shop isn't a bulk_purchase=yes shop
bulk_purchase=* in osm mean that you can BUY item in bulk
not that the shop has a stock of product that he packs for you on site.
bulk_purchase informs how the customer can have the product and not in
what form the stock in the shop is kept

PS: I think your butcher is outdated, I haven't seen any refusals
for at least 2 years :) including in Carrefour-like shop

Le 12.09.19 à 12:54, Antoine Jaury via Tagging a écrit :

And sorry Marc but I don't have an article explaining the use of one-use
only bag proposed by bulk purchase shops.

In my case, I buy only bulk purchase products and it often happen in
supermarket for example that you can only use the supermarket's paper
bags with a plastic window on the bag to see what is inside. I tried
once to use in an "Carrefour shop" a paper bag I reused from another
shop and one of the sell men explained to me that I couldn't do that
because they need to see what is inside the bag without opening it and
for hygienic reasons we can't reuse a bag multiple times.

As explained also in my previous message: butchers, backery, 

Re: [Tagging] Proposed features / landuse=open_defecation

[Bob Kerr via Tagging]

I have reworked the page as per your instructions, please let me know if it 
still needs more clarification.

https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dopen_defecation

Cheers

Bob

> On 13 Sep 2019, at 03:13, Joseph Eisenberg  wrote:
> 
> Thanks for working on this, Bob,
> 
> Check out the page "Proposal_process" and in particular
> Proposal_process#Creating_a_proposal_page to help improve the
> formatting and make sure you've included important information.
> 
> Please clarify exactly what should be mapped with this new tag. Is
> going to be added to whole villages, as suggested in the section about
> "open_defecation=yes?
> 
> "It would have its own sign and could be used as a node or area.
> Although it may be added to small villages to indicate if it is their
> primary source of human waste disposal."
> 
> This would not be a good idea, since it's not possible for mappers to
> confirm that every house or a majority of houses in a village lack
> latrines or toilet. But the rest of the page suggests that this tag is
> supposed to be applied to areas where there are visible signs, in
> other words, there's human feces exposed on the ground?
> 
> There are a couple of problems with the proposed subtags. It's not
> best practice to use abbreviations or uppercase letters in tags, so
> instead of "ODA_" it should be "open_defecation_" or
> "open_defecation:", if need.
> 
> "ODA_Radius_.." "ODA_area_size..." - The first two subtags are not
> needed - the area can be mapped instead, and this provides the shape
> and size just from the position of the nodes in the database.
> 
> "ODA_survey_date=" - there is already a tag for this, survey:date=* or
> source:date=* , but it is recommended to add such information to the
> changeset rather than to individual OSM objects.
> 
> "ODA_responsibility=" is unclear. What would this mean, and how would
> a local mapper in confirm this information?
> 
> "ODA_proposed_solution=" - Unfortunately, this is not appropriate for
> Openstreetmap. We map real, current features, not opinions, reviews or
> suggestions, because such information is too subjective for individual
> mappers to maintain.
> 
> "ODA_abandoned=yes/no" - generally features in Openstreetmap should be
> current, so if an area that was used for open defecation in the past
> has now been abandoned, and there are no signs "on the ground", then
> it should be removed from the database. Some mappers use a prefix
> "abandoned:" like "abandoned:landuse=open_defecation".
> 
> However, if the area is "disused" - not currently in use, but there
> are still signs that it was recently used, and perhaps it's still a
> health hazard because of the presence of decomposing human waste, this
> could be tagged with "disused=yes".
> 
> ODA_survey_hazardous materials_data_weblink= - I'm not sure what is
> intended by this tag. Perhaps the existing tag url=* would be
> sufficient?
> 
> (I've also left these comments on the Talk page of the proposal, so we
> can continue discussion there)
> 
> -Joseph Eisenberg
> 
>> On 9/12/19, Bob Kerr via Tagging  wrote:
>> I have created a proposal page for landuse=open defecation.
>> 
>> https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dopen_defecation
>> 
>> Please review it, my wiki page editing skills have suffered from lack of use
>> so it could do with a little tidy if anyone wants to.
>> 
>> Please discuss your thoughts here. The most controversial area is I am using
>> the landuse tag rather than open_defication = yes. Please let me know which
>> you would prefer.
>> 
>> All the best
>> 
>> Bob
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Reusable packaging

[Martin Koppenhoefer]

sent from a phone

> On 12. Sep 2019, at 13:52, Frederik Ramm  wrote:
> 
> Do we even have a remote hope of achieving a
> level of completeness and timeliness that makes this usable?


if your apprehension comes true and we became the default go-to business 
directory, then definitely yes (but we would have to fight much more with spam 
and manipulation of data out of individual interests, than we do now). This 
role is now mostly taken by G Maps (and, depending on the business type, some 
other companies like yelp, booking or tripadvisor,...), but it isn’t excluded 
we could grow into this role as well.

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