This is an archive of older discussions on the Talk:Map Features-page, if if grows too unwieldy it should be divided into several pages. Discussions that concern a specific topic that has a page of its own may be moved there, but a link to the moved discussion left here.

---

Archive 2006

This section contains discussions that no further comment have been added to since 2006. Archived 07:56, 6 June 2008 (UTC)

Compound words convention

There is some inconsistency about the way compound words are created, compare "pubcrawl" with "national_park". IMHO we should use camel case: pubCrawl and nationalPark.

I agree we should be consistent, well spotted, we should also get the coder's views on the format. I'm concerned about the eventual size of the xml in terms of transfer so some shorthand version of both keys and values might be beneficial, although for this page I think we should keep to the plain English so that we can understand it better. Why not put the proposed actual keys and values in the xml format on a separate keys & values page(s). No reason why we should not devote a page to each one and link to each page from the table here. Blackadder 11:09, 17 Mar 2006 (UTC)

Version identifier for agreed tag names

Whatever is agreed should be labelled with some kind of version identifier so that clients can state that they expect data containing, say, "OSM-core-1.3" tags or "OSM-marine-1.0" tags or "Blackadder-Brum-3.2" tags or whatever.

I fully intend to add my own personal keys and values so that I can use the final output in my own specific way. Client software for editing needs to support any key and value in terms of the editing process, as JOSM does now. For rendering though I see that each bit of software will do either something specific with certain core keys or will allow users to map keys and values to a user defined schema in the client. Blackadder 11:09, 17 Mar 2006 (UTC)

I boldly suggest that this scheme be named "OSM-core-1.0" when it is ready. 80n 13:40, 17 Mar 2006 (UTC)

80n 08:48, 17 Mar 2006 (UTC)

Good feedback. Thanks. Blackadder 11:09, 17 Mar 2006 (UTC)

Think globally & other thoughts

Just a few of my thoughs:

I think that there needs to be a greater effort to think globally. There are plenty of little examples of specifically British things that could make life difficult when transferred to other countries. The tag that stuck out for me was "Motorway".

The problem is inferred data. It makes sense to infer data from existing tags, to reduce file for each entity and reduce time and effort when the map is created. Eg, some of the tags you can infer from "highway=motoway" such as speed limits (high and low), resticted traffic, etc. become quite simply incorrect if that tag is used to describe a french Autoroute or german Autobahn. Also, there may be other data that is useful for a certain application that can be inferred from other tags, but may not be explicitly specified. I think there should be a definition of all other tags that can be directly inferred from each tag (might end up being a huge list) which would then be published (as part of the API) to be processed and mangled into whatever format then end application needs it

Firstly, the tags need to be generic in nature, so that a gps using openstreetmap will not misinterpert a "motorway" appearing in another country, or not be able to find one because every country has their own tag based on their own road names (this would be bad).

Also someone needs to define exactly what the road categories relate to. I would suggest (or this is what i think they mean compared to UK road types).

• Motorway : Motorway (though I don't like the key)
• Trunk: 2-lane A-road
• Primary: A-road
• Secondary: B-road
• Minor: Every other public road
• Residential: fairly obvious.

Ideally a list like this would exist for all countries, so roads of similar quality appear in the database as the same

In addition There doesn't seem to be obvious scope for multilingual names. This is most obviously a problem in Wales, but may also cause problems in other countries, eg the different british and german names for Munich or München.

Also, I'm slightly confused about the real difference between a way and a segment. It's made fairly clear in the context of naming streets. But, what about a situation where the characteristics of a road change. eg. the high streets is many british towns have sections where they are pedestrianised and those where they are'nt What's supposed to happen in this situation? Should highway keys be put on the segments and the name on the way, or create 2 separate ways, or 3 ways, one for each part, and one for the whole lot? in short, what does the segement entity represent.

Final thought. I'm not sure about whether this is the right place to put this, but it occurs to me that much of the thought going into this site is advocating "expandability" and "flexibility" without realising that maps only work because they have a list of extremely tight rules governing how things appear, are laid out, what to include, what not to include. These allow you, the user, to filter out the bits you don't need because the bits you do are consistently laid out, coloured, etc. For this project to work it needs to take responsibility and as much of the control as it can over the layout rules, but make sure that the mechanis==Natural water==

Lakes are represented as "natural=water". But do we use that for artificial lakes too? (docks, reservoirs, flooded clay pits, etc.) Ojw 10:42, 8 Jul 2006 (UTC)

Perhaps an additional key is required to define the type of resourse, eg a reservoir, natural lake, pit, river estuary etc. Perhaps feature=reservoir or something like that. Blackadder 10:06, 10 Aug 2006 (BST)

Natural forest

Forests and woods are currently specified as landuse=forest or landuse=wood. Given that woodland and forests are typically a natural feature and do have a strong natural association, I propose the tags landuse=forest should become natural=forest and landuse=wood should become natural=woodland just like we have scree scrub heath and marsh as natural biome labels NickH 11:08, 22 Aug 2006 (BST)

What about orchards? and we should probably disinguish between fir and deciduous trees too.ms are in place to deal with syntax changes, or quickly make additions to the rulebook to deal with a new requirement (ie. before 2 people decide to invent 2 different ways because the can't wait for the official word.).

Sorry if some of it sounds a bit whiney, I don't mean to complain, just encourage debate by identifying my own problems with the system as it stands Sandothegrate 14:04, 21 Jun 2006 (UTC)

Roundabouts

How would a roundabout on a primary road be distinguished from a roundabout in a residential area? This should not be a highway tag. Need to be able to say highway=primary and junction=roundabout. 80n 18:00, 16 May 2006 (UTC)

A roundabout is an entity in its own right and roads happen to join it. What differentiates a Primary and a residential roundabout other than size (implied by its nodes). What would you put if a minor road crossed a primary road via a roundabout? --Dean Earley 19:00, 21 May 2006 (UTC)

After playing with Osmarender, I now see a reason for not using highway=roundabout. I still think things should be marked with highway=roundabout but can't suggest a way of rendering this. --Dean Earley 11:41, 25 May 2006 (UTC)

Just as an example:

Ojw would make 1,2,4 primary roads and 3 a secondary road, but tag them somehow with a roundabout-related tag so that we can identify them later...

Maybe I'm thick, but I still can't work out what the reccomendation is here. In my opinion it makes most sense to make the way include all of the loop and any of the "triangles" at the exits, then tag it with both junction=roundabout and highway=x, where x would normally be the class of the biggest road joining to it, using the _link variant for motorway, trunk and primary roads. Sandothegrate 23:15, 1 Sep 2006 (BST)

I don't see a problem with your approach. Mine is only different in that I tend to have the forked ends adjoing the roundabout as part of the attached way rather that attached to the roundabout. In any case I make a way for the road leaning in, a way for the roundabout itself and then anotherone for the exiting road. This works fine on the whole for rendering purposes but does occasionally muck up the text which your method would aleviate as you dont normally render text on roundabouts. For navigation purposes... well thats another story! Blackadder 00:00, 2 Sep 2006 (BST)

Authority, Reference, Creativity

The current list of features is a wiki page. Does it mean I can edit it, and what implications does that have on developers of client software such as the Java applet and JOSM? Does the current list represent what happens to be in the OSM database? Or what the author of the wiki page wants to happen? Or does it reflect some already existing GIS standard? If such a standard already exists, should we still define our own? I'm using the Java applet and after a year I'm still just adding line segments. I'm very reluctant to the "ways" concept and apparently this list of features contradict the use of "class" in the Java applet. It's all a big mess and needs to be remade from scratch. --LA2 16:42, 1 Jun 2006 (UTC)

The principle concerning tags seems to be "no compulsion, no prohibition". You are not forced to do anything, you cannot be stopped from doing anything. However despite this anarchic philosophy, good, consistent, comprehensive and useful schemes can be created and the Map Features is just such a thing. The class scheme is another one. IMHO the Map Features scheme is currently more comprehensive and consistent that the class scheme and so, for me at least, it is more useful.

It is true that having many competing schemes that are all attempting to describe the same thing could be counter-productive. On the other hand, separate schemes for specialised applications (like the UK cycle network or piste maps) can easily be accommodated and do not conflict. Evolution will hopefully ensure that the best of any competing schemes becomes the dominant scheme.

Some of the tags in the Map Features scheme are quite UK centric (eg Motorway vs Freeway vs Autobahn). Country specific variants of this scheme or even completely seperate schemes might evolve, or this scheme could be extended to allow Freeway as another highway type. Most of the renderer efforts are to a greater or lesser extent table driven and should be able to accommodate changes to the schemes as they grow and evolve.

Personally, I use the Map Features scheme and will stick with it unless/until something better comes along. 80n 09:21, 2 Jun 2006 (UTC)

Linear non-highways?

Any ideas for labelling things like hedge lines, field boundaries, power lines, fences? (talking about features in the deepest countryside here, not fences by the side of a road...) Ojw 14:21, 4 Jun 2006 (UTC)

For anyone who decides to devise some tags for hedges etc, please allow fields to be named. In my experience most farms in the UK have reasonably well recognised names for each field. 80n 21:16, 11 Jun 2006 (UTC)

Has anything come of this? I have gathered a lot of data about where the feild boundries are, and weather they are hedges, fences, open, or mixed borders. I'm not exactly shore how i should add them though, but i feal its important they should be added, as they are sometimes the only landmark for a person to reference. If I want a field to label 'rape seed' and then a hedge row around it to layble 'hedge' and then there is a track around it, and a road on the other side of the hedge... shoudl this then be 4 different ways? or is there a way to use the ways that make the field area also used for the hedge, and the road?.. Ben. 14:51 6th October 2006 (BST)

Procedure for changing this document

Looking at the history of this document, and how it relates to the real-world use, two things seem to stand out:

• People have lots of ideas for new things they'd like to mark on the map
• Most of these new tags won't show-up on the rendering software

It would be nice to have a page at Proposed map features, where people can define a map feature they want to add, and then discuss or vote on the ideas in a structured way.

For those of us writing renderers (80N's osmarender, my PDF atlas, and the openstreetmap.org team), it would be good to see what features people would like to tag, so that we can modify our software in a timely way to show those features and help the data-gatherers see what they're creating.

Creating a new wiki page would at least give the impression that it's okay to propose new tags, and give a URL to send people who ask whether they can add a particular tag.

Ojw 18:45, 11 Jun 2006 (UTC)

sounds a lot more scalable than having everything on this page, how about creating a category "proposed map features", that way we'll have every proposition in a single thread, so e.g. you can create a new page with the name map_feature_xy and add [ [category:proposed map features] ] at the bottom. if the feature isn't contradicted after a defined time (1month?) or is being appreciated, we could then add it to the map features wiki page, which would then be the official tag-table for renderer-builders

blk 19:22, 11 Jun 2006 (UTC)

I think this is a sound idea - to extend the coverage of tagging and also to have a mechanism that at least gets some feedback on the appropriateness of the proposed tags. We shouldn’t forget that a user is entitled to use whatever tag they wish for their own purposes, but here I think we are going beyond that by providing discussion that helps the majority fit the data input with available output options. Having said that I believe we have a first step to thrash out what a key should be. At the moment there is no restriction or convention on what a key is. Blackadder 10:40, 12 Jun 2006 (UTC)

Gate in highway/nodes

I would like to know what is meant by "gate" in highway/nodes. Could it be a synonym for barrier ?

Thanks. FredB 20:08, 26 Jun 2006 (UTC)

In the UK we have gated roads, mainly associated with a cattle grid that stops livestock that roams freely on open land from getting into areas where livestock is fenced in. You can also of course find gates on many footpaths. Barrier is an alternative but suggests you might not be able to pass, whereas a gate implys you might be able to open it to continue passage. Blackadder 09:38, 3 Jul 2006 (UTC)

Ok thanks a lot. FredB 10:08, 3 Jul 2006 (UTC)

Natural water

Lakes are represented as "natural=water". But do we use that for artificial lakes too? (docks, reservoirs, flooded clay pits, etc.) Ojw 10:42, 8 Jul 2006 (UTC)

Perhaps an additional key is required to define the type of resourse, eg a reservoir, natural lake, pit, river estuary etc. Perhaps feature=reservoir or something like that. Blackadder 10:06, 10 Aug 2006 (BST)

Natural forest

Forests and woods are currently specified as landuse=forest or landuse=wood. Given that woodland and forests are typically a natural feature and do have a strong natural association, I propose the tags landuse=forest should become natural=forest and landuse=wood should become natural=woodland just like we have scree scrub heath and marsh as natural biome labels NickH 11:08, 22 Aug 2006 (BST)

What about orchards? and we should probably disinguish between fir and deciduous trees too.

Historic

Many items are of historic interest. However, you would not necessarily describe something as primarily historic. It is more important to describe what it actually is, rather than describing it as historic. For example, A castle isn't a historic. A castle is a building which perhaps has a property of being of historic interest. A monument may be a building with or without having a property of historic interest. I therefore propose that the historic tag should no longer describe what it is, but instead describe what type of history may be attached to it.

I propose: historic=monument and historic=castle should become building=monument and building=castle . All other currently defined historic tags marked deprecated. The historic tag should then be re-purposed for the type of history it relates. For example, castles would be history=kings_queens battles would be history=war old churches marked history=eclesiastical, old machinery history=industrial, fossils and excavation sites history=natural. I will produce a table with re-purposed history tags.

There's many other historical things we need to consider: Stone circles, earthworks (linear) like Offa's Dyke, forts (without any ruins or buildings remaining,) barrow, burial chambers etc. Anyone any ideas how we could tag these things? --Gwall 12:07, 5 September 2006 (BST)

Tracks

Currently, so i understand, there is just 'tracks' for anything smaller than a minor road?...This means round me everything is Minor, or Track. This seems very vage. Also Rather than just sticking a tag for a gate on the road, cant the entire road be marked as a gated road, as that is what they are called, and sign posted as. Would having Minor - Gated - Drive - Lane - Track, be better, as this would cover all the types. It's just theres a huge difference between a farm driveway with tarmack or cement, a Lane with Gravel or stones and usually some sort of hedging around them, and tracks that are nothing more than compacted earth that run along field edges. Ben 21:17, 13 September 2006 (BST)

Also...Resedential Roads: I'm not really shore what the difference between minor and residential is, cause the roads are the same. I asume it automatically gereates the graphics for houses? when rendered later. If so, how do i just stick a buildings on one side of the road?. Or do i need to draw a box and applie a tag to that to make it a building? Ben 21:26, 13 September 2006 (BST)

Embankments/Valley

When trainlines/roads/dismantled railways etc cut threw the land, the ground either side rises or dips sharply. Is there any way these banks can be represented currently? Ben 21:23, 13 September 2006 (BST)

---

User Defined Tags

User defined would IMHO be best implemented using a namespace scheme, otherwise the core scheme become impossible to extend. If I elect to use <tag k="waterway" v="pool"/> to represent artificial basins then this makes it hard to implement a core tag that means a small pond. OTOH if I used <tag k="waterway" v="ec:pool"/> then there is no possibility of conflict. Likewise user defined tags should be namespaced so <tag k="opm:liftType" v="chair"/> would avoid future conflict should we want a core tag called liftType.

Agreed, it would be a good idea to have all User Defined tags in a different format to core tags although I'm not sure the intention was ever to be that restrictive on the format. As far as I'm concerned, anything goes provided the syntax does not break something (down to the editing software to ensure that). You just have to remember that if you want other users to know what you meant you need to follow something they can understand, eg a core set. Blackadder 11:09, 17 Mar 2006 (UTC)

I propose that we add a strong bit of advice to recommend that user defined values are prefixed with a namespace if the user wants to guarantee that they won't conflict with, or worse, be misinterpreted by some future usage. 80n 13:40, 17 Mar 2006 (UTC)

Why not just say that "everything may conflict, everything may be changed in the future?". Would be more honest. I don't see why anything should be engraved in stone. Coders should not be lured to think that they may depend on any value to be there.

I just have finished a converter of OSM xml format to other formats and I BOLDLY suggest to restrict the allowed characters of tags (= key-names) to the following set: 'aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ_' in order to retain reusability. After having looked at about 100 MB of data we found characters like space, slashes, colons and even more weird ones. And I don't think this will take too much of users freedom of choice... --Geonick 00:26, 12 February 2008 (UTC)

Proposal for strong namespaces

There has been a lot of talk both on the mailing list and IRC about how to internationalise the names used for tagging. Here's my suggestion:

The problem

• Anyone should be able to use whatever tags they want. This makes it impossible to enforce any standards, which makes it hard to render or use the data in many automated ways.
• The "Map Features" tags are UK optimised. This makes it harder for other countries to work out how to tag roads. It may also have other side effects - for example some countries have speed restrictions on their equivalents to motorways.

A solution

I propose that we introduce a namespace to both the keys and values, for example:

<segment>
 <tag k="core:highway" v="GB:motorway"/>
</segment>

This would define the key-value pair to be a member of the "core" namespace. This namespace should be reserved for pre-agreed key/value pairs. The value defines the "highway" to be a "motorway" in the GB - I use GB rather than UK so as to follow the ISO convention.

This way key vale pairs can be defined for each country, so that they make sense in each country and are in-keeping with the local laws, for example:

<segment>
 <tag k="core:highway" v="DE:autobahn"/>
</segment>

This would be an autobahn in Germany. I have elected to fix the key value - this, guess could be changed, though I feel that it might add very little to the scheme. This can be dealt with in the GUI if deemed appropriate

OK, I'm beginning to think that it should be k="core1:highway" rather than k="core:highway" to allow for further extensions beyond "core v.1" Mwelchuk

Mwelchuk 22:51, 08 August 2006 (UTC)

I kinda like the idea of having country specific tags. However I think a better system would be to define where each country is (possibly with the help of the is_in tags and using the same method that freethepostcode uses). We then use that hierarchical information to determine the country (a street belongs to a city, which belongs to a region, which belongs to the country, which belongs to a continent). This method would probably take more work, though it wouldn't require a change to the tags to include the country name in the value. Renderers would need to be updated to cover their specific country names such as autobahn, and to be able to cope with the country specific defaults. However it would be simpler for data entry. Another example would be max_speed. This can be mph or km/h depending the country that you are in. Smsm1 01:17, 9 July 2007 (BST)

Confusing Table

Now I know why I was confused at first. The first row in each section of the table implies that the key should be type and the value should be, for example, highway:

Feature	Feature type	Key	Value	Comments
Linear	Physical	type	highway	Only one of the following
Linear	Physical	highway	motorway
Linear	Physical	highway	trunk
Linear	Physical	highway	primary
Linear	Physical	highway	secondary

Would it be better like this?

Feature	Feature type	Key	Value	Comments
Linear	Physical	highway	One of the following
Linear	Physical		motorway	For restricted access divided highways
Linear	Physical		trunk	For unrestricted access divided highways and other inter regional routes
Linear	Physical		primary	For primary roads
Linear	Physical		secondary	For secondary roads

80n 17:50, 17 Mar 2006 (UTC)

Yep. It started out as a spreadsheet which I was simply replicating down as I went. Your revision looks clearer. Blackadder 18:04, 17 Mar 2006 (UTC)

Feature	Key	Value	Comments
Linear	highway	One of the following
		motorway	For restricted access divided highways
		trunk	For unrestricted access divided highways and other inter regional routes
		primary	For primary roads
		secondary	For secondary roads

This is even cleaner to me. I don't know why list the "Physical" at all. Can it be entered somewhere? Does it matter? And please, remove the "User Defined" - stuff. EVERYTHING can be User Defined. --Imi 15:35, 24 Mar 2006 (UTC)

When starting off I split the keys into logical groups to help reduce duplication. As you say, these groupings have no import into the actual use of the keys and values and you won't therefore find them mentioned on the individual keys and values pages. I plan on cleaning these out sometime in the future. Blackadder 16:24, 24 Mar 2006 (UTC)

I agree this looks much better than the table right now. Can I start doing this on the main page? --bartv 09:29, 21 October 2006

I just did this for the first part. If there is no outrage I plan to do the rest next weekend or something--Bartv 11:26, 18 November 2006 (UTC)

Outrage! :) I find this change harder to read, and makes a scroll needed to see the key name (Yes, I have poor memory…)

Oh, and with the default link colour, it's harder to read the key:value link with it being dark blue on wine red.

Suggestion: use fewer table columns (doable, remove feature, feature type from table), maybe shrink images, or create a two values/entries per row table -- Johndrinkwater 15:58, 22 November 2006 (UTC)

I have prepared 4 small symbol instead of text (node, segment, way, area) in Element column. see example bellow --Dido 08:03, 17 June 2007 (BST)

- node, - segment, - way, - area

Power

Key	Value	Element	Comment
power	tower
power	line

• It is a good idea. Small changes I propose: the angles and lengths of lines should be in every symbol the same, use a border, node a little bit bigger (here with red midpoint approximated to JOSM). And pastel colors.

--OnTour 20:24, 17 June 2007 (BST)

• I like this idea too, especially the changes from OnTour. Makes the thinks a lot easier for newcomers. --Etric Celine 20:48, 17 June 2007 (BST)

yes/no or true/false

Should we be using yes and no as we generally are now or swop to more generally recognised boolean true/false Blackadder 09:19, 24 Mar 2006 (UTC)

yes=1=true=on, no=0=false=off. Doesn't matter to me. --Imi 15:37, 24 Mar 2006 (UTC)

Hmmm if we were going for "more generally recognised", I'd say "yes/no" is probably more widely used and recognised than "true/false" (among the english speaking non-geek population at least)... but then "true/false" seems more precise and unambiguous. Either way seems fine. We should probably choose one or the other, for the sake of making the data easier to use. -- Harry Wood 14:42, 28 August 2007 (BST)

Why highway?

why do you use "highway" as tag name? "highway=footway" is a very strange syntax.. Erik Johansson 08:38, 3 Jul 2006 (UTC)

I grouped different types of ways, hence highway, waterway, railway etc. So if you can think of a better container for roads, footpaths, bridleways, cyclepaths and other street type features then you could use that as an alternative. Of course if you don't want to group you can simply use footpath=yes of something similar. Blackadder 09:34, 3 Jul 2006 (UTC)

Why not just "way" then? Stefanb 10:15, 20 March 2007 (UTC)

That would be confusing in the sense of tagging a way with the key "way". Bruce89 15:23, 20 March 2007 (UTC)

I think "route" would be a better container, even though it's already otherwise in use. --Hawke 09:51, 10 June 2007 (BST)

right-of-way is the usual convention for these things, as that is what is being defined, the right to use it as a way of travel Myfanwy 15:08, 4 October 2007 (BST)

Buildings

I suggest a generic set of tags irrespective of the use of the building: building=warehouse building=tower building=block (eg office block or block of flats) building=terrace building=detached building=semi with additional tags such as height=<height_in_meters> floors=<number_of_floors_above_ground> use=<public|commercial|residential> with amenities provided (eg medical care/surgery/hospital/library/supermarket/town hall/restaurant) specified either in nodes or as tags to the building area.

I agree and suggest adding 2 properties for house-number and the street it belongs to enable door-to-door navigation. Houses spanning multiple house-numbers/streets are broken up into individual ones. Would the id of the Street(easy to parse) or the exact name(would need to be exactly as written in the street and be changed if the name of the street changes) be better as a value? With current tools the name is far easier to do. --MarcusWolschon 16:46, 14 August 2007 (BST)

Tourism

Everything in the tourism section is more fittingly an amenity. I propose moving all those to the amenity tag and creating a new tag, interest, to include the following: tourist, motorist. I'm open to suggestions for other things it could include. -- Hawke 02:51, 25 January 2007 (UTC)

Markets

I need the ability to tag (street) markets. OK with amenity=market? Pemberton

Just the thing I was looking for, so I'm in agreement with you Papaspoof

Alternate system

Hello, I'm possibly over-keen for some programming to do, but would it be useful to have the key,possible values,comments stored in a database and then shown on this page? Dunno if it would be useful? The key's own page (ie Key:highway could be automatically generated from the same data, meaning their would be less copy pasting of data, and less chance of errors?

To (for example) add a new key, you'd see a form requesting the key name and its possible values and comments etc.

If your interested, to see an example of data being shown in a wiki page but pulled from a database, there is a event manager example here. (log in with username test, password test). Click on the 'e' by any event and you can see how it can be edited. (Please don't click x or d). This code has a history of all changes, and changes are revertable just like in the wiki system. --Rickm 23:23, 24 September 2006 (BST)

Oh, the other reason I thought of it was that it would mean showing different languages & translating them might be easier --Rickm 23:28, 24 September 2006 (BST)

Default values

See the discussion on default values I started on the mailing list. Archive. Basically all tags have a default and we should explicitly mention what it is for each tag. --bartv 09:29, 21 October 2005 (CET)

Fall trough from ways to segments

Some (most) of the linear tag/value pairs make sense for both ways and segments. I think we should think about how they work together. For example what if the "oneway" tag of a street is set to "no" expect. None of the segments that make up this particular way have "oneway" tag set except for one segment where it is set as "yes".

Most logical seems to me have the tag on the segment take priority. Thus in the earlier example the whole street is open for two-way traffic except for the section described by the segment that also carries an overriding "oneway" tag.

This issue touches my previous "default values" remark. What if the street has no "oneway" tag, but some of the segments do? --Bartv 14:40, 23 October 2006 (BST)

Duplicates

I've noticed we have amenity=grave_yard as well as landuse=cemetery - which should be used? Jon 12:34, 24 November 2006 (UTC)

I've been using both based what I consider to be common usage: a 'grave_yard' is that area surrounding a church (or other place of regular worship) used for burials, whilst a 'cemetery' is a piece of land used for no other purpose than burials or cremations. -- Batchoy 14:02, 24 November 2006 (UTC)

When I set up the original Map Features we did not have area support in the db and thefore it did not cover tags for areas really at all. Thus the amenity=grave_yard would really be intended as a label for a node. Where you find this type of inconsistency or duplication its best if you can apply both tags (if you think they both apply) until a better tagging framework gets completed and we can weed out unnessary duplication. Blackadder 14:20, 24 November 2006 (UTC)

Why not get rid of the underscores?

Underscores are used in programming languages such as C because a variable must be made of a single word. Here, in OSM, tags are just key-value pairs and there is no reason to bother with underscores. I think multiple-word keys and values should be allowed. Keys and values are represented as strings in the XML file anyway, so it probably doesn't make any difference to the software developers. For example, instead of

<tag k="railway" v="light_rail"/>

why not just say

<tag k="railway" v="light rail"/>

without the underscore?. Novem 23:18, 26 November 2006 (UTC)

tagging historic town gates

a) in Germany we have many history town gates at the borders on the old city walls. They should deserve a own specific tag.

My tagging proposal is:

key: "historic"

value: "Town gate"

b) How to tag the railway station building. It is no node on the railway tracks, however an area or a node beside the railway track.

Proposal:

key: "amenity"

value: "railway station building"

c) How to mark a Museum for non-historic items? E.g. a museum for modern arts or playing toys?

Is there still the key "historic" appropriate?

key "historic"

value: "museum"

Pease comment.

Josy 21:01, 6 December 2006 (UTC)

Archive 2007

Photo key

idea here

perhaps the wrong wiki? use waterway=stream for the 'ditch'. Osm@floris.nu 13:53, 24 June 2007 (BST)

I am adding photos as and when I find them and have spare time. If anyone has better/different pictures that they think better explains the feature feel free to replace mine. pray4mojo 20:28, 8 July 2007 (BST)

What about chapels and small temples etc.

Shouldn't it be distinguished between (big) churches etc. and chapels or small temples as they exist in many places? At the moment there is only "place_of_worship" option and "denomination".

I agree, but also, when walking, the distinction between a church with a tower, church with a steeple etc is also very useful to confirm your location. --Hadleyac 01:57, 8 June 2007 (BST)

Please add comment to any tags, even obvious ones

Could someone please add comments to every tag shown on the list, even obvious ones? example: whats the difference between hotel, motel, guest house, hostel? what's a water_park? what's an icon? --Gerchla 23:09, 12 January 2007 (UTC)

I have added Links to Wikipedia for hotel, motel, guest house and hostel.

Josy 13:55, 14 January 2007 (UTC)

Waterway-->Stream

Hello,

I've seen Waterway, Stream used by some people - is this an official tag? if so shall I add it to the list?

Ta C2r 08:01, 20 February 2007 (UTC)

Housing Estates

How should I tag housing estates? I have rather a lot of them locally and I'd like to do them consistantly. I've made each tower block a node but I'm wondering whether they'd be better off as areas so that their shape can be rendered. Maybe this would enable estate maps to be produced? What should I be tagging them as? Thanks. Secretlondon 00:20, 15 March 2007 (UTC)

I've started making large tower blocks areas and tagging as landuse=residential and is_in=Aylesbury Estate. I think it probably needs more than this to identify high rises, maybe number of floors? I'd love to know how other people are making area/town centre/estate maps Secretlondon 06:11, 16 March 2007 (UTC)

In supplement to Confusing Table

The tables are confusing furthermore. We have some different variants. I propose to modify every table as follows. The columns "Feature" and "Feature Type" should be removed in every table, not only in the table of "Highway". The columns should have the same width, if possible. The colors should be more friendly. Besides, the phrase "one of the following" is confusing and should be replaced. I ask for comments:

Waterway

For the "segment" and "way" elements only one key "waterway" is allowed with one of the following values.

Key	Value	Comments
waterway	river	River (Other languages)
waterway	canal	An artificial open waterway used for transportation, waterpower, or irrigation.((478) Other languages)

For the "node" element only one key "waterway" is allowed with one of the following values.

Key	Value	Comments
waterway	aqueduct	A bridge carrying a channel for supplying water. (Other languages)
waterway	boatyard	Boat yard - a place for constructing, repairing and storing vessels out of the water.

OnTour 19:33, 29 May 2007 (UTC)

• Go for it, It can always be reverted if people want. I don't think this page needs those 2 columns, and generally making it more beginner freindly is a good idea. Ben 22:52, 7 June 2007 (BST)

• go for it. i like your simpler design better. however, as some features can apply to nodes/linear/areas, i would still like to keep that information. --spaetz 14:08, 12 June 2007 (BST)

• The new preview you can see here.

OnTour 21:40, 12 June 2007 (BST)

• Looks nice, but theres now differences between it and the current page!...match them then switch. I don't think the rendering column is needed. It's up to whoever makes the rendering program how they render it, this page is talking about tags. I suggest removing that column therefore. Ben 00:44, 13 June 2007 (BST)

• The column "rendering" is helpful to show small examples. Therefore, this should keep, but are renamed as "example".--OnTour 06:22, 16 June 2007 (BST)

• OSM doesn't have a renderer of its own. OSM is the map data. Renders are independent projects. So I disagree. Ben 16:20, 10 July 2007 (BST)

Landuse Farm

Does this area include ordinary farmland (agriculture, e.g. wheat fields), or only horticultural areas? I was wondering because the description is a little bit ambiguous. Longbow4u 07:48, 13 June 2007 (BST)

• as I understood, it includes ordinary farm land (wheat, cows, etc), so yes use it for that. --spaetz 12:27, 13 June 2007 (BST)

• • Thx, :-) Longbow4u 15:01, 13 June 2007 (BST)
    • I think the opposite to Spaetz. landuse farm should only be use for the "core-area" of a farm. e.g. the area with the farm-house, the barn, greenhouses, stables,... often surrounded by fences. To tag every field where cows or sheep are browsing would be insane and would debilitate the meanings the tag could give. For instance 60% of the non-urban area in Germany is in a agricultural use. Tagging this all as farm can't seriously be the way  ;). For that we should create other landuse-tags. e.g. "landuse=pasture" and "landuse=cropland" --Cbm 05:19, 30 December 2007 (UTC) Example: http://www.informationfreeway.org/?lat=50.79846636502359&lon=6.085032186501197&zoom=17

Why photos?

This page Map Features should give a overview of the possible features. I think photos are not very helpful in reality. Besides, this page will be bigger and bigger. The column photos should be deleted. Only in difficult cases an additional Example should be used.--OnTour 21:45, 8 July 2007 (BST)

• I was only adding photo's to the page as I had seen some on there already and read a little on the mailing list. The biggest help as far as I can see is for people who want to clarify what each type of feature each tag is for. Maybe to see where a secondary road becomes a tertiary or, for people who want to know what a feature is in there own language (supposing it has not already been translated). pray4mojo 23:16, 8 July 2007 (BST)

• It's right, photos are very helpful for a clear understanding. It should be used for this, however, only the column "Example". This should be applied reasonably. So, pictures or graphics should use only where an appropriate requirement consists. If necessary, not helpful render graphics can be removed. OnTour 22:14, 10 July 2007 (BST)

It could be usefull to have the related Key page (e.g. Key:highway) explayining in depth the different option with a small gallery of real matching cases --EdoM (Parliamone) 08:31, 13 July 2007 (BST)

moving amenity=supermarket to shop=supermarket

I moved supermarket back into amenity key. IMO changing things already in map features should be avoided if at all possible. It creates a lot of work.

• Someone has to modify all the programs that use OSM data to understand the new key.
• Someone has to tell users to use the new tag instead of the old one.
• Someone has to go through the OSM data and change all the old tags.
• Someone has to repeat the previous step at regular intervals well into the foreseeable future to catch new additions of the old tag.

Remember there are a lot of users that don't subscribe to the mailing lists. I suspect there are also lots of users rarely return to Map Features after they have memorized the core set of tags they use. These users will continue using the old tags without realizing the tag has changed.

If this has been discussed somewhere I have missed, please revert my changes. --Thewinch 21:31, 11 July 2007 (BST)

Moving supermarket from amenity to shop was approved in the process of adding the shop key - and was recently discussed on the mailing list by me to be sure. Maybe editing on this page without any discussion on the list should be avoided? A simple note on the mailing list by you would have been nice.

Basically, you're saying that once a feature is in this page, it never can be changed to anything else - which is a complete stand still. Newbies often do complain that the tagging scheme is strange and not documented at all. So keeping the current state is probably not such a good idea as it seems and waiting until doomsday so that things you describe changes won't make things better, as new user become familiar with bad concepts and new data is added the wrong way.

What is all the programs to understand the new key you mean? mapnik, osmarender, mappaint and potlatch - that's it for my part. I've already changed mappaint accordingly and Tweety might change osmarender and mapnik soon. Yes, users will have to learn some new tags, some more changes are gonna come in the tagging scheme, not only from me. BTW: changing this page only says that you shouldn't add anything new with these tags, the old tags may still be there - the renderers will understand both, at least for a while. Ulfl 04:46, 13 July 2007 (BST)

Removing approved map features

• amenity = townhall

Someone deleted amenity=townhall. It was a proposed feature.

Why all this voting overhead if everyone is free to change the map features as he/she like! I changed it back. Start an disapprove process if you like to remove something, but not simply do it! --audifahrer 10:05, 12 July 2007 (BST)

Tag 'cheatsheet'

I've produced a cheat sheet of the tags I tend to use, in a way that makes most sense to me. Wondered if anyone else thinks this approach is useful too? Frankie Roberto 23:56, 30 July 2007 (BST)

Areas

Many of the points of interest, such as almost all of the amenity tags (excluding some of the really small ones like phone box and post box), and the shop, tourism, and historic tags, should allow either a node or an area to be defined. Now that we have Yahoo satellite imagery, it is often possible to trace the area of buildings. A few, like aeroway=terminal, actually are rendered by Mapnik and/or Osmarender (see Heathrow Airport). Andrewpmk 22:59, 25 August 2007 (BST)

Wather-Bus Stop

Were i find, or how is the code from a watherbus or public-boot stop?--Bobo11 21:29, 17 November 2007 (UTC)

What is a derelict_canal ?

As of latest Potlatch 0.6 there is a derelict_canal not yet explained in the wiki - what's that? --katpatuka 08:00, 27 December 2007 (UTC)

An old, closed (out off order) canal, or an fragment of a hystoric canal. --Bobo11 00:24, 28 December 2007 (UTC)

Mixed Use?

Quick question: Are there any plans to include a "Mixed Use" variant of land use, as there are already residential, commercial, industrial, etc. already included? "Mixed use" being an area specifically zoned for a mix of residential/commercial/light industrial or similar. On many zoning maps, I've seen a mixed use area shaded as brown. --Bridger987 14:51, 28 December 2007 (UTC)

Edit: Another, more obscure zone that I discovered is included in the town that I live in is "Office/Industrial," which, I assume, is a mix of low-density commercial and industrial. --Bridger987 15:10, 28 December 2007 (UTC)

Most Shops / Many Other Items Never Get Rendered?

Most shops (and many other tags) have no icon in the render column. It seems that these only appear in the editor, but don't show on Mapnik / Osmarender at all (not even a generic dot, like in the editor or text name). This means that the vast majority of shops and many other objects that get put in the map data, never appear on the maps. For example, I just mapped all of the shops in one town, however most of them don't show anything at all - not even a dot - where 95% of these shops have been entered. Even using the tags here.

Could we get some small, inobtrusive, generic icon used (like just a small square) so people can at least hover the cursor over it and see the name and shop type?

Heck, if it's a case of needing an icon, I'm happy to design one myself. It's just very discouraging to gather so much quality data, and have it be invisible, presumably just because it lacks an icon. RoadLessTravelled

Indeed, there should be at least some generic icon. I think the hover thing is a little bit more complicated (and might only be accomplished using open layers), but should be implemented in the near future, too. Shops are one of the most important, most mapped POIs I guess. --Scai 08:59, 8 August 2010 (BST)

Linear fords

Hello, we've got a node highway tag for a ford, but what to do in cases where the ford is so long it should be a segment?

examples include -

Furneaux Pelham TL438283 to TL437294 Standon (TL393221) Much Hadham - TL430187 to TL432186

C2r 19:57, 21 February 2007 (UTC)

Shop

The two examples of 'shop' – butchers and bakers – seem poorly chosen and no guide to how to tag up other kinds of shop. For a start, they use a vernacular phrase that is actually a possessive. Fetch me sausages from the butcher's, with the apostrophe, is the correct form, being short for butcher's shop. Regarding the bakers, the same criticism applies, as well as the fact that not all bread shops bake their own bread, so not all are really baker's shops.

I propose we use a new form that declares what are the main goods that may be bought in this shop, so we'd have:

• shop=bread
• shop=meat
• shop=tools|kitchenware

The older form would be ok too, and butcher and baker should be acceptable, I think, as well as newsagent, off_licence, etc.

I still long for a way of setting multiple values for one key. Shops are in great need of this – I sneaked in an example on the 3rd item above. A well-maintained region would enable shopping routes to be produced, given a shopping list, perhaps by a hypothetical local shop support group or anti-supermarket project. — Lorp 22:12, 22 February 2007 (UTC)

How would this scale to a town centre? We clearly need a supermarket tag, street market, off license (alcohol shop), internet cafe, food(in general), fishmongers, pound shop? ethnic food shops (if so which ethnicities..) etc Secretlondon 17:41, 11 March 2007 (UTC)

How about options for tagging "Farm shop" - a shop selling local produce normally able to tell you exactly where and how everything is grown or reared. And also "Farmer's market" a weekly or monthly market where storeholders sell locally grown, reared or manufactured goods. Useful for those with a eco consciense or for those wishing to support local trade and agriculture. --Farrpau 10:30, 4 May 2009 (UTC)

highway/steps

Should we standardise this to point downwards (or upwards)? Morwen 16:55, 21 March 2007 (UTC)

I say standardise upwards. Steps are comonly seen as a thing to take you up a level so up makes more sense to me. Milliams 16:19, 22 August 2007 (BST)

If the ways at the ends of the steps are on different levels then isn't that enough? --Korea 20:03, 24 August 2007 (BST)

I take steps up a level and down a level in almost exactly equal proportion. I think having the ends of the steps at different levels would work better, in practice, because for most ways the direction is irrelevant, and so it's easy to just ignore the direction of your ways. Looking at the map, there's no way to tell whether the arrow indicates conformance with a standard or simply the direction that the original mapper took when mapping. Having the ends of the steps in different layers is much more intentional, and therefore meaningful. --Eulochon 20:19, 1 May 2009 (UTC)

All stairs I've seen in technical drawings/blueprints has a arrow in upward direction. I vote to follow this standard practice in OSM as well. To use the layer of the connecting ways (or start and end node) is a bad idea as these might be changed without considering the adjacent stair. Gorm 00:18, 15 June 2009 (UTC)

Sailing Club / Rowing Club

Around here we have lots of sailing and rowing clubs. They do not fit with leisure/marina or leisure/slipway because not all have marinas, and they are generally private anyhow.

So I would suggest two new values under leisure; leisure/sailing_club leisure/rowing_club

I have dotted a few around Poole Harbour http://www.informationfreeway.org/?lat=50.68178760245478&lon=-1.9949515313304635&zoom=12&layers=0B00F00

This could be a problem for primarily motor boat clubs, eg Royal Motor Yacht Club in Poole harbour, but if you went for Yacht club rather than Sailing, it would not suit dinghy sailing.

An alternative would be to put them under sport, and for example the Weymouth Sailing Academy would fit this, but I prefer the leisure one.

--Hadleyac 01:54, 8 June 2007 (BST)

Tourist routes

In Poland, and I suppose that in other countries too, there are defined routes for hiking and cyclinge marked with colours. Coulour makrs are painted on the trees along the route. The thing is that a route may, and most often does, comprise several phisical ways. For example you walk along a unpaved track (tracktype=grade2) for a mile and then you turn into a footpath in a forest. And both ways carry the same mark, e.g. red.

There are two categories of such routes: footrouts and cycleroutes. Footroute may contain any way (except of motorways and other noisy types), it may be in rocky mountains, sometimes they may even be impassable (in the spring or after heavy rain) while cycleroutes are defined generally along rather compact roads.

So what we need is to define and mark with colours routes going along phisical ways and mark it as footroute or cycleroute.

See De:Germany_roads_tagging#Wanderwege_und_Radfernwege (sorry in German, but contains useful links to pages in English). Btw: Yay to the ingenious tourist way tagging system used in several mid- and eastern european countries. Unfortunately, in German it was overcome by glyph babylon.

Ipofanes 10:44, 19 September 2008 (UTC)

Building = yes

Shouldn't building = yes be added to this page? It is widely used, and both Mapnik and Osmarender render it. Andrewpmk 22:59, 25 August 2007 (BST)

Yes it definitely should. I moved it to man_made, working around the memory-issues when loading this page. --fuesika 22:44, 9 March 2008 (UTC)

Sports Icons

here are my concepts of the sports icons: they ar inspirated by the symbols of Olympia 1972

• Football http://j-po.de/download/osm/fussball.png
• Swimming http://polchau.de/josias/download/schwimmen.png
• Tennis http://polchau.de/josias/download/osm/tennis.png

replace .png with .svg to see the svg-files.
I think it would be nice if every sport icon has the same layout. so you know that it is a sport icon. --Josias 09:47, 17 December 2007 (UTC)

In the Wikimedia-Commons an user has build PD-symbols for the olympic sports, this symbols could be used without copyright restrictions. (I would build SVGs from this symbols.) --Hedavid 11:49, 29 December 2007 (UTC)

There appear to be SVG versions in the Commons now: f'r'instance this one for rugby... could they not all be adopted? -- TomJ 2101, 13 Feb 2008

Sport

What about martial arts? Is there/should be a category for those? For example Karate, Taekwondo, Judo and others.

How about VORTAC (VOR, DME, NDB)

Should a VORTAC maked as man-made = beacon? I would prefer the official Symbol (a hexagon with three black rectangles on threesides)? --Arbol01 16:32, 30 December 2007 (UTC)

Internationalization of the map features page

The map features page is already translated in different languages (e.g. Fr:Map_Features, De:Map_Features, Cz:Map_Features, etc...) and it's increasing. I think it would be really helpful for the translators if we could use a template to keep the page up-to-date, sharing the same list of approved tags. Of course, it's not the idea to have the whole page as a template but just one template per table (e.g. a template for highway). I made a small page testing the concept here. The template is here.
With this template, the english Map Feature section for highways would just need this:

{{Map_Features:highway}}

My proposal is that the template provides the text in english by default. Thus, the effort for the original writers is not so important, the english text is writen only once and if local countries do not translate immediately, the english text appears by default.
Note that I already submitted this on the talk mailing list but nobody answered. Is this idea so "incongruous" ? Please put your comments. -- Pieren 23:00, 4 January 2008 (UTC)

A shit, seems like I must have read over your mail. We both had the same idea with this approach.

I think it's a good idea to use a template for the tags on the Map Feature pages. At the moment it's a big hussle to keep all the translated pages synchronized.

My solution for this "problem" can be found here Template:Aerialway Values Overview and an example here Key:aerialway.

I should read the discussion pages more often, to avoid doing things twice --Etric Celine 13:52, 7 January 2008 (UTC)

Hmmmm

So there's a second problem to try to solve. Duplicated definitions appearing on Key pagess, and on the main Map Features page. This could also be solved with a template structure, so it's worth thinking about at the same time as the internationisation issue. And Etric Celine's template tackles this. but...

Template:Aerialway Values Overview has a major problem, in that editing the text of the tag definitions, becomes quite tricky. It's hidden away in a template, and intermingled with the text written into other languages.

Another thought is... You could take it down a level further. Individual 'Tag' pages (such as Tag:natural=coastline) could contain the short text description of what that tag means, and that text could be transcluded into the Key:natural page and finally on to Map Features. On the one hand that's quite elegant. On the other hand it means you have to go even deeper to find where you can actually edit the text.

Meanwhile Template:Map Features:highway (Pieren's idea) keeps the text content all still editable on the Map Features page. Nice and simple. But... it only tackles the internationalisation problem. There is still the problem that the 'Key:Highway' page is going to have a duplication of a whole section of the Map Features page.

Hmmmm. Template structures make my head hurt. It's possible some bespoke developed solution will solve this better, so that this ceases to be a wiki organisational problem, and the duplication/internationalisation problems to go away. Something like Tagwatch perhaps, but the trouble is we need features for democratically deciding on tags (and descriptions of tag), which is... what the wiki does best.

-- Harry Wood 16:34, 7 January 2008 (UTC)

you say ">There is still the problem that the 'Key:Highway' page is going to have a duplication of a whole section of the Map Features page.". But this can be easily fixed by my proposal : just call the template Template:Map Features:highway twice (at least in english, it's only one line), once in the "Map Features" page with the default short description, once in the "Key:Highway" page with additional sections for more comments, examples, combinations with other keys, etc . -Pieren 11:35, 8 January 2008 (UTC)

I think he means that you need to copy the translated descriptions which are not shown by default. Anyway I don't believe all the Key:something pages will be translated in the "near future" so this shouldn't be a problem. At least we have the Map Features pages sorted and the same structure on the Key pages even if they are just in english.

The only thing I like to change in your template is the missing link to the corresponding tag page (Tag:highway=motorway for example), then I'm fine with it and think we should use it.

The Tagwatch solution is something that does not work out really. The problem here is, that the script can only show descriptions which are parsed from the related Wiki page. At the moment this means again copy&past and try to synchronize. I've started a small approach to parse every existing [[Tag:Key=Value]] page to get this information, but this is still not perfect.

The best thing is to draw a huge line between "democratically approved" tags and a list of every tag which is in use. In general everyone is allowed to enter any tag he likes and as long as he writes a documentation about it, we can show it either with Tagwatch or any other approach. The Map Features should then list just the "approved" tags. --Etric Celine 13:00, 8 January 2008 (UTC)

JOSM presets don't seem to agree with the table here, need to get the food and drink thing more consistent

I'm adding ammenities (or are they something else?) in Paris, and have realized that we we have a couple of problems with food and drink tags.

1. The JOSM presets don't quite line up with the recommended tags here
2. I'm finding the sub tags either too expressive, or not quite expressive enough. For example, I'm trying to add "Bar Hemingway" at the Ritz, and the choices I find are "nightclub", "café", "biergarten", and "pub". Well the Hemingway doesn't really fit any of those (I guess pub comes the closest". So I'm calling it a "bar". I hope that's OK.

What we finally decided to do with this stuff for Wikitravel was to just put lump them all, including coffee and tea joints under "drink". I don't know if that's appropriate here, but I do think that if we're going to be really expressive about the tags then we also need to have a longer list of choices to try to fit things into. Does that make sense to anybody? Thanks! -- Mark 16:46, 13 February 2008 (UTC)

I think we at least need to distinguish between coffeeshops/tearooms, and bars. Often people will be looking for one, and the other won't do at all! - Notmyopinion 12:38, 18 August 2008 (UTC)

oneway

The following tags are ambiguous and thus should be deprecated:

1. >

or

1. >

Some people might think that cars may drive on these streets in both directions, while other people might consider these streets a oneway street, where driving is only allowed against direction of the arrow vector.

Josy

So what should you name streets that you know aren't oneway. This is kind of important in cities where the norm is oneway streets. Erik Johansson 07:13, 12 May 2008 (UTC)

Both of this exapmples are helpful to override default for motorways, trunks. For most other types of highways this is not necessary, as is by default. As for cities where most streets are oneway you still need to tag them while there will not be supposed mechanism to override defaults for particular area (and that seems to be hard)--LEAn 16:46, 6 June 2008 (UTC)

Agree. means a street is bidirectional. I'll clarify that in the description of the tagging scheme. Someone seems to have already removed ''. This is ok. Josy

Realistic Speed "limit"

We've got our "maxspeed" and "minspeed". Great for route calculation. However, on a lot of the roads that im mapping currently, it is impossible to actually reach "maxspeed", simply because the roads are "twisty" and small.

maxspeed=80 kmh but the realistic speed is 30-40 kmh.

So how about adding a "realisticspeed" tag or "recommended_max" or something.

It would be a great addition for any route calculation software to be able to read this tag and exclude roads that slow down the trip.

Logix

I know what you mean but I don't think that it is a good idea to add reccomended speed as this depends greatly on the driver and the for instance a motorbike could go down the road at 50km/h while a lorry or a car with a trailer on the backmay be able to go no faster than 30km/h. However if Open Street Map were to add a driving directions feature in the future it could be good for giving estimated journey time because at the moment most sites, e.g. Google Maps, Windows Live Maps, give unrealistic times.

Ballysallagh1 17 August 2008

Of course one possible use of the OpenStreetMap-data is directions, and turn by turn navigation. If the openstreetmap.org web page has directionas or not is irrelevant. --Henriko 23:19, 4 May 2009 (UTC)

I'm not sure a real-speed-tag is the correct way to do it. To really make this good you need real statistics from real vehicles, so you get differnt speeds at different hours of the day. Im some towns the real speed is 100 km/h in the middle of the night, and perhaps 5 km/h in the morning, but only in weekdays. And perhaps that kind of data is best kept in some other database separately?

Without this kind of data I still think it would be possible to make a time estimation algoritm semi good, by using data that is already in the map anyway. Perhaps sharp turns can affect the time. Perhaps if the road is narrow. The occurance of speedbump, of course. Number of lanes. Type of surface. Etc.

And as Ballysallah pointed out. All this is vehicle dependent. A Ferrari might care less if the road bends than a truck. A Land Rover might care less of speedbumps than the others. A motorcycle will care less if the road is narrow.

--Henriko 23:19, 4 May 2009 (UTC)

Water, land and coastlines

I just tried it out with many combinatons. This is the result which works with Mapnik and Osmarender:

Only coastlines need the correct direction. "Coastline" islands on "coastline" water must be drawn counter-clockwise. They don't need layer tags.

The mapping direction of water and land does not matter. But "land" islands must have a higher layer than "water" water.

BTW: Osmarender renders "water" and "land" with Bezier curves, but "coastline" polygonal. --Plenz 06:19, 28 February 2008 (UTC)

bus_stop vs bus_halt

Using josm, i've been proposed either bus_stop or bus_halt (in "highway" spot). I'd consider a "bus_stop" being a place where a bus could sporadically stop for a long moment (i have a friend who is a bus driver, and there are such places where they can take their break and wait for a while) whereas i'd consider bus_halt any plae where the bus lets people step in and out... If i am wrong in my understanding, shouldn't then bus_halt be deprecated? What's the global proportion of use of those?

ThaNerd

Personally I would say a bus_halt is not British English. I certainly haven't heard that phrase used. Smsm1 10:45, 25 March 2008 (UTC)

Identify the oneway tags

Some tags are oneway sensitive, means that reversing the order of nodes will impact the meaning of this tag (e.g. of course but also rounabout, coastline, etc...). I would propose to mark such tags in the Map Features page with a symbol like this : . This would allow later the editors to identify such tags and, for instance, raise (at least) a warning message when a user tries to reverse a way tagged with this key.Pieren 21:11, 24 March 2008 (UTC)

I see no problems with it, you can just do it.. If someone complains then we can have a fight over it. Erik Johansson 07:15, 12 May 2008 (UTC)

I think that it's a good idea as well. Ballysallagh1 17 August 2008

Simplify highway link

I would like to simplify the highway link types like motorway_link, trunk_link,...

I would just use "highway = motorway" and "link=yes". So it wouldbe possible to use "link" in all highway categories, e.g. for a "bypass" lane in a roundabout. I think it is also better to use for a routing software. Also it could be used for railroads. Garry

Really good idea. I support this. --Dspies 21:11, 18 October 2008 (UTC)

Talk page clean-up and expectations

We should clean-up this talk-page (some are obsolete, some could be moved into other pages). And most important, we should also explain/discuss what the Map Features page should be, and what should go somewhere else, e.g. into related pages like the Tag:key=value pages. --Pieren 10:49, 5 June 2008 (UTC)

To adress the clean-up problem, I created an archive page where I moved all discussions not commented upon since 2006. If this is a workable solution (multiple archive pages will most likely later be needed), I can move somewhat later discussions as well (perhaps June 2007?). Note that there might be discussions on the archive page that would better be stored in conjunction with the topic itself. In that case I suggest moving the actual discussion to the talk page of the topic, but to leave a link trail on the archive page.--sanna 07:59, 6 June 2008 (UTC)

Column "render" or "Mapnik"/"Osmarender"

UrSuS replaced the column "Render" by two colums "Mapnik" ãnd "Osmarender" in some tables. I don't think it's a good idea. First, we cannot show everything in one page (we have the subpages Tag:key=value for such examples, pictures,etc). Second, why limiting to two renderers ? Next will be Kosmos and so on (potentially no limit). Third, we have to keep the size of the page (amount of KB) under control (it was an issue earlier this year before the wiki software was updated). So, between the two extreme positions where people would like text only (no pics, no imgs at all) and others with all renderers examples, my proposal is to keep a single render column with one example and move other rendering samples into the related Tag pages. --Pieren 12:32, 6 June 2008 (UTC)

I agree. And just to add a note about Kosmos: there aren't any "official" rendering styles for map features in Kosmos, so there isn't any point in adding samples to the Map Features page. --Breki 16:32, 6 June 2008 (UTC)

Ok, I got it, but then we need to include just on type of redenring: Mapnik or Osmarender, becouse curretnly render examples are messed. Ursus 13:40, 9 June 2008 (UTC)

Hmm, now is 2010 and we still don't have decision about this. I suggest Mapnik, because it's default view on map in osm.org. If there will be no objections I can replace images. Yarl ✉ 13:41, 4 March 2010 (UTC)

And why Mapnik ? Osmarender is also present on main page and is rendering much more things than Mapnik. The remark I gave two years ago is still valid. If Kosmos is a bad example, we can take 'cycle map' or any of the dozen Cloudmade rendering styles. It is important to understand and explain over and over again that OSM is a geodatabase and Mapnik is not THE osm map but just a showroom. --Pieren 13:52, 4 March 2010 (UTC)

OK, I understand you. I'm not a big fan of Mapnik, rather some of Cloudmade styles. I just, like Ursus, don't like current mess. Page "Main Features" is very useful for beginers (of course not only) and vast majority of them use Mapnik. And I think they should know what is render-able at the moment, because they can be disappointed seeing no effects. Yarl ✉ 20:44, 6 March 2010 (UTC)

Using the right tags (Mandolyn)

Hi!

How should I tag a road like http://www.jockheck.de/album/photo.php?photo=593&exhibition=7 . Is this a track or a unclassified highway?

Feel free to add the photo to the samples list if usefull!

ciao Detlef

I cant really be sure of the scale on the image. I think this would be "unclassified" since it looks like there are 2 roads with grass in between. A track is when the grass part in the middele, goes under 1 car, and the left and right side wheels go on each side of the grass.

It is clear to me that this is two concrete tire tracks, separated by grass. This is definitely an odd case -- but I guess it's most likely track because it requires driving over the grass to let cars pass in opposite directions.--Speight 00:19, 13 May 2009 (UTC)

Swimming pools

I see water_park under amenities, but not swimming pools. Many smaller towns in the U.S. will have a public swimming pools.

RickH86 15:13, 11 July 2008 (UTC)

Wrong picture?

I think that the picture next to Trunk Link is wrong as I think it should be next to Primary Link. I would just like a second opinion before I change it.

• I think the picture for traffic_calming=table is not a good one. I would classify that as a hump (long bump). It's not even a car legth. --Japa-fi 14:50, 30 October 2008 (UTC)

I took it from Wikipedia (http://en.wikipedia.org/wiki/Speed_table). --Magol 14:16, 31 October 2008 (UTC)

Wrong picture (shop=furnace)

The picture for Tag:shop=furnace shows a fur shop, not a furnace shop. If it were only used in the main map feature page I might have corrected it, but it also seems to be used in many nationalized map feature pages. I don't suppose there's an easy way to recursively change it? I wouldn't want to delete it because someone might want to use it for a Tag:shop=fur tag. --tesche 18:16, 1 November 2010 (UTC+1)

Zoom level of map features

I am looking for information which map feature will be rendered at which zoom level. For example on zoom level 0 (world) streets are not printed. When you zoom in at some point they "appear". Some features seem to be even more tricky as they are not visible on low zoom levels and on very high zoom levels. For example names of cities are neither printed on "world" zoom level (0) nor on zoom level 18. I understand that this makes sense as it improves the picture quality and readability. But who defines this and where is it written down? Thanks for help. --Spuerhund 14:56, 27 August 2008 (UTC)

On the OpenStreetMap mapnik layer the mapnik stylesheet specifies at which level items appear and disappear. File is located here: http://svn.openstreetmap.org/applications/rendering/mapnik/osm.xml . Feature or Bug reports can be reported here: http://trac.openstreetmap.org/ Login using OSM login, add new ticket, assign to steve8@mdx.ac.uk

osmarender layer is controlled it's stylesheets here: http://svn.openstreetmap.org/applications/rendering/osmarender6/

-- Firefishy 01:01, 28 August 2008 (UTC)

Thank you very mutch for your help! --Spuerhund 12:31, 3 September 2008 (UTC)

Oceanographic information and adding roads

What are your thoughts on adding oceanographic information to make openstreetmap also a nautical chart.

OpenStreetMap is a wiki :-) Add what you would like to see on a map. Firefishy 01:05, 28 August 2008 (UTC)

Next thing I wonder is how to add and split roads. When I add a road, it immediately disappears again. On one place the roads are faulty connected, how do I change this? I mean, there is a 3-connection between roads, and two going out are the same (has the same name) and the third one is another road. However when I mark them the highlight in the wrong way, and I don't understand how to remedy this. --Ravn Hawk 16:20, 27 August 2008 (UTC)

Forum or a mail list would be a better place for this question. Firefishy 01:05, 28 August 2008 (UTC)

How map a turnstile?

How is a tunstile to be mapped? My suggestion would be...
... to map the way as highway=footway  oneway=yes and a point at the position of the turnstile as highway=gate . --Gypakk 23:02, 31 August 2008 (UTC)

bank with an atm

this page says : "a bank (for a bank that also has an ATM, use amenity=bank and atm=yes)". but there's also amenity=atm, so in the end we have at least two ways to tag atms... seems confusing. also, this supplemental tag is not listed on amenity=bank. i think amenity=atm would be better tag to use in all situations. marking it as connected to the particular bank branch could be done with relations (if required at all).

It's not currently possible to tag this way anyway (you can't use the same tag twice) Circeus 02:06, 23 October 2008 (UTC::

People have been using semicolons forever to give a tag 2 values: amenity=bank;atm spaetz 13:37, 5 November 2008 (UTC)

I know, but using the tag twice doesn't work is all I meant. And though I haven't tested it, I suspect "amenity=bank;atm" would result in nothing at all being displayed. Circeus 03:27, 6 November 2008 (UTC)

Rendering rules

I think there needs to be an additional section on this page detailing how features and tags are interpreted, or should be interpreted, by the renderer. Or if not here then on one of the development pages. I've seen Mapnik (for example) draw a layer-1 footpath over a layer-0 secondary highway and then on the same page draw a layer-0 tram line over a layer-1 trunk highway. From this and other things it's obvious that neither tag type or layer number are being used as the primary sorting heuristic to the drawing algorithm. It's also not clear how borders and bridge outlines should be rendered...they can't be drawn together by tag type because otherwise different highway type borders would overlap each other. And they can't be drawn together by layer since it's obvious that the map itself isn't drawn by layer alone. A little bit of clarification here would save developers like myself hours of trawling through source code and script files.

What about these?

I have some shops that I don't know what keywords to use.

• Clothes: primarily or only clothes
• Department stores: Household items, but not (or almost no) furniture
• Furniture+: Furniture but also sell a lot of other stuff, like appliances, computers and televisions
• Beauty: Shops that sell beauty supplies but don't do hairdressing
• Copy: Shops that do photocopying and sell paper (and related) supplies
• Communication: Stores that sell mobile phones and/or satellite dishes and subscriptions (I know that this is a proposed keyword, but JOSM doesn't recognize it and it doesn't get rendered by any of the map renderers so it must not be official)
• Storage: Places meant for (temporary) storage

— Val42 20:52, 25 October 2008 (UTC)

amenity=shelter is proposal

Is it right that only tags are listed on the map feature page that are approved? I saw that amenity=shelter is listed here, but it is just in proposal state (http://wiki.openstreetmap.org/wiki/Proposed_features/Shelter), no vote started. So I think it's not a official tag und should not be exist on the map features page. Don't know if I'm right, but if I am, it should be removed. I think it's not good if anybody list proposed feature here if they are not approved. I'm not very familiar with the way how tags get into the map features list. Can anyone tell me if my point of view is right? S.A.L. 16:34, 16 November 2008 (UTC)

If it's in widespread use (I haven't checked the tagwatch) and without conflicting uses, then it's good and ok to have it on the map features until someone proposes something that requires it to be replaced by something else. Alv 17:16, 16 November 2008 (UTC)

But doesn't that mean, that we do not need the proposal state with the voting option, because map features can be inserted without any voting? A further problem is, that this way a proposal will be a proposal forever, because noone can see the need of a discussion if the proposed feature is already listed in the map features. It makes a proposal senseless S.A.L. 22:58, 16 November 2008 (UTC)

amenity=shelter looks to be voted on by old standards. I would say, yes, it needs to go to vote on the new standards before being added to the map feature page if not already there. looks like User:ULFL has been adding features based on usage rather than being voted to acceptance by the comunity.--Nickvet419 00:57, 17 November 2008 (UTC)

Proposal for all map features sub-templates

It would be very helpful if the all the map features templates (e.g. highway) contained a bit of wikisyntax to optionally disable feature descriptions, e.g.:

{{#ifeq: {{{motorway:show}}} | no || 
|-
| [[{{{highway:key|key:highway}}} | highway]]
| [[{{{motorway:value|Tag:highway=motorway}}} | motorway]]
| [[Image:Mf_way.png]] 
| {{{motorway:desc|A restricted access major divided highway, normally with 2 or more running lanes plus emergency hard shoulder. Equivalent to the Freeway, Autobahn, etc..}}}
| {{{motorway:render|[[Image:Rendering-highway_motorway_neutral.png]]}}}
| {{{motorway:photo|[[Image:Motorway-photo.jpg | 100px]]}}}
}}

instead of the current:

|-
| [[{{{highway:key|key:highway}}} | highway]]
| [[{{{motorway:value|Tag:highway=motorway}}} | motorway]]
| [[Image:Mf_way.png]] 
| {{{motorway:desc|A restricted access major divided highway, normally with 2 or more running lanes plus emergency hard shoulder. Equivalent to the Freeway, Autobahn, etc..}}}
| {{{motorway:render|[[Image:Rendering-highway_motorway_neutral.png]]}}}
| {{{motorway:photo|[[Image:Motorway-photo.jpg | 100px]]}}}
|-

That way someone using the individual templates could call {{Map Features:highway | motorway:show = no}} to hide that specific entry. I'm asking for this because I'm translating the page into Icelandic where a lot of these features -- like motorways -- simply don't exist.

--Ævar Arnfjörð Bjarmason 06:03, 4 January 2009 (UTC)

Icelanders may also want to map other countries, so it might make more sense to explain what the feature is and that it isn't used in Iceland. That's how it is done in some other languages. --abunai 00:16, 15 January 2009 (UTC)

Isn't there a motorway being constructed (at least it was summer 2008) between Reykavik and Keflavik? Gorm 00:59, 15 June 2009 (UTC)

Map Features: Re-organizing

Hi, Natural Resources Canada shows a nice organization of all the types of data... earth sciences. See http://wiki.openstreetmap.org/wiki/CanVec_OSM_Map_Features#CanVec:_Theme_keywords Perhaps the different features can be placed into these main categories or a variation of it? Purpose: To make it easier for users to find the information they are looking for. --acrosscanadatrails 10:57, 16 January 2009 (UTC)

Clarification for charge=*

I find this tag very useful for route planing, but I believe it needs a bit of clarification. Usually fees are different for different kind of vehicles (eg. motorcycles, small cars, small cars with trailer, trucks), so maybe it would be useful to have charge:truck=*, charge:car+trailer=* and leave general charge=* for all other, not specified vehicles. For example in Germany where only trucks have to pay Maut on motorways it may look like this

charge=0
charge:truck+e2+a6=20 EUR (Euro 2 truck with 6 axles)

It seems to be too long comparing to other tags, so maybe charge=(truck+e2+a6:20 EUR)(car:5 EUR)0 - but this instead would be hard to keep in order...

Please share your comments Uazz 19:15, 15 April 2009 (UTC)

This page needs a legend

This page needs a legend for the element icons ( ), preferably linked to the appropriate wiki page for that element. They may be obvious to experienced users, but I'm new to OSM. I can guess, but am not sure of what they mean. --Hrynkiw 22:09, 27 April 2009 (UTC)

These icons are used on many different pages, so a legend on Map Features wouldn't solve the general problem. Would it work from an usability perspective to add links to the icon templates (Template:iconWay etc.) so you could click on them for an explanation, e.g. the appropriate section on the Elements page? (I'm not entirely sure how to implement that technically, but assume it is possible.) --Tordanik 11:34, 28 April 2009 (UTC)

Why not just change the alt-text for the images to say 'path', 'node', and 'area'? I'm not a web developer, but I'm assuming that would be straightforward. --DanHomerick 05:32, 25 September 2009 (UTC)

Done, see template {{Icon}}. Yarl ✉ 18:43, 26 February 2010 (UTC)

noexit

Discussion moved: Talk:Key:noexit

Inline Skating

Is the tag "sport skating" valid for inline skating too? If yes it would make sense to add it in the comments field.

The idea is to mark all roads where in-line skating is possible cause of street quality. Maybe the quality would be an interesting attribute (bad - very good) ???

Mapping regular streets as sport facilities does not feel quite right. I think it is better to try classify roads and foot paths by the quality of its surface more generally. Unfortunately there is still many discussions about how to grade this, and few decisions. But I think the best right now is to use smoothness=excellent. See Key:smoothness. --Henriko 23:48, 4 May 2009 (UTC)

I think the smoothness tag is not enough to describe if a road is suitable for inlines skating. Even if the smoothness are excellent, the road also needs to have good visibility, no 90 degree corners, no intersecting roads at every 25 meters etc etc. I would also be glad to have a tag that clearly shows how suitable it is for inlines skating. For road bikes, the problem is basically the same. Any suggestions of how to solve this? --zvenzzon 20:25, 16 Sept 2009

You can see that stuff just by looking at the map layout, no need for a special tag. --Hawke

Inclines

Highway=incline and highway=incline_steep haven't been defined properly, and are probably not verifiable. As Key:incline has been created maybe the old tags should be moved to deprecated features. Peter James 21:10, 6 June 2009 (UTC)

Totally agree on this. I would even go so far as to suggest have all occurences (bot-work?) of "highway=incline"/"highway=incline_steep" replaced with "highway=road" and "incline=incline"/"incline=incline_steep". Not pretty, but conserves the information while highlighting the situation in JOSM validator etc. Gorm 00:04, 15 June 2009 (UTC)

Abutters

Key:abutters is on both Map Features and Deprecated Features. If the tag is deprecated should this be indicated on Map Features or just removed? Peter James 21:40, 6 June 2009 (UTC)

cycleway track

The picture attached to "cycleway track" is misleading. --Keichwa 01:56, 24 July 2009 (UTC)

In OSM terms the grass and trees in this picture are sufficient to make the cycleway a separate track. If it were a solitary cycleway "in the woods", as in the map example, people would eventually draw it separately as a highway=cycleway. It could be a bit clearer (but I don't know how that would fit in the table) but at the moment both cases are shown, and they are then better described at Key:cycleway. The cycleway=track becomes redundant once the solitary cycleway is drawn as a separate way. Alv 06:30, 24 July 2009 (UTC)

Fire lookout towers

There are many hundreds (if not thousands) of Fire Lookout Towers sprinkled all over the planet. Most are no longer in use, since the advent of telephones and population increase. OSM really needs to recognize these types of features natively. More info here for those nostalgic for older times and things: http://en.wikipedia.org/wiki/Fire_lookout_tower --Oisact 20:51, 8 August 2009 (UTC)

Map key

The map key that's shown on the map if you click the button in the left, doesn't show tertiary, unclassified, residential or service... It also shows "unsurfaced", which to my knowledge isn't rendered anymore. I'm sure it's pretty outdated. Remember that new users or people just browsing the map probably use that one. Perhaps it should be updated and also maybe localized? /Grillo 18:54, 17 August 2009 (UTC)

picnic-site

i see tags about 'picnic site' and i can't see Icons on the map? --Abonino 07:03, 30 August 2009 (UTC)

bad link?

"well, see tracktype=* for more guidance."

the link go on a new side, but 20cm down i see a head of chapter "Tracktype".

Bad link?

regards --Abonino 07:06, 30 August 2009 (UTC)

The template with the highway values isn't only used on Map Features, but also, for example, on Key:highway. It's easier to use the same text for all pages including the template, so we need a link that works everywhere, not just on Map Features.

This shouldn't be a problem as the tracktype section on Map Features and Key:tracktype are identical, too - they also use the same template. --Tordanik 08:09, 30 August 2009 (UTC)

Speed cameras

This symbol doesn't show up in the osm renderer. Shouldn't this tag be changed to reflect the discussion here:

http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:enforcement

leisure=park vs. leisure=nature_reserve

The page describing Tag:leisure=park has the suggestion that it should be for municipal parks, and that nature_reserve should be used for natural parks like Yosemite (in California, USA). But it also has a TODO, and doesn't give the air of being settled. Furthermore, there's not even a page describing what a Tag:leisure=nature_reserve is. Has the community decided on what the dividing line between parks and nature_reserves should be?

In the US, we have an official designation called 'Wilderness Area' that is applied to some parts of some parks. A 'Wilderness Area' indicates that roads can't be built there, and that even the number of backpackers heading into the area is limited. It's a reserve for nature in a fairly strict sense. But then there are 'parks' like Big Basin Redwood Park, which is a large park that is kept natural, but which doesn't carry the extra protections of a Wilderness Area. Nature_reserve, or park? What's the main criteria for separation? Is it the amount of protection for the reserved nature, or is it just how natural the area appears to be? --DanHomerick 05:50, 25 September 2009 (UTC)

Pier

Is the picture of man_made=pier correct? It looks very similar to leisure=marina. The UK idea of a pier is more as something like [1] or [2]. Is the UK or US usage intended? Proboscis 15:41, 25 September 2009 (UTC)

They're overlapping things, aren't they? A marina is an area, that may include many piers within it. So, when looking at a pier, you might very well be looking at a little part of a marina. We could choose a picture of a pier that isn't used as a part of a marina (like the ones you linked to), but perhaps the initial confusion is good, so long as we clarify the overlapping nature in text. --DanHomerick 15:52, 25 September 2009 (UTC)

Urban Streets

As a new OSMer, I'm puzzled regarding how to tag some urban and suburban streets. In many cases, they are not tertiary (they don't really go anywhere), they are not residential (no residences within many blocks), and they are not unclassified (often four or six lanes wide as opposed to the two lanes in the unclassified guideline). Surely this has been addressed and I'm missing it. But, it seems that there needs to be something like 'highway=urban_street' or 'highway=retail_access' or similar to address these streets. TIGER data in my city (Fort Worth, TX) seems to arbitrarily set them as either unclassified or as residential. Granted, in a few cases there is a high-rise condo building present, but access to that isn't the primary purpose of the street. Or have I missed a solution that is already in place? turbodog 10:30, 1 October 2009 (UTC)

It would be helpful to post a link to an example of the streets. My first reaction to your post is, "6 lane roads that don't really go anywhere? Wow, everything IS bigger in Texas..." =) --DanHomerick 04:50, 2 October 2009 (UTC)

Well the example I was thinking of is only four lanes (plus parking lanes), such, as Main St. in Fort Worth (haven't figured out how to add map links yet). It's nine blocks long. It's currently classified residential, but there are no residences, nor does it lead to residences. Unclassified seems a bit of a put down for Main St. in a Texas city that's pushing a million people :-), but that's probably the way to go under the current system. -- turbodog, 11:09, 3 October 2009 (UTC)

I've done some more study in the wiki and various Talk sections, and decided that functionality rather than physical characteristic is the primary, although certainly not sole, driver in highway keys. So, for the case I have described, i.e., a wide urban street that doesn't extend past the confines of a relatively small urban area, the "proper" (if there is one) way to key it, since there is no "urban_street" key is as "unclassified" with "lanes=4". Concur?turbodog, 06:02, 4 October 2009 (UTC)

Sort order

Some sections of map features are sorted alphabetically and some are organised in a different order, either by frequency of use or by importance or just a bit random? Can we review what would be best in each case? Here is a list of the main ones:- PeterIto 10:40, 23 October 2009 (UTC)

• Highways - listed in road hierarchy with motorway first - looks good to me (PeterIto)
• barriers - a bit random as far as I can see - would alphabetical be better (PeterIto)?
• Cycleway - in a logical order - looks fine to me (PeterIto)
• Waterway - in order of usage with most common at the top - looks fine to me (PeterIto)
• Railway - in order of usage with most common at the top - looks fine to me (PeterIto)
• Railway:Additional features is alphabetical - looks fine to me (PeterIto)
• Aeroway - in order of useage with most common at the top - looks fine to me (PeterIto)
• Manmade - is in alphabetical order
• Leisure - is a bit random to my eyes - I suggest alphabetical would be better as there is no clear order of importance (PeterIto)
• Amenity - some sub-sections are alphabetical, others look a bit random from my perspective (PeterIto)
• Shops - are in alphabetical order
• Tourism - are in alphabetical order
• Historic - was nearly alphabetical, I tweeked it to make it strictly alphabetical (PeterIto)
• Landuse - I (PeterIto) have just made it alphabetical but it has been suggested that this is not helpful
• Military - Almost alphabetical - I suggest it should be strict alphabetical (PeterIto)
• Natural - Alphabetical
• Sport - Alphabetical

There are some other smaller sections not mentioned in the list.

Time and date based tags

It would be extremely valuable if OpenStreetMap offered a way to attach time and date information to locations. This would mean that OpenStreetMap could replace commercial publications such as Time Out and other listings magazines.

I'm not familiar with OpenStreetMap tagging, but ideally you could put something like this:

amenity=cinema
name=phoenix
film=The Men Who Stare At Goats(length=2.00, times=2009:12:12:19:30, 2009:12:12:21:30, 2009:12:12:23:30)
film=Fantastic Mr. Fox(length=2.00, times=2009:12:13:19:30, 2009:12:13:21:30, 2009:12:13:23:30) 

..which would show that 'The Men Who Stare At Goats' is showing on the 12th December 2009 at 7.30pm, 9.30pm and 11.30pm. And 'The Fantastic Mr. Fox' is playing at the same times on the next day.

There is already the 'opening_hours' tag, but it is not suitable. Also, in the above example, I'm not sure you could insert two 'film' tags, since the second would remove the first.

Is anything like this possible?

--Cali 15:22, 7 December 2009 (UTC)