User:EzekielT/deleted proposals

Welcome to the deleted proposal repository!

This repository documents deleted proposals.

Armory/armoury

See also Talk:Key:military#military=armory for additional comments

armory
Proposal status:	Abandoned (inactive)
Proposed by:	Robert Horning
Tagging:	`military=armory`
Applies to:	area
Definition:	An armory, small reserve military training center, or depot not part of a larger military base
Statistics:
Rendered as:	*
Draft started:	2009-06-20
RFC start:	2008-09-20
Vote start:	*
Vote end:	*

Proposal

Adding the tag "military = armory" to be used for smaller military installations that can be normally found on a neighborhood or smaller town basis. These buildings tend to be used by reserve components of the military (and the National Guard units in the USA) and usually don't have barracks or significant extended facilities like larger military bases.

Rationale

Note, this is not a recruiting station or something for public relations, but an actual training center for military purposes, and tend to be owned and operated by the national governments on some level, even if used for other community purposes. Yes, a recruiting station can be sometimes found at these places as well, but that isn't its primary purpose.

This can also include facilities like a logistical depot or some other similar military facility... again, usually used by reserve military forces where the equipment is intended to be kept relatively close to part-time military personnel who have other occupations and roles in the community.

There are many equivalents to this world-wide by many nations.

Tagging

Discussion

Armory or Armoury?

The Canadian definition is with the 'u' http://en.wikipedia.org/wiki/Halifax_Armoury but wikipedia has it with no 'u', but the pictures and definition as the 'u' http://en.wikipedia.org/wiki/Armory_(military)

military=armoury; (for the point) building=yes; military=armoury; (for the area) A building used by the militia. (Natural Resources Canada - CanVec Map Features Definition Code 2010030 (point) and 2010032 (area)) --acrosscanadatrails 00:18, 4 March 2010 (UTC)

Voting

academic
Proposal status:	Abandoned (inactive)
Proposed by:	*
Tagging:	`landuse=academic`
Statistics:
Draft started:
Proposed on:	2007-11-05

Rationale

For OSM activities by the scientific community, see Research.

This would include areas that are college or university campuses. These are sometimes part of the centre of a city or town with a mixture of public property and property owned by the institution, or they are specific premises with a physical border.

Tags

This proposal introduces a single *new* key and value pair:

* landuse=academic

Existing tags could probably be used to add information, for example:

* name=John Moores University

Rendering

Possibly light grey with the institution name in the middle.

Discussion

The tags amenity=university and amenity=college can and are already used for campus areas. See their description on the Map Features page. So I think this proposal is redundant. --Cartinus 11:58, 9 January 2008 (UTC)
indeed it is, this is unnecessarily complicating things. please provide a rationale why the existing tags are not suitable, or it will be removed form the proposals page Myfanwy 22:15, 4 February 2008 (UTC)

Abandoned highways
Proposal status:	Abandoned (inactive)
Proposed by:	Bilbo
Tagging:	`highway=abandoned` Data item
Applies to:	line
Definition:	Similar as railway=abandoned, but for highways
Statistics:
Rendered as:	perhaps highway rendered by dotted line
Draft started:
Proposed on:	2008-02-22

See Proposed features/Abandoned for an active proposal.

Rationale

highway=abandoned

The course of a former highway which has been abandoned and the previous surface is removed or so grown over so it is no longer visible.

However, some signs of the previous road still remain visible in the landscape.

Basically similar to railway=abandoned, just in this case it is highway that was removed and got disused, not railway

Same as in railway=abandoned: Designation not to be used if the feature has been turned into another use, eg cycleway.

Applies to

Lines

Rendering

Highway with dotted lines, with similar width as highway=residential

Comments

Please use the discussion page for comments.

Voting

Cottage
Proposal status:	Abandoned (inactive)
Proposed by:	*
Tagging:	`tourism=cottage`
Applies to:	node
Definition:	"In modern usage, a cottage is a dwelling, typically in a rural, or semi-rural location..." (wikipedia)
Statistics:
Rendered as:	icon representing a cottage

Comments

Is this not already covered by the existing but fairly new Map Features tourism=chalet? "The term chalet is used in the hospitality industry to describe detached cottage(s) with self-contained cooking facilities and/or bathroom and toilet facilities." MikeCollinson 18:36, 5 July 2008 (UTC)

4th Dimension
Proposal status:	Abandoned (inactive)
Proposed by:	peter.doerrie
Tagging:	`=`
Applies to:	Annotation
Definition:	Scheme to tag the time relevant aspects of features
Statistics:
Rendered as:	?
Draft started:	2009-03-24

Proposal

I propose to develop a tagging scheme to represent time-relevant informations of features. This could include existing tags (like openening_hours) but will also feature new tags, for example for construction/destruction dates.

Rationale

OSM is in some parts of the world a very detailed image of what features exist at that point at the moment. This is fine and enough for the normal use of a map (which is orientation in space), but there is more potential. Every time a street changes its course, a sandbank changes its position or a house gets demolished this feature will be deleted by the next mapper passing that area. Of course it is still somewhere in the Database (or is it not?) but there is no information available about its exact duration of existence and/or since when it existed. But exactly that will be of great interest for coming generations.

At the same time, there are permanent and existing features that have time-relevant aspects: Opening hours of shops, duration of construction sites or time-limited structures to name a few.

To make a tagging scheme of this kind work without implications for all the rendering and editor programs, it should be considered in the API.

Example

Imagine a researcher who wants to study urbanization. At the moment all he can do is compare maps, verbal accounts and photos of an area from different times. But all these (maybe with exception of the verbal accounts) are just snapshots and do not show a real process. All the researcher can do is to interpolate between the snapshots and hope, that he has enough data to actually do that. Enter the new tagging scheme. By writing special rendering rules he can visualize the exact progress of a certain area in time, providing that the area was sufficiently mapped from the beginning. All the mappers would have to do for that, is to apply the scheme to every feature they would otherwise just delete.

Another application could be the mapping of the age structure of buildings in a town. When we come to the point where every single building in a given town is mapped in its outlines in OSM, it would be very easy to generate age-structure maps for this place

Tagging

The tags sorted by different categories

Creation of permanent features

The type of creation meant here differs from the time the feature got added to the database. It refers to the date a permanent feature (street, building, shop, etc.) was physically created.

construction_date=yyyy-mm-dd

Time / date limitations of features

There are already some tags in use, that should be kept:

opening_hours=* for the days / hours a feature will be open to the public

Others should be changed or introduced:

There are already some tags for the limitation of access restrictions. At the moment there are six different tags. I suggest to reduce them to one, with the same syntax as opening_hours=*.

restricted_hours=*

Abandoned / Disused features

Features that still exist today (and can be seen), but are no longer in use and / or abandoned. There is already a good proposal for a abandoned=yes key and we have a disused=yes key. All we need to do is to add time-relevance to them:

The beauty of this is, that we can now track the "lifespan" of a feature from creation over disuse and abandonment to deconstruction.

Start date and end date

I suggest we concentrate on using start_date=* and end_date=* for now. Frankie Roberto 16:31, 29 May 2009 (UTC)

Applies to

Everything

Rendering

Depends on the specific tag.

Comments

Please comment on the talk page

bus_turning_point
Proposal status:	Canceled (inactive)
Proposed by:	manfredbrandl
Tagging:	`highway=bus_turning_point`
Applies to:
Definition:	Define a point where busses can turn by pushing back
Statistics:
Rendered as:	probably no
Draft started:	2016-03-24

Canceled

This proposal is canceled in favor of the proposal for turning_point

Proposal

I propose a new value for the key "highway" to represent a point where busses can turn by pushing back. This is for situations where there is no turning circle and no turning loop.

Rationale

The bus turning point is usually not a destination in itself, but gives usefull information for bus drivers that it is possible to turn the bus there with pushing back if there is no turning circle. I think there are at least many thousand bus turning pionts on the world, but there may be more. There is a similar tag for waterways [[1]]

Examples

http://www.openstreetmap.org/node/4077011329 and http://www.openstreetmap.org/node/2749414252

Tagging

highway=bus_turning_point

Additional Tagging

Add maxlength=* if there is a known length restriction for turning vehicles.

Applies to

All Bus Turning Points where pushing back is neccesary

Rendering

maybe no

Comments

Please comment on the discussion page.

Castle

castle
Proposal status:	Canceled (inactive)
Proposed by:	telegnom
Tagging:	`historic=castle` Data item
Applies to:	area
Definition:	should also be avaliable as area as castles are usually buildings
Statistics:
Rendered as:	building with the icon 'castle' and the name of it
Draft started:
Proposed on:	2009-01-12
Vote start:	*
Vote end:	*

See historic=castle

This proposal was (probably) to change the castle definition to allow areas (Unnecessary to create a whole proposal page about such minor thing, but anyway historic=castle does now say areas too, so... )

A better implementation Relation:route exists. See also Proposed features/trailblazed, osmc:symbol=*.

Marked trail
Proposal status:	Abandoned (inactive)
Proposed by:	*
Tagging:	`marked_trail=color (red, green, blue, yellow)`
Statistics:
Rendered as:	This feature should indicate, that this segment is a marked trail with some colour signs e.g. tourist signs/marks

Proposal

There are many marked trails in the world which are designated for tourists, cyclists etc. and IMO there is no way, how to mark these trails in OSM yet. So I am proposing this simple tagging scheme to note a colour of the marked trail. If this proposal is found good, there is a chance to differentiate between symbols used to mark the trail such as circles, stripes etc. File:Tourist sign.jpg

Tagged segments/ways should be rendered at highest zoom only with a line colour specified in value. Maybe it should be rendered with some offset from underlaying way or just a semitransparent line. If segment/way carries information in ref or name tag, this should be also displayed (number of cycleway, name of the trail [e.g. in Slovenia]).

Any comments very appreciated as this is really worldwide spread feature and I don't know much more marking systems than in Czechia, Slovakia, Slovenia.

Discussion

I ML'ed about this a while ago, and no answer seemed to exsist so some tag is needed. I've stuck route= for the moment on a few trails, but the problem is when many trails share 1 bit of track/road/path. The colour is also inportantly usually, as trails are marked in the UK with colours usually. So Many names, many trails, and many colours may exsist on the same way. Would it be OSM accepted to be adding many values to one key, in; this; sort; of; way? Ben 16:03, 8 June 2007 (BST)

I think this should be done with repeating tag - value instead of concatenating with ; because parsing this xml is much more harder and xslt transforms are much more complicated and the information is not structured as it has to be in xml. So a segment with blue and green on it should IMO look like this: ...

 <tag key="marked_trail" value="green">
 <tag key="marked_trail" value="blue">

... I think there should not be problem with xslt transforms or so... What are others opinions? Kubajz 09:08, 10 June 2007 (CEST)

AFAIK in other countries (e.g. Germany), they do not have one system, but many systems, which are combining color and shape of the mark. On the other hand, in Romania for example, all marks were red, but different shape. So, we should think about this issue too. In Czech republic we have four colors only, however, special "educational" trails are available too, not speaking about marked cycle ways (for example in Sumava).

IMHO marked_trail is all right and sufficient, but rules or examples for usage of this attribute should be defined too, e.g.:

If there is only colored system in your area:

red
blue
green
yellow

If there is only ,,shape`` system in your area:

cross
circle
square

If there are both systems in your area:

red-cross
blue-triangle

--Jachymc 09:58, 10 June 2007 (BST)

Might this be better done with the Proposed features/Trail and Proposed features/Network features? --Hawke 00:14, 12 June 2007 (BST)

Proposed trail seems (to me) to be something else, as it replaces current features (and I don't like it), this is something that uses existing ways, so it is both trail or footway and marked_trail. Proposed network is something virtual, not visible on map. --Walley 12:29, 27 June 2007 (BST)

Trail and networks are really something different. Jachym, personally I don't like mixing apples and pears (apples and oranges etc.) as it leads to confusion. After a week you simply do not remember whether color or shape comes first and what is the separator. It is not so flexible. Imagine, in one country is decided to change shape only system to color system and you have to rebuild whole system. Another reason to separate these two tags is the number of symbols needed to display in map. In your version it is c+s+(c*s) - where c is number of colors, s number of shapes - or very special logics to construct from names. In my proposal you need only s shapes, that can be colored using any color you need (if I imagine the use of SVG or similar) or in the worst case (c*s) using static bitmaps - even though it is better about c+s symbols. --Kubajz 12:52, 2 July 2007 (BST)

I don't think this proposal is the same as a trail or network. Its for routes/paths/suggested walks etc, its not defining phisical attributes, and its not a network really. Usually round me the forest routes are a colour and have a name. And there are frequently many on 1 path. It is posible to add the same key twice but not by using the interfaces most people use, so I don't think Kubajz's earlier proposal would be the way to go, unless I'm not understanding that correctly. Maybe we need a key that can be varied. so route=, route_2= route_3=. And asuming route_3=xyz then we could add the colour to name seperate. so; xyz_name="oak trail"; xyz_ref="A1"; xyz_colour="blue". This would work the same as a road, where you add the details under each tag, but it would allow many routes on 1 way, by having a semi variable key. (xyz:name= may be neater). Ben 01:34, 12 July 2007 (BST)

Numbering keys is terrible thing IMO. OSM decided to use XML as a backend, so I think we should use all benefits it serves. I think all editing tools can be updated to conform with multiple keys of the same name. Imagine you have route_1, route_2 and route_3 on one way (even if I would just define three ways sharing the same underlaying segments) and then you need to delete route_1 - this leads to extra mess - the number loses its substance and therefore the routes can be numbered as anybody is willing. This theory leads to avoid numbering key names as this does not carry additional information. Finally defining 999 xsl templates for 999 routes is another silly thing. --Kubajz 10:39, 16 July 2007 (BST)

In my view you only have real world features like pathes,tracks,trails which are described by highway=footway or highway=bridleway, etc. There is discussion to replace these 'highway-tags' by route=trail;foot=yes;horse=yes,etc. I am in favour of this change, but we shouldn't discuss this here. All the 'marked routes' you want to catch in your proposal will if the work is done well all have representatives in highway=.....-tags with additional info on permissiveness. I can imagine you use your signs to fill access-tags like foot=yes or foot=permissive. But IMHO that's all info these signs offer. I don't see why I should know that I will encounter round green marks on a track or trail. I also don't see why you couldn't put these under the network key.rvanderh 22:38, 4 August 2007

you need to know that you will encounter round green marks on a track or trail because they show you where the trail leads. This proposal is not about physical ways, it is about those marks. It simply says no matter what highway type are you walking on, you are on trail marked by that symbol or color. The network tag can be probably used to mark all marked_trails as network=czech_marked_trails for example.--Walley 11:01, 14 August 2007 (BST)

All markings along routes are ment to know 'where the trail/route leads'. There is imho absolutely no differencte between markings along a visual trail and markings along a non-visual trail. In cities I absolutely need the GR/LDP-markings to guide me a route through the cityrocks. Please explain me what is (in essence) the difference between a marked route in a city and a marked route on a mountain ? When I loose the marks I am totally lost in both places.

yes, this is the reason why we need this:)

The essential difference between highway footway etc. and marked_trail is, we need to show this dumb line in a map. I don't know whether this proposal is the best, but it is feasable. If someone thinks it is really unnecessary, tell me a way to place this information into map. I would like to point out, that one marked trail can in fact run on many types of surfaces, therefore it is not appropriate to say one physical way is one marked trail. If we reuse segments of current and create a new way (the marked route) we need to tag it. Propose something feasable before you say this idea is bad. P.S.: Czechia is a country with the highest density of marked trails on the world :] If anybody from abroad wants to see a marked trail in real, I can accomodate him for free in Prague :]--Kubajz 11:53, 7 September 2007 (BST)

the best way should be, to mark the ways in a route-relation --Cbm 06:51, 28 December 2007 (UTC)

I made an example for usage of this tag: https://wiki.openstreetmap.org/index.php/Outdoor https://www.openstreetmap.org/?lat=50.2094&lon=11.6057&zoom=13&layers=B0TT--Gerchla 13:09, 19 January 2008 (UTC)

We do need something for marked trails, and this should work:

marked_trail_red=yes marked_trail_green_slash=yes

.AFAICS it should not cause xml problems, and it can handle multiple marks on one path (common!). Pavel 00:54, 30 January 2008 (UTC)

Some info about the system in Hungary: shapes and colors are shown on the map with abbreviations. So a trail with a green stripe, a yellow cross and a blue triangle would be marked (abbreviations translated): "G Y+ B▲" (stripe is the default shape). This is not very friendly to foreigners, who have to look up the meaning of the letters, but otherwise works quite well ;). For representing this in OSM, I favor one of the earlier proposals:

 marked_trail=green;yellow-cross;blue-triangle

This is simple, and similar to how multiple references on the same way are represented. --Szmi 08:18, 18 February 2008 (UTC)

In Germany there are often trail markings with more complicated images, e.g. a black deer on white background or a red boar on yellow and so on. Is there a way to tag these? --R kleineisel 09:06, 7 January 2009 (UTC)

At http://www.freemap.sk we have experimental use of slightly modified version of this proposal with tags like this:

 <tag key="marked_trail_green" value="yes">
 <tag key="marked_trail_blue" value="yes">

It allows to use modification for marker shapes

 <tag key="marked_trail_green" value="circle">
 <tag key="marked_trail_blue" value="square">

also using tags for nodes on marked trails with maps or stands

 <tag key="marked_trail" value="map">
 <tag key="marked_trail" value="stand">

Result is here (try to turn on/off "Turistika" layer on layer switcher) --Dido 11:24, 18 March 2008 (UTC)

---

I think it would be easier to use something like highway=trail (or highway=hiking) and additionally an optional key like marking=red;green;whatever. That way it would be easier to create a hiking map like the cycle map, also incorporation the keys Key:sac_scale and Key:trail_visibility.

Furthermore the hiking trails would not show up on normal street maps, like they do it now (because they are tagged with keys like highway=path) --Uhu01 05:08, 9 September 2008 (UTC)

IMHO marked trails a a group of ways. All ways belonging to this trail should be tagged as usual, eg. with highway=foot tracktype=grade4 etc. Then they should all be added to the relation. The relation itself will then hold all properties belonging to the marked trail, eg. name, type, operator, symbol. It all exists. We must simply use it. So: no need for an 'marked_trail'.

key	value	element	comment	Vorschlag von	Status
`marked_trail_green=*`	bar		Grüner Strich auf weißem Grund	rudimap (siehe Proposed_features/Marked_trail)	proposal
`marked_trail_yellow=*`	dot		Gelber Punkt auf weißem Grund	rudimap (siehe Proposed_features/Marked_trail)	proposal

--rudimap 13:46, 23 June 2008 (UTC)

USA Marked trails explanation

In the USA, we use a colored vertical stripe painted onto trees next to the trail. If there is no tree, we use rocks or install a signpost. The stripes are 1" wide by 4" high, and are often painted on with a paper stencil. This is pretty standard across the entire United States. If a trail is marked with this standard, it usually means that some government agency or group of people care-for and clear and upkeep the trail.

There are often times many unmarked dirt paths cutting off from these marked trails. Maps that you get from government agencies (state parks, federal parks, local parks) will usually only show the marked trails, and they will color the trail lines on the map in the color of the tree marks. So if you have a trail with purple markings on the trees, the maps that show this trail will color the line purple. There are no limits on which colors to use. I have seen dozens of colors, but mostly limited to the main distinguishable colors.

It is common to see two trails combine for some portion. So you might have trees marked with both orange, and white, or even a third color, then later on they will diverge to their own trails.

Needs in the USA

There is a definite need in the US for maps to be able to show what official trail you are on, and also to distinguish the managed trails from the many unmanaged smaller paths.

Currently, all trails / paths show visually the same in openstreetmap.org and mobile apps like 'Offline Topo Maps'. This makes it difficult to follow a managed trail and to know where you are. There is no visual distinction between a marked, managed trail and small unofficial or animal paths that are also marked in OSM. Often, many people want to stick to main trails.

Solution Opinion I like the solution given in Proposed features/trailblazed, and it seems active and followed and cared-for. However, I do not understand how this will equate to a Visually different line on standard OSM maps to highlight these managed trails, over non-managed paths. Everything blends together and there are hundreds of trails and no one knows where is most popular and safe to go.

--nyeates1 14:50, 24 May 2012

Nodes: Signposts

Regarding the node values,

 <tag key="marked_trail" value="map">
 <tag key="marked_trail" value="stand">

there are now proposals for tourism=information, information=map/guidepost, hiking=yes that should cover this. See Proposed features/Information — vibrog 07:28, 9 January 2009 (UTC)

thank you for pointing me to this proposal, we are going to use this more general tagging schema --Dido 19:36, 10 January 2009 (UTC)

A simpler tagging scheme for marked trails

I believe a simple trailblazed=yes-scheme will be adequate.

One can imagine extensions for it, such as trailblazed:color=*, trailblazed:symbol=*, trailblazed:number=* (but that can probably be a relation route).

Yes, and the relation route can be tagged color=*, symbol=*, ref=* -- vibrog (talk) 09:37, 4 August 2015 (UTC)

When combining trailblazed=yes with operator=*, that will probably indicate color and symbols as operators have norms for marking (In Norway: DNT use blue paint for trailblazing, NCS code S 1040-B). Using operator here may lead to a problem though, if there is a groomed ski trail in the winter, because there are different operators for the seasons. -- vibrog 06:04, 27 May 2009 (UTC)

For skiing pistes, I've later learned that piste:trailblazed=yes can be used -- vibrog (talk) 09:37, 4 August 2015 (UTC)

There are a lot of mountain trails in Norway which are only marked by cairns (Norwegian: varde), which is a pile of stones. What tag shall I use?

Use trailblazed=yes on ways, add ways to a route or network relation with symbol=cairn. -- vibrog (talk) 09:37, 4 August 2015 (UTC)

Bag shop

Bag shop
Proposal status:	Obsoleted (inactive)
Proposed by:	Math1985
Tagging:	`shop=bag` Data item
Applies to:
Definition:	Shop selling bags
Statistics:
Rendered as:	A bag
Draft started:	2014-01-01
RFC start:	2014-01-01

Rationale

Currently the tag shop=bag (612) is used in parallel to the less used tag shop=bags (120). I propose to agree on the defacto standard (the singular).

Definition

A shop selling bags. Bag shops usually focus on hand bags, but might also sell other kinds of bags, such as backpacks, travel bags, etc. In addition, some related leather accessories, such as wallets, might be sold.

Image

Fitness centres

gym
Proposal status:	Canceled (inactive)
Proposed by:	AndiG88
Tagging:	`leisure=gym`
Applies to:	,
Definition:	A place, typically a private club, providing a range of facilities designed to improve and maintain physical fitness and health.
Statistics:
Draft started:	2014-07-30
RFC start:	2014-07-30

This is a cancelled proposal to map Gym / Fitness centre's with the tag leisure=gym

See Gym / Fitness centre for the set of alternative tags/proposals

The content of this proposal has been archived to avoid confusion with the current version of the documentation.

View proposal content

Arena

Arena
Proposal status:	Canceled (inactive)
Proposed by:	Acrosscanadatrails
Tagging:	`leisure=arena` Data item
Applies to:
Definition:	an enclosed, large surface used for sporting activities
Statistics:
Draft started:	2010-03-04

This proposal was cancelled by its author.

Use one of the approved tags leisure=stadium, leisure=pitch or leisure=sports_centre instead.

Description

Status: proposal
Proposed-by: User:Gerv
Proposal-date: 2008-02-03

Proposal

There is a general "access=<access_type>" tag on Map_Features#Restrictions. There are also a number of "<vehicle>=<access_type>" tags for specific classes of vehicle. However, there is none for "motor_vehicle=<access_type>" because that's the general case, covered by the general tag.

It seems to me that on waterways, where you find boats, "boat" is the equivalent of "motor vehicle". So having "boat=private" seems redundant given that we have "access=private". I suggest deprecating it in favour of the more general tag.

Discussion

With highways the highway type denotes what the default "vehicle" is for that way:

Bicycles for highway=cycleway
Pedestrians for highway=footway|pedestrian|steps
Horses for highway=bridleway
Motorvehicles for all other types

Next it is assumed that the default "vehicle" has access unless noted otherwise. This is probably because the mappable roads without access are a minority.

For waterways you get a completely different picture. My guess is that the majority of mappable rivers is non-navigable. Hence the use of boat=yes to denote navigability. The tagging of boat=private is just shorthand for boat=yes plus access=private. You can maybe get this removed from the map features page with this proposal, but I think this shorthand is so convenient, that you will see people keep using it. Therefore any renderer or other application better keep having a "rule" for it.

--Cartinus 23:28, 4 February 2008 (UTC)

I agree with the first half of your logic. But, by analogy, the default "vehicle" on a canal is a boat, and it also has access until noted otherwise. I doubt people are going to tag every waterway=canal with boat=yes, because it's obvious. A canal was built to take boats, just as a road was built to take motor vehicles. <shrug> I guess I don't care too much about this, it just seemed a consistency cleanup.

Gerv 09:21, 16 February 2008 (UTC)

I don't agree that access=* implies motor vehicles. In fact, to me it implies all vehicles(+pedestrians and equestrians). Any exceptions must be explicit. For waterways, consider a swimming area, which might be boat=private, swimming=permissive (Leaving aside that there is no key 'swimming' as yet, I assume you take the point). The only reason that there is no access key for motor_vehicle is that no one has seen a need for it, presumably because all the roads that do not allow motor vehicles are other special classes (like bridleway)

--Hawke 22:19, 18 February 2008 (UTC)

OK, then. Proposal abandoned.

Gerv 18:33, 5 March 2008 (UTC)

Voting

...is not open yet.

Bike shed

It has been proposed that this page be replaced by a haddock. (Discuss)

It has been proposed that this page be deleted or replaced by a redirect. See the discussion page for further information.

amenity = bikeshed

Description

A place for parking bicycles. If it ever gets built, that is.

Group: amenities

Used on these elements

Useful combination

Status: undefined

More details at taginfo

Tools for this tag

taginfo · AD · AT · BR · BY · CH · CN · CZ · DE · DK · FI · FR · GB · GR · HU · IN · IR · IT · LI · LU · JP · KP · KR · NL · PL · PT · RU · ES · AR · MX · CO · TW · UA · US · VN
overpass-turbo
OSM Tag History

Note for the avoidance of doubt: This page is a work of satire and is not intended to represent a serious tagging scheme. Two minutes' inspection of the contents would confirm this to any reasonable reader, but it seems I need to be over-careful. There are a great many wiki pages of a lot less merit that do not get flagged for deletion within hours of their posting, so I have taken the liberty of removing the flag from this page and replacing it with this clarification. Anybody adamant that this page has no merit is welcome to open voting on the subject...

A bikeshed is a building, shelter or other structure intended to provide safe parking for (usually pedal) bicycles. Due to the great range of possible design characteristics and the great complexity of any planning process, few actual bikesheds have ever been built.

How to Map

When mapping a bikeshed, it is vital to consult the community to the widest possible extent. It is often unclear whether use of building=* is merited and, if so, which key value is most appropriate. colour=* is a hugely important attribute, and at least a week should be allowed to decide which colour to specify, how to allow for the effects of weathering (hence the need for prevailing wind and sunshine info), whether to specify decimal RGB, CMYK, web-style Hex or pantone, not forgetting the option of whether to spell it color=* instead.

When specifying opening_hours=*, be mindful of the fact that not all mappers are in the same time zone as you are. Where you cannot have the decency to keep your bikeshed operational 24/7 it may be more sensitive not to build the damn thing in the first place.

Special care should be taken in determining the orientation of the bikeshed : so as to correctly identify the front of the bikeshed. Sometimes this can be done by taking point counts of discarded cigarette ends in locations around the bikeshed. A botantical quadrat square is useful for this purpose. When the bikeshed is symmetrical it may be necessary to show the orientation using one or more relations.

Rendering

YAGNI

Tags

Key	Value	Comment
amenity	bikeshed	Tag either the area or the central node. Or both. In which case, better add them to a relation representing this bikeshed, plus the relation of all other bikesheds worldwide
name	*	The name of the bikeshed
access	public/customers/private	Distinction between public bikesheds, customers bikesheds (such as at cinemas etc.), and private bikesheds (such as for staff in a business park).
highway	cycleway	Road inside bikeshed. Add tag `cycleway=parking_aisle`.
fee	yes/no/interval	Whether you have to pay a parking fee or not. Default value is no. If the fee must be paid only on certain hours, the same syntax can be used as for opening hours. (See the discussion page.)
supervised	yes/no/interval	Whether the bikes are guarded to prevent car theft and vandalism. Default value is no. If a guard is only present on certain hours, the same syntax can be used as for opening hours.
capacity	number	The amount of bicycles that can be accommodated. (Including all special parking spaces e.g. disabled spaces) Read talk page on this.
colour	colour	Painting bikesheds is an essential OSM activity.

Mapping individual or groups of parking spaces

It may help to further prolong the mapping of the bikeshed if we decide to map each separate bike space, including details of its type (locker, hanger, those old-fashioned ones that buckle your wheel etc.). How to tag this is left as an exercise to the mapper, since nobody is ever going to use such tags anyway. Invent something! Go mad!

Open Issues

There are many elements of bikeshed tagging to perfect. To involve the worldwide community as widely as possible, it is advised to crosspost all discussion to @talk, @talk-de, @talk-au, @talk-legal, @strategic, as well as to local authorities and public representatives. Existing threads on more important topics are handy, as it attracts the attention of readers who might otherwise ignore what you have to say. Indeed, you will be surprised how many everyday threads offer good segways into the important subject of your bikeshed.

Similar tags

amenity=bicycle_parking

This more established proposal is so laughably simplistic, I will not discuss it any further.

Circular

Key:circular
Proposal status:	Canceled (inactive)
Proposed by:	LordOfMapping
Tagging:	`circular=yes,no`
Applies to:
Definition:	to mark circular objects / areas / ways
Statistics:
Rendered as:	-
Draft started:	2013-07-15
RFC start:	2013-07-15
Vote start:	never
Vote end:	never

Background

This tag should mark circular objects / areas / ways as circular so that the renderer can render them as circles. This reduces the number of nodes in circular ways and makes the map look better especially on high zoom-levels.

Usage

Use circular=yes to mark circular objects / areas / ways.
Use circular=no to mark octagons, dodecagons etc.

Examples

A round storage tank:
building=storage_tank
circular=yes

A roundabout:
highway=residential
junction=roundabout
circular=yes

A building that looks like a octagon:
building=yes
circular=no

A useless discussion on daft tag, like this one, usually on the tagging@ list:
circular=yes

Comments

Please discuss under the talk page.

Agricultural access

agricultural access
Proposal status:	Abandoned (inactive)
Proposed by:	FrankM
Tagging:	`access=agricultural` Data item
Applies to:	linear
Definition:	Indicate that a road may only be accessed by agricultural vehicles
Statistics:
Draft started:
Proposed on:	2008-01-02

(Proposal was moved here from Proposed features/Access only)

Rationale

In Germany, a lot of tracks are marked as "No vehicles, except agricultural vehicles" or "No motor vehicles, except agricultural vehicles". (Most of them are also allowed for bicycles)

"Except agricultural vehicles"	<tag k="access" v="agricultural"/>	No vehicles, except agricultural vehicles
"No motor vehicles" - "Except agricultural vehicles"	<tag k="motorcar" v="agricultural"/>	No motor vehicles, except agricultural vehicles

Applies to

Ways

Tags

A service road where only agricultural vehicles are allowed:

<tag k="highway" v="service" />
<tag k="access" v="agricultural" />

alternative proposal ("agricultural" as a type of vehicle):

<tag k="access" v="no" />
<tag k="agricultural" v="yes" />

Comments

also see: http://lists.openstreetmap.org/pipermail/talk/2007-December/thread.html#21320 --Cbm 21:36, 2 January 2008 (UTC)
IMO, this is an abuse of the access tag; "agricultural" is not a type of access, it is a type of vehicle. (like we have bicycle=, motorcycle=, hgv=, etc. Also, see the Proposed features/access: name space proposal. --Hawke 18:46, 4 January 2008 (UTC)

Employment agency

employment agency
Proposal status:	Canceled (inactive)

Tag:office=employment agency already exist

Ferns

natural = fern

Description

A fern.

Group: Natural

Status: proposed

More details at taginfo

taginfo · AD · AT · BR · BY · CH · CN · CZ · DE · DK · FI · FR · GB · GR · HU · IN · IR · IT · LI · LU · JP · KP · KR · NL · PL · PT · RU · ES · AR · MX · CO · TW · UA · US · VN
overpass-turbo
OSM Tag History

A fern.
Proposal status:	Proposed (under way)
Proposed by:	EzekielT
Tagging:	`natural=fern`
Applies to:
Definition:	A fern.
Statistics:
Draft started:	2017-07-30

More details at taginfo

natural=ferns

If you know places with this tag, verify if it could be tagged with another tag.
Automated edits are strongly discouraged unless you really know what you are doing!

Trails

Trail
Proposal status:	Canceled (inactive)
Proposed by:	Hawke
Draft started:	2007-06-10

Rationale

Provide a value for a nonspecific or multi-use path.

Applies to

Ways

Usage

Tags

A path (as for bicycles, horses, snowmobiles, cross-country skiing, etc.) could be tagged as:

<tag k="route" v="path"/>
<tag k="bicycle" v="yes"/>
<tag k="horse" v="yes"/>
<tag k="snowmobile" v="yes"/>
<tag k="xc_ski" v="yes"/>

Deprecates

highway=cycleway

highway=bridleway

highway=footway

Rendering

This should probably be rendered as a thin line (similar to current highway=footway), possibly broken, with color depending on the allowed usage.

Misc

If this is accepted, the values "cycleway", "bridleway", and "footway" should be deprecated.

Outstanding problems

This doesn't provide for "designated use" paths. Perhaps an addition to the access keys would be good. (e.g. bicycle=designated, foot=yes for a cycleway which allows foot, or foot=designated, bicycle=yes for the opposite)

Comments

I think this proposal solves more than the 'multi-use problem'. It also solves the problem that footway,bridleway and cycleway refer to 'legal rights of way'. Some people interpret a footway as foot=yes is an implied value whereas other people find the implied value is foot=permissive. See: http://lists.openstreetmap.org/pipermail/talk-gb/2007-August/000739.html

Argument against is that footways, bridleways and cycleways are normally rendered different on maps and I am not sure whetter this proposal makes it more difficult to render these different ways.

rvanderh,3 Aug 2007.

The new scheme misses the main function of the way. There's a huge difference between highway=footway;bicycle=yes and highway=cycleway at least here in Germany.

Maybe I miss something (quite new in OSM). But as far as I understand the proposal tagging for a (typical) footpath or a (typical) cyclepath will be <route=path;foot=yes> and <route=path;cycle=yes>. Although indeed I miss 'foot' under 'Tags' rvanderh,3 Aug 2007.

Problem is that <route=path;foot=yes;bicycle=yes> could be a) a path that is primarily intended for pedestrians (though cyclists are allowed to use it) or b) a path that is primarily indended for cyclists (though pedestrians are allowed to use it). -- Eckhart 22:11, 3 August 2007 (BST)

How else do you propose to solve the following: A path that is primarily intended for both cyclists and pedestrians, but is not a "legal right of way" for either? --Hawke

Pick your choice:

highway=footway;foot=permissive;bicycle=permissive or

highway=cycleway;foot=permissive;bicycle=permissive or maybe even

~~highway=primary;foot=permissive;bicycle=permissive ????~~

Nick (link above) just told he doesn't render highway=footway default as foot=yes. In my view it supports this proposal to remove pathes out of the highway-family. rvanderh,3 Aug 2007

highway=footway indicates that it is primarily intended for foot, highway=cycleway for bicycles. And primary is a major road for automobiles and thus completely inappropriate. None of those options provide for an equal-use route. --Hawke 08:59, 4 August 2007 (BST)

As far as I understand the descriptions in map_features xxxway is about 'legal status'. So you call a trail 'highway=footway' when you see official signs 'public footpath','yellow arrows' or the round blue/white signs in urban areas. Similar for bridleway,byway,and i think cycleway. I did some googling on 'bridleway','byway','cycleway' and 'rights of way' and I didn't find any clues that 'horseriding' is THE intended use on 'bridleway', or 'cars' on byways or cycles on cycleways. Checked law in NL use of cycleways by pedestrians is allowed if there is no footpath. So it's or highway=cycleway;cycle=yes;foot=yes (equal rights) or it is highway=cycleway;cycle=yes (single right). But I will stop arguing on highway=primary;foot=yes :)--rvanderh 11:18, 4 August 2007 (BST)

Okay, I now see the problem for rendering the map. But maybe you can explain why someone would want to know what the primary use of a path is ? The only thing I can think of is that one use has priority on the other use. But I don't think this is a real world situation. In my view the map should reflect the 'real world' rvanderh,3 Aug 2007

I agree with 'real world' completely, and feel that route=path reflects that, better than highway=xxxway. One reason I can think of to know the primary/intended use of a path, is so someone can make a map of all the "bike routes" in an area, or all the "hiking trails", or all the "ski trails". In most cases, bike can use roads -- but it's not as useful for a special purpose map to show/highlight everywhere a bike *could* go, rather only the routes that are built or designated with that purpose in mind. --Hawke 08:59, 4 August 2007 (BST)

You can make special purpose maps also without knowing the 'intended use'. I know bridleways on 'normal' maps have a different rendering, but why should OSM copy/paste ? Why should I want to know a way's intended use is 'horse' ? The only thing I want to know is that it may/can be used by horses so that I can avoid it if I am afraid of horses. Your proposal fits both single and multi-use and that's all there is IMHO.--rvanderh 16:36, 4 August 2007 (BST)

If you're riding a horse, you might prefer the bridleway over the footway because your horse suffers less fatigue. If you're cycling, you might prefer the cycleway because you can ride faster there. 3247 22:14, 6 January 2008 (UTC)

Can you explain that difference, please? The only difference I can see is if highway=cycleway is forbidden to pedestrians. And if so, route=path;bicycle=yes;foot=no would take care of that. (remember, the logic is that for access permissions, =yes means that it is a legal right-of-way). --Hawke

In Germany, on a cycleway you can ride as fast as you can (well, with some exceptions). On a footway which permits cyclists to use it you have to adjust your speed to pedestrian speed. E.g. a routing application would have to take care of that. -- Eckhart 17:28, 4 August 2007 (BST)

This 'cycleway you can ride as fast as you can' is by definition a single use path. If pedestrians are allowed on a cycleway, by law cyclist should adapt there speed on these 'weaker' traffic users. Even if something like 'intended use' exists it doesn't mean that this 'intended use' has more rights then the other 'legal' or 'permitted' users. Maybe cyclist don't like it, but then you better get rid of your fellow users and make it a single use path. --rvanderh 20:19, 4 August 2007 (BST)

In the UK I've been using cycleway in two ways, and I'm not sure this proposal adequately captures them. First, to represent paths that actually have a sign with a bicycle on them or the word "cycle path" - never mind that pedestrians can still use them, I've found it useful and faithful to the real world to represent them as ways primarily intended for cyclists. Second, to represent paths that are well surfaced, used predominantly by cylists, that are part of cycle networks and that are usually much bigger than a standard footpath. I quite like seeing two different kinds of path on the map, I think it conveys useful information. TomChance 13:48, 5 August 2007 (BST)

In the US, the sign in question generally says "BIKE ROUTE" and has a picture of a bike on it. However, these are frequently just sidewalks (that is, primarily for pedestrians) rather than paths purpose-built for bicycling. In some cases they'll also be widened for safety (to allow bikes to travel faster without causing problems for pedestrians. In regards to seeing two different kinds of path, I also like that -- but this proposal does not interfere with it. It is perfectly feasible to have the renderer render "route=path, foot=yes" one way, and "route=path, bicycle=yes" another. The intent of this proposal is primarily to unify footway,bridleway, and cycleway into one tag, as they have much in common with each other and little in common with the roads that make up the majority of highway=. --Hawke 23:40, 6 August 2007 (BST)

Think this is a good idea and closer to the scheme I would have come up with. Given the permissions of the path is defined by the foot=yes/permissive, horse=yes/permissive tags (etc), things like "highway=bridleway" are extraneous. Better in my view would be to use foot, horse etc for permissions, and highway=path, highway=gravel_track or highway=mud_track to represent the physical surface of the path. --Nick W 22:52, 4 August 2007 (BST)

Nick I miss something. You support the proposal and you still mention 'highway=..'. Maybe you should have a look on Ben's proposal on 'highways': http://wiki.openstreetmap.org/index.php/User:Ben./Highways . Main goal: move 'legal status' from the main key (highway-old,route-new) to the secondary access-key. Hawke proposes 'route' in stead of 'highway'. I oppose against highway=mud_track,etc or route=mud_track,etc. Let's put this under the surface-key or/and tracktype-key. Ben proposed (link above) route=road/track/trail/path. I don't know what his idea was on this, but it fits in my perception of the hierarchy in 'routes' I see in the countryside, allthough I doubt about 'road' and am not sure about the difference between trail en path (unpaved/paved ?)--rvanderh 23:23, 4 August 2007 (BST)

Just a quick general comment - this seems to depend upon quite a significant change to the way we differentiate between physical / legal / etc. aspects of a map feature. Is that correct? Just taking all forms of path out of highway would be very confusing. I'd rather see this proposed as part of that wider change, and do a lot of work to ensure that it is widely discussed since it would be such a big change. Personally I'd rather we just waited to fully develop something like STAGS/cOSMology, or went for Nick's proposal of a relatively small change. TomChance 13:48, 5 August 2007 (BST)

TomChance: The "highways" proposal would be a significant change for little gain. (Ben primarily doesn't like the term 'highway' as it has extra implications for legal rights). This proposal is a rather small change, and shouldn't be confusing (as the foot/bridle/cycleway would be only deprecated and thus should still work until someone went and removed them. (presumably well after this proposal would be made official) --Hawke 23:40, 6 August 2007 (BST)

Hawke. Maybe you could append some information in your proposal on the way it affects rendering of maps. The more I read in the Wiki and lists, the more I realize people are more worried about rendering of maps then about the meaning off tags. So give people confidence that the maps keep rendering the way they are used too.--rvanderh 00:25, 7 August 2007 (BST)

Rvanderh: The "Rendering" section covers this as well. It basically says that it should not affect rendering.

Rvanderh: Correct, a path is paved, a trail is unpaved. A trail may be narrower and have a more uneven surface as well. --Hawke 23:40, 6 August 2007 (BST)

This looks like what I need to tag the skiing trails I've been entering. I found references to "route=ski" and "piste:type=nordic" but to get them rendered anywhere, I needed to add a highway tag so I set it to "footway" with a comment. But these are definitely not "footways" and should not be confused with paths during summer, though they do overlap in places. You can see them in this area. If this proposal is accepted, the "xc_ski" paths need to look different to avoid confusion. On Norwegian paper maps, they are typically drawn as solid but often thin, red lines. --Bjornmu 21:13, 4 December 2007 (UTC)

As far as Poland is concerned I would see this feature completly different. Routes (paths/trails) are something completly non-phisical. They comprise a set of highways: footpahts, tracks, bridleways, unclassified etc. (rather not motorways). What constitues a trail in Poland are colourful stripes painted on trees, stones and everything that does not move along the path. Some trails have also reference numbers assingned by Polish Touring Society. I imagine route=path like this. Some highways that may be walked along subsequently are tagged with the same set of route=path tags.

Imagine three ways: a track and too footpaths that meet the track in different points like this

 \ w1
  \   w3
===.====.===w4
 w2    /
      /w5

The cycleroute goes along the track w2,w3,w4 and a hiking trail along footpaths w1 and w5 and along the track w3. The only reasonable means to achieve this seem to be relations. Steelman 22:10, 20 December 2007 (UTC)

I agree with steelman, that a route is something totally non-physical.
IMHO it would be much better to add a "highway=path" to combine footway, cycleway, bridleway,... in one highway-value. By adding a "designated" to the core-values of "Key:access" we can capture the real world even more accurate, without losing information.
e.g. http://upload.wikimedia.org/wikipedia/commons/0/03/Zeichen_240.svg or http://upload.wikimedia.org/wikipedia/commons/0/03/Zeichen_241.svg signed ways are nether a foot- nor a cycleway; they are both by definition, but to can't take this correctly at the moment. If there would be only "highway=path" you can catch it totally right -> highway=way bicycle=designed foot=designed. A sideeffect is also, that the renderers can perfectly adjust themselves to their's needs. --Cbm 21:59, 25 December 2007 (UTC)

I add a new proposal for the idea with: "highway=path" + new access-core-value "designated" http://wiki.openstreetmap.org/index.php/Proposed_features/Path --Cbm 02:10, 26 December 2007 (UTC)

Business lunch

"Tag:business_lunch=yes"
Proposal status:	Abandoned (inactive)
Proposed by:	Gutsycat
Tagging:	`business_lunch=yes; Mo-Fr 12:00-16:00`
Applies to:	,
Definition:	Good to find cheap and fast place to eat
Statistics:
Rendered as:	picture of a clock with 4 o'clock on it
Draft started:	2015-10-24
RFC start:	2015-10-24
Vote start:	*
Vote end:	*

See key:lunch

Proposal

Ability to add a "business_lunch=yes" tag to cafe or restaurant where you can have business lunch.

Rational

When you are a tourist you want to have simple dinner with 3 plates: salad, soup and hot meal and as cheaper as it could be. So it good to have points near you with such service.

Examples

business_lunch=yes/no
business_lunch=Mo-Fr 12:00-16:00

Discussion

Talk:Proposed features/business_lunch

3D approximation

3Dapproximation
Proposal status:	Abandoned (inactive)
Proposed by:	Dkiselev
Tagging:	`3Dapproximation=Text what describe 3D model generation for object`
Statistics:
Rendered as:	buildings commonly
Draft started:	2011-03-20

The 3D Development team are currently working on unifying 3D related tags.
For first results see Simple 3D Buildings.

Headline text

Описываем что мапим и какими тэгами

Modelling language definition

Типы данных Строки: 'строка заключается в одинарные кавычки: \'строка\' '

Числа

Объекты

Динамическое приведение типов

Стековая запись аргументов

Snow kiting

"Key:sport, Tag:piste:type=snowkite, Extend_by_snowkite"
Proposal status:	Abandoned (inactive)
Proposed by:	"ondiiik"
Tagging:	`", sport, piste, type"=", snowkite"`
Applies to:	", , "
Definition:	"Extend sport:piste:type by snowkite to mark backcountry area used for Snow Kiting"
Statistics:
Rendered as:	"picture"
Draft started:	"2013-11-17"
RFC start:	""
Vote start:	""
Vote end:	"" Flowers