Proposal talk:Information

General opinions

I think the proposal should also include signposts Proposed_features/Guidepost. --Vrabcak 12:48, 11 November 2008 (UTC)

That is a right objection. Vsandre 17:25, 11 November 2008 (UTC)

I like this proposal. This tag is needed, I had to name nodes as a workaround to indicate the nature of the information. --Nop 22:36, 11 November 2008 (UTC)

I like this proposal, too. It's useful for all those information signs in the wild... :) --ise 15:34, 01 December 2008 (UTC)

I like it as well and will start to use it. :) --Driver2 23:25, 6 December 2008 (UTC)

/me too. additionally I suggest content=* for text based signs. I'll write a proposal soon --Malenki 15:31, 7 December 2008 (UTC)

I think for this you have to use description=* --Vsandre 10:14, 23 December 2008 (UTC)

Good proposal! But for me the value "wildlife" is a subset of value "nature", therefore redundant. Sometimes you may find boards containing both descriptions "flora" AND "fauna". --Urk 06:48, 6 January 2009 (UTC)

Regarding map/hikingmap/bicyclemap, can skiingmap, skimap or pistemap be added to the list? — vibrog 07:31, 9 January 2009 (UTC)

Great proposal. I was the one who made the original tourism=information page, this works much better. I will definitely use it. Just don't make use of the basic information= tag too complex. MikeCollinson 10:42, 21 May 2009 (UTC)

Experience with information tag

It appears that the Osmarender and Mapnik maps do not render the information tag at all. When it was first rendered on the Hiking map, it turned out that a more specific tagging of information points is sorely needed. As there was to agreed tag, many people have put all the information into a verbose name tag, which is cluttering up the map in many cases. A lot of unwanted information is also showing.

It has become quiet around this proposal. And it also seems that it was not linked in the proposal page, I have fixed that. I have started correcting overly verbose information tags, but I think we really need to advertise a bit and continue with this proposal. --Nop 15:52, 12 February 2009 (UTC)

Much more possible values and categorization

I support this tag, however I think there are much more possible values than presented in this proposal. For example, each sport that can be practiced outside can have dedicated information boards. Specifically, I think of posts indicating directions to find climbing sites. However, this raises a categorization issue: a general sports map will face the complicated task of aggregating all possible sports-related values (hiking, canoeing, climbing, diving, free-flying, etc.) Should there be some built-in categorization like information=sport;mountain;hiking ? I know that currently some people also use the reverse way of tagging things (climbing=information), what’s your opinion about that ? --Pshunter 21:35, 14 February 2009 (UTC)

I disagree. The current proposal addresses the points where we actually have problems. A logical extension later on will be easy. Furthermore, I believe that the case of a board for multiple sports is extremely rare, I have never seen one. I also think that reverse tagging is a bad idea - the proposal follows the same scheme used for highways, tracks, routes etc., this is consistent. --Nop 12:26, 16 February 2009 (UTC)

I mainly think of various types of information aimed at different types of users. Citymaps, hikingmaps, cyclemaps and pistemaps are proposed, and the same applies to signposts: is the post useful to hikers, bikers, skiers, other people or any combination thereof? On a general tourism map you may want to put all maps because they contain important and general info, but not the individual signposts. On a specialized map e.g. for hiking, you may not want to include information not relevant to hikers. I think it would be useful to have a standard way to specify to whom the information is relevant. Then, we could only have information=map scope={hiking, piste, bicycle, etc.} --Pshunter 13:17, 16 February 2009 (UTC)

Does this matter? Any signpost is an aide in orientiation, and if the post is part of a route, the significance is already sufficiently tagged with that route. --Nop 13:19, 16 February 2009 (UTC)

Ok, put aside the general reflexion. The real question is : I have some signposts designed to guide climbers to climbing crags. They are only useful to climbers, the ways they point to only go to these crags and nowhere else. How do I tag them? They are placed along a main road to mark the starting point of the paths to reach the crags. Most of the time there is also room to park near the post. In fact these posts are something between an orientation board and a simple signpost. --Pshunter 13:30, 16 February 2009 (UTC)

Yes, I support this too. Another value that would be useful is something for Parish Notices boards (or the equivalent) which are boards that anyone can put info and adverts for local events happening soon --Chris Clemson 00:20, 17 June 2009 (BST)

New scheme

Probably it is really better to change into a more flexible scheme. While mapping with this tags I noticed that in some cases it is really difficult to use the exact tag. Because many maps are used as city maps but also with routes for hiking and bicycling. So what to choose? So my next proposal step could be something like this.

For the tags information=map and information=guidepost it could be better to use tags with the content of the maps or the main use of a guidepost. I think it is the best to use the access=* values.

main key	sub key	description	Rendering	Photo
information=map		A board with a map. If possible use a more specified tag.	or
information=map	hiking=yes or foot=yes	A board with a hiking map.	and
information=map	bicycle=yes	A board with bicylce routes of region.	and
..	..	..	..	..
information=guidepost		Signposts/Guideposts for showing the right direction to different destinations
information=guidepost	hiking=yes or foot=yes	Signposts/Guideposts are often found along official hiking routes. See also Proposed features/Guidepost
information=guidepost	bicylce=yes	Signposts/Guideposts are often found along official bicylce routes.
..	..	..	..	..

It is also possible to mix this additional access key, so that a map can also be a hiking and a bicycle map.

The next important key should be map_type=*. With this you could describe how the map looks like or how detailed the map is.

key=value	description	example/photo
map_type=topo	A map with topographical background for e.g. a historical or hiking map. The map contains contour lines.
map_type=street	A map with all streets or ways of an area. The streets are mostly named.
map_type=schema	A painted map only with important ways and POIs.
map_type=toposcope	A marker erected on high places which indicates the direction to notable landscape features which can be seen from that point.
..	..

The same should be possible for the size of the area which is shown.

key=value	description	example/photo
map_size=site	A map of special site, like of a historical castle.
map_size=city	A map of a city.
map_size=region	A map for a lager area.
..	..

The key-names are only a first shot and can be changed if they are unsuitable. --Vsandre 12:55, 14 May 2009 (UTC)

There should also be categorization of information = board:

key=value	description	example/photo
board_type=notice	At (parish) notice boards you can find parish notices or adverts for local events happening soon.
board_type=history	A board with historical information about this place.
board_type=nature	A board with information about nature in this region. Often used at educational trails.
board_type=wildlife	A board with information about animals living in this region. Often used at educational trails.
board_type=plants	A board with information about plants of this region. Often used at educational trails.
..	..

new vs. original scheme

How to convert the nodes/ways with the original scheme into the new one?

information = map

original	new scheme
information=citymap	information=map map_size=city map_type=street
information=sitemap	information=map map_size=site
information=hikingmap	information=map hiking=yes
information=bicyclemap	information=map bicycle=yes
information=mtbmap	information=map mtb=yes
information=pistemap	information=map ski=yes
information=tactile_map	information=tactile_map

In most cases you have to write more. But now you are able to define a map showing hiking and bicycle routes. In my opinion information=tactile_map should be a separate tag, because of its importance. But on the other side it should be able to use a combination of information=map and tactile=yes. Should be discussed ->here

information = board

original	new scheme
information=history	information=board board_type=history
information=nature	information=board board_type=nature
information=wildlife	information=board board_type=wildlife

Stick with the old scheme

I dislike the modified proposal a lot. It's complicated and over-engineered for describing a map. The old version was straightforward and simple to understand. It is already widely accepted and in use. About 3600 nodes and at least one map using it show that it works well. It is crazy to change it now. --Nop 23:08, 25 July 2009 (UTC)

For describing a map you only need to tag information=map. ;-) And if you want to describe a hiking map, you only have to write one more tag. If you add this via JOSM or a other POI editing program, you have to select it by once.

If we don't open the scheme to more flexibility, we could probably end with the same problems, we have with the highway classification.

• How a tag a map with hiking, cycling, inline-skating and of course horse riding routes?
• How to differ between a schematic map (only with information about one route, but without all interesting ways you want) and a topographical map. It could be uninteresting for YOUR map, but not for me.

The next problem is, that the information=*-key will explode if every transportation mode get it own tag. And now there is already the problem for people to tag a map for skiing, tag as pistemap, as skiingmap, as nordicskiingmap or as alpineskiingmap.

An in the end a proposal could be changed during the proposal process and all existing nodes could be easily converted. --Vsandre 10:35, 26 July 2009 (UTC)

It is bad policy to forcibly change 3600 nodes in active use. The voting on those tags has already happend by the people using it. Proposals should be compatible to existing usage, so extend it, but do not try to remove tags with several hundred usages. --Nop 11:33, 27 July 2009 (UTC)

The existing nodes could be easily changed by bot and new nodes will be tagged with the new scheme, when I update the JOSM-presets. So what is the problem aside from the existing nodes. If there is a problem in the scheme I will reverse it.--Vsandre 20:42, 27 July 2009 (UTC)

3600 uses means a lot of people who want to tag it this way. You cannot just ignore all those people, propose something else and retag the work of hundreds to your liking, at the same time wiping the nodes off the maps. Those nodes are just as quickly tagged back to their original state by a bot and you have a nice little edit war going. --Nop 14:40, 28 July 2009 (UTC)

3600 uses because of the JOSM-implementation as preset or because of knowing the proposal. In any way I do understand your intervention, but I will take care about the future of this proposal and the information key. Imho a new proposal should be easily expendable and not be fixed and useless for further ideas. Please argue against my intentions of the changing and not the existence! --vsandre 21:31, 28 July 2009 (UTC)

Rendering

Maps with information items

I have added rendering support for some of the tags to the hiking map, they will be rendered with the next update. --Nop 12:26, 16 February 2009 (UTC)

Signpost icon

I do not recognize the left symbol proposed for a singpost at all. Where does it come from? --Nop 12:26, 16 February 2009 (UTC)

Have look at information=guidepost. The symbol is often used at maps from the DAV and at czech maps. Please feel free to take part in the vote for the best symbol. --Vsandre 13:01, 16 February 2009 (UTC)

Tactile maps for the blind

We need another value for tactile maps for the blind, please! --Lulu-Ann 11:26, 20 March 2009 (UTC)

^{[ dead link ]}

While writing the new scheme I was not sure how to categorize tactile maps. In my opinion information=tactile_map should be a separate tag, because of its importance. But on the other side we could use a combination of information=map and tactile=yes. What is your opinion?

A tactile map is a special need of blind persons. information=map ist not of use for blind persons, and a separated tactile=yes neither. Only the combination is a worthful information. I added it here and I guess it should stay this way. I rather think of having it tagged like blind=tactile_map andblind=tactile_paving to have HaptoRender only looking for one tag. --Lulu-Ann 14:49, 28 July 2009 (UTC)

I think it was a good decision to mark it as information=*map, because it is useful for orientation not only for blind persons and most of your examples could be also tagged with tourism=attraction. The question is not, if it is easier to handle for a render or routing program, the schema should be consequentially. Because of the differences to a normal map, it is OK for me that there will be a separate tag. --Vsandre 21:47, 28 July 2009 (UTC)

Access Keys to describe a guidepost

It is very dangerous for routing apps to use Access-keys to describe a guidepost or map closer.

So instead bicycle = yes I suggest information:bicyle = yes or guidepost=bicycle --chris66 10:56, 24 December 2009 (UTC)

This is only a problem if you put the guidepost on a way node. (Which is a failure) If not and the guidepost is a single node near the way, there will be no problems for any routing software.--Vsandre 18:44, 26 December 2009 (UTC)

Where does it say that the guidepost should not be a way node? I place all my (Hiking-)guideposts on the intersection of two (or more) ways, and I know many others that do the same. AFAIS the position of the guidepost-node is not mentioned in this proposal. Also compare it with the (Destination-Sign-Proposal) where the sing node is ment to be ON the way. --T-i 14:05, 28 December 2009 (UTC)

How many guideposts do you know that are standing in the middle of the intersection? And how many that don't? Please tag what is on the ground. Not just because that is a good principle, but also because you see here what happens if you don't do that. (breaking routing) --Cartinus 13:29, 29 December 2009 (UTC)

It's a problem of the data structure in OSM. As the streets are simplified to lines, one has to decide if a guidepost belongs to the street or to the surrounding area. For me, a guidepost belongs to the street (unlike e.g. a post box which I would tag at it's 'real' position). It's a similar problem to highway=bus_stop.. --T-i 21:34, 5 January 2010 (UTC)

Addition: Another tag, that is put on an intersection and not where it 'really' is: traffic signals --T-i 15:23, 11 January 2010 (UTC)

And if you read that page about traffic signals, there is section on the bottom that explains why that is a problem. --Cartinus 21:29, 11 January 2010 (UTC)

This is not only a routing issue. foot/bicycle/ski=yes just have a meaning that doesn't fit in here. See access=*: "Access values are used to describe the legal access for highway=*s and other facilities" If you set bicycle=yes on a guidepost, that either means that bikers are allowed to view that guidepost (while others are not?), or that bikers are allowed to jump on the guidepost with their bicycles. There are bicycle acrobats who can do this, but this is certainly not what you meant.

I suggest adding guideposts to the respective route relations instead. Same for information=board and information=map. --Fkv 09:23, 23 January 2012 (UTC)

Much more board_types

During mapping all those board in around my home I noticed much more than those types on the proposal page:

• industry: boards with information about industry (in my area in the past). Tagged as: board_type=history;industry
• sport: boards with information about local sport clubs, sport events etc.
• sights: boards with information about sights in a certain area
• culture: unsure about this. is a board with information of the local library. better: library?
• politics: boards by (local groups of) political parties. party as operator.
• official: an official board by an agency or registry office (de:Bürgerbüro)

http://www.informationfreeway.org/api/0.6/node[information=board][bbox=6.859278,51.23609,6.862245,51.237833]

XAPI-Link with all of the above described boards (due to Wiki-Syntax no clickable link)

Furthermore I tagged according to the proposal history if there was a description of the history of something next to the board, and notice for information of a church (religious community, parish?). Probably church, place_of_worship or religious would be better here.

Probably those tags could be added to the proposal. --E-Malte 14:52, 2 March 2010 (UTC)

I want to support your proposal! Here in Germany, we have many boards of political partys and even sport clubs operate some boards. --Timmo 14:53, 23 May 2012 (BST)

why not board:type=* or just board=* ?? --dr&mx (talk) 22:09, 1 May 2013 (UTC)

We should generally avoid keys named ..._type or ...:type, because people mix them up all the time. The <key>=<value1> + <value1=value2> subkey scheme is more concise and less error prone. Therefore, I would prefer board=* and map=* over board_type=* and map_type=*. --Fkv (talk) 10:21, 30 November 2014 (UTC)

board_number

We (hiking in Czech republic) need also some "board_number" tag as the boards are often numbered, especially along various learning tracks. This is not the same as ref=... as ref denotes the reference number of the track itself. --Kavol 20:36, 19 April 2010 (UTC)

ref on relation = track num, ref on board node = board number ?? More tags make more chaos I think Jezevec 22:22, 19 April 2010 (UTC)

Probably a board:ref would do fine for this task. Guess its better to understand than board_number. --E-Malte 22:37, 19 April 2010 (UTC)

I will support Jezevec. All current softwares can evaluate this. If you want to show the dependency to an educational trail put the board into this relation.--vsandre 07:52, 20 April 2010 (UTC)

That sounds too confusing to me. Why to overload tags, having to decide the exact meaning depending on context it is used in? What does "all current softwares can evaluate this" mean, doesn't that mean "it will show me anything with network=iwn and ref=number like a number of the track, instead of the number of the object itself"? What about using ref:board (not board:ref, to keep the convention)? --Kavol 08:41, 20 April 2010 (UTC)

Because it is the common use of ref=*. I will show it to you with a similar example. Every highway=motorway have its own reference number. And every exit or junction (highway=motorway_junction)have its own reference number. To differ between this numbers you have to look at other tags. In your example of a rendering rule you have to check before if it is a route=* or a information=board.--vsandre 10:50, 20 April 2010 (UTC)

But if I'll take I look at information=board and decide to take ref=number for the board number then the track reference is missing. I have to ask "hey, doesn't this node belong to some relation that I can read the track reference from?" and the person who created the node is forced to create also the appropriate relation. In your ideal world, all the objects belonging to some particular track should be mapped and assigned to a relation. But we don't live in an ideal world. I am really not sure, if a relation describes some path, and the board is not on that path, that it should be part of the relation despite being referenced as a part of the same track. In our (Czech) hints for touristic tracks tagging there is even explicitly mentioned that a track has two ends, no ways aside. Not sure if the motorway junction example is right, the junction always has to be on the road, you can't have it 200 m off the road. --Kavol 18:03, 20 April 2010 (UTC)

Map size

I think we should use the same words for map size like for place. Lulu-Ann

milestone

what about adding information=milestone for this example. (or information=guidepost should work?). it marks distance to Santiago at the Camino de Santiago pilgrims route.

--Sergionaranja 22:28, 28 June 2010 (UTC)

Personally, I put information="guidepost" and guidepost="milestone", name="Km 81, Castromaior" and operator="Diputación Provincial de Lugo".--Xan 11:06, 1 July 2011 (BST)

historic=milestone is in use. I know of no milestones built in modern time. --Fkv (talk) 09:57, 30 November 2014 (UTC)

information=display

I would add information=display to the list of possible values of information. A display is simply a monitor (TV or something else) for displaying specific information: tourism information, bus frequency (typically in bus stops), traffic congestion (in motor vehicle roads), etc.

What do you think?

Support, sounds like a good idea. --Kslotte 16:07, 30 June 2011 (BST)

Thanks--Xan 11:07, 1 July 2011 (BST)

Just an example table

main key	value	description	Rendering	Example
information	display	A display is simply a monitor (TV or something else) for displaying specific information: tourism information, bus frequency (typically in bus stops), traffic congestion (in motor vehicle roads), etc. A display:type tag could be added: display:type=traffic_information, display:type=bus_frequency, display:type=tourism_information, etc.		this is an example of information=display and display:type=traffic_information that is an example of information=display and display:type=bus_frequency, operator="EMT Madrid".

--Xan 11:22, 1 July 2011 (BST)

Dennert Fir Tree

Hi, I want to propose the tag information=dennert_fir_tree for information boards who are very special for the harz mountains to show historic information, see http://en.wikipedia.org/wiki/Dennert_Fir_Tree Ogmios 00:22, 16 April 2012 (BST)

Looks more like a subtype of information=board, board_type=historic to me.--Kaitu 20:49, 16 April 2012 (BST)

maybe so Ogmios 10:50, 17 April 2012 (BST)

Maybe it makes more sens like this: information=board, information:type=historic, board:type=dennert_fir_tree Ogmios 22:40, 18 April 2012 (BST)

Since nobody seems to be interested in this topic I begin to describe those boards with dennert_fir_tree=yes. Ogmios 14:02, 3 May 2012 (BST)

Village/Town/City Sign Post

How about a tag for those village/town signposts - there's a lot of them. I cant think how to describe them but I'm sure you all know what I mean. Many 'significant'/'interesting' towns and villages in the British countryside usually have them either in the centre or on the roadside when entering. For those of you who are unfamiliar here are some examples:

http://upload.wikimedia.org/wikipedia/commons/8/83/Village_Signpost,_Church_Lane,_North_Cockerington_-_geograph.org.uk_-_106295.jpg

http://www.picturesofengland.com/img/L/1014975.jpg

http://s0.geograph.org.uk/geophotos/01/15/74/1157454_2c2511e9.jpg

These are different from the standard roadsigns for places, with which they coexist, and are primarily for touristy reasons so are perhaps worthy of a tag. --Abc26324 (talk) 00:03, 2 March 2013 (UTC)

Combination

What about a guide post combined with a map? Two single nodes or is there a scheme to combine things? --Chinus (talk) 23:16, 18 December 2013 (UTC)

I have the same problem. Any idea how to tag board with two sections - one for map and another for text description, for example history? Both aspects of the information are major. Not sure if this is a good solution:

• information=map;board
• board_type=history
• map_type=topo

Another solution could be to place two nodes nearby, but I don't like this idea as well. --*Martin* (talk) 20:45, 4 February 2014 (UTC)

I think that the first solution is correct, and I have been using it already a couple of times. It is not our fault that application developers are lazy. --Fkv (talk) 10:09, 30 November 2014 (UTC)