Re: [Tagging] Refining heritage tag

[Paul Allen]

On Sat, 18 Apr 2020 at 00:43, Martin Koppenhoefer 
wrote:

I still don’t see why we would need a new tag heritage_title rather than
> the established protection_title##
>

>From  https://wiki.openstreetmap.org/wiki/Key:protection_title

Requires
boundary=national_park
boundary=protected_area

So not applicable to heritage=*.

Admittedly, the wiki page for protected_area states that it can be used
on heritage sites, but when you read through the rest of the page it's
not talking about buildings.  Or even a castle complex.  It's talking about
things like "registered historic landscapes" (a UK term), which are
historic and therefor e have heritage value, but aren't covered by the
existing heritage=* key.  Instead they're covered by
boundary=protected_area (I think).

The heritage=* and boundary=protected_area are pretty much orthogonal
in what they cover.  There might be cases where both tags apply but they
are going to be exceptions rather than the rule.

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

Re: [Tagging] Refining heritage tag

[António Madeira]

Now that I've read the German wiki more carefully, I realized that they
consider World Heritage not only as natural areas but also for
buildings, although they clearly state "Always with *boundary
=protected_area
*"
which makes this somewhat confuse... I don't mind at all to use
"protection_title", but I prefer not to create unnecessary conflicts.


Às 20:43 de 17/04/2020, Martin Koppenhoefer escreveu:


sent from a phone


On 18. Apr 2020, at 01:04, Paul Allen  wrote:

The fraction of heritage POIs which are
protected areas is less than 1%.


I still don’t see why we would need a new tag heritage_title rather than the 
established protection_title
Maybe protected “area” is a strange tag for a building, but this doesn’t extend 
to protection_title, or are there objects where we would need both tags?

Cheers Martin


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

Re: [Tagging] Refining heritage tag

[Martin Koppenhoefer]

sent from a phone

> On 18. Apr 2020, at 01:04, Paul Allen  wrote:
> 
> The fraction of heritage POIs which are
> protected areas is less than 1%.


I still don’t see why we would need a new tag heritage_title rather than the 
established protection_title
Maybe protected “area” is a strange tag for a building, but this doesn’t extend 
to protection_title, or are there objects where we would need both tags?

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

Re: [Tagging] Refining heritage tag

[Paul Allen]

On Fri, 17 Apr 2020 at 23:38, Martin Koppenhoefer 
wrote:

because it leads to key bloat. It makes evaluation harder or more
> complicated  if you have to cater for a lot of different keys which all
> basically are about the same thing: the ref that an operator has assigned
> to it
>

But the other way leads to namespace collisions which cause problems when
searching for keys. Like it or not, ref:*=* is used for a lot of things, not
just heritage.  Too late to change.  So do we want a place where searches
for ref:foo are going to turn up false hits unless you can think of other
appropriate search conditions to narrow it down or do we want
heritage:ref:foo
so we can avoid collisions?

There are pros and cons both ways.

heritage sites are already within the scheme, this was introduced with the
> protected area proposal and class 22 already covers heritage protection
>

Some, but by no means all, POIs with heritage tags are protected areas.  All
of the heritage POIs I've mapped have been listed buildings or scheduled
monuments: buildings, bridges, castles, megaliths, mottes, that sort of
thing.  Over 100 listed buildings in my town alone:
https://britishlistedbuildings.co.uk/wales/cardigan-ceredigion
(I think I've mapped them all).  Over 250 scheduled monuments in my
county: https://ancientmonuments.uk/wales/ceredigion
(I've not mapped anywhere near all of them).  Not a single one of them is
a suitable candidate for boundary=protected_area.

Yes, there are also protected areas in Wales.  But not as many as there
are listed buildings in my town.  The fraction of heritage POIs which are
protected areas is less than 1%.

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

Re: [Tagging] Refining heritage tag

[Martin Koppenhoefer]

sent from a phone

> On 18. Apr 2020, at 00:08, António Madeira  wrote:
> 
> I know there are many ref tags that don't follow this procedure, but if this 
> is useful why not starting to adopt it for some schemes like this one?


because it leads to key bloat. It makes evaluation harder or more complicated  
if you have to cater for a lot of different keys which all basically are about 
the same thing: the ref that an operator has assigned to it


> It would turn the entire scheme more tight and organized, with a more logical 
> structured "tree".


it makes it much more tedious to type in, because it renders autocompletion 
less efficient. I hate to type long keys because they all start the same, 
particularly on mobile devices. It also makes things harder for preset 
development, it’s not something that could not be solved, but everybody with 
database columns for keys will hate a schema like this.


> Anyway, this will obviously have some resistance, but I think it is well 
> worth to debate about it.
> 
> 
>>  
>>> 
>>> heritage:xxx:criteria=* - This tag is for the classification criteria used 
>>> by the xxx operator. It changes the previous xxx:criteria=*
>>> heritage:xxx:inscription_date=* - This tag is used for the date the 
>>> heritage was officially registered by xxx operator. It changes the previous 
>>> xxx:inscription_date=*
>> 
>> 
>> same comment as above for ref.
>> 
>>  
>>> 
>>> heritage:xxx:designation_title=* - This tag is used for the heritage title 
>>> (international or national). This is new and is an attempt to circumvent 
>>> the use of protection_title=* which is wrong in this context. 
>> 
>> 
>> why is protection title "wrong"?
> 
> Show Quoted Content
>>  
>>> 
>>> heritage:xxx:criteria=* - This tag is for the classification criteria used 
>>> by the xxx operator. It changes the previous xxx:criteria=*
>>> heritage:xxx:inscription_date=* - This tag is used for the date the 
>>> heritage was officially registered by xxx operator. It changes the previous 
>>> xxx:inscription_date=*
>> 
>> 
>> same comment as above for ref.
>> 
>>  
>>> 
>>> heritage:xxx:designation_title=* - This tag is used for the heritage title 
>>> (international or national). This is new and is an attempt to circumvent 
>>> the use of protection_title=* which is wrong in this context. 
>> 
>> 
>> why is protection title "wrong"?
>> 
>> As discussed in this thread before, the protection title tag was created for 
>> natural areas. Unless an heritage site coincides with a natural protected 
>> area, it's not correct to use that tag. Unless we extend its scope for this 
>> scheme.
>> 
> 
> As discussed in this thread before, the protection title tag was created for 
> natural areas. Unless an heritage site coincides with a natural protected 
> area, it's not correct to use that tag. Unless we extend its scope for this 
> scheme.
> 


heritage sites are already within the scheme, this was introduced with the 
protected area proposal and class 22 already covers heritage protection 

https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area#Social-protected-area

Cheers Martin 


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

Re: [Tagging] Refining heritage tag

[António Madeira]

Hi, Martin.
Thank you for your input.



Às 06:38 de 17/04/2020, Martin Koppenhoefer escreveu:

Am Fr., 17. Apr. 2020 um 04:27 Uhr schrieb António Madeira via Tagging
mailto:tagging@openstreetmap.org>>:

After communicating with lutz from Historic.Place, he told me they
didn't create this heritage scheme, they just adopted it.
I took the opportunity to present him my proposal of refining this
scheme and I got his support to go ahead with it, so I'm
presenting it here in order to make the necessary adjustments with
a new proposal.

heritage=* - This is the main tag, which uses the admin_level [not
changed].


currently 147558 instances


heritage:operator=xxx - This is the tag for the official operator.
I propose using separators [;] in those cases where an heritage
has an international and a national operator.



currently 122076 instances, of which around 150 already have semicolon
separated multivalues. There are not many multivalues, but I would see
it as the already standard method (based on values of other tags), and
believe it would be ok to add this to the wiki without further voting.

heritage:ref:xxx=* - This tag is for the code/number reference of
the operator(s) above. It changes the previous ref:xxx=*



there are already some heritage:ref tags (and subtags like
heritage:ref:vie)
name 12188 heritage:ref, and 500+ heritage:ref:xxx
It would be more complicated to count "ref:xxx" combined with heritage.
I am more reluctant to welcome this idea. What would be the benefit?
Generally, standard tags (like "ref" and derived tags like ref:mhd)
would seem the usual way, no? We do not add highway:ref=* tags for
example, because the tags refer to the object they are put on.
Prefixing them with "heritage" would only invite people to mix up
objects of different nature into the same OSM object.



The benefit would be exactly that, to be able to count references which
we know for certain that are related to the heritage scheme.
I know there are many ref tags that don't follow this procedure, but if
this is useful why not starting to adopt it for some schemes like this one?
It would turn the entire scheme more tight and organized, with a more
logical structured "tree".
Anyway, this will obviously have some resistance, but I think it is well
worth to debate about it.




heritage:xxx:criteria=* - This tag is for the classification
criteria used by the xxx operator. It changes the previous
xxx:criteria=*
heritage:xxx:inscription_date=* - This tag is used for the date
the heritage was officially registered by xxx operator. It changes
the previous xxx:inscription_date=*



same comment as above for ref.


heritage:xxx:designation_title=* - This tag is used for the
heritage title (international or national). This is new and is an
attempt to circumvent the use of protection_title=* which is wrong
in this context.



why is protection title "wrong"?


As discussed in this thread before, the protection title tag was created
for natural areas. Unless an heritage site coincides with a natural
protected area, it's not correct to use that tag. Unless we extend its
scope for this scheme.




heritage:xxx:website=* - Used for the heritage official website 
(international or national).



same comment as above for ref. I would even suggest to use a plain
"website" rather than an xxx:website, as long as there is only one
operator (very common situation).
Current use is 15772 heritage:website and 11258 website, plus 949
heritage:website:sipa (looks like an import), 713 contact:website, 225
heritage:website:arqueologia and 39 heritage:operator:website (IMHO to
deprecate, we're not a general web directory)

In general, let's use standard tags as long as there aren't good
reasons for creating specific derivative tags.


I agree with your observations here, but we need to consider that the
website of the building (or whatever) has its own website, and the
official operator has its proper webpage related to the heritage
classification. This is very frequent and it would be important to
differentiate between the normal website and the operator's website.


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

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[António Madeira]

If a refugee site has a well established name (and, unfortunately, there
are many examples all over the world), I don't see why it can't have a
"place" tag.

Às 18:24 de 17/04/2020, lukas-...@web.de escreveu:

Hi,
my question is whether this then rather would be something for the
"place" tag? Or did we maybe have that discussion already?
--Lukas
*Gesendet:* Freitag, 17. April 2020 um 18:28 Uhr
*Von:* "Manon Viou" 
*An:* "Tag discussion, strategy and related tools"

*Betreff:* Re: [Tagging] Feature Proposal - RFC - Refugee Site Location
Hello everyone,
It seems I haven't been very clear in my explanations; I sometimes
have a bit of trouble choosing the right word (especially in English).
And I think the “small”/”large” discussion is going the wrong direction…
The new tag we want to propose is to map refugee camps or as it’s
seems better to say in English now : refugee sites. So we want to map
*human settlement*.
The social_facility=shelter tag is very suitable to map single or
individual building or a small group of buildings like a refugee
center, an accommodation center or a care and hosting center for refugees.
But (according to many people now)  the social_facility=shelter tag is
not suitable to map  refugee camps that are human settlements,
populated places where hundreds or  thousands people live.
That’s why we propose to create a new value for the amenity tag :
amenity=refugee_site, to map human settlement where refugees can find
protection.
kind regards,
Manon

Le 17 avril 2020 à 13:03, Warin <61sundow...@gmail.com> a écrit :
On 17/4/20 5:29 am, Manon Viou wrote:

Hello,
According to Martin and Warin, the difference between large
and small refugee site is not clear enough,
Martin suggested to use population capacity, for instance less
than 200 people fro small refugee site,
Warin suggested to use number of square meters,
For what I have observed, small facilities sheltering refugee
(for instance: refugee centers, accommodation center, care and
hosting center, church) are not exactly what we can call
refugee site. the difference, beyond the number of building,
number of population or square meter, is quite obvious.

?? How is it 'obvious'???

I have no idea of what that 'obvious' thing is!

Is it really necessary to set a precise rule ?

At the moment there is nothing that can be used to distinguish
between the two.

Suggestion have been made on the number of buildings, number of
people and the area.

Please tell us how you distinguish between them.

I would rather suggest to share some example (like the ones
mentioned above) in order to help contributors to decide if it
rather an amenity=refugee_site or a social_facility=shelter.

Examples are fine. But there must be a statement in words of the
difference between them.

Regards,
Manon

Le 16 avril 2020 à 02:16, Warin <61sundow...@gmail.com>
 a écrit :
On 16/4/20 1:23 am, Manon Viou wrote:

Thanks Martin, yes, refugee sites should always be
temporary even if, as you said, some turn to be very
long term places. That's why we do not suggest to add
temporary/permanent options.
Manon

In which case the description for amenity=social_facility
+ social_facility=shelter is not correct.

If it is to be done on area then specify the number of
square meters rather than the number of buildings???

Buildings can be a of different sizes and capacities. An
area could be more consistent as to the number of people.

Imagery may not be up to date so counting buildings may
not be possible.

Le 15 avril 2020 à 11:36, Martin Koppenhoefer <
dieterdre...@gmail.com
> a écrit :
sent from a phone

On 15. Apr 2020, at 01:13, Warin <
61sundow...@gmail.com
> wrote:
I would think amenity=refugee_site is an area
set aside for the non-temporary residential
use of refugees

maybe I’m a dreamer, but I would expect all
refugee related features to be “temporary”, even
if we are talking about relatively long periods of
time
Cheers Martin

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

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Lukas-458]

Hi,

my question is whether this then rather would be something for the "place" tag? Or did we maybe have that discussion already?


 

--Lukas

 

Gesendet: Freitag, 17. April 2020 um 18:28 Uhr
Von: "Manon Viou" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - Refugee Site Location



Hello everyone,

 

It seems I haven't been very clear in my explanations; I sometimes have a bit of trouble choosing the right word (especially in English). And I think the “small”/”large” discussion is going the wrong direction…

 

The new tag we want to propose is to map refugee camps or as it’s seems better to say in English now : refugee sites. So we want to map human settlement.

 

The social_facility=shelter tag is very suitable to map single or individual building or a small group of buildings like a refugee center, an accommodation center or a care and hosting center for refugees.

 

But (according to many people now)  the social_facility=shelter tag is not suitable to map  refugee camps that are human settlements,  populated places where hundreds or  thousands people live.

 

That’s why we propose to create a new value for the amenity tag : amenity=refugee_site, to map human settlement where refugees can find protection.

 

kind regards, 

Manon

 


Le 17 avril 2020 à 13:03, Warin <61sundow...@gmail.com> a écrit :
 
On 17/4/20 5:29 am, Manon Viou wrote:


Hello, 

According to Martin and Warin, the difference between large and small refugee site is not clear enough, 
Martin suggested to use population capacity, for instance less than 200 people fro small refugee site, 

Warin suggested to use number of square meters, 

For what I have observed, small facilities sheltering refugee (for instance: refugee centers, accommodation center, care and hosting center, church) are not exactly what we can call refugee site. the difference, beyond the number of building, number of population or square meter, is quite obvious.


 

?? How is it 'obvious'???

 

I have no idea of what that 'obvious' thing is!

 

 


Is it really necessary to set a precise rule ?


 

At the moment there is nothing that can be used to distinguish between the two.

Suggestion have been made on the number of buildings, number of people and the area.

 

Please tell us how you distinguish between them.

 


I would rather suggest to share some example (like the ones mentioned above) in order to help contributors to decide if it rather an amenity=refugee_site or a social_facility=shelter. 


 

Examples are fine. But there must be a statement in words of the difference between them.


Regards, 

Manon

Le 16 avril 2020 à 02:16, Warin <61sundow...@gmail.com> a écrit :
 
On 16/4/20 1:23 am, Manon Viou wrote:


Thanks Martin, yes, refugee sites should always be temporary even if, as you said, some turn to be very long term places. That's why we do not suggest to add temporary/permanent options. 

Manon


 

In which case the description for amenity=social_facility + social_facility=shelter is not correct.

 

If it is to be done on area then specify the number of square meters rather than the number of buildings???

Buildings can be a of different sizes and capacities. An area could be more consistent as to the number of people.

Imagery may not be up to date so counting buildings may not be possible. 

 



Le 15 avril 2020 à 11:36, Martin Koppenhoefer < dieterdre...@gmail.com> a écrit :

 

sent from a phone

 


On 15. Apr 2020, at 01:13, Warin < 61sundow...@gmail.com> wrote:

 

I would think amenity=refugee_site is an area set aside for the non-temporary residential use of refugees


 

maybe I’m a dreamer, but I would expect all refugee related features to be “temporary”, even if we are talking about relatively long periods of time

 

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


 




Manon Viou

Coordinatrice projet Missing Maps

 m_v...@cartong.org |  manon.viou



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


 




Manon Viou

Coordinatrice projet Missing Maps

 m_v...@cartong.org |  manon.viou
 +33 (0)4 79 26 28 82 |  +33 (0)7 83889839

 Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E

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




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

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Manon Viou]

 
 
  
   
Hello everyone,
   
   

   
   
It seems I haven't been very clear in my explanations; I sometimes have a bit of trouble choosing the right word (especially in English). And I think the “small”/”large” discussion is going the wrong direction…
   
   

   
   
The new tag we want to propose is to map refugee camps or as it’s seems better to say in English now : refugee sites. So we want to map 
human settlement.
   
   

   
   
The social_facility=shelter tag is very suitable to map single or individual building or a small group of buildings like a refugee center, an accommodation center or a care and hosting center for refugees.
   
   

   
   
But (according to many people now)  the social_facility=shelter tag is not suitable to map  refugee camps that are human settlements,  populated places where hundreds or  thousands people live.
   
   

   
   
That’s why we propose to create a new value for the amenity tag : amenity=refugee_site, to map human settlement where refugees can find protection.
   
   

   
   
kind regards, 
   
   
Manon
   
   

   
  
  
   Le 17 avril 2020 à 13:03, Warin <61sundow...@gmail.com> a écrit : 
   
   
   
On 17/4/20 5:29 am, Manon Viou wrote: 

   
   

 Hello, 


 According to Martin and Warin, the difference between large and small refugee site is not clear enough,  
 Martin suggested to use population capacity, for instance less than 200 people fro small refugee site, 


 Warin suggested to use number of square meters, 


 For what I have observed, small facilities sheltering refugee (for instance: refugee centers, accommodation center, care and hosting center, church) are not exactly what we can call refugee site. the difference, beyond the number of building, number of population or square meter, is quite obvious.

   
   
   ?? How is it 'obvious'??? 
   
   I have no idea of what that 'obvious' thing is! 
   
   
   

 Is it really necessary to set a precise rule ?

   
   
   At the moment there is nothing that can be used to distinguish between the two. 
   Suggestion have been made on the number of buildings, number of people and the area. 
   
   Please tell us how you distinguish between them. 
   
   

 I would rather suggest to share some example (like the ones mentioned above) in order to help contributors to decide if it rather an amenity=refugee_site or a social_facility=shelter. 

   
   
   Examples are fine. But there must be a statement in words of the difference between them. 
   

 Regards, 


 Manon


 Le 16 avril 2020 à 02:16, Warin 
 <61sundow...@gmail.com> a écrit : 
 
 
 
  On 16/4/20 1:23 am, Manon Viou wrote: 
  
 
 
  
   Thanks Martin, yes, refugee sites should always be temporary even if, as you said, some turn to be very long term places. That's why we do not suggest to add temporary/permanent options. 
  
  
   Manon
  
 
 
 In which case the description for amenity=social_facility + social_facility=shelter is not correct. 
 
 If it is to be done on area then specify the number of square meters rather than the number of buildings???
 Buildings can be a of different sizes and capacities. An area could be more consistent as to the number of people.
 Imagery may not be up to date so counting buildings may not be possible. 
 
 
  
   
Le 15 avril 2020 à 11:36, Martin Koppenhoefer < 
dieterdre...@gmail.com> a écrit :
   
   

   
   
sent from a phone
   
   

   
   

 On 15. Apr 2020, at 01:13, Warin < 
 61sundow...@gmail.com> wrote:


 


 I would think amenity=refugee_site is an area set aside for the non-temporary residential use of refugees

   
   

   
   
maybe I’m a dreamer, but I would expect all refugee related features to be “temporary”, even if we are talking about relatively long periods of time
   
   

   
   
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 
 


  


 
 Manon Viou
 Coordinatrice projet Missing Maps
  m_v...@cartong.org |  manon.viou

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

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Martin Koppenhoefer]

sent from a phone

> On 16. Apr 2020, at 23:33, António Madeira  wrote:
> 
> Do we divide big schools from small schools? Or small theatres from big 
> theatres?


things can change nature just by changing size or quantity. We have different 
tags for a single tree and a tree row and a forest. We also have different tags 
for a stream and a river, for a bakery and a factory which produces brea. Or 
hamlet, village, town and city. There could be reasons to distinguish 
facilities by size, provided they are changing nature due to / along with size. 


> There are refugee_sites which are de facto towns and villages, so those would 
> be mapped as a normal place.


they could get additional qualifiers (or additionally the amenity =refugee_site 
tag).

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

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Warin]

On 17/4/20 5:29 am, Manon Viou wrote:

Hello,
According to Martin and Warin, the difference between large and small 
refugee site is not clear enough,
Martin suggested to use population capacity, for instance less than 
200 people fro small refugee site,

Warin suggested to use number of square meters,
For what I have observed, small facilities sheltering refugee (for 
instance: refugee centers, accommodation center, care and hosting 
center, church) are not exactly what we can call refugee site. the 
difference, beyond the number of building, number of population or 
square meter, is quite obvious.



?? How is it 'obvious'???


I have no idea of what that 'obvious' thing is!




Is it really necessary to set a precise rule ?



At the moment there is nothing that can be used to distinguish between 
the two.


Suggestion have been made on the number of buildings, number of people 
and the area.



Please tell us how you distinguish between them.


I would rather suggest to share some example (like the ones mentioned 
above) in order to help contributors to decide if it rather an 
amenity=refugee_site or a social_facility=shelter.



Examples are fine. But there must be a statement in words of the 
difference between them.



Regards,
Manon

Le 16 avril 2020 à 02:16, Warin <61sundow...@gmail.com> a écrit :

On 16/4/20 1:23 am, Manon Viou wrote:
Thanks Martin, yes, refugee sites should always be temporary even 
if, as you said, some turn to be very long term places. That's why 
we do not suggest to add temporary/permanent options.

Manon



In which case the description for amenity=social_facility + 
social_facility=shelter is not correct.



If it is to be done on area then specify the number of square meters 
rather than the number of buildings???


Buildings can be a of different sizes and capacities. An area could 
be more consistent as to the number of people.


Imagery may not be up to date so counting buildings may not be possible.


Le 15 avril 2020 à 11:36, Martin Koppenhoefer < 
dieterdre...@gmail.com > a écrit :


sent from a phone

On 15. Apr 2020, at 01:13, Warin < 61sundow...@gmail.com 
> wrote:


I would think amenity=refugee_site is an area set aside for the 
non-temporary residential use of refugees


maybe I’m a dreamer, but I would expect all refugee related 
features to be “temporary”, even if we are talking about relatively 
long periods of time


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


CartONG- Humanitarian mapping and information management 



Manon Viou

*Coordinatrice projet Missing Maps*

Email: m_v...@cartong.org  | Skype: manon.viou



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

Re: [Tagging] Refining heritage tag

[Martin Koppenhoefer]

Am Fr., 17. Apr. 2020 um 04:27 Uhr schrieb António Madeira via Tagging <
tagging@openstreetmap.org>:

> After communicating with lutz from Historic.Place, he told me they didn't
> create this heritage scheme, they just adopted it.
> I took the opportunity to present him my proposal of refining this scheme
> and I got his support to go ahead with it, so I'm presenting it here in
> order to make the necessary adjustments with a new proposal.
>
> heritage=* - This is the main tag, which uses the admin_level [not
> changed].
>

currently 147558 instances




> heritage:operator=xxx - This is the tag for the official operator. I
> propose using separators [;] in those cases where an heritage has an
> international and a national operator.
>


currently 122076 instances, of which around 150 already have semicolon
separated multivalues. There are not many multivalues, but I would see it
as the already standard method (based on values of other tags), and believe
it would be ok to add this to the wiki without further voting.



> heritage:ref:xxx=* - This tag is for the code/number reference of the
> operator(s) above. It changes the previous ref:xxx=*
>


there are already some heritage:ref tags (and subtags like heritage:ref:vie)
name 12188 heritage:ref, and 500+ heritage:ref:xxx
It would be more complicated to count "ref:xxx" combined with heritage.
I am more reluctant to welcome this idea. What would be the benefit?
Generally, standard tags (like "ref" and derived tags like ref:mhd) would
seem the usual way, no? We do not add highway:ref=* tags for example,
because the tags refer to the object they are put on. Prefixing them with
"heritage" would only invite people to mix up objects of different nature
into the same OSM object.




>
> heritage:xxx:criteria=* - This tag is for the classification criteria used
> by the xxx operator. It changes the previous xxx:criteria=*
> heritage:xxx:inscription_date=* - This tag is used for the date the
> heritage was officially registered by xxx operator. It changes the previous
> xxx:inscription_date=*
>


same comment as above for ref.



>
> heritage:xxx:designation_title=* - This tag is used for the heritage title
> (international or national). This is new and is an attempt to circumvent
> the use of protection_title=* which is wrong in this context.
>


why is protection title "wrong"?




> heritage:xxx:website=* - Used for the heritage official website
> (international or national).
>


same comment as above for ref. I would even suggest to use a plain
"website" rather than an xxx:website, as long as there is only one operator
(very common situation).
Current use is 15772 heritage:website and 11258 website, plus 949
heritage:website:sipa (looks like an import), 713 contact:website, 225
heritage:website:arqueologia and 39 heritage:operator:website (IMHO to
deprecate, we're not a general web directory)

In general, let's use standard tags as long as there aren't good reasons
for creating specific derivative tags.

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