Talk:Map Features

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — Map Features
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen Kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk bokmål norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português português do Brasil română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް
Older discussions may be found in the Archive.

errors / ommissions / miscellaneous

A section for other 'issues'

  • amenity=school is displayed in the page as a light-purple area for ways, whereas mapnik renders them as a pale yellow colour


Can we clarify the meaning of the tag landuse=basin? The current definition, "An area of land which drains into a river." seems to be correct from the standpoint of the science of hydrology, but it is not a land use (since it describes a natural feature of the landscape, not how humans are using a particular plot of land).

A comment on the talk page suggests that landuse=basin may indicate a man-made pond with sharp borders, such as a sewage treatment pool. However, that is not a land use either, it is a man-made object.

After reading the description of the new tag, basin=infiltration, I suspect that landuse=basin means that a plot of land has been designated as a place for rainwater to pool and be held back so that it does not enter a river too quickly.

If this is so, then landuse=basin does not indicate that the land in question is always under water or even under water most of the time. Thus, the default rendering should be be solid blue, but rather blue raindrops as with landuse=basin, basin=infiltration.

What are your thoughts? How can these questions be resolved?

-- TomashPilshchik


The definition of this tag reads: "A place where drinking water is found and applied to the local waterpipes network." The is rather vague, especially the part about "a place where drinking water is found", which could mean anything including a lake.

Is it OK to change this to: "A device or building used to collect, purify, and distribute drinking water"?

-- TomashPilshchik

What about sewerage works ?

Pmailkeey (talk) 10:25, 5 December 2014 (UTC)


I think toll=yes is not for a node-element but also for a way-element. --chris66 14:29, 23 December 2009 (UTC)

Tag found that is not member of any list

There is a tag Tag:building=dormitory that is on no list, neither approved, nor rejected without any discussion, what to do with it? TobiBS 22:05, 11 February 2010 (UTC)

What to do? Just use ;)
Actually, the right thing to do would be changing it into a proposal site and moving it to, say, Proposed features/Dormitory building. Right now, it pretends to be an established tag, which it isn't (according to usage by mappers and software, isn't). Not sure whether that's worth the effort, though. --Tordanik 22:00, 25 August 2010 (BST)
It wouldn't. Proposals and voting is needed only when there are several conflicting ways to model the same thing, or if a user wants it included in the Map features before really widespread use. Discuss, enter data, document. Documenting any tags is beneficial; tag equivalences or "community favoured alternatives" can be linked to, if such exist. Specifically in this case Key:building allows for custom values (quote: "Mappers may also define their own values. Renderers are free to support these or just treat them as synonyms for building=yes."). Alv 07:36, 26 August 2010 (BST)
Everything you write about inventing and documenting tags is true, but it would work equally well with a proposal page instead of a Key/Tag page. I personally consider creating a Key/Tag page (instead of a proposal page with the same content) something that should require a certain level of popularity, just as a Map Features entry. Note that I didn't mention voting at all: Writing a proposal page doesn't mean that there needs to be a vote! You can still just wait for the tag to become popular enough, but imo placing it on Proposed features instead of Key/Tag says "this is documentation for a tag that isn't yet widely used". And that's certainly true in this case. --Tordanik 12:32, 26 August 2010 (BST)


This could be useful to map out advertising billboards. I'm not quite sure how it works, but I would also like to tag these with the following data : size, with lights or not, TV billboard, non-commercial, rollover messages, legal or illegal.

Mobile (or Cell) Phone Mast?

What should I label a mobile phone mast as? man_made=tower seems a bit much for something that is often only tens of metres high at most. Perhaps there should be a man_made=mobilephone_mast

If you want to discuss tagging you are better off emailing the tagging mailing list, as for which tags, man_made=tower, tower=communication then you have a whole buch of tags to describe frequencies used and what not. --Delta foxtrot2 06:35, 13 June 2010 (UTC)

Emergency : State Emergency Service

The description to the tag:emergency=ses_station should be changed to "A State Emergency Service is an organisation that provides emergency help during and after declared (natural or otherwise) disasters", instead of "A State Emergency Service is an Australian volunteer organisation that provides emergency help during and after declared (natural or otherwise) disasters." --Federico Explorador 20:29, 30 May 2012 (BST)

Cleanup Request

This central page has a few problems:

  • translated pages get out of sync
  • no policy what kind of features get listed here (well known, proposed, voted,...)
  • table is huge and heavy to load
  • rendering col hides OSM multimap and self rendering approach and is outdated

There is a discussion on Talk:Proposed_features#Features_that_hasn.27t_gone_through_the_proposal_process that hits a few aspects. I'm not gonna edit anything here cause of it's central nature. Any ideas? --!i! This user is member of the wiki team of OSM 18:04, 6 November 2010 (UTC)

Before we see any more cleanup labels come and go on this page: Please discuss your ideas for improvements of this page here. !i! has already made a start by listing the problems he sees with this page; if you have any suggestions for solutions please let us know. As someone who has worked on one of the translated pages I disagree with pages getting out of sync being much of a problem: as most of the translated pages have translated only part of the features anyway, it's not unusual for the users to find a mix of english descriptions and descriptions in their native language here. That situation is still a lot better than only english text or only (sometimes very) incomplete translations. I agrre with missing policy being a problem, but that can not be solved technically, instead discussion and the search for a (rough) consensus is needed. I guess everyone agrees that the page is really heavy weight. And for the last point: I have to admit that I have no idea what that was supposed to mean. --Lyx 21:40, 23 November 2010 (UTC)
May I suggest, as a starter, to break the page into subpages, leaving only the introductory material in the current page? I.e. we could have a Map_Features/Physical, Map_Features/Non Physical and so on. Furthermore we might want to break down the physical category into two pages, one for linear features such as roads and railways and one for area or node-based features, such as buildings or parks. I'd be happy to do it if you guys think it'sa good idea... -- Manu3d 01:09, 12 January 2011 (UTC)
Splitting the page has been mentioned in the (distant) past, but there's a reason why it has been kept as one page: in-browser searching. Sure, there's the wiki search, but finding the relevant pages can be hard especially when one doesn't know the correct key or value beforehand, or isn't that fluent in English. Personally, I'm unsure whether it would be better or worse if split; it's still getting huge. Alv 11:13, 12 January 2011 (UTC)
I understand what you mean: in Firefox you just have to press CTRL+F and then type whatever you are looking for to get to the first instance of it in the page. Might I then adjust my proposal to meet your concern: in the main page we keep the introductory text as already mentioned but we also add a much more compact, text-only table acting as an index, each column listing the features (i.e. "highway/motorway" and "amenity/fuel") and each column header (maybe repeated every X number of items) being a link to pages such as Map_Features/Physical. This way one can still search the whole list but the page would become much lighter. And potentially each listed feature too might be a link to a specific Tag:* page. -- Manu3d 22:25, 12 January 2011 (UTC)
"Rendering" needs to broken apart into some of the popular applications, ie Mapnik, Osmarender, etc. There should be aphoto for each of them. Not just one random photo. Not all features render on different applications. Being able to see the icon at a glance for maybe the top 10 would be helpful to compare how they render and where. Also a zoom level for each one should be included. These should be able to be filtered so you can easily see what shows where and at what level. Maybe the rendering could be taken off altogether on the main page and a included on the link page. -- ((srmixter)) 8 January 2013
Osmarender is dead. If at all, we should display the example rendering images of our main layers, i.e. Standard, Cycle Map, Transport Map and MapQuest Open. However each of them is maintained by different people and keeping example pictures of their current rendering up-to-date seems difficult. Moreover we don't even have a key yet for any other than the standard layer which should be higher priority than those example rendering images in my opinion. --Scai 12:10, 11 January 2013 (UTC)

Red Links

Items making its way to Map Features should be well documented. Encountering red links here is the same as not adding the information. I suggest that the cleanup team is given permission to remove red links as they contribute no useful information unless somebody (preferably those who added it) documents its content. --Skippern 09:46, 15 December 2011 (UTC)

Political History Map

I was looking everywhere on the web for a map where you can move a bar back and forth and see historical boundaries change, but I couldn't find anything. I don't know how difficult it would be to integrate, but the data is already available. Later on, if the data can be found, perhaps other metadata could be added like city population and we could see cities flare up like stars, or dwindle during the black death. But, even the most basic incorporation of historical borders would be of tremendous value. Does anyone have any idea where to start? --JGould 08:46, 22 October 2011 (BST)

Probably not as much detail as you require but google earth has some historical maps with timeline slider you can access from the menus, fraid it doesn't seem to move the boundaries for you or change the roadmap overlay.

Sort order

Comment to PeterIto on his talk page: Please revert the alphabetic order, at least in the highway table. We discover now that some newcomers are using "highway=path" instead of "track" just because of that. If you don't do it, I will, which is always annoying. --Pieren 15:51, 15 March 2012 (UTC)

Back in January did a considerable amount of cleanup across all of these tables, increasing consistency between them. All tables are now organised into sections as appropriate and alphabetically within the sections. The contents of the tables is now more consistent, with some common tags added and in other cases excessive detail and duplication reduced. Every table also now also has a taginfo link in a consistent style.
In response to Pieren's specific comment above. I have now added detail to the entry for 'path' in the highways table to suggest that footway, cycleway or track may be better. I do however agree that there is an argument splitting 'Roads' and 'Paths' in Highways table back into separate sections, and it may be appropriate to order the roads section by classification not alphabetically, however raceway, bus_way, living_street, service and pedestrian don't really fit into a logical hierarchy which is why I used alphabetical. I also found it uncomfortable to have track with 'roads' rather than 'paths' which is why I merged them.
If you wish to make such a change then please go ahead, but please do this by adjusting the current table rather than reverting is to an earlier one which would loose the many other changes I have made, in particular many changes to the attributes section.
-- PeterIto 20:46, 15 March 2012 (UTC)
I'm afraid that nobody is carefully watching this talk page. Anyway, what I want is to restore what we had since the beginning, means that the order of highway classes is sorted by importance from the highest to the lowest. This is what newcomers can quickly understand. Otherwise they have to go through 20 descriptions before they can decide which one is appropriate. And of course they don't do that and instead, use the first one that fits more or less for what they need. I received feedbacks from newcomers improperly using hihgway=path just because of the current sorting (instead of "track"). Expanding the short description will solve one issue but not all. What people need is a clear overview about the hierarchy of the highway types, not comments saying "check other values below in case x,y,z". --Pieren 10:48, 16 March 2012 (UTC)
+1 from me for going back to importance-based ordering of road and path highway classes. Yes, there are some rare road types that don't strictly fit the hierarchy - just put them at the bottom of the list. Alphabetic sorting is barely more useful than random and only makes sense if there is no better order available at all. --Tordanik 12:27, 16 March 2012 (UTC)
Sorted. I have gone back the an importance order for highways and it does make more sense. PeterIto 11:24, 31 May 2012 (BST)


I suppose it's refreshing to some to see something not Americentric for once, but the nomenclature being used in OSM is egregiously Britocentric. Terms like "primary highway, secondary highway" are patently Britain-specific. Likewise the "link" road types. "Living street" has no meaning outside Europe, from what I can tell. And apparently Britain has no such thing as "daycare" or "preschool", I suppose they call it something else, but I've no idea what.

I could go on, but could there be maybe some guidance for people outside the UK who basically have to wing it with the Britocentric terms used for map features? Or work on universalising them, perhaps. - KTyler 05:51, 10 May 2012 (BST)

After 8 years, by chance you arrive on the project and want to change what is widely used and accepted all around the world. The tags are key/value pairs which can be added by editors presets (the icons on Potlatch or the presets menu in JOSM). You can translate those presets to your local language/wording if you like (OSM editors are all open sources) as they are already translated into German, French, Russian, etc. Create a US centric version of the features names if you like. Important is only that the meaning of the tags remain consistent over the continents, that a highway=primary is more important than a highway=secondary, etc. Note that many countries created a specific wiki page to explain how the UK centric terminology has to be used with the local practices. See United States roads tagging for instance. Also the Map Features wiki page has been translated in many languages and reworked for local habits, sometimes adding specific local features, sometimes removing features which do not exist locally (like your example of the 'living_street'. --Pieren 12:48, 10 May 2012 (BST)
There could be a page listing commonly used tags that are, or can be, unintuitive for wikipedia:American English natives, purely because of the words used. Just so that they're not limited to searching, which can list lots of unrelated pages. For the lack of a better page title, I'd go for wikipedia:British English. Alv 07:29, 11 May 2012 (BST)
Unfortunately language and country are not the same thing, unless you are proposing an American English language tag. (And a wikipedia:Canadian English, and an Australian, etc.) What I'm saying is that just because everyone has put up with (or more like, it seems, struggled with) the Britocentrisms as the square pegs in their round holes, doesn't mean that the project shouldn't endeavor for terms that are more universal. Sure, it's obvious that a "primary highway" is more "important" than a "secondary highway", but those terms apparently have specific defined meaning in the UK -- elsewhere, afaik, they do not. Outside UK, what makes a road secondary and not primary? Do we just make it up as we go along? Or arbitrarily wing it? Seems like that's an invitation for a globally inconsistent map. - KTyler 20:40, 12 June 2012 (BST)
I do agree that the UK system of road classification is odd, and indeed possibly quaint, however it is probably no more odd than any other. I think it is useful therefore to maintain a single version of English for use for the main tags and values within the database, and for historic reasons that is British English. That is not a reason however not to try to make the documentation in the wiki more understandable to more people, in particular to those more familiar use wikipedia:North American English, although there are other dialects in use for some terms in English as used in Australia and indeed in India. As a simple way to show the amount of variation between the two versions of English, consider the following and notice the diversity of terms used:
  • Wikipedia:Carriageway"A single carriageway road (North American English: undivided highway) has one carriageway with 1, 2 or more lanes together with any associated footways (North American English: sidewalk) and road verges (North American English: tree lawn, boulevard, etc.). A dual carriageway road (North American English: divided highway) has two roadways separated by a central reservation (North American English: median)."
  • wikipedia:road verge "A road verge, (also verge, city grass, devil's strip, nature strip, parking strip, planting strip, sidewalk buffer, tree belt, tree lawn, utility strip, parkway etc.) is a narrow strip of grass or plants and sometimes also trees typically located beside the carriageway (roadway)"
  • wikipedia:Sidewalk "A sidewalk, or pavement, footpath, footway, and sometimes platform, is a path along the side of a road."
As it happens I am currently working on the Highways article on the OSM wiki and will explore how to make it a little more approachable for people from other places. Regarding the classes of road used in different places, this article is useful Highway:International equivalence.
-- PeterIto 22:40, 12 June 2012 (BST)
I appreciate the links to United States roads tagging and Highway:International equivalence. It's not entirely obvious that such pages exist, IMO. :) - KTyler 09:56, 13 June 2012 (BST)
Great. I have also just added United States roads tagging to the 'see also' list in the highways article. PeterIto 10:23, 13 June 2012 (BST)

Telephone lines and poles

There are set conventions for marking electric power lines and poles.

There are no set conventions for marking telephone lines and poles.

Please make some.

Jidanni (talk) 10:40, 18 April 2013 (UTC)

Remove Rendering column

Continuation of Talk:Key:barrier#Remove_Rendering_column. What do you think about removing the Rendering column from map feature tables? The main concern I see now is that rendering samples are dispersed everywhere (some on map feature pages, others on individual tag pages) and not maintained. IMO renderers should have their own page showing samples of all supported tags. This way we keep wiki definitions independent from renderings, and rendering samples are gathered together on their page (easier maintenance). --Oligo (talk) 19:36, 16 July 2013 (UTC)

You can't move the rendering column to each renderer's wiki page. Because mostly it is just the stylesheet that "supports" tags, not the renderer itself. Either we should keep a central sample rendering collection like here on Map Features, or each individual tag page should have a list of example renderings. The latter seems to be more difficult to maintain. --Scai (talk) 20:16, 17 July 2013 (UTC)
I think individual example galleries on each tag page would be a good solution; preferably these would even use machine-readable templates. The current approach to have 0-1 images for each tag in a dedicated column seems limited because it doesn't allow for multiple renderers or even just stylesheets. --Tordanik 05:39, 18 July 2013 (UTC)

" Cyclists share a lane with motor vehicles, but there are markings indicating that they should share the lane with motorists. "

I am not sure about intended meaning but this sentence is at least weird. Can somebody fix it to intended meaning? 06:18, 24 September 2013 (UTC)

Best practice for “User defined” table rows

I am trying to improve the “User defined” rows at the bottom of the tables in all languages. My first draft of a specification, largely based on existing practice, is:

Each table on this page has a row at the bottom labelled “User defined” on the English-language page and specified by the Proposed_features:value2 and Proposed_features:desc template arguments. The description should mention Taginfo and should link to //<key>#values, for instance //, preferably using protocol-relative URLs*. Any references to Tagwatch need to be removed because because this service has closed down. Note that there are repeated rows on the page and each one needs to be edited separately.

--Andrew (talk) 21:53, 30 April 2014 (UTC)

I'm currently playing with a template Taginfo Statistic pictogramm.png (Template:Keystat) for the "User defined" rows and maybe other use cases like proposals, ... . Haven't added a lang variable yet and haven't thought about the http/https nor about language specific Taginfo links. Unfortunately we have fixed the most occurrences of Tagwatch to Taginfo already. Using a Template makes it easier if the syntax of the url links to taginfo changes in the future. --Werner2101 (talk) 11:02, 27 May 2014 (UTC)

Features when tagged and upload not seen in OpenStreetMap

There are features listed in Map Features page but when tagged and uploaded, are not seen in the OpenStreetMap. The data exists when map data view is enabled but in the standard layer physical existence of the feature cannot be viewed. Example: man_made = kiln tag is an accepted tag and is listed in the Map Features page. I tagged an area with this tag and uploaded to osm but I was not able to see the mapped area but the data were there. There is a suggested rendering as well but I guess it is not implemented yet.Basically, We represent the OSM community in Nepal and we are working on a project which include mapping kiln that produce bricks in our capital city. Pollution especially air pollution has been a main issue for quite some time in Kathmandu. According to Environmental Pollution Index 2014 published by Yale University, Nepal ranked second last after Bangladesh in terms of air quality and its effect to human health and toxic chemicals such as polyaromatic hydrocarbons (PAH) from combustion in brick kilns and diesel vehicles (MOEST, 2005) adds to it. We need to map the data related to brick kilns and keep it open (upload to osm) for analysis of the data for possible actions. There are 98 users of the tag man_made = kiln according till October 16 2014.

We want these to be visible in the openstreetmap so what is the procedure to make this feature to be rendered?

  • Each mapping layer available on the map (choose with the “stack of books” icon) maintains its own style sheet with a choice of features to render. The standard layer has its own feature request page.--Andrew (talk) 11:17, 19 October 2014 (UTC)

Seems like there is no way to make this road type.

I meet some road with this conditions:

  • One-way for cars
  • Two-way for moto, bikes, buses.

Seems like there is no way to mark this on the map correctly.

I'd suggest 'road' for the cars and 'specialist' lane for the other vehicle type e.g. bike route. Both lanes to be marked one-way (opposing each other).

You can specify which types of vehicles the oneway tag applies to, as used in the Netherlands: oneway:bicycle=no (meaning bicycles can go both directions). You can either use oneway:motorcar=yes or use oneway=yes plus oneway:motorcyle=no plus oneway:bicycle=no plus whichever mode you further need to add. The only question is if this will be parsed correctly by all routers, but it is the way to tag it. --Mdeen (talk) 14:16, 18 December 2014 (UTC)

Last changes by Xxzme?

I would like to revert the last change to this (already huge) page done by User:Xxzme withou any previous discussion.

I really do not see any benefit of adding here weird template {{Map_Features:animal}}

Also I believe that the templates below were removed previously for a good reason.

In my opinion they should not be here.

Any thoughts?

Chrabros (talk) 11:57, 1 December 2014 (UTC)

I agree that most of them should not be on Map Features, especially things like "animal" (mostly duplicates of tags listed elsewhere or exotic use cases) and "abutters" (that key is no longer used in any significant quantity). There are some where an argument could be made to keep them, but generally we should pay attention to not include every tag ever used on Map Features. --Tordanik 22:31, 1 December 2014 (UTC)
Okay, animal contain duplicate tags. But rest are not. These tags used by people aroud the world. If you want to remove them, please clarify why. Is there better schema now? Is this tag deprecated? Xxzme (talk) 15:27, 4 December 2014 (UTC)
Cycleway template is completely duplicated in highway template. Chrabros (talk) 07:52, 5 December 2014 (UTC)
Valid point, I missed that. Xxzme (talk) 10:40, 5 December 2014 (UTC)
Agreed. If the complaint is that the number of templates differs in some languages that can be fixed.--Andrew (talk) 23:39, 1 December 2014 (UTC)
Not only that. Why do you want to remove tags that are in widespread use in OSM? Xxzme (talk) 15:27, 4 December 2014 (UTC)
Because this page should list only major OSM features in widespread use.
It is not written anywhere. This is only your subjective opinion about how big "Map Features" should be.
You are trying to enforce your opinion about how "wiki should look like". Instead of single view enforced by single user, users should compare multiple approaches and pick one for them. Do not remove valid information. Xxzme (talk) 10:39, 5 December 2014 (UTC)
There are at least three of us who thinks that this page was better before and only you keep changing it by adding unnecessary tags. Chrabros (talk) 07:52, 5 December 2014 (UTC)
There at least Russian community where tag surface in widespread use. There at least countless OsmAnd users who use surface and smoothness tags for routing. There dozens of programs that support contact: namespace, including OsmAnd Xxzme (talk) 10:37, 5 December 2014 (UTC)
Sure they are, I believe you. But why these tags needs to be shown here on this extra large page? There are more tags widely used which are not here. This page is not meant to contain all tags used in OSM. I would suggest to temove surface and abutters again at least. Chrabros (talk) 14:15, 5 December 2014 (UTC)
If we are looking at the additions separately, these are my opinions:
  • {{Map Features:contact}} The alternatives to the contact tags (e.g. website instead of contact:website) are used a lot more often, so they should be the ones featured here.
  • {{Map Features:abutters}} Abutters has vanished in importance when compared to landuse, which is used 3 orders of magnitude more.
  • {{Map Features:smoothness}} Smoothness tagging always been highly controversial and many mappers refuse not to use it, even if there is a following. I believe that it would be misleading to present it to unsuspecting newbies as if it was established.
So these 3 should be removed imo. I could agree with the inclusion of surface, traffic_calming and information in Map Features, as I would consider these largely established and uncontested. --Tordanik 14:47, 5 December 2014 (UTC)
Not simply removed! Users should able to access them easily. Right now it is impossible other than via Map features page. They are present everywhere at wiki, Map features is simply incomplete after you remove them. Before any futher removals we should add cross links to Category:Navigational templatess. abutters should be linked from landuse navbar, contact namespace tags from contacts navbar, smoothness from Template:Highways. Then you can actually remove them from Map features. Xxzme (talk) 15:16, 5 December 2014 (UTC)
The tables are displayed at contact=*, abutters=* and smoothness=*. These pages all have something vital that simple tables lack: an explanation of when you want to use the tags at all without drowning out information for people who want to map other things.--Andrew (talk) 16:45, 5 December 2014 (UTC)
This is because they are Namespaces, not key/tag pages. But it is fine, we will improve this later by expanding them per each tag/key page. User will see links and follow them. But we must show them links to follow at least. See Category:External reference tag - this category should be reimplemented using navbar templates mentioned above. When all links are grouped in navbars they are easy to understand and navigate without reading every single key/tag page - this is huge advantage. Xxzme (talk) 17:15, 5 December 2014 (UTC)
Both {{Map_Features:abutters}} and {{Map_Features:smoothness}} are mentioned in highway template and the tables are shown on their respective pages. So why is it necessary to display them here? Chrabros (talk) 15:21, 8 December 2014 (UTC)
smoothness is not displayed in Template:Map Features:highway (please use ctrl+f). If there any duplicate information we should fix this and remove used templates if possible. Xxzme (talk) 23:00, 9 December 2014 (UTC)
Sorry, my mistake, I meant to say that {{Map_Features:surface}} is mentioned in Template:Map Features:highway so it could be removed as well. But you can add one line for {{Map_Features:smoothness}} in the same way and the size of the whole MapFeatures page would be greatly reduced, no? Chrabros (talk) 07:55, 10 December 2014 (UTC)
Yes sure, done. Xxzme (talk) 14:20, 10 December 2014 (UTC)
The same is true for {{Map_Features:information}} which is mentioned in tourism template. Chrabros (talk) 12:07, 9 December 2014 (UTC)
Okay, there more duplicates. Then should we simple remove these 3 templates, because translators may translate them by mistake. See Category:Map_Features_template Xxzme (talk) 22:31, 9 December 2014 (UTC)
Which three templates are you reffering to? It starts to be a bit confusing. And removed them from where? From MapFeatures page? Chrabros (talk) 07:55, 10 December 2014 (UTC)
4 already, they are removed from Map features but their names are confusing for translators (they named "Map features" but they are not used at Map features page itself but at respective Key: pages. This is not obvious when you open Category:Map_Features_template, we should keep this category clean so translators can easily update their Map features pages easily. Xxzme (talk) 14:20, 10 December 2014 (UTC)
{{Map_Features:traffic calming}}
Why do we have to include Traffic Calming template when this template itself is not used on the key page in English at all? See traffic_calming=*. Chrabros (talk) 12:40, 18 December 2014 (UTC)
If you ask me, a map feature template shouldn't be in both the key page and in the map features page. Why? Because these pages have conflicting purposes. The Map Features page is supposed to show tags accepted by the community while the page of a key is an attempt to enumerate most values of the key. --Jgpacker (talk) 18:59, 22 December 2014 (UTC)

Road type: Dual Carriageway

I'm sure this is needed as other mappers have a specific symbol for them and they are quite different from two opposing roads.

Foot(path) distinctions

I think it'd be better if path and footpath / footway were better differentiated. I like the idea of 'path' being either unmarked or generally rough / unsuitable for wheelchairs and footpath/footway being a good surface and suitable for wheelchairs - i.e. only single steps rather than flights.

Rail Track: direction ?

There doesn't appear to be an option to indicate the direction of travel on the tracks. One for the future, I guess.

Pmailkeey (talk) 10:27, 5 December 2014 (UTC)

oneway:bicycle and cycleway=*

The Wiki page does not give any comment on whether to add oneway:bicycle=no on a cycleway=opposite_track or not. On Key:oneway:bicycle I cannot find any explicit statement about whether to add oneway:bicycle=no if it applies to cycleway=opposite_track or cycleway=track.

The actual reason for my question is: I want to tag cycleway:right:oneway=no while the highway=* has oneway=yes. So the question is actually much more related to oneway=* than anything else. So I will ask the question again on the page above and propose to continue the discussion there. Please tell me since the proposed tagging at this page was not intended and there.--U715371 (talk) 19:42, 25 February 2015 (UTC)

Because Key:oneway#Sub_keys_.2F_exceptions in fact states what I was asking for, I will add the suggestion to use oneway:bicycle=no to cycleway=opposite_track after March 9th 2015, if there are no further comments.--U715371 (talk) 23:48, 1 March 2015 (UTC)


If someone can figure out how to edit this page, can they remove the b from bevergreen ?

Done. Chrabros (talk) 07:20, 22 April 2015 (UTC)

No way to click to see examples on the map

So we read about lots of features.

But let's say one wishes to see an example on the map.

No where can one click to see a example of a given feature on the map.

No matter on this page, nor on the individual tag's page.

Nor is there a way mentioned to see all of feature X within Y kilometers of me here at Z.

Jidanni (talk) 20:54, 12 August 2015 (UTC)

What tags get included in this wiki?

I am looking at the tags listed on this wiki for cycleway=* , and see that cycleway=shared is not included, even though CycleStreets uses it to make route recommendations, and Taginfo shows it as the 6th most popular value. What are the criteria used to determine whether a tag should be included here? --One Ironaut (talk) 02:14, 21 September 2015 (UTC)

If you think that this tag is frequently used, then just add it here. Chrabros (talk) 07:18, 21 September 2015 (UTC)
Only established tags should be added here. This means as many as possible of: approved by vote, well documented, mostly uncontested, used in several independent applications, used by a lot of mappers. The exact threshold is somewhat subjective, though.
In your specific example, the "shared" value is said to be "considered obsolete" on Key:cycleway, so that would be a possible reason to not list it here. --Tordanik 08:12, 21 September 2015 (UTC)

Map key lacks farmland

Farmland (beige colour) is missing in the map key on --SelfishSeahorse (talk) 19:31, 16 March 2016 (UTC)

Czech version of MapFeatures is too complicated

Hi, it seems that the Czech version of Cs:Map Features page has become too complicated for this server and it is not shown complete.

Does anyone know how to solve it? Can someone adjust the server parameters so this important page is not truncated?

Thank you. Chrabros (talk) 13:15, 17 May 2016 (UTC)

"Map Features" attempts to document in the same page every tag documented on this wiki ! That's very bad, if should just document a common subset.
In fact Map Features is very huge in all language, including English, there are too many templates transcluded, generating too much content.
Really, there should be separate thematic sections for most details.
"groups" will be used for that but for now they are mostly drafts and still not well organized. Support for translated group names is starting (being tested for now in French and Japanese in a few pages). The early attempts to create "groups" were completely broken in all languages (including English!)
So don't bother with Map Features, try translating pages for feature groups that are transcluding much less templates.
Verdy_p (talk) 16:13, 17 May 2016 (UTC)
Well, I really was not looking for an answer "don't bother". I would prefer if someone could extend the parameters of the server slightly so the server could display the whole page.
I consider this page quite important, after all it is linked from a prominent place in the main menu.
Chrabros (talk) 06:21, 18 May 2016 (UTC)
I mean that we cannot continue expanding the content if this page indedinitely. This page has gone out of scope over time because it is insufficiently focused on much too many details.
It requires splitting in all cases (and in all languages), using separate pages, and then changing this page into just a summary index of topics, not a complete list of tags.
For the complete list of tags (alphabetic index) we have categories. For searches, well we have... the search bar. Then we an also have thematic "groups" (both in subcategories, or in more focused pages).
Verdy_p (talk) 09:33, 18 May 2016 (UTC)
Ack. I don't use the page. And there is no official "list of all tags" in OSM which this page suggests.--Jojo4u (talk) 14:21, 25 May 2016 (UTC)
I’ve managed to simplify {{TagPagename}} to get the whole of Cs:Map Features to display. Japanese, Russian and Ukrainian need more work.--Andrew (talk) 20:56, 26 May 2016 (UTC)
Thanks fot this, but it does not help actually. I had to remove the whole template Sport to get the rest of the page to be displayed. When I re-enter it then the problem persists. Chrabros (talk) 07:12, 27 May 2016 (UTC)

Map Features usefulness, usability and maintainability

I’ve started a mailing list discussion about this page and what we are trying to acheive.--Andrew (talk) 09:19, 29 May 2016 (UTC)

As a wiki editor and heavy mapper I don't use this page. It takes ages to render and displays only a selection (e.g. club=* is missing). I usually use search to find a feature.--Jojo4u (talk) 23:18, 30 May 2016 (UTC)
I wonder if the long time to render is related to the large size of templates that overflows size limits in some languages. Are there profiling tools for Mediawiki that tell us what is taking up the space?--Andrew (talk) 04:15, 31 May 2016 (UTC)
The really long rendering time is because of some browser add-on or other settting of my Firefox. Using a fresh profile or Opera the rendering time is inside the expected limits for such a big page.--Jojo4u (talk) 16:03, 5 September 2016 (UTC)

Using Tag lists


I have noticed that two of us have made a radical step and replaced the usual Map Features templates with Tag lists (so far for Geological, Office and Man-Made sections).

I do not like this change and I would like to discuss it.

The original Map Features templates (as I understood them) were hand picked selection of the most useful tags from given category. It was replaced by a list which lists every tag which has a documentation (no matter how bad) on wiki. What's the point of promoting tags like office=camping and office=engineer - to name the first two from many examples? Also when anyone creates any page in those "namspaces" it gets listed automatically in Map Features page which give is some kind of legitimacy and promotion, which is undesirable.

Also the rendering column is missing in Tag lists. So these sections are different from the rest of the page.

There is another problem that the Tag lists are not translated fully in other languages (for sure it is not available in Czech). So if I were to use it on Czech version of Map Features page I would have to live with a partially translated pagem, which I do not like as the page is translated completely to the Czech language. The current status - when the Tag lists are used on English version of Map Features page only - I do not like either as the content of English and all the other language versions is different and will diverge over the time.

I do not see any significant benefits in using Tag lists so far and I see only drawbacks. So I would propose to return to the original state. What is your opinion?

Chrabros (talk) 06:25, 5 September 2016 (UTC)

The main problem this will solve is diverging definitions on the Tag Features pages and the main wiki page. Having the definitions on two different pages is quite a maintenance burden, and it's clear that not many users contribute to keeping the definitions synchronised. Note that some definition are better on the individual pages, and some are better on the Map Features page, so duplicating the work really leads to less quality overall.
The old list was hand-picked. However, who is to make the decision which tags to pick and which tags not to pick? Personally I have no problem with office=engineer.
Perhaps one way to exclude weak tags is to require a minimal number of instances?
About the rendering column, Jochen Topf (who created TagList), will be adding this column to TagList too. So at least this is something that will be solved.
See also the mailing list for more information:
I think using TagList is the way to go for the future, but I do agree that this step warrants more discussion. I'm therefore fine with rolling back the changes until a discussion in the community has taken place.
Maybe we can create an alternative Map Features Beta page in the meanwhile?Math1985 (talk) 08:14, 5 September 2016 (UTC)
Hmm, if the main problem is to solve the diverging definitions then I see what you are up to. However I never saw this as a big problem in my language as all the definitions were created by me and I keep them synced. But I can see that it can pose a problem for someone.
But I think that sometimes it is useful to have one short description for the info box and Taginfo and one longer for a MapFeatures page. Maybe (just an idea) we could add one more infobox parameter with a longer description for TagList. If it would be present it would be displayed by TagList in preference to a description= parameter.
Also I think it would be very nice to have parameter to exclude (or include) the tag from the TagList at all. Something like "MapFeatures=yes/no" with the default setting beeing maybe "yes" (not sure here).
That would allow us to exclude deprecated or poorly documented or very rare tags from the list and therefore we could both have what we aim for.
Chrabros (talk) 08:31, 5 September 2016 (UTC)
Which tags appear in a taglist is controllable by the user. That was one of my most important design goals for the taglist: You can get all tags with as specific key if you want to, but you can also just list specific tags. The mechanism behind this doesn't decide, the community does. As for the missing translations, this can, and should be, fixed (see Talk:Taginfo/Taglists#Translation. I am just not sure what the best way would be to do this, technically and for the users, and welcome any input. I will add a "rendering" column to the taglists once that information is in the info box template. Currently the information is just not there, so taginfo can't get to it. The biggest question, in my opinion, concerns the description. I am not a big fan of having a "short description" and a "long description" or something like this. It just makes keeping things up to date more difficult and using the descriptions more difficult for any kind of program, because you always have to ask yourself, which one to use, what to do if there is only one etc. I think there should be only one concise description used everywhere. For more information, you can always click through to the wiki page. But this is certainly something which can be debated and taginfo can be changed if necessary. There is a different problem there: Taginfo currently doesn't work well if the description contains anything other than plain text. Markup or even links sometimes don't work. I think we should discourage the use of markup or links in those description texts because it makes it basically impossible to use the descriptions outside the wiki context. If I want to, say, show those descriptions in an editor, the editor would have to understand mediawiki markup (or taginfo would have to understand it and translate somehow). I think it is much better if we always require plain text and add extra information like wikipedia links into a different field in the info box. Joto (talk) 09:52, 5 September 2016 (UTC)
I fully agree with 'I think we should discourage the use of markup or links in those description texts'. We need to manually review all TagList and Map Features definitions anyway, this is something we can include in that process. Math1985 (talk) 11:33, 5 September 2016 (UTC)