Talk:Tag:tourism=viewpoint

viewing Angle

I'm wondering whether there is a tag used for viewpoints from which a view is limited only to some direction. Quite often one can see only to one direction and the view to all other directions is blocked e.g. by forest or mountain. Say that I would like to create a point from which one can see to the north. Does anybody know any tag for this? At least a non-standard one :-) --Vojtaf 18:07, 28 August 2008 (UTC)

I don't know of any special tags. Why not use this one, and add direction=<number of degrees clockwise from North> or similar? EdLoach 10:06, 29 January 2009 (UTC)

I was just wondering the same, so checked here. We would need to state the start and end point of the range at which the view is of. For rendering purposes it may be easier to tag the range of the view, so it may be 180 degrees, and the centre angle of that range. It could be rounded down to blocks of 22.5 degrees so only 16 symbols are needed for the rendering program. This would work so long as there aren't views in 2 directions from 1 point but it's not a 360 view. I think I'll tag tourism=viewpoint; viewpoint:0; range:160, for a 160 degree view north.

Also I'm wondering what we should do when a linear route offers a view which isn't best in any 1 particular spot? Ben 20:35, 10 February 2009 (UTC)

for linear routes I would suggest tagging the way segment with "tourism=scenic_route". --Grille Chompa 11:59, 12 February 2009 (UTC)

I was just wondering the same. I miss this tag too. I would prevere a tag "direction" instead of viewpoint. So you can have direction=0 and then the optional range=160. May be for rendering you can take a range of 90 degrees if a direction is set and no range-tag. i think, a set with symbols of a range with 30° would be enough. here is the europeen tagwatch for viewpoint --fossy 17:23, 18 March 2009 (UTC)

I think you are overdoing it a little. In real life, you don't need ranges accurate to a degree and nobody is able to determine the exact degree. It think this should be simplified to: range: quarter, half, (full) and it would be enough to give the direction in N, NE, E, SE, S, SW, W, NW. --Nop 19:10, 21 March 2009 (UTC)

Yes, you don't need the latest degree. But in my opinion the tag should be exactly as possible. And Numbers are very simple. German People would may be write NO instead of NE. And if you would prefere to render only quaters you can do it by calculate the symbol out of the exact value. Example: for range-values from 0° to 135° you take the quarter, for range-values from 136° to 225° you take the half, and so on. The same with the directions: values from 23° to 67° are NE, from 68° to 112° are E and so on. --fossy 07:21, 22 March 2009 (UTC)

Well, in my opinion, data should not be unnecessarily and unrealistically detailed. German people can tag in English, that is not different here from any other tag. And recalculating the values is exactly the problem. All existing render chains I know are based on mapping tags to map features, none of them supports transposing overdetailed range values. Which means that none of this is going to show on any map anytime soon. I prefer tags than can be visualized with existing technology so we can make some use of them. --Nop 15:12, 2 June 2009 (UTC)

If you say, that if the data cannot be rendered, so let it be, you are wrong. The OpenStreetMap is supposed to be a geodatabase, not a map. One should really map everything that comes to your mind and that is right. For the purpose of displaying rendered maps there are different projects such as the OpenStreetBrowser...
Keep on tagging! ;-) --Derstefan 17:12, 8 January 2011 (UTC)

I do not say that. --Nop 23:34, 8 January 2011 (UTC)

Another way of thinking would be to trace an area (a triangle for the simplest case) with tourism=view_area (better names are welcomed), with one node holding tourism=viewpoint, and add a relation between this point and the area. Nodes other than the viewpoint may be taken from particular points of the site (e.g. a bridge, a church, a mountain not so far from here...). No need to measure and store any angle (at least for the user point of view). For map rendering, what about a piece of cake on the viewpoint, with constant radius, the angles showing the points of view (NE, SW, E, whatsoever) ; or some touristic maps may also draw that polygon for more details. Teuxe 14:09, 21 April 2011 (BST)

I think that views can hardly be represented by closed areas. In any given area, there are usually some places invisible because the view is blocked by nearer+higher places, vegetation, or buildings. And outside the area, there may be some mountains or towers visible because they are so high. Even on the ocean, approaching ships become visible before they reach the horizon. That's why I prefer just mapping the angles, not the scope. With elevation data becoming more and more exact, renderers should be able to calculate scopes themselves. --Fkv 20:45, 21 April 2011 (BST)

Resolved: The direction=* tag is well documented and in widespread use for this purpose so marking this as resolved, alternative proposals can be opened as a new section or discussed on the talk page for direction=* Aharvey (talk) 09:33, 13 March 2022 (UTC)

Tagging scheme

As tag we should use viewpoint:direction=* or viewing_direction=*, because direction=* is used in an other way.

Because of the possibility of multiple viewing directions, we should not use direction and range. Instead we should use the same scheme of opening_hours and allow more than one directions separated with a semicolon. To show the range it is good to use the start and end direction separated with a dash.

The degrees should be positiv integer numbers and rounded to full five degrees. (e.g. 0°, 5°, 115°, 120° and not 3.57632°, -120°) --Vsandre 10:20, 2 June 2009 (UTC)

example

key=value	viewing direction
viewpoint:direction=0-180	possible viewing direction to north, east and south
viewpoint:direction=90-270	from east over south to west, but not to north
viewpoint:direction=0-45;180-315	from north to north-east and south to north-west
viewpoint:direction=270-360;0-90	from west over north to east, but not to south

Discussion

I think this is total overkill. Most real-life situation do not need this amount of precision, it is impossible to determine the view to a degree, so the information will always be wrong, debatable and quickly outdated. It is not possible to show it on a map in this detail. No existing rendering chain supports such type of tagging, so it's useless for all existing maps.

Keep things simple! --Nop 12:02, 2 June 2009 (UTC)

I limited the angels to full 5 degrees steps. If you only want to use the cardinal points, why not rounding these angels to N,NE,E,SE,SW, W or NW. viewpoint:direction=0-90 will be preprocessed for example to meta_viewpoint:N=yes, meta_viewpoint:NE=yes and meta_viewpoint:E=yes.--Vsandre 14:31, 6 November 2009 (UTC)

I think that 5° steps would just combine the drawbacks of all suggestions:

* you are not allowed to map the exact angle even if you measured it

* without a good compass, you probably still don't know the angle that exactly

* it is still somewhat difficult to read for both humans and computers

* besides, mappers wouldn't care and would type in more exact values anyway whenever they know

Therefore, I prefer 1° steps as in your original suggestion. If this is considered too fine or too complicated, then Nop's suggestion (NE,SW...) seems more to the point. The syntax could be: viewpoint:direction=<any combination of N,NE,E,SE,S,SW,W,NW, separated by semicolons> The default would be full view, so you never need to type in the complete list. --Fkv 18:40, 14 January 2011 (UTC)

When you can't determine the view to a degree, just type in an estimation. We also use to map coordinates with 7 positions after the decimal point, although none of us can ever measure them that exactly. --Fkv 18:40, 14 January 2011 (UTC)

Why not (propose) a relation of type=line_of_sight with members 1*from and (1-n)*to. Include only the outermost visible things or the main attractions visible, if it's not a "nature only" type of viewpoint. Alv 12:13, 2 June 2009 (UTC)

Opose these proposal, because one relation and n ways with n+1 nodes will be too much for one simple degree.--Vsandre 14:31, 6 November 2009 (UTC)

Really it's true that we should not need to be very precise for the opening angle, because it will be actually rendered using bubble-formed rays around a small central filled circle: these rays should not exceed the maximum number of 10 (for a full circle), and in all other cases it will between 3 and 9 rays. This will limit the number of symbols to just a few: 3 to 9 rays.

• With 3 rays within a 80 to 120 degrees angle, even if the viewing angle is lower than 80 degrees, meaning that the number of rays need to be rounded, as well as the number of rays; and their angle mutual separation recomputed according to this rounded number). This metric gives a angle separation of rays between 40 degrees inclusive and 60 degrees exclusive.
• Viewing angles between 120 degrees and 160 degrees exclusive you add a fourth ray with the same separation between 40 and 50 degrees.
• Viewing angles between 160 degrees and 200 degrees exclusive you add a fifth ray.
• Viewing angles between 200 degrees and 140 degrees exclusive you add a sixth ray.
• Viewing angles between 240 degrees and 280 degrees exclusive you add a seventh ray.
• Viewing angles between 280 degrees and 320 degrees exclusive, you add an eigth ray.
• Viewing angles between 320 degrees and 360 degrees inclusive, you add the last ninth ray around a full circle, which normally requires no orientation and whose "central" ray can point arbitrarily to the North.

Finally, it also happens that the same point gives two view points in opposite directions, without neceassrily filling the whole circle: we could as well superopose the two viewpoints.

When rendering as SVG it will absolutely not a problem to use a rotate() operator for each ray drawn.

However the direction of viewing should have enough precision so that it will properly be rendered with one half of the rays one one side, and the second half of rays on the otherside. On coastal maps or mountain maps, these viewpoints are very frequently found and need to be correctly oriented, so I think that the precision of 1 degree will still be necessary (this will not be a difficulty, given that the symbol can be fully vectorized, using basic computations).

On the opposite the direction of viewing must be precise enough (especially for coastal maps like with cliffs or capes).

It's also true that not all viewpoints are "natural", this may be on top of a building, tower or fortress, in a city.

There is also the case of viewpoints along a path: this is not necessarily both sides of the way. For such case, it is usual to draw them differently a half-transparent medium/light green or light blue or cyan shadow (sometimes even gold/orange on some maps) on the correct side of the path (it may be on the right or left of both sides of the way, and only for a given section): this is typical for pedestrian paths along rivers, canyons, or watered areas. The effective color of this shadow depends on the kind of viewpoints, and notably the terrain on which it is observed. But it may also depend on the convention used to denote selected touristic routes. Verdy p 06:41, 27 August 2009 (UTC)

So my suggestion is for "viewpoint=direction[,view_angle]", where the direction is a single angle measured anticlockwise from the North, with a precision as down to 1 degree, and an optional view_angle (the default will be 80 degrees that draws 3 rays, and the view_angle will be one between 80 and 280 degrees by step of 10, or 360). E.g. viewpoint:direction=52, and optional viewpoint:open=45.

The renderer will adjust itself the viewpoint:open value occording to its rendering constraint (may depend on the form of the rays, or rendering resolution). The length of rays should be about the equivalent of 50-100 metres on map, and it will disappear at some scales where it becomes impossible to display the asterisc-like symbol with distinct rays and a clear central dot of about 2 metres. Verdy p 06:53, 27 August 2009 (UTC)

The advantage of your proposal is that it can already be used with the todays rendering software. But you forgot the problem of having two different directions, see example viewpoint:direction=0-45;180-315. --Vsandre 14:31, 6 November 2009 (UTC)

but how to define a around-view ? direction=360 ?? --Lübeck 14:06, 1 August 2012 (BST)

viewpoint:direction=0-360 --t-i 23:07, 19 August 2012 (BST)

why ? we did not tag opening_hours=Mo-Su 0:00-24:00 -> 24/7 is enough ! --Lübeck 08:27, 22 August 2012 (BST)

Binoculars

How about binoculars=yes if there are public binoculars (as on the image in the Description Box)? Perhaps with a binoculars:fee=yes if you have to pay to use the binoculars... --T-i 02:17, 10 September 2009 (UTC)

This tag for ways

I propose to use this tag for ways too. Very often especially good view available not from one point but from part of footway (from bridge, from path along cliff, ect). Lzhl 21:48, 21 November 2010 (UTC).

You're right that sometimes you have a whole way with a nice view. I think of the panoramic roads. But in terms of OSM we should confine ourselves to on node. Not only because in the word viewpoint is the word point. How would you interpret the property direction. One would have to have the opinion of a programmer of a renderer. --geozeisig (talk) 08:09, 24 November 2017 (UTC)

Specify definition

In the center of Vienna there's a bar with a quite good view, on their website they claim that it would be one of the best views in Vienna (which isn't true). Someone added a note that the viewpoint should be added to the map. If there's no clear definition of a viewpoint, every bar / restaurant / café in every city can claim to have a viewpoint as long as they are located in a high-rise building…

In my opinion, a viewpoint should always be publicly available, apart from that it should be identified by a sign and/or there should be public binoculars and/or a map explaining the panorama. These are just a few examples but I think it's important to agree on some criteria. --Stefan Nagy (talk) 17:49, 12 October 2014 (UTC)

tagging with peaks

I strongly disagree with "Due to the rule One feature, one OSM element the node should not be another object at the same time, eg natural=peak or man_made=tower".

tourism=viewpoint may be also considered as property of object, not as a separate object. Given that 10% of tagged viewpoints are following this tagging method it is clear that I am not unusual in this opinion - see https://taginfo.openstreetmap.org/tags/tourism=viewpoint#combinations Mateusz Konieczny (talk) 22:56, 21 November 2017 (UTC)

I agree in this case with you that the tag could be read as property, although a true "peak" will always offer some kind of view, so I feel it is superfluous to add tourism=viewpoint here (similarly for the top of towers, etc.). --Dieterdreist (talk) 14:07, 23 November 2017 (UTC)

Note that tourism=viewpoint is not for any place with any view, see "A place where tourists, visitors, hikers might like to visit and take photographs." Mateusz Konieczny (talk) 03:49, 17 January 2018 (UTC)

If we have an object like a tower or peak, viewpoint can be added as a property like viewpoint=yes. Unfortunately tower is not rendered at Carto, then it would be noticed that not both can be rendered simultaneously. There are other cases where this is so similar: tourism=hotel + swimming_pool=yes or amenity=cafe + ice_cream=yes etc. --geozeisig (talk) 07:59, 24 November 2017 (UTC)

It can be also added directly as tourism=viewpoint, there is no good reason to avoid it Mateusz Konieczny (talk) 03:49, 17 January 2018 (UTC)

"a true "peak" will always offer some kind of view" - note that this is true probably only in your local area. There are many forested peaks with no view whatsoever Mateusz Konieczny (talk) 06:23, 17 June 2018 (UTC)

And anyway, just because all objects tagged with X can be also tagged with Y does not mean that Y should not be tagged Mateusz Konieczny (talk) 06:30, 17 June 2018 (UTC)

Astronomy

Would it be fair to tag a viewing area for astronomers as a viewpoint? Most of the places also have good views during the day, and are usually named. I am referring specifically to places like Ice House Observation Plateau, or Old Iron Mountain.

Maybe an additional tag could be added, like type=astronomy

--gappleto97 00:39, 16 June 2018 (UTC)

Places that have unusually good views during day may be clearly tagged. For dark sky locations without good views during day I would invent a separate tag, if any. Mateusz Konieczny (talk) 07:06, 16 June 2018 (UTC)

fenced/fall hazard

I'm trying to come up with a tag to either say this viewpoint is fenced and generally safe so long as you don't go climbing the fence, or unfenced with a fall hazard off the edge of the lookout. --Aharvey (talk) 09:35, 13 March 2022 (UTC)

For the latter, simply hazard=fall?

For the former, there was actually protection=* before it's changed to separation=* in Proposed_features/cycleway:separation. Personally think it can still be used (as in protection=fence) here) when there is no parallel features next to the object (would be separation:*=not_required). to show edge barriers preventing falls and restraining crashes.

--- Kovposch (talk) 11:20, 13 March 2022 (UTC)

There is also case that viewpoint is in place that is flat without fall hazards Mateusz Konieczny (talk) 11:56, 13 March 2022 (UTC)

Spotting points for airplanes

Aircraft spotting

It would be nice to have a tag to indicate viewpoints suitable for "plainspotters" [1]. I tried documenting myself on the wiki and mailing list and I've found nothing. So I will BE BOLD and, following any tags you like, I would like to start proposing viewpoint=planespot to indicate a "viewpoint suitable to take good photos of airplaines, taking off or landing" --Valeriobozz (talk) 09:56, 18 September 2022 (UTC)