User talk:Jeisenbe

From OpenStreetMap Wiki
Jump to navigation Jump to search

maxdraft/maxdraught/draft: consolidation needed

please add comments: Talk:Inland_navigation#Limitations, thanks Kannix 2020-06-01

You abstained from voting on "changing table" proposal

Hi, you abstained from voting for/against https://wiki.openstreetmap.org/wiki/Proposed_features/changing_table

Luckily you included a reason in your vote so I can investigate.

Re: "this proposal introduces too many new tags." Are you really sure? For example: It splits up `diaper=bench` into `changing_table=yes` and `changing_table:features=bench`, `diaper=room` into `changing_table=yes` and `changing_table:location=dedicated_room`, `diaper:male` into `diaper=yes` and `changing_table:location=male_toilet` etc. It also makes possible to tag `changing_table:location=male_toilet;female_toilet` instead of `diaper:male=yes` and `diaper:female=yes`.

Re: "I don't think the other tags are necessary." Just the subkeys `changing_table:features` and `changing_table:access` are new and fully optional to tag. The subkey `changing_table:location` replaces `diaper=room`, `diaper:male=yes` and `diaper:female=yes` and adds support of more scenarios like having a changing table in the wheelchair users' restroom/toilet. E.g. I need to tag a changing table inside a toilet for users of a wheelchair. This isn' t possible with the `diaper` key beside the other reasons why we should replace that key.

`changing_table` supports more scenarios than `diaper` and adds systematic tagging that is easily understandable and logically good. It does the necessary abstraction of the `diaper` key to make tagging changing tables a lot easier while allowing complex tagging and supporting more scenarios. Valor Naram (talk) 08:30, 5 May 2019 (UTC)

Your reverts on Tag:natural=peninsula and Tag:natural=isthmus (ValueDescription data)

Hi! I thought we are migrating the data of the ValueDescription info boxes to wiki items. Duplicating the data in the ValueDescription template makes maintaining it much harder (there are already the Map_Features templates that still need to be edited separately). Regards --SelfishSeahorse (talk) 09:32, 9 June 2019 (UTC)

I edited them because I had noticed that the descriptions in the Map_Features page were very short, and I don't know of another way to get the description right in Map Features, Taginfo and the ID Editor. Has there been some discussion about using separate wiki items for this? Where do I find the wiki items if I need to edit the descrition? --Jeisenbe (talk) 11:42, 9 June 2019 (UTC)

maxtents

I see that you (with some good reasons ;-)) removed maxtents from toursim=camp_pitch. You mentioned a pending discussion on the tagging list. Hope the discussion is dealing with toursim=camp_site too. BTW I would prefer capacity:tents too. --Nospam2005 (talk) 08:33, 3 July 2019 (UTC)

Yes, I asked about it just today. I'm also working on a proposal to clarify the property tags for campsite: Proposed_features/Campsite_properties. If you are interested in improving the Wiki and keeping up on new tag proposals, I'd recommend subscribing: https://lists.openstreetmap.org/listinfo/tagging --Jeisenbe (talk) 11:55, 3 July 2019 (UTC)

De facto

Hi, thanks for your clean-up of tag status fields, most of them make a lot of sense! However, I'm not so sure about your change of atm=yes from "in use" to "de facto". In my opinion, being a de facto standard doesn't just mean a lot of uses (by mappers and developers), but also the absence of meaningful opposition/competition. In this case, there's a competing tag, amenity=atm, with a comparable number of uses and an approved proposal to back it up. This raises the question where we draw the line for "de facto" status. When changing the status of maxstay, your edit comment mentioned "no major competing tags", leading me to believe that you agreed this should be a factor. Did I misinterpret that comment? --Tordanik 14:40, 7 July 2019 (UTC)

I agree with you: there shouldn't be an ongoing debate about what tag to use. Fortunately, there is no competition between atm=yes/no and amenity=atm - the first is a property or attribute of another feature, like a bank. It lets you know whether the feature has an atm or not. The amenity tag is for mapping an atm as a separate feature, almost always on a node. Similarly, both drinking_water=yes/no and amenity=drinking_water are approved tags; the first is a property of a feature like a spring, foutain or campsite: is there drinkable water there? The second is a separate feature, tagged on it's own node. --Jeisenbe (talk) 14:48, 7 July 2019 (UTC)
one could argue that amenity=atm isn’t competing with atm=yes, as the property is for a different feature which isn’t an atm. Or in other words, atm=yes isn’t defining an atm, it just states there are one or more atms in the feature. If you add atm=yes to a bank it does not imply you have to refrain from mapping the atm explicitly as its own object.—Dieterdreist (talk) 20:15, 7 July 2019 (UTC)
Some mappers will argue that one should place an amenity=atm node inside the bank polygon instead of adding atm=yes to the bank. The page actually used to say "if possible you should try to place a separate node". This has since been softened to "this may be preferred", but I feel there's still some residual competition between atm-as-a-feature and atm-as-a-property.
That being said, I can see how one could reasonably conclude that atm=yes has earned "de facto" status. I brought this up mostly because Jeisenbe is editing this field for several objects, and I wanted to learn about his general criteria for deciding the status. These seem sensible enough as far as I can tell. :) --Tordanik 20:44, 7 July 2019 (UTC)
The status In use does not need to be changed to De facto! To me the difference between the two is that the status De facto came earlier in OSM history so was used before In use. I would prefer to see that history maintained and not removed. If all the status tags are to be 'tidied up' then decide on a very limited number of values and use only those? Say De facto, Draft, Proposed, Voting and Rejected. So Accepted and In Use would all move to De Facto loosing any possibility of easily seeing where they can from. I vote against the reduction in status values. Keep In use. Warin61 (talk) 00:44, 9 July 2019 (UTC)
Defacto in OpenStreetMap means established but not approved through voting. You also have to distinguish approved and rejected mean the definition has been voted on, while in use and defacto mean the definition was not voted. The difference between the latter is that in use tags will either not be used in significant numbers or there are competing ways to tag the same thing or property. Consequentially, defacto tags should be generally accepted as standard and used in significant numbers. —Dieterdreist (talk) 08:04, 9 July 2019 (UTC)
I agree with Dieterdreist and the current documentation supports this. The page Template:ValueDescription defines "de facto" as "the tag is in widespread use, but no formal proposal process has taken place", versus "in use": "the feature is in use". I believe it would be good to make a new page that specificially states this, separate from the hard-to-find template page, and perhaps gives some more clarity about when to set the status to "de facto". My standard is to use "de facto" for tags that have been used a large number of times in multiple countries, is supported by more than one editor and more than one database users (eg rendering, routing app etc), and is not disputed or in conflict with another tag. "In use" means that the tag is currently being used to add new features: it wasn't from an abandoned proposal or a single import, but this includes tags that are quite rare and not supported by any editors or database users, and tags which have a better alternative. --Jeisenbe (talk) 10:41, 9 July 2019 (UTC)
Generally with tag status there is some confusion, because the voted stati are about a concrete proposal, while the usage stati are about usage (and absence of a proposal). The real situation for a tag could include (one or more) "rejected" proposals (rejected definitions) and still be the defacto standard ;-) Or there could have been 2 proposals for the same tag, one rejected and one approved. Or we could even have 2 approved proposals for the same tag ;-) I guess we cannot deal with this currently? --Dieterdreist (talk) 11:10, 9 July 2019 (UTC)

tag waterway=sluice_gate

why did you undo my tag waterway=sluice_gate ? A lock gate and a weir is a type of sluice gate, but not all sluice gates are lock gates or weirs. So, it would be better to 'deprecate' 'lock gate' and 'weir', instead of 'sluice gate', and if one want to go 'in detail' with 'sluice gate', one can simply add 'details*'=yes . There are several types of sluice gates ... valve-types/ring gate types/vertical lift gates/radial gates/stoney gates/sector gates/inflatable gates/etc... -> https://nptel.ac.in/courses/105105110/pdf/m4l10.pdf

https://www.shutterstock.com/nl/search/sluice-gate

--Henke54 (talk) 09:13, 18 July 2019 (UTC)

As I mentioned in the comments on the change: The tag waterway=sluice_gate was not yet documented with a wiki page and has only been used 200 times. Please create a proposal page and discuss the tag with others prior to adding it to the Map Features page. While anyone can make up new tags without a proper proposal, the Map Features page is supposed to only include tags that are well established or approved by the community. I've made a stub page to document this tag, but it would be preferrable to write out full documentation and then discuss on the Tagging mailing list, as recommended at the page Proposal process. --Jeisenbe (talk) 14:09, 18 July 2019 (UTC)

amenity=embassy status

maybe the status of the tag should be “obsolete”, as amenity=embassy was not approved by voting? On the other hand this is still the defacto standard because it is mostly used and you can hardly ignore the tag when looking for an embassy.—Dieterdreist (talk) 08:24, 28 July 2019 (UTC)

I tried "in use" for now - it's certainly still being used (probably even for new map features, though this would take some work to prove) but I think it's no longer "de facto" since office=diplomatic + diplomatic=embassy is now a tag that means the same thing. I think a "de facto" tag should be the clearly primary tag used for a particular feature, telling wiki users "yes, this is the right tag", so if there are two competing tags they can be "in use" or another status.
Probably the proposal for office=diplomatic should have made it very clear how it was supposed to replace amenity=embassy and if voting for it was a vote to deprecate the other tag. We might add something to the Proposal Process page that says "any tags that will be deprecated by this proposal should be listed at the top, under the "Proposal" heading, as well as in the "pages affected" section" or something like that. --Jeisenbe (talk) 12:28, 28 July 2019 (UTC)

Looking at the actual usage, if you want to make a map of embassies you would still have to look at amenity=embassy as it is the de facto tag which by far the most embassies are tagged with. Yes, there was a vote, but this doesn’t guarantee that the transition will actually happen, think about highway=bus_stop. My advice would be to keep amenity=embassy on the embassies and additionally put the new tags. IMHO it is still a defacto tag, although there should be mention of the alternative tagging in the documentation, sure.—Dieterdreist (talk) 15:20, 28 July 2019 (UTC)

Status removal

Hi, your status removal here is not correct -- the Key:access:roadtrain:trailers has status=abandoned. I would actually recommend reverting data item change, and modify it to be set to abandoned (Q19) instead (see all statuses). P.S. I also think it would be great to remove the status from the wiki page -- redundant (it will still show up properly because of the data item) Thanks! --Yurik (talk) 14:55, 5 August 2019 (UTC)

I tried to do that, but I couldn't get the status "abandoned" to show up as an option, so gave up. I expect your bot will fix it in the morning. I promise I'm not usually this incompetent. Perhaps my internet connection is too flakey? (It's via satellite uplink) --Jeisenbe (talk) 14:58, 5 August 2019 (UTC)
Sadly no, the bot won't fix it -- it will never touch anything contaminated by humans :) In other words, if you modify a specific property of a data item, that property becomes taboo for the bot. So it has to be forever maintained by the human. And yes, sometimes autocomplete might get confusing (because we have more than one item with the label "abandoned"), but you can always just type Q-number directly (if you know it). --Yurik (talk) 15:14, 5 August 2019 (UTC)
Re: "I also think it would be great to remove the status from the wiki page -- redundant (it will still show up properly because of the data item)" - I disagree. When this happens, it becomes completely confusing when you go to edit the page, and then wonder "was I imagining things? I thought I saw a status set there?"
Please discuss such major wiki formatting changes at the Talk mailing list prior to removing "status=" and "status=link" from the description boxes on wiki pages. --Jeisenbe (talk) 15:00, 5 August 2019 (UTC)
This has already been done in many places for various params - it is much harder to keep multiple wiki pages and a data item in sync -- much easier to just rely on the data item (most wiki pages tend to mismatch). I agree about the confusion -- eventually the hope is that wiki page will not have ANY data -- you will just write {{ItemDescription}}, and it will do the rest, plus give you a few pencil icons to modify these things quicker. But this is in a future - for now it is up to you if you want to have dups or not. Thx for helping with it! --Yurik (talk) 15:14, 5 August 2019 (UTC)

Moving key/tag pages to "Proposed features"

I just saw that you recently moved some tag pages to new names starting with "Proposed features". I usually remove Template:KeyDescription and Template:ValueDescription from proposal pages, to clarify that a specific page is a proposal (and not a tag information page). Apart from personal preferences, the page Proposed features/Tag:place=civil parish looks strange. You did not move the Italian version and without Template:Proposal Page an occasional wiki user would not figure out that it is a proposal. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 21:27, 14 August 2019 (UTC)

Thank you for catching that. I hadn't expected to find a translated page for such a new tag. I've moved the Italian translation now, and changed the templates to Proposal Page - meant to do that last night but forgot. --Jeisenbe (talk) 00:22, 15 August 2019 (UTC)
Okay, I just asked about all this on the Tagging mailing list, and it turns out there are a number of people who believe it's perfectly fine to document new tags in the regular Tag: and Key: namespace, as long as they are used and the documentation matches the actual use. So perhaps we should not be moving these to proposal space after all (except for those that have never actually be used in the database)? Discuss more at [[1]] or on the Tagging mailing list if you want to add your viewpoint about this issue. --Jeisenbe (talk) 12:17, 15 August 2019 (UTC)
Thanks for the update. When reading a tag page with status de facto, draft, proposed, or undefined in Template:KeyDescription I would assume that there was no accepted proposal already. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 15:42, 15 August 2019 (UTC)
I think "Any tags you like" is ok - until someone protests. Otoh if you think some key/tag needs serious discussion or is a "vanity tag" don't hesitate to move it "out of the way". RicoZ (talk) 20:35, 25 September 2019 (UTC)

Moving Key:walk-in to "Proposed features"

Hi, thanks for your work organizing the wiki. Regarding https://wiki.openstreetmap.org/w/index.php?title=Proposed_features%2FKey%3Awalk-in&type=revision&diff=1889922&oldid=1889900 : I don't mean to have Key:walk-in go through a proposal process. I was following Any tags you like while editing OSM and wanted to explain what the tag I added meant in case someone else stumbled on it. ("You can use any tags you like, but please document them here on the OpenStreetMap wiki, even if self-explanatory.") Feel free to add a status=unofficial or unapproved or whatever. Do you know if https://taginfo.openstreetmap.org/keys/walk-in will continue to pull content from the wiki page when it's under proposed? --Jarek Piórkowski (talk) 23:53, 14 August 2019 (UTC)

I've added a new discussion section to the "Proposal process" page and the "Any tags you like" page to talk about this more generally. While I've documented tags myself when I found that they were already being used by a number of other mappers (see Tag:natural=mountain_range and Key:building:structure, I believe that brand-new tags which are only used by one person should be documented in your own user space (e.g. User:Jeisenbe/Tag:key=value or as Proposed_features/ page. You are not required to send out an email or discuss a draft proposal with anyone, just make the page and document it. But I'm perfectly happy to send an email to the Tagging list so that other people will be aware of your new tag and perhaps make suggestions on how to improve it, if needed (which you are free to ignore). Getting more people involved also makes it more likely that more people will start using your new tag. Also, a proposal page (or using your user space) makes it clear that this is "your tag", and that other wiki editors shouldn't just change the description or redirect it, like with a standard feature page. --Jeisenbe (talk) 01:10, 15 August 2019 (UTC)
Is this discussion https://wiki.openstreetmap.org/w/index.php?title=Talk%3AProposal_process&action=historysubmit&type=revision&diff=1890030&oldid=1885456 or was there something else?
I'm annoyed by me having followed a long-standing wiki/OSM practice and instead being pushed into a proposal process something or other. If I wanted to have suggestions from the tagging list I would have posted there and made a tagging proposal. If someone sees the tag and wants to discuss improvements on the tagging, I am all ears, but frankly I'm not really interested in a process of having Germans or Brits tell me why a tag is bad. The sentence "You can use any tags you like, but please document them here on the OpenStreetMap wiki, even if self explanatory." has been in the page literally since the beginning of the page in 2008 https://wiki.openstreetmap.org/w/index.php?title=Any_tags_you_like&oldid=180586 and that's what I did. The key:walk-in was there to explain how I've used the tag. Feel free to add a big "this tag was only used 11 times by one editor" sign on it if you like. If you would like to change the wider principle I would suggest starting a much wider discussion. If not, please move the tag page and all the links to my userspace. --Jarek Piórkowski (talk) 01:25, 15 August 2019 (UTC)
I've also opened discussion at Talk:Any_tags_you_like and on the Talk mailing list and Tagging mailing list, since the Proposal process page and the advice in Any tags you like are different.
If you want to move the page back to Key:walk-in or over to User:Jarek Piórkowski/Key:walk- either is fine by me, just click on "More" between the View History and the search box, and then select "Move". But I think your tag is probably a good idea which could be approved: then it could be added to more visible pages like Map Features and the various healthcare-related wiki pages. --Jeisenbe (talk)
Outcome of discussion on Talk and Tagging list so far: it looks like there is plenty of support for just documenting new tags in the regular Tag: or Key: namespace, if you want to (though a few people disagree) See Tagging mailing archive. I'll move the page back to the original location for now, but you are always free to move it to your User space or make it a proposal if you want to. --Jeisenbe (talk) 12:23, 15 August 2019 (UTC)
Thank you, I have moved it back and will make some changes based on your questions. I would encourage you to reach out to the editors if they are active on the wiki before reclassifying things as "draft proposal".
Feel free to start a proposal process for walk-in/booking/reservation tags (or maybe enrollment=only rather than walk-in=no?) and see what the consensus shakes out to. "Reservation" for a doctor's office seems weird to me - reservation is what you have at a restaurant - but I can live with that. Though incidentally, the discussion in mailing list changing over into what to do about booking.com URLs and then petering out is an example of why I didn't bother with the process for this tag. --Jarek Piórkowski (talk) 16:08, 17 August 2019 (UTC)
Thanks for responding to my other questions over on the Talk:Key:walk-in page; that's very helpful. While half or more of the responses on the mailing lists are unhelpful, usually there are one or two useful responses. --Jeisenbe (talk) 00:32, 18 August 2019 (UTC)

layer=* is not an "extra tag for rendering"

Replying to your comment here because I think it would be spam to discuss it on the Carto tracker.

layer=* has a long evolving history. There were endless "battles" (before my time) whether layer should mark areas to render "above" other areas. Many mappers (mostly before my time) thought every river and creek should have "layer=-1" because "it is lower than surrounding ground". Some projects had the idea of deriving height/elevation information from "layer". Many mappers used "layer" as a simple method to hide warnings about crossing ways. The result was a mess so that the tag was close to useless for data consumers because of predominantly wrong use.

I am responsible for most of the definition/overview/intro section of the current layer=*, pushed this and many checks for validators after some debates on the mailing list(s) and discussions with individual mappers.

If you are curious you can look at what it looked like before my first edit. I hope the core of the definition is pretty solid now. RicoZ (talk) 20:26, 25 September 2019 (UTC)

It would be better to discuss this on Talk:Key:layer. I have no problem with the current use of the layer=* key, it seems to work pretty well, and it does represent a real-world property (although interpretation requires considering all the ways that cross each other in a certain area). But I also see covered=yes as representing something real: that the way is covered by another surface (like a roof or bridge or pedestrian square etc), but not fully enclosed in a tunnel. --Jeisenbe (talk) 01:01, 26 September 2019 (UTC)
Agree, both are here to model real world properties. Technically there are significant differences between and covered=yes and the more specific values but I don't complain as long as it works:). RicoZ (talk) 18:11, 28 September 2019 (UTC)

Proposal process

Hello, Jeisenbe, thank you for your suggestion of initiating a new tag proposal. I felt that something of this kind should be done, but did not know what exactly to do. Now, I am new to this wiki, and I find the description of the process on the page you indicated somewhat unclear. I am not familiar with the customary procedures, so I am afraid to create more harm than good. Isn't there any template I could utilize to this purpose, please? I feel a little lost in the rules. Thanks, --Hlv (talk) 11:05, 4 November 2019 (UTC)

You can use the proposal page template here: https://wiki.openstreetmap.org/wiki/Proposal_process#Proposal_Page_Template - it is also helpful to look at a few other proposals to see what things are included. Here are a few examples: -

You can also try emailing the [Tagging mailing list https://lists.openstreetmap.org/listinfo/tagging] first with your ideas to get feedback. --Jeisenbe (talk) 11:57, 4 November 2019 (UTC)

attraction=roller_coaster

Hello! You have edited a number of different wiki pages related to attraction=roller_coaster, so let me ask here your personal opinion about this tag. Should attraction=roller_coaster be recommended for open ways or not? It seems from your edits that you are suggesting that attraction=roller_coaster should not be applied to open ways alone, but if it is specified together with roller_coaster=track then it is acceptable. Is it right? Thank you! QGIS User (talk) 02:28, 23 November 2019 (UTC)

Mass removal in Key:lunch

Hello! Thank you for updating statuses in my various articles and extending content. Could you please take some time to explain why you removed so much from the lunch article? I think in order for the concept to really go through, we need to provide much more context. There exist various articles that are much longer and much more elaborate. If you still think something should be refactored, it is polite to ask on the talk page first and/or to move content to the talk page instead of simply deleting it. -Bkil (talk) 21:03, 17 December 2019 (UTC)

Also the whole article has been translated to various languages, and many of these paragraphs are needed to explain some of the concepts that may or may not be universal across cultures. I'd rather have most of the information restored, although you are welcome to do some copy/editing and improving to content as you desire, especially if you are a native English speaker. -Bkil (talk) 22:37, 17 December 2019 (UTC)
Please discuss at the tag talk page: https://wiki.openstreetmap.org/wiki/Talk:Key:lunch --Jeisenbe (talk) 07:38, 18 December 2019 (UTC)

At least it would be nice if you could wait

You don't seem to understand the basics of programming, but immediately press the reset button.

At least it would be nice if you could wait until I explained this to you on my discussion page. Was just there, but with your posts icht can now rewrite everything again. Thanks --Ottonormalverbraucher (talk) 12:38, 25 December 2019 (UTC)

Sorry, I'm not sure what you are referring to? --Jeisenbe (talk) 12:39, 25 December 2019 (UTC)
I would like to answer your questions on my user page. If you work on them all the time, it's difficult. --Ottonormalverbraucher (talk) 13:04, 25 December 2019 (UTC)

hazard for natural=cave_entrance

I did this modification because:

  • i"m speleologue at Union Belge de Spéléologie.
  • Public services have signaled this cave has risk of fall

How would you inform people of the dangerousness of the place? 16:15, 21 January 2020‎ Rammstan

Rammstan, Thank you for helping to improve Openstreetmap. Let's discuss this at Talk:Tag:natural=cave_entrance. --Jeisenbe (talk) 02:50, 23 January 2020 (UTC)

Edit to parts article

Maybe they have no usage, but that's why they are possible values right? I thought that was the point? Really, I mostly put parts=motorcycle in it to offset the motorcycle:parts none sense. Although, that tag is mainly used in cases where parts=yes is also fine to use. That said, I agree with you about parts=oil. I have no clue what oil parts are. There actually use to be a lot more usage of the parts tag and various keys related to it until RTFM gutted the whole thing. I'm kinda trying to bring it and other tags that he desecrate back. So, whatever values might or might not have been in use before he mass edited them into oblivion, IMO it's still worth mentioning different options in the article, even if they might not currently be in use. So people know what they can use as a substitute for his tags. Especially if it's ones that were in use at one point, but aren't now because of his actions. Btw, if you want to see a good example of it compare parts and parts:motorcycle to each other in OSM Tag History. The mass gutting is still going on. Same goes for other tags that compete with his. Hence the keys that might not be used, but still have value being listed as possible options. Although, I'm also fine not listing them if need be. I guess. --Adamant1 (talk) 11:24, 10 March 2020 (UTC)

Are we talking about Key:parts? If you would like to propose new tags, it would be proper to create a proposal page like Proposed_features/Key:parts and add the suggested tags. The "Key:" and "Tag:" pages are for documenting tags that are actually being used. --Jeisenbe (talk) 11:47, 10 March 2020 (UTC)
Yeah. I'm pretty sure I don't have to do a proposal for it. Since it's been in use for ten years, had upwards of 1,200 uses by over 300 users, and was on a consistent study increase before RTFM messed with it. So, at best its in use, if not de defacto for that type of tag. Especially considering RTFM's tons of article and mentions about every tag he can think of, even if they have zero/small uses only by him that know one is putting in check. Even if it was not for that though, there are tons of articles around about de defacto/in use tags that don't have proposals and I see no reason why this should be a special case. Although, I agree there should be a limit on what tags deserve an article or what should qualify to be called in use (let alone de facto). A tag that's only been edited by a single user or one that only has tons of usages due to mass editing of a more established tag shouldn't qualify as either de facto or in use IMO, but the wiki isn't clear where the line is from what I've been able to find. Except for stating tags with zero use shouldn't be called either of those things or be included in articles, but that leaves a lot of Layaway for RTFM to get away with things he shouldn't be able to. Perhaps you know where the line is better then I do though? --Adamant1 (talk) 01:44, 11 March 2020 (UTC)
You are right, there's no need to approve the Key "parts=" since it is already in use, but if you are suggesting that other mappers might want to use tags, which are not yet used, those specific tags (like parts=motorcycle) could be mentioned in a proposal. If you don't want to make a proposal, you can just start using the tag and then document them on their own tag pages. But I don't think that theoretical tags should be documented on Key: or Tag: pages - they have to have been used at least once. I personally don't care what tags are used for motorcycles, but if this is important to you, a proposal would be the best way to get your ideas accepted by the community. --Jeisenbe (talk) 10:03, 11 March 2020 (UTC)
I'm fine with forgoing parts=motorcycle. The only ones I really care about are yes/no and the other few with some usage. I prefer to let tagging happen naturally anyway. I assume if there's no usages of parts=motorcycle by now its becuase there is no need for it. Parts=yes is perfectly fine in 99% of cases anyway. Its to bad there aren't better standards for this kind of thing though. As there's lots of hoerible tags with lots of uses out there and visa versa. Oh well. --Adamant1 (talk) 13:16, 11 March 2020 (UTC)

Workshop

Thanks for your changeset comment in workshop article. I was planing on researching the tag more when I got a chance. After doing a little digging it looks as though FabLabs are a trademarked entity that are different from hacker spaces. Although, I am not exactly sure how, but it seems to be more of a none profit social facility where people create things. I guess that technically apply to other hacker spaces also though. So, who knows. There is a social facility tag for workshops, but I don't think it's definition necessarily fits them. So, I'll do some more digging, I guess. That said, I don't necessary feel the need to create a proposal for it at this time. As it was more creating a document for an existing tag, compared to something I'm 100% solid on advocating for. I be in the future though, but there is a point (I think maybe something like over 100 uses by more then 20 different editors or something close to that) where things can and should be documented without them having to do proposals. Whoever the tag is or isn't used. For instance there are plenty of "one off" articles for random tags that where done in single imports and things like that, just to inform people what's "out there." Which I see nothing wrong with. Nor do I think a proposal would be needed in those cases. Who knows where the line is though. In this case, I'll probably figure out what the best way to re-tag the instances of FabLab is, if any, and reevaluate things from there. I'm sure a lot the of the uses of the workshop tag could be updated to more modern ones also. Which makes me question even more the usefulness of the whole opening_hours:workshop tag, but that's a different thing. Except to say, there must be such a thing as a pure workshop. Even if I can't point to any right now ;) Do you think there is a such a thing or are "workshops" probably better tagged with other tags? I'm fine with it if they are. --Adamant1 (talk) 05:23, 13 March 2020 (UTC)

(It would be better to talk about this on the tag page). It turns out there was a proposal for Key:workshop back in 2013: Proposed_features/Key:workshop - it looks like they were going to use the tag as a primary feature tag for hackerspaces, including "fablab" and "repair cafe" locations. Most of the values are still workshop=fablab.
It's totaly fine to document workshop=* and amenity=workshop, as long as the text of the wiki page is based on how the tags is currently being used by mappers.
One thing to figure out would be a good definition for "workshop". The proposal was going to be only for non-profit, community "workshops" like some hackerspaces, but the work "workshop" in English has a wide variety of meanings. In particular, should amenity=workshop only be used for public workshops (it's under "amenity") or is this being used for private or industrial workshops as well?
Looking at actual usage (http://overpass-turbo.eu/s/RyA) there are a large number of workshops in Zanzibar, Tanzania: there are 334 nodes in that region. These are anything that might be called a "workshop": car repair, welding, carpentry, bicycle repair - many could instead be under a different tag in amenity=* or craft=*. The other main usage is in French-speaking parts of Europe, almost all with the name "Repair Café" which I guess is a brand?
It's a good idea to check overpass turbo prior to making a new feature page to find out detail like this. --Jeisenbe (talk) 05:51, 13 March 2020 (UTC)

Rental

I'm fine with it not being in the shop=car article since like you said it doesn't have any usages there. As a compromise though, I will be keeping it in the shop=motorcycle article after you purge it because it was tagged on many motorcycle shops before RTFM mass-edited them and it still is although to a less degree unfortunately.

Blanking redirects

It’s better to ask for redirects you don’t think are useful to be deleted than to change to a blank page. --Andrew (talk) 22:05, 15 March 2020 (UTC)

That seems like such a pain for the wiki maintainers. Oh well. What template should I use for that? --Jeisenbe (talk) 22:28, 15 March 2020 (UTC)
Use {{Delete|your reason}}, please. That is way easier than blanking because all pages will show up in Category:Labelled for deletion. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:40, 21 March 2020 (UTC)
Thank you. I will avoid messing with the redirects in the future, probably not worth the trouble for everyone. --Jeisenbe (talk) 12:35, 21 March 2020 (UTC)
It is perfectly fine to ask for the deletion of confusing redirects. Template:Delete is just needed so that other users know that you requested deletion, giving them a fair chance to respond, and notifying wiki admins about your request. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 14:25, 21 March 2020 (UTC)

water=riverbank

Why this change? water=riverbank is a duplicate of water=river and waterway=riverbank. --Klumbumbus (talk) 21:10, 20 March 2020 (UTC)

Oops, you are right. I read it as "waterway=riverbank", not "water=riverbank". (It's easy to see how this mistake happens). --Jeisenbe (talk) 23:47, 20 March 2020 (UTC)
Thanks. --Klumbumbus (talk) 11:39, 21 March 2020 (UTC)

Tag:bus=no

Hi Jeisenbe! I've to ask for your revert of Tag:bus=no on 2020-04-13 11:46(UTC) because it isn't intirely clear to me. The supplement I decided to, resulted from IMHO illogical meaning of the existing text due to the transforming from the page Key:bus (bus=yes) into the page bus=no. Text bevor my edit: "The Public_transport proposal in 2011 approved using bus=no with public_transport=stop_position on a node on the highway=* way to show where a bus stops on the street." — There is the "bus=no" in it! I thought about what to do. First shot was to add a "does not" in front of "stops". But after flying over the original proposal I decided to re-transform the "bus=no" in this sentence in the original "bus=yes" from the source (bus=*) and to add the supplement (version 2020-04-12 18:57(UTC)) with the "(optional)" indication: Text: "And (optional) bus=no, if a bus does not stop on this node."
In the proposal at #Stop Position there is listed "bus | yes / no" (in the table) and recommendation "optional". So "no" is mentioned IMHO. I have no worries with it, but in my opinion the text like it is currently makes less sense, particularly with following sentence "This is mainly useful ...". First sentence has the yes, the following refers to no. — May be the first shot version with bus=no and where a bus does not stop on a street? Please feel free to handle it as you think best! --regards! Chris, Chris2map (talk) 13:52, 13 April 2020 (UTC)

Ah, I didn't find that table. It doesn't make much sense to use bus=no with public_transport=stop_position, except in the rare case of a tram and bus sharing the same way - but usually trams have their rails mapped separately: http://overpass-turbo.eu/s/SMn - The rest of the proposal really only mentioned "bus=yes" with stop_position nodes. --Jeisenbe (talk) 13:59, 13 April 2020 (UTC)
I like the solution, thanks! --Chris, Chris2map (talk) 14:07, 13 April 2020 (UTC)

craft=shoemaker

Hi. I was looking around for a tag to add to shoe stores that repair shoes. Craft=shoemaker seems appropriate, but I see you removed the combination of shop=shoes from it's article. While I agree that "shoemaker" might make it sound like it doesn't work for that, but I'm not sure what better tag there would be. Except for repair, but craft=shoemaker is used with shop=shoes roughly 200 times. Whereas, repair=shoes is only used 14. So, is there any way you could add shop=shoes back and maybe add craft=shoemaker to that article? It's better to go with the approved tag when you can. Instead of forcing people to go with a janky work around, like a pointless namespace or a tag that has almost zero use in the case of repair. BTW, in the shop=shoes article RTFM inserted a thing saying that craft=shoemaker doesn't apply to shops that repair shoes. I'm not really clear why. Since the craft=shoemaker says it's for places that repair shoes. Since your the one that edited the article to not include shop=shoes would you have any idea why he's saying that? It seems like it would be a fine tag for shops to me. Nothing excludes craft tags from being added to shops. --Adamant1 (talk) 09:15, 19 April 2020 (UTC)

Amenity=hospice revert

Since when does every sub key of a tag have to be approved, especially for a specialized tag like social facility for it to depreciate something? There's depreciated tags all over the place where a sub tag of an approved tag has more use. There's even tags that depreciate other ones when they are aren't even approved. For instance amenity=park is depreciated for leisure=park even though it's only de facto, etc etc. So I see zero problem here. It could be deprecated for both healthcare=hospice and social_facility=hospice. I don't really care. The point is, there's a better tag (or tags) out there. Just having a little banner at the top saying "pretty please use an alternative but you don't have to though" doesn't cut it IMO when there's clearly better options. --Adamant1 (talk) 20:14, 20 April 2020 (UTC)

I'd be fine with deprecating it, but there should be a clear alternative. To deprecated it, healthcare=hospice could be approved first via the proposal process. Or there would need to be clear community consensus in favor of that tag instead of social_facility=hospice or amenity=hospice. --Jeisenbe (talk) 22:38, 20 April 2020 (UTC)
Unfortunately, it's not really clear though if hospices are social facilities or healthcare ones. Even if healthcare=hospice has more tagging. Either way, it would be good to depreciate what amenity tags we can, especially if it's already covered by a none amenity top level tag, but I guess the numbers need to be lower and there needs it be clearer what tag should be the preferred one. I'm at least going to mention social_facility=hospice in the banner though. --Adamant1 (talk) 22:56, 20 April 2020 (UTC)
I've worked at a hospice during my medical training. They are certainly medical facilities, especially the inpatient facilities which are usually mapped. --Jeisenbe (talk) 23:34, 20 April 2020 (UTC)
I don't know. Like I said on GitHub, they can also be outreach places where someone goes out to the persons home. It's more about the type of end of life care being provided then where it takes place. Although, it can take place in medical facilities, but it's not exclusive to them. IMO the best way to go would be to use social_facility=hospice in conjunction with healthcare=hospice depending on the circumstance. The wiki description of social_facility doesn't preclude it from being used for tagging facilities where healthcare takes place though. So, I'm mixed on what the best option is. --Adamant1 (talk) 20:32, 21 April 2020 (UTC)

Removing parameters from template

Sadly, currently removing parameter from template results in data item (likely invalid) data to be used.

I finished your two edits ( https://wiki.openstreetmap.org/w/index.php?title=Key:craft&curid=65195&diff=1986136&oldid=1985784 and lane one) by purging invalid data also from a data item (it may be necessary to wait a bit before cache is purged and template stops showing wrong entry)

See https://wiki.openstreetmap.org/w/index.php?title=Item:Q184&action=history

Mateusz Konieczny (talk) 22:19, 3 May 2020 (UTC)

Thank you for the reminder. --Jeisenbe (talk) 20:58, 4 May 2020 (UTC)

Maze

Hello Jeisenbe,

I saw you edited tag:attraction=maze to make clear that this is a de-facto, in use tag. I have been adding a lot of mazes in the Netherlands recently, and have tagged them all with attraction=tourism + tourism=maze.

However, now the wiki has some conflicting info

  • the general Mazes page says the attraction=maze-propsal is abandoned, and points to tag:leisure=maze.
  • Tag:leisure=maze is a placeholder page, not showing much info, but that attraction=maze is abandoned.

attraction=maze is used about 830 times, while leisure=maze is used about 270 times. Then according to the page Mazes, there is also maze=labyrinth which is used 33 times.

I am all for unification of tags, but how should we proceed on this? Just edit the wiki to show attraction=maze is the one and only? Hold a formal decision process on the taginfo list? And then afterwards, manually or botwise change all leisure=mazes to attractions (or the other way around)?

a Christian Labyrinth

Also, what I miss in the wiki is the explicit mention of "proper" labyrinths, which are the "mazes" that have only one long route to the center - and is currently often depicted in or near Christian churches, often on a flat floor and with differntly-coloured tiles as deleniator. Those are more of a contemplative nature. If you would lead a kid(of whatever age) to one of those instead of to a "proper hedged" maze, you might disappoint some. Should the maze=labyrinth be used for this? If so, then should there be a "maze=maze"-like tag for mazes which do have split-offs? IIVQ (talk) 12:20, 1 June 2020 (UTC)

I would recommend discussing this on the Tagging mailing list. Note that it's not necessary to have a proposal to use a tag. --Jeisenbe (talk) 14:39, 1 June 2020 (UTC)

Mapping populated places as areas for addressing schemes

Thank you for commenting on my edits of the Place key page. Note that my edit did not imply that place areas are required for addressing - only that certain regional practices treat it as such. Following your suggestion, I have created an entry on the Talk page trying to make it as clear and detailed as possible. Feel free to discuss.