Talk:Map Features

Older discussions may be found in the Archive.

Contents 1 landuse=basin 2 man_made=water_works 3 toll 4 Tag found that is not member of any list 5 man_made=billboard 6 Mobile (or Cell) Phone Mast? 7 Cleanup Request 7.1 Red Links 8 Political History Map 9 Sort order 10 Britocentric?

landuse=basin

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

man_made=water_works

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

toll

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)

man_made=billboard

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)

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

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)

Britocentric?

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 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 British English. Alv 07:29, 11 May 2012 (BST)