User talk:Chrabroš

From OpenStreetMap Wiki
(Redirected from User talk:Chrabros)
Jump to navigation Jump to search

multipolygon is a relation

I think you make a huge mistake by disabling relations in many tags. Relation multipolygon is obviously a relation. The icon "area" means a "closed way", in opposition to the simple, unclosed, linear way (like a highway) symbolized by the icon "way". That's all. --Pieren (talk) 13:58, 6 February 2014 (UTC)

Geeee, I am really confused now. :-0 I have added onRelation=yes yesterday on some building= tags, which I have edited. Not really important ones, there was no content at all ususaly. But I have changed it on the main building=* page, and I have got reverted by Tordanik (Undo revision 987059: building is an area tag). So I have read the discussion on this page and some users stated that the relation multipolygon should be considered as Area and not Relation in this context which seems to make sense. So I have reverted the other changes. And now you tell me that it was wrong. :-(
I was not able to find an exact definition of what onRelation really means. They have reverted my change of onNode=yes for building, which I think is perfectly OK. Do you know where I can find the proper way how to determine how to set these?
What tags should have onRelation=yes (excluding multipolygon)? I do not know now.
And BTW I think that you are wrong about "closed way" and "area". They are not the same thing. I was translating the Area page lately, so I rememeber, and the difference is quite clear. Though they are technically the same, from renderer's point of view "closed way" is just a way, but "area" is the way PLUS the filling inside. So the icon IMO means "on closed way" or "on area" depending of the context of the tag.

Chrabros (talk) 14:12, 6 February 2014 (UTC)

I understand your confusion but these two guys are wrong. Have a look here : Elements#Area_.28closed_way_.29. The multipolygon is in "relation" section. Also the taginfo statistics are showing numbers for nodes, ways and relations. The multipolygons are counted in the relations element types. Again, these guys are wrong. --Pieren (talk) 14:51, 6 February 2014 (UTC)
OK, both ways of thinking about it have its merits. But it seemes to me logical (as it did before) that multipolygon relation is mainly relation. Also just under need is Taginfo count which clearly indicates number of relations (including multipolygon), so it would be stupid to say onRelation=no. Another reason is that when user searches some feature in OSM, this should give him a hint, which elements he should searche to find all objects. Last but not least Pieren seems to have higher "rank" than Tordanik and he is able to explain his opinions, instead of just reverting. ;-) Conclusion: reverted my reverts ;-), returned onRelation=yes, learned my lesson.

The same is true for Pieren, by the way. Dropping a single link and vanishing is not a proper discussion.

Sorry for over-zealously reverting your edit. It's just that this topic was already on Key:building's talk page, and you changed the page without taking that into account and without giving a edit comment explaining why. So at that moment it felt to me as if you were wilfully ignoring previous discussion and just trying to push your opinion, which made me annoyed about your edit. In fact, I guess now that you felt the same way about my revert, for similar reasons.
I've now also explained my opinion in more detail on Talk:Key:building, so perhaps you are still willing to give my way of thinking a second chance and consider a revert of the revert of the revert. ;-) --Tordanik 16:50, 7 February 2014 (UTC)
Hi Tordanik, thank you for your reaction. Actually I was not reading the Talk page before I did the change. I was translating pages into Czech and this has become kind of routine for me - the onRelation value is usually left unfilled, so when I see that this value is used and it makes sense (usually on multipolygons) then I just add it.
With the onNode=yes I was too fast. I understand now, that the intention for onNode=no might be to persuade the users to do the extra work and map the building as area. I should have read the Talk page before. Though it might me nice to write on the building page, that area is preferred for the building and that node is just for "cannot do it better" case. Just a thought. Chrabros (talk) 06:12, 9 February 2014 (UTC)
I think adding something to that extent to the Building page would be appropriate. Perhaps also drop a line in there that most applications only benefit from building areas.
But regarding the multipolygon dispute, I'm disappointed that you did an "after discussion" edit without even reacting to my arguments at Talk:Key:building#onRelation.3F. --Tordanik 15:24, 10 February 2014 (UTC)
Gee, sorry, I have not noticed that you wrote on the Talk:Key:building#onRelation.3F page. It seems that RSS does notify only about changes in main pages, not talk pages. It was not meant to be offensive. I tought that the debate about onRelation was over, and that onNode is remaining open question. I'll respond there. Chrabros (talk) 06:59, 11 February 2014 (UTC)

levels of buildings

I would suggest to not suggest the 3D-tags like building:levels. I guess this is not accepted by the community. And IMHO this is not useful on the buidling-way, because mappers will mess up the building:levels with the total number of levels of a house. I would like to introduce a new tag which gives the number of levels of a building in total. 10. 2. 2014, 02:18 ‎Cracklinrain (talk)

Well, first of all please learn how to sign your comments on this wiki, so I do not have to do it for you.
Second, I am little bit surprised that you say that the building:levels=* is not accepted by the community. There are cca 2,500,000 uses of this tag! So it seems that it is widely accepted. Maybe you meant that it was not proposed and approved in official process. Could be. But the tag is documented and used. So if you plan to propose a new tagging schema, then fine, but rather include this tag as well as it is, otherwise the confusion will be even greater. :-) Chrabros (talk) 04:34, 10 February 2014 (UTC)
This is not about new tagging schemas. building:levels=* is used for 3D rendering. In the context of the building page without mentioning roof:levels=* etc. the mentioning gets misleading. To add the Tag might be OK in regard to the usage statistics, but not without mentioning the related tags of that concept. So we might keep building:levels=*, but than we will have to add roof:levels=* to the suggested tags at least. But IMHO the mentioning of the building:levels=*-Tag is not useful at all. --Cracklinrain (talk) 20:15, 10 February 2014 (UTC)
Well, you might be right that this tag might be used incorrectly. But this is true for many tags, if not all of them. But in case of building:levels=* is the risk IMO very low as the page about it is very nice, it even has an explanatory picture, which is rare, so I think that the risk is very low here. So it seems weird to me that we would try to hide information about this tag from the users, esp. when this tag is relatively widely used. Chrabros (talk) 06:52, 11 February 2014 (UTC)

not rendered my mapnik

Please, do not specify in the map features tables if mapnik is rendering or not the feature. First, this information can quickly change. Second, the description in the table has to be as short as possible. We already have to many verbose descriptions there. Third, mapnik is one renderer among others and there is no reason to talk about mapnik and one style and not about the others (cyclemap, topomap, etc). You can talk about mapnik support in the detailed page about the tag. --Pieren (talk) 13:27, 12 February 2014 (UTC)

Come on, Pieren! This time it was not me who did it. The mapnik note was not added by me. You have reverted a wrong edit.
I have removed the =References= section as it breaks up the structure of MapFeatures pages. Find another guilty guy. ;-) Chrabros (talk) 16:12, 12 February 2014 (UTC)
Sorry. This is because of this f***** mediawiki reporting all changes from all contributors in the same page. I forwarded the message to the right contrib. now.--Pieren (talk) 17:28, 12 February 2014 (UTC)

Translation

I have no idea. You should contact one of the admins or submit a ticket. --Pieren (talk) 09:43, 17 February 2014 (UTC)

Thanks, I'll try. Chrabros (talk) 09:58, 17 February 2014 (UTC)

Key:addr translation

It seems you have accidentally overwritten the English version of Key:addr with the Czech content: [1]. Was that your intention? --Tordanik 21:39, 23 February 2014 (UTC)

Well, I think that Czech is a beautiful language and everyone should try to learn a little bit of it. ;-) But in this case I was called off to have a dinner and I have pasted into a wrong window. :-( Thanks for pointing it out Tordanik.
Chrabros (talk) 01:44, 24 February 2014 (UTC)

organization or organisation

Please note that the wiki, like the tags, is normally expressed in uk English, not US English for historical reasons. Thus this change http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:office&curid=57498&diff=999412&oldid=997522 is not required. --Pieren (talk) 13:10, 10 March 2014 (UTC)

OK, sorry. I have edited it to back organisation. Chrabros (talk) 13:41, 10 March 2014 (UTC)

buildingːpart=yes

I don't understand why you prefer adding "=yes" to "building:part" here[[2]]. It seems unnecessary to me. --Jgpacker (talk) 18:06, 19 March 2014 (UTC)

Maybe it is unnecessary maybe it is not. But the bottom of the page clearly states its meaning. I am not defending the logic of this tag. What I am defending is a integrity of the description of the page which you have broken. part is yes and parts is number. Read the bottom of the page. Your edit resulted in a difference between top and bottom of the page. Chrabros (talk) 19:04, 19 March 2014 (UTC)
Yeah, it's true. I missed the other "=yes"..
I removed the "=yes" part because there are other possible values for building:part [[3]]. But it seems they aren't approoved values, so I guess it's okay to leave the "=yes" as it is in the page content, but it should be removed from the "Useful combination" list --Jgpacker (talk) 19:41, 19 March 2014 (UTC)
And why it should be removed when it is recommended by the page and 95% of values is yes? I would rather leave it there. Chrabros (talk) 19:50, 19 March 2014 (UTC)
Because there are other possible values when making a combination with building:levels. You say 95% of the values are "yes", but that's out of 83 292 (currently), meaning there are 4,160 instances of this tag with other values, which is not insignificant. --Jgpacker (talk) 20:07, 19 March 2014 (UTC)
Update: Simple_3D_Buildings#Building_parts mentions there are other possible values for building:part=*: "If some parts of the building=* have different attributes (e.g., height), they can be modelled as additional areas, tagged with building:part=yes or building:part=type of building:part." --Jgpacker (talk) 01:04, 20 March 2014 (UTC)
OK, maybe I am wrong here. I thought that this sentence
For describing number of levels at parts of building we use building:parts=* at polygon of building and building:part=yes and building:levels=* at polygons of parts of buildings.
means that the number of levels of building part goes to building:parts=* as a number. But there is obviously another page building:parts=* describing building:parts=* as "horizontal/vertical/mixed". So probably misread this sentence. What do you think?
Anyway: what about adding this to the Useful combinations: building:part=yes and building:parts=horizontal/vertical/mixed
and this to the text building:part=yes or any other value suitable for building=*?
Chrabros (talk) 03:18, 20 March 2014 (UTC)
Update: Funny. When I was translating this page to Czech I was reading the sentence the other way, so that horizontal/vertical/... is the content of parts tag. ;-) Chrabros (talk) 03:30, 20 March 2014 (UTC)
Well, the funny thing is that the possible types of building:part aren't specified in it's page. It indeed gives the impression that it could be one type of the building=* tag, however it doesn't confirm that(on taginfo, there are such values as "base" and "column"). I'm not sure how much information is necessary in the wiki page and how much is supposed to be only linked, but I think the useful combination part could be only links. --Jgpacker (talk) 20:36, 22 March 2014 (UTC)
Well, since Tordanik have removed building:parts from that page completely I think the source of confusion is gone I do not care so much now. =* or =yes seems not important now. Chrabros (talk) 03:18, 23 March 2014 (UTC)

reorganisation of this wiki's navigation

Hello, I write to you because you are part of the Wiki Team. I would like to establish a navigation concept for this wiki, lead by use cases. I wrote an example main page and an example navigation page (for the use case 'contribute map data'). In January, I wrote a correspendent proposal on Talk:Wiki_organisation, with some but not much feedback. I would be happy if you could add your feedback in order to decide either to refuse the proposal or to proceed. In the latter case I will incorporate all feedback, write the two missing navigation pages ('about' and 'use') and finally I would like to change the main page. Best wishes, --Cantho (talk) 07:18, 8 April 2014 (UTC)

Now I proposed to apply the proposed changes to the main page. Your feedback/ vote is welcome. If you want to respond but don't have the time right now, please give a notice about when you think you can respond. Have a nice day --Cantho (talk) 10:10, 23 May 2014 (UTC)

Your reversion of Cs:Tag:historic=cannon

Could you spell out your objections to Moresby’s version more clearly if you’re making a change like that?--Andrew (talk) 06:13, 17 April 2014 (UTC)

I believe that I already did so User_talk:Moresby#New_proposed_KeyDescription_Template. Chrabros (talk) 06:27, 17 April 2014 (UTC)

Překlad

Díky za další překlady stránek do češtiny! Je to opravdu hodně užitečné a to nejen pro nováčky, na mailinglist chodí jen málo lidí (a ještě méně lidí je ochotno prohrabovat se jeho historií). Kdysi jsem se pustil do překladu FAQ (ale skončil jsem v podstatě akorát u nadpisů), je to tady k volnému využití. --Jkjk (talk) 11:26, 19 April 2014 (UTC)

Díky za tip, pomalu na tom dělám, ale je to teda nášup. Budu rád, když mi tu stránku Cs:FAQ případně zkontroluješ a opravíš.
Chrabros (talk) 13:09, 10 June 2014 (UTC)

agricultural

Hi Chrabros, could you please have a look at the page (created by you) Key:agricultural. The text seems to be contradictory now (after someone else's edit). Someone mentioned this on DE talk:Key:agricultural. Thanks. I do not want to dive deeply into this topic now. --Aseerel4c26 (talk) 19:59, 16 January 2015 (UTC)

Hi, I do not see the contradiction. It seems it is in sync with the original proposal, which I have linked to the page. Chrabros (talk) 15:44, 18 January 2015 (UTC)
Thanks. Hmm, "Legal access restriction for agricultural motor vehicles" (so the key is about a vehicle type) vs. "which can but not necessarily is performed using agricultural vehicles" (so the key is about a traffic type/purpose). --Aseerel4c26 (talk) 17:41, 18 January 2015 (UTC)
Well, key agricultural=yes/no/* is about vehicle type and access=agricultural is about traffic purpose. That is how I understand the proposal. Chrabros (talk) 18:54, 18 January 2015 (UTC)
I have tried to make the difference more visible on the page. Would you try to explain it on German talk page? My written German is not that good. Chrabros (talk) 19:11, 18 January 2015 (UTC)
Thank you, I have tried to translate. Please check it. :-) --Aseerel4c26 (talk) 22:47, 18 January 2015 (UTC)

Problem with status link

Actually accepted tags within one proposal doesn't mean that their previous usages are accepted. Well this is because our documentation and tools are tag centric rather proposal and tag centric.

Right now we can only mention that 4 tags are accepted as part of proposal X.

Here is similar situation with residential=*. See Prevalent usage section. Xxzme (talk) 17:53, 26 January 2015 (UTC)

OK, I see the problem. Do you have any suggestion? Chrabros (talk) 09:06, 27 January 2015 (UTC)

About your edit of Tag:waterway=water_point page

Hi, you have added the sentence below in waterway=water_point itself: 

* waterway=water_point Same feature for boat holding tanks.

Perhaps you meant another tag, but which tag would you describe about? --Mfuji (talk) 09:23, 9 January 2016 (UTC)

Hi, it was not me. I have just corrected a typo "watger"->"water".
The sentence was added by User:Brycenesbitt.
I have asked him already what he meant by this change - see User_talk:Brycenesbitt#water_point.3F
Chrabros (talk) 08:31, 11 January 2016 (UTC)
Oh, sorry! and thanks for asking him! --Mfuji (talk) 08:35, 11 January 2016 (UTC)
waterway=water_point is the same as ammenity=water_point, except for boats. So ammenity on land, waterway when accessible to boats. Or use both ammenity and waterway tags for the rare station that serves both users. Brycenesbitt (talk) 18:09, 14 March 2016 (UTC)

"ruined:" or "ruined"?

[4] - it was not an accident that it was "ruined:". The motivation was that wiki-search would not find the prefix version so I tried it this way.. just one of many tries- It may warrant a fresh look but have a look at the previous discussion which was here: http://wiki.openstreetmap.org/wiki/Talk:Lifecycle_prefix#Testing_possibilities_to_rename_prefix_keys RicoZ (talk) 22:42, 15 March 2016 (UTC)

Hello, well, if you want this key to be named ruined:=* then I suppose the page should be moved to "Key:ruined:" as well. Otherwise the language bar does not work.
I wonder why this paged is named without ":" when the other related Lifecycle pages are named abandoned:=*, demolished:=*, removed:=*, ... Wouldn't be better to name it ruined:=* instead of ruined=* as well? Chrabros (talk) 07:13, 16 March 2016 (UTC)
I think it should be "ruined:" and moved to "Key:ruined:". We have tried several alternatives to see how search engines would find those prefixes and may have forgotten to rename some. What would be also very helpful is a template for namespace prefixes/postfixes. I have started something http://wiki.openstreetmap.org/wiki/User:RicoZ#Template_hacks but got distracted before finishing. RicoZ (talk) 22:37, 16 March 2016 (UTC)
So, I have moved the page ruined=* to ruined:=* Chrabros (talk) 11:47, 23 March 2016 (UTC)

Template:Discouraged

Just a heads up that I have some questions on Template_Talk:Discouraged--Jojo4u (talk) 23:03, 30 May 2016 (UTC)

Elbe-Labe-Meeting

Have you seen Elbe-Labe-Meeting? Would be nice to meet in person to talk about the Taginfo/Taglists feature. Joto (talk) 09:36, 5 September 2016 (UTC)

Interesting idea. I will discuss it with my girlfriend to find out if I want to participate. ;-) Chrabros (talk) 10:16, 5 September 2016 (UTC)

lunch

Hello. I have extended the lunch draft and I am interested in your opinion and welcome your additions based on your experience. Cheers, Bkil (talk) 14:33, 19 November 2016 (UTC)

Oh sorry, I forgot the link: https://wiki.openstreetmap.org/wiki/Key:lunch Bkil (talk) 09:50, 20 November 2016 (UTC)

Iconsize 14px

Hello, in the openstreetmap-carto the icons have been changed from the size 16 in 14. See issues/2430, pull/2451

so far 

<rect 
   width="16" 
   height="16"

now 

<rect
   width="14"
   height="14"

And the original size should now be displayed:

so far 

<svg
  width="100%" 
  height="100%"

now 

<svg
   width="14"
   height="14"

This change is also interesting for TagList, because otherwise the icons are displayed too large. In this way I have, for example Bank-16.svg, changed.

On the website symbols the symbols have got new names without the addition of the size (bank-16.svg >> bank.svg).

Do you have an opinion whether and how we should do this in the Wiki?

Greetings

Not sure if I understand the question. Do you mean if we should use icons with renamed names? Or if we should use smaller icons in wiki?
Regarding the size I think that we display the icons too small at wiki at this moment. I think that they should be displayed much larger
to see them conveniently and disregard the size used for rendering the map.
Chrabros (talk) 10:52, 29 November 2016 (UTC)
If you try 
{{Taglist|tags=shop|with_rendering=true}}
you will get big icons and small.
This can be changed by exchanging width="100%" to width="14" ... in the svg-file.
You are right the size of icons that we display is too small at wiki. On Key:shop the double size was chosen. Because in the future all icons have max 14 px we could use 28 px. I would like that.
OK, I see it. It is not nice. I suppose that Taglist does not use the size parameter from wiki. But I think that this could be fixed in Taglist code, no?
Chrabros (talk) 12:16, 29 November 2016 (UTC)
There are icons in different sizes. E.g. Volcano-8.svg, Entrance.10.svg but most are 14px or 16 px. So there will be no uniform presetting. But we can change it in the svg-file e.g. File:Bank-16.svg
What do you think of this: DE:Tag:shop=clothes
I think this is a nice size of an icon.
Chrabros (talk) 14:09, 29 November 2016 (UTC)
Well, let's change that. Hopefully, everyone will like it.
Well, it seems that Verdy p reverts the changes of those icons back to the original size claiming that they are used in Taglists. Chrabros (talk) 08:22, 1 December 2016 (UTC)
In taglist they are shown in original size. This is in the svg file. Is there a discussion on this subject with a majority opinion? --geozeisig (talk) 06:21, 3 December 2016 (UTC)

osmcarto-rendering for areas

Have you seen that osmcarto-rendering for areas can be added? E.g. Tag:natural=wood It is also used for taglist. The question is only in what size?

Many images are in the format 125x125 px. In the example it is reduced to 100x100. Of course you could also upload a picture with 100x100 to display it with 1:1.

By the way, I am not convinced that all existing Templates should be replaced by Taglist. --geozeisig (talk) 06:41, 3 December 2016 (UTC)

lanes on small roads

Hallo Dalibor,

du hast meine Änderungen der Wikiseite zu lanes rückgängig gemacht (Key:lanes en und Key lanes cz). Ich hatte als Quelle auf die Diskussion im Wiki verwiesen. Du sagtest "I think you are changing the old definiton with very little discussion".

Da hast du Recht. Ich habe vergessen, der Diskussion auf der Wikiseite den Link zur Diskussion im Forum hinzufügen. Das habe ich jetzt getan (mit meinem schlechtem Englisch). Ich möchte aber nicht einfach den Revert wieder wegnehmen, das empfinde ich als schlechten Stil.

Was denkst du?

Grüße, Jochen

--Jo (talk) 23:32, 10 February 2017 (UTC)

Hi, I have no problem with changing the tag meaning to marked lanes only. But then in the example of a road with no markings it should be clearly stated that there should be no lanes tag and definitely not lanes=1 which is misleading.
Chrabros (talk) 08:48, 13 February 2017 (UTC)

airmark=beacon and aeroway=navigationaid

Everything in the aviation has to do with radiofrequency is nevertheless with airmark=beacon tagged. So I cleaned up the overlaps at aeroway=navigationaid. So the system Approach lighting system (als) and Precision approach path indicator (papi) still remains. That are light marking systems which were tagged as well in the past. The systems ils vor dvor etc. must of course be corrected. I have already begun.

A correction is better than 2 parallel tagging schema.

Best regards Dieter

But it seems that aeroway=navigationaid is used more than airmark=beacon. Also I like "aeroway" as key more than "airmark", which is strange word.
Anyway I believe that we cannot change the way the features are tagged by simply changing wiki. We could only suggest that one way is preffered.
And in any case we should not delete the documentation while such elements are in database. It is necessary to keep it for reference even if the tagging schema would be declared obsolete.
My proposal would be to choose one tagging schema and clearly state on wiki that this schema is preffered.
Chrabros (talk) 09:02, 17 February 2017 (UTC)
The statistics are now somewhat clearer. airmark=beacon stands for the radio frequencies while aeroway=navigationaid stands for the light. Unfortunately, taginfo does not show statistics (why?) but taginfo|navigationaid does (The rest I will also look at). You can change the wiki pages (E.g. Key:navigationaid) so that it becomes clear (my english is not as good as yours). It would be good to point to the old stand. Then I would also write a ticket to JOSM, so they expect the same.--geozeisig (talk) 07:00, 23 February 2017 (UTC)
Hmm, but I am not sure that I like the idea that we split those devices by their design into completely different keys. Why shoudl we? Chrabros (talk) 08:30, 25 February 2017 (UTC)
The topic has now also been implemented in JOSM. See Ticket#14417. So it has also a conclusion for me.--geozeisig (talk) 06:04, 23 June 2017 (UTC)
That is nice. Thanks for info. Chrabroš (talk) 09:34, 23 June 2017 (UTC)

Tag:pipeline=substation

Hi! Why onRelation=no? Pipeline substations may be big buildings or territories.--Literan (talk) 09:43, 24 February 2017 (UTC)

Hello. If you mean that they could be mapped with multipolyon relation, then yes, it is right. But on this wiki we do not consider multipolyon as relation in context of onRelation=yes, these are simply areas (onArea=yes).
onRelation=yes is reserved for cases where the tag has some meaning on any relation except multipolygon. Otherwise it would just have the same meaning as onArea=yes and will hold no useful info.
Chrabros (talk) 09:52, 24 February 2017 (UTC)
OK, understand. --Literan (talk) 10:40, 24 February 2017 (UTC)

Translation out of sync template

Hi Chrabros, I have ust noticed you added the translation out of sync template to an English tag definition page, indicating that the tag definition page was a translation from a foreign (=not-English) page. From my understanding of how the OSM comunity develops tags, this cannot happen. Tags have to be proposed and defined in English, all other language versions for these tag pages should be translations from English, not the other way round. It can happen that tags get developped locally first, but from the point on that the tag definition gets amended, this should happen first on the English "main" tag page (after discussion on the tagging mailing list) and then get translated. The page in question is this one: Tag:emergency=access_point but this really applies in general to all tag definition pages. --Dieterdreist (talk) 16:32, 28 February 2017 (UTC)

Yes, I did it. Aparently there is a lot more information on German page. I aggree that theoreticaly the tag should be documented in English first. But it is often not the case. See Category:Translate from German.
Also the information on German version of that page is quite confusing. Maybe you could tidy it up and adjust the English page accordingly. My German is not so good so I can do it with ease.
Chrabros (talk) 07:25, 1 March 2017 (UTC)

I suggest removing the template from the English version page and add the "out of sync" to the German translation of this feature definition page (in fact, have done it now). I don't want to amend the English page from the German page without discussing it on the tagging ML before. --Dieterdreist (talk) 16:26, 1 March 2017 (UTC)
I have now added and then again removed the template from the German 'translation' as it didn't make sense. I have replaced the infobox in the English version with a hint that there is more information in the German version. Still this tag shouldn't likely have gotten this feature page, it is still a "draft" and there is another tag with more usage. --Dieterdreist (talk) 16:33, 1 March 2017 (UTC)

Well, it is a little bit hidden now. The warning was more prominent before. But OK. Chrabros (talk) 18:34, 1 March 2017 (UTC)
Yes, it is less prominent now, but from what I have seen (at a glimpse) there are not contradictions between these 2 languages, there is just a bit more text in the German version, but there are no fundamental differences, so a bold warning is maybe not required? --19:13, 1 March 2017 (UTC)
But have a look at the German page. There is written in the bottom <tag k="highway" v="emergency_access_point"> so it is quite confusing and it should be fixed. Chrabros (talk) 09:22, 3 March 2017 (UTC)
Yes, I agree this is not consistent. I'll ask on talk-de. --Dieterdreist (talk) 10:15, 3 March 2017 (UTC)

Conditional restriction tags

Regarding these two edits [5] [6]:

As a new editor, I'm bound to make a lot of mistakes, so thank you for trying to correct them!

restriction:conditional=* as a key does appear on 2984 relations. They are used if a restriction, that would be marked using restriction=no_right_turn, only_left_turn, and so on, but has a condition like "Mon-Fri 7am - 5pm": an example is https://www.openstreetmap.org/relation/6895922/history .

Such a relation would be tagged type=restriction; restriction:conditional=no_left_turn @ (Mo-Fr 07:00-09:00). Thus, it's a separate key, and worth listing in the Conditional restrictions infobox.

For people who scan the "Keys" column of Relation:restriction#Tags, they might not see the "The following keys are deprecated" message, and try to enter the information with day_on=* instead. This is why I added a row to the article. --Kakurady (talk) 20:19, 9 March 2017 (UTC)

Hello
as far as I know this way of tagging conditional turn restrictions is not documented on wiki so far. There was a debate how to tag them but no one updated the new style you are mentioning. But from the discussion I am not really sure that this way is the only way which we would like to document here and set it as a standard.
Your edit, IMHO, was trying to establish this standard. But it seems to me that it would need to be confirmed by more people first.
Don't you want to raise this issue on tagging mailing list first? It would be nice to aggree on one standard way of tagging there restrictions and then document it.
But maybe I am wrong and that this debate was held some time ago with clear results and in that case I am sorry.
Chrabros (talk) 02:38, 10 March 2017 (UTC)

Beehive

I do not translate from Polish into English, because my Polish knowledge of this subject is not satisfactory. --Władysław Komorek (talk) 11:44, 21 March 2017 (UTC)

OK. It is a pity. Chrabroš (talk) 03:33, 30 March 2017 (UTC)

Tag template capitalization and other invisible edits

Hi Chrabros,

I've noticed you are performing edits aimed at improving the readability of wiki pages' source code, such as capitalizing tag template inclusions. This change and this one, for example.

Now as far as I know, there is no rule whether we should write {{tag|highway|motorway}} or {{Tag|highway|motorway}}. Personally, I prefer the lowercase variant because the template is often mixed into a paragraph of normal text, and capitalization in an otherwise lowercase body of text detracts from readability a bit.

Of course this is not a very important issue, so if you were just preferring one style in the text you are adding to the wiki yourself, I wouldn't mind. But you're very often applying these changes across an entire article written by authors who chose the lowercase style. And you have probably changed several hundered pages in that manner, which makes it hard for me to ignore. In my opinion, it's not ok to perform such large-scale changes without finding a consensus first. --Tordanik 21:16, 6 April 2017 (UTC)

Hi Tordanik,
I like the template names to be captitalized as you have noticed. This applied not only to {{Tag}} but to others as well.
I do not feel that it impacts readability, quite contrary, but it is a matter of personal taste I guess.
Usually I do not make this change on its own, but I do it while editing something else.
I have noticed that you perform the same thing, in the opposite manner of course from time to time [[7]].
But if you choose to write all template names lowercase, how would you write {{TagValue}} and {{TagKey}}? Uncapitalized versions seems ugly to me.
Also I was conviced to do so while discussing this with someone (I cannot find the converstaion now) and it seems that I am not the only one who likes the capitalization of template names. I can name geozeisig and Lenochod.
Anyway if you think it is important then please raise this issue somewhere to find a consensus and I will adhere to majority's opinion. Chrabroš (talk) 05:19, 7 April 2017 (UTC)

Redirects access=forestry/agricultural

Both access=agricultural and access=forestry value pages redirect to the transport mode keys agricultural=* and forestry=* which I find highly confusing. They should redirect to access=* like the other values.-Jojo4u (talk) 21:09, 14 April 2017 (UTC)

Hi, I thought it adds more information. But you are right that these are different. I have fixed it. Chrabroš (talk) 00:08, 15 April 2017 (UTC)

Wildlife Park

Please kindly check Talk:Tag:zoo=wildlife park#Contradicting Definitions. -- TZorn (talk)

OK, I will. Chrabroš (talk) 13:52, 26 April 2017 (UTC)

Thank you for correcting Tag:shop=beverages

Thank you for correcting my mistake. It was not the first time (sometimes I go too fast). Other times I had always noticed and corrected it. This time I did not realize my mistake. I have recovered the Spanish version and saved it (now yes) in its corresponding place. Thanks again! --Daniel Capilla (talk) 10:15, 26 April 2017 (UTC)

De nada. Chrabroš (talk) 13:52, 26 April 2017 (UTC)

Key:bulk_purchase - is it only large?

moved to Talk:Key:bulk purchase --Aseerel4c26 (talk) 13:30, 11 February 2018 (UTC)

"natural"

Re https://wiki.openstreetmap.org/w/index.php?title=Key%3Anatural&type=revision&diff=1426101&oldid=1001517 I've changed onRelation=no to onRelation=yes. See https://community.openstreetmap.org/t/natural-bay-multipolygon-or-single-dot-dispute/97325/10 . SomeoneElse (talk) 14:41, 26 March 2023 (UTC)

Česko - systém adres

Připsal jsem na stránku ještě něco o tom, že nové lokality už nemusí mít domy očíslovány podle výstavby, a taky něco o tom, jak to mají na Slovensku pro porovnání s Českem. Zatím nevím přesně, jak o tom předpřipravení čísel v nových lokalitách formulovat, ale některé obce už to tak dávno dělají. Když popřemýšlím nad orientační absencí v Čechách a zejména na moravském venkově, tak by se s možná dalo něco dělat, i když se o tom vůbec nehovoří.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User_talk:Chrabroš&oldid=2664074"