Re: [Tagging] Wiki changes for police tag

[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

Re: [Tagging] Wiki changes for police tag

[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


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

[Tagging] Feature Proposal - RFC - changing table

[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

[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] Feature Proposal - RFC - changing table

[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] Opening hours syntax for non Gregorian calendar

[Phake Nick]

That doesn't seems to solve the problem that would occur. For instance, how
to represent the first Sunday (a feature in Gregorian calendar) after
Chinese traditional ceremony X (a feature in Chinese traditional calendar)
in the opening time syntax, if they're split up for "simplicity"? What
about when the opening time also cover non-holiday festivals that only
occurs according to either calendars?

On 2019-05-18 Sat 04:50, Paul Allen  wrote:

> Problem of splitting: what if a mapper gives the opening times in both
> calendar_X and calendar_Y
> and they disagree?  Consumers will have to have rules like: in country_Z
> use calendar_X if given,
> otherwise use standard opening_hours if given, otherwise use calendar_Y if
> given, otherwise
> pick at random from what is left.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours syntax for non Gregorian calendar

[Simon Poole]

As I've pointed out before the one thing that is unproblematic to add
are more variable date public holidays, right now there is only easter
defined,  adding ramadan for example would be no problem.

Further expressing a rule is one thing, evaluating it is a something
else, and adding some kind of "context" value to help in the later (for
example a time zone value as has been suggested previously)  could
potentially work.

Simon

Am 18.05.2019 um 12:34 schrieb Phake Nick:
> That doesn't seems to solve the problem that would occur. For
> instance, how to represent the first Sunday (a feature in Gregorian
> calendar) after Chinese traditional ceremony X (a feature in Chinese
> traditional calendar) in the opening time syntax, if they're split up
> for "simplicity"? What about when the opening time also cover
> non-holiday festivals that only occurs according to either calendars?
>
> On 2019-05-18 Sat 04:50, Paul Allen  > wrote:
>
> Problem of splitting: what if a mapper gives the opening times in
> both calendar_X and calendar_Y
> and they disagree?  Consumers will have to have rules like: in
> country_Z use calendar_X if given,
> otherwise use standard opening_hours if given, otherwise use
> calendar_Y if given, otherwise
> pick at random from what is left.
>
> -- 
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] Wiki changes for police tag

[Lionel Giard]

I also see it as a top-level tag. i find it similar to the recent
"healthcare=*" which can be used by itself too.

Le sam. 18 mai 2019 à 11:46, Jan S  a écrit :

> 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 
>> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours syntax for non Gregorian calendar

[Paul Allen]

On Sat, 18 May 2019 at 12:01, Simon Poole  wrote:

>
> As I've pointed out before the one thing that is unproblematic to add are
> more variable date public holidays, right now there is only easter
> defined,  adding ramadan for example would be no problem.
>

Syntactically, probably not a problem.  Calculation of the astronomical
events is well-defined.
Interpreting those events is not:  In some schools of Islam, calculation
suffices; in others
visual confirmation is required.  The two can (and often do) differ by a
day.  Possibly
solvable by having ramadan_x and ramadan_y.  Or just by ignoring the
problem and stating
that "ramadan" means local definition of Ramadan, whatever that happens to
be.

Note also that whilst opening_hours blithely defines "easter," the date on
which it falls
differs between the Catholic and Orthodox churches.  When a country
celebrates
Easter depends upon religious factors.

Can we just ignore the problem?  For Easter, maybe.  Data consumers could
build in
country-specific rules defining if Easter is Orthodox or Catholic.  Along
with astronomical
calculations, that would allow an app to say "This office in a different
country from you is
closed because it follows a different definition of Easter from your
location."  Not so easy
for Ramadan defined by visual observation.

A bigger problem, as I see it, is that cultures using the luni-solar
calendar often have days of
the week that begin at sunset, not midnight.  Especially important in
religious observances:
the Jewish Sabbath starts at sunset on Friday.  In the current scheme, "Su
off" is not strictly
necessary (it can be inferred) but to be fair to other cultures you'll need
to be able to specify
Sabbath (the obvious abbreviation has a clash) and similar days in other
cultures.

These are just the problems I know of.  I doubt that is all of them.

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

Re: [Tagging] Opening hours syntax for non Gregorian calendar

[Simon Poole]

Am 18.05.2019 um 15:28 schrieb Paul Allen:
> ...
> Can we just ignore the problem?  For Easter, maybe.  Data consumers
> could build in
> country-specific rules defining if Easter is Orthodox or Catholic. 
> Along with astronomical
> calculations, that would allow an app to say "This office in a
> different country from you is
> closed because it follows a different definition of Easter from your
> location."  Not so easy
> for Ramadan defined by visual observation.
> ...

Evaluation of opening hours values already depends on location and lots
of configuration for the PH tag (and in principle for the SH one too).
So this wouldn't be introducing anything new. See
https://github.com/opening-hours/opening_hours.js#holidays



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

Re: [Tagging] Wiki changes for police tag

[Simon Poole]

Am 18.05.2019 um 11:44 schrieb 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.

I think you will find that most people will disagree with and will want
to tag buildings as buildings. 

In any case the answer to my question seems to be "sorry we didn't think
of that".


>
> 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


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

Re: [Tagging] Wiki changes for police tag

[Mateusz Konieczny]

18 May 2019, 22:07 by si...@poole.ch:

>
>
>
> Am 18.05.2019 um 11:44 schrieb 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.
>>
>
> I think you will find that most people will disagree with and  will want 
> to tag buildings as buildings. 
>
>
> In any case the answer to my question seems to be "sorry we  didn't think 
> of that".
>
>
It is the same as with say shop=supermarket.

It is not enough to tag shop=supermarket to indicate that building exists,
you still need to have building tag (maybe on the same object, maybe on a 
separate way).

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

Re: [Tagging] Wiki changes for police tag

[Graeme Fitzpatrick]

On Sun, 19 May 2019 at 06:12, Mateusz Konieczny 
wrote:

> It is the same as with say shop=supermarket.
>
> It is not enough to tag shop=supermarket to indicate that building exists,
> you still need to have building tag (maybe on the same object, maybe on a
> separate way).
>

Which seems to be covered by
building=retail + shop=supermarket

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

Thanks

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