User talk:Chrabros

From OpenStreetMap Wiki
Jump to: navigation, 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)


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


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)


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)


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


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


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)


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




And the original size should now be displayed:

so far




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?


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