User talk:Jeisenbe

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  (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  (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: -

• https://wiki.openstreetmap.org/wiki/Proposed_features/sunbathing
• https://wiki.openstreetmap.org/wiki/Proposed_features/Key:spacing%3D*
• https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:natural%3Dplateau

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  (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  (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.

Fake volcano?

Regarding [2], did you come across an example where the verifiability of a volcano would be controversial? Otherwise what makes you think this pages needs such warning and perhaps highway=primary not ? There will be always some people who map things wrongly and most of those don't read this wiki ;).RicoZ (talk) 16:47, 18 June 2020 (UTC)

See e.g. https://www.openstreetmap.org/changeset/86299088 - lots of hills in Portland, Oregon, which show no evidence of being extinct volcanoes. While it can be hard to distinguish a highway=primary from a highway=secondary, one would not be at risk for mistaking it with a railway=* or waterway=* - that's more like the difference between volacano and peak. Unfortunately some mappers enjoy tagging extinct cinder cones and lava domes as natural=volcano, even when there is no current-day evidence of this pre-historic volcanic activity. --Jeisenbe (talk) 16:48, 18 June 2020 (UTC)

Thanks for the pointer. So are you saying that if the vent or crater is not visible on ground but it is known to be an extinct volcano the combination natural=peak with volcano:status=extinct should be used instead? RicoZ (talk) 17:57, 18 June 2020 (UTC)

The tag natural=peak can and should always be used for the high point of a hill or mountain or ridge: any topographic prominence is a natural=peak. The tag natural=volcano should be used at the center of a volcanic vent. So for example if you have a volcano with a central crater, the middle of the crater (or the actual location of the vent, if visible) gets natural=volcano, while the high point on the crater rim should get natural=peak + ele=*. Where does the name=* go? That depends on local usage. If there is a dormant volcano where the vent is plugged with a volcanic dome, then you could use natural=volcano at the center of the dome. But if it's an extinct volcano where there is no evidence of where the vent was located I remove the tag natural=volcano because it does not represent a current, real-world feature: it's purely historic. The tag volcano:status=extinct is fine to use when there is a vent or clear evidence that the feature was a volcano, but it's questionable how it can be verified to be correct, if all signs of the volcano are hidden by vegetation or destroyed by erosion. --Jeisenbe (talk) 18:06, 18 June 2020 (UTC)

We have many extinct and dormant volcanoes that are "well known" and imho those should be mapped somehow. If nothing else is visible than it is probably fair to assume that the peak is a remnant or close approximation of the volcano so I would map this together with volcano:status=extinct. I think giving people a halfway correct alternative makes it more likely that they will follow this advice than saying don't do it, its not verifiable. RicoZ (talk) 18:36, 18 June 2020 (UTC)

Post-vote cleanup recreational route relation role proposal

https://wiki.openstreetmap.org/wiki/Proposed_features/Recreational_route_relation_roles Hi. You said to use the post-vote cleanup instead of adapting the proposal text to turn it into an instruction for mapping. In principle, you are right, of course. I looked at the post-vote cleanup section and I could not quite match it with this kind of proposal. The cleanup instruction looks like it is meant for features, and this proposal is not about a feature. Still, it's more than adding some remarks about roles under the relation pages: I do want a clear tagging instruction page for the approved role set. In short, yes, please help me with the cleanup! --Peter Elderson (talk) 17:52, 19 June 2020 (UTC)

shop=car see also section

Yeah, but how related are caravans and trailers to a car dealer really? Anyway, I added those values for a specific reason, because I've spent the last few weeks re-tagging motorcycle dealers and repair shops that were wrongly tagged as shop=car or shop=car_repair. Of which there were hundreds. So, there is clearly some confusion about them. If everything with a motor, or anywhere that works on something with a motor, is being wrongly tagged as shop=car/car_repair then there needs to be something in those articles to clarify things and let people know there are other tags they can use. I asked Tigerfell if he could implement the bullet point template so they can at least be side by side, but even if he doesn't implement it the article still needs to clarify things and reference the alternatives. I don't really care how that's done, but things being tagged correctly is more important then an article not being a little long. --Adamant1 (talk) 06:33, 21 June 2020 (UTC)

Please talk about particular articles on the Talk page of that article, not here. Thanks. --Jeisenbe (talk) 06:41, 21 June 2020 (UTC)

Your the one that disagreed with the change and reverted it though based on your personal opinion that it made the article to long. So, its not a general problem with the article. Otherwise I would have. Whereas, critiques about an articles length 100% should be discussed on the articles talk page. Not just reverted. Adamant1 (talk) 06:48, 21 June 2020 (UTC)

removal of SPARQL query for fire stations

Hi Jeisenbe, I partly understand why you removed the link to the SPARQL query from the tag page / see also section (as it is not required to understand the tag meaning), but I am not sure it was a good idea. It is a fun link which could help to motivate some mappers of fire stations, and it does not really harm (as a singular instance of such links), and it is directly related to fire stations. My plea would be for putting it back, if you want. Reference: https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aamenity%3Dfire_station&type=revision&diff=2016602&oldid=2015872 --Dieterdreist (talk) 08:08, 29 July 2020 (UTC)

OK, if you think it's actually valuable. The user who added this link also added about a dozen others from the https://wiki.openstreetmap.org/wiki/SPARQL_examples page to various tag pages: most of those were somewhat relevant, but this one seemed to be a stretch: couldn't we add a link like this to every tag page, in theory? --Jeisenbe (talk) 08:12, 29 July 2020 (UTC)

I am not sure it is actually relevant. I agree it is not needed. I also agree that "in theory" it could be added to every page, but as long as it is not happening I am not afraid (if it would be done, the better solution would be to integrate it in the template). I find it interesting to get such "triggers" from time to time, so that interested readers could follow the link and experiment with SPARQL, modify the query etc. --Dieterdreist (talk) 08:17, 29 July 2020 (UTC)

revert of Tag:barrier=wall

Congrats! Now it looks crappy again... The stupid pics that make it ugly, the great general description blaa blaaa blaa... : "...typically made from solid brick, concrete or rocks, and almost always built so that it is opaque (cannot be seen through)" and the same crap in the "short" description for the template. OSM is not Wikipedia. We don't picture the things! Or is so bad we have to picture things like a wall?

Since your revert now we have got a "wall=*" in the combination part of the template...

As a wall can be made of glass bricks or massiv glass panels the following part is not right or it is not a main characteristic. "...that it is opaque (cannot be seen through)" ...and so I removed it. You reverted almost all and so this is back again.

I forgot to add est_width=* again. Shame on me...!

What about a comment on the Talk page? And/Or a message to me? Nothing! That's simply bad style!

You are very quick and your English is better then mine. That's all.

--EinKonstanzer (talk) 22:44, 3 August 2020 (UTC)

Please discuss on the Talk:Tag:barrier=wall page. --Jeisenbe (talk)

revert of Tag:tourism=caravan_site

In the revert https://wiki.openstreetmap.org/w/index.php?title=Tag:tourism%3Dcaravan_site&diff=prev&oldid=2023074 of tourism=caravan_site you indicate that the edit I made was for the difference between a Motorhome stopover and a tourism=camp_site. Indeed, I am trying to specify the difference between tourism=caravan_site and tourism=camp_site. It is currently underspecified on the wiki (also see the talk page). Also see the referenced tagging mailing list discussion about this topic (https://lists.openstreetmap.org/pipermail/tagging/2020-August/054828.html). I agree that an RV park is also part of tourism=caravan_site. Can you give a list like the one you reverted yesterday, which would indicate the difference between a caravan site and a camp site for an RV park in America? That list can be matched with the one I made, and the result put on the wiki. --Hiddewie (talk) 17:26, 18 August 2020 (UTC)

There is not a simple list that will distinguish these two tags, besides the text which is already on that page: "If a site is primarily for tents, it should be tagged as tourism=camp_site". I believe this is clear: places which are mostly for caravans (RVs/motorhomes) are a tourism=caravan_site while places that are mostly for tent camping are tourism=camp_site. --Jeisenbe (talk) 05:58, 22 August 2020 (UTC)

I would agree if that description were a verifiable property of a camp/caravan site. As an example of a hard to distinguish place, a camping on the Titisee (Germany). camping and its detailed plan. There are many more pitches for campers and other camping vehicles, and a small 'zeltwiese' which is more suited for tents. I would easily classify this as a tourism=camp_site, because tents are allowed, there is mostly grass on the pitches, there is a reception and one cannot come and go during all hours of the day. Outside the camping is a 'Stellplatz fur Wohnmobile' which I would classify as tourism=caravan_site. The preceding arguments are more objective than 'the camping is more suited for tents than camping vehicles'. The wiki should be updated with some of these arguments. --Hiddewie (talk) 13:47, 22 August 2020 (UTC)

A "Stellplatz fur Wohnmobile" sounds like a "Caravan stopover site" mentioned on the page. We don't seem to have these commonly in North America, at least not in my area. While it might be reasonable to use the tag tourism=caravan_site for those features as well (I don't know enough about them to be certain), it cannot be limited to only those features, because in North America the tag is very commonly used for "RV Parks". See the map here: https://taginfo.openstreetmap.org/tags/tourism=caravan_site#map or this search for caravan_site features with website tags for many examples - https://overpass-turbo.eu/s/Xit --Jeisenbe (talk) 03:11, 23 August 2020 (UTC)

The "Stellplatz fur Wohnmobile" seems to be a stopover site, and should clearly be marked as tourism=caravan_site as per the wiki, because the place is primarily (only) meant for caravans and other motorized vehicles. My problem (and the reason for the wiki edit) is 'main' the camp site I mentioned in my example. This place could be tagged as tourism=caravan_site (with the argument "most of the places allow motorized velicles, so the place is primarily for caravans and camper vans) or as tourism=camp_site (most pitches allow tents, so the place is primarily for tents, but motorized vehicles are allowed). I would tag it as tourism=camp_site. The wiki of both camp_site and caravan_site should reflect how to make the distinction between the two tags, which is currently not the case ("primarily for campers/caravans" is not something objective you can verify on the ground. --Hiddewie (talk) 09:17, 23 August 2020 (UTC)

Your revert of barrier=boom

Hi Jeisenbe, I'm sure you mean the best for the wiki (and indeed your revert may be better for the wiki than my edit), but I feel it would have been better to ask me to revert my own edits if you feel they weren't helpful. Otherwise one is left feeling like a lot of hard work is overruled by a single person's differing view. Discussion would let us come to a common view. eteb3 (talk) 07:15, 8 October 2020 (UTC)

I apologize, that was rude of me. I've reponded on Talk:Key:barrier since there does not seem to be a page for barrier=boom yet. The basic problemis that man_made=boom is equally common and seamark:obstruction:category=boom is more common. --Jeisenbe (talk) 17:43, 8 October 2020 (UTC)

Thank you. I'll take a close look at the Key:barrier discussion page shortly. eteb3 (talk) 18:47, 8 October 2020 (UTC)

"A pitch" to "the tag leisure=pitch"?

Why exactly did you change this? Many editors don't add "the tag key=value" to the wiki articles, and I just wanted to make sure the page was uniform.

This helps make it clear exactly what tag is being discussed by the article. It's fairly standard for Tag:key=value pages. --Jeisenbe (talk) 19:28, 31 October 2020 (UTC)

Place of mourning

Hi there. Do you still have open questions on Proposed features/Place of mourning? Vollis (talk) 13:13, 20 December 2020 (UTC)

Reservoir repurposed as a basin

Hi, thanks for the cleanup edit in water=reservoir. However, are you sure that reservoirs can't become basins? It is somewhat common in my area for old agricultural reservoirs to see new development around the reservoir. During this process they decommission the reservoir from the original use of storing water for agricultural use (perhaps even building up and regrading the sides), but keep the depression in place for use as an infiltration or detention basin for stormwater. I'd suggest that the recommendation should remain, though perhaps with more specificity on when that would happen. --Phidauex (talk) 16:20, 29 December 2020 (UTC)

Let's discuss this at Talk:Tag:water=reservoir --Jeisenbe (talk) 06:09, 30 December 2020 (UTC)

added description for key service:vehicle:lpg

Greetings, I just added a description for the new key service:vehicle:lpg. It actually refers to the car repair workshops that install and fix lpg kits. Can you please revert to the version I modified so that it appears in the wiki table of service:vehicle as a new option ? Best regards

The use of the strike markup < s >

Hi @Jeisenbe - you just declared in some of your changes that the use of the strike markup example makes things harder to read and reverted them, but you just used it yourself heavily on the healthcare page for tags you don't like. In particular for healthcare=centre, you initiated a deprecation discussion on the tagging list which does not have a result yet, but you did strike the tag. Can you please explain this contradiction? --Polarbear w (talk) 11:23, 12 January 2021 (UTC)

Would you please comment on the relevant pages or provide a link? I can't remember where this happened originally - maybe nursing_home or hospitce?

I see you've reverted the change in question on Key:healthcare, which of course you are free to do. But I was under the impression that there was no opposition to deprecation on the tagging list: the one comment want to make a disambiguation list of alternative tags, which is what I meant by deprecating anyway: suggest using tags which has a specific meaning.

Re strikeout: I am mainly opposed to using strikeout by itself without an additional explanation, I see it as helpful for discouraged tags which nevertheless have been in a list for a while and are still used, so would be odd to remove. But generally avoiding is is probably also a good idea --Jeisenbe (talk) 06:58, 14 January 2021 (UTC)

Thanks, having 'an additional explanation' is a good criterion in general. --Polarbear w (talk) 12:15, 14 January 2021 (UTC)

Meet about Template:Proposal

Can we meet online via a voice call on some service like OSM World Discord Server (Discord username lectrician1#1946) or the OSMUS Slack (member id U01A8UA53L1)? I would like to explain some specifics as to what I've included in Template:Proposal and why. I really don't want to type out everything. Explaining verbally would be much faster. @Mateusz Konieczny:, you might be interested too. --Lectrician1 (talk) 06:45, 15 January 2021 (UTC)

I am just someone who has a hobby of editing OpenStreetMap, and this wiki. If you have important information and ideas to share it should be done in a public forum, not just with me or Mateusz or any other frequent wiki contributors. If you prefer verbal explanations to typing consider recording a video and sharing it on the Talk mailing list or the some other appropriate forum. Personally I prefer text. --Jeisenbe (talk) 05:20, 16 January 2021 (UTC)

What does government=bailiff mean?

Hello. Wth reference to User_talk:Pippo6: I needed a tag for a bailiff. I found bailiff is only mentioned in Pl:Tag:office=lawyer. I upstreamed it into the English versions of tag:office=government and key:lawyer. Feel free to revert, mention it elsewhere, ask for a clear definition to the Pl guys or to those who made the tagged nodes visible on overpass-turbo before my wiki edit. --Pippo6 (talk) 10:54, 3 February 2021 (UTC)

What does it mean in Poland? The term 'Bailiff" has a wide range of meaning in English. See https://en.wikipedia.org/wiki/Bailiff#England_and_Wales - where it is used for several different kinds of government official. In the USA, a Bailiff is "a police officer providing court security", who maintain order in a courtroom. According to wikipedia it seems that in Poland a "a court bailiff (komornik sądowy) is a public official (but not a civil servant) who is assigned to undertake enforcement action within the area of the jurisdiction of a single regional court" - it seems they collect court debts or financial charges? --Jeisenbe (talk) 20:43, 3 February 2021 (UTC)

I hope you will forgive me for intervening in your conversation, but AFAIK, "bailiff" is the most popular English translation for the office called "Gerichtsvollzieher" in German or "huissier de justice" in French. Their basic function is to execute civil judgments (I owe you money, you get a judgment, and now you ask the "bailiff" to go attach my earnings or whatever). The details vary a lot from jurisdiction to jurisdiction; in Germany they are court officials, in Belgium they are self-employed professionals with certain executive powers (like notaries). Vollis (talk) 15:02, 4 February 2021 (UTC)

Thanks! I will add your explanation to Key:government. --Jeisenbe (talk) 06:26, 5 February 2021 (UTC)

church:type"

Plesae revert your edits in building=church. This is very important information regarding churches / chapels. This tag defines the affiliation of the church to its parent organ, based on official diocesan sources. If you don't like it, you don't have to use it, but we have over a thousand uses. So deleting in-use tags is against the wiki policy. Especially since this tag is described on the Wiki. --Władysław Komorek (talk) 16:36, 5 February 2021 (UTC)

I have not deleted any instances of this tag in the database. In fact, I created Key:church:type to document it. But I removed mention of it from the Tag:building=church page because it appears to be a tag that describes a amenity=place_of_worship + religion=christian feature - a Christian place of worship, aka a church congregation, cathedral, basilica, parish, or chapel, etc. - but a building=church is just the type of architectural building, and it might now be converted into a amenity=theatre - for example https://www.theoldchurch.org, so Tag:building=church is the wrong place to mention it. --Jeisenbe (talk) 06:41, 6 February 2021 (UTC)

farmland

Care to explain your undiscussed edit at https://wiki.openstreetmap.org/w/index.php?title=Tag%3Alanduse%3Dfarmland&type=revision&diff=2112006&oldid=2109450 ? https://taginfo.openstreetmap.org/keys/farmland#valueshttps://taginfo.openstreetmap.org/keys/farmland#values suggests > 3k uses of farmland=pasture. SomeoneElse (talk) 11:23, 16 February 2021 (UTC)

landuse=meadow is the standard tag for meadows / pastures. See e.g. https://taginfo.openstreetmap.org/tags/meadow=pasture --Jeisenbe (talk) 01:16, 18 February 2021 (UTC)

New vote on Evaporation ponds

Thanks for voting! There were a few minor issues that were discovered after the vote started, and therefore the vote has been restarted. If you want you can participate in the new vote that was started at Proposed_features/Evaporation_basin. --ZeLonewolf (talk) 23:59, 17 February 2021 (UTC)

Wikidata: place of mourning

Hi! I'm going to revert your edit on amenity=place_of_mourning. The Wikidata item Q19833158 now is labelled "funeral parlour" in English (it used to be "mortuary", indeed), and if you look at the Wikipedia links, it only refers to Spanish "tanatorio" and Catalan "tanatori", which pages do describe what we call "place of mourning" here. The linked Commons category is still called "Mortuaries", but if you look at that, the definition is: "A mortuary is a burial building or building for the dead to remain for viewing (emphasis added). The definition then goes on to explain what a "morgue" is, but giving the link to the distinct category "morgue". And if you look at the media there, some may be a bit doubtful and the categories overlap, but even Commons has a distinct category for morgues (which is what we call amenity=mortuary, and the Commons category is linked to Wikidata Q6451172 linked in turn to amenity=mortuary). Vollis (talk) 08:22, 18 February 2021 (UTC)

Your revert on Keyːsmoothness

Hi, I noticed you reverted my edit of Keyːsmoothness, and added some text yourself under the Usage heading. I first mentioned the text you removed on that talk page on 19th November, and I proposed to add it to the introduction on 19th January. You participated in that discussion and didn't object, so I'm surprised you reverted it. What is it you don't like about it? What do you propose instead? The text you added under Usage is not a shortened version of what I added, and I'm not sure if it is actually true (I don't know of any navigation apps that use smoothness=*).--Rhhsmits (talk) 19:04, 8 March 2021 (UTC)

Your comment on boundary=place

Modifying Tag:boundary=place, you said "Not sure if that’s a good idea, but it’s happening... which means that the place= is both on the node and the area." Let's call it tagging for the renderer (and Nominatim) as places as areas are not rendered, so they need the label with name=* and place=*. And the relation needs the name=* and place=*. That's one way to avoid named landuse=residential with places mapped as nodes. Quite useful for neighborhoods --Nospam2005 (talk) 21:27, 20 April 2021 (UTC)

VEC TRANSLATION

[3] hello, forgive me for the delay, but I use very little this wiki, I'm on wikipedia !! Is there a place where you can find the entities to be translated so as to make it easier to translate the places into the Venetian language? Let's say it's not very intuitive OSM! Thank you with all my heart --Fierodelveneto (talk) 19:43, 29 December 2021 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the author of image File:50a24e7b3913bdcc8e4559e32753a93f.png ?

Or is it copied from some other place (which one?)?

Please, add this info to the file page - something like "I took this photo" or "downloaded from -website link-" or "I took this screeshot of program XYZ".

In case that you are the author of the image: Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

Would you be OK with CC0 (it allows use without attribution or any other requirement)?

Or do you prefer to require attribution and some other things using CC-BY-SA-4.0?

If you are the author: Please add {{CC0-self}} to the file page to publish the image under CC0 license.

You can also use {{CC-BY-SA-4.0-self}} to publish under CC-BY-SA-4.0 license.

Note that in cases where photo is a screenshot of some software interface: usually it is needed to handle also copyright of software itself.

Note that in cases where aerial imagery is present: also licensing of an aerial imagery matter.

Feel free to ask for help if you need it - you can do it for example by asking on Talk:Wiki: new topic.

Please ask there if you are not sure what is the proper next step. Especially when you are uploading files that are not your own work or are derivative work (screenshots, composition of images, using aerial imagery etc).

Once you add missing data - please remove {{Unknown|subcategory=uploader notified January 2022}} from the file page.

--Mateusz Konieczny (talk) 08:16, 26 January 2022 (UTC)

water=tidal

Hi, for the tag water=tidal, in the history, I can see that you have changed the statut to deprecated around 2 years ago. I'm ok with that so I just changed the wiki page to use the official way for deprecated tags. But in the text, there is a link to Deprecated_features and on this page we don't find the tag water=tidal. I would like to add it but I don't know the date (I'm not sure it is the same that the one of your change visible in the history) and I don't know the reason, if any. Do you have these informations ? Best regards Fred73000 (talk) 22:15, 7 February 2022 (UTC)

aerial imagery

What is the source of aerial imagery for https://wiki.openstreetmap.org/wiki/File:Lower-table-rock-outline-aerial-imagery.png and https://wiki.openstreetmap.org/wiki/File:Hookton_Slough_in_iD_editor.png ? Can you describe it at their file pages? (it is necessary to mark proper licensing info for this files) Mateusz Konieczny (talk) 13:25, 28 March 2022 (UTC)

It looks like a screenshot from JOSM using one of the available imagery layers, but unfortunately I did not record which one was used at the time. --Jeisenbe (talk) 20:01, 17 April 2022 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the creator of image File:Salt Marsh tidal channels.jpg ?

Or is it copied from some other place (which one?)?

Please, add this info to the file page - something like "I took this photo" or "downloaded from -website link-" or "I took this screeshot of program XYZ" or "this is map generated from OpenStreetMap data and SRTM data" or "map generated from OSM data and only OSM data" or "This is my work based on file -link-to-page-with-that-file-and-its-licensing-info-" or "used file downloaded from internet to create it, no idea which one".

Doing this would be already very useful.

Licensing - photos

In case that you are the author of the image: Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

In case where it is a photo you have taken then you can make it available under a specific free license (except some cases, like photos of modern sculptures in coutries without freedom of panorama or taking photo of copyrighted artwork).

Would you be OK with CC0 (it allows use without attribution or any other requirement)?

Or do you prefer to require attribution and some other things using CC-BY-SA-4.0?

If you are the author: Please add {{CC0-self}} to the file page to publish the image under CC0 license.

You can also use {{CC-BY-SA-4.0-self|Jeisenbe}} to publish under CC-BY-SA-4.0 license.

Once you add missing data - please remove {{Unknown|subcategory=uploader notified 2022, June}} from the file page.

Licensing - other images

If it is not a photo situation gets a bit more complicated.

See Drafts/Media file license chart that may help.

note: if you took screenshot of program made by someone else, screenshot of OSM editor with aerial imagery: then licensing of that elements also matter and you are not a sole author.

note: If you downloaded image made by someone else then you are NOT the author.

Note that in cases where photo is a screenshot of some software interface: usually it is needed to handle also copyright of software itself.

Note that in cases where aerial imagery is present: also licensing of an aerial imagery matter.

Help

Feel free to ask for help if you need it - you can do it for example by asking on Talk:Wiki: new topic.

Please ask there if you are not sure what is the proper next step. Especially when you are uploading files that are not your own work or are derivative work (screenshots, composition of images, using aerial imagery etc).

If you are interested in wider discussion about handling licencing at OSM Wiki, see this thread.

(sorry if I missed something that already states license and source: I am looking through over 20 000 files and fixing obvious cases on my own, in other I ask people who upladed files, but it is possible that I missed something - in such case also please answer)

--Mateusz Konieczny (talk) 18:49, 14 June 2022 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the creator of image File:Mangrove-species.jpg ?

Or is it copied from some other place (which one?)?

Please, add this info to the file page - something like "I took this photo" or "downloaded from -website link-" or "I took this screeshot of program XYZ" or "this is map generated from OpenStreetMap data and SRTM data" or "map generated from OSM data and only OSM data" or "This is my work based on file -link-to-page-with-that-file-and-its-licensing-info-" or "used file downloaded from internet to create it, no idea which one".

Doing this would be already very useful.

Licensing - photos

In case that you are the author of the image: Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

In case where it is a photo you have taken then you can make it available under a specific free license (except some cases, like photos of modern sculptures in coutries without freedom of panorama or taking photo of copyrighted artwork).

Would you be OK with CC0 (it allows use without attribution or any other requirement)?

Or do you prefer to require attribution and some other things using CC-BY-SA-4.0?

If you are the author: Please add {{CC0-self}} to the file page to publish the image under CC0 license.

You can also use {{CC-BY-SA-4.0-self|Jeisenbe}} to publish under CC-BY-SA-4.0 license.

Once you add missing data - please remove {{Unknown|subcategory=uploader notified 2022, August}} from the file page.

Licensing - other images

If it is not a photo situation gets a bit more complicated.

See Drafts/Media file license chart that may help.

note: if you took screenshot of program made by someone else, screenshot of OSM editor with aerial imagery: then licensing of that elements also matter and you are not a sole author.

note: If you downloaded image made by someone else then you are NOT the author.

Note that in cases where photo is a screenshot of some software interface: usually it is needed to handle also copyright of software itself.

Note that in cases where aerial imagery is present: also licensing of an aerial imagery matter.

Help

Feel free to ask for help if you need it - you can do it for example by asking on Talk:Wiki: new topic.

Please ask there if you are not sure what is the proper next step. Especially when you are uploading files that are not your own work or are derivative work (screenshots, composition of images, using aerial imagery etc).

If you are interested in wider discussion about handling licencing at OSM Wiki, see this thread.

(sorry if I missed something that already states license and source: I am looking through over 20 000 files and fixing obvious cases on my own, in other I ask people who upladed files, but it is possible that I missed something - in such case also please answer)

--Mateusz Konieczny (talk) 10:41, 9 August 2022 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the creator of image File:Pangkalan ojek Sinakma.jpg ?

Or is it copied from some other place (which one?)?

Please, add this info to the file page - something like "I took this photo" or "downloaded from -website link-" or "I took this screeshot of program XYZ" or "this is map generated from OpenStreetMap data and SRTM data" or "map generated from OSM data and only OSM data" or "This is my work based on file -link-to-page-with-that-file-and-its-licensing-info-" or "used file downloaded from internet to create it, no idea which one".

Doing this would be already very useful.

Licensing - photos

In case that you are the author of the image: Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

In case where it is a photo you have taken then you can make it available under a specific free license (except some cases, like photos of modern sculptures in coutries without freedom of panorama or taking photo of copyrighted artwork).

Would you be OK with CC0 (it allows use without attribution or any other requirement)?

Or do you prefer to require attribution and some other things using CC-BY-SA-4.0?

If you are the author: Please add {{CC0-self}} to the file page to publish the image under CC0 license.

You can also use {{CC-BY-SA-4.0-self|Jeisenbe}} to publish under CC-BY-SA-4.0 license.

Once you add missing data - please remove {{Unknown|subcategory=uploader notified 2022, August}} from the file page.

Licensing - other images

If it is not a photo situation gets a bit more complicated.

See Drafts/Media file license chart that may help.

note: if you took screenshot of program made by someone else, screenshot of OSM editor with aerial imagery: then licensing of that elements also matter and you are not a sole author.

note: If you downloaded image made by someone else then you are NOT the author.

Note that in cases where photo is a screenshot of some software interface: usually it is needed to handle also copyright of software itself.

Note that in cases where aerial imagery is present: also licensing of an aerial imagery matter.

Help

Feel free to ask for help if you need it - you can do it for example by asking on Talk:Wiki: new topic.

Please ask there if you are not sure what is the proper next step. Especially when you are uploading files that are not your own work or are derivative work (screenshots, composition of images, using aerial imagery etc).

If you are interested in wider discussion about handling licencing at OSM Wiki, see this thread.

(sorry if I missed something that already states license and source: I am looking through over 20 000 files and fixing obvious cases on my own, in other I ask people who upladed files, but it is possible that I missed something - in such case also please answer)

--Mateusz Konieczny (talk) 14:51, 31 August 2022 (UTC)

office=healthcare

I suspect that https://wiki.openstreetmap.org/w/index.php?title=Tag:office%3Dhealthcare&diff=prev&oldid=2062630 was at least partially responsible for the cockup that resulted at https://community.openstreetmap.org/t/deprecated-features-reason/99048 .

What was the reason for your change? Was there some discussion somewhere that led to a group of people thinking that this tag was somehow "discouraged"? Where was that and who were they, or was it just a genuine accident? SomeoneElse (talk) 13:53, 13 May 2023 (UTC)

man_made=clearcut in landuse=forest

Hi, I'm mapping in Germany. If I see it correctly, you recommend in the man_made=clearcut entry to cut the clearcut out from the surrounding forest by means of an MP relation. A few sample queries in my area show that this advice is mostly (~70%) disregarded here, and I personally would not agree with it either. My main reason is that from a semantic point of view, the clearcut area is still part of the forestry acitivities going on (unlike, for instance, a meadow or small settlement in the forest). Am I overlooking any reasons that speak for cutting it out? Or would you agree to start a community discussion on this (I already left a comment on the wiki talk page, but that will presumably not be read by anybody anyway...). Best regards! --Alfons234 (talk) 05:46, 2 June 2023 (UTC)

@Alfons234: please read Forest page - "clearcut area is still part of the forestry acitivities going on" does not work if landuse=forest is used for tree-covered areas Mateusz Konieczny (talk) 08:23, 7 June 2023 (UTC)