[Tagging] The reason to not use loc_name is far too subjective.

The wiki says this: "but only where this is deemed to be too much of a slang name or otherwise unofficial-sounding. Ordinarily though, the name which local people use is the name we set in the name=* tag!" https://wiki.openstreetmap.org/wiki/Names#Local_names_(loc_name) This is, once again,

Re: [Tagging] Picnic_table with barbecue table extension.

reference? On Mon, 22 May 2023, 19:06 Dave F via Tagging, wrote: https://snipboard.io/H5FYGT.jpghttps://snipboard.io/H5FYGT.jpgHi I've a leisure=picnic_table but has an extended table top made of metal to accommodate disposable barbecues. Can anybody recommend a sub-tag that's more

[Tagging] Picnic_table with barbecue table extension.

https://snipboard.io/H5FYGT.jpghttps://snipboard.io/H5FYGT.jpgHi I've a leisure=picnic_table but has an extended table top made of metal to accommodate disposable barbecues. Can anybody recommend a sub-tag that's more descriptive than barbecue=yes?

Re: [Tagging] Perimeter of a pitch

Have you not checked the OSM wiki for pitch? DaveF On 21/05/2023 21:08, Raphael wrote: Hello everyone Does the area outside the sidelines of a pitch up a board, a fence, a change in surface or similar belong to a pitch (sports field) or not? I'm asking because there's [some disagreement][^1]

Re: [Tagging] Area of young trees - saplings

already. Anne -- Sent from my Android phone with WEB.DE <http://WEB.DE> Mail. Please excuse my brevity. On 16/05/2023, 13:49 Dave F via Tagging wrote: Is there a tag for areas where you trees are planted? Too small to be self supporting they're often individually attached to

[Tagging] Area of young trees - saplings

Is there a tag for areas where you trees are planted? Too small to be self supporting they're often individually attached to a pole & encased in a protective tube. natural=wood seems inappropriate, as does scrub. I thought 'saplings' would be suitable, but taginfo return none DaveF

Re: [Tagging] Deprecate sport=cricket_nets

I don't sport=cricket_nets is fine. it's clear. it's specific. It doesn't interfere with any other tags. The argument that it's not, technically, a sport & therefore inaccurate is... meh. DaveF On 30/01/2023 13:54, Illia Marchenko wrote: Hello everyone, I suggest deprecating

Re: [Tagging] Route names being applied to tracks/paths

On 29/12/2022 09:47, Warin wrote: Hi, I think the 'names' should be removed from these 'unnamed' things ..the 'name' is the name of the route not the individual tracks/paths some of which existed before some routes were created. +1 DaveF ___

Re: [Tagging] Route names being applied to tracks/paths

Yves wrote: Remove the name of the way, put a name on each relations. Except if it makes sense to keep the name also on the way for whatever reason you see fit. Le 30 décembre 2022 18:06:12 GMT+01:00, Dave F via Tagging a écrit : What do you do if there are two routes? DaveF On 3

Re: [Tagging] Route names being applied to tracks/paths

What do you do if there are two routes? DaveF On 30/12/2022 02:19, brad wrote: +1 If the only name is the route name I think it makes good sense to put it on the local way too, that's the name of the trail. Brad On 12/29/22 08:59, Zeke Farwell wrote: I've heard the assertion that a way has

Re: [Tagging] Route names being applied to tracks/paths

On 29/12/2022 15:13, Zeke Farwell wrote: On Thu, Dec 29, 2022 at 9:15 AM Dave F via Tagging wrote: The actual way routes progress along often have their own, different, name. These should be ithe name placed in the way's name tag. Yes, the way name tag should be the most local

Re: [Tagging] Route names being applied to tracks/paths

On 29/12/2022 12:32, Yves via Tagging wrote: The simpliest way to map a long route is to give the same name to every ways it is composed of. The reason route relations were created was because long routes share the /same/ ways. It avoids cluttering up the name & ref tags The actual way

[Tagging] plantation=yes?

Hi What does plantation=yes represent? Associated with woods, but nothing in the wiki. 2437  uses worldwide. Seems too vague to be OSM useful. DaveF ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Lyft and nameless sectioning in OSM

On 11/10/2022 19:34, Evan Carroll wrote: Some examples of these nameless sections are, * w1101484647 by A_Prokopova_lyft Not looked at all your examples, but i can't see a problem with your first. It covers a large area of no just a building but car parking etc, and is surround by landuse

[Tagging] not:brand:wikidata?

Hi What is 'not:brand:wikidata'? There are 5000+ in the database. Can't see any wiki details. I'm struggling to comprehend the logic. Cheers DaveF ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Terminology primary feature, main tag, etc..

On 03/10/2022 09:11, Warin wrote: 2 primary features, identified by feature tags, represented by one OpenStreetMap element. Main key for stream is waterway, for road it is highway. In the osm2pgsql standard style, both are primary keys. The guide says 'one feature = one OSM entry'.

Re: [Tagging] Terminology primary feature, main tag, etc..

On 03/10/2022 12:55, Volker Schmidt wrote: On Mon, 3 Oct 2022, 12:20 Marc_marc, wrote: imho only one main feature/objet : the stream bed and car use it, a bit like a bicycle uses a road. OT, but I cannot let it pass: Roads, in most cases, are dedicated to vehicles (including

Re: [Tagging] Terminology primary feature, main tag, etc..

On 03/10/2022 06:51, Mateusz Konieczny via Tagging wrote: Oct 2, 2022, 23:30 by dieterdre...@gmail.com: sent from a phone On 2 Oct 2022, at 19:40, martianfreeloader wrote: - primary feature [1] - main key [2] - primary key [3] -

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

On 22/11/2020 22:27, Christoph Hormann wrote: Exactly. It also shows how we in OSM traditionally make decisions about tagging. An idea to change tagging practice was suggested - on an open channel for everyone to read and comment on without hurdles and with an archive that allows us now to

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

On 22/11/2020 18:12, Clay Smalley wrote: On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging mailto:tagging@openstreetmap.org>> wrote: Contributing to the database (also *volunteers*) are expected to map to a certain standard. There shouldn't be a reason to expect de

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

I'm surprised you think that as you were a contributor to the discussions: https://github.com/gravitystorm/openstreetmap-carto/pull/3102 https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html DaveF On 22/11/2020 16:32, Christoph Hormann wrote: Dave F via Tagging hat am

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

On 22/11/2020 11:24, Richard Fairhurst wrote: [cross-posted to talk-us@ and tagging@, please choose your follow-ups wisely] If you go against the accepted principle of not X-posting on a newsgroup, you've no entitlement to lecture how others respond. Brian M. Sperlongano wrote: > It seems

Re: [Tagging] surface=boardwalk? is it duplicate of surface=wood?

To me, boardwalk describes the design & appearance rather than the surface construction: An elevated walkway. Although I do admit that's mostly influenced by The Drifters song. DaveF On 21/11/2020 23:20, Mateusz Konieczny via Tagging wrote: Is there some value in surface=boardwalk tag? It

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

On 17/11/2020 18:56, stevea wrote: I've found published data (from the authority authorised to amend the route) are often too inaccurate, out of date or lacking in detail to warrant transferring to OSM. Then, don’t import, curate or transfer them to OSM. I don’t believe we want "inaccurate,

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

On 17/11/2020 03:09, Seth Deegan wrote: May I ask why not source=*? TBH. I'm not a fan of the tag. I don't think it adds much value. It's too subjective/variable, but... It relates to the individual contributor editing individual objects. A contributor can obtain data from many different

Re: [Tagging] Tagging Cycle Route Relations vs. Ways

On 16/11/2020 16:17, Seth Deegan wrote: The Cycle Routes Wiki Page states: "It is preferred to tag the cycle routes using relations instead of tagging the ways." If I come across a route that has the

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

On 26/10/2020 23:26, Martin Koppenhoefer wrote: crossing_ref as far as I have understood the tag, is not about the type of crossing, I think you've misunderstood. DaveF ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

/2020 15:33, Martin Koppenhoefer wrote: Am Mi., 16. Sept. 2020 um 16:27 Uhr schrieb Dave F via Tagging mailto:tagging@openstreetmap.org>>: I thought the correct tag for this was crossing_ref. Have you cross checked to see if they've been swapped instead of removed? crossi

Re: [Tagging] Proposal to change key:man_made to key:human_made

It appears so. Pretending there is a bias, doesn't mean there is one. DaveF On 21/10/2020 02:34, Phake Nick wrote: At this point it's clear enough OP is just trolling? ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Proposal to change key:man_made to key:human_made

"Insanity Is Doing the Same Thing Over and Over Again and Expecting Different Results" On 20/10/2020 19:02, Martin Koppenhoefer wrote: but it’s fair to discuss every proposal on its own. ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Proposal to change key:man_made to key:human_made

No. In the context of OSM, think of man_made=bridge akin to a noun. The actual bridge object. bridge=* is akin to an adjective/attribute of an object. DaveF On 20/10/2020 05:56, Robert Delmenico wrote: Essentially though, they mean the same thing: man_made=bridge is for areas yes is for ways

Re: [Tagging] Proposal to change key:man_made to key:human_made

On 19/10/2020 15:39, Robert Delmenico wrote: Regardless of the origin of the term, the current use of 'man' is to identify adult males. That's your misinterpretation. You think you're being original with your proposal, but it's not the case. Every couple of years someone come along with the

Re: [Tagging] Proposal to change key:man_made to key:human_made

That in a project to create an up to date map, there are people involved who get upset over things changing is, indeed, weird. DaveF On 19/10/2020 13:58, Mateusz Konieczny via Tagging wrote: Yes, latest update date can be a hint but treating it is as an argument to avoid making an edit is

Re: [Tagging] Proposal to change key:man_made to key:human_made

Irrelevant of any implied meaning, 'man_made' always appeared to be a clunky, catch-all tag. OSM was being a bit lazy. I mean, *everything* is either man made or natural.  We really should come up with more specific, accurate key tags. DaveF On 19/10/2020 12:45, Jo wrote: It would be best to

Re: [Tagging] Proposal to change key:man_made to key:human_made

I'm in no way supporting the proposal, but this argument of 'it'll make the entities look fully up to date" is illogical. If taken to it's conclusion, nothing will ever be update again. It's false to think that just because an entity was amended yesterday, it means it's up to date: If a typo

Re: [Tagging] railway=station areas

On 17/10/2020 09:53, Martin Koppenhoefer wrote: On 15. Oct 2020, at 15:12, Dave F via Tagging wrote: Please send all messages to the public forum Martin. I will write to whoever I want, not your business. Wow. The arrogant hypocrisy. (& v. short term memory) You may already

Re: [Tagging] railway=station areas

On 17/10/2020 10:00, Martin Koppenhoefer wrote: On 15. Oct 2020, at 16:40, Dave F via Tagging wrote: Which negates any desire to change the meaning of railway=station from "places where customers can access railway services or where goods are loaded and unloaded." I am perf

Re: [Tagging] railway=station areas

On 15/10/2020 11:01, OSM wrote: Am 10.10.2020 um 00:35 schrieb Dave F via Tagging: I edited a copy of the diagram (A-simple-station.svg) of a station layout, primarily to remove any references to PTv2 tags, a completely independent, duplicating tagging schema, irrelevant to anything to do

Re: [Tagging] railway=station areas

Please send all messages to the public forum Martin. It was a post in reply to the topic. Unlike a few train spotters in Germany I'm not scared to have all discussions be public & a matter for record. Please don't dictate over events on which you have no authority. DaveF. On 15/10/2020

Re: [Tagging] railway=station areas

Please send messages to forum, John. On 14/10/2020 03:17, John D. wrote: unless you visit the platform or there is a visible sign how do you know where the train stops ? Unsure of the relevance of that to this discussion. how is nodes better than area ? Points have already been made.

Re: [Tagging] railway=station areas

On 11/10/2020 09:25, Mateusz Konieczny wrote: Including all this tracks feels ridiculous to me. Agreed. Over the past few years in the UK I've been maintaining/checking the railway=station tag to ensure there are the correct number. I've the changed the few that were mapped as areas to nodes

Re: [Tagging] railway=station areas

On 11/10/2020 08:16, Martin Koppenhoefer wrote: Are you mapping train stations as areas? From reading your replies here the impression I get is you are advocating for not extending the representation from a node to an area, right? I do not understand why you are fighting so hard to make a tag

Re: [Tagging] railway=station areas

On 10/10/2020 00:34, Andrew Harvey wrote: I believe most of this discussion is moot as the *vast* majority of railway=stations are mapped as nodes: I don't think that makes the point moot since nodes are just a quick first pass way to map a station, railway=station is one of the

[Tagging] railway=station areas

Apologies for breaking the thread, but I was unable to connect to Tagging & missed the initial message in my email client. I'm the user in disagreement. (Although reading the current railway=station wiki page I'm not convinced there's an genuine alternative belief). I believe most of this

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

Please don't crossthread newsgroups. If you have to alert the few who don't subscribe to both, post a message telling them it's on another newsgroup. DaveF On 16/09/2020 14:11, Niels Elgaard Larsen wrote: Mateusz Konieczny via talk:

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

On 16/09/2020 14:59, Jeremy Harris wrote: On 16/09/2020 14:26, Matthew Woehlke wrote: On 16/09/2020 05.57, Martin Koppenhoefer wrote: I noticed that crossing=zebra tag usage is drastically shrinking while the very generic crossing=marked, which was quite unpopular before (2013-2018 below

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

I thought the correct tag for this was crossing_ref. Have you cross checked to see if they've been swapped instead of removed? DaveF On 16/09/2020 10:57, Martin Koppenhoefer wrote: I noticed that crossing=zebra tag usage is drastically shrinking while the very generic crossing=marked, which

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

Hi  I request to replace all occurrence of the prefixed versions of the contact keys, as it adds no quality to the OSM database On 04/05/2020 11:53, Valor Naram via Tagging wrote: I request to replace all occurrence of the non-prefixed versions of the contact keys like Key:phone,

Re: [Tagging] Can highway=cycleway be limited to MTB?

No to motorway, a motorway is a divided, limited access highway, distinct from other types of highway.   Trunk is ambiguous, it wouldn't bother me if it was removed. How to miss the point Note the "etc". The wiki for cycleway, the 1st line: "The highway

Re: [Tagging] Can highway=cycleway be limited to MTB?

On 03/04/2020 00:35, Morten Lange via Tagging wrote: I agree. And I am glad to se that seems to the overwhelming sentimemt on the list. MTB trails are a specific type of cycleway. They are indicated as such by using specific tags in combination with highway=cycleway. For those who want to

Re: [Tagging] Can highway=cycleway be limited to MTB?

On 02/04/2020 20:11, brad wrote: On 4/2/20 10:56 AM, Dave F via Tagging wrote: And here we go again... If a way is designated for riding a bicycle then it's a cycleway, irrelevant of severity or conditions. The trouble with this is that very few trails are 'designated' for riding

Re: [Tagging] Can highway=cycleway be limited to MTB?

On 02/04/2020 15:53, Kevin Kenny wrote: A key issue is that mtb:scale can't be the only indication. Otherwise, we're falling into a trap - which has been a common trap in the past. It's a trolltag https://wiki.openstreetmap.org/wiki/Trolltag - a second tag that negates or massively changes

Re: [Tagging] Can highway=cycleway be limited to MTB?

On 02/04/2020 20:02, brad wrote: No need for sympathy, I strongly agree with what you're saying.  I think it's unfortunate that we even have the cycleway and footway tags, but they need to be treated as special cases of highway=path, Are you also suggesting removing the "special cases" of

Re: [Tagging] Can highway=cycleway be limited to MTB?

On 02/04/2020 12:40, Snusmumriken wrote: On Thu, 2020-04-02 at 22:24 +1100, Andrew Harvey wrote: just usually only a certain kind of bicycle. Well, that's the problem, if one can't travel on a certain way with a general purpose bicycle, then it shouldn't be tagged highway=cycleway You're

Re: [Tagging] Can highway=cycleway be limited to MTB?

On 02/04/2020 11:33, Volker Schmidt wrote: There is another aspect: The wiki page highway=cycleway states also " Tagging a way with highway =cycleway implies that the route is designated for bicycles." This means it implies, at least in Italy and

Re: [Tagging] Can highway=cycleway be limited to MTB?

And here we go again... If a way is designated for riding a bicycle then it's a cycleway, irrelevant of severity or conditions. cycleway with mtb:scale combination is a valid tag. mtb:scale gives an indication of what equipment would probably be required. The problem, as so often in OSM, is

Re: [Tagging] Route names that aren’t names

A general point to all: Please don't confuse a way's name with a route's name. They are different. There can be multiple routes traversing over the same way. On 28/03/2020 21:56, Richard Fairhurst wrote: Sure. NCN 4 is called "NCN 4" in the same sense that the M4 is called the "M4". That's

Re: [Tagging] Route names that aren’t names

On 28/03/2020 18:18, Richard Fairhurst wrote: Hello folks, Route relation names aren’t in a great state, are they? Let’s say that I want to render cycle route names on a map (because, well, I do). I zoom in on a way along the East Coast of Britain and I find it’s a member of this route:  

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 20/03/2020 15:26, Janko Mihelić wrote: the order of platforms and ways I'm unsure what you mean. Could you expand please? Is there a wiki page? DaveF ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 11/03/2020 12:16, Jo wrote: But if the originally, more common tag highway=bus_stop is already used, there is no need to add bus=yes. OK, but if we have to keep highway=bus_stop anyway, then one could also say that it's not needed to add public_transport=platform to such nodes anymore.

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 11/03/2020 12:07, Joseph Eisenberg wrote: I notice that they also refer to adding bus=yes etc to platforms representing bus stops, which was not part of the PTv2 proposal, but I guess tries to deal with one of the issues that led people to prefer highway=bus_stop. Yes, that is a rather

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 11/03/2020 12:12, Jo wrote: That stop_position nodes became optional is probably because of my influence. Sorry. but In the beginning they were definitely part of how PTv2. railway=stop was, I believe, around before PTv2 concept. I disliked this very much because all of a sudden

[Tagging] Barbecue disposal bins

Hi Communal bins in parks etc for the disposal of hot ash or single-use tray barbecues. Unable to find the appropriate tag in the wiki or taginfo. Suggestions? PS Is anyone as irritated as I am by the shortening to 'bbq'. It seems to serve no beneficial purpose & consensus/convention is

Re: [Tagging] Criticism of PTv2

On 10/03/2020 20:52, Phake Nick wrote: In the sense of bus, sidewalk could be a platform because they are raised from the driving road surface. You can google "bus platform" and see many example of the word being used in real world. But that's not how it was implemented in the PT

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 09/03/2020 22:26, Jarek Piórkowski wrote: Separate relations per each route variant If you mean bidirectional, they've been mapped since the inception of route relations. - verifying that the highway ways are continuous in the relation. Which PTv2 tags allows that? DaveF

Re: [Tagging] Criticism of PTv2

On 09/03/2020 21:00, Alan Mackie wrote: So it's better to label them all as platforms? I can't see any raised area in a typical bus stop:... Why would we tag it as if it looks like this?... This is just one example of poor concepts implemented in PTv2. We should be mapping *physical*, not

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

On 09/03/2020 13:21, Jarek Piórkowski wrote: PTv2 is fine for people who want to handle routes that have variants and branches and who want computer validators to be able to spot potential errors in these branches. I'm intrigued: What Ptv2 tags enable those? DaveF

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

This proposal by Stereo is nothing really new.  Just a alternative to routing which has been around since relations were introduced. Definitely not 'PTv3'. The 'via' option appears almost as difficult to maintain as including ways. On 08/03/2020 01:41, John Doe wrote: That would be

Re: [Tagging] amenity=faculty?

On 04/02/2020 16:03, Mateusz Konieczny via Tagging wrote: Universities may have faculties, that often deserved to be mapped separately. For example university may take a large area, possibly disjointed area across the city but Faculty of dentistry, Faculty of forestry, Faculty of mathematics

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

On 28/01/2020 21:23, Tomas Straupis wrote: Yet for ten years or even more the logic was that... Are there any reasons why this must change now? Any benefits? I think your mistaken in your timeline. Cycleway & footway were around before path was introduced to cover the

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

On 27/01/2020 16:41, Mike Thompson wrote: I have never understood the use of tags like "cycleway", "bridleway", and "footway." To me these mix two different concepts (physical form and legal access) in a single tag. These values do not indicate a way's form. That is achieved with

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

On 27/01/2020 15:36, Jmapb wrote: My own impression over the years has been that mappers use highway=cycleway on anything that primarily for bicycle traffic, and add access keys for any other permitted traffic. Similarly for highway=footway. So "highway=cycleway + foot=yes" and "highway=footway

Re: [Tagging] building=disused

On 16/01/2020 12:57, Paul Allen wrote: So the wiki says now. It's not what it said in the past. But let's say you're correct. We both know that standard carto doesn't render physical objects with a disused prefix. I, and others, believe that it is important to render physical objects

Re: [Tagging] building=disused

On 16/01/2020 12:01, marc marc wrote: you want me to believe that every time an object has gone, It's not gone. We're talking about buildings which are physically still existing. you make an enquiry to find out how it disappeared ? Err.. No.You don't have to know why a building isn't

Re: [Tagging] building=disused

On 16/01/2020 12:01, Paul Allen wrote: A lot of buildings have to be building=yes, for lack of anything better. But you already lost the battle with building=house, which is too firmly entrenched to change. Why would it need to change? If that's it's *current* usage tag it as house. If it

Re: [Tagging] building=disused

On 16/01/2020 01:08, Paul Allen wrote: That matches my thinking on the issue. Others seem to agree. Do they? So, at the very least, the wiki needs to be amended. Does it? "Use the disused: lifecycle prefix on tags that relate to features that are in a reasonable state of repair but

Re: [Tagging] building=disused

Joseph says tagging usage should dictate OSM-carto: the community should make tagging decisions based on what works best for mappers and what makes logical sense, without worrying what a particular renderer will do. But then ignores the more popular disused: prefix But this is not always

Re: [Tagging] building=disused

On 16/01/2020 11:34, marc marc wrote: I'm also using was: because I don't care Well. Done. You. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building=disused

On 14/01/2020 19:32, marc marc wrote: Le 14.01.20 à 19:34, Markus a écrit : If i understand it correctly, building=* values describe how the building looks, not how it is used. For example, a church that is now used as a pub still remains a building=church. I fully agree with that. note that

Re: [Tagging] building=disused

You're using was: to represent the same meaning as disused:, so why not use the far more popular latter one? On 14/01/2020 19:02, Markus wrote: For example, building=commercial + disused=yes on the area and was:shop=supermarket + name=* on a node within.

Re: [Tagging] building=disused

The correct term is 'don't tag *incorrectly* to suit the render'. All tags are for the renderer, otherwise all the maps would be black lines & dots DaveF. On 14/01/2020 18:42, Kevin Kenny wrote: Whenever I raise a point like that, there is a chorus of 'don't tag for the renderer.'

Re: [Tagging] building=disused

The reason it's discouraged is it removes the building type. ie building=church. Even though it may not be used as a church currently it still looks like one. Renderers may still want to distinguish it as such as it's a prominent feature, useful for navigation. On 14/01/2020 17:59, Andy

Re: [Tagging] How to tag oneway restriction applying to pedestrians?

The OP clearly defines the scope of his question with "pedestrian highways" ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag oneway restriction applying to pedestrians?

On 09/01/2020 20:17, Volker Schmidt wrote: oneway=yes|no needs indeed be applicable to vehicles only, That tag on footways would apply only to walkers. DaveF ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] addresses on buildings

On 07/01/2020 17:18, Paul Allen wrote: On Tue, 7 Jan 2020 at 16:51, Volker Schmidt wrote: May I come back to the navigation aspect. Let's assume I have a single square building aligned with the compass directions. It is between two parallel East<>West roads. It is placed closer to the road

Re: [Tagging] addresses on buildings

On 07/01/2020 00:30, Jarek Piórkowski wrote: Hi, https://wiki.openstreetmap.org/wiki/Addresses#Denmark and https://wiki.openstreetmap.org/wiki/Da:Adresser seem like a good place to start. Hi Jarek Yes I had read the first link previously. Of course nothing is truly forbidden in OSM as long

Re: [Tagging] addresses on buildings

On 06/01/2020 21:55, Volker Schmidt wrote: This depends on the country. It is "forbidden" to put the address on the building in Denmark, A similar rule exist in Italy: the number has to be put where the actual entrance is, Well, this is slightly better than floating nodes as in Denmark, but

Re: [Tagging] addresses on buildings

On 05/01/2020 18:37, Marc Gemis wrote: This depends on the country. It is "forbidden" to put the address on the building in Denmark, Hi Where does it say that? Where does it say it's forbidden to add address data to building polygons in OSM? Keeping address data separate from buildings

[Tagging] pavement placed plaque

Hi I've a carved stone plaque(?) that's fixed flush into the pavement. it's to indicate the start/finish point of a long distance walk. https://whatsdavedoing.com/cotswold-way-guide/#start Two questions: 1 Is plaque the best name? Our Wiki quotes Wikipedia as it being vertical, but that

Re: [Tagging] Rail segment in a bike route

On 14/12/2019 14:42, Volker Schmidt wrote: Adding a bicycle=dismount is OK I suppose, but I'm unsure there's really a problem. This street in Padova carries a (mono-rail) tram (railway=tram) and is closed to bicycles, tagged with bicycle=no. I

Re: [Tagging] Rail segment in a bike route

On 14/12/2019 10:17, Martin Koppenhoefer wrote: if I saw this I would think I’d have to push the bike there, not take a train Well, yes - you would have to push it into the carriage. Your assumption would only occur if the railway tag is ignored. Cheers DaveF

Re: [Tagging] Rail segment in a bike route

On 14/12/2019 07:00, Francesco Ansanelli wrote: Thanks everybody for the feedback. I've added the bicycle=dismount on the railway. I think we still need some role in the relation to better describe the situation. Adding a bicycle=dismount is OK I suppose, but I'm unsure there's really a

Re: [Tagging] emergency=ambulance_station vs amenity=fire_station

be treated as polygons when mapped as closed ways, and then submitting a PR (pull request) to add these for the next database reload, which might happen soon, if enough people are interested in making it happen. - Joseph Eisenberg On 11/11/19, Dave F via Tagging wrote: On 11/11/2019 02:20, Joseph

Re: [Tagging] emergency=ambulance_station vs amenity=fire_station

On 11/11/2019 02:20, Joseph Eisenberg wrote: If this is about Openstreetmap-carto, there is now an open issue: https://github.com/gravitystorm/openstreetmap-carto/issues/3968 - note that rendering area features in the "emergency=" key, like this, would require reloading the database on the

Re: [Tagging] emergency=ambulance_station vs amenity=fire_station

On 10/11/2019 16:53, Greg Troxel wrote: So I agree these tags should be kept separate. I'm struggling to comprehend how a question I deliberately kept simple at just one sentence long can cause so much misinterpretation. As for emergency= and amenity=, that's a historical artifact and

[Tagging] emergency=ambulance_station vs amenity=fire_station

Hi Simple question (which I presume has been previously discussed) : Why the different key tags to describe what are essentially synonymous entities? DaveF ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Service road - Can it be a driveway if serving multiple houses?

On 06/11/2019 18:04, Greg Troxel wrote: I think a shared driveway is still a driveway. This is the crux. The only distinguishing attribute from what we'd all tag as a driveway is that's it's shared. A driveway is designated as privately owned rather than by the local authority. It isn't

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

On 05/11/2019 13:11, Andy Townsend wrote: https://www.openstreetmap.org/way/65663472 (Meir Tunnel, dry even on a wet Wednesday in Stoke*) bans foot and bicycle traffic, so you can neither walk nor cycle through it.  A cycle router would have to flat-out avoid it, whereas it may choose not

[Tagging] Service road - Can it be a driveway if serving multiple houses?

Hi In the UK, Amazon Logistics are adding useful data from their GPS'd delivery vehicles. Mainly highway=service as the last part of their journey to a destination. However, one of their contributors removed service=driveway from a highway=service road. In the changeset comments they said

Re: [Tagging] amenity=hospital on things that are not hospitals - is it a good idea?

On 28/10/2019 09:42, Shawn K. Quinn wrote: On 10/28/19 03:44, Mateusz Konieczny wrote: "sign having a hospital icon and no name can simply be tagged type=destination_sign + amenity=hospital" https://wiki.openstreetmap.org/wiki/Relation:destination_sign For me it seems a horrible and

  1   2   3   4   5   6   >