Re: [Tagging] Route names that aren’t names
I’ve added a ticket to the side report: https://github.com/openstreetmap/openstreetmap-website/issues/2573 -- Andrew From: Andrew Hain Sent: 29 March 2020 11:19 To: Sarah Hoffmann ; Tag discussion, strategy and related tools Subject: Re: [Tagging] Route names that aren’t names This tagging habit arose because the ref isn’t displayed in the side panel, only the name. Fix that and we can do a big clean-up. -- Andrew From: Sarah Hoffmann Sent: 29 March 2020 10:41 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Route names that aren’t names Hi, On Sat, Mar 28, 2020 at 06:18:01PM +, Richard Fairhurst wrote: > Route relation names aren’t in a great state, are they? > > The upshot: bad luck if you want to render the actual names of routes on a > map. You can’t. Or want to search for them. The sad state of the name tag is the only reason why you still can't search for hiking/cycling routes on osm.org[1]. [1] https://github.com/osm-search/Nominatim/issues/413 > A modest proposal: let’s use the name= tag in route relations for route > names. Let’s use the ref= tag for route numbers. If it doesn’t have a name, > it shouldn’t have a name= tag. Same as we do everywhere else. > > If you need somewhere for a mapper-facing route description (and I can see > that you need that for “part United Kingdom 5”), then I guess the obvious > place to put that is the note= tag. But let’s keep it out of the name tag; > and let’s have a concerted effort to remove them from existing name tags. Problem is that a large part of routes is mistagged this way. The public transport people even officially recommend this crappy tagging for the name tag[2]. So I suspect that this particular ship has sailed a long time ago. [2] https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport=625726#Route These days I wonder if it wouldn't be better if we introduce a tag that explicitly contains the name only. How about official_name for a, well, official name of the route and local_name for one that is used by everybody else. On top of that, it would be good to encourage more use of tags for all the other info that nowadays ends up in the name tag. Most of the are actually defined somewhere already: * ref * symbol * operator * region [3] * itinary (or, as PT people prefer: from, to, via) * section_name (section? stage? leg?) * section_ref [3] Basically the entity that 'ref'refers to. Sometimes that is a touristic area, sometimes the operator. I'd rather call it 'network' but that tag is already used for something else. If this kind of extended tagging gets widely enough used, then the name tag can just fall into oblivion. Sarah ___ 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] iD semi automatic adding public_transport to aerialway=station
Agreed, public transport is certainly the exception here. Yves Le 31 mars 2020 04:21:25 GMT+02:00, Gegorian Hauser a écrit : >___ >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] iD semi automatic adding public_transport to aerialway=station
Hello, iD giving a message about all types of aerialway tations to add there the public transport tagging. For me the public transport tagging should not be addet to a winter sport aerialway. Winter sport areas main function it to having fun and not to transport people. Also iD is giving these function on goods they in the most cases are not allowed for people to access. The most aerialways are used for winter sports(zip line for fun) and only some smal ammount of gondola/cable_car/chair_lift etc. are used only for public transport. There are over 15000 aerialway stations in Europe and over 1000 are just tagged also with public_transport For me these combination is in the most situations wrong and for this iD should not have this "fixing" function. Maybe I am wrong with this, but if we add public_transport to winter sports we should also add public_transport to escalators, moving walkways, elevators, amusement ride, alpine slide etc. regards Gregor ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Route names that aren’t names
On Sun, 29 Mar 2020 at 12:33, Paul Allen wrote: > On Sun, 29 Mar 2020 at 10:42, Sarah Hoffmann wrote: > >> * section_name (section? stage? leg?) >> > > Segment? Just a thought. > > Might be a bit too much baggage in that term? https://wiki.openstreetmap.org/wiki/Segment ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)
> Well the equipment in this case is playground=sandpit. As the outline of the sandpit is identical with the outline of the leisure=playground, why would this be wrong? Theoretically you need to create an object for the playground itself and another object for the playground equipment. Both then will share the same geometries (outline). In practical meaning you normally won't map it this way because it is idiotic. My proposal also reflects that and provides a way to map such cases without having to do it the theoretical way. -- Sören Reinecke alias Valor Naram ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)
sent from a phone > On 30. Mar 2020, at 20:03, Sören Reinecke via Tagging > wrote: > > For example: https://www.openstreetmap.org/way/137931618 . In this case > Key:playground was used to tag playground equipment on the playground > object itself. But for such cases we use Key:playground:* . This is one > example of many. it is not clear without knowing the place whether it is as you say. The tags are leisure=playground playground=sandpit this could also be intended as a sandpit kind of playground. Usually in OpenStreetMap tagging, if people tag A=B B=C when B is a feature, C is a subclass (more specific kind) of the B class. There are some exceptions to this, where B=* would be things from the B domain, examples are the playground key and golf key. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Updating definition and description of place=square
Às 05:08 de 30/03/2020, Martin Koppenhoefer escreveu: Am Mo., 30. März 2020 um 01:11 Uhr schrieb Kevin Kenny mailto:kevin.b.ke...@gmail.com>>: One example: Berkeley Square in London. In form, it's a public garden, but even the English designate it a town square. As I understand it, an Englishman would not raise eyebrows at a sentence: "Winston Churchill, as a child, lived in Berkeley Square. The Churchills' house, № 48, is the one entirely residential building remaining there; the rest of the buildings are all offices of financial concerns, much like the rest of Mayfair." The thing is that squares often also serve as addresses and can be somehow seen very similar to streets, so the same as you can live in a street (meaning you live in a house on this street), you could also live on a square (a house bordering this square). At least it works like this in some languages I am aware of. Cheers Martin Like in Portugal, for example. In most cases, the name of the square is the address of the adjacent buildings. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)
On 30.03.2020 20:02, Sören Reinecke via Tagging wrote: >> How will that help? What errors are you commonly finding? > > For example: https://www.openstreetmap.org/way/137931618 . In this case > Key:playground was used to tag playground equipment on the playground > object itself. But for such cases we use Key:playground:* . This is one > example of many. Well the equipment in this case is playground=sandpit. As the outline of the sandpit is identical with the outline of the leisure=playground, why would this be wrong? tom ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)
On 30.03.2020 20:02, Sören Reinecke via Tagging wrote: >> How will that help? What errors are you commonly finding? > > For example: https://www.openstreetmap.org/way/137931618 . In this case > Key:playground was used to tag playground equipment on the playground > object itself. But for such cases we use Key:playground:* . This is one > example of many. Well the equipment in this case is playground=sandpit. As the outline of the sandpit is identical with the outline of the leisure=playground, why would this be wrong? tom ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)
> The current system seems to make sense. It makes sense but it seems that it is also much error-prone because it is easy to oversee one sentence in the wiki of Key:playground:* and Key:playground that makes the difference (pointing the case where the key should be applied) > If you have a leisure=playground feature, probably mapped as an area, you can tag it with a list of tags like "playground:slide=yes", "playground:swing=yes", to show what equipment is available. > If you want to map a slide or a swing as a separate feature, you tag it "playground=slide", or "playground=swing" > What is the problem with this? No problem with it. This is alright. But Key:playground shouldn't combined with Tag:leisure=playground . > Re: > " I want to combine them to help to decrease tagging errors." > How will that help? What errors are you commonly finding? For example: https://www.openstreetmap.org/way/137931618 . In this case Key:playground was used to tag playground equipment on the playground object itself. But for such cases we use Key:playground:* . This is one example of many. > Re: > This would allow to map playgrounds and their equipment in situations where a playground just has one equipment and this equipment fills up the whole area of the playground. > Mappers can tag "leisure=playground" + "playground=structure" on the same node or area in this case, right? The Wikipage for "Key:playground" says the following: "It should be tagged to separate objects within the area of a playground". An exception is given with "Only when the position of the individual objects cannot be mapped yet" at the really end of the page. But for such cases where we cannot map playground equipment as an extra object we have the Key:playground:* . Cheers Sören Reinecke alias Valor Naram ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)
Am Mo., 30. März 2020 um 16:45 Uhr schrieb Sören Reinecke via Tagging < tagging@openstreetmap.org>: > > https://wiki.openstreetmap.org/wiki/Proposed_features/Unifying-playground-equipment-tagging > > > Proposal: > I propose the key playground to be deprecated and the use of key > playground:* instead. That would mean that on both playground and > playground equipment objects in OSM the key playground:* applies. This > then would also allow to map playgrounds and their equipment in > situations where a playground just has one equipment and this equipment > fills up the whole area of the playground. > You are proposing to abandon the distinction between playgrounds and implicit features on them (properties) and things on a playground (explicitly mapped playground equipment as a feature). Wouldn't this move make it actually harder, rather than simpler, to understand what is represented? Usually we are advocating for the contrary: using different keys for features provided by other features (properties) and features mapped explicitly. In this case, it is already like this, and you do not provide (IMHO) sufficient arguments to change it. Redefining tags that are in use (properties for playgrounds then could also represent explicit features) is generally problematic, why aren't you proposing different tags as an attempt to avoid confusion? I do not understand why this would make mapping easier or less error prone. You will find tags that are not used as documented for any feature. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)
The current system seems to make sense. If you have a leisure=playground feature, probably mapped as an area, you can tag it with a list of tags like "playground:slide=yes", "playground:swing=yes", to show what equipment is available. If you want to map a slide or a swing as a separate feature, you tag it "playground=slide", or "playground=swing" What is the problem with this? Re: > " I want to combine them to help to decrease tagging errors." How will that help? What errors are you commonly finding? Re: > This would allow to map playgrounds and their equipment in situations where a playground just has one equipment and this equipment fills up the whole area of the playground. Mappers can tag "leisure=playground" + "playground=structure" on the same node or area in this case, right? -- Joseph Eisenberg On 3/30/20, Sören Reinecke via Tagging wrote: > Hey, > > a new RFC for > https://wiki.openstreetmap.org/wiki/Proposed_features/Unifying-playground-equipment-tagging > > Purpose: > Simplified tagging of playground equipment on the playground itself or > as separate object. Both schemes already exist and I want to combine > them to help to decrease tagging errors. > > Proposal: > I propose the key playground to be deprecated and the use of key > playground:* instead. That would mean that on both playground and > playground equipment objects in OSM the key playground:* applies. This > then would also allow to map playgrounds and their equipment in > situations where a playground just has one equipment and this equipment > fills up the whole area of the playground. > > > > > What I feel: > I know many of you do not want developers to speak about how you should > do things. But I think a dialogue is necessary and also good for us all > and we can learn from each other: Mappers know the philosophy of OSM, > the mapping, tagging and the QA, they know what to achieve how. > Developers know the philosophy of orthogonality and nornmalisation of > things and can help mappers to make OSM more useful. > > I am the developer of Babykarte. Babykarte follows what I want to > propose for a quite long time already with some extra specifications > which enables it to be quite flexible in interpreting the tagging. This > makes Babykarte a really good interpreter of the tagging of playground > equipment. This is necessary to do for us developers (we would be happy > if all mappers would stick to the specs) because some mappers decided > not to read the wiki carefully or not at all but instead to actually > map without knowing how. So developers always need to do some > interpreting and thinking of all the possibilities people do not map in > accordance with the spec. This makes us to create our own spec that > builds on the official one because people aren't following the > community's specs. > > > -- > ~ Sören Reinecke alias Valor Naram > > > Developer (not Founder) of the Babykarte: https://babykarte.github.io > Participating in "MapDiscover" project: https://mapdiscover.org > "Community Support" for Trufi Association: > https://trufi-association.org > Documentation for Trufi Communities on mapping bus routes: > https://github.com/trufi-association/mapping-documentation > > > Ein Gag zu Hamsterkäufen: https://klopapier.mapdiscover.de > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)
Hey, a new RFC for https://wiki.openstreetmap.org/wiki/Proposed_features/Unifying-playground-equipment-tagging Purpose: Simplified tagging of playground equipment on the playground itself or as separate object. Both schemes already exist and I want to combine them to help to decrease tagging errors. Proposal: I propose the key playground to be deprecated and the use of key playground:* instead. That would mean that on both playground and playground equipment objects in OSM the key playground:* applies. This then would also allow to map playgrounds and their equipment in situations where a playground just has one equipment and this equipment fills up the whole area of the playground. What I feel: I know many of you do not want developers to speak about how you should do things. But I think a dialogue is necessary and also good for us all and we can learn from each other: Mappers know the philosophy of OSM, the mapping, tagging and the QA, they know what to achieve how. Developers know the philosophy of orthogonality and nornmalisation of things and can help mappers to make OSM more useful. I am the developer of Babykarte. Babykarte follows what I want to propose for a quite long time already with some extra specifications which enables it to be quite flexible in interpreting the tagging. This makes Babykarte a really good interpreter of the tagging of playground equipment. This is necessary to do for us developers (we would be happy if all mappers would stick to the specs) because some mappers decided not to read the wiki carefully or not at all but instead to actually map without knowing how. So developers always need to do some interpreting and thinking of all the possibilities people do not map in accordance with the spec. This makes us to create our own spec that builds on the official one because people aren't following the community's specs. -- ~ Sören Reinecke alias Valor Naram Developer (not Founder) of the Babykarte: https://babykarte.github.io Participating in "MapDiscover" project: https://mapdiscover.org "Community Support" for Trufi Association: https://trufi-association.org Documentation for Trufi Communities on mapping bus routes: https://github.com/trufi-association/mapping-documentation Ein Gag zu Hamsterkäufen: https://klopapier.mapdiscover.de ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Updating definition and description of place=square
On Mon, Mar 30, 2020 at 4:09 AM Martin Koppenhoefer wrote: > The thing is that squares often also serve as addresses and can be somehow > seen very similar to streets, so the same as you can live in a street > (meaning you live in a house on this street), you could also live on a square > (a house bordering this square). At least it works like this in some > languages I am aware of. That's at least an explanation, though, for why it is that squares are also micro-neighbourhoods, in both New England and old England. A square in common speech often encompasses the buildings that front on it. It can be in some cases that urban redevelopment has caused the square to vanish while the name lives on, or that a developer has chosen 'Square' as the name of something else. (There's a strip mall near me that used to be called St. James's Square.) That, of course, is no longer a square, any more than Billingsgate is a gate.(*) (*) Yes, historically, it was the water gate where the Thames left the City, but that fortification is long gone, and even the fish market that led to 'billingsgate' as a word for foul language has moved away, and the word itself faded into obscurity. But Billingsgate remains as a Ward of the City. -- 73 de ke9tv/2, Kevin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Veterinary pharmacy
AFAIK in Belgium, you can get all medicins for your pets from any pharmacy. In addition, some vets have a small supply of often used medicins that they can sell. Perhaps some of the larger veterinary clinics have a separate counter where you can only get medicins for animals. If you want to map those, you might want to use a separate node and tag. But even one of the largest vet clinics in Belgium (the one from the Univ. of Ghent), does not have a separate counter and the medicins are provided by the vet or by the person where you pay for your visit. Of course, this might be different in other countries, but I haven't heard anything like that from dog owners around the world. regards m. On Sat, Mar 28, 2020 at 2:41 PM Paul Allen wrote: > > On Sat, 28 Mar 2020 at 09:47, Warin <61sundow...@gmail.com> wrote: >> >> On 28/3/20 7:51 pm, Martin Koppenhoefer wrote: >> >> sent from a phone >> >> On 28. Mar 2020, at 08:31, Warin <61sundow...@gmail.com> wrote: >> >> veterinary medical supplies, how to choose what amenity? >> >> On 28/3/20 6:12 pm, Francesco Ansanelli wrote: >> >> Hello, >> >> >> I have a question about this tag: >> >> >> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dveterinary_pharmacy >> >> >> It's not much adopted and in unknown status. Should we use it? >> >> Some pharmacies also sells veterinary medical supplies, how to choose what >> amenity? >> >> >> >> Map both as separate nodes. >> >> >> >> but it’s the same shop. >> >> >> Different OSM features. > > > Really? I suppose there might be such a place, with different shop counters, > different staff, different back rooms full of medicines, etc., but I'd expect > it to be a normal pharmacy that also carries some veterinary medicines. > There are 3 pharmacies in my town and one vet (there used to be two > vets; there's another pharmacy being set up). None of the pharmacies > have a separate counter for veterinary medicines but I know that at > least one of them dispenses them because my next-door-neighbout > with three dogs and two cats gets them from somewhere, and she's > not travelling to either of the two cities over 30 miles away to get > them. > > In a really big city I suppose there could be a veterinary-only pharmacy. > So we may need amenity=veterinary_pharmacy for rare cases but > for most instances we'll need something that goes along with > amenity=pharmacy (and/or healthcare=pharmacy) to indicate > it also handles veterinary medicines. > > -- > 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] Route names that aren’t names
Le 30 mars 2020 08:25:40 GMT+02:00, Peter Elderson a écrit : > >Note that not all renderings currently show the name or ref of the >parent trail relation,... Inevitably, the current situation is stained by the abilities of the actual renderer, and the other way around. Maybe those renderers should sit around a wiki page and document how ideal tag could be and how they can be used in rendering, also taking into account the ability to parse nested relations or not with their respective toolchain. Improvements could go both sides... Yves ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Updating definition and description of place=square
Am Mo., 30. März 2020 um 01:11 Uhr schrieb Kevin Kenny < kevin.b.ke...@gmail.com>: > One example: Berkeley Square in London. In form, it's a public garden, > but even the English designate it a town square. As I understand it, an > Englishman would not raise eyebrows at a sentence: "Winston Churchill, as a > child, lived in Berkeley Square. The Churchills' house, № 48, is the one > entirely residential building remaining there; the rest of the buildings > are all offices of financial concerns, much like the rest of Mayfair." > The thing is that squares often also serve as addresses and can be somehow seen very similar to streets, so the same as you can live in a street (meaning you live in a house on this street), you could also live on a square (a house bordering this square). At least it works like this in some languages I am aware of. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Route names that aren’t names
Yves: > We should be able to follow Richard's proposal and re-tag names in name=* and > references in ref=* and filling itinerary, operator, etc... along the way. If I have a long foot trail, divided into 20 legs, should the leg route relations get the name tag of the trail? On the ground, some markings show the route name along the entire route, but most markings are just the symbol. Note that not all renderings currently show the name or ref of the parent trail relation, most renderings show the names or refs of the separate leg relations. I am not judging this, it's just that when I remove the names and refs, they disappear from those maps. Best, Peter Elderson ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
