User talk:Jeisenbe

From OpenStreetMap Wiki
Jump to navigation Jump to search

Via ferrata

Hi, the overpass link you have added to the page doesn't seem to work for me. Also, while it is of some interest that many features are mapped as highway=path + via_ferrata_scale=* the number should not be used as guidance for mappers. I think the results of the recent discussion in the mailing list (search for tagging "RFC rewritten proposal Via_ferrata_simplified") were clear and you are invited to reopen the discussion there. RicoZ (talk) 19:20, 26 April 2019 (UTC)

I've moved this discussion to Talk page of highway=via_ferrata--Jeisenbe (talk) 02:31, 27 April 2019 (UTC)

You abstained from voting on "changing table" proposal


you abstained from voting for/against

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)


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: --Jeisenbe (talk) 11:55, 3 July 2019 (UTC)

natural tree stump

Hi Joseph, I have seen you depromoted natural=tree_stump, and I agree usage numbers are not through the roof (yet), but it is in significant use and no alternative tag is competing with it. It has gained nearly 500 uses in 1.5 years and is constantly growing. For me, as there are no alternative ways to tag tree stumps, this is the defacto tag. —Dieterdreist (talk) 13:13, 7 July 2019 (UTC)

Response at Talk:Tag:natural=tree_stump--Jeisenbe (talk) 13:22, 7 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)


I just noticed you promoted highway=bus_stop (currently 2 409 422 instances) from in use to defacto. The reason for in-use was maybe that the tag is disputed (by some), because there is also an alternative tagging method with public_transport=platform and bus=yes (currently 844 200 instances). Not sure which is better in this case (personally I clearly support the de-facto status).--Dieterdreist (talk) 10:30, 29 July 2019 (UTC)

I've copied this to Talk:Tag:highway=bus_stop - please just mention my username at the relevant talk page in the future, and I'll respond there) --Jeisenbe (talk) 13:12, 29 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... ->

--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)


I saw a few of your edits and I wonder why you did them. Eg. removing military=obstacle_course from the list. I was not able to find any discussion about the removal. The tag is literally used worldwide and there are tags that are used much less than this one. sport=obstacle_course was created at the same time but is even used less. Please help me to understand your edits. At this point I could only describe them as questionable at best. --TBKMrt (talk) 14:50, 27 July 2019 (UTC)

Please discuss at Talk:Tag:military=obstacle_course --Jeisenbe (talk) 05:53, 28 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)

Moving Key:walk-in to "Proposed features"

Hi, thanks for your work organizing the wiki. Regarding : 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 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 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 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 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)