Re: [Tagging] breads of bakeries

[bkil]

Unless its website is in a language you don't speak, which contains a
bunch of material except it doesn't list the exact kinds of items sold
there or if it's a small shop that doesn't have any website at all.

On Fri, May 3, 2024 at 1:40 PM Zoon van Michiel  wrote:
>
> What is the benefit of putting the breads a bakery sells into OSM?
> I think all categories of bread that might affect someone's choice to go to a 
> bakery are already present in OSM.
> For example: pastry , diet:gluten_free , diet:lactose_free.
> Otherwise, bread is just bread. I will choose the variety I like best when I 
> get there.
> And if you really want to know what they have, just go to their website which 
> is more likely to be up-to-date anyway.
> On May 3 2024, at 12:36 pm, bkil  wrote:
>
> https://wiki.osm.org/Key:organic or sourdough:organic=yes
>
> On Fri, May 3, 2024 at 9:43 AM Martin Koppenhoefer
>  wrote:
> >
> > I agree for specific types of bread, but maybe we can have "classes" of 
> > breads, if that makes sense. Personally, when going into a bakery I am 
> > interested in the quality of the bread more than the exact type. Typically 
> > I would ask "do you have bread made of natural sourdough" and the answers 
> > will vary from "no" to "yes" to "all our breads are made from natural 
> > sourdough", and I find this information worthy to record (although I am not 
> > doing it yet). Similarly it can be interesting if they sell only bread or 
> > also bread rolls, or also pizza.
> > ___
> > 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

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

Re: [Tagging] breads of bakeries

[bkil]

https://wiki.osm.org/Key:organic or sourdough:organic=yes

On Fri, May 3, 2024 at 9:43 AM Martin Koppenhoefer
 wrote:
>
> I agree for specific types of bread, but maybe we can have "classes" of 
> breads, if that makes sense. Personally, when going into a bakery I am 
> interested in the quality of the bread more than the exact type. Typically I 
> would ask "do you have bread made of natural sourdough" and the answers will 
> vary from "no" to "yes" to "all our breads are made from natural sourdough", 
> and I find this information worthy to record (although I am not doing it 
> yet). Similarly it can be interesting if they sell only bread or also bread 
> rolls, or also pizza.
> ___
> 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] breads of bakeries

[bkil]

When that question occurs to you that you need to work around the 255
character limitation by using an unbounded number of alternative keys,
each coming from an unbounded domain, then it's an indicator that you
are overdoing it. I think it is kind of "okay" to list some key
generic types as long as it fits the 255 character limit (but
honestly, if you are over 64, that's already a smell that you are
using OSM for something that it isn't).

On Fri, May 3, 2024 at 8:12 AM Graeme Fitzpatrick  wrote:
>
>
>
>
> On Thu, 2 May 2024 at 21:21, bkil  wrote:
>>
>> Yes, that would be even better.
>> sells:bread=wholemeal:x;y;wholemeal:z
>
>
> But if you're selling ="white variety-a", "wholemeal variety-a", "multi-grain 
> variety-a", "gluten-free variety-a", then the same for varieties b, c & so 
> on, I can see a 255-character limit approaching rapidly!
>
> 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] breads of bakeries

[bkil]

Yes, that would be even better.
sells:bread=wholemeal:x;y;wholemeal:z

On Thu, May 2, 2024 at 12:39 PM Martin Koppenhoefer
 wrote:
>
> what about
> sells:bread=X;Y;Z (xyz being bread types)
> ___
> 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] breads of bakeries

[bkil]

It is equivalent to stating

shop=bakery
bread=wholemeal:x;y;wholemeal:z

Or the more conventional:
bread=wholemeal_x;y;wholemeal_z

On Thu, May 2, 2024 at 10:19 AM iriman--- via Tagging
 wrote:
>
> Hi
> I've tagged a few bakeries for the bread they sell.
> At first I used semicolon to separate values:
>
> shop=bakery
> bread=x;y;z
>
> Since I'm focused on adding/updating bakeries that are using wholemeal flour 
> in their products, I added a general tag bread:wholemeal=yes.
>
> But this tag was too general because some bakeries sell more than one type of 
> bread and not all of them are made of wholemeal flour. So I decided to 
> separate values with a namespace scheme:
>
> shop=bakery
> bread:x=yes
> bread:y=yes
> bread:z=yes
>
> and expanded this tagging by another tag per bread to know if it's made of 
> wholmeal flour:
>
> bread:x:wholemeal=yes
> bread:z:wholemeal=yes
>
> By this method it's possible to face a long list of tags of bread types for a 
> single bakery and also a lot of namespaced keys in general, as pointed by 
> mueschel:
>
> 
>
> So is it better to retag like first tagging and also add the bread:wholemeal 
> with semicolon-separeted values?
>
> shop=bakery
> bread=x;y;z
> bread:wholemeal=x;z
>
> or any other suggestion?
>
> Thanks
> ___
> 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] Please join the OSM accessibility initiative

[bkil]

Okay, I have now copy & pasted the content of the linked page to the
bottom of this page and translated the five words that were not in
English. I hope that you now consider it good enough to add yourself
to the list of volunteers so we could start working. 🤞 🙏 ☯️

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

Re: [Tagging] Please join the OSM accessibility initiative

[bkil]

Thank you for noting. Former projects are linked from the bottom of the page.

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

[Tagging] Please join the OSM accessibility initiative

[bkil]

We are in desperate need for new tags and tools to improve
accessibility for both contribution and use. Please refer to the
following page for a detailed scope and feel free to add yourself as a
volunteer if you could give us a hand in any of the outlined areas:

https://wiki.osm.org/User:Bkil/OSM_accessibility_initiative

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

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[bkil]

Just a note about your "fact": your phone can roam to any available
network when you are dialing the emergency number. You can even dial
it without a SIM inserted in most countries. Hence why it displays the
text "emergency calls only" in such cases. Circuits towards the
emergency number are also much higher prioritized, so when the line
seems busy otherwise or produces unusable quality and drop-outs,
emergency calls will still be more usable (with sufficient coverage of
course).

On Mon, Aug 7, 2023 at 9:03 PM Colin Smale  wrote:
>
> Two users on the same network standing next to each other can get different 
> results. They may be connected to different base stations. CDMA is a whole 
> other can of worms.
>
> There are so many variables, it's impossible to give detailed data for "cell 
> phone reception at location X". But the original intention of the proposal 
> was limited to campsites and a couple of other specific categories of place, 
> which are often out in the sticks with no coverage. and I can see why it 
> might be useful to have some kind of indication whether you can expect any 
> kind of usable coverage at these locations. This would need to be specific 
> about network, service provider (MVNO) and frequency band at least to be 
> useful.
>
> Some networks allow voice-over-wifi. This might be a useful thing to record - 
> if the location operator provides wifi, you may be able to use "WiFi Calling" 
> even if the cellular coverage is dodgy.
>
> Interesting fact: Mountain rescue organisations often use SIMs from a 
> different country, which are free to roam onto any network with a tiny bit of 
> signal. If you are in your home state you will probably be locked to a 
> specific network.
>
> On 07/08/2023 01:55 BST Mike Thompson  wrote:
>
>
>
>
> On Sun, Aug 6, 2023 at 6:39 PM Evan Carroll  wrote:
>
>
>
> While I don't disagree, that's not an argument for OSM. OSM's job isn't to 
> mitigate real world safety issues caused by technology. It's to map generally 
> useful geographically verifiable things.
>
> I don't understand how cell coverage isn't verifiable - visit the site (e.g. 
> campground) in question, pull out your phone, note how many bars, try to make 
> a call, send a text, use some data (perhaps run a speed test). Yes, it is 
> only good for your carrier, but the carrier should be recorded. Yes, there 
> could be network congestion, or a tower could be out, but we map roads, and 
> they can be congested, or closed due to accidents, flooding, landslides, 
> construction, etc.  In some way, this is getting back to our roots, actually 
> getting out and surveying, rather than just relying on satellite/aerial 
> imagery.
>
> Mike
> ___
> 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] ladders

[bkil]

Think about emergency doors, emergency steps and emergency paths
leading to them all along motorways. Sounds a bit exhaustive to create
a new emergency value for each one. An access restriction sounds more
reasonable.

On Sun, Aug 6, 2023 at 2:33 PM Anne-Karoline Distel  wrote:
>
> Hello all,
>
> in my endeavour to improve the mapping and tagging along waterways, I noticed 
> that there is no approved or documented tag for ladders along shorelines. 
> There is ladder=yes (https://wiki.openstreetmap.org/wiki/Key:ladder), but it 
> seems to be meant for hiking paths and is only rendered on lines. I mapped a 
> few ladder=yes along river shores on OSMAnd, only to discover that I need to 
> add the quay wall to have them rendered which is a lot of extra effort, and 
> cannot be done casually using OSMAnd.
>
> After talking to someone who canoes, they tell me that many of the ones I had 
> mapped along the retaining wall in the town where I live are actually for 
> emergencies, when people fall into the river. They're not meant to be used by 
> swimmers, i.e. they're not actually accessible from the shore with a gate in 
> the fence. Then I'm thinking, should it be emergency=ladder? But what if one 
> isn't sure if they are for boating people or only for emergency situations? 
> So I'm now mapping them as man_made=ladder (and add ladder=yes, so they get 
> rendered), as other people have done in harbour or river situations before 
> me, but only very infrequently.
>
> 30 are mapped as ladder for scuba diving 
> (https://taginfo.openstreetmap.org/keys/scuba_diving%3Aentry%3Aladder#overview),
>  but the average person might not know, if there is no signage. I think a 
> simpler way would be to just use man_made=ladder and add the sport or the 
> emergency tag to the best of ones knowledge.
>
> Anne
>
> ___
> 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] [RFC] Feature Proposal - Extended playground equipment

[bkil]

For coin operated machines, see also:
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Damusement_arcade

On Sat, May 27, 2023 at 3:40 PM Alex  wrote:
>
> > "playground=ride / Is it supposed to include also coin operated ones that 
> > make noise/lights/movements?"
>
> There is already "attraction=kiddie_ride" for them. This are different types 
> of devices, which are also usually not part of playgrounds.
>
>
> > "playground=hammock / These are also placed independently from playgrounds. 
> > Maybe have single tag for both?"
>
> Good idea – TagInfo knows 76x leisure=hammock, but I think we should use this 
> tagging only outside of playgrounds (since hammocks on playgrounds are for a 
> specific target group / accordingly sized / not for public use in the 
> stricter sense). I added a reference to this tagging in the proposal: "For 
> public hammocks in general that are not part of playgrounds resp. intended 
> for this specific target group, there is leisure=hammock in use."
>
>
> > "playground=artwork / playground=steps / why not use regular step tagging?"
>
> If an object is part of the playground design and provides a 
> "play"/playground function, then it should also be identifiable and evaluable 
> via the playground namespace. Otherwise, for example, the stairs of the path 
> network on a playground could no longer be distinguished from those that are 
> part of a structure (which makes data evaluations impossible for this 
> devices/values).
>
> "artwork" is certainly an edge case here, but this value refers primarily to 
> (sometimes very small, discrete) decorative playground elements, most of 
> which I would not wish to spam the tourism=artwork namespace. (The sample 
> picture in the proposal is a very "significant" one compared to what else is 
> out there.) Maybe they don't even fit the broader definition of 
> "tourism=artwork" because of it's limited public usability ("A tag for public 
> pieces of art; typically being staged in the physical public domain, usually 
> outside and accessible to all." – see also hammock example)
>
> What do you think?
>
>
> Am 27.05.23 um 10:25 schrieb Mateusz Konieczny via Tagging:
>
> playground=ride
>
> Is it supposed to include also coin operated ones that make 
> noise/lights/movements?
>
> https://www.google.pl/maps/@50.054966,19.8545417,3a,15.3y,207.67h,84.22t/data=!3m7!1e1!3m5!1sHED2kF0PByYJyi9CYVjXXw!2e0!5s20110801T00!7i13312!8i6656?entry=ttu
> caught one
>
> re: playground=hammock
>
> These are also placed independently from playgrounds. Maybe have single tag 
> for both?
>
> re: playground=artwork
> why not just normal artwork tagging?
>
> "If it has a significant art relevance, consider also adding tourism=artwork. 
> "
>
> Note that vast majority of tourism=artwork has no art relevance and 
> definitely no
> significant art relevance
>
> re: playground=steps
> why not use regular step tagging?
>
> (the same goes for some other tags)
>
>
> May 27, 2023, 08:46 by supap...@riseup.net:
>
> Hi all,
>
>
>
>
> anyone who maps playground equipment from time to time might be  familiar 
> with the issue: The playground values from the wiki  represent only a 
> small range of possible playground devices, for  many others you have to 
> get creative, come up with your own tags  or dig through TagInfo to see 
> how other mappers might have mapped  a device.
>
>  As a group of mappers who regularly map playgrounds, we are  proposing 
> more values to the list of documented playground  equipment to better map 
> typical devices that had no documented  value before.
>
>  > https://wiki.openstreetmap.org/wiki/Proposal:Extended_playground_equipment
>
>  Please discuss this proposal on its Wiki Talk page.
>
>
>
>
>
>
> Best,
>  Alex for the group of proposal authors
>
>
>
>
>
>
> ___
> 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

[Tagging] Tag which restaurant or cafe allows bringing your own food or drink?

[bkil]

Certain allergies or dietary restrictions preclude one from consuming
a meal prepared by conventional amenities, or if the find the drink
offering insufficient (for example you can rarely find milk or
vegetable juice at most places). Or you would like to bring some
snacks from home to a pub that only offers drinks (salty snacks may
build your thirst and make you buy more drinks).

Such a customer may still want to enjoy the company of their friends
and perhaps want to play a game together (see: gaming cafe). This can
happen when 1-2 such users accompany 4 others who do want to purchase
meal on site.

It does incur costs for the restaurant if not all patrons pay, so it
can also be tagged whether it is allowed, and if it is, whether it is
expected or mandated to pay an entry fee or to purchase something else
instead on the menu as compensation (drinks, dessert). Such a
restaurant may provide a microwave oven for reheating - this is common
for fast food restaurants (canteens) catering to office workers who
usually bring their own food to work.

In certain cases, government regulations may mandate signing a waiver
by such attendee that any and all ill effects from consuming the meal
shall be the responsibility of the person.

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

Re: [Tagging] Best practices for creating a categorical key=value

[bkil]

Can you ring the doorbell and purchase or order something from that
office? If yes, you could consider it to be a kind of shop. If it is
only a reseller, consider:

shop=trade + trade=building_supplies + sells=precast_concrete
or even shop=doityourself.

If it is manufacturing the said goods, consider:

man_made=works + product=precast_concrete

https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dworks
https://wiki.openstreetmap.org/wiki/Key:industrial

On Wed, Jan 18, 2023 at 4:28 PM Daniel Bégin  wrote:
>
> I want to locate and identify the offices of different construction companies 
> in my area. I found that office=construction_company would be a good start 
> but I also want to identify the type of construction company, what it builds, 
> its specialty. Unfortunately, I couldn’t find any key that would allow me to 
> do this (construction=* couldn't be an option). What if I create a new key 
> that matches an often used pattern based on a higher hierarchical tag value? 
> Would it be right?
>
>
>
> For example, the mapping of a company that produces and installs precast 
> concrete could be tagged as…
>
>
>
> office=construction_company
>
> construction_company=precast_concrete
>
>
>
> but I have my doubts on the best way to do it. Any suggestion?
>
> Thanks,Sent from Mail for Windows
>
>
>
> ___
> 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 - Voting - Healthcare 1.1 - General comment

[bkil]

That's an interesting problem. Does the mediawiki API support CORS? If
yes, we could easily create a very simple third party GUI form for it
just for voting or adding a new comment on the talk page.

On Sun, Nov 6, 2022 at 1:31 PM ael via Tagging
 wrote:
>
> A very general comment:-
>
> I very seldom consider voting on proposals, but I did want to look over
> this one.
>
> However, when I logged into the wiki, there seemed to be no easy way
> to find current proposals nor to identify those with active voting.
> Perhaps if I had kept a copy of the initial messages in this thread,
> I would have found an URI.
>
>
> I would also comment that when I had decided to vote on another
> proposal some time ago, it was not an easy process and seemed to involve
> editing a page in what was not an immediately obvious way. I gave up for
> lack of time. Note that I do program in several languages, so I
> possibly have more expertise and experience than many mappers.
>
> There are only a tiny number of people who vote on these proposals,
> and while there is maybe a small audience on this list who even know,
> I wonder how many even then are put off by the non obvious voting
> process. Or is it just me?
>
> ael
>
>
> ___
> 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 - Approved - migration to use belarusian as default language in Belarus for tagging

[bkil]

Why did I get a private message about this?

On Mon, Oct 10, 2022 at 11:19 PM Paveł Tyślacki
 wrote:
>
> Hey
>
> Proposal to use belarusian as default language in Belarus for tagging were 
> approved by majority: (belarusian) 
> https://wiki.openstreetmap.org/wiki/Be:Belarus_language_issues/Migration_proposal
>
> next steps regarding proposal:
> - update documentation
> - notify major users about new rules
> - in month make migration
> - for 3-6 month actively support users to use new rules
>
> ___
> 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 - Move proposal voting from wiki to the new forum

[bkil]

What about bridging them together?

On Sat, Sep 24, 2022 at 12:00 PM Yves via Tagging
 wrote:
>
>
>
> Le 24 septembre 2022 10:47:53 GMT+02:00, Mateusz Konieczny via Tagging 
>  a écrit :
> >3) https://community.openstreetmap.org/t/votes-on-discourse/508
> >strongly encourages voting without comment, further moving it
> >from commenting with feedback to just a pure vote
> >
> >Is there a mode that requires and records comments from "no" votes?
> >
> >4) It divorces proposal content and vote making more likely that
> >people will vote without even looking at proposal
> >
>
> 3) and 4) above are serious arguments.
>
> I would be cautious about voting: the wiki proposal process is a wiki + 
> tagging list process which has certainly its flaws, and that is sanctioned in 
> some way by voting on the wiki.
> I think the new community site should be more integrated in the process 
> before talking about voting.
> Yves
>
> ___
> 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] Tagging becoming more mature

[bkil]

Although, I understand that there could exist some special meanings of
the word "park":
https://en.wiktionary.org/wiki/park

The most widely understood meaning also documented in Wikipedia seems
to be consistent:
https://en.wikipedia.org/wiki/Park

And anyway, terms must be understood in their GB sense within
OpenStreetMap as declared by the project.

On Thu, Nov 12, 2020 at 3:36 AM stevea  wrote:
>
> What I've said here (about ponds) is something I think a lot of us have long 
> recognized:  syntactic design of the sort that Joseph originally expressed 
> concern about, where maybe we deprecate a tag, somebody disagrees, somebody 
> else proposes differences, yet somebody else says "the subject is richer than 
> that and deserves a full design..." is hard work.
>
> There is a fair bit of tagging in OSM which might be described as "poor in 
> hindsight" that works (and in some cases worked) OK for a while, but when 
> brought into the larger world, begins to crack around its edges.  Some of 
> this is due to linguistic differences around the world (e.g. leisure=park 
> conflicting with the use of "park" in US English), some of this is due to 
> hasty and poor syntactic design of the tag in the first place.  Some of this 
> is due to reasons I'm not mentioning, as maybe we don't even (yet) fully 
> understand why some of what we do might not be quite good enough to grow into 
> our future.
>
> While I'm not proposing any specific fixes to these longer-term challenges to 
> OSM, I am saying that good syntactic design (and when appropriate, formal 
> proposals to implement them) is an important element to minimizing the risks 
> of how we've been doing this during our first couple of decades.  As OSM 
> grows from adolescence into adulthood, (16 years and growing!) I believe we 
> can keep our "plastic tagging where we can coin a new key" so it remains 
> intact, as such free-form tagging is an important flexibility built into the 
> project.  However, as we mature, become more worldwide (linguistically 
> diverse, accommodating similar-yet-different aspects of many things, both in 
> slight naming differences and slight actual differences...) we must consider 
> more mature methods to implement well-designed aspects like sound, 
> future-proof tags.  This includes both improvements to existing tags as well 
> as new tags.
>
> I love the spirited discussions that happen here and other places in OSM 
> where a variety of voices come together to discuss new ideas, new tags and 
> new ways to map:  may this wonderful spirit live on forever in our project.  
> Yet, we can also simultaneously recognize that there are "grown-up" methods 
> to designing "industrial strength, world-ready" aspects to the project that 
> will last and last far into our future.  Let's find ways to keep both going 
> strong, whether it's moving more to formal proposals (or not), other more 
> formal methods (or not) and keeping great, inclusive, respectful dialog alive 
> as we do so.
>
> SteveA
> ___
> 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] Feature Proposal - Voting - Objects generating audible cues

[bkil]

https://wiki.openstreetmap.org/wiki/Proposed_features/Objects_generating_audible_cues
is open for voting now.

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

Re: [Tagging] Feature Proposal - RFC - Objects generating audible cues

[bkil]

Surely you could always refine tagging according to your needs (like
with dog:species=Rottweiler). Although, I think the exact species of
canines could change much more often due to replacement and/or moving.
You probably also need to be an expert on the topic to tell apart
hundreds of purebred types and their voices, and then handle all the
impure ones as well.

You could also consider mapping their count, because that is pretty
easy to tell (1-3).

Anyway, I probably wouldn't overload the audible*=* scheme with
this. It seems like many are interested in this. Marking it may
involve hazard=dog, surveillance:type=guarddog, guard:type=dog or
guard_dog=yes.
https://taginfo.openstreetmap.org/tags/hazard=dog#overview
https://taginfo.openstreetmap.org/tags/surveillance%3Atype=guarddog
https://taginfo.openstreetmap.org/tags/guard%3Atype=dog
https://taginfo.openstreetmap.org/keys/guard_dog#values

Funny:
https://taginfo.openstreetmap.org/keys/guard_dog%3Anoisy#values
What about guard_dog=invisible?

So my question is still of a mapping ethics nature: would we be doing
any harm if we mapped whether a given private home has visible or
audible guard animals? (Sirens and other security measures aren't that
interesting from an ear-mapping perspective)



On Thu, Oct 15, 2020 at 12:32 AM Graeme Fitzpatrick
 wrote:
>
>
>
>
> On Thu, 15 Oct 2020 at 01:10, bkil  wrote:
>>
>> "hearing a dog" could be one of them.
>
>
> But aren't you then going to need to differentiate the sounds?
>
> # 18 has a Chihuahua (yap yap yap yap yap yap yap yap) while # 23 has a 
> Rottweiler (WOOF)
>
> 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] Feature Proposal - RFC - Objects generating audible cues

[bkil]

A person navigating with a cane can use multiple cues on any given
section, and "hearing a dog" could be one of them. If two houses are
marked at 33% and 66% of a block as having dogs and only one of them
barks at you at a given occasion, you should still be able to
integrate this cue among others because you are counting your steps
and experiencing elapsed time at the same time (along with observing
flower beds, surface texture, rainfall drains, driveways, fence type,
trees, street cabinets and whatnot). The more cues you can lean on the
better.

Also if they navigate using their seeing eye dog, it may also help
them keep good distance from such fences and to not get startled when
the inside and outside dogs start to vocalize with each other. Of
course I've seen many lazy dogs all over the place, but I've seen many
more who aren't provided with enough entertainment so they go an extra
mile to bark at you (while wagging their tails).

Looking at it from a security perspective: it is very common to place
a sign on your fence to the effect of `beware of vicious dog` even
though I have never seen or heard any dog there. It is so common that
I would say no dog was ever found there in 50% of the cases.

According to my mapping experience, dogs live a really long time (and
they even multiply), and having a dog at a house is much much more
stable than some commonly tagged properties. A "dog person" will
usually replace a dog after it dies, hence even if a given dog stays
for 5 years, the "dogness" of a property usually stays until the owner
stays the same. In 99% of the cases, dogs are present for multiple
years, while transport stops, road surfaces, or even geometry of
tracks can change every year.

For those who have no visual impairment at the moment (but this could
change for the worse in the blink of an eye!), it is more desirable to
hike, walk your puppy or push your baby stroller on calmer streets
that have the least amount of barking.

On Wed, Oct 14, 2020 at 4:42 PM Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> > On 14. Oct 2020, at 16:22, bkil  wrote:
> >
> > It has been raised on a private discussion if we could mention whether
> > a private house or an industrial site has a guard dog that is easily
> > identifiable by its barking.
>
>
>
> if you only hear it this could still be a fake barking from loudspeakers ;)
>
> If you are going to tag it, it should be distinguishable between “have seen a 
> dog” and “have heard a dog”
>
> 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] Feature Proposal - RFC - Objects generating audible cues

[bkil]

It has been raised on a private discussion if we could mention whether
a private house or an industrial site has a guard dog that is easily
identifiable by its barking. It is my viewpoint that from a mapping
ethics standpoint, we should not map this because it may compromise a
home's security. What do you think?

On Sat, Sep 26, 2020 at 12:01 PM bkil  wrote:
>
> I welcome your comments on the following proposal:
>
> Those with vision impairment should also have the right to explore and
> map their surroundings in ways appropriate for them. We should have a
> unified way to specify the kind of noise that is generated by an
> object. The most useful ones are those which are right beside a
> footway and which is clearly audible when walking by.
>
> The existing documentation for man_made=street_cabinet should be
> updated to deprecate sound=* and the few existing OSM occurrences for
> this tag combination along with power=* should be changed to use
> audible=*.
>
> The following mistaggings of traffic_signals:sound=* should also be
> eliminated manually: sound=* (in the right combination),
> crossing:signals:sound=*, crossing:sound=*.
>
>
> See the proposal page for details:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Objects_generating_audible_cues

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

Re: [Tagging] meaning of highway=crossing + bicycle=no

[bkil]

We always use it on nodes to mark a crossing where you must dismount. Not
very common on ways around here.

On Mon, Oct 5, 2020 at 11:22 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> I always understood
> highway=crossing + bicycle=no
> tagging to mean "you cannot use this crossing to cross road while cycling,
> it does not affect legality of cycling on the road"
>
> Used when
> (1) cycleway or footway with allowed cycling is interrupted by
> crossing where cyclists are obligated to dismount
> (2) there is cycleway/footway with allowed cycling on both sides of
> road, it is tagged as cycleway:left/cycleway:right/cycleway:both
> and there is pedestrian only crossing at some point
> (cyclist cannot switch sides without dismounting)
>
> Or is it a tagging that means "you must dismount while either
> using crossing and while cycling on the road",
> making this basically useless.
>
> I am asking as there was discussion on OSM Wiki between me
> and one other person, with recent edits to OSM Wiki that seems
> to misrepresent real tagging practice.
>
> I am considering reverting them, but I wanted to ask here whatever
> what I think about tagging practice matches what other consider
> as consensus.
>
> See
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag:highway%3Dcrossing&action=history
>
> https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dcrossing#highway.3Dcrossing_with_bicycle.3Dno
> for OSM Wiki links
> ___
> 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] Feature Proposal - RFC - Objects generating audible cues

[bkil]

I welcome your comments on the following proposal:

Those with vision impairment should also have the right to explore and
map their surroundings in ways appropriate for them. We should have a
unified way to specify the kind of noise that is generated by an
object. The most useful ones are those which are right beside a
footway and which is clearly audible when walking by.

The existing documentation for man_made=street_cabinet should be
updated to deprecate sound=* and the few existing OSM occurrences for
this tag combination along with power=* should be changed to use
audible=*.

The following mistaggings of traffic_signals:sound=* should also be
eliminated manually: sound=* (in the right combination),
crossing:signals:sound=*, crossing:sound=*.


See the proposal page for details:
https://wiki.openstreetmap.org/wiki/Proposed_features/Objects_generating_audible_cues

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

Re: [Tagging] [OSM-talk] "Limitations on mapping private information" - wiki page

[bkil]

Not until the page is finalized and accepted by the community. Until
then, it is a draft, and it is frowned upon to mix such controversial
drafts into the main namespace

On Wed, Sep 16, 2020 at 4:38 PM Jez Nicholson  wrote:
>
> "why this page resides in the main
> namespace and not in the responsible proposer's user space?" - it's a wiki, 
> we are generally a libertarian group, there are no restrictions on creating a 
> page other than wanting to be relevant. I personally find it relevant.
>
> On Wed, 16 Sep 2020, 14:47 bkil,  wrote:
>>
>> Could someone perhaps clarify why this page resides in the main
>> namespace and not in the responsible proposer's user space?
>>
>> > Do not name individuals in OpenStreetMap tags, unless their name is on a 
>> > business sign posted towards the street, or part of the business name and 
>> > available in public records.
>> >
>>
>> What if the name of the operator is printed on each receipt when you
>> shop there or a certificate is placed on the wall that shows it? We
>> usually add that to operator=*.
>>
>> Indeed I think that the article confuses mapped things that are
>> worthless and mapped things that are dangerous (according to GDPR).
>>
>> For example, the reason why we don't map private washing machines is
>> that its location and capacity is not information that is in public
>> interest (hence why it is not a POI). Another reason that it fails the
>> verifiability criterion: if I want to check that the position and type
>> information of the washing machine is still accurate, I need to ring
>> the doorbell and be invited in to see for myself, but it is not
>> realistic that an owner would invite dozens of potentially malicious
>> random people into their house just for this.
>>
>> Even if the object would be visible from the outside, it is of no use
>> to 99.% of individuals if the owner does not let me do my laundry
>> there. If a TV is fully and clearly visible from the outside through
>> the window, it _may_ serve a public utility of entertainment if you
>> can lip read, but you need to ring the doorbell each time you want to
>> switch channels...
>>
>> Private parking and driveways are acceptable because it hints at which
>> way the entrance is - helping delivery personal and guests alike. I've
>> mapped some very interesting hilly terrain where this can be
>> especially useful, as roads were pretty dense and the road towards
>> where the entrance is was not trivial and a failed guess could cost
>> you a few more minutes of walking or driving for each house.
>>
>> Private swimming pools aren't that interesting but people seem to
>> enjoy tracing them. Maybe in case of emergency they could be used as a
>> nearby water source by the fire brigade?
>>
>> From the privacy section, am I reading correctly that you suggest that
>> you find it acceptable to map each tomb in a cemetery by name?
>>
>> I think a lot of considerations are missing in this article other than
>> those stemming from the GDPR, like military and national
>> considerations. You also do not mention that there exist regions where
>> mapping activities are forbidden by the law and punishable by prison
>> sentence. And anyway other than describing "what is worthless to map",
>> I think you are trying to basically gather "mapping ethics", and maybe
>> this should be better be done in Wikipedia because it does not only
>> concern OpenStreetMap, but any mapping provider.
>>
>> On Wed, Sep 16, 2020 at 3:15 PM Niels Elgaard Larsen  wrote:
>> >
>> > Mateusz Konieczny via talk:
>> > > https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
>> > >
>> > > Do you think that this page is a good description of community consensus?
>> > >
>> > > The page has
>> > > "This page is under development (May 2020). It may not yet reflect 
>> > > community consensus."
>> > > and I would like to check whatever it matches community consensus well 
>> > > or mismatches it.
>> >
>> >
>> >
>> > I think we should avoid language such as "There is no need to split 
>> > residential
>> > landuse into individual plots".
>> >
>> > Of course there is a need for someone somewhere to tag just about 
>> > everything.
>> > For example, if you want to buy a house you would want to see where the 
>> > plot is.
>> >
>> > Thi

Re: [Tagging] [OSM-talk] "Limitations on mapping private information" - wiki page

[bkil]

You misunderstood me. I don't _care_ about private swimming pools and
I don't think they are public interest. I don't think that mapping
them can get us trouble with GDPR. You see that's my problem with a
page like this: it blurs the line between ethics, legals and
recommending to map things that add the greatest value to the largest
number of users. I think these should have their separate pages.

On Wed, Sep 16, 2020 at 4:39 PM Paul Allen  wrote:
>
> On Wed, 16 Sep 2020 at 14:47, bkil  wrote:
>>
>>
>> Private swimming pools aren't that interesting but people seem to
>> enjoy tracing them. Maybe in case of emergency they could be used as a
>> nearby water source by the fire brigade?
>
>
> Depending on the terrain, they may be visible and serve as navigational
> references.  "If I'm where I think I am, there should be a house with a
> swimming pool in that direction."
>
> Also, swimming pools are not people and have no right to privacy under
> the GDPR.
>
> Also, aerial imagery exists.  People can look at such imagery in Google
> Maps, Bing Maps, etc.  If you don't want people knowing you have
> a swimming pool then build a cover over it or bribe all the aerial imagery
> companies to doctor their images so your swimming pool isn't visible.
>>
>>
>> From the privacy section, am I reading correctly that you suggest that
>> you find it acceptable to map each tomb in a cemetery by name?
>
>
> I've mapped a few tombs by name.  They're large, elaborate, and
> (most importantly) are "listed buildings" meaning they are of
> cultural significance and protected by law.  I wouldn't bother
> mapping any other tombs in a cemetery, not unless I ran out
> of things to map (that isn't going to happen).
>
>> I think you are trying to basically gather "mapping ethics", and maybe
>> this should be better be done in Wikipedia because it does not only
>> concern OpenStreetMap, but any mapping provider.
>
>
> And what if OSM feels those generic mapping ethics are too lax?
> We'll end up with our own, one way or another.  Even if it's only
> guidance as to how to interpret generic ethics in the context of
> the OSM mapping model.
>
> --
> 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] [OSM-talk] "Limitations on mapping private information" - wiki page

[bkil]

Could someone perhaps clarify why this page resides in the main
namespace and not in the responsible proposer's user space?

> Do not name individuals in OpenStreetMap tags, unless their name is on a 
> business sign posted towards the street, or part of the business name and 
> available in public records.
>

What if the name of the operator is printed on each receipt when you
shop there or a certificate is placed on the wall that shows it? We
usually add that to operator=*.

Indeed I think that the article confuses mapped things that are
worthless and mapped things that are dangerous (according to GDPR).

For example, the reason why we don't map private washing machines is
that its location and capacity is not information that is in public
interest (hence why it is not a POI). Another reason that it fails the
verifiability criterion: if I want to check that the position and type
information of the washing machine is still accurate, I need to ring
the doorbell and be invited in to see for myself, but it is not
realistic that an owner would invite dozens of potentially malicious
random people into their house just for this.

Even if the object would be visible from the outside, it is of no use
to 99.% of individuals if the owner does not let me do my laundry
there. If a TV is fully and clearly visible from the outside through
the window, it _may_ serve a public utility of entertainment if you
can lip read, but you need to ring the doorbell each time you want to
switch channels...

Private parking and driveways are acceptable because it hints at which
way the entrance is - helping delivery personal and guests alike. I've
mapped some very interesting hilly terrain where this can be
especially useful, as roads were pretty dense and the road towards
where the entrance is was not trivial and a failed guess could cost
you a few more minutes of walking or driving for each house.

Private swimming pools aren't that interesting but people seem to
enjoy tracing them. Maybe in case of emergency they could be used as a
nearby water source by the fire brigade?

From the privacy section, am I reading correctly that you suggest that
you find it acceptable to map each tomb in a cemetery by name?

I think a lot of considerations are missing in this article other than
those stemming from the GDPR, like military and national
considerations. You also do not mention that there exist regions where
mapping activities are forbidden by the law and punishable by prison
sentence. And anyway other than describing "what is worthless to map",
I think you are trying to basically gather "mapping ethics", and maybe
this should be better be done in Wikipedia because it does not only
concern OpenStreetMap, but any mapping provider.

On Wed, Sep 16, 2020 at 3:15 PM Niels Elgaard Larsen  wrote:
>
> Mateusz Konieczny via talk:
> > https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
> >
> > Do you think that this page is a good description of community consensus?
> >
> > The page has
> > "This page is under development (May 2020). It may not yet reflect 
> > community consensus."
> > and I would like to check whatever it matches community consensus well or 
> > mismatches it.
>
>
>
> I think we should avoid language such as "There is no need to split 
> residential
> landuse into individual plots".
>
> Of course there is a need for someone somewhere to tag just about everything.
> For example, if you want to buy a house you would want to see where the plot 
> is.
>
> This is not about needs, but about privacy, and maybe data quality.
>
>
> --
> Niels Elgaard Larsen
>
> ___
> 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] Link to stream of webcam

[bkil]

The problem with url=* is (as per my talk page comment) that you can tag
the camera as contact:webcam (or whatever, as said I don't like it either,
I'm just using it), while you may tag the operator's website as
contact:website without causing any confusion. If you only had a single
link in url=*, how would you know whether it is for the operator or for the
camera stream?

On Fri, Sep 4, 2020 at 9:47 PM Paul Allen  wrote:

> On Fri, 4 Sep 2020 at 20:40, bkil  wrote:
>
>> "contact" can mean one-way contact, as in "on what channel does this POI
>> broadcast information for us?" Note that except contact:email, most
>> other links are also used oneway in 99% of the time.
>>
>
> In my dialect of English there is an expectation that there is at least a
> possibility
> of a conversation.  At the very least, the possibility that a human might
> become
> aware of some issue I'd raised.
>
> A surveillance cam isn't a "contact" and contact:* is STILL a stupid idea.
>
> Oh, and what's wrong with url=*?  Especially as the wiki page endorses it.
>
> --
> 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] Link to stream of webcam

[bkil]

"contact" can mean one-way contact, as in "on what channel does this POI
broadcast information for us?" Note that except contact:email, most
other links are also used oneway in 99% of the time.

On Fri, Sep 4, 2020 at 9:34 PM Paul Allen  wrote:

> On Fri, 4 Sep 2020 at 20:13, bkil  wrote:
>
>> I also raised this question some years ago on the talk page but went with
>> the flow and continued to tag webcams with contact:webcam=*. I think it
>> makes more sense if you see a static gallery of a venue specified under
>> contact:flickr=*, prerecorded videos under contact:youtube=* and you can
>> also check out the traffic in real time under contact:webcam=* (for example
>> on a beach or a pub to decide whether it would be a suitable time to give a
>> visit).
>>
>
> None of those come under what I would consider "contact"  Some youtube
> channels permit comments on videos but they may be ignored by the
> creator.
>
> I think the contact namespace is entirely without justification in the
> first place.  Adding things that aren't mechanisms for contacting
> somebody merely compounds the stupidity.
>
> There are reasons for having the addr: namespace.  It groups together
> elements which may not be meaningful unless considered as a group.
> Knowing the house number is not much good without knowing the
> street and town (in the UK the postcode and house number suffice,
> but you need both).
>
> Are you unable to look at somebody's facebook page unless you also
> know the twitter account?  Do you need the instagram as well?  No,
> because they're independent.
>
> I've yet to see any valid reason for having a contact: namespace and
> using it for surveillance cams is the least valid reason I've seen
> yet.
>
> --
> 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] Link to stream of webcam

[bkil]

I also raised this question some years ago on the talk page but went with
the flow and continued to tag webcams with contact:webcam=*. I think it
makes more sense if you see a static gallery of a venue specified under
contact:flickr=*, prerecorded videos under contact:youtube=* and you can
also check out the traffic in real time under contact:webcam=* (for example
on a beach or a pub to decide whether it would be a suitable time to give a
visit).

On Fri, Sep 4, 2020 at 8:42 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 4. Sep 2020, at 20:29, Jmapb  wrote:
> >
> > If I were proposing a tag, I'd probably say `camera:url` or
> `webcam:url`. But `contact:webcam` is documented and in popular use all
> over the world.
>
>
> I am not saying a webcam is never a means to contact someone, but it isn’t
> a suitable tag for the cam itself/a surveillance camera
>
> It is used 1800 times currently, that’s significant but not sure it is
> also „popular“.
>
> 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] Tagging multiple images on one object

[bkil]

I would assume that this is unwanted based on my above citations from
their scope document. Was this not your reading on this question? Although,
if we ask, they _may_ decide to change their scope based on our needs, but
as estimated, this would greatly increase their expenses.

On Thu, Aug 27, 2020 at 12:23 PM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> I would ask on Commons whatever it would be acceptable, I would not just
> assume that
> this is unwanted.
>
> Aug 27, 2020, 12:18 by bkil.hu...@gmail.com:
>
> Then there's OpenTrailView as a viable alternative (neither Mapillary, nor
> OpenStreetCam has a free server component), although in the long term, I
> think we should follow an IPFS, P2P or federated-systems route to scale
> costs.
>
> I don't feel it's fair to overload Commons by shifting the costs of all of
> our street level imagery to them. If we for whatever reason wanted to stick
> to a centralized solution, OSMF should be the one paying the costs, but
> then we would pay dearly (someone on Reddit did some estimates).
>
> On Thu, Aug 27, 2020 at 6:59 AM Thibault Molleman <
> thibaultmolle...@gmail.com> wrote:
>
> - I'm doubtful of the future of openstreetcam
> - some people don't like Facebook to the point where they don't want to
> use mapillary  so we need to have an alternative
>
>  And that still doesn't solve the problem of not having a system to put
> multiple images into one tag
>
> Cheers
> Thibault
>
> On Thu, Aug 27, 2020, 00:21 bkil  wrote:
>
> Have you considered uploading these to OpenStreetCam, Mapillary or
> whatever comes after OSM migrates away from that one?
>
> On Wed, Aug 26, 2020 at 11:37 PM Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>
>
> sent from a phone
>
> > On 26. Aug 2020, at 15:21, Jake Edmonds via Tagging <
> tagging@openstreetmap.org> wrote:
> >
> > Sorry, I meant that images of generic drinking fountains can go in
> ‘Drinking fountains in ’ and only need one image linked to the
> node.
> > A unique fountain deserves its own category
>
>
> I named the fountains as an example where I see one image as sufficient.
> Of course you could also make tens of each, with details, from all sides
> and so on, but for me 1 is completely ok, serves to give an impression.
>
> On the other hand, city gates should have at least 2, one from the outside
> and one from the inside, in those cases I have recently seen, and you can’t
> do it with the image tag (a category for every individual city gate seems
> overkill too in many cases).
>
> 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
>
> ___
> 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] Tagging multiple images on one object

[bkil]

Then there's OpenTrailView as a viable alternative (neither Mapillary, nor
OpenStreetCam has a free server component), although in the long term, I
think we should follow an IPFS, P2P or federated-systems route to scale
costs.

I don't feel it's fair to overload Commons by shifting the costs of all of
our street level imagery to them. If we for whatever reason wanted to stick
to a centralized solution, OSMF should be the one paying the costs, but
then we would pay dearly (someone on Reddit did some estimates).

On Thu, Aug 27, 2020 at 6:59 AM Thibault Molleman <
thibaultmolle...@gmail.com> wrote:

> - I'm doubtful of the future of openstreetcam
> - some people don't like Facebook to the point where they don't want to
> use mapillary  so we need to have an alternative
>
>  And that still doesn't solve the problem of not having a system to put
> multiple images into one tag
>
> Cheers
> Thibault
>
> On Thu, Aug 27, 2020, 00:21 bkil  wrote:
>
>> Have you considered uploading these to OpenStreetCam, Mapillary or
>> whatever comes after OSM migrates away from that one?
>>
>> On Wed, Aug 26, 2020 at 11:37 PM Martin Koppenhoefer <
>> dieterdre...@gmail.com> wrote:
>>
>>>
>>>
>>> sent from a phone
>>>
>>> > On 26. Aug 2020, at 15:21, Jake Edmonds via Tagging <
>>> tagging@openstreetmap.org> wrote:
>>> >
>>> > Sorry, I meant that images of generic drinking fountains can go in
>>> ‘Drinking fountains in ’ and only need one image linked to the
>>> node.
>>> > A unique fountain deserves its own category
>>>
>>>
>>> I named the fountains as an example where I see one image as sufficient.
>>> Of course you could also make tens of each, with details, from all sides
>>> and so on, but for me 1 is completely ok, serves to give an impression.
>>>
>>> On the other hand, city gates should have at least 2, one from the
>>> outside and one from the inside, in those cases I have recently seen, and
>>> you can’t do it with the image tag (a category for every individual city
>>> gate seems overkill too in many cases).
>>>
>>> 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
>>
> ___
> 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] Tagging multiple images on one object

[bkil]

Have you considered uploading these to OpenStreetCam, Mapillary or whatever
comes after OSM migrates away from that one?

On Wed, Aug 26, 2020 at 11:37 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 26. Aug 2020, at 15:21, Jake Edmonds via Tagging <
> tagging@openstreetmap.org> wrote:
> >
> > Sorry, I meant that images of generic drinking fountains can go in
> ‘Drinking fountains in ’ and only need one image linked to the
> node.
> > A unique fountain deserves its own category
>
>
> I named the fountains as an example where I see one image as sufficient.
> Of course you could also make tens of each, with details, from all sides
> and so on, but for me 1 is completely ok, serves to give an impression.
>
> On the other hand, city gates should have at least 2, one from the outside
> and one from the inside, in those cases I have recently seen, and you can’t
> do it with the image tag (a category for every individual city gate seems
> overkill too in many cases).
>
> 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] Tagging multiple images on one object

[bkil]

Didn't we have an OSM tool in the past that showed points with broken
links? (Also I think the citations I've given earlier a few hours ago
should clear up what should or should not be deleted - by policy they
_should_ delete the lower quality image if a better quality image is also
available)

On Wed, Aug 26, 2020 at 8:49 PM Paul Allen  wrote:

> On Wed, 26 Aug 2020 at 19:39, Mateusz Konieczny 
> wrote:
>
>>
>> In practice you need horrific image quality,
>> to the point of unasibility for deletion to
>> succeed
>>
>
> So maybe the chance of deletion is low enough that we can drop the
> argument that "wikimedia might delete it" when discussing using
> wikimedia images.
>
>>
>> They have backlog of copyright violations,
>> and tricky cases where legality is not clear.
>>
>
> Ah, in that case we might need a bot that works in the other direction.
> Not one that tells wikimedia we've used one of its images but one
> that tells us that one of the wikimedia images we used has gone.
>
> People making backlog worse by making
>> such "low quality, delete" would not be
>> appreciated or encouraged there
>>
>
> We don't appreciate or encourage people who make ill-judged
> edits to the map, but it happens.
>
> --
> 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] Tagging multiple images on one object

[bkil]

> [...] Must be realistically useful for an educational purpose. [...]
> File in use in another Wikimedia project [...] [OR]
> File in use on Commons only: An otherwise non-educational file does not
acquire educational purpose solely because it is in use on a gallery page
or in a category on Commons, nor solely because it is in use on a user page
(the "User:" namespace), but by custom the uploading of small numbers of
images (e.g. of yourself) for use on a personal Commons user page is
allowed. Files relating to projects or events of the Wikimedia community,
such as user meetings, are also allowed.
> [...] For example, the fact that an unused blurred photograph could
theoretically be used to illustrate an article on "Common mistakes in
photography" does not mean that we should keep all blurred photographs. The
fact that an unused snapshot of your friend could theoretically be used to
illustrate an article on "Photographic portraiture" does not mean that we
should keep all photographs of unknown people. The fact that an unused
pornographic image could theoretically be used to illustrate an article on
pornography does not mean that we should keep low quality pornographic
images (see also Censorship).
> [...] Examples of files that are not realistically useful for an
educational purpose:
> Private image collections, e.g. private party photos, photos of yourself
and your friends, your collection of holiday snaps and so on. There are
plenty of other projects on the Internet you can use for such a purpose,
such as Flickr. Such private image collections do not become educational
even if displayed as a gallery on a user page on Commons or elsewhere.

Via:
https://commons.wikimedia.org/wiki/Commons:Project_scope
https://commons.wikimedia.org/wiki/Commons:Contributing_your_own_work

Some other technology (like IPFS) may also be sufficient for such party
photos and the mentioned Flickr also has a creative commons & public domain
sharing option that allows reuse for stock footage.
https://wiki.openstreetmap.org/wiki/Flickr

Also about uploading your party pictures as a child: you may not have
received the informed consent of all models portrayed on the picture (i.e.,
your family and other customers) that you have uploaded. For example in
many countries, you must sign individual waivers if you want to publish the
photographs that include identifiable humans. This is especially true with
Commons, because the purpose of uploading is to contribute the content in a
manner which allows other contributors to edit, remix and reuse your
photographs in ways that you or your models did not anticipate.
https://en.wikipedia.org/wiki/Personality_rights
https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
https://en.wikipedia.org/wiki/Right_to_be_forgotten
https://en.wikipedia.org/wiki/Celebrity_privacy#Right_of_publicity
https://en.wikipedia.org/wiki/Right_to_privacy

On Wed, Aug 26, 2020 at 11:54 AM Thibault Molleman <
thibaultmolle...@gmail.com> wrote:

> Ah ok, I had a bunch of my images deleted that I uploaded when i was a kid
> (maybe not the smartest thing to do at the time.)
> They were birthday photos and put them up cause figured it could work as
> stock photos (remember one site actually using one of them) and they got
> deleted a couple years ago.
> (looking back on the deletion requests. Turns out they were just unsure
> what the license was. (fair enough, uploaded them when I was 12 or
> something, so probably didn't really know what I was doing).
>
> Guess wikimedia commons galleries are a good solution then.
> Maybe it should be made more clear on the wiki that this is the thing you
> should do if you want to upload multiple images
>
> Cheers,
> Thibault
>
> On Wed, 26 Aug 2020 at 11:30, Andy Mabbett 
> wrote:
>
>> On Wed, 26 Aug 2020 at 10:04, Thibault Molleman
>>  wrote:
>> >
>> > Ah, I feel like there are certain images that might get deleted from
>> Commons
>> > just because they don't "contribute to wikipedia articles".
>>
>> That is not a valid reason for deletion from Wikimedia Commons.
>>
>> Commons' scope is far wider than just hosting images for Wikipedia.
>>
>> > Maybe a special example but still:
>> > Recently mapped a construction zone for a residential area and took a
>> > couple photos. Those might not "belong on Commons" according to their
>> > moderation team.
>>
>> There is no "moderation team" on Commons; deletion decisions there are
>> made by the community of contributors at large (just like edits in
>> OSM).
>>
>> Your images sound as though they would be in scope. Did you try to upload
>> them?
>>
>> Do you have an example of an image which has been deleted from Commons?
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Taggin

Re: [Tagging] Tagging multiple images on one object

[bkil]

I didn't share my viewpoint yet here. In my opinion, there is usually no
need for more than one image on a POI (two at worst), so I don't see a
need. If you want to photograph each entrance of a school, why don't you
attach each photo to the respective entrance? If you made photographs of
each hall, why don't you do indoor mapping and attach the photos to the
respective hall, etc.

In general, I think it is more productive to create a Wikipedia article
about a thing of major interest (like a university) and illustrate the
article with a proper amount of images and/or create a gallery there. In
this case, even 1 OSM image link is considered excessive, as it could and
should be scraped from the sidebar of the article by data users instead. In
my experience, Wikipedia does a better job at maintaining articles (and
galleries) than OSM in many, if not all regions.

Your link is 100 characters long, and a field is limited to up to 255
unicode characters, so two of these could fit in. I think if you use
reasonable providers, links should be reasonably short. Filenames are
optional in IPFS links and also, if we added schema-specific a key for ipfs
(similar to Mapillary/Flickr/etc), it could be a lot less shorter (46
characters a piece + semicolons), like
image:ipfs=QmR9wseHQiLbv4AnTXACo5rQ1CEcKj2fJq6vEnuZoi6Amd

On Wed, Aug 26, 2020 at 11:06 AM Thibault Molleman <
thibaultmolle...@gmail.com> wrote:

> Ah, I feel like there are certain images that might get deleted from
> Commons just because they don't "contribute to wikipedia articles".
> Maybe a special example but still:
> Recently mapped a construction zone for a residential area and took a
> couple photos. Those might not "belong on Commons" according to their
> moderation team.
>
> As mentioned on the linked wiki page, you can escape a semicolon by
>> doubling it:
>>
>>
>> https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#Escaping_with_.27.3B.3B.27
>>
>> Ah interesting, somehow missed that.
> It's a solution, but still doesn't solve the problem of long urls clogging
> up one tag.
> Definitely if you have long urls because of unique hash/id's
> (extreme example: IPFS urls:
> https://ipfs.io/ipfs/QmR9wseHQiLbv4AnTXACo5rQ1CEcKj2fJq6vEnuZoi6Amd?filename=IMG_20200727_172553.jpg
> )
>
> Cheers,
>
> On Wed, 26 Aug 2020 at 10:54, bkil  wrote:
>
>> As mentioned on the linked wiki page, you can escape a semicolon by
>> doubling it:
>>
>> https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#Escaping_with_.27.3B.3B.27
>>
>> On Wed, Aug 26, 2020 at 9:11 AM Thibault Molleman <
>> thibaultmolle...@gmail.com> wrote:
>>
>>> While I use the semicolon for some other tags already, the problem with
>>> using it for something that has a URL.
>>> Is that TECHNICALLYaccording to the specification, a URL can contain a
>>> semicolon.
>>> So I feel like the use of a semicolon in a url based tag isn't a good
>>> solution
>>>
>>> On Wed, Aug 26, 2020, 08:44 Mateusz Konieczny via Tagging <
>>> tagging@openstreetmap.org> wrote:
>>>
>>>> If someone really needs multiple images on one object then
>>>> https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
>>>> is standard.
>>>>
>>>> At the same time use for that seems dubious for this specific tag.
>>>>
>>>>
>>>> Aug 26, 2020, 07:41 by thibaultmolle...@gmail.com:
>>>>
>>>> Hi,
>>>>
>>>> It seems like there (still) isn't a proper tagging system to put
>>>> multiple images on one node/way/relation.
>>>> Having the ability to link other images as well would be useful I think.
>>>> Either via:
>>>> `image=url1;url2;url3`
>>>> or
>>>> ```
>>>> image=url1
>>>> image:2=url2
>>>> image:3=url3
>>>> ```
>>>> That later would allow for any application that currently uses images
>>>> to still continue to work perfectly.
>>>>
>>>> Curious to hear your thoughts
>>>>
>>>> Cheers,
>>>> Thibault
>>>>
>>>>
>>>> ___
>>>> 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
>>
> ___
> 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] Tagging multiple images on one object

[bkil]

As mentioned on the linked wiki page, you can escape a semicolon by
doubling it:
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#Escaping_with_.27.3B.3B.27

On Wed, Aug 26, 2020 at 9:11 AM Thibault Molleman <
thibaultmolle...@gmail.com> wrote:

> While I use the semicolon for some other tags already, the problem with
> using it for something that has a URL.
> Is that TECHNICALLYaccording to the specification, a URL can contain a
> semicolon.
> So I feel like the use of a semicolon in a url based tag isn't a good
> solution
>
> On Wed, Aug 26, 2020, 08:44 Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> If someone really needs multiple images on one object then
>> https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
>> is standard.
>>
>> At the same time use for that seems dubious for this specific tag.
>>
>>
>> Aug 26, 2020, 07:41 by thibaultmolle...@gmail.com:
>>
>> Hi,
>>
>> It seems like there (still) isn't a proper tagging system to put multiple
>> images on one node/way/relation.
>> Having the ability to link other images as well would be useful I think.
>> Either via:
>> `image=url1;url2;url3`
>> or
>> ```
>> image=url1
>> image:2=url2
>> image:3=url3
>> ```
>> That later would allow for any application that currently uses images to
>> still continue to work perfectly.
>>
>> Curious to hear your thoughts
>>
>> Cheers,
>> Thibault
>>
>>
>> ___
>> 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] source=RTK_GNSS

[bkil]

So let me just repeat to see whether I understand you correctly. You
would like to see protection measures getting implemented in
OpenStreetMap editors (like JOSM, iD and Vespucci)?

Such protection would warn if any node or way is moved that has
accuracy < 1? And/or it would warn if the accumulated move is more
than the specified accuracy?

On Tue, Jul 21, 2020 at 6:04 PM Allroads  wrote:
>
> Thanks for the accuracy link
>
> “you should mark the approximate accuracy of the given measurement as 
> returned by the instrument in the given instant.”
>
> That is also better.
>
>
> It is just, that you get a hint, source, accuracy, that the data is measured 
> in. Before you drag a node.
> ___
> 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] Map maintenance with StreetComplete - Preferred tagging

[bkil]

OpenStreetMap is a shared database - you generally shouldn’t annotate
POI with tags for your own use.

Tags should correspond to ground truth - hence they need to pass the
verifiability. If I resurvey the POI, will I conclude the same future
todo_check_date=* that you have previously added? What if the
tolerance between the two of us don’t match, and I conclude that it
needs to be resurveyed in 1 year, while you would be sure that it
needs to be resurveyed in 1 month?

This sounds a bit like if we started adding fixme=update on
everything, and that is something that we should avoid at all cost
(everything is fixme and needs updating on OSM by definition).

I think everyone should maintain their own todo list on their own
devices and/or in some critical cases in the form of map notes if they
need help from the community.

Viewing from a different perspective: the choice of survey priority
should be decided in situ locally by the mapper who has capacity to do
regular verification. If people adding new POI overburden maintainers
with too short deadlines, all POI will show up as expired. However,
maintainers only have a finite amount of free time, so they will need
to prioritize their mapping activities by the cost to benefit ratio.
Hence they will probably sort by when a POI was last surveyed,
rendering todo_check_date=* redundant at best.

By the way, if a proper amount of people were actually using OSM data
and their applications supported an easy feedback mechanism, such
legwork would be obsolete. For example, if one navigates to a POI that
they find closed, why couldn't they just report it? Or even better,
couldn't we use data mining to get this information from their
location and interaction traces as others do (subject to consent)?

And on the positive side: when a user checks into a venue with their
social application of choice (be it Diaspora or Friendica) or if the
respective wifi network name shows up on a scan nearby, couldn't we
consider these as affirming signs?

On Fri, Jul 24, 2020 at 11:39 PM Peter Elderson  wrote:
>
> Op vr 24 jul. 2020 om 22:53 schreef Tobias Knerr :
>>
>> On 24.07.20 14:13, Peter Elderson wrote:
>> > In comparable cases (non-OSM, but comparible checking schemes), I do not
>> > record the date it has been checked, I record the future date when it
>> > should be checked (again).
>>
>> When it should be checked is opinion-based, though.
>
>
> True, and the opinion is the user's opinion at the time of the survey. You 
> can suggest a default re-check date for the type of feature (might also be 
> empty) and leave it up to the user to accept or change that.
>
>
>>
>> The date when you last checked a shop's opening hours it is a fact. But
>> opinions on how often one should revisit a shop to check the opening
>> hours again may vary a lot between mappers. So I think the former is
>> more suitable to be added to the OSM database.
>
>
> It's a historic fact, but it doesn't drive any plan.
>
>>
>> There are some comparatively rare cases where you know in advance that
>> something will change (e.g. with construction that is scheduled to be
>> finished by a particular date), but imo that's more the domain of
>> opening_date or temporary tags.
>>
>> > The routine is then, ask if check_date is absent OR when the current
>> > date is past the check_date.
>>
>> I don't think this is a big benefit compared to "... OR when the current
>> date is X months past the check_date".
>
>
> I think you are thinking code in the app, not maintaining a bunch of features 
> such as 35000 routes or all the Stolpersteine in the area
>
> The difference is the determination of X. It's feature and opinion-dependent. 
> Checking/displaying due checks is very simple, and doesn't have to know 
> anything, just compare the tag with the date, and all pop up.
>
>>
>> Also, I tend to prefer making software a little more complicated if it
>> lightens mappers' manual workload, so making at least some use of
>> history (e.g. so that no check_date needs to be set when a tag is first
>> added) seems reasonable to me.
>
>
> As a maintaining mapper, I would set the future check_date at entry time.
>
> Your plan sounds fine, but it will not be of much use to me. I still have to 
> maintain an agenda and listst for checks in the future. If a future check 
> mechanism were in place, I'd simply display a check map, just like a map 
> showing all notes or all fixme's.
>>
>>
>> ___
>> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

/OFF-topic

>  I wouldn't presume I could push my car along a motor_vehicle=no way, or 
> dismount my horse and lead it along a horse=no way.
>

I think the last few messages are pointing us in the right direction,
but let me share some entertaining insights to answer your question.

Under our jurisdiction, a person pushing a bicycle or a moped (mofa)
are specifically mentioned at various key points in the law.
https://net.jogtar.hu/jogszabaly?docid=9751.KPM

The law legally regards you as a pedestrian when you (Appendix 1, II/a):
* push a bicycle,
* push a moped,
* ride a (slow enough) wheelchair,
* push a wheelbarrow,
* push a stroller.

The following road users are regarded as drivers (Appendix 1, III/a):
* person driving a vehicle (except person pushing bicycle or moped),
* person riding/driving/leading an animal.

Pushing a cart seems to be a mixed bag:
* you don't need to hold a driver's license,
* you are not considered a pedestrian, hence can not use the sidewalk
and must abstain from alcohol consumption.

Pushing any other vehicle (e.g., motorcycle, automobile) is considered
dangerous and not recommended, except for moving them to safety until
it can be towed. The pusher in this case is legally considered a
driver, the act itself is legally considered driving the given vehicle
and hence must hold a valid license and must also abstain from
alcohol.

So to sum it up, when you are pushing your car, the same OSM car
access restrictions apply to you as if you were sitting inside and
using the engine. When you are leading your horse, the same horse
restrictions apply to you as if you were riding it (i.e., you should
not lead a horse on public roads when you are drunk because you may
not be cautious enough to protect the animal from causing an
accident).

On Thu, Jul 23, 2020 at 9:36 PM Jmapb  wrote:
>
> On 7/22/2020 12:05 PM, bkil wrote:
>>
>> My guess is that the adoption of a dismounted_bicycle=* tag or similar
>> would require significantly *less* work than re-examining all current
>> bicycle=no ways.
>>
>
> Yes, I think that would be workable.
>
>>
>> Nonetheless, I completely agree with you, =no should mean =no! But I
>> fear we're in the minority, and that the sloppy tagging of the past has
>> a formidable inertia.
>>
>
> I disagree, see my other answer relating to agriculture.
>
> Also, it contradicts the principle of least surprise that most countries do 
> not have such restrictions, hence regardless of how you would like to 
> redefine `bicycle=no`, half of the world would still keep tagging it 
> incorrectly.
>
> As I see it, having bicycle=no imply permission to push a dismounted bicycle 
> violates the principle of least surprise because it's inconsistent with other 
> *=no access tags. I wouldn't presume I could push my car along a 
> motor_vehicle=no way, or dismount my horse and lead it along a horse=no way.
>
> I'm not asking for a stricter redefinition of bicycle=no because I suspect 
> it's simply not feasible at this point, especially given the continued 
> popular support for the interpretation that allows dismounted travel. But 
> it's clear why there's confusion here. Precisely because of this 
> inconsistency in the meaning of *=no, the strictest documented bicycle tag 
> value does not correctly describe the strictest real-world cases (which are 
> not rare.) And I guarantee that many mappers do not know that they're 
> implicitly permitting dismounted bicycle travel when they tag bicycle=no, 
> especially if they're aware of the bicycle=dismount tag.
>
> At the same time, I fear that defining a new value, stricter than =no (eg 
> =prohibited, =banned, etc) would probably cause more problems than it would 
> solve, given the number of data consumers that would need to adapt to this 
> change. This is why I reluctantly suggested adding a second tag 
> (dismounted_bicycle=no) alongside bicycle=no, even though it feels like an 
> ugly hack. Other possibilities might be prohibited=bicycle, 
> bicycle:prohibited=yes. foot:pushing_bicycle=no, foot:conditional=no @ 
> (pushing_bicycle)... all pretty hard to love.
>
> Maybe I'm wrong and a stricter-than-no value could be adopted without too 
> much pain? There is already limited use of bicycle=prohibited. (OSRM 
> currently appears to ignore it, see 
> https://www.openstreetmap.org/way/244518832 and 
> https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=45.61895%2C13.86592%3B45.61999%2C13.86804
>  .)
>
> Jason
>
> ___
> 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] Map maintenance with StreetComplete - Preferred tagging

[bkil]

This should be more applicable in case the person walked by the said
object in person: https://wiki.openstreetmap.org/wiki/Key:survey:date

Also, I'd like to stay neutral in this question as of now, but I think
it would be possible to implement heuristic algorithms to reconstruct
the history of a way even if it was split and to walk backwards on
changesets to check where "survey" was also mentioned as a "source".
We had a talk about just this on our local list some years ago.

A little preprocessing could go a long way, and such data structures
could be generated weekly or even less often - as the issue itself is
that a long time has already passed since the said objects were
updated. There's no need to extend the API just for this.

On Thu, Jul 23, 2020 at 6:08 PM Tobias Zwick  wrote:
>
> Hello everyone
>
> As you may or may not know, my microgrant proposal "Map maintenance with
> StreetComplete" [1] was selected to be funded by the OSMF. So, I am
> happy to have the oppurtunity to invest the time  extending the app,
> hoping that it will help to keep the map up-to-date and unburden people
> and communities invested in that topic.
>
> I am pitching this here because there are three details on which I would
> like to hear your input. Two of these are about tagging.
>
> But first, how will it work?
> 
>
> So, what StreetComplete will do is to scan the map for whether certain
> properties (tags) of map features haven't been surveyed for a certain
> time. If this is the case, users will be prompted to answer the question
> for that property again. For example, if the app ascertained that the
> smoothness of a road hasn't been changed for 5 years, it would ask users
> again about the smoothness of the road.
>
> Challenges
> --
>
> Now, you might imagine that this is not so straightforward to implement,
> and you would be right, for several reasons:
>
> Firstly, the OSM API has no notion about when a particular property of
> an element has last been changed, only for when the whole element has
> last been changed. But elements are changed all the time for various
> reasons. Roads for example tend to be changed especially often, splitted
> up to accomodate bus routes, turn restrictions, when detailing
> intersections, etc.
>
> Secondly, there is only the date of the last change, but that doesn't
> mean that is the date of the last survey. Even though that would be the
> information we are interested in: when has the element last been checked
> on-site?
>
> Thirdly, the OSM API does not offer users to record solely that they
> checked something and that it is still up to date. Any new record in OSM
> must always come with a tagging change.
>
> Solutions
> -
>
> In the absence of direct API support, fortunately the community came up
> with a solution: Add the check_date tag to the element that has been
> checked on a survey - or with the namespace if it concerns only a
> certain tag of a map feature.
>
> This works well and is actually already used by Streetcomplete in the
> "Is this construction site finished?"-quest:
> If the element as a whole hasn't been changed for 6 months *or* the
> check_date key is present and its value is older than 6 months, the
> quest is eligible to be asked again. When the user answers the question,
> the check_date is set to current date.
>
> Your input
> ==
>
> Now here is where I would like your input:
>
> 1. Use check_date:smoothness or smoothness:check_date?
> --
> check_date with a namespace isn't used all that often yet, both variants
> are used and thus there is no real winner yet. What variant do you
> prefer and why? And most importantly, which variant would be most
> consistent with existing tagging practices?
>
> 2. Always record check_date or avoid tagging it where not absolutely
> necessary?
> ---
> If something is resurveyed and it is acknowledged that nothing changed,
> it is absolutely necessary to tag check_date. If something changed, it
> is not strictly necessary because that the element changed as a whole is
> itself also recorded.
> But as already mentioned, elements can and do change all the time. One
> can not assume that if an element has been changed that it has been
> checked on-site. And even if one could, maybe not all the things were
> checked but for example only the bus route relation, or maybe only the
> presence of a sidewalk, or someone made the way a little more detailed etc.
>
> The topic whether StreetComplete should only tag the minimum of what is
> necessary to ensure functionality or always tag check_date (at least for
> properties that are eligible for re-survey) was already subject to
> discussion in the issue tracker here:
> https://github.com/westnordost/StreetComplete/issues/1836
>
> Maybe it is obvious that my opinion is that StreetComplete should always
> tag 

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

Alright, I didn't know you were only asking for the entertainment
value, but then I accept your challenge.

Actually I could indeed think of a place where you are only allowed to
be present in case you are pushing a bicycle. Imagine a bicycle
adventure park that only contains bicycle roads. Let's say that the
terms of service declares that visitors must not leave their bikes
unattended (i.e., no parking).

Now let's pretend that there's a small bridge in the middle of the
park that includes a small stretch of stairs that has bicycle pushing
rails (or substitute with just a single wooden bridge in a bad shape
that has a bunch of long cracks that could easily lock your wheels if
you ride over it - true story, we had a bridge just like that). A sign
would be posted here that disallows bicycle riders from accessing it,
but pushing through would be possible.

How could you be walking on to this bridge if you were not in
possession of a bicycle in the first place?

/OFF: Yep, the included whip antenna of an RTL SDR can receive these
beacons from an impressive range.


On Thu, Jul 23, 2020 at 5:33 PM Matthew Woehlke
 wrote:
>
> On 23/07/2020 09.59, Philip Barnes wrote:
> > On Thu, 2020-07-23 at 09:35 -0400, Matthew Woehlke wrote:
> >> I'm trying (and failing) to imagine a road/path/whatever that you
> >> are allowed to walk on *iff* you are pushing a bicycle (or moped
> >> or...). Do you know of any examples?
> >
> > I cannot think of many roads where you can walk but not cycle, other
> > than pedestrianised streets in town centres but you can walk on lots of
> > footpaths where you can push a bicycle. Some are too long and totally
> > unsuitable.
> >
> > A few of examples from my local big town
> > https://www.mapillary.com/map/im/HW9qSNB-1JlkQAC3SH_gZQ
> > https://www.openstreetmap.org/way/23896048
> >
> > https://www.openstreetmap.org/way/350458507
> >
> > https://www.openstreetmap.org/way/318709194
>
> All of those examples appear to allow regular pedestrians (foot=yes),
> which is common. I am asking if there are any places where walking is
> allowed *only* if you are pushing a bicycle, i.e. "no bicycle, no
> access". IOW, where your joke about dogs isn't a joke.
>
> (OT: Airline transponders may be IFF — note the capitalization —
> although I wonder about that because I always think of IFF as more a
> military thing. I'm not sure if civilian transponders are really meant
> to *identify friend or foe*, or if they're more just "transponders".)
>
> On 23/07/2020 09.59, bkil wrote:
> > For example, bicycle=dismount should be understood that bicycle
> > access is only allowed if a rider dismounts. However, if we had to
> > write bicycle=dismount + foot=no, then the meaning basically becomes:
> > neither riding your bicycle nor walking is allowed here, which is
> > quite the opposite compared to what bicycle=dismount would mean if it
> > were placed alone on the POI. Hence the correct way to tag this
> > should be bicycle=no + foot=no.
>
> Right, that's what I was suggesting, because the only plausible
> interpretation I can come up with for foot=no + bicycle=dismount is that
> you may traverse the way [on foot] iff you are pushing a bicycle. The
> question was, does that ever actually happen? I'm not *quite* willing to
> rule it out...
>
> --
> Matthew

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

Thank you, I do have a degree related to mathematics and I do understand
what *iff* means. However, that message didn't make sense with this
interpretation, this is why I've clarified my answer and I hope I've
cleared up any misunderstanding.

On Thu, Jul 23, 2020 at 4:17 PM Paul Allen  wrote:

> On Thu, 23 Jul 2020 at 15:01, bkil  wrote:
>
>>
>>> I'm trying (and failing) to imagine a road/path/whatever that you are
>>> allowed to walk on *iff* you are pushing a bicycle (or moped or...). Do
>>> you know of any examples?
>>>
>>>
>> I don't quite understand what you are trying to get at with the question,
>>
>
> That "iff" was not a typo.  It's mathematical short-hand for "if and ONLY
> if."
> Does the question make sense now?
>
> --
> 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] amenity=customer_service RFC

[bkil]

Within the way drawn for the office building, you should place a separate
node for the office POI. This node should be one having the given access=*
tag. Although, I think if I can visit a public office, that usually implies
that I have access to the given building as well, we usually do not add
access=* to buildings.

On Thu, Jul 23, 2020 at 3:53 PM Volker Schmidt  wrote:

> Careful with "access".
> access=customers on an office building would imply you can drive into this
> building with any means of transport, provided you are a customer.
>
> On Thu, 23 Jul 2020 at 15:46, bkil  wrote:
>
>> On Thu, Jul 23, 2020 at 3:39 PM Volker Schmidt  wrote:
>>
>>> So it would have to be customer_service=yes|no at least.
>>> That would also permit to check which offices have been evaluated by
>>> mappers for the presence or less of customer_service.
>>>
>>>
>> access=customers/private would also solve this without having to invent a
>> new top level tag.
>> ___
>> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

> > I.e., bicycle=dismount means that you can proceed after you dismount,
> > however if a certain combination of other tags are also present
> (foot=no),
> > a data user would need to ignore this, making this more confusing than
> > necessary (bicycle=no).
>
> I'm trying (and failing) to imagine a road/path/whatever that you are
> allowed to walk on *iff* you are pushing a bicycle (or moped or...). Do
> you know of any examples?
>
>
I don't quite understand what you are trying to get at with the question,
but let me list a few places where I think bicycle=dismount is implicitly
encoded:
* footways;
* "road closed" (unless certain extensions are added below)
https://commons.wikimedia.org/wiki/File:Estonia_road_sign_311a.svg
* within buildings (train stations, subway stations - you are free to carry
your portable bike around here);
* one way streets from the wrong way (should push either on the sidewalk if
it exists or on the road).

Maybe I didn't make myself clear in that sentence. I referenced a statement
from a different tagging thread a few weeks ago.

The gist is that if a mapper encounters a given tag (like
bicycle=dismount), a given definite meaning should be understood. This may
be _refined_ by further tags on the same POI, especially subtags, like
highway=service + service=driveway. Meaning shall not be redefined, rather
made more specific in these cases. However, I can't say that
highway=service + not_really_service=yes, i.e., a certain combination of
independent tags may not carry a meaning that greatly contradicts with any
subset of the said tags.

For example, bicycle=dismount should be understood that bicycle access is
only allowed if a rider dismounts. However, if we had to write
bicycle=dismount + foot=no, then the meaning basically becomes: neither
riding your bicycle nor walking is allowed here, which is quite the
opposite compared to what bicycle=dismount would mean if it were placed
alone on the POI. Hence the correct way to tag this should be bicycle=no +
foot=no.

I really enjoyed Phil's joke and I recommend that you think about it as
well.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=customer_service RFC

[bkil]

On Thu, Jul 23, 2020 at 3:39 PM Volker Schmidt  wrote:

> So it would have to be customer_service=yes|no at least.
> That would also permit to check which offices have been evaluated by
> mappers for the presence or less of customer_service.
>
>
access=customers/private would also solve this without having to invent a
new top level tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=customer_service RFC

[bkil]

Could you perhaps use existing tags instead of this?
office=company + access=customers
vs.
office=company + access=private

On Thu, Jul 23, 2020 at 2:44 PM Philip Barnes  wrote:

> On Thu, 2020-07-23 at 14:06 +0200, Simon Poole wrote:
>
> Wouldn't most, if not all, cases where this would be used already be
> covered by the corresponding (and likely already in use) shop=* value?
>
> It is also a confusing term to have chosen as prior to reading your page I
> had a Customer Services desk in my mind. Typically this is where you go to
> exchange purchases, get refunds.
>
> Phil (trigpoint)
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

But also consider that it wouldn't make sense to tag a motorway as
foot=no + bicycle=dismount (+ moped=dismount + mofa=dismount +
auto_rickshaw=no + agricultural=no), because the combination of tags would
create a completely new meaning, and that is not a preferred tagging
practice in OSM.

I.e., bicycle=dismount means that you can proceed after you dismount,
however if a certain combination of other tags are also present (foot=no),
a data user would need to ignore this, making this more confusing than
necessary (bicycle=no).

By the way, shouldn't simply adding motor_vehicle=only be sufficient? That
mostly covers the legal definition around here.

On Wed, Jul 22, 2020 at 11:26 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 22. Jul 2020, at 22:51, bkil  wrote:
>
> bicycle=no is usually used on busy motorways where dismounting isn't
> feasible:
> https://commons.wikimedia.org/wiki/File:Nederlands_verkeersbord_C14.svg
>
> On such a road, a bicycle router should only offer to dismount if the road
> has sidewalk=!none.
>
>
>
> on motorways there is also foot=no, this is why dismounting isn’t an
> option there. Generally we assume that dismounting makes the cyclist a
> pedestrian (vast majority of bicycle=no are just the same as dismount), and
> the rest is a different kind of question (what kind of objects  are you not
> allowed to bring, including bicycles, firearms, alcohol, religious symbols,
> political symbols, animals, sneakers, scissors, face masks, fireworks, etc.
> etc.)
>
>
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

Although I think we've given enough evidence and _some_ of your quotes make
sense, let me add another consideration.

This is where bicycle=dismount could be used (although it is the default on
highway=footway):
https://commons.wikimedia.org/wiki/File:Opastemerkki.jpg

bicycle=no is usually used on busy motorways where dismounting isn't
feasible:
https://commons.wikimedia.org/wiki/File:Nederlands_verkeersbord_C14.svg

On such a road, a bicycle router should only offer to dismount if the road
has sidewalk=!none.

However, transporting a (folding) bicycle here is still allowed in the
trunk or on racks without any trickery.

Am I understanding correctly that this is what the wilderness rules would
like to achieve?
vehicle=no + scooter=prohibited + bicycle=prohibited + moped=prohibited +
unicycle=prohibited + hand_cart=prohibited + wheeled_luggage=prohibited

I think if we concentrated on this case, it would be better to invent a
specific access value to convey that they don't want to see you be in
possession of anything that could leave a track in normal use
(access=legged). When you go out with something like this in the wild, they
could rightly infer that you would want to ride it when the park rangers
are not looking. Not sure about the extent of such restriction, but it
might also make sense to put it onto the natural area instead of each and
every individual path of it.

Am I right in that they still allow riding on the back of animals (like an
elephant, buffalo, yak, camel, donkey or horse) or machinery that mimic
limbic locomotion (like AlphaDog )?

On Wed, Jul 22, 2020 at 8:58 PM Allroads  wrote:

> It is annoying for me too.
>
> A router discussion.
> https://github.com/abrensch/brouter/issues/79
> Talk about a situation the use of use_sidepath and dismount. And the
> bicycle=no, which is not a hard no.
> Some qoutes.
> “Hm, but in very most cases, bicycle=no is used effectively in sense of
> bicycle=dismount, not in in sense *No bicycles here*.”
> “In my experience, bicycle=dismount is used very rarely, mostly if there
> is an explicit request to do it, in agreement with OSM intention for short
> way segments only, like e.g. narrow bridges, passes, collision danger etc.”
> “
>
> The only relevant interpretation of bicycle=no is the OSM tagging
> intention, not what I or you think about it. And that is clear - red/white
> traffic sign with a black bicycle, or legal equivalent.
>
> The routing itself is for bikers, not bicycles. Pushing bicycle is a legal
> and frequent mode of bicycle transportation. Bikers may then use such
> profiles that either penalize it either forbide it ( CF=1 for total
> ignoring, or  for navigation hint consideration )”
>
>
>
> Nothing changed.
>
> What they saying is, it is common accepted, OSM intention.
> bicycle=dismount is not often used, but very often should it be used, so
> routers take the common accepted. =no also = dismount. A hell of a job to
> set all these =dismount, tagging, what is really prohibited is better, OSM
> method. (new value?).
>
> Talking to route developers* is now  a past station!* Conclusion: no is
> not a hard no. Unfortunately, we must go further. A new value! This not
> only a bicycle problem.
>
> .
> No, new access key
> dismounted_bicycle all others must also have a equivalent, unworkable,
> more typing. Better one value, that fits all, fits the access systematic
> hierarchy.
> You must always look at this hierarchy to make routing decisions.
> The choose for a key make everything more complicated.
> Also for visualization.
>
>
> *From:* Tod Fitch
> *Sent:* Wednesday, July 22, 2020 4:53 PM
> *To:* Tag discussion, strategy and related tools
> *Subject:* Re: [Tagging] Is there a good way to indicate "pushing bicycle
> not allowed here"?
>
> This thread has been quite amazing to me. My impression is that it starts
> with some routers (a.k.a data consumers, a.k.a. “renderers”) treating a
> “no” as a “maybe” and now people are looking for a new term to indicate
> that “we really, really, mean NO!”. This is worse than tagging for the
> render, it is obsoleting a straight forward and explicit tag value for a
> broken renderer.
>
> Discussion devolves into “if I disassemble by bicycle and put into wheeled
> luggage is it okay now?”.
>
> Why not treat “no” as no? If I can push the bicycle through then we
> already have “dismount”.
>
> Is there some other way of getting a bicycle through? If so, then come up
> with a new value for that (“disassembled”?).
>
> In the meantime, file bug reports against any router that routes a bicycle
> over a “no”.
>
> At least where I am, “no really means no” and if you are caught with a
> bicycle at all then you are subject to a fine. Thousands of kilometers of
> paths are so marked and it really wouldn’t be nice to redefine an existing
> value.
>
> Cheers!
> Tod
>
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> __

Re: [Tagging] Tagging motorcycle parking

[bkil]

It would be advantageous to map them separately because one riding a
motorcycle could make better use of OSM to navigate to and from the exact
position of the applicable parking space.

On Wed, Jul 22, 2020 at 9:11 PM Matthew Woehlke 
wrote:

> I've seen some parking lots that have spaces specifically for
> motorcycles (i.e. that are not large enough for cars), although the lot
> as a whole is mixed-use. Is there no "direct" way to tag this (something
> like capacity:motorcycle)?
>
> Right now the only option seems to be to model the lot as two separate
> entities, one which excludes the motorcycle spaces, and one which is
> *only* the motorcycle spaces which could be amenity=motorcycle_parking.
> Is this really the best way?
>
> --
> Matthew
>
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

>
> My guess is that the adoption of a dismounted_bicycle=* tag or similar
> would require significantly *less* work than re-examining all current
> bicycle=no ways.
>
>
Yes, I think that would be workable.


> Nonetheless, I completely agree with you, =no should mean =no! But I
> fear we're in the minority, and that the sloppy tagging of the past has
> a formidable inertia.
>
> J
>
>
I disagree, see my other answer relating to agriculture.

Also, it contradicts the principle of least surprise that most countries do
not have such restrictions, hence regardless of how you would like to
redefine `bicycle=no`, half of the world would still keep tagging it
incorrectly.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

>
> Yes, my guess is that early mappers felt no need for bicycle=dismount
> because it was simply presumed that foot=yes + bicycle=no meant the same
> thing -- the assumption of a very bicycle-friendly culture!
>
> The obvious problem with bicycle=closed is that it's rarely used so
> routing software will probably not be looking for it, and so will
> happily send bicycles along bicycle=closed ways. In fact, I wanted to
> test some routers but I can't find a single bicycle=closed way currently
> tagged on the whole map.
>
> The other subtler problem is that it might be possible to
> confuse"bicycle=closed" with"bicycle=folded" especially for non-native
> English speakers.
>
>
That was a value deprecated by 2008 (or a typo on the wiki). See my other
answer from 2008 that already uses `bicycle=no`.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

When it was split in 2008, it had the following proposed values:
https://wiki.openstreetmap.org/w/index.php?title=Key:bicycle&oldid=119888


   - bicycle=yes 
   - bicycle=no 
   - bicycle=designated
   
   - bicycle=private
   
   - bicycle=permissive
   
   - bicycle=destination
   

   - bicycle=unknown
   



Documentation for dismount appeared around 2010 on this page:
https://wiki.openstreetmap.org/w/index.php?title=Bicycle&oldid=517641

> Where cycling is not allowed on short sections of signposted cycleroutes
(typically in the UK on narrow bridges and underpasses which are shared
with pedestrians), there are usually signs saying "Cyclists dismount".
These have been tagged as follows (300+ uses as of 2010-08-15)

It occured on this page in 2014:
https://wiki.openstreetmap.org/w/index.php?title=Key:access&oldid=1108382

Note that similarly, you may see a restriction for `agricultural=no` on
various roads around here, but you may still transport them over trailers
("possess") on the very same routes. Restrictions in this case were needed
because such vehicles are usually much slower than traffic and/or are much
more destructive to the road surface.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

> I wonder if carrying a bicycle (possibly folded) would also be prohibited
> on these unpaved ways?
>
> As was mentioned in the last thread, the rules for most federal wilderness
> areas in the USA strictly prohibit possession of any bicycle on the
> property, whether the wheels ever touch the ground or not. Rangers will
> fine the violators.
>

We don't have such areas around here but I have heard about them. The
concept is that tracked vehicles disturb and compact the ground and kill
many creatures that you are not aware of compared to bipedal locomotion. It
is thus imperative that if you dismount and push the bike, it still leaves
a track and still does a bit of destruction along the way. Wooden ways
similar to that depicted may also be more dangerous (and you could also
easily get a flat tire along the way and then potentially want to sue them).

If you were to carry it on your back (for whatever twisted reason), it
would not cause any harm, but then what is the point of carrying a bike
around for dozens of kilometers in the wilderness?

I think they usually don't have many provisions for foldable bicycles in
the USA because it doesn't have as much culture as in Europe or in the UK.

> To me, the simplest and most logical tagging approach would be:
>  - bicycle=no means no bicycles, ridden or otherwise
>  - bicycle=dismount means pushing is allowed
>  - other values can be used for even more restrictive situations:
> bicycle=carried, bicycle=folded, bicycle=boxed...
>
> But the problem with this, as I've learned, is decades of tagging by
> mappers who had no experience with the idea of bicycles being completely
> prohibited, so used bicycle=no to mean bicycle=dismount in situations where
> foot traffic was permitted.
>
> If this unfortunate tagging practice really needs to be preserved (the
> idea of retagging so many bicycle=no ways is certainly daunting) then I'd
> suggest a new key, dismounted_bicycle=*, which will function as a
> regulation key (like smoking=*) rather than a vehicle access key. Total
> bicycle prohibition would be encoded with both bicycle=no and
> dismounted_bicycle=no, and other dismounted_bicycle=* values can be
> developed for whatever the regulations are in particular situations.
>
> Jason
>

According to OSM wiki history, `bicycle=dismount` is a pretty recent tag,
perhaps less than 7 years old. I think `bicycle=no` was invented much
earlier. Hence it is you who wants to redefine a well established tag.

According to the first version of access=* in 2006:

https://wiki.openstreetmap.org/w/index.php?title=Key:access&oldid=3772
>  Closed to or unsuitable for bicycle traffic
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

>
> On the other hand, the terms of services of transport companies usually
>> have written provisions for carrying on folded bicycles irrespective of
>> size limits (for example, they even allow folded mountain bikes).
>>
> they might not even allow big boxes, according to the current situation
> (empty or full).
>
>
Yes, the terms of service of transport companies around here clearly state
luggage restrictions regarding dimensions and weight. However, the same
document waives just these limits in certain well defined categories
(foldable bicycles, strolles, ski equipment, plants, etc).

Of course they can still apply blanket terms to not let you board if you do
something unreasonable, like carry a 10 meter high foldable, a motorized
stroller or something like that.

nice project, although it looks as if it may get far too heavy to carry
>> around once it is realized.
>>
>
>
As mentioned, there exist both concept and mass produced alternatives that
have tiny luggage wheels just to aid carry, I can post some links if you
haven't seen such before. Although, you generally rarely carry your
foldable for extended periods - it is usually the one doing the carrying!

I probably wouldn't understand what `bicycle=explicit_no` means if I didn't
know about this thread. A core concept to follow when inventing OSM tags is
that smart enough individuals should be capable of deciphering what a tag
means just by reading all tags (and/or the possible values for the key) of
the given POI and the context even without consulting the wiki.

It's a funny thing that I wanted to recommend `bicycle=prohibited` at the
same time instant that Paul posted his reply! Not sure what the _best_ tag
would be, but at least this could be somewhat understood.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

This may all sound tangential or nitpicking to you, but to those with the
right equipment, the tags you propose, depending on scenario would simply
be misleading.

A photo would help to understand the exact place, but I think you could
easily push your foldable bike through narrow passages if you rotate your
handlebar and/or fold your pedals.

If you can fold your bicycle in 15 seconds, it integrates a
visually protective cover and has small luggage-wheels for moving when
folded, it would not cause a problem to take a 100m detour in the park if
it could save you kilometers and/or going into dangerous traffic. I've seen
such designs in mass production, but wouldn't want to do much advertising
here.

On Wed, Jul 22, 2020 at 12:06 PM Volker Schmidt  wrote:

> The boxes business is most likely leading us a bit up the Nymphenburg
> Schlosspark garden path.
> The real issue is routing for bicycles.
> Many (bicycle) routers I know would route you against (short) stretches of
> one-way roads or on short stretches of (bicycle=no) footpaths, so in those
> cases it is important to be sure that you distinguish between hard-no and
> soft-no for bicycles.
> I have come across another type of hard-no for bicycles in the form of
> chicane-type cycle barriers too narrow to push a bicycle (or a wheelchair)
> through.
>
> On Wed, 22 Jul 2020 at 11:48, bkil  wrote:
>
>> I have yet to see a park where they limit the size of luggage I can carry
>> with me (within rational limits).
>>
>> I think local law always defines what a bicycle is exactly. I don't think
>> that they have the right to search your box to check whether it contains
>> legally defined bicycles - that could only be done by a police officer and
>> would need a warrant, so I think we can always carry bicycles in a box.
>> Mind you that luggage could also have wheels.
>>
>> For circumventing carry-on rules, it was common knowledge that if you
>> removed the front tire, it could not be ridden anymore and could be
>> understood to be not a bicycle, rather it was classified as "bicycle
>> parts". Some thought this could be used to transport bicycles on a train
>> for free, but it was actually oversized for the definition of luggage, so
>> the actual deciding factor was always the kindness of the staff.
>>
>> If you carry a front wheel and your friend carries the rest, can you
>> enter the park? Both of you are only carrying parts, and none of you
>> possess bicycles.
>>
>> On the other hand, the terms of services of transport companies usually
>> have written provisions for carrying on folded bicycles irrespective of
>> size limits (for example, they even allow folded mountain bikes).
>>
>> Just for kicks:
>>
>> https://ecofriend.com/bike-that-folds-into-an-a3-paper-size-box-is-rightly-named-the-a3-bicycle.html
>>
>> On Wed, Jul 22, 2020 at 11:30 AM Martin Koppenhoefer <
>> dieterdre...@gmail.com> wrote:
>>
>>>
>>>
>>> sent from a phone
>>>
>>> On 22. Jul 2020, at 11:07, Mateusz Konieczny via Tagging <
>>> tagging@openstreetmap.org> wrote:
>>>
>>> bicycle_pushed=no was suggested in previous discussion, see
>>>
>>> https://lists.openstreetmap.org/pipermail/tagging/2019-November/thread.html#49056
>>>
>>>
>>>
>>> and then you would also need
>>> bicycle_carried=no
>>> and
>>> bicycle_carried_in_a_box=no
>>> (the latter is rare and could be seen as another way of saying
>>> carrying_boxes=no or maybe carrying_boxes:conditional =no@(any_dimension
>>> > 0.3m)
>>>
>>> And we would have to define what „bicycle“ means.
>>>
>>> Are these bicycles?
>>> 1.
>>> https://www.picclickimg.com/00/s/ODAwWDgwMA==/z/F-8AAOSwstJZXeV2/$_12.JPG
>>>
>>> 2.
>>> http://img0.biker-boarder.de/detail_oxp1/g13_edge_raw.jpg
>>>
>>> 3.
>>> http://www.unicyclist.com/filedata/fetch?id=2476281
>>>
>>> 4.
>>>
>>> https://photos.netjuggler.net/monocycle-kris-holm-24p/grande/Monocycle-Kris-Holm-24-pouces-isis1.jpg
>>>
>>> etc.
>>>
>>> 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
>>
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

In Hungary, you are not considered a driver when you are pushing a bicycle
or a moped, but you are if you push a motorcycle.

In museums, I think I would tag cloakroom:use=mandatory or something like
that. It happened to me in the past that I've checked in my portable
bicycle in the cloakroom when I didn't have a lock at hand and they didn't
mind.

On Wed, Jul 22, 2020 at 11:43 AM Martin Koppenhoefer 
wrote:

>
>
> Am Mi., 22. Juli 2020 um 11:34 Uhr schrieb bkil :
>
>> I think the core idea behind such a restriction is that people only want
>> to go to that park for walking around (no cross-traffic), and pushing the
>> bike for half an hour doesn't make much sense and allowing people to push
>> bikes around would risk them hopping on the bike when nobody is looking.
>>
>> What does this sign mean exactly, does this only disallow pushing a bike
>> or am I also discouraged from carrying one in, like a foldable bike? A
>> foldable bike can be carried onto city buses as luggage around here without
>> an extra fee. How could such a sign limit the type of luggage I can carry
>> onto the premises?
>>
>> Also, I'd invent something like this:
>> dog=carried
>>
>
>
> in some places you are not allowed to carry big objects (sometimes not
> even small bags like lady's handbags or umbrellas), e.g. in certain
> museums. On the other hand, I am not sure we even need to tag these things,
> of course you cannot bring your bike to an indoor museum typically. Or a
> huge box. What about pushing a motorcycle, I believe legally you are a
> pedestrian as well.
>
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

I have yet to see a park where they limit the size of luggage I can carry
with me (within rational limits).

I think local law always defines what a bicycle is exactly. I don't think
that they have the right to search your box to check whether it contains
legally defined bicycles - that could only be done by a police officer and
would need a warrant, so I think we can always carry bicycles in a box.
Mind you that luggage could also have wheels.

For circumventing carry-on rules, it was common knowledge that if you
removed the front tire, it could not be ridden anymore and could be
understood to be not a bicycle, rather it was classified as "bicycle
parts". Some thought this could be used to transport bicycles on a train
for free, but it was actually oversized for the definition of luggage, so
the actual deciding factor was always the kindness of the staff.

If you carry a front wheel and your friend carries the rest, can you enter
the park? Both of you are only carrying parts, and none of you
possess bicycles.

On the other hand, the terms of services of transport companies usually
have written provisions for carrying on folded bicycles irrespective of
size limits (for example, they even allow folded mountain bikes).

Just for kicks:
https://ecofriend.com/bike-that-folds-into-an-a3-paper-size-box-is-rightly-named-the-a3-bicycle.html

On Wed, Jul 22, 2020 at 11:30 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 22. Jul 2020, at 11:07, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
> bicycle_pushed=no was suggested in previous discussion, see
>
> https://lists.openstreetmap.org/pipermail/tagging/2019-November/thread.html#49056
>
>
>
> and then you would also need
> bicycle_carried=no
> and
> bicycle_carried_in_a_box=no
> (the latter is rare and could be seen as another way of saying
> carrying_boxes=no or maybe carrying_boxes:conditional =no@(any_dimension
> > 0.3m)
>
> And we would have to define what „bicycle“ means.
>
> Are these bicycles?
> 1.
> https://www.picclickimg.com/00/s/ODAwWDgwMA==/z/F-8AAOSwstJZXeV2/$_12.JPG
>
> 2.
> http://img0.biker-boarder.de/detail_oxp1/g13_edge_raw.jpg
>
> 3.
> http://www.unicyclist.com/filedata/fetch?id=2476281
>
> 4.
>
> https://photos.netjuggler.net/monocycle-kris-holm-24p/grande/Monocycle-Kris-Holm-24-pouces-isis1.jpg
>
> etc.
>
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

[bkil]

I think the core idea behind such a restriction is that people only want to
go to that park for walking around (no cross-traffic), and pushing the bike
for half an hour doesn't make much sense and allowing people to push bikes
around would risk them hopping on the bike when nobody is looking.

What does this sign mean exactly, does this only disallow pushing a bike or
am I also discouraged from carrying one in, like a foldable bike? A
foldable bike can be carried onto city buses as luggage around here without
an extra fee. How could such a sign limit the type of luggage I can carry
onto the premises?

Also, I'd invent something like this:
dog=carried

On Wed, Jul 22, 2020 at 11:22 AM Volker Schmidt  wrote:

> Apart from the island parts of Venice, there is this "famous" example,
> cited everytime the argument comes up: Bicycles, even walke, are not
> allowed in the Schlosspark Nympenburg (see leaflet):
>
> 
> "Das Mitführen von Fahrrädern ist im ganzen Park nicht gestattet. Nutzen
> Sie bitte das Angebot an Fahrradständern an den Eingängen."
> It appears that we still have no commonly agreed tag in OSM to indicate
> that type of restriction. OSM's "bicycle=no" is used to mean "riding of
> bicycle is forbidden" or  "you cannot bring a bicycle here".
> I agree we need a tag for a "hard" no-bicycle tag.
> In theory we do have the bicycle=dismount tag for not-riding a bicycle,
> but, unfortunately we do have too many existing uses bicycle=no in the
> database that in reality should be bicycle=dismount
> (Taginfo:
> 1?078?526 bicycle=no
> 79528 bicycle=dismount)
> I do not like "explicit-no", but I do not have any alternative suggestion
> either. bicycle=hard-no ? bicycle=prohibited ?
>
> I guess there is a similar problem with dogs: there are places where you
> cannot bring a dog, and there are places where you can not walk your dog,
> but you may carry it.
>
>
>
>
> On Wed, 22 Jul 2020 at 10:32, Oliver Simmons 
> wrote:
>
>> It seems highly strange that you wouldn't even be allowed to carry/push
>> your bike, are you sure that was what it meant?
>> Do you have a picture of the sign?
>>
>> On Tue, 21 Jul 2020, 22:50 Allroads,  wrote:
>>
>>> There lots of forest roads/path, where the bicycle/pushed carried is
>>> prohibited. Mostly, private owned land with a access_sign.
>>> “the bicycle” “transportation vehicle” is prohibited.
>>>
>>> Because, navigation programs do not us bicycle=no, as a hard no, there
>>> is the need for a extra value.
>>> bicycle=explicit_no, means “the vehicle” is prohibited.
>>>
>>> Why a value?
>>> We need a one value, otherwise a lot of more keys, which makes it things
>>> complicated. At the end it means for all explicit no!
>>> bicycle_pushed=no
>>> motorcycle_pushed=no
>>> horse_pushed=no ;-)
>>> moped_pushed=no
>>> mofa_pushed=no
>>> etc.
>>>
>>> Better one value, key=explicit_no
>>>
>>> What do you think?
>>>
>>> If we do not solve this problem, this stays forever.
>>>
>>> On the wiki page dismount, this bicycle_pushed is mentioned.
>>> https://wiki.openstreetmap.org/wiki/Tag:bicycle%3Ddismount
>>> For me a wrong advise.
>>> The problem is wider for more transportation modes, even for other
>>> product to carry around.
>>>
>>> Private access_sign rules, can go much further then traffic_sign. In
>>> what is prohibited.
>>> What the owner think and write down on the sign is valid.
>>> The skateboard is prohibited, means you can not carry a skateboard
>>> around with you.
>>> skateboard=explicit_no
>>>
>>> I need this value to do it correctly. Where the bicycle is no allowed.
>>> Or a other value meaning the same.
>>>
>>> ___
>>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] source=RTK_GNSS

[bkil]

https://taginfo.openstreetmap.org/search?q=accuracy
Yes, definitely. We used accuracy=* for this in the past, although I see it
is now a bit overloaded. accuracy:meters=* and location:accuracy=* both
seem to be widely used.

All of them should be interpreted as meters by default (i.e.,
location:accuracy=0.01).

Also be advised that you should not mark the theoretical best accuracy here
- you should mark the approximate accuracy of the given measurement as
returned by the instrument in the given instant. It could easily revert to
an imprecise result if it momentarily loses its signal or data connection.

On Tue, Jul 21, 2020 at 1:11 PM Allroads  wrote:

> There is data, what is measured.
>
> With RTK GNSS, there is 1cm accuracy possible.
>
> Should we tag this mapped data, so that we know the accurancy level of
> this data?
>
>
> Greetings Allroads.
> ___
> 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] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

Should this be tagged amenity=fast_food? Its name contains the word
"restaurant" and these are proper cooked meals similar to what one
makes at home, but they cook large batches, so people can just sit in
and have a bowl of pagpag with no delay:
https://www.bbc.co.uk/news/av/world-asia-42990661/how-meat-is-recycled-and-sold-to-the-poor
https://en.wikipedia.org/wiki/Pagpag

Also, how would you differentiate this from McDonald's (if at all), by
introducing a new tag fast_food=pagpag, or perhaps with
cuisine=pagpag? (I can find a few occurrences in name and name:en but
that's not the proper place)

On Thu, Jul 2, 2020 at 8:19 PM 德泉 談 via Tagging
 wrote:
>
> 在 2020年7月2日 星期四 上午7:18 [GMT+8]， Paul Allen< pla16...@gmail.com> 寫道：
> > On Wed, 1 Jul 2020 at 23:59, Martin Koppenhoefer  
> > wrote:
> >> On 2. Jul 2020, at 00:44, Paul Allen  wrote:
> >>
> >>> I cannot deny the possibility, but I have never seen a takeaway
> >>> kebab shop with seats for queuing customers.
> >>
> >> typical configuration in such places around here is a board (“table”)
> >> attached to the wall and bar stools. You can use it while waiting but
> >> also to eat if you want.
> >
> > example pic with limited outdoor and indoor seating, typical situation:
> >
> > I've never seen anything like that with a takeaway.  Cafes, yes.  Seats
> > outside used when it's sunny, seats inside used when it's raining.  Not
> > any takeway that I recall.
>
> It's interesting to find the difference of the food shops between different 
> nations, I'm surprised that seats for the takeaway queue is not common in 
> your place. Let me introduce the Taiwanese fried chicken shop.
>
> Localize fried chicken shop in my hometown is very common. (Note that 
> although everyone call it fried chicken shop but they sell fired vegetables 
> and seafood too.) This kind of shops usually only for takeout, and don't have 
> seats. They sell fast food, but they actually not fast.
>
> https://www.facebook.com/104450897586160/photos/a.158539162177333/229840271713888/?type=3&theater
>
> Upper page is the most famous fried chicken shop in my hometown. They will 
> give you a number paper and you have to wait at least 50 minutes at the peak 
> hour to get your food, so they provide some seats for those who are waiting 
> for their chicken.
>
> https://imgur.com/BtUnsdM
>
> This is a new shop nearby my home and I still need to wait 6 minutes for 
> frying the chicken so they also provide seats.
>
> I've taken a look and wanted to know how local mapper in my hometown tagged 
> this kind of shop, and made me funny that one is shop=kiosk, and other are 
> shop=deli (may be the translation problem of iD editor). Only very few of 
> them are amenity=fast_food. I think that local mapper may think that 
> amenity=fast_food is for McDonald KFC or MOS burger some place you can sit in 
> it.
>
> I think that I would call McDonald or MOS burger "fast food restaurant" and 
> the "fast food shop" is for upper examples.
>
> -Tan
>
> ___
> 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] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

On Thu, Jul 2, 2020 at 1:18 AM Paul Allen  wrote:
> I can't let Britain down in the bizarre food vendors contest. A butcher near
> me sells various types of raw meat (obviously).  There are also racks
> outside on the pavement: a rack of fruit and a rack of vegetables.  I was
> informed a few years ago by an alcoholic that the butcher also sold wine
> (I never went in to check).  During tourist season, also outside is a chicken
> rotisserie.  So he sells fast food.  How do we tag a fast food, alcoholic,
> grocering butcher?
>
> How would you tag your example?  It doesn't really seem a good fit for
> any tag we have.
>

Oh yeah, that's common around here as well! Some butchers sell all
kinds of interesting ready to eat things, like salami sandwiches,
grilled chicken, fried sausages (kolbász), fatback (szalonna), ham
hock (csülök), pork rind (tepertő), breaded cheese, breaded fried meat
slices, usually all offered with pickles (kovászos uborka, vegyes
vágott) and bread, but some may also cook chips.

Actually this is an instance where I think I would accept adding both
shop=butcher and amenity=fast_food to the same node, because both
functions can stand on their own: I can purchase both raw meat and
ready to eat simple fast food.

I'm a bit puzzled about mixing in the greengrocer and drink shop
aspect, though (cuisine=* and drink=*?). There.

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

Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

Funny that you mention. I've just read the Hungarian interpretation of
a legal advisor regarding what counts as seating. They were
differentiating between the sit down amenity kind and the
takeaway-only shop kind of cukrászda from a tax perspective.

According to them, in order for a _service_ to be achieved, the
customer needs to be provided with:
* tables and seating that is being periodically cleaned and reset,
* napkins,
* cutlery,
* a waste basket,
* access to a toilet.

They explicitly state that:
* all else being equal, food court type of seating and using the mall
toilets is acceptable,
* self-service is acceptable,
* boards attached to the walls or eating at the counter are not acceptable.

Source:
https://adozona.hu/2017_es_valtozasok/Fel_van_adva_az_afalecke_adokulcs_etelre_it_WUS0R3

How we usually paraphrase this is that an amenity is a place where
people would _want_ to sit down to eat and/or wouldn't be ashamed to
invite others as well.

On Thu, Jul 2, 2020 at 12:59 AM Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> On 2. Jul 2020, at 00:44, Paul Allen  wrote:
>
> I cannot deny the possibility, but I have never seen a takeaway
> kebab shop with seats for queuing customers.
>
>
>
> typical configuration in such places around here is a board (“table”) 
> attached to the wall and bar stools. You can use it while waiting but also to 
> eat if you want.
>
> example pic with limited outdoor and indoor seating, typical situation:
>
> https://www.zomato.com/it/roma/istanbul-kebab-pizza-flaminio-roma/photos
>
>
> 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] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

Again, I still don't have enough information about your "takeaway"
places, but if you are not satisfied with takeaway=only + capacity=0,
could it be also solved via subtagging?

I can see someone started experimented with
amenity=restaurant + restaurant=diner

And:
amenity=fast_food + fast_food=van/truck/street_kitchen

It even has a wiki page, although it also fell victim to Mr.
Jeisenbe's art of deleting information:
https://wiki.openstreetmap.org/w/index.php?title=Key:fast_food&oldid=1929947

Would fast_food=diner or fast_food=takeaway cover your use cases (not
sure about the difference)?

On Wed, Jul 1, 2020 at 11:31 PM Paul Allen  wrote:
>
> On Wed, 1 Jul 2020 at 22:10, Jarek Piórkowski  wrote:
>>
>>
>> Yeah, but we're being told that British takeaways are very different
>> from other casual food places that have seating
>
>
> A takeaway doesn't have seating.
>
>> and the provision of seating is of key interest to Paul.
>
>
> Yep.  If you're on foot (I usually am) and you live in a country that is
> often cold and it frequently rains (I do) then seating is a key factor
> in deciding where to go for food.
>>
>>
>> So, are they different enough to have a new root tag? Or do we accept
>> ambiguity of cafe/fast_food root tags and specify with subtags?
>
>
> Or do we smoosh them all up into one aggregate tag and not bother
> with distinctions?  That would work.  It would make it far easier to
> tag things.  No agonizing decisions about whether it's one thing
> or
>>
>>
>> In my reading, that's what the entire discussion has been about.
>
>
> I think it also had a little to do with exploring cultural differences both
> in how different cultures categorize things, and how those cultures
> use tags for those categories, and where the mismatches are, and
> how we fix things.
>
> BTW, I happily admit to being the only member of my own culture.
> It's distantly related to British culture, but with some quirks. :)
>
> --
> 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] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

>> > Shop=pastry?
>> >
>>
>> Unfortunately we can't use that tag, as the menu of a cukrászda far
>> exceeds the definition of what the word "pastry" implies. They usually
>> offer many items from the following categories:
>> * cakes
>> * cookies
>> * custards
>> * doughnuts
>> * frozen desserts
>> * puddings
>> * scones
>> * sugar confections
>> * sweet pastries
>> * sweet pies
>
>
> What you list is a mix of (to use the technical terms) baker's confectionery
> and sugar confectionery.
>

Almost right, but see the rational definition from Wikipedia:

> Bakers' confectionery includes sweet baked goods, especially those that are 
> served for the dessert course.
> Bakers' confections are sweet foods that feature flour as a main ingredient 
> and are baked.

The above list and the menu of a cukrászda may also include desserts which:
* need cooking, but not baking,
* need no cooking or baking at all,
* do not have flour as the main ingredient,
* some that bakers aren't allowed to make in Hungary (only a cukrász
or a pastry cook).

I based these top level dessert/sweet categories on these pages:
* https://en.wikipedia.org/wiki/List_of_desserts
* https://en.wikipedia.org/wiki/List_of_pastries
* https://en.wikipedia.org/wiki/Pastry
* https://en.wikipedia.org/wiki/Confectionery

> What a shame we don't have a word that
> combines both types of item.
>
> Actually, we not only have such a word, we have the corresponding tag:
> shop=confectionery.  However, the wiki contradicts itself.  The first 
> paragraph
> includes cakes and croissants as items it sells.  The second paragraph says
> that shops selling cakes should be shop=pastry.
>
> Also, I don't know about the UK in general, but I can only remember
> seeing "confectionery" applied to sweet shops that want to appear
> up-market.  Wiktionary agrees with me.  Wikipedia doesn't.
>

Unfortunately, my position as a foreigner is pretty weak when trying
to argue about the meaning of English words with a native speaker, but
let me share the insight I gained after analyzing a few articles.

The word "confectionery" can mean both
* sugar confections alone,
* and a broad category that encompasses both sugar confections and
baker's confections.

This confusion causes the kind of documentation inconsistency that you
observe. Hence we should avoid words with such confusing multiple
meanings in OpenStreetMap if possible. Hence I propose that we
deprecate shop=confectionery and introduce shop=sugar_confections
instead.

A word even worse than this is "pastry", that could refer to:
* a kind of dough,
* vaguely "small tarts and other sweet baked products",
* a mostly specific category of desserts outlined in the above
taxonomy related to the second point,
* sometimes incorrectly to various desserts in general.

Though the last one doesn't seem to be an accepted meaning, this error
occurs a lot on Wikipedia (possibly propagated by non-native
speakers).

After some more effort, I could narrow down the definition to
something manageable by cross checking with my taxonomy outlined
above, but the blur between its meanings also warrants avoidance in
OpenStreetMap.

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

Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

> The only possible downside I see is that it requires more carto code if you
> want different icons.  But that would be necessary however we did this.
>

Possibly. But if part of the world already uses amenity=café for
places that do not primarily focus on coffee, this icon revision based
on subtypes is unavoidable and a beneficial update.

>  Of course, the unambiguous,
> uncontaminated name would be cukrászda, but I doubt that would
> go down well with those who don't speak Magyar.

Yes, tagging with "cukrászda" would be the best. ;-) Although, people
would have a hard time typing the accent, and surely it's not a
Hungarian invention. I imagine it could have been inspired by the
French patisserie and brought in from Germany to the Austro-Hungarian
Monarchy.

>  Maybe > cafe=beverages?  I'm not entirely happy with that as it implies
> nothing but beverages.
>

Just to recap, a cukrászda is kind of an artisan fancy dessert bakery,
cakery & confectionery that operates as a café where they replace
"coffee" with "desserts" in people's minds.

They may offer liquid desserts as well, but this is usually not a
defining characteristic.

> It would need guidance in the wiki as to where the line is between a
> coffeehouse (or whatever we call it) and a cafe that isn't a coffeehouse.
>

Yes, that should be a good idea before someone submits a grand
unification proposal.

> Do sandwiches as well as cakes make it a diner?  How about if there
> are hot sausage rolls, too?  What is the classification of the places
> at smaller railway stations that have this sort of menu but aren't
> places people go to socialize?
>

If the primary audience is hungry travelers, then it would probably be
a diner (or a fast food restaurant, not sure about the difference in
the UK). Otherwise if they just want to have something to go with the
tea or coffee, it's not a diner.

It's pretty subjective and culture dependent what people usually mean
by "go with" in this context, but local mappers can almost always
determine that with high accuracy.

For example, some cultures would call for cookies with their tea,
while others do pretzels or peanuts, still others may be fine with
thin sausage stick snacks, a pickled egg or a mini sandwich. Surely
you can get "filled" with any kind of food item if you consume a vast
amount of it, but the intention here is that the meal part should not
be that "filling" to the point of being an obstacle to further drink
consumption .

>> Or even this one:
>> amenity=cafe + cafe=teehouse
> For golfers? :)
>

Hah, a mind spoiled by the command line. Hm, should have been
amenity=cafe + cafe=teahouse...

>> For the kind of cukrászda where you can not sit in, we could also add
>> takeaway=only/capacity=0 to this or maybe introduce shop=*** instead.
>
>
> Shop=pastry?
>

Unfortunately we can't use that tag, as the menu of a cukrászda far
exceeds the definition of what the word "pastry" implies. They usually
offer many items from the following categories:
* cakes
* cookies
* custards
* doughnuts
* frozen desserts
* puddings
* scones
* sugar confections
* sweet pastries
* sweet pies

> I'm kind of puzzled as to how the socialization aspect of a cukrászda works 
> when
> there are no seats. :)
>

Indeed, the socialization aspect is not important for shops. However,
what is still important is:
* they focus on various desserts and usually appeal based on the looks,
* have a refrigerated translucent counter,
* their products are hand made,
* the products are usually not prepackaged,
* the products are perishable, usually without added extra
preservatives in most items,
* they are usually a family owned small producer, not a retailer,
* they hold appropriate government "cukrász"/confectioner/whatever
licenses as per country regulations and/or advertise their cooking
certificates and awards on the wall,
* they usually offer on demand customization, made to order,
* they usually offer a choice of bottled drinks to go with your dessert.

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

Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

So just a quick idea, what do you think if we subtyped amenity=café?

What non-UK people refer to as a café:
amenity=cafe + cafe=coffeehouse

Diners/greasy spoon and whatnot:
amenity=cafe + cafe=diner

Or even this one:
amenity=cafe + cafe=teehouse

$SUBJECT:
amenity=cafe + cafe=cukrászda***
(***We're still working on the word to recommend, but many came up
already, like dessert, dessert_bakery, sweet_bakery, fancy_bakery,
patisserie and others)

For the kind of cukrászda where you can not sit in, we could also add
takeaway=only/capacity=0 to this or maybe introduce shop=*** instead.



On Tue, Jun 30, 2020 at 11:40 PM Paul Allen  wrote:
>
> On Tue, 30 Jun 2020 at 20:13, Gábor Fekete  wrote:
>>
>>
>> It's about the main function. In an imagined daily routine (similarly to 
>> Bkil), coffeehouse (and cukrászda) is the place of some social life after or 
>> between meals. One can arrange a date with his/her (girl)friend, or even a 
>> meeting with a business partner for a short talk in a posh coffeehouse in a 
>> calm ambience (soft chillout music, porcelain tableware). It's not about the 
>> food or the coffee :)
>
>
> So nobody would ever go to a cukrászda alone, just to eat the limited fare.
> And nobody would ever have a romantic meeting at a McDonalds.  Except
> that both of those happen.  Yeah, I know you said main function, but it's all
> blurred together, especially with the existing tags.  McDonalds calls itself
> a fast food restaurant yet I get mocked because it occupies my mental
> space for "cafe" and I think of "fast food" as a type of cuisine.
>
> The discussions so far make things murkier.  At one moment bkil argues
> that cukrászda sell only coffee and should be split off, and that sounds
> sensible.  Then he says they sell cakes.  And sandwiches.  Which puts
> them into that broad category in the wiki for amenity=cafe, which
> encompasses anything from coffee shops to diners (but not if the
> diners sell fast food, everyone assures me).
>
> A cukrászda sounds almost like a UK coffee shop, which can be for
> socializing/meeting but is also for people who feel a little hungry.  Except
> places that start out as coffee shops in the UK usually end up selling more
> substantial meals too.
>
> It is a horrible mess.  Our tags, especially amenity=cafe, are a poor fit to
> reality.  Retagging everything would be the only way to bring some sense to 
> it.
> But that will never happen. Maybe the best we can do is carve out something 
> for
> coffee shops that can be applied to newly-mapped POIs and accept that the rest
> is a mess.  Doing that might let this thread die down.
>
> --
> 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] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráre?, pasticceria, konditorei, patisserie, ...

[bkil]

> But then how do we handle food places in food courts?
>
> They would all count as =fast_food, as everything is already cooked / 
> prepared, & they are takeaway only from the actual shopfront, but there is 
> seating & tables 5m's away, so are they takeaway or sit-down?
>

These kind of places around food courts are indeed amenity=fast_food
restaurants. They aren't takeaway=only, because they almost always
offer a tray, napkins, plates and utensils that you need to take back
after you are finished (or leave it at the common collection point),
although some may be throw-away and you get to use the waste basket,
table and chair as well.

If I took away my food from a restaurant and sat down right in front
of them, they would probably ask me to leave and stay out of sight.

But still if you are in general taking your food away, you only get a
box in a bag (or if you bring your own box and bag, you get nothing
other than your food).

How much I'd write in capacity=* is another question - actually adding
capacity=food_court and giving a total capacity on the separate food
court polygon would make more sense, but it's not standard practice
(yet).

> When I was working at the Uni several years ago, we'd go over to one of the 
> coffee shops for morning coffee. It was a kiosk only, & they only served tea 
> & coffee, together with bottled water & you could also buy bottles of milk 
> from them to take back to the staff kitchens. Fine, so it's a =coffeeshop. 
> But, they also had a container on the counter full of biscuits (cookies) for 
> sale! Does that then make them a cafe?
>

It's still a café as per the definition: you primarily go there to
grab a cup of coffee or tea, and you can also get something to go with
that - cookies (by the way, in Hungary, it's called tea cookies/tea
cakes/tea pastry/tea desserts just because of this!).

> Similar to the food-court set-up ^, there were tables & chairs out the front, 
> but not for their exclusive use - anybody could sit & have a chat, coffee or 
> eat their lunch that they'd brought from somewhere else.
>

I think I know what you mean, we also have these. If I need to bring
back something after I'm finished, it's not takeaway=only. Otherwise
you can add a bunch of picnic tables in front of the building with
access=customers and that would solve it for all intents and purposes.

> That (at least to me?) then raises the problem of opening hours (which I know 
> can easily be defined). The vast majority of "cafes / coffee shops" (places 
> you can get a tea / coffee & a light meal) around here open at ~6am, but they 
> then close at ~2-3pm - they're not open after work or for an evening meal.
> Similarly, most restaurants (full table service of a multi-course meal) don't 
> open till ~6pm, then stay open till 11-12.
> Does that affect the cafe / restaurant definition dilemma?
>

Here's an overview from Hungary.
A typical restaurant around here is open between 10:00-22:00 or 12:00-24:00.
A typical small pub stays open the longest, some are non-stop, but
most open in the morning and close in the evening.
Better and larger pubs typically follow the opening hours of
restaurants, maybe closing an hour or two later on party nights, so
let's say between 12:00-01:00.
A typical café/coffee shop opens in the morning and closes earlier in
the evening, like 08:00-20:00, some up to 9pm.
A typical cukrászda aligns with typical shops, open between
10:00-18:00, or some up to 7pm.
Fast food places vary a lot: they can be either non-stop, tied to the
opening hours of the containing facility (like shopping mall
10:00-20:00 or a theatre nearby) or mostly focused around lunch times.

You could typically frequent a cukrászda right after work hours or on
weekends, though some may consider giving a visit at the end of a
longish lunch break.

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

Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráre?, pasticceria, konditorei, patisserie, ...

[bkil]

> I'd be happy with that.  Except we don't have seating=yes.  We can 
> differentiate
> with takeaway=yes|no|only.  However, apart from the chip shop and a Greggs, 
> all
> the fast food joints near me that I can recollect are takeaway=only.  So I 
> don't
> get a hint from the icon as to whether I can sit down or not.
>

Indeed as I've mentioned there exists lots of fast food places in
Hungary without seating. It's not a majority, but there's a
significant proportion. It's common at underpasses, serving gyros,
slices of pizza, burgers and other simple things that can be eaten
without utensils. Some serve these from their trucks, although some do
carry a few tables and foldable chairs as a convenience.

The majority operate from within brick and mortar buildings where even
the smallest ones have at least 4 tables and 8 chairs - most often
they also have elaborate outdoor_seating=* constructions right in
front of the venue - including seats, tables, waste baskets, umbrella,
sometimes even wind protections and electric or gas heating apparatus,
decorative plants and big screen TV.

We usually tag ones without seating as takeaway=only and/or
capacity=0. Note that capacity=0 also appears on some maps after the
name, like "Burger Place (0)", giving a hint at the seating capacity,
making seating=no redundant.

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

Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráre?, pasticceria, konditorei, patisserie, ...

[bkil]

Yes, pretty much sounds like a cukrászda to me. ;-)

Especially if they prepare their own desserts and if they take custom
orders (why shouldn't they if they already have a pastry cook?).

Do they have waited tables? Do they serve alcohol? It would be great
if you could share a link to their website or some photos so we could
see for ourselves.

On Tue, Jun 30, 2020 at 2:35 PM Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> On 30. Jun 2020, at 14:13, Philip Barnes  wrote:
>
> Cuisine=dessert is perfectly valid, my local big town has
> two restaurants which only sell desserts.
>
>
>
> doesn’t seem to meet the requirements of the amenity=restaurant tag in 
> OpenStreetMap though („full sit down menus“), or are the desserts considered 
> „full menus“?
>
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant
>
> 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] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

On Tue, Jun 30, 2020 at 12:11 PM Martin Koppenhoefer
 wrote:
> it is you who knows the cukrászda best. You must decide (together with your 
> fellow local mappers who also know the feature), whether it is a subtype of 
> one of the established tags, or whether it is so different that it must get a 
> new tag. People from England or Italy can not help significantly you to make 
> this decision, because we do not know the feature well. We can only help you 
> by asking questions and trying to explain what the implications and meaning 
> of the established tags are (and only if we can concur on a common meaning 
> ;-) which is not a given, as shown by this discussion). You will also almost 
> everytime find someone who does not agree, and while I have read a lot of 
> things from Paul that made sense in other contexts, in this particular 
> discussion it appeared to me that he was sometimes giving interpretations of 
> established tags that didn't find other supporting voices.
>

Indeed your input is highly valuable. In parallel to this thread, your
answers have sparked a constructive 6th/7th wave of discussions in
Hungarian on matrix.

It's not that we disagree within the community, it's that we honestly
don't know the _right_ answer. We're trying to dig deeply into the
linguistic, historical and cultural aspects as well to better
understand the constraints.

It's a major blocker that the most important key words do not have
proper translation between English and Hungarian, or their approximate
translations misleadingly map to different concepts or subsets of
substantances (sütemény, péksütemény, cukrászsütemény, édesség,
cukrász, torta, desszert, ...).

We're trying to avoid this by trying to come up with new compound
words and/or generalizing by categories.

> I think this is what we all are striving for here, the problem is that it is 
> not obvious. It is clear we ideally want to be able to exactly understand 
> from the tags what kind of object it is, but if have too many different types 
> on the top level, it will make it difficult to use the data (you must know 
> all these tags and look for them in order to show them to your users), while 
> if we have too few top level tags, people must also look for all the subtags 
> in order not to get a wrong impression. We are looking for a "middle way", 
> and what makes sense in this regard is seen differently by different people. 
> That's why we are discussing here.
>

So we're just now working with another member of our community in
attempting to come up with a schema where we could "micromap" the type
of desserts served by category. This direction may allow for using
more general top level amenity and shop tags, although I personally
don't see an existing one that would be an _optimal_ choice. If not
done right, its maintenance burden may also be higher than
anticipated. In general, a new top level tag is sometimes understood
to be a shorthand for a bunch of other subtags (existing or virtual
ones), so we'll see what kind of redundancy this would introduce.

We're still doodling about this, but will keep you posted.

>> From a perspective of local knowledge, I had to point out the
>> workaround of using amenity=cafe + cuisine=* for many years now to
>> well experienced OSM editors with thousands of edits around the world,
>> because they wouldn't have otherwise thought of this (but then they
>> also disagreed with this concept). How would I then expect a novice
>> mapper or a navigation user to have figured this out then?
>
> by documenting it in the wiki, also in your language
>

So basically my argument here was that it is good practice to document
tags and useful combinations (I also do that as a hobby), we should in
general prefer not to use tag wordings that aren't "obvious" given
basic knowledge of English. Hence, I agree that we should keep it
simple and to give at least a fair chance for international users to
understand a POI without local knowledge.

> (and potentially convincing the makers of tagging presets to cater for it).
>

At some point in time, a well intentioned translator caused great
confusion by mixing shop=confectionery and shop=pastry, but we fixed
it promptly. I agree that after we agreed on a schema that could work
across borders, it would be a great benefit to the mapping community
to make presets for it.

> (I have seen there are quite some hits in the wiki already for this word).
>

Yes, as mentioned, we're having this FAQ all the time, and hence at
least we started to document the dirty workarounds that we'd been
using up to now to be consistent locally, but this consistency breaks
down around the world (and with the sit-in kind of cukrászda).

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

Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

I think there would be room for such POI specialization in Hungary as
well (menza/cafeteria, kifőzde/étkezde, csárda, kisvendéglő, fogadó,
kávéház/kávézó, bisztró, pince, romkocsma).

Although, I may not be catching the gist here, based on the concept of
not including values in key names, should it be
restaurant:type=it:ristorente;it:pizzeria instead? Or is this a
translatable key, so we could add the equivalent
restaurant:type:hu=étterem;pizzéria
in there as well along all other translations? That sounds a bit
redundant.

But basically yes, that could work, *if* we could find something to
specialize under. If we specialized sit-in "cukrászda" under
"café/kávéház", should we also create a "virtual" category under café
named "real kávéház"? That sounds like a bit involved.

Specializing the takeaway "cukrászda" under something close to
"pastry" may or may not work, depending on whether non-artisan pastry
shops are common outside Hungary and if they could lead to confusion
or not.

We also have places whose names implicate "mixed" function around
here, like "Étterem & pizzéria", "Étterem & cukrászda", "Cukrászda &
fagyizó", "Kávéház & cukrászda", "Kávézó & pékség", but in most cases
it is easy to determine the main function on a survey, most of the
time even from their website (most often restaurant, cukrászda,
cukrászda, cukrászda and café respectively, although the last one
could actually turn out to be indeed both a café and a bakery at the
same site).

However, I'm not quite comfortable with someone adding a specific
combination of top level tags to convey a new kind of function
regardless of how similar the synthesis result might sound like unless
the meaning of the independent tags can stand on their own on
the given POI and be valid.

For example I've seen something in Austria that looked like a
cukrászda being tagged amenity=café + shop=bakery (probably based on
the name). In general, if a data user that does not interpret this
combination specially only wanted to search for cafés, returning this
could be misleading as mentioned in the previous mail. If, on the
other hand it wanted to find all bakeries (to purchase bread or kifli
for example), the user would again be disappointed because such places
most often only keep fancy bakery products, not staple ones.







On Sun, Jun 28, 2020 at 4:09 PM Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> On 28. Jun 2020, at 15:58, bkil  wrote:
>
> We are leaning towards being dissatisfied with tagging as either
> shop=pastry or amenity=cafe.
>
>
>
> today I think I would prefer a generic descriptive term as the main tag (e.g. 
> shop=sweet_bakery) and have subtags for specilizations or product categories.
>
> Another (general) issue are “mixed” places like “Bäckerei Konditorei Cafe” or 
> “Bar Pasticceria Gelateria Tavola Calda”, as the individual classes often 
> tend to use the same key.
> One way I am paying tribute to these is the
> restaurant:type:it tag, which gets multiple (slightly “normalized”) values in 
> the local (here Italian) language:
> https://taginfo.openstreetmap.org/keys/restaurant%3Atype%3Ait
>
> These can be quite useful for people speaking the language and familiar with 
> the local expectations, and might eventually be transformed to more specific 
> detail tags later (not holding my breath for it).
>
>
> Cheers Martin

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

Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

Yes, "we" refers to the Hungarian mapping community who we discussed this
topic with a few times in the past, although we're still waiting for
others from the neighboring area to also chime in.

We'd be more than happy if we could have input from as many cultures
as possible.

In Hungary, coffeehouses (and cafés) generally do not make _any_ of
their desserts, while a cukrászda makes _almost_ all of them (if not all).
Hot meals are also not expected in a cukrászda, while some fraction of
cafes around here do offer a time limited daily lunch:menu=* (they
usually order such meals from external kitchens), though as mentioned
it would be plausible for a bigger coffeehouse to have a kitchen where
they could cook something simple like an omelette.
However, I would be surprised if coffeehouses were common in the UK which
do not serve any coffee.

The mapnik icon of a café is a coffee cup. The primary motivation of
us wanting to go to a café is to have some coffee, tea, a soft drink
and perhaps something to go with that.

The icon of a cukrászda could be some kind of dessert (unfortunately
the piece of cake is taken by shop=pastry). The primary motivation of
going to a cukrászda is to have some nice desserts, and perhaps some
liquid to go with that - so that's just the corollary.

The use case is clearly different, and the two can rarely be
substituted for one another. For example, if you plan to go out on a
date in a cukrászda, but it suddenly closes the day before, you won't
reschedule the event to a café - you will reschedule to another
cukrászda. If you planned a date to a Korean restaurant and you have
to reschedule it similarly, the Mongolian restaurant would be a
fulfilling substitute for most people.

As highlighted in our notes, people usually don't go to a cukrászda
because they are hungry - they usually have something to eat at a
restaurant or at home beforehand.

Placing custom orders is only an option - a defining feature of a
cukrászda is that they keep a buffer of some of the most popular
desserts inside a chilled see-through counter that you can choose
from based on visuals (also a unique feature - this is rare in a café).

Of course some of the desserts can only be prepared afresh, so one
can sit down with some salty appetizers until it is ready. In Hungary,
we don't quite have other kinds of "pastry shops" as an alternative, so
it's really not a "30-minute side trip".

craft=patisserie doesn't seem to be an established tag. Also this is
not something like a beekeeper where we can ring the doorbell anytime
to get some honey. Due to health regulations, a "cukrász" (~something
like pastry cook) is not allowed to make desserts at home - she must
operate a kitchen for this purpose. Then for the same reason, no
customers or guests are allowed in the kitchen, there must be a place
where they can be served (at a cukrászda in person or perhaps by delivery).

We did consider possibilities for mapping the kitchen as well (maybe
with the tag similar to what you suggest, or the more established and
related craft=confectionery), but I personally don't find that of
priority for the average map user, we'll see later on.

This itself is a major difference compared to a bakery, because baking
simple flour based breads and simple baker's confections doesn't
command the same number of permits or expertise (and they usually
don't need a chilled counter either).

It is understandable that there will always be corner cases and that
mapping is not 100% science, but this doesn't mean we couldn't even
try to get things right. People may or may not be looking for cafes
that much, because they are pretty common, but a cukrászda is a much
more rare and valuable POI compared to that.

Indeed most single cukrászda does not feature every kind of dessert that
I've listed, but they usually feature many items from multiple categories,
(usually many times the number of possibilities compared to a café
that purchases only the most popular few kinds of desserts from a
cukrászda for offer) and if we only listed the most representative
upper level categories individually, it would still leave lots of
room for mapper error.

Overall, adding cuisine=* (5-10 items listed, some non-pastry) +
shop=pastry + artisan=yes may be a kludgy workaround for a
cukrászat/cukrászda where you can't sit in, but this reasoning would
make shop=confectionery redundant as well. But we still need a
solution for the sit-in kind which is clearly an amenity.

So we'll be thinking about some mapping options and will also discuss
it later on.

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

Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

[bkil]

Actually we have a very similar problem with tagging a "Tejivó" in
Hungary (literally a "place to drink milk"). It's conceptually very
similar to a café (coffeehouse...), but the coffee offering isn't that
pronounced (other than using their own milk). Rather, they serve a
huge variety of dairy based products, all artisanal made from their
own organic milk, including drinks, cheese, sandwiches, pastry and
desserts. I think people prefer to go there for their artisanal
desserts. Although, I guess they do keep in stock some non-artisanal
products as well.

This all makes them much closer to a traditional "cukrászda" than a
"kávézó", although the difference is moot as we don't have a way to
tag "cukrászda" anyway at the moment.

Here's their menu:
http://cserpestejivo.hu/menu.php

On Mon, Jun 29, 2020 at 2:45 PM Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> > On 29. Jun 2020, at 14:12, Andrew Harvey  wrote:
> >
> > So we have a first level tag for fruit_tea, purple_yogurt, milk_tea, 
> > bubble_tea, fresh_squeezed_juice, blended_juice, milkshake, smoothie? It's 
> > too long tail and breaks down when you have a shop that sells a mixture of 
> > those instead of just one, a single primary tag for all of these is better.
>
>
> what I wrote was that I believe subtagging is an option, but that it will / 
> should not be a subtag for a (yet to introduce according to you) tag 
> shop=drinks
>
> We will not get main tags for purple yoghurt or fruit tea, because there 
> aren’t such places (at least I have never heard of places specializing in 
> these, unlike bubble tea, which apparently is a thing).
>
> 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] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

> That's what cuisine=* is for.  That's what Google is for.  That's what Yellow 
> Pages is for.  That's what TripAdvisor is for.

Yes, I've been wondering why we keep adding streets and POI to OSM, I
thought that's what Google Maps is for.

Now seriously, OSM has a great advantage of not favoring only
motorists and that the schema (and its POI set!) can be extended based
on demand - by the people, for the people. This clearly sets the two
aside and it has been one of the top arguments I use when I call for
supporting OSM (but see also: tracking, offline usability, ...).

Why keep data together in a database if you could get the same
information from randomly scattered sources? Clearly a database
carries value - it is protected by EU database rights as well (they
are probably protected in the UK as well _somehow_).

Surely I'm not saying that we should pour everything into OSM. That's
why we have outside links to Wikipedia and Wikidata. But the most
basic information must be present for each POI (=point of public
interest): it's position (making OSM a geo-database) and something
that carries an identification, like it's name, contact:website with
more information and the type of POI, possibly for the benefit of
foreigners or if it can't be inferred from the name, or if multiple
things with the same name can be found at roughly the same position.

If we already add a type, why can't we make it right? Why not use such
a taxonomy that makes sense, enabling interpretation for both locals
and internationally? It's not like I advocate adding dozens of useless
extra tags - I'm advocating replacing an ill-defined or ill-fitting
word with another word that fits the type better. This doesn't carry
that much of a database overhead. Now compare this to if we always had
to list the full menu of a place so searching could be made operable.
This would also be a nightmare from the perspective of keeping the
data up to date as discussed in some previous threads.

It is considered best practice to tag the type of POI in such a way
that people (and machines) are allowed to understand the basic essence
(primary purpose) of a given place just by looking at the semantic
tags (so minus the name and strapline).

I'm still not sure how we should tag a cukrászda around the world and
I haven't made a concrete suggestion for this yet, but I'm positive
that users are looking for this and deserve the right to be able to
search for it _somehow_. Mappers deserve the right to be able to tag
what they see on the ground. People wasting time searching for
workarounds to tag a curkászda means that they care enough. Why should
users again waste more time when they are trying to use the data that
mappers have scrambled on purpose?

From a perspective of local knowledge, I had to point out the
workaround of using amenity=cafe + cuisine=* for many years now to
well experienced OSM editors with thousands of edits around the world,
because they wouldn't have otherwise thought of this (but then they
also disagreed with this concept). How would I then expect a novice
mapper or a navigation user to have figured this out then? This also
shows that in the minds of people familiar with the concept, a bakery,
a café, a cukrászda and a sweets shop are all very different things.
Hence after all these years, I came to admit that I was wrong and this
workaround doesn't work, so I stopped recommending it. Sometimes we
have to admit that we were wrong and move on to the right direction -
this is what agility is about.

On Sun, Jun 28, 2020 at 9:05 PM Paul Allen  wrote:
>
> On Sun, 28 Jun 2020 at 18:51, Gábor Fekete  wrote:
>
>> Me too.  A cukrászda is definitely not a cafe in my opinion. A cukrászda 
>> surely offers a wide variety of self-made sweets, probably coffee too. A 
>> cafe, tagged with cuisine=cake, probably has a limited selection of cakes 
>> (from unknown source).
>
>
> So one offers home-made cakes and the other may offer home-made cakes
> (the few cake-only cafes I'm aware of around here offer home-made
> cakes) or may not.  I'm not sure that merits a different value of main
> tag.  They both sell cakes.
>
>>
>> And what about the tourist, who makes a 30-minute side trip to go to a 
>> coffee shop to eat some sweets, and finds only two kinds of marlenka in a 
>> paper box?
>
>
> That's what cuisine=* is for.  That's what Google is for.  That's what Yellow 
> Pages
> is for.  That's what TripAdvisor is for.
>
>>
>> I share the opinion that some cukrászdas are not shops, they should be 
>> tagged as amenity (but not amenity=cafe).
>
>
> From where I'm sitting, they quack like cafes.  Cafes with very limited 
> choices of
> cuisine, but still cafes.  Some of them are cafes selling home-made products,
> but they still quack like cafes.  They are cafes I would avoid 
> (diet-controlled
> diabetes) just as I would avoid vegetarian cafes (I don't like their menus) so
> I would be delighted to find those things specified by cuisine=* so I could
> avoid 

Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

Okay, so at least now I better see where the misunderstanding stems
from. Let's get some facts straight. It may be true that almost all
words in OSM are interpreted within British English, but amenity=café
is an exception (we've decided to leave out the accent for the benefit
of the international community).

Other than the accidental clash in wording, it doesn't refer to a
British cafe, greasy spoon or a diner - without having visited one of
those, I'd probably simply tag those as amenity=fast_food.
https://en.wikipedia.org/wiki/Cafe (redirect to coffeehouse)
https://en.wikipedia.org/wiki/Cafe_(British)
https://en.wikipedia.org/wiki/Greasy_spoon
https://en.wikipedia.org/wiki/Diner

Let me share some proof to consider.

If you refer to:
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcafe

> amenity=cafe (café) is for a generally informal place with sit-down 
> facilities selling beverages and light meals and/or snacks. This includes 
> coffee-shops and tea shops selling perhaps tea, coffee and cakes through to 
> bistros selling meals with alcoholic drinks."

This highlights the fact that we've introduced this kind of amenity to
tag a café or coffee-shop as per the text and Wikipedia.

The pictures all show coffeehouses.

The proposed icon that shows the most prominent feature of this
amenity depicts a coffee mug.

You can verify that this was the original intention and original icon
of the creators as well:
https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dcafe#Voting

If you think the community should reserve the tag amenity=cafe for
diners and British cafe, what tag do you think the rest of the world
should be using for their hundreds of thousands of coffeehouses?

As mentioned by Feket, a coffeehouse usually also has something to "go
with" your coffee, tea or other beverage, like a sandwich, a snack or
even a piece of pie or cake they purchased (possibly from a
cukrászda). Most small cafés around here usually lack a kitchen in
which they could cook hot meals. I think offering something quick and
simple like an omelette mentioned on the talk page could also be
plausible, but people definitely aren't coming here for the food.
However, it is not unheard of in Hungary that you could enjoy a 2-hour
limited-time daily lunch:menu=* meal in a café or in a drink-only pub
that they also order from outside kitchens (I also have some
description of this custom if you are interested - the source page has
recently been vandalized).

This also brings us back to amenity=fast_food:
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfast_food

> Fast food is for a place concentrating on very fast counter-only service and 
> take-away food.
>
>The food has a short preparation and serving time, usually because it is 
>industrially prepared food and requires very few additional preparation steps. 
>Food is typically served on disposable plates or in boxes, and often to be 
>eaten with plastic cutlery. Food is typically paid for at the counter prior to 
>consuming. There may be sit-down facilities ranging from one or two to many 
>easy-to-clean chairs and tables.
>
>The most obvious examples are the ubiquitous US chains such as McDonald's, but 
>also includes places like Subway sandwich shops, and may include "fast casual" 
>places like Chipotle Mexican Grill, Hot Dog booths, China take away, 
>carts/food trucks (only ones that appear regularly at the same place) and more.

https://en.wikipedia.org/wiki/Fast_food_restaurant

> A fast food restaurant, also known as a quick service restaurant (QSR) within 
> the industry, is a specific type of restaurant that serves fast food cuisine 
> and has minimal table service. The food served in fast food restaurants is 
> typically part of a "meat-sweet diet", offered from a limited menu, cooked in 
> bulk in advance and kept hot, finished and packaged to order, and usually 
> available for take away, though seating may be provided. Fast food 
> restaurants are typically part of a restaurant chain or franchise operation 
> that provides standardized ingredients and/or partially prepared foods and 
> supplies to each restaurant through controlled supply channels. The term 
> "fast food" was recognized in a dictionary by Merriam–Webster in 1951.[1]
>
>Arguably, the first fast food restaurants originated in the United States with 
>White Castle in 1921.[2] Today, American-founded fast food chains such as 
>McDonald's (est. 1940) and KFC (est. 1952)[3][4][5][6] are multinational 
>corporations with outlets across the globe.

Note that illustrations depict Burger King, McDonald's and a fish and
chip shop in England, and that the icon generally depicts a fast food
item like a burger. It is true that there exist such small fast_food
restaurants that they operate from a vehicle and they may only have
tables, but no seats (takeaway=only and/or capacity=0), but this is a
minority. The vast majority do have at least picnic table kind of
seating outside, and ones residing within buildings 

Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

Thank you for your additions regarding Italy and Germany, I've copied
your insights into the document.

So to summarize, we started to debate this around 2011 before you
introduced shop=pastry and then had some more discussions in 2016,
2018 and this year too. We've also experienced the shop=confectionery
vs. shop=pastry debate back then and ever since had been wondering
what the exact definition of shop=pastry is around the world.

We are leaning towards being dissatisfied with tagging as either
shop=pastry or amenity=cafe. I think we would need some more input
from other nations before we can proceed to discuss the recommended
tagging. It would be great if we could only focus on each nation's
specialty in this thread and not be carried away by existing tagging
conventions.

If you are interested, let me share just a few corner cases based on
the linked shared notes. It would be perfectly normal for a sit-in
cukrászda to not offer coffee or wifi at all or lack table service. In
contrast, a data user would rightly have the expectation of finding a
somewhat wide variety of coffee at a cafe returned in the search
results.

Also, how would you customize the map icon? The cuisine tag within a
cafe could contain a lot of elements. What would differentiate between
a cukrászda and a cafe for either the renderer or a search engine,
*pastry*? As described in the shared notes, it's common for a cafe to
serve at least one kind of sliced cake along with coffee (possibly
purchased from either a cukrászda or from some industrial source). A
cukrászda that is artisan can by default accept custom orders for
cakes, while that can't be said about a cafe. How would I find this on
a map if the two were combined?

After consulting the OSM wiki and Wikipedia, I had to conclude that
"pastry" is too narrow of a category to be useful for us. As
previously mentioned, a cukrászda also carries a wide variety of
desserts, including sugar confections, flour confections (pastry),
non-dough based desserts, liquid desserts, ice cream, salty snacks and
possibly also sandwiches. If during the discussion we find an overlap
in meaning with shop=pastry, at the very least, we should introduce a
new tag (e.g., shop=dessert) and specify the kind of desserts it
carries (sugar confections, pastry, cake, ice cream, etc.) and
deprecate the redundant old top level tags.

In Hungary, shops selling non-artisan sugar confections ("sweets
shops") is rare. Ones selling mass-produced, non-customizable pastries
even more so (if they exist at all other than in supermarkets). On the
other hand, even smallish villages can support a fancy cukrászda
producing various desserts along with a few more bakeries that also
produce simple sweet pastry. Around here, a bakery producing sweet
pastry (pretty common) is not the same as a cukrászda.

We list many more arguments in the linked document if you are interested.

On Sun, Jun 28, 2020 at 3:02 PM Martin Koppenhoefer
 wrote:
>
> FWIW, the tag shop=pastry was introduced for these, because the tag that was 
> in use up to then was shop=confectionery where the term seemed to describe a 
> sweets shop. Now, pastry is probably a term which covers just a part of all 
> these, literally. In general, it may also be a question what you want to 
> describe, naturally, all of these sell different kind of products, according 
> to the local tradition.
>
> Generally, in Italy the term is "pasticceria" and also "gelateria" (artisanal 
> ice cream maker), as the latter are officially considered a subtype of 
> "pasticceria" (you can also often/sometimes find pasticcerias which sell 
> icecream they produce during the summer, although many gelateria shops will 
> only sell ice cream, or might additionally sell sweet bakery which includes 
> ice cream, e.g. semifreddo (half cold), ice cream sandwiches, etc..
>
> Sometimes, there are mixed places, which sell both, bread and salty bakery 
> together with sweet bakery (typical in Germany), and there are of course also 
> huge differences in the types of products ("simpler sweet bakery will often 
> be present in a pasticceria, while more sophisticated products may be more 
> probably limited to "pure" pasticcerias (or Konditorei in Germany). A normal 
> "bakery" in Germany will usually also sell simple sweet bakery products 
> ("Kuchen"), while a "Bäckerei Konditorei" will more probably have a bigger 
> selection and more elaborated "Torten".
>
> One distinction (subtag / property) could be whether they have products with 
> cream, or more stuff like cookies.
>
> Furthermore, there are also pasticcerias which specialize in regional 
> products (e.g. pastry from Sicily, also outside of Sicily in other places, 
> e.g. Cannoli: https://en.wikipedia.org/wiki/Cannoli e Cassata 
> https://en.wikipedia.org/wiki/Cassata and cassatina: 
> https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Ftse1.mm.bing.net%2Fth%3Fid%3DOIP.qhDcBUpJMzoRMX2LNVi51wHaE-%26pid%3DApi&f=1
>
> Also in Germany (and p

[Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

[bkil]

Hello,

I'd like to ask your help in improving the definition of the venue
mostly serving self-made artisanal desserts that I describe at the end
of this message.

Before we discuss possible tagging solutions (we will probably need a
new tag), we would like to have some input from mappers in other
Central European countries where they also have such an amenity.

It would be good to know what these terms mean in your culture and if
you could please share an objective definition of how you recognize
it.

Unfortunately, this can be considered a local specialty in so many
levels that even wikipedians struggle with consistent wording, setting
up of language links and wikidata across the various terms. Hence some
cross-cultural collaboration would be in order and it would be best to
eventually fix this in Wikipedia as well.

After gathering information on this topic from various sources and
conducting a few discussions, we came to the conclusion that it is
possible to reliably differentiate between a bakery, a cafe, a
restaurant, a fast food place, a sweets shop (selling conserved,
wrapped, mass manufactured goods) and a cukrászda (both sit-in and
take away types).

Please refer to my notes where I try to enumerate the properties of a
typical cukrászda and if possible, please be at least as explicit in
the definition that you share about your national variant.

https://wiki.openstreetmap.org/wiki/User:Bkil/amenity%3Ddessert#Attempted_work_in_progress_definition_for_mapping

>From Hungary, with Love
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Public WLAN boxes

[bkil]

keep in mind from the side
of the community when mapping things within OpenStreetMap. I think
I've also read a few mailing list threads, forum topics, FAQ entries
and whatnot in the past about just this, just ping me if you'd like to
refer to some of them and I'll try to find them for you.

So to sum it up, you may map whatever you desire until you follow
(additional to the usual best practices):
* use abstraction
* honor public interest
* allow maintainability
* don't clash with others
* don't disappoint users
* discuss with the community


On Mon, Dec 30, 2019 at 10:40 PM Warin <61sundow...@gmail.com> wrote:
>
> On 30/12/19 21:31, bkil wrote:
> > We have similar services to those, but I wouldn't map those. If you
> > subscribe for a high enough tier of Telekom Internet, you get access
> > to FON. If you subscribe to UPC and enable it on your modem, you get
> > access to UPC Wi-Free.
> >
> > We must not map these because these are not hotspots of public interest.
>
> If someone wants to map them they can. Not up to you or me to dictate
> what can go into OSM.
>
> It it easy enough to find some of them here .. most public phone boxes
> have them together with visual signs to let you know of the service.
> If you have meet the requirements then having the information in OSM
> enables you to make your own map of the service.
>
> Some think mapping private swimming pools should not be done. Yet in my
> country these are used to fight fires and as such form a usefull public
> emergency resource.
>
> I suppose you don't map private houses, private farms, private roads
> (driveways) etc etc...
> There  many 'private' things already present in OSM.
>
>
> ___
> 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] Public WLAN boxes

[bkil]

We have similar services to those, but I wouldn't map those. If you
subscribe for a high enough tier of Telekom Internet, you get access to
FON. If you subscribe to UPC and enable it on your modem, you get access to
UPC Wi-Free.

We must not map these because these are not hotspots of public interest.
You can not simply pay a given sum of money (or register for free) to
connect - if you don't live in a house where there is Telekom/UPC coverage
or you don't want to sign up for years of commitment - you're out. Also FON
has their own map, so similar to campus Wi-Fi, those who have access
already know where to look for it (this was a phrase on the wiki in the
past).

We must only map points of public interest, this is why we map neither home
water taps, nor encrypted home Wi-Fi. This is not my opinion - these are
the established practices of mapping - do tell me if this policy changes,
because I wouldn't mind mapping these myself.

FVGWiFi is a bit different that you don't need any serious commitment to
get access and it is indiscriminately accessible for anyone living in the
country, hence I think it qualifies as being of (local) public interest and
is mappable.

We had similar, but less restrictive network providers in Hungary in the
past, for example WifiZone and Wiera, not sure if they are still free.
Certain municipalities also operate dozens of protected hotspots in their
own district/town, I guess they have similar limitations so we could map
them with the same tags after we invent the missing keys.

On Mon, Dec 30, 2019 at 9:56 AM Warin <61sundow...@gmail.com> wrote:

> Some have no fee as such but linked to you opening your home wifi for use
> by others (telstra Australia do such a thing).
> I prefer access=private.
>
> On 30/12/19 09:40, bkil wrote:
>
> Okay, I guess customers may be getting a bit closer, although we would
> still need to convey somehow that not everyone can be a customer (for
> example no tourists) and that I can't just show up in person to volunteer
> to be a customer as wit ha cafe - I need to do my "homework" of registering
> at home or at another hotspot.
>
> Be advised that I wrote many parts of that wiki page, including that
> phrase. It was not part of the original proposal - I've merely documented
> what I found on TagInfo at the given time instance (it occurs 4 times at
> the moment that is below noise level), or at least some of the better and
> more consistent ideas. I'd be open to suggestions for improving any part if
> you see it benefits the community.
>
> I'd like to point out that the word "charge" around here is mostly used in
> the meaning of replenishing electric charge into the battery of a device.
> It is so widely used in this sense that even many of those understand it
> who don't speak English! In this context, I think it could be confused with
> amenity=device_charging_station, although I acknowledge that a mapper needs
> a certain amount of ingenuity to mix this up.
>
> On Sun, Dec 29, 2019 at 10:36 PM marc marc 
> wrote:
>
>> Le 29.12.19 à 21:50, bkil a écrit :
>> > fee=no @ register with an Italian phone number
>>
>> it seems to indicate that it's fee=yes if you don't register,
>> which doesn't seem to fit with what you're saying.
>> I prefer :
>> internet_access:fee=customers (you need to be a customer of it... some
>> use access for that)
>> internet_access:fee:amount=0 (the wiki suggest this key but
>> internet_access:charge is imho better)
>> internet_access:description=*
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> 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] Public WLAN boxes

[bkil]

Okay, I guess customers may be getting a bit closer, although we would
still need to convey somehow that not everyone can be a customer (for
example no tourists) and that I can't just show up in person to volunteer
to be a customer as wit ha cafe - I need to do my "homework" of registering
at home or at another hotspot.

Be advised that I wrote many parts of that wiki page, including that
phrase. It was not part of the original proposal - I've merely documented
what I found on TagInfo at the given time instance (it occurs 4 times at
the moment that is below noise level), or at least some of the better and
more consistent ideas. I'd be open to suggestions for improving any part if
you see it benefits the community.

I'd like to point out that the word "charge" around here is mostly used in
the meaning of replenishing electric charge into the battery of a device.
It is so widely used in this sense that even many of those understand it
who don't speak English! In this context, I think it could be confused with
amenity=device_charging_station, although I acknowledge that a mapper needs
a certain amount of ingenuity to mix this up.

On Sun, Dec 29, 2019 at 10:36 PM marc marc 
wrote:

> Le 29.12.19 à 21:50, bkil a écrit :
> > fee=no @ register with an Italian phone number
>
> it seems to indicate that it's fee=yes if you don't register,
> which doesn't seem to fit with what you're saying.
> I prefer :
> internet_access:fee=customers (you need to be a customer of it... some
> use access for that)
> internet_access:fee:amount=0 (the wiki suggest this key but
> internet_access:charge is imho better)
> internet_access:description=*
> ___
> 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] Business names in capital letters

[bkil]

I find it amusing that some of the other big map providers have chosen a
different "canonical" capitalization of the same trademarks. So they either
are not canonical after all, or we misunderstood the meaning of the name=*
key all along. I think when deciding such issues, we would need to share an
established path of reasoning and/or reliable references.

We had the same argument over a local mailing list and another idea came
up: some of the signage you see and many of their own website use the given
capitalization for stylistic purposes. But the question remains: why isn't
a map using stylistic capitalization? Or as some others do, why isn't
OpenStreetMap using it?

The signs, official company registry documents, websites, receipt, press
releases, newspapers and Wikipedia sometimes contradict (Wikipedia
notoriously even within itself, so don't use that as a reference), while at
other times the mostly match. What do you think about these?

ALDI:
Albrecht-Diskont
https://en.wikipedia.org/wiki/Aldi#History

Lidl:
Ludwig Lidl
https://en.wikipedia.org/wiki/Lidl#History

SPAR, SPAR express, DESPAR, etc.:
Door Eendrachtig Samenwerken Profiteren Allen Regelmatig
https://en.wikipedia.org/wiki/Spar_(retailer)#Etymology

Obi:
"the name goes back to the French pronunciation of the word hobby"
https://de.wikipedia.org/wiki/Obi_(Baumarkt)#Geschichte

TESCO:
"the initials of the supplier's name (TES), and the first two letters of
his surname (CO)"
https://en.wikipedia.org/wiki/Tesco#Origins


On Mon, Dec 16, 2019 at 9:36 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 15. Dec 2019, at 19:26, Markus  wrote:
> >
> > If we enter names exactly as they appear on signs, we would have to
> > change all place names to all caps in Italy, France and likely in
> > other countries too.
>
>
>
> as a general rule, all names exactly as they appear on signs does not
> work. Name is the common name as decided by the mapper and according to the
> conventions we have set up (e.g. generally no abbreviations, unless the
> name itself is an abbreviation, like AT&T etc.)
> It can still make sense to have a dedicated tag for the name as it is sign
> posted (e.g. there are occasionally typos on signs, and for people that
> don’t know the situation it could be useful to have this information for
> orienteering on the ground), just like we have official_name for cases
> where the common name is different (and a variety of tags for alternative
> names).
> Apparently, name:signed is the most common tag (if I didn’t miss
> something) with currently 551 uses.
>
> For example there can be different name versions on different signs for
> the same feature (e.g. abbreviated and not street names), and even errors
> /typos on signs can occur.
>
> 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] Public WLAN boxes

[bkil]

I probably wouldn't add the antenna tags either, unless it is visible
and useful for navigational purposes. If possible, please add the
network name as well, something like this:

operator=Comune di Cividale del Friuli
internet_access=wlan
internet_access:ssid=FVGWiFi

This is a bit sketchy question, as without additional tags, people
could mistake these for real open hotspots that are open to tourists
as well:

"Places where internet access is only for members or private persons,
and not offered to the general public. This includes your personal
home DSL, LAN, WLAN, any internal networks of companies, and internet
access only for students (e.g., WLAN hotspots on the campus), because
these are not open to the general public."

Although, I think we can rightly map these because it does good
service to the local community, but we should somehow differentiate
it. Maybe like so?

fee=no @ register with an Italian phone number
description=Registration through a live Internet connection and giving
an Italian phone number is required

I've seen other hotspots that also need registrations, but which allow
you to register on site via their walled garden (or endorsing the
operator on social media, etc.). This one is different, because I
think you need to prepare well in advance before going out on the
streets. Maybe we should invent some new tags for this. I found
internet_access:registration=* not specific enough. Maybe
internet_access:registration=in_advance/on_site/no?

Furthermore, linking to information regarding how you can freely
register may prove useful (although viewing that needs an Internet
connection as well..), like:
contact:website=http://www.regione.fvg.it/rafvg/cms/RAFVG/infrastrutture-lavori-pubblici/telecomunicazioni/FOGLIA5/
(Or would operator:website be more appropriate?)

Someone has been attempting to use amenity=internet_access,
amenity=wifi (sic!) or service=internet_access as a primary tag, but
it is not established yet - internet_access=* usually comes second to
some other primary tag (like leisure=park, amenity=bench,
amenity=cafe, highway=footway, etc) indicating what kind of function
the access point is attached to (roughly the scope of operation or
"range", although we are not allowed to map the exact range itself).

Finally, could you by any chance get in contact with the operator and
ask if we could import the data behind their access point map?

Thanks for the great efforts - if we could find answers to the above,
we'll be able to map a lot of similar networks in the future.


On Wed, Dec 18, 2019 at 11:23 AM Cascafico Giovanni  wrote:
>
> Hello ML,
> which tags for those boxes, usually on pole or wall mounted which
> provide free public WLAN access? In my area they are managed by
> municipality and are subject to registration.
>
> My tagging would be:
>
> man_made=antenna
> operator=Comune di Cividale del Friuli
> antenna:application=wlan
> internet_access=wlan
> fee=no
>
> ___
> 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] szekler_gate vs. szekely_gate?

[bkil]

Just a quick question to some native speakers, which one would you
understand as more correct?

artwork_type = szekler_gate
tourism = artwork

vs.

artwork_type = szekely_gate
tourism = artwork

For describing the following very common objects in central Europe:
https://commons.wikimedia.org/wiki/Category:Sz%C3%A9kely_gates
https://hu.wikipedia.org/wiki/Sz%C3%A9kelykapu

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

Re: [Tagging] lit=yes/no threshold

[bkil]

In many parts of Hungary, vegetation can overshadow street lights,
especially if they are placed high enough. They may make efforts to
protect roads against this, but they rarely consider footways. Hence I
know a lot of streets where road illumination is fair, but the
sidewalk right beside it (maybe 1-2m from the road) is dark along the
majority of the road.

I also agree with Martin's definition of being lit and I usually do it
like that.

I don't split ways by the centimeter to specify illumination - if a
stretch of path has too many shadows, you need to bring your own
lights anyway, so I consider that not being lit.

On Sat, Jul 6, 2019 at 2:39 PM Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> > On 6. Jul 2019, at 14:07, Tobias Zwick  wrote:
> >
> > The least subjective definition is to map the physical presence of street 
> > lanterns on the way, not the light they emit. (This definition (though) 
> > would mean that a footway close to a lit street would be mapped as unlit as 
> > long as it does not have own lanterns.)
>
>
> the presence of street lights indicates the road could be lit, it has no 
> implications whether it is actually lit. For example last summer I went to an 
> island where all streets had relatively new street lights, but half the 
> island they kept them off so that light pollution was reduced.
>
> In small villages in Germany, street lights are often turned off at a certain 
> time (e.g. after 23h), etc.
>
>
> 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] New sections added to "Good Practice" page?

[bkil]

Floating restaurants, hotels and event halls are pretty common in
Budapest. Some fancy ones even offer budget daily lunch menus.

https://www.a38.hu/en

If we interpreted the intention, semantics and usage patters of
building=* in OSM, we could use something like building=boat,
building=caravan or building=vehicle, but it is unfortunate that none
of these can be understood to be buildings in any sense of the word.
We would need something like:
housed_in=vehicle
contained_in=vehicle
enclosed_in=vehicle
hosted_in=vehicle

This seems to be the most generic term that applies:
structure=vehicle/boat/cart/tent/building/...
https://en.wikipedia.org/wiki/Structure#Load-bearing

On Sat, Jul 6, 2019 at 1:26 AM Fernando Trebien
 wrote:
>
> On Mon, Jul 1, 2019 at 5:33 PM bkil  wrote:
> > Be my guest:
> > intermittent=yes
> > ephemeral=yes
> > building=no
> > permanent=no
> > movable=yes
> > stationary=no
> > caravan=yes
> > mount=trailer
> > support=wheels
> > foundation=no
> >
> > https://en.wikipedia.org/wiki/Floating_restaurant
> > https://en.wikipedia.org/wiki/Houseboat
>
> Pure fun. Closest I've ever done was a floating restaurant [1], which
> had been there for 6 months when I mapped and is there ever since, but
> could be gone tomorrow. Also, where I live, there are many weekly
> public markets licensed by the prefecture. The main one is a major
> meeting point for the locals [2]. The only thing you find there during
> weekdays are the signs stating the name, time and location of the
> event.
>
> caravan=* is related to access rights [3].
>
> [1] https://www.openstreetmap.org/way/560511031
> [2] Main one: https://www.openstreetmap.org/node/2267135759
> [3] https://wiki.openstreetmap.org/wiki/Key:caravan
>
> --
> Fernando Trebien
>
> ___
> 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] New sections added to "Good Practice" page?

[bkil]

Be my guest:
intermittent=yes
ephemeral=yes
building=no
permanent=no
movable=yes
stationary=no
caravan=yes
mount=trailer
support=wheels
foundation=no

https://en.wikipedia.org/wiki/Floating_restaurant
https://en.wikipedia.org/wiki/Houseboat

On Mon, Jul 1, 2019 at 7:30 PM Fernando Trebien
 wrote:
>
> On Sat, Jun 29, 2019 at 7:58 PM Joseph Eisenberg
>  wrote:
> > 2) "Don't map insignificant, perishable and mobile object"
> >
> > This is certainly true, but it duplicates advice in the previous
> > section, so I've removed it.
>
> I think the existing advice was better indeed, so +1 for removing this.
>
> > 1) "Check the history of important objects"
> >
> > "Before making significant changes to important objects (in particular
> > settlements, administrative boundaries, major buildings, tourist
> > attractions,long route relations etc), check their history. Who did
> > this and why? Was this an experienced contributor or a newbie?
> > Previous editors may have valuable insights to offer on why things are
> > currently tagged the way they are."
> >
> > I don't find this information helpful for new mappers.
> >
> > What is the "history" in this context? I don't think it would be clear
> > to new mappers - it seems to suggest changeset comments
> >
> > What is an "important object?"
>
> I think I see what concerns that mapper as important. I've seen new
> mappers deleting place nodes by accident and reinserting them,
> creating objects that are not linked to the edit history of the former
> objects. Of course, I've also seen this with less salient features
> too.
>
> While OSM does not have the concept of notability, some kinds of
> mistakes prompt the community more readily than others. For example,
> accidentally removing part of a motorway is likely to be discovered
> and fixed very fast (also making some people a little annoyed), while
> accidentally removing part of a residential road may take years to be
> noticed and fixed, depending on the level of OSM contributions (very
> high in Germany, low where I am in Brazil). Errors on administrative
> boundaries often show up while converting the data for offline usage,
> which some apps do daily, but with JOSM and iD today this is not easy
> to do unintentionally. Deleting a tourist attraction also prompts a
> quick reaction, as the attraction is searched way more often than,
> say, the median household building.
>
> I've often been told to explain certain kinds of changes in changeset
> comments. The only way mappers can become aware of such comments is by
> reading the history. Thus, reading the history is good practice, in
> fact for all objects, but it adds a lot of extra work, mostly because
> our current tools cannot display the history of every small object
> (changes to geometry, tags, and changeset comments) in a way that is
> easy/quick to read.
>
> I've often recommended using note=* and source:*=* tags for the more
> important justifications as they are more visible to mappers, but a
> careless mapper may make changes ignoring those as well, as they are
> not very visible in all editors. The wiki prescriptively discourages
> the use of source:*=* since 2016, but the OSM Tag History service
> tells me that usage of source:*=* tags continues to increase
> worldwide, so I'm note sure it can really be described as a
> "historical" practice.
>
> --
> Fernando Trebien
>
> ___
> 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] Which global OSM mailing list for the "community index"?

[bkil]

1. Although, just copying the archive may not seem to add too much
value, I do see the potential improvement to the forum search index.
However, it would be real useful if this transfer could be automated
and turned into a kind of near-realtime sync. Then all you needed to
implement is reverse sync to forward the replies given on the forum to
the original mailing list. And by that we have created a single
unified platform from two, previously disjoint ones!
2. Repeat for all platforms.
3. ???
4. Profit!!!

On Fri, Jun 28, 2019 at 8:06 AM Frederik Ramm  wrote:
>
> Hi,
>
> On 28.06.19 04:14, Graeme Fitzpatrick wrote:
> > Thoughts?
>
> Very bad idea, is my thought. Copying old threads to forums swamps the
> forums, and gives people there old discussions to look at but in which
> they cannot participate any more, as the authors of whatever arguments
> you post will not be reading the forum. In my eyes, this plan treats the
> forum as second-class and is disrespectful to its users.
>
> 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

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

Re: [Tagging] Tagging Digest, Vol 117, Issue 90, topic 1 & 4: Ban of Ulamm by Woodpeck

[bkil]

If you could give us a link where we can continue this discussion
without being off topic, I'd gladly chime in with my viewpoint. We had
dozens of mail threads on our local list in this topic in the past
with some good pointers as well.

On Tue, Jun 25, 2019 at 8:01 PM Mateusz Konieczny
 wrote:
>
>
>
>
> 25 Jun 2019, 18:34 by ulamm.b...@t-online.de:
>
> We must not publish scans of historical maps as our own work, that could 
> violate copyright.
> But if we use the informations shown in historical maps for free hand 
> drawings, we do not violate the copyright for maps.
>
> [citation needed]
>
> I am pretty sure that rewriting, redrawing, tracing and making other 
> derivative works is not cancelling
> copyright on the original work.
>
> See https://commons.wikimedia.org/wiki/Commons:Derivative_works for 
> exploration about
> this topic in a bit different context, but nearly everything should be 
> applicable and is describing
> situation well.
>
> https://en.wikipedia.org/wiki/Derivative_work is also relatively readable
>
> ___
> 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] Which global OSM mailing list for the "community index"?

[bkil]

I'm thinking more along the lines of:
https://en.wikipedia.org/wiki/Matrix_(communication_protocol)#Bridges
https://en.wikipedia.org/wiki/Friendica#Features
But we're still missing a few. It would be best if we had a single
unified platform (or one for realtime, and one for non-realtime use
cases). Partitioning could still be done using labels/categories
within the platform.

On Sat, Jun 22, 2019 at 10:52 PM marc marc  wrote:
>
> Le 22.06.19 à 10:31, bkil a écrit :
> > I wonder why nobody has created a gateway
> > to merge all discussions
>
> nabble.com/ do the job (but you can only merge ml/forum only
> ___
> 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] paid ferry - fee or toll tag

[bkil]

My answer reflected on Paul's suggestion of introducing yet another term
(fare=*) to more closely match common vocabulary. I wouldn't recommend
merging tolls, sorry if you read it like that.

On Sat, Jun 22, 2019 at 11:10 AM Colin Smale  wrote:

> On 2019-06-22 10:38, bkil wrote:
>
> If we step back a bit from our dictionaries, fee=* as a concept is
> isomorphic to toll=* (and fare) in this context.
>
>
> Only insofar as they indicate that the user has to pay. "Toll" has a
> distinct meaning, in the UK at least, that it is (and needs to be)
> sanctioned by law.
>
>
> As all of them could
> be understood by native speakers and fee=* covers a more general
> category, it is clearly the better choice. If we consider our data
> users, non-native speakers and learning curve, the less terms we use
> in our vocabulary, the better.
>
>
> "As simple as possible, but not simpler". Attributed to Albert Einstein,
> and a philosophy I wholeheartedly embrace. If it is required to be able to
> make the distinction between a charge levied based on a legal sanction, and
> a charge simply levied by the owner because they feel like it, then the
> subtle difference between "toll" and the other words is significant. If we
> all agree that the distinction is not to be represented in OSM, then this
> discussion is moot - call it something neutral like payment, fee, charge,
> whatever. This process is called data modelling; the modelling aspect comes
> from the fact that you have to make compromises, and you have to choose
> which compromises to make according to what is important to you. Otherwise
> you are just replicating reality at full scale, which defeats the point of
> modelling.
>
> As this is OSM, it only takes one person to want to make this distinction
> to unchain interminable discussions...
>
>
> On Thu, Jun 20, 2019 at 11:20 AM Paul Allen  wrote:
> On Thu, 20 Jun 2019 at 01:33, Warin <61sundow...@gmail.com> wrote:
> The Oxford Dictionary says
>
> Toll : A charge payable to use a bridge or road.
>
> Yep.  Also, in the UK, carries legal implications.  Legislation is
> required to require tolls on a
> public highway.
>
> Fee : A payment made to a professional person or to a professional or
> public body in exchange for advice or services.
>
> That's how I'd use it.  Of course, ferries provide a ferry service, so fee
> could be used.  But I'd go
> with something else: fare.  We don't talk of rail tolls or rail fees, we
> talk of rail fares.  We don't talk
> of air tolls or air fees, we talk of air fares.  From OED online: "The
> money paid for a journey on
> public transport."
>
> --
> 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
>
> ___
> 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] About the diaper key

[bkil]

👍


On Tue, Jun 18, 2019 at 4:48 AM Satoshi IIDA  wrote:

>
> As my small contribution, switched to changing_table in a baby care
> proposal page~
> https://wiki.openstreetmap.org/wiki/Proposed_features/babycare
>
>
>
> 2019年6月17日(月) 5:44 Rory :
>
>> Hi,
>>
>> On Wed, 12 Jun 2019 16:14:59 +0200, Valor Naram wrote:
>> > the proposal at
>> > https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table
>> has
>> > been accepted now and I can start with the post-vote process and
>> > creating a wiki page. The property Key:changing_table success the
>> > Key:diaper for now but we or at least I have to deal with the question
>> > "What's going on with the diaper key". The answer seems clear:
>> > Key:diaper is now superseded by Key:changing_table. While it's the part
>> > you CAN definetly answer with ease. The second part properly not. "What
>> > do we do with the POIs having the Key:diaper?"
>> >
>> > I am very excited about hearing your ideas since some of you noted that
>> > just replacing the diaper key and its values with the key and the values
>> > of the new key can be problematic.
>>
>> I suggest finding data consumers (people/apps/sites/software which uses
>> the existing `diaper` tag), and talking to them about supporting the new
>> `changing_table` tag. Likewise talk to data contributors (editing
>> software) and talk them into supporting your new scheme.
>>
>> I really don't think a mechanical edit to change all is a good idea. You
>> can't rely on all data consumers to read all lists & wiki pages, and you
>> risk a data consumer re-adding the `diaper` tag.
>>
>> If no-one's using the `diaper` tag, then why not make or encourage data
>> consumers to support it?
>>
>> Rory
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Satoshi IIDA
> mail: nyamp...@gmail.com
> twitter: @nyampire
> ___
> 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] paid ferry - fee or toll tag

[bkil]

If we step back a bit from our dictionaries, fee=* as a concept is
isomorphic to toll=* (and fare) in this context. As all of them could
be understood by native speakers and fee=* covers a more general
category, it is clearly the better choice. If we consider our data
users, non-native speakers and learning curve, the less terms we use
in our vocabulary, the better.

On Thu, Jun 20, 2019 at 11:20 AM Paul Allen  wrote:
>
> On Thu, 20 Jun 2019 at 01:33, Warin <61sundow...@gmail.com> wrote:
>>
>> The Oxford Dictionary says
>>
>> Toll : A charge payable to use a bridge or road.
>
>
> Yep.  Also, in the UK, carries legal implications.  Legislation is required 
> to require tolls on a
> public highway.
>
>> Fee : A payment made to a professional person or to a professional or public 
>> body in exchange for advice or services.
>
>
> That's how I'd use it.  Of course, ferries provide a ferry service, so fee 
> could be used.  But I'd go
> with something else: fare.  We don't talk of rail tolls or rail fees, we talk 
> of rail fares.  We don't talk
> of air tolls or air fees, we talk of air fares.  From OED online: "The money 
> paid for a journey on
> public transport."
>
> --
> 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] Which global OSM mailing list for the "community index"?

[bkil]

We should probably list the OSM Forum as well then. OSM Help also uses
your OSM credentials. OSM IRC channels do not need credentials - a
random alias is sufficient.

The OSMF link seems to be more about donations than giving a hand.

I'd funnel using these two categories:

Primary:
* OSM Help
* OSM Forum
* OSM Talk mailing list
* OSM IRC channel

Secondary:
* Reddit
* Facebook
* Telegram
* Discord
* Twitter
* OSMF website

Although, I wonder why nobody has created a gateway to merge all
discussions to a single platform (or at most two platforms).

On Fri, Jun 21, 2019 at 8:08 AM Peter Elderson  wrote:
>
> You can use your OSM account to access the osm-forum 
> https://forum.openstreetmap.org/
>
> Vr gr Peter Elderson
>
>
> Op vr 21 jun. 2019 om 06:26 schreef Graeme Fitzpatrick 
> :
>>
>>
>>
>> On Thu, 20 Jun 2019 at 20:01, Frederik Ramm  wrote:
>>>
>>> Hi,
>>>
>>> in parts of the world for which no particular national/regional
>>> resources have been defined, the "id" editor will suggest to get in
>>> touch with "us" and/or other mappers through:
>>>
>>> * Reddit
>>> * Facebook
>>> * Telegram
>>> * Discord
>>> * Twitter
>>> * OSM help
>>> * OSM IRC channel
>>> * OSMF website
>>
>>
>> This is sort of a continuance of the conversations following Simon's post 
>> last week about too much traffic on the list!
>>
>> The problem I have with most of those options (Reddit, Facebook, Discord, 
>> Twitter, & also the mailing lists) is that you need to sign-up to them. I 
>> don't know IRC works & I don't even know what Telegram is!
>>
>> As someone said last week, it would be good if the simple act of creating an 
>> OSM account to edit the map, also gave you access to the "forum" or 
>> whatever, to ask for help, give advice to others, discuss new tags, have 
>> local conversations & so on.
>>
>> Personally, I think that we should be making much more use of the existing 
>> Help forum, with a complete redesign of the first page, to break things up 
>> into "lounges", as per other forums eg http://fordforums.com.au/index.php
>>
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[bkil]

This is what you are looking for, it has been used 160 times:
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Ddevice_charging_station

Although, I'd probably just unify this with amenity=charging_station
and always specify the socket type and voltage. You should only
navigate to a charging station that has a compatible socket anyway.

I usually mark the available sockets using power_supply=* on cafes and
pubs where I can charge my computer or phone without guilt. It can be
useful for both mapping parties and drone photography.

On Sat, Jun 22, 2019 at 6:59 AM Warin <61sundow...@gmail.com> wrote:
>
> On 22/06/19 11:24, marc marc wrote:
> >> waiting areas often have specific locations
> >> to charge electronic devices.
> > https://wiki.openstreetmap.org/wiki/Tag%3Aamenity%3Ddevice_charging_station
> >
> >   >  amenity=charging_station <> amenity=power_supply
> >
> > some normal electrical outlets allow cars to be charged
> > and some charging terminals use normal outlets.
> >
> > I think we're gonna to do it in two proposals:
> > - get amenity=power_supply adopted
> > - try to harmonize how the type of socket/plug is described.
> > socket key is probably the most successful but for charging stations,
> > the information is missing if it is a plug or a plug at the end of a
> > cable on the terminal side.
>
> What is really being tagged here?
>
> The socket.
>
> So tag "electrical_socket=USB/*"??
> That clearly says what it is, not a power generating station or some other 
> thing that could be construed in to a 'power supply'.
>
> Add tags access=customers/* fee=no/yes/* and
> for the detailed types of mappers voltage=*, frequency=*.
> The type of socket will usually determine the maximum current/power so I'd 
> not tag that.
>
>
>
> ___
> 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] A modest proposal to increase the usefulness of the tagging list

[bkil]

On Wed, Jun 5, 2019 at 6:05 AM John Willis via Tagging
 wrote:
> On Jun 4, 2019, at 2:40 PM, Mateusz Konieczny  wrote:
>
> Or you will use.
> Thanks for handling man_made bridge. I use it a lot.
>
> The only comment to this idea of “make tags for you to use” is that if you 
> invent a tagging method for a particular type of object, that you include 
> similar objects that people would like to map to avoid tag fragmentation.
>
> If you propose amenity=foobar, I expect you to consider a subtag like 
> foobar=* or foobar:type=* to be able to define different types of the foobar 
> people encounter.
>
> if you are proposing a new tag foo_bar=* to handle x, y, & z, I expect you to 
> consider l,m,n,o & p as well - even if you don't use them -  because trying 
> to get them “approved” later is very difficult, and people will use incorrect 
> tags on objects just to complete mapping if that is the case.
>
> the Tagging mailing list extends the **tagging system**, It’s not just for 
> solving a single particular mapping issue for an individual.
>
> Tags can be extended later, but it means convincing people to support a 
> sinlge tag value they don't care about individually or don't understand the 
> usefulness of, when it probably would have easily been approved without 
> objection if it was included in the original proposal. the golf=cart_path 
> recently comes to mind.
>
> Javbw
>

Agreed on all points.

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

Re: [Tagging] Tagging buildings that people work in

[bkil]

I feel your pain. To solve this, you need to fill in the In-Reply-To header
with the message-id of the message you are replying to. I don't use digest
mode on the tagging list (I use folders and filters instead), but you
should find the message-id somewhere in the message. If it is missing, you
can find it online in the archive by clicking on the first link on this
page pointing to the sender's e-mail address:

https://lists.openstreetmap.org/pipermail/tagging/2019-June/045861.html

This will open up a message compose window with fields filled in correctly.
If your MUA does not support gathering the In-Reply-To value from the link,
you can copy&paste it manually from the link after setting it up:
https://superuser.com/questions/1177870/how-to-manually-set-the-in-reply-to-header-in-thunderbird
https://www.pixelbeat.org/docs/thunderbird-threading.html

On Sat, Jun 1, 2019 at 8:39 PM ET Commands  wrote:

>
> > Date: Sat, 1 Jun 2019 10:01:13 +0200
> > From: bkil 
> > To: "Tag discussion, strategy and related tools"
> >   
> > Subject: Re: [Tagging] Tagging buildings that people work in
> >
> [...]
>
> > Also, currently I see each of your replies as a new message thread,
> > unrelated to one another. Could you please use message threading (I
> thought
> > that clicking on the 'reply' button would have done the right thing)?
> > https://support.mozilla.org/en-US/kb/message-threading-thunderbird
>
>
> Thanks for pointing me to the Thunderbird support site.
>
> I get my mailing list messages in digest form.  When I want to reply to
> a message, I strip out all the other messages from the digest except the
> one I'm replying to.  Not sure message threading would help me.
>
> Also, thanks to everyone who took the time to send me their comments
> about tagging "occupied" buildings.
>
> Mark
>
>
>
> ___
> 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] Tagging buildings that people work in

[bkil]

Sorry if I didn't make myself clear in formulating the questions, I'll try
to rephrase my inquiries again below.

On Wed, May 29, 2019 at 8:09 PM ET Commands  wrote:

> > Date: Fri, 24 May 2019 20:34:52 +0200
> > From: bkil
> > Subject: Re: [Tagging] Tagging buildings that people work in
> >
> > landuse=* seemed appropriate for most use cases I have encountered. Why
> do
> > we need to tag this on a building resolution?
> Because landuse is for the entire property a building sits on, not the
> building itself.
>
>
You've described the difference between specifying the high level landuse
in an area (that may be even a few blocks large) compared to the proposed
micro-mapping on buildings. This is correct, but I would like to know the
reason, meaning what advantage would such a resolution carry to the map
consumer?

> What data consumers did you have in mind?
> Mapmakers.
>
>
Being a mapmaker is a profession - they make maps for a given audience, for
a given user group or a given task. Specifically, by data consumer we mean
a downstream project that offers services based on OSM data, commonly in a
slippy-map format, but sometimes aggregating statistics or joining data
from various places, providing better insight or an index.

For example, given the height of a building or the number of floors or its
colour, there exist applications that can show a 3D map or even generate
game scenery from real cities. By adding a proper digital elevation model,
you could envision the use of this information for radio antenna link
planning as well. Tagging the kind of sports played in a recreation centre
or in a bar makes it available for map queries (where is the nearest place
I could play pool at?).

It's not a problem if there doesn't exist any data consumers for a new
notation and you don't want to implement any either - I'm just curious
whether you could come up with a plausible one to be created in the future.

Reading this answer together with the next one makes me feel as if we
should map this for the general renderer and "just because we can"
(although we probably can't as per my other points), but I hope I'm reading
you incorrectly. We could use line laser scanners to reproduce roads to
submillimeter accuracy, but we don't do that - instead we take a model of a
real life entity and represent it in a way that serves a given real life
purpose like pedestrian and automotive navigation. Buildings have all kinds
of imperfections (also accumulating with time), but we usually represent
them as simple boxes (that mind you is already too detailed to the taste of
many).

Another drawback is that Mapnik already has too many colours and symbols by
only showing the items of common interest, hence they had to hide a few
already. I'd definitely not like to compromise even more items of common
interest for occupancy on the general overview maps. I couldn't think of
who would look at specialized maps only showing these, but as I've asked
previously, please do share.

> What common interest does this annotation serve?
> It allows you to symbolize "occupied" buildings differently from
> "unoccupied" ones.
>
>
For example, people drawing their own back yards and their own garage there
does not serve common interest, however if you add a roof (rain cover) that
resides in public property where I could stand under if it is raining, it
is of common interest.

Another example is mapping your own water tap does not serve common
interest, but at the same time mapping a water tap found on the street adds
great value, as I could go there and have some water when I'm hiking in the
summer when it's hot and I'm thirsty.

Do people want to go inside an unoccupied building to seek shelter? Do
people want to see these kind of buildings as an attraction? Do people want
to stay away from occupied buildings due to possible danger? Should we
search for survivors in occupied buildings after a disaster (not good
enough because we should also search in residential buildings)? Does this
help mobile cell phone base station planning (although I guest they simply
look at their spatial network stats and be done with it)?

In general, I really like features, new tags and micromapping, but please
help me out a little here. I'd still need some convincing to see why this
would be a useful addition.

If it does not stand on its own as a feature, then as you've mentioned
yourself, it's just a placeholder, a kind of FIXME that you expect others
to map in more detail for it to be usable. See the answer I've given in the
relevant section as to why I view this as a bad thing.

> What is the verification criteria? Do I need to station next to the
> My personal criteria is not meant to be that exact.  For example, I can


>
You may have a given heuristic i

Re: [Tagging] Tagging buildings that people work in

[bkil]

The kind of derivative information that you suggest does not add much to
the map, hence I don't support your proposal.

On the other hand, if you simply added the area of the parking lot you see
next to the building (kind of a factual information), others could draw the
same conclusion as you did. At the same time, this would be great help for
drivers in finding parking spaces, adding utility to the map compared to
"symbolizing things". Note that we prefer that OpenStreetMap contains
mostly verifiable facts, not pure inferences. It would be extra helpful if
you used a resolution high enough for you to see whether it is fenced off
or not (access=*).

Note that I don't always add even parking lots from aerial imagery to the
map without local knowledge, because you can't be certain about what is on
the ground. Around here, it is not always easy to tell apart from car
retail, parking + residential storage&garages, VAT auction storage lots,
marketplaces and whatnot. Historic cities have very limited parking space,
and even those are mostly underground - with your inference someone may tag
all of these buildings as unoccupied, which is clearly wrong.

Also, currently I see each of your replies as a new message thread,
unrelated to one another. Could you please use message threading (I thought
that clicking on the 'reply' button would have done the right thing)?
https://support.mozilla.org/en-US/kb/message-threading-thunderbird


On Thu, May 30, 2019 at 2:01 AM ET Commands  wrote:

>
> > Date: Wed, 29 May 2019 20:46:28 +0100
> > From: Paul Allen 
> > To: "Tag discussion, strategy and related tools"
> >   
> > Subject: Re: [Tagging] Tagging buildings that people work in
> >
> > On Wed, 29 May 2019 at 19:09, ET Commands  wrote:
> >
> > My personal criteria is not meant to be that exact.  For example, I can
> >> see from an aerial photo a large building surrounded by a large parking
> >> lot.  I can surmise that several or many people work in the building,
> >> but I have no idea what they do there.
> >>
> > Sorry, but you cannot surmise that people work there.  Even if you do a
> > ground survey,
> > it may not be possible to make that determination unless you get close
> > enough.
> >
> > Sure, large office buildings of relatively recent construction tend to
> have
> > a distinctive style
> > ("Lego plain with large windows").  And they often have a large car park.
> > But...
> >
> > England changed its planning rules in 2013 to allow the conversion of
> > office blocks and
> > industrial buildings into homes without having to apply for planning
> > permission (often
> > a lengthy and expensive process, with permission frequently being
> denied).
> > The outcome,
> > given the economic downturn, was predictable.  There are a lot of
> buildings
> > that, using
> > aerial imagery and your criteria, would be mapped as offices but which
> are
> > not.
> >
> > Reference: https://www.bbc.co.uk/news/business-48031661
> >
> > --
> > Paul
>
>
> Fair enough.  But in the area where I map in the United States, I would
> bet that using my criteria I would be correct 95% of the time, if not more.
>
> Mark
>
>
>
> ___
> 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] Tagging buildings that people work in

[bkil]

By the way, don't get me wrong, it is a perfectly valid desire to tag
these. $SUBJECT has occurred to me as well in the past. In such cases, I
looked for the full address, other text on mailboxes, on the building
itself, on the fence and in WLAN and PAN in the air and tried to research
these on the net. Based on the result, I can usually add a few POI's or
companies there and even adjust the surrounding landuse. If nothing turns
up, it is probably not a building of public interest.

You might also consider asking a resident, although if this is the only way
to verify, it may not scale well on the long term and it is prone to change.

I consider this a constructive alternative approach to recommending mass
tagging of "something is here but I don't know what".

On Fri, May 24, 2019 at 8:34 PM bkil  wrote:

> I can see what maintenance burden this notation could bring, but I would
> need more information to see what we could gain from it.
>
> landuse=* seemed appropriate for most use cases I have encountered. Why do
> we need to tag this on a building resolution?
>
> What data consumers did you have in mind?
>
> What common interest does this annotation serve?
>
> What is the verification criteria? Do I need to station next to the
> building in working hours for a given amount of time and declare it
> occupied if I see any person entering or leaving, and mark it unoccupied
> otherwise? Or is it enough if I see indirect indications, such as open
> windows (what is they are motorized and remote controlled), lighting (some
> leave it always on for security)?
>
> Is it enough if I see a resident through the window? How do I know if the
> person is not merely a guard or an intermittent maintenance personal?
>
> If a storage building complex is only occupied by a guard (supervised=* /
> surveillance:type=guard), do you consider it occupied?
>
> Do you consider weekend houses occupied if they are only occupied
> intermittently or even seasonally? How do I verify this?
>
> Note that we usually do not add fixme kind of tagging for the sole purpose
> of marking the absence of regular information, as by definition, a blank
> map is missing an infinite amount of information and we would definitely
> not like to store so many fixme's.
>
> Although I acknowledge it is sometimes easy to distinguish abandoned
> buildings, especially if it is missing furniture, doors or windows, but we
> have life cycles for that.
>
> On Fri, May 24, 2019 at 12:40 PM Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 23. May 2019, at 19:05, marc marc  wrote:
>> >
>> > following that, building=yes building:use=yes is better
>> > yes can be improved when you'll known that's the current use,
>> > if it not the same as what is excepted for this building look
>>
>>
>> +1, seems to reflect the amount of knowledge.
>> The combination of building=* with building:use=no might be interesting
>> as well
>>
>> 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] Tagging buildings that people work in

[bkil]

I can see what maintenance burden this notation could bring, but I would
need more information to see what we could gain from it.

landuse=* seemed appropriate for most use cases I have encountered. Why do
we need to tag this on a building resolution?

What data consumers did you have in mind?

What common interest does this annotation serve?

What is the verification criteria? Do I need to station next to the
building in working hours for a given amount of time and declare it
occupied if I see any person entering or leaving, and mark it unoccupied
otherwise? Or is it enough if I see indirect indications, such as open
windows (what is they are motorized and remote controlled), lighting (some
leave it always on for security)?

Is it enough if I see a resident through the window? How do I know if the
person is not merely a guard or an intermittent maintenance personal?

If a storage building complex is only occupied by a guard (supervised=* /
surveillance:type=guard), do you consider it occupied?

Do you consider weekend houses occupied if they are only occupied
intermittently or even seasonally? How do I verify this?

Note that we usually do not add fixme kind of tagging for the sole purpose
of marking the absence of regular information, as by definition, a blank
map is missing an infinite amount of information and we would definitely
not like to store so many fixme's.

Although I acknowledge it is sometimes easy to distinguish abandoned
buildings, especially if it is missing furniture, doors or windows, but we
have life cycles for that.

On Fri, May 24, 2019 at 12:40 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 23. May 2019, at 19:05, marc marc  wrote:
> >
> > following that, building=yes building:use=yes is better
> > yes can be improved when you'll known that's the current use,
> > if it not the same as what is excepted for this building look
>
>
> +1, seems to reflect the amount of knowledge.
> The combination of building=* with building:use=no might be interesting as
> well
>
> 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