Re: [Tagging] Idea for a new tag: amenity=power_supply

2019-06-23 Thread Jan S


Am 23. Juni 2019 14:16:43 MESZ schrieb Paul Allen :
>Mapping a GPU would be like mapping a tractor on a farm.  It's not
>sensible
>because it moves.

Wouldn't it make sense then to tag it with the airport or airstrip and indicate 
the connector/voltage/etc for the entire facility?

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


Re: [Tagging] Idea for a new tag: amenity=power_supply

2019-06-21 Thread Jan S


Am 21. Juni 2019 16:29:02 MESZ schrieb Michael Brandtner via Tagging 
:
>The sub-tag does already exist, I've linked to it in my original post
>(power_supply=). What doesn't exist is a main tag for tagging isolated
>columns for power supply.
>This image shows what I'm talking about:
>https://www.alamy.de/outdoor-steckdosen-mit-sicherheitsschalter-auf-blau-metall-pol-fur-die-stromversorgung-von-kleinen-booten-im-hafen-umgeben-mit-konkreten-fliese-montiert-image233468696.html
>
Thanks, now I know what you mean.
>
>
>Am Freitag, 21. Juni 2019, 16:17:48 MESZ hat Philip Barnes
> Folgendes geschrieben:  
> 
> On Fri, 2019-06-21 at 15:49 +0200, Jan S wrote:
>> 
>> Am 21. Juni 2019 15:25:06 MESZ schrieb Philip Barnes <
>> p...@trigpoint.me.uk>:
>> > On Fri, 2019-06-21 at 16:07 +0300, Anton Klim wrote:
>> > > Guess it could be the same as fuel stations/hotels etc with extra
>> > > amenities: high-level tagging on the whole campsite pitch with a
>> > > sub
>> > > tag, or nodes on actual power sockets for more detail.
>> > 
>> > The position is useful information, you may need to know if your
>> > cable
>> > is long enough.

If these sockets are typically located at caravan parking spots in campgrounds, 
wouldn't it be sufficient to add a sub-tag to the proposed tag 
tourism=camp_pitch? Btw, voting for that tag is underway until 28 June here: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:tourism%3Dcamp_pitch

Best, Jan

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


Re: [Tagging] Idea for a new tag: amenity=power_supply

2019-06-21 Thread Jan S


Am 21. Juni 2019 15:25:06 MESZ schrieb Philip Barnes :
>On Fri, 2019-06-21 at 16:07 +0300, Anton Klim wrote:
>> Guess it could be the same as fuel stations/hotels etc with extra
>> amenities: high-level tagging on the whole campsite pitch with a sub
>> tag, or nodes on actual power sockets for more detail.
>
>The position is useful information, you may need to know if your cable
>is long enough.

Would such a tag fit for e-car charging stations, too, or can we already tag 
those? These charging stations basically provide electricity for money, too, 
don't they?

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


Re: [Tagging] refugee camp

2019-06-19 Thread Jan S
I think that we basically have to distinguish between two types of migrant
or refugee camps.

On the one hand there are established camps that have developed an urban
structure, with shops, services etc. People often live in these camps over
long periods of time (in case of the Palestinians even several
generations), but may still officially be refugees or migrants, because
they're not granted another permanent residence status under the laws of
the hosting state. In some situations, these places have become so
permanent, that they're in fact like municipalities, although they may not
be officially recognized as such. If these places have reached such a level
of development and don't receive new migrants or refugees (e.g. the
Palestinian refugee camps in Gaza or the West Bank), I wouldn't even tag
them as refugee camps, because on the ground they couldn't be distinguished
from any other town. This might apply to the camp in Thailand mentioned
blow, but also camps for Palestinian or Syrian refugees in Arab countries.
IMO, these camps should simply be tagged as place=*. According to the "on
the ground" rule, if they are similar to any other town in the respective
area, they should probably even not be tagged as refugee camps at all
(except in the name of the place).

On the other hand, there are more temporary camps, such as
https://en.wikipedia.org/wiki/Dadaab. These camps are much more makeshift
and continue to receive migrants or refugees. They are quite clearly
distinguishable from other towns in the area. Also, there are temporary
housing facilites for migrants and refugees in many countries, where asylum
seekers are sheltered during their asylum procedure, and they're relocated
to normal flats after some time. Due to the provisional structure or their
character as short-term housing, I'd suggest that these facilites be tagged
as refugee camps. Still, the tag "social_facility=shelter" doesn't seem to
be appropriate, as it is used fot shelters with even shorter occupation
(for people affected by natural disasters or homeless people for a night
etc.). I'd therefore propose to introduce a new tag,
"social_facility=refugee_camp", exclusively for this type of facility.

Best,
Jan




I did not add a refugee=yes tag. I tagged it as a place=town because my
> quick search for alternatives came up empty and there are about 50,000
> people living there. That way, at least the camp name shows up on maps and
> is searchable. I'll retag it based on what we decide here.
>
> On Tue, Jun 11, 2019 at 12:06 PM Violaine_Do  <https://lists.openstreetmap.org/listinfo/tagging>> wrote:
>
> >* Hi,
> *>>* Did you think about adding refugee=yes tag on place=* ?
> *>>* There were also an idea, if you have the boundary to develop rules
> *>* around boundary, similar to boundary = administrative to
> *>* boundary=refugee see
> *>>* 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Camp_Boundaries 
> <https://wiki.openstreetmap.org/wiki/Proposed_features/Refugee_Camp_Boundaries>
> *>>* I also think is is something to dig in and happy to help...
> *>>* Best,
> *>>* V
> *>>* On 11/06/2019 05:39, Jan S wrote:
> *>* >
> *>* > Am 10. Juni 2019 22:05:53 MESZ schrieb Dave Swarthout <
> *>* daveswarthout at gmail.com 
> <https://lists.openstreetmap.org/listinfo/tagging>>:
> *>* >> The refugee camps I'm familiar with in Thailand are not social
> *>* >> facilities
> *>* >> except in an incidental way. They are essentially internment camps
> *>* >> surrounded by fences with guarded gates where undocumented aliens are
> *>* >> kept.
> *>* >> They are landuse=residential because they're isolated areas in the
> *>* >> countryside and contain permanent dwellings but having no other way to
> *>* >> tag
> *>* >> it at the time, I tagged a big refugee camp near Mae Sot as place=town
> *>* >> and
> *>* >> name=Mae La Refugee Camp. As for the refugee aspect, I made a note and
> *>* >> left
> *>* >> it at that.*
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] refugee camp

2019-06-11 Thread Jan S


Am 10. Juni 2019 22:05:53 MESZ schrieb Dave Swarthout :
>The refugee camps I'm familiar with in Thailand are not social
>facilities
>except in an incidental way. They are essentially internment camps
>surrounded by fences with guarded gates where undocumented aliens are
>kept.
>They are landuse=residential because they're isolated areas in the
>countryside and contain permanent dwellings but having no other way to
>tag
>it at the time, I tagged a big refugee camp near Mae Sot as place=town
>and
>name=Mae La Refugee Camp. As for the refugee aspect, I made a note and
>left
>it at that.

I have my doubts whether place=town is the appropriate tag for a fenced living 
area, where people are obliged to live. Why wouldn't a big prison be place=town 
then, too (just have a look at https://en.m.wikipedia.org/wiki/Palmasola)?


>I'm not sure which approach would be better between social_facility,
>amenity or what have you, but any tourism-related tag definitely will
>not
>work.

My idea of a refugee camp is that there's some kind of social service, either 
public or private, like food distribution, medical attention, maybe housing or 
tents being provided by the government, UNHCR, or whomever. Would anything like 
that apply to the camps in Thailand you've described? If yes, I wouldn't have 
issues with using social_facility...

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


[Tagging] refugee camp

2019-06-10 Thread Jan S
>
> On 6/6/2019 5:27 PM, Graeme Fitzpatrick wrote:
> >>* I'd suggest something like social_facility=temporary_housing.
> *>>>* To me, social_facility doesn't quite cut it for "refugees". Refugees
> *>* strike me as people fleeing from war / massive natural disaster -
> *>* social_facility comes across as small scale for homeless people /
> *>* women's refuge sort of thing?
> *>>Browsing through the values of social_facility:for, it's a lot more
> diverse than just victims of abuse and poverty -- and
> social_facility:for=refugee(s) has hundreds of uses. But you definitely
> have a point about scale -- some of these camps house over a hundred
> thousand people. That's on the scale of a small city -- a community, not
> a facility. So maybe place=refugee_camp is a better solution.
>
> J
>
>
Picking up the subject again (and having noticed that the refugee camps I
know in my area are not tagged at all or at least very rudimentary simply
as amenity=social_facility), I've done another search on the internet and
have dug up this wiki page:
https://wiki.openstreetmap.org/wiki/Refugee_Camp_Mapping

It's been modified in 2018 for the last time, is quite rudimentary in the
description of the tags and values proposed and apparently oriented mainly
at makeshift camps in Africa or the Levante. It would be an effort to bring
some order into this and to make it more diverse (covering anything from
spontaneous camps like the infamous Jungle in Calais or the already
dismantled Idomeini camp, to permanent structures like asylum-seeker
reception centres like this: https://www.openstreetmap.org/way/390153052).

I'll see if I can give it a try over the next weeks... or would that be a
task for a coordinated action?

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


Re: [Tagging] refugee camp

2019-06-07 Thread Jan S


Am 6. Juni 2019 23:27:37 MESZ schrieb Graeme Fitzpatrick 
:
>On Fri, 7 Jun 2019 at 04:34, Jmapb  wrote:
>
>>
>> There are 40 instances of social_facility=refugee_camp, and 18 of
>> social_facility=refugee_housing.
>> For the primary tag you could go with social_facility=group_home or
>> social_facility=shelter, but they don't seem quite right.
>
>
>
>> I'd suggest something like social_facility=temporary_housing.
>>
>
>To me, social_facility doesn't quite cut it for "refugees". Refugees
>strike
>me as people fleeing from war / massive natural disaster -
>social_facility
>comes across as small scale for homeless people / women's refuge sort
>of
>thing?

Hi. IMO social_facility sounds appropriate. Refugee camps are basically housing 
for people in distress, just as is the case for homeless shelters or women's 
shelters. I don't think the reason why people are in distress or the number of 
people affected makes a difference. What's decisive is the vocation of the 
facility, which is to provide a service offered by society for people in need.

We should then make further differences as to the type of refugee shelter, e.g. 
social_facility=camp, social_facility:for=refugees (or migrants?) or 
social_facility=group_home, social_group:for=refugees/migrants in case of solid 
structures dedicated to recently arrived migrants.

Best, Jan

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


Re: [Tagging] Inland customs offices

2019-05-31 Thread Jan S


Am 31. Mai 2019 11:57:58 MESZ schrieb Warin <61sundow...@gmail.com>:

>Also found at airports .. and those can be some distance from the
>border.

Which are borders also? Hm...

Anyways, I'll just change the wiki. Just wanted to be sure beforehand.

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


Re: [Tagging] Inland customs offices

2019-05-31 Thread Jan S


Am 30. Mai 2019 22:40:56 MESZ schrieb Paul Allen :
>On Thu, 30 May 2019 at 21:19, Anton Klim  wrote:
>
>> There is another, older key, amenity=customs, which is actually used
>at
>> border crossings (from what I’ve seen) to denote customs control.
>> I am not sure why the amenity tag was deprecated (it also seems to be
>used
>> more often than the office tag). A customs office is not necessarily
>a
>> place where such control can be carried out and surely should be
>> distinguished?
>>
>
>Amenity:  n.
>
>   1. Pleasantness.
>   2. A thing or circumstance that is welcome and makes life a little
>   easier.
>   3.  Convenience.
>   4.  A unit pertaining to the infrastructure of a community.
>
>It you squint really hard, you can maybe see number 4 applying.  But
>the
>fact that amenity=*
>is usually applied in the context of number 2 or 3 makes a customs
>office a
>bad fit.

Indeed. I don't think amenity would fit for customs offices either. Police 
offices are already somewhat difficult to qualify as amenities, but you can put 
them under no 4. A customs office however doesn't serve the community in the 
same way, so it shouldn't be an amenity.

But independently from that, we agree that there's no reason to make a 
difference between customs offices at borders or at other places, as long as 
they control goods?

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


[Tagging] Inland customs offices

2019-05-30 Thread Jan S
Hey everyone,

I've just noticed that the wiki at
https://wiki.openstreetmap.org/wiki/Tag:government%3Dcustoms defines a
customs building as "A structure near or at an international boundary where
travelers and vehicles crossing the border are inspected."

Customs controls however take place inland, also, e.g. at river ports or in
bigger commercial areas. There, lorries or containes pass customs control
and are then sealed by the customs officials and may thus pass a border
without further inspection of the content.

I propose that inland customs facilities be tagged as government=customs,
too, and the wiki be modified accordingly.

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


Re: [Tagging] Navaid relation?

2019-05-22 Thread Jan S


Am 22. Mai 2019 00:44:51 MESZ schrieb Mateusz Konieczny 
:
>
>22 May 2019, 00:38 by marc_marc_...@hotmail.com:
>
>> Le 22.05.19 à 00:16, Florian Lohoff a écrit :
>>
>>>
>>> Hi marc,
>>>
>>> On Tue, May 21, 2019 at 10:02:53PM +, marc marc wrote:
>>>
 Hello,

 Le 21.05.19 à 23:46, Florian Lohoff a écrit :

> Currently all Routing/Navigation application try hard to find
> the nearest or best point on the routeable network for a given
> destination lat/lon or object.
>

 with best, you mean : only one ? that look like wrong
 a destination can have several points depending on the type
 of locomotion.
 the same type of locomotion can have several points, e.g. several
>ways
 that desert a station by foot, several other for car, ...

>>>
>>> What is the expectation to get navigated to when selecting a park?
>>>
>>
>> there is no such thing as "a single point that makes everyone agree"
>> take the case of a square park fenced by a fence, surrounded by 4 
>> streets each with a pedestrian entrance to the park.
>> those arriving from the north will probably want to stop at the
>street 
>> to the north, while those arriving from the south will probably want
>to 
>> stop at the street at the south entrance.
>> Those who have difficulty walking will probably prefer the car park 
>> closest to an entrance, while others will prefer parking for people
>with 
>> reduced mobility or free parking, all while they have all come by
>car.
>> on the basis of which objective criteria will you decide which point
>of 
>> the public network is most suitable to reach the park?
>>
>Also, some people may drive (bicycle), other may arrive by a public
>transport
>others may walk or drive (by car) etc.
>
>See for example https://www.openstreetmap.org/#map=17/50.06288/19.91742
>
>- a park that has multiple entrances, each may be preferred in some
>situation.

I am also against mapping for navigation purposes. The data shall reflect the 
truth on the ground, all else is up to the programme making use of that data.

In case of a park with multiple entrances (which would obviously have to be 
recognisable by other programmes), it's up to the routing software to route you 
either to the entrance closest to you, the one that's best to be reached given 
the means of transport chosen or maybe offer you a choice of entrances to 
select from.

The same goes for big complexes like airports. Take Madrid Barajas or London 
Heathrow with terminal buildings at different locations, plus a cargo area and 
maybe a general aviation area. Here, you obviously have to chose a specific 
point you want to be routed to, and then the routing software should take you 
to an entry point of that specific place.

I imagine that like on a taxi. If you say "Take me to Heathrow", the driver 
will inevitably ask "Which terminal?". If you say "Take me to Central Park", 
the driver will, again, ask you for a more specific location or make a decision 
for you (the nearest/furthest entry, depending on his/her honesty ;)). These 
very decisions should be made, or these very questions asked by a routing 
programme.

Best, Jan

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


Re: [Tagging] Aerodrome classification

2019-05-20 Thread Jan S


Am 20. Mai 2019 16:30:30 MESZ schrieb Joseph Eisenberg 
:
>
>It seem to me that the presence of public passenger flights is the
>basic idea of the word "airport" to the general public (pilots certain
>have different ideas, but they have their own specialized databases),
>and it would be good if we could tag this in a consistent way.
>
>For use by pilots, and for people considering charter flights, it may
>be useful to make a distinction between "general aviation" airports
>that have services like hangars, fuel, staff etc, versus an airstrip
>in a farmer's field which lacks any services or facilities other than
>an unpaved runway.

I assume that OSM will not be used for aviatory navigation purposes out of 
security reasons ( at least I hope the pilots flying me around do so following 
aviation-specific maps...) . Rather, it's aim is to serve people on the ground. 
So we shouldn't primarily look at the requirements of pilots but of ordinary 
users. So I agree with Joseph that the relevant differentiation happens between 
airfields with only general aviation and airports with commercial services. 
This line should be clearly drawn in mapping. Also, this enables renderers to 
only show commercial airports on larger scales and not any airstrip in the same 
way as big international airports.

Facilities at airports that may be relevant to pilots should then be tagged 
apart from the classification of the airport.

Best, Jan

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


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

2019-05-20 Thread Jan S
Hi,

I find camp_site:part=* somewhat complicated, too. Also, it wouldn't be 
consistent with the use of camp_site=* to describe the type of camping site, 
either.

I'd prefer tourism=camp_pitch. This also has the advantage that this key can be 
used for isolated camping pitches that are not part of a proper camping ground.

Best, Jan

Am 20. Mai 2019 11:39:17 MESZ schrieb Joseph Eisenberg 
:
>It appears that the proposal for camp_site=camp_pitch will be rejected
>with 12 votes in opposition out of 26 votes total, for
>
>A couple of those who voted in opposition would prefer to use
>"tourism=camp_pitch" instead. There were also a couple of people who
>suggested "tourism=camp_site:part" and a couple in favor of
>"camp_site:part=camp_pitch". Several other people voted in opposition
>but did not specify a preferred alternative.
>
>So what's that best tag to try instead?
>
>I think "camp_site:part=*" is rather convoluted, and
>"tourism=camp_pitch" has the benefit of using a well-known key, but
>perhaps there are other suggestions?
>
>On 5/8/19, Joseph Eisenberg  wrote:
>> Reminder: voting is underway to approve the tag  camp_site=camp_pitch
>> since May 1st so it  will continue for the next week till May 14th
>> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
>>
>> Please check out the proposal page and add your comments or votes:
>>
>https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch#Voting
>>
>> On 5/1/19, Joseph Eisenberg  wrote:
>>> I believe the discussion about the tag camp_site=camp_pitch is now
>>> complete here. Also see the talk page:
>>>
>https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/camp_site_pitch
>>>
>>> You can now vote to approve or reject this tag. See:
>>>
>https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
>>>
>>> Description of camp_site=camp_pitch:
>>> "An tent or caravan pitch location within a camp site"
>>>
>>> This proposal provides a way to tag individual pitches within a
>>> campground or caravan site. A "camp pitch" in this context is the
>free
>>> space used to place a tent or or caravan within a tourism=camp_site
>or
>>> tourism=caravan_site area. Usually only one caravan is permitted in
>an
>>> individual pitch, but more than 1 tent may be allowed on a single
>>> pitch in some cases."
>>>
>>> Please read the proposal and vote:
>>>
>https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch#Voting
>>>
>>
>
>___
>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] Wiki changes for police tag

2019-05-19 Thread Jan S


Am 19. Mai 2019 06:10:21 MESZ schrieb Graeme Fitzpatrick 
:

>Would the police then work under building=government (which was
>discussed a
>while back) + police=xxx?

I'd think so, as long as the police (or other government offices) occupy the 
entire building. Otherwise it would just be a node on the building.

Could anyone take that into the wiki? I won't find the time soon...

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


Re: [Tagging] Feature Proposal - RFC - changing table

2019-05-18 Thread Jan S
Hi Valor,

Thanks for reducing your proposal. I could go with it. Still, it's up to the 
programming guys to say whether the changing of the name of the key from diaper 
to changing_table is somehow problematic.

Best, Jan

Am 18. Mai 2019 11:28:31 MESZ schrieb Valor Naram :
>Hey guys,
>
>my first proposal regarding changing tables were rejected because of
>being "too complex". I will give it a second chance and provide you
>with the v2.0 of it: https://wiki.openstreetmap.org/wiki/Proposed_featu
>res/changing_table
>
>Author: Valor Naram
>Definition: A tag to mark the possibility to change the baby's nappy.
>It makes tagging of changing tables possible. See https://en.oxforddict
>ionaries.com/definition/changing_table for the definition.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Wiki changes for police tag

2019-05-18 Thread Jan S
Interesting point... I'd suggest that it is a top-level tag itself. Otherwise 
you'd have to tag buildings as building=* and police=*, which I find an 
unnecessary duplication that might even result in contradictory tags.

Best, Jan

Am 18. Mai 2019 10:36:32 MESZ schrieb Simon Poole :
>Seems as if the proposal and now the definite wiki page is missing one,
>not quite unimportant, bit of information:
>
>is police an attribute to be used on other "top-level" (say for example
>building=xx OSM objects or does it define a stand alone "top-level"
>object itself?
>
>Simon
>
>Am 17.05.2019 um 23:03 schrieb Jan S:
>> Hi everyone,
>>
>> I've created the pages https://wiki.openstreetmap.org/wiki/Key:police
>> and subpages for values police=barracks, police=car_pound,
>> police=car_repair, police=checkpoint, police=detention,
>> police=naval_base, police=offices, police=range, police=storage and
>> police=training area, as well as the generic police=yes.
>>
>> All this in accordance with the approved proposal for key:police.
>>
>> Best, Jan
>>
>> ___
>> 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] Wiki changes for police tag

2019-05-18 Thread Jan S
Hi Graeme,

I've just seen that. I've used the taglist template, but apparently it
doesen't work as intended. I'll make a manual list.

Best,
Jan

Am Sa., 18. Mai 2019 um 01:06 Uhr schrieb Graeme Fitzpatrick <
graemefi...@gmail.com>:

>
>
> On Sat, 18 May 2019 at 07:05, Jan S  wrote:
>
>>
>> I've created the pages https://wiki.openstreetmap.org/wiki/Key:police
>> and subpages for values police=barracks, police=car_pound,
>> police=car_repair, police=checkpoint, police=detention, police=naval_base,
>> police=offices, police=range, police=storage and police=training area, as
>> well as the generic police=yes.
>>
>
> Hi Jan
>
> Some of the sub-tags aren't shown, so not sure if you've created pages for
> them yet?
>
> =detention, =naval_base & =range are currently missing.
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Wiki changes for police tag

2019-05-17 Thread Jan S
Hi everyone,

I've created the pages https://wiki.openstreetmap.org/wiki/Key:police and
subpages for values police=barracks, police=car_pound, police=car_repair,
police=checkpoint, police=detention, police=naval_base, police=offices,
police=range, police=storage and police=training area, as well as the
generic police=yes.

All this in accordance with the approved proposal for key:police.

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


[Tagging] Voting results - tag:police

2019-05-14 Thread Jan S
Hi everyone,

The police=* proposal has been unanimously approved by 30 votes. Thanks for 
your massive support!

I hope that I'll have the time to change the wiki over the next days.

All the best,
Jan___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Looking for Existing Proposal/Feature - Firearm Restrictions

2019-05-10 Thread Jan S
Hi Jane,

Welcome! I'm currently visiting Texas, so I know that firearm restrictions are 
a fact that may be worthwhile to register in OSM. I suggest you write up a 
proposal following the guidelines in the wiki and taking other proposals as 
examples and put it up for comments here. If you feel that there's sufficient 
support for your proposal, you can pass it on to voting.

Good luck!

Best, Jan

Am 9. Mai 2019 21:44:02 GMT-05:00 schrieb Jane Smith 
:
>Good Evening,
>
>I am considering submitting a proposal for restrictions or allowances
>on
>carrying firearms in a particular location. I checked through the
>proposal
>pages and the active features pages and did not see anything related to
>this. The Proposal Process page suggested emailing this list to ensure
>nothing similar is already in use.
>
>Examples of these restrictions in my area would be signs on buildings
>prohibiting carrying firearms concealed and/or openly. The signs
>themselves
>would be nodes, but the allowance or restriction would apply to ways.
>
>Thank you.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - tag:Police

2019-05-08 Thread Jan S
Well, I share the impression that the tag will be accepted this time. I'll let 
the voting open during the usual 14 days period however. You never know if 
someone will have another opinion on this.

Best, Jan

Am 5. Mai 2019 22:49:57 GMT-05:00 schrieb Mateusz Konieczny 
:
>Just wait for the end of voting schedule.
>
>
>5 May 2019, 20:53 by bkil.hu...@gmail.com:
>
>> We're now at 20 unanimous approval votes. Do we still need more?
>>
>> On Sun, Apr 28, 2019 at 11:51 PM Graeme Fitzpatrick <>
>graemefi...@gmail.com <mailto:graemefi...@gmail.com>> > wrote:
>>
>>>
>>>
>>> On Mon, 29 Apr 2019 at 04:18, Jan S <>> grimpeu...@gmail.com
><mailto:grimpeu...@gmail.com>>> > wrote:
>>>
>>>>
>>>> So, I'm looking forward to your votes
>>>>
>>>
>>> Done! Good luck :-)
>>>
>>> Thanks
>>>
>>> Graeme
>>> ___
>>>  Tagging mailing list
>>>  >> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>>  >> https://lists.openstreetmap.org/listinfo/tagging
><https://lists.openstreetmap.org/listinfo/tagging>
>>>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature Proposal - Voting - tag:Police

2019-04-28 Thread Jan S




Hi everyone,

since the police facilities proposal had already been widely discussed, I 
hadn't expected much further comment on the stripped-down version consisting 
only of the police tag. That's why I'm already putting it to vote again.

So, I'm looking forward to your votes and expect heavy participation :)

Please vote here: 
https://wiki.openstreetmap.org/wiki/Proposed_features/tag:Police

Best, Jan

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


[Tagging] Feature Proposal - RFC - tag:police

2019-04-23 Thread Jan S
Hey,

As the proposed tagging scheme for police facilities appeared to be too
complex to find approval by a majority of voters, I've stripped it down to
just defining a police tag.

I've set it up as a new proposal at
https://wiki.openstreetmap.org/wiki/Proposed_features/tag:Police.


I'm again looking forward to your comments.

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


Re: [Tagging] Why should we avoid overusage of amenity=* tag?

2019-04-22 Thread Jan S
Am Mo., 22. Apr. 2019 um 01:48 Uhr schrieb Paul Allen :

>
> It certainly makes overpass turbo queries a lot simpler and more intuitive
> if we can group all
> education facilities under education rather than under amenity.  Typing
> "education=*" is shorter
> than "amenity=school or amenity=university".  And won't trip you up if you
> forget that you also
> needed to query for amenity=college, etc.  We did it for healthcare, we
> can do it for education.
>
> In the short-term it means even more complex queries to find educational
> establishments because
> both sets of tags will be in use.  However, if we have a 1:1
> correspondence (amenity=school ->
> education=school) then a bulk edit is technically possible and maybe even
> politically possible.
>
> Otherwise let's get rid of amenity=* by tagging EVERYTHING as thing=*.
> It's the logical next step
> after using amenity any time we can't think of a better tag.
>
> I am in favour of using specific tags to group sets of things that belong
together, instead of using general tags like "amenity". But it's difficult
to teach an old dog new tricks. "Amenity" has been adopted so widely that
whenever a specific set of tags would be introduced, the question arises of
how to treat those things that have already been tagged as "amenity=*".
E.g. in the case of educational institutions, it would either be necessary
to maintain amenity=school or amenity=university, or double-tag these
institutions for the sake of backward compatibility as amenity=school and
education=school, or to automatic retagging of all amenity=school as
education=school (DANGER!!!).

These difficulties, and opposing ideas on how to deal with existing tags,
make it hard to change established tagging schemes. But I am strongly in
favour of not establishing new amenity=* for hitherto unmapped facilites,
but rather use new tags altogether, whose use can then be expanded into
proper tagging schemes.

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


[Tagging] Feature Proposal - Voting results - Police facilites

2019-04-22 Thread Jan S
The voting period for the refined police facilities proposal (
https://wiki.openstreetmap.org/wiki/Proposed_Features/Police_facilites) has
ended. The proposal has been rejected by 8 approvals against 3 rejections
(72.7% approval).

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


Re: [Tagging] Feature Proposal - Voting - Police Facilities

2019-04-08 Thread Jan S
Hi Graeme,

Thanks for asking. I've left an answer in the wiki, which I likewise repeat 
here.

"I think it would be convenient to leave this to be determined by people with 
local knowledge. It should depend on what is the more common denomination. In 
Germany, some abbreviations are the commonly used denominations, while other 
facilities or units are commonly known by their full name and the abbreviation 
is of a more technical use."

Best, Jan

Am 8. April 2019 00:36:25 MESZ schrieb Graeme Fitzpatrick 
:
>Thanks Jan
>
>Just posed a question which I'll repeat here so nobody misses out!
>
>Question re operator & police:unit "names".
>
>Under :operator you have the example of NYPD, then under :unit you
>mention
>CRS & SWAT. Should they be abbreviated (which is how everybody knows
>them!), or spelt out full - New York Police Department, Compagnie
>Républicaine de Sécurité (which you have under CRS barracks), Special
>Weapons & Tactics etc
>
>Thanks
>
>Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature Proposal - Voting - Police Facilities

2019-04-07 Thread Jan S
Hi everyone,

I've adapted the police facilities proposal according to the votes and comments 
I've received during the first voting. In particular I've done away with the 
landuse=police tag and the plan to deprecate amenity=police in the future.

Give it another look, please, and vote: 
https://wiki.openstreetmap.org/wiki/Proposed_Features/Police_facilites

Thanks!

Best, Jan___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-30 Thread Jan S
Am Sa., 30. März 2019 um 19:05 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> if you want to make changes to the proposal you can still do it, from my
> understanding, this would stop the current voting, and there would be a new
> voting on the modified proposal.
>
> The new voting period would again have to be min. 2 weeks, voting isn’t so
> much about democracy anyway (it is hardly representative and it is not
> binding), it is for discovering potential problems, and testing the
> acceptability. In the end what really counts is whether the tags are
> actually applied, and whether the tagged objects correspond to the
> definition.
>
> I believe the french scheme is a good idea, because it removes the
> ambiguity for people who know the local system (it is what seems most
> helpful to local data users), but it should be accompanied by an
> international classification.
>
>
Thanks! I have stopped the voting and modified the proposal taking into
account the major arguments brought forward against the first version.
Please feel free to revise the new version and comment on it!

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-30 Thread Jan S
Hey guys,

the voting has had people give more specific comments on the proposal. In
has become clear in particular that landuse=police is mostly seen as
superfluous, while hitherto there were people speaking out against as well
as in favour of this tag.

I've now also understood the idea of the police:XX tag for localised
information that has been established in France and would include such a
scheme.

Now, how to proceed? I don't think that adapting the proposal while the
voting is open would be considered democratic. Should I thus interrupt the
voting and adapt the proposal? Or wait until the voting is over, adapt, and
open another voting period?

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


[Tagging] Feature Proposal - Voting - Police Facilities

2019-03-24 Thread Jan S
Hey guys,

There are no more open discussions around the police facilities proposal. I've 
hence decided to open it for voting. I'm looking forward to your opinions.

Vote here: 
https://wiki.openstreetmap.org/wiki/Proposed_Features/Police_facilites

Best, Jan___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-17 Thread Jan S


Am 17. März 2019 22:38:30 MEZ schrieb marc marc :
>Le 17.03.19 à 11:23, Jan S a écrit :
>> it wasn't obvious which were police stations and which were other
>facilities. In the end, I used Google maps... So there is practical
>relevance.
>
>i'm in favor of police=* (execpt the double tag for the station)
>but it's not a food relevance to promote a new schema because some
>objet 
>are wrongly mapped.
>so ifsomeone make a mistake with police=*, did we new a 3nd schema ?
>or just fix the mistake in osm ?

The issue here was that there is no real way to tag police facilities other 
than stations. There's office=government and government=police, but that 
doesn't fit in many cases either. So we have mistagging due to a lack of 
alternatives and no good way of repairing the bad tags. That's why in this 
particular case a new scheme is the appropriate way.

Best, Jan

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-17 Thread Jan S


Am 17. März 2019 21:47:03 MEZ schrieb Graeme Fitzpatrick 
:
>There are some extensive Police areas, rather than just buildings - as
>mentioned, the Academy, driver training area, Mounted Police stable,
>which
>would usually include paddocks & so on.
>

I think this is similar to universities. There, buildings and the campus are 
tagged as amenity=university. Even big police facilities won't be as big as 
some unis. So I don't see an issue in tagging the area of a facility as 
police=*. The military, on the contrary, has huge areas under their exclusive 
control. So there, a landuse=military tag makes sense.

>They would all be tagged as police=facilities, but how would they
>render,
>as they wouldn't / shouldn't have the Police icon on them?

In general I think, someone who's a better designer than me would have to come 
up with a specific icon or icons for police facilities that are not police 
stations.

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-17 Thread Jan S


Okay, I think the police scheme is consolidating.

I had included a new landuse=police tag, inspired in landuse=military. I'm not 
sure whether we really need that. I came to think that the police doesn't use 
land in the same way the military does for training grounds, huge shooting 
ranges, bomb dropping areas or even nuclear test sites. So as of now I tend to 
eliminate it from the proposal.

This would likely be the last question I'd raise. We could then soon go to a 
vote :)

Best, Jan

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-17 Thread Jan S


Am 16. März 2019 20:09:05 MEZ schrieb Mateusz Konieczny 
:
>Some police facilities will remain mistagged, no matter tagging scheme.
>
>Have you already fixed such objects or opened OSM notes mentioning
>mistaggings?

No. I wouldn't have known which other tags could've been applied. That's why I 
decided to make the proposal and define tags first.

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-17 Thread Jan S


Am 16. März 2019 23:18:38 MEZ schrieb Joseph Eisenberg 
:
>The key “police” is not currently on the list of features that import
>as a
>polygon in osm2pgsql, when mapped as a closed way.
>
>So renderers and other database users that rely on osm2pgsql will need
>to
>add the “police” key to the lua transformations list and reimport the
>database.
>
>This is easy for cartographers that make insividual maps, but it’s a
>major
>undertaking for the main OSM servers, which is only done every couple
>of
>years. So it will take some time before any objects tagged
>“police=station”
>without an “amenity” tag could be rendered on the Standard map layer on
>OSM.
>
>This shouldn’t be a problem for things like warehouses, non-public
>offices,
>vehicle impound facilities etc. But it requires patience for police
>stations.

Good point. I hope this transition period can be provided by double tagging 
police stations for a while at least.

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-17 Thread Jan S


Am 17. März 2019 00:56:42 MEZ schrieb Warin <61sundow...@gmail.com>:
>On 17/03/19 03:15, Martin Koppenhoefer wrote:
>>
>>
>>
>>
>> sent from a phone
>> On 16. Mar 2019, at 15:53, Jan S > <mailto:grimpeu...@gmail.com>> wrote:
>>
>>> So you basically can't rely on OSM to find a police station in case 
>>> of an emergency.
>>
>>
>> let us not overemphasize the emergency in this context. In an urgent 
>> emergency you would expect the police to come to you rather than the 
>> opposite.
>
>If you are being assaulted, it is better to run towards the police 
>rather than away.

The other day I was abroad and a window of my car was broken and a bag stolen. 
I needed to go to a police station and ran into the issue that there were 
several amenity=police facilities around and it wasn't obvious which were 
police stations and which were other facilities. In the end, I used Google 
maps... So there is practical relevance.

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-16 Thread Jan S
Am Sa., 16. März 2019 um 15:09 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

> > On 16. Mar 2019, at 13:11, Jan S  wrote:
> >
> > All other police facilites, that may currently have been tagged
> erroneously as amenity=police would be tagged only as police=*,
>
>
> The „problem“ with this approach is that maps who base the presence of
> objects in their renderings on the presence of specific keys will likely
> not happen to find these police=* things in their database. Depending on
> how relevant the objects are for the specific map, this may be desirable or
> not. Just as a point of consideration. Of course in theory who defines the
> filtering rules for the keys might add „police“, but in practice it takes a
> lot of time to establish a new key as standard.
>
> Sure, but currently amenity=police is used indiscriminately on many
police-related objects, no matter whether they are important or providing
background services. There are several instances of police barracks or
warehouses mapped as amenity=police, although they clearly don't provide
service to the public. So you basically can't rely on OSM to find a police
station in case of an emergency. I think that's worse than maybe losing
some other police facilities from certain maps.

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-16 Thread Jan S
Am Fr., 15. März 2019 um 17:48 Uhr schrieb marc marc <
marc_marc_...@hotmail.com>:

> Le 15.03.19 à 17:16, Jan S a écrit :
> > I sense dissent here about the future use of amenity=police. Would it be
> a possible solution to keep amenity=police for public-facing police
> stations only,
>
> that's the current meaning.
>
> > but invite mappers on the wiki to nevertheless add police=station, so
> that in the future the majority of police stations will hopefully also
> carry the police=station tag?
>
> at the risk of repeating myself, some mappers disapprove of having to
> enter the same information twice because of the coexistence of 2 tags
> with the same meaning.
> you can of course try your luck by submitting this idea grouped with the
> rest of your proposal... or you can separate this conflicting idea to
> increase the chances of adoption of the main part of your propal,
> it's up to you (I'll separate).
>
> anyway, even if it passes, it is unfortunately inevitable that the 2
> tags get out of sync and then the meaning gets worse than before:
> if a mapper deletes the only-one tag from a police station,
> his intention is clear, it's not more a police station.
> if a mapper deletes only one of the 2 tags from a police station, has he
> done so because the police station is closed (and the other must also be
> deleted) or because he wants to delete one of the 2 duplicated schemes?
>
> this "dual-schema" period is really painful, which is why I find it
> preferable that it be as short as possible.
> in this perspective, I am in favor of first promoting all police=* who
> currently do not have a tag and once this scheme is well known/used,
> do another operation to try to switch amenity=police to police=station
> (and, I repeat, do not underestimate the enormous resistance of some
> community members who think (imho wrongly) that frequent tags should be
> kept immutable for eternity.)
>

I have prepared the proposal for a transition period that hopefully won't
break current mapping and rendering by maintaining amenity=police for
public-facing police stations, but inviting mappers to tag these stations
also as police=station.

All other police facilites, that may currently have been tagged erroneously
as amenity=police would be tagged only as police=*, while public-facing
police stations shall be double-tagged as amenity=police and
police=station. It can then be decided in the future whether amenity=police
will prevail or whether public-facing police stations will be exclusively
tagged as police=station, in order to be consistent with other police
facilites.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-15 Thread Jan S


Am 15. März 2019 09:17:31 MEZ schrieb Mateusz Konieczny 
:
>Mar 15, 2019, 7:37 AM by grimpeu...@gmail.com:
>
>>
>>
>> Am 15. März 2019 00:19:22 MEZ schrieb althio <>
>althio.fo...@gmail.com > >:
>> >Martin Koppenhoefer <> dieterdre...@gmail.com
>> > wrote:
>>
>>>My primary interest is in specifying the kind of
>>>police and facility, a generic amenity=police on top of that does not
>>>harm. If the new scheme becomes so widespread that every police station
>>>also has a more specific police=* tag, we can still decide to remove
>>>the amenity=police tags.
>>
>> That sounds reasonable. So we'd keep amenity=police as the general
>indicator of police facilities
>>
>Public-facing police facilities. For example police warehouse should
>not be tagged with it
>(and even if some are tagged this way I think that everybody would
>consider it as a tagging
>mistake).

I sense dissent here about the future use of amenity=police. Would it be a 
possible solution to keep amenity=police for public-facing police stations 
only, but invite mappers on the wiki to nevertheless add police=station, so 
that in the future the majority of police stations will hopefully also carry 
the police=station tag?

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-15 Thread Jan S


Am 15. März 2019 07:55:31 MEZ schrieb Joseph Eisenberg 
:
>Please don’t change the established meaning of amenity=police; it
>should
>keep meaning “a public police station”.
>
>Most database users are only going to be interested in public police
>stations, that’s why we’ve gotten by for over 10 years with just
>amenity=police.

But amenity=police is currently used indiscriminately for *all* police 
stations, public-facing or not. That's what makes the current mapping 
inconsistent and impractical. To make it usable and consistent again, we'd at 
least have to either replace amenity=police by police=* in all 
non-public-facing police facilities or add police=* to the tagging of these 
facilities.

And, I don't think that tagging police stations as amenity=police and 
police=station would be too demanding for the average mapper. You just have to 
get used to it.

I simply find it undesirable to use different keys for things that are so 
closely connected in reality as is the case of police facilities.

Best, Jan

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-15 Thread Jan S


Am 15. März 2019 00:19:22 MEZ schrieb althio :
>Martin Koppenhoefer  wrote:
>> > If this seems viable, I would expand the proposal by a migration
>proposal from amenity=police to police=station
>>
>> I don’t think we should abandon amenity=police and it will likely not
>happen unless people tag so many different things with the tag that it
>becomes useless. My primary interest is in specifying the kind of
>police and facility, a generic amenity=police on top of that does not
>harm. If the new scheme becomes so widespread that every police station
>also has a more specific police=* tag, we can still decide to remove
>the amenity=police tags.

That sounds reasonable. So we'd keep amenity=police as the general indicator of 
police facilities and use police=* as a sub-tag to specify the type of 
facility. The current wiki page for amenity=police would consequently move to 
police=station and amenity=police would be reduced to indicate that the tag is 
used for all police facilities (and maybe hold a list of what's considered 
police by country).

I'll adapt the proposal.

>There is no need to abandon amenity=police for public facing police
>stations.

That, on the contrary, doesn't seem consequent to me. We'd end up with 
amenity=police and police=* as main tags for different types of police 
facilities. I fear that that would be confusing and cause inconsistent mapping.

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-14 Thread Jan S


Am 14. März 2019 19:43:52 MEZ schrieb Markus :
>On Sat, 9 Mar 2019 at 23:11, Jan S  wrote:
>>
>> I'll collect more opinions on the abolition of amenity=police.
>
>Note that every software that uses OSM data would need to be updated
>before amenity=police can be removed. Therefore it is is unlikely that
>amenity=police would disappear soon. Instead, people would have to
>double-tag police stations as amenity=police + police=station in order
>to comply with both the old and the new scheme. This is why i'm unsure
>whether it's sensible to introduce a new tag for police stations.

I know. That's why I had asked earlier whether it would be better to establish 
a completely new police-tag for all police facilities (probably with 
double-tagging of police stations during a period of adaptation) or to maintain 
amenity=police for police stations and establish the police-tag only for all 
other facilities.

I'm still in favour of the first option. It requires retagging, but we'd end up 
with a neat and consistent tagging scheme. And software could map 
amenity=police and police=station as the same. amenity=police would thus slowly 
be phased out and not have to be eliminated completely in one stroke.

If this seems viable, I would expand the proposal by a migration proposal from 
amenity=police to police=station.

Best, Jan

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-14 Thread Jan S
There have been no further comments on the proposal for several days now, 
neither were there comments on the proposal page. Would it be an issue if I 
started the voting this weekend although the proposal is less than two weeks 
old?

Best, Jan

Am 11. März 2019 17:32:13 MEZ schrieb Martin Koppenhoefer 
:
>
>
>sent from a phone
>
>> On 10. Mar 2019, at 19:07, Andy Townsend  wrote:
>> 
>> That difference might confuse  - that's an American rather than a UK
>difference, I think.  Where "jail" (or even "gaol") is used in the UK
>it's essentially a synonym for prison. 
>
>
>in Germany, the cells in a police facility would not be called a
>prison, AFAIK there are only “drunk tanks” (Ausnüchterungszelle /
>sobering cell) and people would otherwise (pre-trial detention) go to a
>real prison (government facility / de: JVA). There are also other
>places where people are forcibly confined which aren’t “prisons”, e.g.
>psychiatric hospitals and nursing homes. 
>
>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] [OSM-talk] Tagging disputed boundaries

2019-03-14 Thread Jan S


Am 14. März 2019 01:02:56 MEZ schrieb Sergio Manzi :
>On 2019-03-14 00:26, Graeme Fitzpatrick wrote:
>>
>> On Thu, 14 Mar 2019 at 08:06, Sergio Manzi > wrote:
>>
>>
>> I was advicing somebody something completely different as of
>lately: to form a hidden, underground, group of motivated persons to
>draft proposals that are already agreed upon by at least "some" before
>going public with the proposal...
>>
>> Your opinion?
>>
>>
>> Did see that, & thought Hmmm?
>>
>> The problem I can see, & yes, of course there'll be ways around it,
>is how do you pick their conspirators collaborators team?
>>
>> Do you stick up a post saying I'm thinking about a new way of mapping
>disputed boundaries, anybody interested please contact me privately, or
>do you send private messages to me, Joseph, Kevin, Dave etc etc to say
>the same thing?

That somehow sounds like the working group I had brought up earlier. I think 
its a good way to proceed on fundamental and complex issues.

It wouldn't have to be secret group though. A call for participants and then a 
list of participants could be published on the proposal page. Also, and in 
general, proposals should, IMO, be linked on the wiki pages that are concerned, 
so as to raise more attention and more participation in the voting process.

Maybe it would be viable to initially propose that a complex situation is to be 
resolved and that a working group shall be established to that end. Thus, 
people don't have to vote complex proposals but rather only determine that an 
issue is complex and that a working group shall be conformed to resolve it.

The (working/secret ;)) group would then develop a solution that would have to 
be approved by simple majority of the votes cast (with working group members 
excluded from voting). A qualified majority as in individual proposals doesn't 
seem to be necessary to be, because a working-group proposal is more reliable 
than individual proposals and thus doesn't require the same level of approval 
by the community.

This procedure is more complex than that for individual proposals. It also 
presupposes a degree of confidence in the work of the group. But it might be a 
way to get better results for complicated problems.

Best, Jan

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


Re: [Tagging] [OSM-talk] Tagging disputed boundaries

2019-03-13 Thread Jan S


Am 13. März 2019 00:33:02 MEZ schrieb Graeme Fitzpatrick 
:

>I have no idea how we could improve things so there is more feedback -
>maybe remove the discussion page from the proposals, so all discussion
>has
>to happen on the tagging list?

Or promote proposals better, may by consistently (or even automatically) 
linking them on the wiki pages of the affected tags?

Best, Jan

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


Re: [Tagging] [OSM-talk] Tagging disputed boundaries

2019-03-12 Thread Jan S
Am Di., 12. März 2019 um 19:22 Uhr schrieb Johnparis :

> Thanks. I never did post the final vote, which was 17 yes, 14 no, and 2
> abstain. (There was an additional yes vote after the time period elapsed,
> which has no effect on the outcome.)
>
> The proposal was therefore defeated, not having achieved anywhere near 74%
> approval. I suspect that it is not possible to get anything higher that
> what the proposal achieved (about 55%). I have not gone through the
> comments to see if further changes and another vote would make a difference.
>
> What surprised me, however, was the general lack of interest. I had
> thought this was a hot button issue, what with dozens of people registering
> with OSM, the big kerfuffle about Crimea, etc. If only 33 people are
> interested in this topic, it seems useless for me to continue to try to
> refine the proposal.
>
> Having comments during the voting seems useful, but I was taken aback by
> the fact that issues were raised during the voting that were not raised
> during the Request For Comments period. That strikes me as odd, since it
> raises issues that cannot be discussed during the voting. I refer, for
> example, to the idea of the "on the ground" principle.
>
> The proposal was written specifically to SUPPORT the "on the ground"
> principle, which I felt was undermined by the vote of the OSM Foundation
> board.
>
> The problem with the current system is that it conflates two things: the
> border claim by a country and the line of control for a country.
>
> Let's start with borders. ALL borders in OSM are based on claims. All of
> them. Even when you see a fence, a border crossing post, etc., those are
> REFLECTIONS of the border claim. They are not the border itself. And all
> borders (even maritime) are based on paper. Either there was a war and a
> treaty, or there is a traditional agreement, or in the case of maritime
> borders, there is (generally) a 12-mile boundary away from "baselines", all
> of which are claims. So to be clear, every single admin_level=2 boundary in
> OSM today is based on a claim.
>
> Lines of control are different, and are based on actual "on the ground"
> control. Those are fluid and difficult to ascertain in some cases, which is
> why the proposal spelled out a system that anyone could apply to know where
> and how to (literally) draw the line.
>
> Because it's basically impossible to eliminate the border claims (they are
> inherent to the OSM map), and because they are not observable "on the
> ground", the proposal was designed to eliminate the conflation between
> border claims and lines of control. The purpose of this is to support the
> on the ground principle. I am surprised that some people thought it might
> undermine it.
>
> Similarly with the list of claiming entities. There is ALREADY such a list
> ("political entities with ISO codes"), it is simply not consistently
> followed. The proposal offered specific criteria so everyone would know
> who's in and who's out, as well as a way to change the criteria.
>
> But enough of that. These things could have been discussed during the RFC.
> They weren't. I doubt with such a controversial topic, however, that a 74%
> vote would ever be possible. So I am content to mark it as "defeated".
>
> I do like Nathaniel's idea, and since we have "any tag you like" there is
> nothing to stop people from implementing the proposal as is. I do suspect
> that edit wars (as we have already seen) will follow, and I feel sorry for
> the Data Working Group and the OSM Foundation board -- I certainly wouldn't
> want to arbitrate those.
>
> John
>

Hi John,

I don't think that there's a lack of interest in the issue of disputed
territories, but rather that you've hit a fundamental issue in OSM (and
that might also appear in any other community-driven project).  Mapping
disputed territories is a complex, because it requires (hobby) mappers to
involve themselves into issues of international politics. Questions of
territorial control, the status of disputes and recognition of states and
other entities involve international politics and law. The question of how
to map the borders of Crimea, Western Sahara or Israel, which entities are
involved and how such conflicts are being resolved go beyond the scope of
everyday mapping. It simply is much more demanding to take a stand on such
a politically charged issue than e.g. on how to map police facilites, where
there is usually no dispute about their existence.

Taking into account the complexity of the issue at hand, I haven't been
surprised at all that there were few mappers commenting and voting on your
proposal. I haven't mapped international boundaries myself, simply because
I didn't have the time to familiarise myself with the current OSM mapping
policy and the technical details of mapping such long ways in JOSM. Still,
I have voted your proposal, because I have a professional background that
has allowed me to easily make up my mind on the issue at hand.


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-11 Thread Jan S


Am 11. März 2019 17:32:13 MEZ schrieb Martin Koppenhoefer 
:
>
>in Germany, the cells in a police facility would not be called a
>prison, AFAIK there are only “drunk tanks” (Ausnüchterungszelle /
>sobering cell) and people would otherwise (pre-trial detention) go to a
>real prison (government facility / de: JVA).

Not always. Central big police detention facilities are also used during 
demonstrations or large events like football matches and then people may be 
held even during several days. Also, here in Hesse the police runs the 
detention facility for deportees, which, however, is another borderline case 
due to the longer detention periods there... I'd tend to tag it as prison, not 
as police detention 
(https://www.polizei.hessen.de/dienststellen/polizeipraesidium-suedhessen/ueber-uns/broker.jsp?uMen=c4970ee1-825a-f6f8-6373-a91bbcb63046&_ic_uCon=b2050950-dce8-c761-560d-877101467e03=20470d14-3169-f841-ab27-2006165474d5)

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-11 Thread Jan S


Am 11. März 2019 01:45:56 MEZ schrieb Joseph Eisenberg 
:
>> “in China some police divisions even managed to setup their own
>for-profit companies, like hospitals or construction companies, that
>would
>serve general public and compete in business environment in order to
>create
>additional revenue stream for their police division. I don't think it
>would
>be wise to tag them police=hospital or police=commercial either?“
>
>I agree. In Indonesia my local police station has a public clinic,
>pharmacy, daycare, church and mosque. The military base has all of
>these,
>plus some general merchandise shops. It’s a way to improve public
>relations
>(and perhaps make some money?). Oh, and the airfield transports goods
>by
>cargo plane at market price.
>
>But these businesses and services should not be tagged under a “police”
>key

Agreed. But you could map the area as landuse=police?

The police scheme should be limited to "typical" police functions, i.e. law 
enforcement. As always though, there will be cases where it's difficult to tell 
the police from the military or from other civilian offices or functions. These 
cases will inevitably have to be decided individually.

Best, Jan

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-11 Thread Jan S


Am 11. März 2019 00:40:14 MEZ schrieb Graeme Fitzpatrick 
:
>> How about police=detention as a more generic term then?
>>
>
>Yep, that covers it nicely!

Ok, so police=detention be it.

I've also adapted the definition to better distinguish the facilities I have in 
mind from prisons or jails (which, in the US at least, may serve as detention 
facilities even for convicted criminals, like Sheriff's jails) and which should 
be tagged as amenity=prison.

Best, Jan

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


Re: [Tagging] discouraging shop=fashion

2019-03-10 Thread Jan S


Am 10. März 2019 22:28:13 MEZ schrieb Graeme Fitzpatrick 
:

>I agree, so what is the procedure for deprecating a tag?

The normal proposal procedure, only that you don't propose a new tag but the 
abolition and replacement of an existing one?

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-10 Thread Jan S


Am 10. März 2019 20:31:33 MEZ schrieb Paul Allen :
>On Sun, 10 Mar 2019 at 18:45, Sergio Manzi  wrote:
>
>no problem maintaing the currently defined terminology "prison" and
>> "operator", for me: as I said it was a bit of hair splitting and as I
>hit
>> the send button I also asked myself if maybe "jail" was an
>americanism (*I'm
>> Italian, I spent some time in the US but very little time in the
>UK...*).
>>
>
>The prison/jail distinction tends to be an American thing.  In the UK
>they
>mean the same
>thing and police stations (if they have detention facilities at all)
>have
>cells, not jails.  From what
>I've dug up so far, it seems only the US has this distinction.
>
>In researching this answer I also found that (according to Wiktionary)
>"gaol" used to be the preferred
>spelling in the UK and Australia until Monopoly came along and used the
>American spelling even
>in those two countries.

How about police=detention as a more generic term then?

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-10 Thread Jan S


Am 11. März 2019 00:00:55 MEZ schrieb Paul Allen :
>On Sun, 10 Mar 2019 at 22:53, Martin Koppenhoefer
>
>wrote:
>
>>
>> > On 10. Mar 2019, at 14:13, Paul Allen  wrote:
>> >
>> > Which of all those get mapped as police and which get mapped as
>military
>> will need to be
>> > figured out at some point.
>>
>>
>> IMHO we should be able to map it as both (as military and as police)
>where
>> it is applicable.
>>
>
>It will end up being a per-country decision (or in-country dispute). 
>And
>however it's decided, it's
>better documented.  Just to stop people asking the same question
>repeatedly
>here and in the
>forums.  So either a table on the police=* page or a link from it to a
>page
>documenting the
>local decision.

+1

I think it would have to be determined even for each facility if it is more 
police or more military in unclear cases. According to this decision, barracks 
for example could either be mapped as police=barracks and military=yes if 
they're more police-like, or military=barracks and police=yes if the military 
character is stronger. But again, that's a local decision.

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-10 Thread Jan S


>1) You're using "operator=*" to identify the particular police force to
>which a feature is related. That's in line with what we do in several
>other situations, but as we are talking about police, wouldn't be
>"corps=*" more correct?
>
>2) More than "prison" I think "jail" would be more adequate: AFAIK
>police forces do not "own" prisons (long term incarceration) but only
>jails (short term incarceration). It is true that in some countries a
>dedicated police force is in charge of prisons operation, but the
>"ownership" of the prison is usually "the government".

Thanks, Sergio.

This comes down to a fundamental question: is it better to use already 
established values for new schemes (which is what I tried to do), or is it 
preferable to introduce new, maybe more specific values (which is what Sergio's 
proposal is aimed at, if I'm right)?

Best, Jan

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


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-10 Thread Jan S
Am So., 10. März 2019 um 14:15 Uhr schrieb Paul Allen :

>
> Under "Rendering" you say "Typical police stations, i.e. places where one
> can get in contact
> with the police usually 24/7, should be rendered different from other
> police facilites"
>
> In my part of the UK (still running austerity measures) which is largely
> rural, the police stations
> in smaller towns are not 24/7.  They work office hours.  There is a
> special phone on the outside
> of the building that contacts the main police station (which around here
> can be up to 30 miles
> away).
>
> I know you say "usually" but I'd change that to "often."  Around here it's
> unusual for these
> stations to be 24/7.  You probably also need to mention opening_hours=* as
> a tag that
> can be used in combination.
>

Good point. That may even more often be the case in rural areas. I'll
reformulate that part. The use of opening_hours=* seemed obvious to me, but
I'll point it out.

>
> You don't discuss what to do when the domestic police are (at least
> notionally) part of the
> military.  Somebody here brought up the Italian Carabinieri.  And
> yesterday I read that the
> French Gendarmerie are part of the French military.  In the UK domestic
> police are not
> part of the military but the Ministry of Defence has various Service
> Police forces dealing
> with the protection of military bases and the behaviour of military
> personnel; it also
> has the "Ministry of Defence Police" for dealing with terrorism and
> protecting nuclear
> plants (I've simplified what they do).
>

> Which of all those get mapped as police and which get mapped as military
> will need to be
> figured out at some point.  If not on the page for police=* itself then at
> least a page documenting
> local decisions on such matters.
>

I deliberately didn't want to get into this discussion. This is something
that has to be sorted out locally. E.g. in France, I've seen that they map
the Gendarmerie as military, but the public-facing offices as
amenity=police. I think that it's essential to detemine the principal
function of an entity in each place. Does it appear principally as police
or as military? While the Gendarmerie is under the auspices of the Ministry
of Defense, it fulfils the role of a civil police in rural areas. Btw, fire
fighters in Paris and Marseille are military units, too, but no mention to
this is made in OSM.

Here in Germany, there's a military police (Feldjäger), but they're
comptent only in relation to crimes within the military or affecting
military property. They're stationed on military ground. I'd tag them as
military, not as police.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-10 Thread Jan S
Am So., 10. März 2019 um 04:09 Uhr schrieb Graeme Fitzpatrick <
graemefi...@gmail.com>:

> Good start Jan.
>
Thanks!

>
> A first few thoughts.
>
> police=naval_base sounds very dramatic & possibly a bit over the top?
> Having said that, none of the other common options seem quite right either
> eg mooring / dock / boatyard / marina? Maybe police=marine_operations /
> maritime?
>

Indeed naval_base might be a bit much. But I just wanted to copy the
military scheme as far as possible, without inventing new keys, because
marina somehow wouldn't seem fitting either. Marine_operations or maritime
sound good, but they wouldn't be fitting for river police, would they?
Police=water might be an option, though, albeit it's ambiguous, also (a
police to control water quality?).


> police=prison. Are you aware of the existing amenity=prison?
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dprison
>
> I am aware of it. My thought was to have all police facilities under one
tag. Prisons are generally not run by the police, but specialized services.
Still, there are police prisons that are separate from police stations.
Here in Frankfurt, there used to be a proper police prison in its own
building (https://www.openstreetmap.org/node/1591630307). It's out of use
today, though, but I imagine that the concept might still exist in other
places.

Such areas shall be tagged as landuse
>> =police
>> 
>> .
>>
>
> Nice idea! Maybe rendered as blue stripes, where =military is pink (which
> has always struck me as a bit strange! :-))
>
>
>> Typical police stations, i.e. places where one can get in contact with
>> the police usually 24/7, should be rendered different from other police
>> facilites.
>>
>
> I would suggest possibly only rendering the actual "Police stations",
> using the existing policeman icon? Everything else, possibly just tagged as
> building=yes + name=Police holding yard, so that the only "Police" icons
> you see are the Police stations that you need to visit?
>

police:name
>> 
>> =* shall be used to tag the denomination of police running the specific
>> facility
>>
>
> As Warin mentioned above, just use the existing name= & operator= tags eg
> name=Palm Beach Police Station
> operator=Queensland Police Service
>
> name=Gold Coast Water Police
> operator=Queensland Police Service
>
> name=Gold Coast Aviation Operations Centre
> operator=Australian Federal Police
> would certainly seem to work in most of our contexts - would this format
> work worldwide, especially in European countries that seem to have myriad
> Police Forces?
>
There's a lot of police forces here, indeed. Operator would be a good
option to hold the name of the police force operating the facility, just in
the sense you've mentioned. I've adapted my proposal already!


>  Btw: It's my first shot, so please be gentle with me.
>>
>
> Nerve-wracking, isn't it? :-)
>
No, for the moment it's enticing :)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - police=*

2019-03-09 Thread Jan S


Am 9. März 2019 22:34:39 MEZ schrieb marc marc :
>
>police:name : it's not what should be in operator or network ?
>
>police:type : type is a no-meaning tag despite I currently no idea for
>a 
>good name.
>I also fail to understand the dif with police:name.
>what's the police:name of CRS ?
>what's the police:type of NYPD ?

Thanks for your observations. I'll collect more opinions on the abolition of 
amenity=police.

I've added some tagging examples to the proposal, so I hope that the concept is 
clearer now.

Best, Jan

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


[Tagging] Feature Proposal - RFC - police=*

2019-03-09 Thread Jan S
Hi everyone,

I have written up a draft of a police scheme. It would be a pretty
fundamental modification of the current way of tagging police facilites,
but I think that given the current state of the map, that does not allow to
differentiate police stations that provide emergency services and other
police facilites, we'd have to tag many facilites that are currently
amenity=police again, anyways. So, why not try a new approach altogether
and pull things straight for the future.

I'm looking forward to your comment!

See the proposal at
https://wiki.openstreetmap.org/wiki/Proposed_Features/Police_facilites

Btw: It's my first shot, so please be gentle with me.

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


Re: [Tagging] amenity=police

2019-03-09 Thread Jan S


Am 8. März 2019 19:02:08 MEZ schrieb Martin 
>
>what about other police facilities that are also tagged with
>amenity=police
>now, should they key the basic tag as well?

That wouldn't be useful, I guess. Maintaining amenity=police would already be a 
concession to existing mapping and rendering traditions in the case of 
public-facing police stations. But it shouldn't remain the general tag to mark 
all police facilities. Many police facilities simply don't coincide with the 
definition of amenity, which reads "For describing useful and important 
facilities for visitors and residents".

I'd still favour a clear-cut solution with a proper police scheme.

Best, Jan

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


Re: [Tagging] amenity=police

2019-03-06 Thread Jan S


Am 6. März 2019 19:37:13 MEZ schrieb Martin Koppenhoefer 
:
>I would be more in favor of using more explicit tags, like
>amenity=police_station because this implies more obviously that it is a
>public facing facility.

Or, to keep it simple, maintain amenity=police for public-facing police 
stations and office=government and government=police for all non public-facing 
facilities. Although such a scheme would probably fall short again, given the 
many different types of police facilities...

Or - I'm just brainstorming - amenity=police for public-facing stations and a 
police scheme for all other facilities?

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


Re: [Tagging] amenity=police

2019-03-06 Thread Jan S


Am 6. März 2019 13:56:43 MEZ schrieb Martin Koppenhoefer 
:

>
>IMHO we need to distinguish different kind of facilities (e.g. a police
>station from police barracks) and different kind of police types at the
>facility (e.g. coast guards, customs, federal police, military police,
>etc.
>plus subtypes as required.)
>
>Regarding the facility type, the tag "amenity=police" is choosen poorly
>because it may be interpreted as any kind of police facility, or it may
>be
>seen as "for police stations only". (Btw. there are also different kind
>of
>police stations based on size/rank and opening hours, at least in
>Germany,
>e.g. "Polizeiwache", "Polizeipräsidium" / Direktion,
>"Kriminalkommisariat",
>"Polizeiposten", "Polizeirevier", etc., some of which also imply
>certain
>operator types (Kriminal...))
>The details may vary in Germany according to the Bundesland.
>
>I am not only interested in the German situation, but would like to
>collect
>more tagging requirements  from other realities as well, so that it can
>become a global scheme, although I would recommend to tag the specific
>name
>in the local language (see above) as well (not necessarily in name,
>might
>eventually be a candidate for official name).

I propose that we proceed on two levels. On the one hand we should define a 
general "police" scheme that's sufficiently general to cover police facilities 
worldwide. That could be the "police" tag I've proposed, and a list of keys for 
typical facilities. This scheme should provide a tag for points of first 
contact, typically with 24/7 service (i.e. the prototype of a local police 
station). Other police stations that don't fulfil this role could be grouped as 
e.g. "police=office" or "police=administration" and then be differentiated by 
the name tag. Otherwise we could represent the level of hierarchy of the 
respective offices with something like a "police:admin=1-5" scheme, but I 
wouldn't see the use of doing so.

The other question that remains unresolved (and IMO can only be resolved in 
every state or region autonomously) is the definition of what is to be 
considered police. But independently of the respective local definition, the 
corresponding sites should be able to be mapped under a new police-scheme.

Best,
Jan

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


Re: [Tagging] amenity=police

2019-03-06 Thread Jan S


Am 6. März 2019 01:57:21 MEZ schrieb Martin Koppenhoefer 
:
>
>
>sent from a phone
>
>> On 5. Mar 2019, at 12:17, Jan S  wrote:
>> 
>> Any thoughts on this?
>
>
>if you think about it, there are more police forces in Germany,
>particularly if we find more specific tagging for specific categories
>of forces (e.g. Bereitschaftspolizei, Autobahnpolizei,
>Wasserschutzpolizei, LKA, BKA) and others that might eventually be
>considered police like Zoll, Steuerfahndung, Justizvollzugsbeamte,
>Küstenwache, Forstamt (forrester), Ordnungsamt,
>Wirtschaftskontrolldienst, Feldjäger, ...

IMO you're mentioning two types of forces. All those that carry the notion 
"Polizei" as part of their name are police forces. They are either part of the 
state or the federal police (except the BKA, which is a separate entity). I 
think hence that a subdivision as to whether a unit belongs to the state or the 
federal police is sufficient in Germany. Also, different units of the same 
police force may share facilities.

All other forces or entities are part of the administration. The main 
difference is that the police may intervene in any issue of any other entity, 
as long as that other entity is not available or not able to cope with the 
situation. E.g. the police intervene in prison riots if the prison staff cannot 
deal with the situation. Or, if you're partying hard during the day, it'll be 
the Ordnungsamt knocking on your door, while at night it'll be the police (who 
may also knock during the day, if the Ordnungsamt for some reason can't).

This, however, will have to be defined according to the domestic situation in 
every state.

Best, Jan

>Belonging to “military” does not necessarily exclude a body from being
>a police force, neither in osm, or does it?
>
>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] amenity=police

2019-03-05 Thread Jan S


Am 6. März 2019 00:35:44 MEZ schrieb Graeme Fitzpatrick :
>On Tue, 5 Mar 2019 at 22:01, Jan S  wrote:
>
>
>How about emergency=police?
>
I had thought about that, too. But my impression is that the emergency tag is 
more restricted to facilities that help you in ongoing situations of distress 
and are on the spot. I assume it's rather unusual to go to the police in an 
emergency, but you'd rather call them.

The police station itself may be for less urgent situations mainly. So also for 
that reason, the emergency tag may be inaccurate.

Best, Jan

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


Re: [Tagging] amenity=police

2019-03-05 Thread Jan S
Am Di., 5. März 2019 um 12:46 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

>
>
>
> Mar 5, 2019, 12:17 PM by grimpeu...@gmail.com:
>
> I would hence suggest to introduce a new tag "police" with keys like
> "station", "administration", "criminal police", "barracks", "range",
> "naval_base" (for river police or coast guard), etc. The type of police
> could then be tagged as "operator=*"
>
> "police=station" should be defined as comprising all police stations of
> the lowest level, where you can turn to in case of an emergency, no matter
> whether the operating entity is formally a civil or a military one. Other
> areas or buildings, like barracks, ranges, administrative units etc. could
> then be tagged as "police=*" or "military=*", according to the
> classification of the operating force.
>
> Any thoughts on this?
>
> I would tag office with internal police administration with some office=*
> tag, without amenity=police
>
> We should not tag Tesco headquarters as shop, we should not tag government
> office
> maintaining canals as waterway=canal and we should not tag government
> office
> managing police as amenity=police
>
> Similarly, police laboratory, range, barracks, academy, warehouse should
> also should not be
> tagged amenity=police.
>
> But police tag makes sense, just do not require or request to always add
> also amenity=police.
>
> I would keep amenity=police to public-facing police places.
>
> To values of police tag - there is also municipal police (in Poland called
> "Straż Miejska"
> that is usually mostly handling illegally parked vehicles and minor
> disturbances like
> drunk people).
>
> So also police=municipal?
>
> BTW, I would not mix police type (municipal, state, military, etc) with
> object type (naval_base,
> administration, barracks, range) in one key.
>
> Thanks for commenting!

Maybe my post was confusing.

I imagined that all public-facing police stations be tagged as:

police=station
operator=(Bundespolizei/Straż Miejska etc.)
opening_hours=*
...

Police barracks would then be

police=barracks
operator=*
...
And an administrative building could be

police=administration
operator=*
opening_hours=*
...

As amenity=police is currently being used indiscriminately for almost all
police-related facilities, we would have to review all police buildings
manually anyways to differentiate police stations and other units. In the
long run, I would therefore get rid of amenity=police altogether (and thus
decongestionate the "amenity"-tag a bit).

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


Re: [Tagging] amenity=police

2019-03-05 Thread Jan S
Am Fr., 1. März 2019 um 18:55 Uhr schrieb Greg Troxel :

> Martin Koppenhoefer  writes:
>
> > I wonder what we call "police" in OSM.
> >
> > The wiki does not offer a lot of guidance (France aside): "A police
> station
> > is a building where police officers and other staff work and are
> dispatched
> > from, and where suspects and evidence are collected and processed."
> > https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpolice
> >
> > Is this limited to civil police forces, or does it include military
> forces?
> > The French seem to include the Gendarmerie (military force under the
> > jurisdiction of the Ministry of the Interior), and similarly we include
> the
> > Carabinieri in Italy (adding also landuse=military).
>

I have looked at some police facilites in my area and must admit that I am
now even more confused about how to map them.

Here in Germany, there are two main police forces, the 16 state polices and
the federal police. Also, in some cities there is a municipal police, which
are usually uniformed members of the city administration who are not
allowed to recur to the use of force. Still, they do some minor policing
tasks. There's also a military police, but afaik their competences are
restricted to issues within the military forces.

Here in Frankfurt for example, the municipal police station is tagged as
"amenity=police" and "operator=Stadtpolizei" (
https://www.openstreetmap.org/way/440792258), which to me is fine. State
and federal police stations are also tagged as "amenity=police" albeit
without the "operator" tag (e.g. https://www.openstreetmap.org/way/440792258
for a federal police station and
https://www.openstreetmap.org/node/401296942 for a state police station).
That's also fine, I guess, although the "operator" tag might be helpful.

However, other facilities of the state police, like barracks for special
units, are also tagged as "amenity=police" (
https://www.openstreetmap.org/way/55342341), although they don't attend the
public at all. And even stranger, barracks of the federal police are tagged
as "military=barracks" (https://www.openstreetmap.org/way/4537958),
although since the Federal Border Protection Service (Bundesgrenzschutz)
has been transformed into the federal police in the 1990s, it has lost its
combatant status under international law and today clearly is a civil
police force.

In France, I've checked only one Gendarmerie site, where the area has been
tagged as "landuse=military" but the Gendarmerie station on the area, where
the public is attended, has been tagged as "amenity=police" (
https://www.openstreetmap.org/way/47840959). However, the barracks of the
Compagnie Républicaine de Sécurité at Strabourg are also mapped as
"amenity=police", although there doesn't seem to be a post to attend the
public, either.

The combination of "office=government" and "government=police" is hardly
used at all in Germany and France (which is not surprising at all, given
that taginfo only returns 75 instances at all).

In consequence, I don't see that the current way of tagging police
facilities was useful for several reasons:

1) Police facilities are tagged as "amenity=police", indiscriminately of
whether one can go there in an emergency or not. Even purely administrative
units which don't attend the public at all receive the same tag as common
police stations.

2) The police has a variety of facilites, similar to the military forces,
that cannot be currently differentiated.

3) There is a confusion about what to tag as "police" and what to tag as
"military".

I would hence suggest to introduce a new tag "police" with keys like
"station", "administration", "criminal police", "barracks", "range",
"naval_base" (for river police or coast guard), etc. The type of police
could then be tagged as "operator=*"

"police=station" should be defined as comprising all police stations of the
lowest level, where you can turn to in case of an emergency, no matter
whether the operating entity is formally a civil or a military one. Other
areas or buildings, like barracks, ranges, administrative units etc. could
then be tagged as "police=*" or "military=*", according to the
classification of the operating force.

Any thoughts on this?

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


Re: [Tagging] Clarification unclassified vs residential

2019-02-23 Thread Jan S


Am 23. Februar 2019 03:47:50 MEZ schrieb Greg Troxel :

>Really the notion of "unclassified" is odd, and it probably should be
>"quaternary".  Arguably residential should then be highway=level5,
>regardless of housing, and perhaps some tag on all highways about
>residential or not - but as I said earlier, you can tell that from
>landuse.

I strongly support this. "Unclassified" causes much confusion outside the UK 
and is at the root of many equivocal tags. "Minor" might also be an appropriate 
denomination.

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


Re: [Tagging] Clarification unclassified vs residential

2019-02-22 Thread Jan S


Am 22. Februar 2019 17:59:28 MEZ schrieb Paul Allen :
>On Fri, 22 Feb 2019 at 16:42, Florian Lohoff  wrote:
>
>>
>> I have never said that residential may only be used in city limits.
No, but other did. Sorry I didn't separate this from the reference to your 
post. No offense meant.

>Residential areas, to me, are
>named localities.

That may be true in Western Europe, but in many places in other parts of the 
world there may be areas of residential use that are not named or only have, 
sometimes even several, unofficial denominations. 

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


Re: [Tagging] Clarification unclassified vs residential

2019-02-22 Thread Jan S


Am 22. Februar 2019 16:20:23 MEZ schrieb Florian Lohoff :
>On Thu, Feb 21, 2019 at 04:54:09AM -0700, Richard Fairhurst wrote:
>> Florian Lohoff wrote:
>> > From the original meaning unclassified was the lowest class road 
>> > in rural or off city limits. residential was the lowest class road 
>> > within city limits. (Assuming that city limits mean residential 
>> > usage)
>> 
>> That's reasonable but not _quite_ true. highway=unclassified is often
>used
>> in urban areas to denote a minor distributor road. 
>
>But the above is the documentation we had for like 10 Years - This is 
>why i asked for clarification. It seems everybody has different
>assumptions about usage and priority of unclassified vs residential
>and those are not reflected in the unclassified tag page. The German
>page has much more stuff but IMHO wrongfully added by a small group.

I understand the documentation of the highway tag as indicating that 
"unclassified" indeed designates a more important road than "residential". 
Under "usage" it reads: "See the table below for an ordered list from most 
important (motorway) to least important (service)." And as "unclassified" is 
above "residential", I would consider it as being more important (although this 
may not be respected by routing engines).

Also, there is nothing to support that residential roads were to be used within 
city limits only. Residential roads are described as an "access to housing" or 
"accessing or around residential areas". Residential areas may also well be 
unincorporated groups of houses (thinking e.g. of task description for HOT OSM 
tasks in Africa).

Best, Jan___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] StreetComplete 10 / foot=yes on residential

2019-02-17 Thread Jan S



>> We also need to apply common sense when mapping.
>
>
>yes. Although common sense is not a criterion for legal access. This is
>either allowed or forbidden, and unless it is forbidden, access is by
>default allowed on roads. 

I fear common sense in fact somehow IS a legal criterion. Lawyers and lawmakers 
have already more than a hundred years ago rendered to the fact that it's 
impossible to regulate people's behaviour into every last detail. This is 
particularly true for a system with so many participants like traffic. That's 
why above all other traffic rules there's the basic rule of " you shall not 
pose more risk to others than what is strictly inevitable". Here in Germany 
this rule is expressed in section 1 subsection 2 of the traffic code (§ 1 (2) 
StVO). And that's why no sign is necessary at the tunnel at Tunisstrasse in 
Cologne (the example put forward in this discussion before). There, all 
pedestrians, load-bearing or not, have plenty of less dangerous options than 
walking through the tunnel. In consequence, I would consider it right to tag 
the tunnel as "foot=no".

All the best!___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging