Re: [Tagging] Game and toy library

[ChameleonScales]

Sure but if anyone has something to say that is directly related to my proposal 
it would be best to discuss it there.

Other than that, is it complete enough to move it from Draft to Proposed?

‐‐‐ Original Message ‐‐‐
On Friday, October 12, 2018 3:21 AM, Warin <61sundow...@gmail.com> wrote:

> Took me a while to find it .. to save otehrs time here is a link.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/toy_and_game_library
>
> Proposals are usually discussed both here and on their own discussion page.
>
> On 11/10/18 20:27, ChameleonScales wrote:
>
>> I made some updates to the wiki proposal and I propose we continue the 
>> discussion on its discussion page.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, October 9, 2018 11:23 PM, ChameleonScales 
>>  wrote:
>>
>>> Hi all,
>>>
>>> Game and toy libraries don't fit in any feature type.
>>> They can be but are not necessarily:
>>> - non-profit organizations
>>> - child care facilities
>>> - social faciilties
>>> - toy stores
>>> - libraries
>>> - probably other things
>>>
>>> So I think they should have their own feature type and tag.
>>> How about
>>> amenity:library=game_and_toy
>>>
>>> Would that be possible?
>>>
>>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> ___
>> 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] How to tag named group of named water areas?

[Kevin Kenny]

>
> why not a multipolygon? I agree that you don’t need additional tags for a
> group relation, just type=group, a name and the members, but for a site you
> would need something that describes the site, a tag for a group of water
> areas, so as long as all the members are areas (or parts), a multipolygon
> would be better.
>

When the lakes themselves are complex multipolygons with many islands,
repeating that data for the group is likely to be a maintenance nightmare.
(I know this from curating boundary=protected_area relations that include
partial shorelines on such lakes. It's especially fun when the boundary
splits islands.)

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

Re: [Tagging] How to tag named group of named water areas?

[Martin Koppenhoefer]

sent from a phone

> On 12. Oct 2018, at 09:13, Warin <61sundow...@gmail.com> wrote:
> 
> Why not bet both ways? 
> Make both a site and a group relation. 


why not a multipolygon? I agree that you don’t need additional tags for a group 
relation, just type=group, a name and the members, but for a site you would 
need something that describes the site, a tag for a group of water areas, so as 
long as all the members are areas (or parts), a multipolygon would be better.

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

Re: [Tagging] Opening hours too long for OSM

[Tobias Zwick]

It is already part of the specification that "Mo-Fr 9-17" is possible.
Alas, QA tools / the openinghours evaluation tool emit a warning in this
case: "Time range without minutes specified. Not very explicit! Please
use this syntax instead "9:00-17:00"."
Not sure why that is not seen as explicit.

On 12/10/2018 22:29, bkil wrote:
> That looks like a nice improvement.
> 
> Additionally, I've always wondered why we need to enter :00 after
> every hour and zero pad the hours? The shops themselves usually post
> the opening hours as 9-17 - why can't we use this human friendly
> abbreviation? I don't feel that it would be that much harder to parse.
> (9-17h would also work for me) 9-17:30 and 9:30-17 are still
> unambiguous (though, the latter looks a bit uglier at first).
> 
> I think this would greatly improve readability, make data entry faster
> and less error prone and shorten the field all at the same time.
> 
> Is this fit for a proposal?
> 
> On Fri, Oct 12, 2018 at 12:04 AM Robin Schneider  wrote:
>>
>> On 10/11/18 11:47 PM, Jmapb wrote:
>>> On 10/11/2018 5:21 PM, Tobias Zwick wrote:
>>>
 Hey there!

 So, a user of StreetComplete came across the following complicated
 opening hours for a shop (prettified):

 Jun-Sep: Mo-Sa 10:00-18:00;
 Jun-Sep: Su 10:00-12:00;
 Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
 Nov-Mar: Sa 10:00-12:00;
 Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
 Apr-May: Sa 10:00-12:30;
 Apr-May: Su 10:00-12:00;
 Oct: Mo-Fr 10:00-12:30,15:00-18:00;
 Oct: Sa 10:00-12:30;
 Oct: Su 10:00-12:00

 Unfortunately, this does not fit into the opening_hours value, as this
 is limited to 255 characters. What can we do?
>>
>> Hey :)
>>
>> I would say your best bet is to try to shorten the opening_hours values using
>> every little trick that the syntax has to offer, for example you can join the
>> month ranges which is enough to bring you under 255 characters.
>>
>> Jun-Sep: Mo-Sa 10:00-18:00;
>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00,15:00-17:00;
>> Nov-Mar: Sa 10:00-12:00;
>> Apr-May,Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>> Apr-May,Oct: Sa 10:00-12:30;
>> Apr-May,Jun-Oct: Su 10:00-12:00
>>
>> You can then use the "value to compare to the first value:" feature of
>> https://openingh.ypid.de/evaluation_tool/ to check that you still preserved 
>> the
>> original meaning.
>>
>> I don’t have much to add in case you can not bring the value under 255 only 
>> that
>> I also don’t know any software which would handle that. I guess having the
>> special cases in an additional tag and `opening_hours` fully valid would be 
>> best
>> then.
>>
>> opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar:
>> Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr
>> 10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr
>> 10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00
>>
>> This won’t work. I had an idea for doing that but this is not supported yet:
>> https://github.com/opening-hours/opening_hours.js#todo
>>
>> --
>> Live long and prosper
>> Robin `ypid` Schneider -- https://me.ypid.de/
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] Opening hours too long for OSM

[Paul Allen]

On Fri, Oct 12, 2018 at 11:24 PM Allroads  wrote:

> https://github.com/opening-hours/opening_hours.js/issues/270
> Thinking loud, I like a set of subcategories.
> Basic set for a year, others for the fast change.
> I find this a practical understandable solution.
>

Until I took a look at the github issue you raised, I thought your proposal
was totally
incomprehensible.  Having read the github issue I now think it impractical
and unworkable.

Computerized data consumers like apps can handle it.  Mappers and people
using the map
query tool will not find it so easy.  It doesn't cope with seasonal hours
well if there are more
than two divisions in the year.  Mappers may end up revising the yearly
entry when they should
have modified the other entry and vice versa.

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

Re: [Tagging] Opening hours too long for OSM

[Allroads]

https://github.com/opening-hours/opening_hours.js/issues/270
Thinking loud, I like a set of subcategories.
Basic set for a year, others for the fast change.
I find this a practical understandable solution. 

From: OSMDoudou 
Sent: Friday, October 12, 2018 5:22 PM 
To: 'Tag discussion, strategy and related tools' 
Subject: Re: [Tagging] Opening hours too long for OSM 


As to improving (thinking out loud here...), ..

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

Re: [Tagging] hydrants

[Viking]

Bkill, at least in Italy hydrants are strong enough that it is impossible to 
brake them using only its key and human force. Anyway, if you think this tag is 
usefull, ok, map it.
I'm sure that also in Hungary OSM could help firefighters if hydrants mapping 
will become capillar. We in Italy have our databases too, but OSM is updated by 
many users, so we can take advantage of this continuous update to check new 
hydrants.
Then, I personally inserted our local hydrant database in OSM, so that any 
firefighter (and any civilian too) with a smartphone can easily look for the 
nearest hydrant and navigate to it.

François, use the same tagging schema for hydrants and pipe valves is a good 
idea.

Bkill, at the same time, having a tag that corresponds to the plates is a good 
idea too.

Paul, you are right, both 1) and 2) have merits, so I ask here to the community 
which solution do it prefer.

In summary:

for solution 1) to minimize database, I propose
opening:direction = clockwise / anticlockwise

for solution 2) to do not have different sets of values that apply in different 
situations, I propose
turn_to_open = clockwise / anticlockwise

Best regards,
Alberto


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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

Re: [Tagging] Opening hours too long for OSM

[bkil]

That looks like a nice improvement.

Additionally, I've always wondered why we need to enter :00 after
every hour and zero pad the hours? The shops themselves usually post
the opening hours as 9-17 - why can't we use this human friendly
abbreviation? I don't feel that it would be that much harder to parse.
(9-17h would also work for me) 9-17:30 and 9:30-17 are still
unambiguous (though, the latter looks a bit uglier at first).

I think this would greatly improve readability, make data entry faster
and less error prone and shorten the field all at the same time.

Is this fit for a proposal?

On Fri, Oct 12, 2018 at 12:04 AM Robin Schneider  wrote:
>
> On 10/11/18 11:47 PM, Jmapb wrote:
> > On 10/11/2018 5:21 PM, Tobias Zwick wrote:
> >
> >> Hey there!
> >>
> >> So, a user of StreetComplete came across the following complicated
> >> opening hours for a shop (prettified):
> >>
> >> Jun-Sep: Mo-Sa 10:00-18:00;
> >> Jun-Sep: Su 10:00-12:00;
> >> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
> >> Nov-Mar: Sa 10:00-12:00;
> >> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
> >> Apr-May: Sa 10:00-12:30;
> >> Apr-May: Su 10:00-12:00;
> >> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
> >> Oct: Sa 10:00-12:30;
> >> Oct: Su 10:00-12:00
> >>
> >> Unfortunately, this does not fit into the opening_hours value, as this
> >> is limited to 255 characters. What can we do?
>
> Hey :)
>
> I would say your best bet is to try to shorten the opening_hours values using
> every little trick that the syntax has to offer, for example you can join the
> month ranges which is enough to bring you under 255 characters.
>
> Jun-Sep: Mo-Sa 10:00-18:00;
> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00,15:00-17:00;
> Nov-Mar: Sa 10:00-12:00;
> Apr-May,Oct: Mo-Fr 10:00-12:30,15:00-18:00;
> Apr-May,Oct: Sa 10:00-12:30;
> Apr-May,Jun-Oct: Su 10:00-12:00
>
> You can then use the "value to compare to the first value:" feature of
> https://openingh.ypid.de/evaluation_tool/ to check that you still preserved 
> the
> original meaning.
>
> I don’t have much to add in case you can not bring the value under 255 only 
> that
> I also don’t know any software which would handle that. I guess having the
> special cases in an additional tag and `opening_hours` fully valid would be 
> best
> then.
>
> opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar:
> Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr
> 10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr
> 10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00
>
> This won’t work. I had an idea for doing that but this is not supported yet:
> https://github.com/opening-hours/opening_hours.js#todo
>
> --
> Live long and prosper
> Robin `ypid` Schneider -- https://me.ypid.de/
>
> ___
> 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 too long for OSM

[Tobias Zwick]

Regarding the general workaround of defining some common tag extension
scheme, the idea sounds good at first, but I think this cannot be the
solution after all.
Because, let's not fool ourselves, the application support for an
extension syntax will be almost non-existent. Just look at the support
for things like shop=books;stationery. Also, all QA-Tools will complain
about opening_hours or any other tag normally containing structured data
that is split along several keys to be wrong.

I think this can only be solved effectively centrally, and since Simon
mentioned an earlier ticket in openstreetmap-website, I opened a ticket
to request this:

https://github.com/openstreetmap/openstreetmap-website/issues/2025

On 11/10/2018 23:21, Tobias Zwick wrote:
> Hey there!
> 
> So, a user of StreetComplete came across the following complicated
> opening hours for a shop (prettified):
> 
> Jun-Sep: Mo-Sa 10:00-18:00;
> Jun-Sep: Su 10:00-12:00;
> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
> Nov-Mar: Sa 10:00-12:00;
> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
> Apr-May: Sa 10:00-12:30;
> Apr-May: Su 10:00-12:00;
> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
> Oct: Sa 10:00-12:30;
> Oct: Su 10:00-12:00
> 
> Unfortunately, this does not fit into the opening_hours value, as this
> is limited to 255 characters. What can we do?
> 
> Is there any generic way to treat an overflowing tag? Perhaps use a
> second key to store the rest, something like (in this case)
> 
> opening_hours=Jun-Sep: Mo-Sa 10:00-18:00;Jun-Sep: Su
> 10:00-12:00;Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
> Nov-Mar: Sa 10:00-12:00;Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;Apr-May:
> Sa 10:00-12:30;Apr-May: Su 10:00-12:00;Oct: Mo-Fr
> 10:00-12:30,15:00-18:00;Oct: Sa 10
> opening_hours_1=:00-12:30;Oct: Su 10:00-12:00
> 
> ?
> 
> Greetings
> Tobias
> 
> ___
> 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 too long for OSM

[Simon Poole]

Am 12.10.2018 um 18:37 schrieb Frederik Ramm:
> Hi,
>
> On 10/12/2018 12:54 PM, Tobias Knerr wrote:
>> I agree that this problem calls for a general solution, as it's not
>> specific to opening hours.
> ...
>
> Or can we afford to just skip mapping that detail?
>
It is all fine and dandy for us to abstractly discuss such things, it is
another to explain to Josephine mapper that no, the opening hours of the
shop you want to map are one character too long and you need to map less
detail. I just don't believe that "map less detail" is a concept that
you will be able to convey to a majority of contributors and trying to
do is likely futile.  The trend is simply the consequence of progressing
from the rough to the detailed.



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

Re: [Tagging] ref of waste_basket on public_transport=platform (Was: Combined waste/recycling bins)

[marc marc]

Le 12. 10. 18 à 19:49, Torbjörn K a écrit :
> After re-reading the wiki on public_transport=platform
> waste_basket=yes

on https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
it's bin=yes (but that doesn't solve the question about the ref)

> waste_basket:ref=B42

Imho this one is better because ref:yz is used as the ref of the stop 
for the network xyz.
Ihope that no network is named waste_basket but it wouldn't be a good 
idea to mix two different types of information in the same syntax

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

[Tagging] ref of waste_basket on public_transport=platform (Was: Combined waste/recycling bins)

[Torbjörn K]

Hi all,

I have another scenario of "combined" waste baskets.

How should I tag the ref of a waste_basket integrated into the information 
pillar of a public_transport=platform?

For separate waste baskets, I'm following the scheme of

amenity=waste_basket
waste=trash
ref=B101

Where the "B101" is printed on the waste basket in huge letters.

Similar, there are waste baskets integrated into the pillar of a bus stop's 
platform also having a "B42" well recognizable.

Up to now, I've created separate nodes very close to the platform node for the 
waste_basket.
After re-reading the wiki on public_transport=platform and re-opening the 
dialog of JOSM's preset, I realized that I should tag it with the platform via

waste_basket=yes

I want to correct my previous error regarding the separate nodes. But how can 
I also tag the waste_basket's ref. Should I do

waste_basket:ref=B42

or

ref:waste_basket=B42

I hope, I haven't kidnapped this thread.

Kind regards
torbjoernk


On Tuesday, October 9, 2018 4:30:58 PM CEST Paul Allen wrote:
> A village a few miles from me (but in a different county) recently got one
> of
> these combined litter/recycling bins:
> https://www.facebook.com/permalink.php?story_fbid=2241627292737699=163202
> 1387031629&__tn__=C-R
> 
> How to tag?  Each of the two sections is around the size of a large
> amenity=waste_basket.  The recycling half is a little smaller than the
> amenity=recycling + recycling_type=container images in the wiki, and they
> are a little smaller than the recycling containers I see around here.
> 
> In any case, if I put both of those tags on a node only one of them would
> be rendered. If I use two nodes that are almost touching, only one of
> them would be rendered.
> 
> These combined disposal things appear to be catching on, so I'd
> expect to see them increasingly replacing existing
> amenity=waste_basket.  It seems to me we probably need a dedicated
> tag that everyone agrees on (no chance of that happening) and then
> convincing the renderer folks to render it (the odds of that happening
> can only be expressed as multiples of the square root of -1).



signature.asc
Description: This is a digitally signed message part.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours too long for OSM

[Frederik Ramm]

Hi,

On 10/12/2018 12:54 PM, Tobias Knerr wrote:
> I agree that this problem calls for a general solution, as it's not
> specific to opening hours.

The "problem" in my eyes is people even wanting to store more than 255
characters in a tag value. Don't do it.

Yes I can see how use cases can be constructed that "need" this but I
think it is perfectly ok that some things cannot be mapped in 100%
detail. Just like we have a limited resolution (of about one
centrimetre) and we're usually happy to approximate a curve with a few
nodes and not 100. Do we *really* need to record when a shop is open
8-18h except on the third Wednesday in even months, if that Wednesday
does not happen to be before or after a public holiday?

Or can we afford to just skip mapping that detail?

> We need to make sure that this can be implemented in a key-agnostic
> manner, though

Why, so that people are free to invent any number of keys to hold
arbitrary length values? Reality check! Tags are supposed to be readable
and writable by human beings. If you find you need > 255 characters to
describe opening hours, then you've left that terrain already. Why not
write Tobias' original example as

H4sIABrJwFsAA/MqzdMNTi2wUvDN1w1OVDA0sDIw0DW0AJLWXF4wueBSmIQRWMIvv0zXN7EIpEkn
pFQnJEPHrQhZhY6CoSmYY46qHGEBxBzHgiKgRCXYcmQTjA10oAZYoKpDNsAYRQLNhf7JJQRNBatB
NxEiiGIaFwARtRivJAEAAA==

then, only takes 179 bytes ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] Opening hours too long for OSM

[OSMDoudou]

> opening_hours="see the web site."

If one doesn't intend to tag the opening hours, then one better uses the 
"website" tag [1] and not the "opening_hours" one.

But it would be a pity one doesn't document opening hours due to a technical 
limitation.

As to improving (thinking out loud here...), couldn't one envisage an 
enhancement to document opening hours with "opening_hours:jan_sep=08:00-12:00" 
and "opening_hours:ph::jan_sep=08:00-16:00" if the place is opened in the 
afternoon only on public holidays, for examples ?

Of course, data consumers must be adapted, but it doesn't break anything or 
doesn't require to change the technical limitation.

And maybe a more radical improvement and definitive solution would be to go 
towards a semantic web [2], so the data doesn't need to be in the OSM database 
but there is a link to query data hosted outside OSM. A bit like for "wikidata" 
tag. [3]

[1] https://wiki.openstreetmap.org/wiki/Key:website
[2] https://en.wikipedia.org/wiki/Semantic_web
[3] https://wiki.openstreetmap.org/wiki/Wikidata



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

Re: [Tagging] opening_hours value question

[John Willis]

Thanks to both Marc & Markus. 

^___^ 

Javbw

> On Oct 12, 2018, at 9:08 PM, Marc Gemis  wrote:
> 
> A useful tool to verify the expressions is
> http://openingh.openstreetmap.de/evaluation_tool/  (is listed on the
> page you link)

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

Re: [Tagging] opening_hours value question

[SelfishSeahorse]

Hi!

On Fri, 12 Oct 2018 at 13:33, John Willis  wrote:
>
> - Can someone type me the necessary tag value for such a monthly calendar 
> dependant item? "Open on the 3rd Saturday from 10am-1pm"

The n-th weekday of the month can be written by appending the number
(1 for 1st, 2 for 2nd, ..., -1 for last) enclosed in square brackets
to the weekday (Mo-Su). Thus 'open on the 3rd Saturday from 10am-1pm'
translates as:

Sa[3] 10:00-13:00

> - also, is there a way to positively define "closed Tuesdays" or similar? It 
> may not be necessary, but it is a common thing to see, hopefully it is easy 
> to tag.

You can:

Tu closed (or synonymously: Tu off)

For example 'open every day from 09:00 to 18:00, but closed on
Tuesdays' can be written:

09:00-18:00; Tu closed

But i personally prefer it the other way around:

We-Mo 09:00-18:00 (or Mo,We-Su 09:00-18:00)

'closed' is only indispensable if you want to override a previously
defined rule, for example:

Mo-Sa 09:00-18:00; PH closed

which means 'open every day from Monday to Saturday from 09:00-18:00
but closed on public holidays'.

> Thanks in advance

You're welcome.

Regards
Markus

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

Re: [Tagging] opening_hours value question

[Marc Gemis]

A useful tool to verify the expressions is
http://openingh.openstreetmap.de/evaluation_tool/  (is listed on the
page you link)

Only open on the third Saturday:   Sa[3] 10:00-13:00
Closed on Tuesdays: Tu off
so e.g. open all week from 9am to 5pm, except Tuesdays:   Mo-Fr
09:00-17:00; Tu off
should be the same as Mo,We-Fr 09:00-17:000

m.
On Fri, Oct 12, 2018 at 1:33 PM John Willis  wrote:
>
> I am really impressed by the key opening hours
> https://wiki.openstreetmap.org/wiki/Key:opening_hours
>
> However, it is just at my threshold of understanding. I can read the examples 
> and adapt it for my needs.
>
> In Japan, I was surprised to see shops that are "closed Tuesdays" or similar. 
> I can tag those. (map the opening hours around the Tuesdays).
>
> But some shops are open "on the 3rd Saturday of the month, rather than being 
> closed. (Sometimes it's the opposite).
>
> - Can someone type me the necessary tag value for such a monthly calendar 
> dependant item? "Open on the 3rd Saturday from 10am-1pm"
>
> I didn't see an example that I could adapt, or perhaps I don't understand 
> that it's the one to use.
>
> - also, is there a way to positively define "closed Tuesdays" or similar? It 
> may not be necessary, but it is a common thing to see, hopefully it is easy 
> to tag.
>
> Thanks in advance
>
> Javbw
> ___
> 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] Dispensing vs vending (Was: Combined waste/recycling bins)

[SelfishSeahorse]

On Thu, 11 Oct 2018 at 11:28, Martin Koppenhoefer
 wrote:
>
> no, I would remove only those from "vending", which are not about vending. 
> E.g. parcels and excrement bags. Those that are about dispensers could get a 
> dispensing tag, those that offer completely different services like parcel 
> drop off should get proper tags that describe the thing.

What about

amenity=parcel_station
parcel_station:send=yes/no
parcel_station:receive=yes/no

?

Regards
Markus

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

[Tagging] opening_hours value question

[John Willis]

I am really impressed by the key opening hours 
https://wiki.openstreetmap.org/wiki/Key:opening_hours

However, it is just at my threshold of understanding. I can read the examples 
and adapt it for my needs. 

In Japan, I was surprised to see shops that are "closed Tuesdays" or similar. I 
can tag those. (map the opening hours around the Tuesdays). 

But some shops are open "on the 3rd Saturday of the month, rather than being 
closed. (Sometimes it's the opposite). 

- Can someone type me the necessary tag value for such a monthly calendar 
dependant item? "Open on the 3rd Saturday from 10am-1pm"

I didn't see an example that I could adapt, or perhaps I don't understand that 
it's the one to use.   

- also, is there a way to positively define "closed Tuesdays" or similar? It 
may not be necessary, but it is a common thing to see, hopefully it is easy to 
tag. 

Thanks in advance

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

Re: [Tagging] Opening hours too long for OSM

[Tobias Knerr]

> Am 12.10.2018 um 01:27 schrieb Simon Poole:
>> We have a number of keys for which the values can easily exceed 255
>> chars besides opening_hours, lane destinations and conditional
>> restrictions are good candidates. Not to mention changeset tags. With
>> other words it is a general problem which should be tackled with a
>> general solution.

I agree that this problem calls for a general solution, as it's not
specific to opening hours. And yes, an extension syntax seems like a
good choice for now. While it's going to be entered manually at first,
it would allow transparent editor support, and possibly an automatic
conversion if any future API revision should support longer values natively.

We need to make sure that this can be implemented in a key-agnostic
manner, though, i.e. by simply concatenating the values. This means: No
key-specific exceptions such as omitting semicolons in an opening hours
string.

I don't have any strong opinions on the syntax, but it should be
something that doesn't clash with existing uses. Tobias' suggestion to
use _2 suffixes would overlap with things like name_2 that are currently
used in the database, so I'd prefer using something else. Maybe double
underscores, or a character such as # that's not typically used in keys
at all?

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

Re: [Tagging] Opening hours too long for OSM

[Simon Poole]

Am 11.10.2018 um 23:47 schrieb Jmapb:
> ...
>  Lengthening the field would be great, but failing that I suppose
> opening_hours_1 is an ok stopgap, though it's unlikely there's any
> end-user software that will look for it. One thing I'd recommend,
> though, is not to end truncate the value mid-clause. In your example,
> I'd probably put all of October in opening_hours_1 so that the
> standard opening_hours tag is correct and parseable on its own.
Just in case somebody jumps on this: using iDs multiple value convention
for this would be a very bad idea (because we are splitting a single
value that needs to be concatenated back together, and you don't want
that to happen with an object that has multiple OH values). Matter of
fact because of iD using the _/n /notation, an extension convention
would likely need to use something else, perhaps #/n/


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

Re: [Tagging] Opening hours too long for OSM

[Warin]

If they are going to make it complex ... retaliate and make it simple?

opening_hours="see the web site."




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

Re: [Tagging] Opening hours too long for OSM

[Tobias Zwick]

>Do we really need to re-declare the month ranges each time? I would 
>think that
>
>   opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar: 
>Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr 
>10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr 
>10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00
>
>...would work just as well. Seems to pass muster at 
>openingh.openstreetmap.de and it's a svelte 251 chars.

Unfortunately, that does not work. According to the specs, every rule must 
specify its own months range. If you don't, that rule applies throughout the 
whole year. E.g.

Jun: Mo-Sa 10:00-18:00; Sun 10:00-12:00

is interpreted as "open Mo-Sa 10-18 o'clock in June, always open on Sunday 
10-12 o'clock".

Tobias 

Am 11. Oktober 2018 23:47:06 MESZ schrieb Jmapb :
>On 10/11/2018 5:21 PM, Tobias Zwick wrote:
>
>> Hey there!
>>
>> So, a user of StreetComplete came across the following complicated
>> opening hours for a shop (prettified):
>>
>> Jun-Sep: Mo-Sa 10:00-18:00;
>> Jun-Sep: Su 10:00-12:00;
>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
>> Nov-Mar: Sa 10:00-12:00;
>> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
>> Apr-May: Sa 10:00-12:30;
>> Apr-May: Su 10:00-12:00;
>> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>> Oct: Sa 10:00-12:30;
>> Oct: Su 10:00-12:00
>>
>> Unfortunately, this does not fit into the opening_hours value, as
>this
>> is limited to 255 characters. What can we do?
>>
>> Is there any generic way to treat an overflowing tag? Perhaps use a
>> second key to store the rest, something like (in this case)
>>
>> opening_hours=Jun-Sep: Mo-Sa 10:00-18:00;Jun-Sep: Su
>> 10:00-12:00;Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
>> Nov-Mar: Sa 10:00-12:00;Apr-May: Mo-Fr
>10:00-12:30,15:00-18:00;Apr-May:
>> Sa 10:00-12:30;Apr-May: Su 10:00-12:00;Oct: Mo-Fr
>> 10:00-12:30,15:00-18:00;Oct: Sa 10
>> opening_hours_1=:00-12:30;Oct: Su 10:00-12:00
>>
>> ?
>>
>> Greetings
>> Tobias
>>
>
>Do we really need to re-declare the month ranges each time? I would 
>think that
>
>   opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar: 
>Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr 
>10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr 
>10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00
>
>...would work just as well. Seems to pass muster at 
>openingh.openstreetmap.de and it's a svelte 251 chars.
>
>This doesn't answer the real question of course, because certainly 
>longer values are possible, especially when exceptions for holidays etc
>
>are tacked on. Lengthening the field would be great, but failing that I
>
>suppose opening_hours_1 is an ok stopgap, though it's unlikely there's 
>any end-user software that will look for it. One thing I'd recommend, 
>though, is not to end truncate the value mid-clause. In your example, 
>I'd probably put all of October in opening_hours_1 so that the standard
>
>opening_hours tag is correct and parseable on its own.
>
>J
>
>___
>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] highway=crossing used on ways

[marc marc]

On 12.10.2018 09:25, Gerd Petermann wrote:
>> In November 2015 I fix nearly all such ways, since then the number increased 
>> again to 488. 

the best is to first try to understand where it comes from: look for 
recent cases, check the editor tag, ask the user how/why he chose this

 >> I wonder if that means that we should accept highway=crossing as a 
shortcut for highway=footway + footway=crossing?

it look like a bad idea (but I also dislike using footway for way 
without any foot-only traffic sign).
I agree that i'ts an error and thanks for the cleanup
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=crossing used on ways

[Tobias Knerr]

On 12.10.2018 09:25, Gerd Petermann wrote:
> In November 2015 I fix nearly all such ways, since then the number increased 
> again to 488. I don't know about iD, but JOSM prints a warning
> when you use this tagging, still many edits were made with JOSM. I wonder if 
> that means that we should accept highway=crossing as a shortcut for 
> highway=footway + footway=crossing?

The highway=crossing tag has been used 2787469 times, according to
Taginfo. So these 488 occurrences on ways don't even represent a tenth
of a percent of the tag's total uses. I don't think this is a strong
reason to change the tag's definition.

Having some amount of "noise" in the data is one of the downsides we
accept with our open tagging model, and in my experience, you will find
a similar amount of non-standard uses, misspellings and other errors for
most tags. However, it's still beneficial to clean up every now and
then, so thank you for your past efforts to fix the errors in the
database and improve the documentation! And it's encouraging to hear
that JOSM validator catches this kind of problem, I hope other editors
will also eventually add more error-checking tools.

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

Re: [Tagging] How to tag named group of named water areas?

[Warin]

On 12/10/18 12:57, Dave Swarthout wrote:
What I'm learning by reading this thread over again is that there is a 
lot of confusion about relations in the context I'm interested in. 
Group or site, whether one or the other will render or, more 
importantly for me at least, is whether the object will be findable in 
a Nominatim search.

Why not bet both ways?
Make both a site and a group relation.

I would hate like hell to have tagged such an object and then not be 
able to locate it. I don't care which method gets the nod on this list 
but in the end I want those features to be findable.


Dave

On Fri, Oct 12, 2018 at 4:40 AM SelfishSeahorse 
mailto:selfishseaho...@gmail.com>> wrote:


On Mon, 8 Oct 2018 at 21:16, Tod Fitch mailto:t...@fitchdesign.com>> wrote:
>
> I had not noticed the existence of the group relation before.
Seems to me that it and the controversial site relation have some
overlap. For the examples I can think of where I think the site
relation works it seems like the group relation would also work.
So, at present and lacking counter-examples, it seems to me that
one of these two relations should go away.

There is quite some difference between the suggested group relation
and a site relation:

A site relation is an own feature that consists of several other
features. (For example, a wind farm cannot be mapped as a power plant
area, but it can be mapped as a power plant site relation with
multiple wind turbines as members.[1])

[1]: https://www.openstreetmap.org/relation/3792332

In contrast, a group relation isn't a separate feature, but just a
name; the feature is already defined for its members. (Like in our
example the two ponds 'Small Pond' and 'Big Pond' that together are
called 'Groble'.)

This is also why a site (or multipolygon) relation wouldn't work
in our example.

Regards
Markus

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



--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com


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



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