Proposal:Info on web-presence
Info on web-presence | |
---|---|
Proposal status: | Abandoned (inactive) |
Proposed by: | Spaetz |
Tagging: | Info_URL=<URL> |
Statistics: |
|
Rendered as: | none or e.g. earth-symbol if there's an Internetaddress available |
Draft started: | |
Proposed on: | 2007-03-25 Modified_by: Fröstel 2007-11-21 |
voting is suspended until the proposal is modified according to the criticism
- Modified (RFC)
Rationale
To many objects we're currently mapping there also belongs a website, giving further up-to-date information by the people/company running the object. This will be useful when you want to look at the menu of a restaurant, check the current exhibitions of a museum or the temperature of an outdoor swimming-pool and so on.
This is not supposed to link Wikipedia because there is an other proposal for that (which also covers website links). When there are several websites for one object this tag should point to the one of the person/company who's also running/owning the physical object.
Tagging
The shortest name for web-adress is URL. But as there could be more than one resource for an object, using different protocols things should be tagged as:
- url:http = http://www.tour-eiffel.fr - for websites
- url:webcam = http://www.paris-live.com - for webcams
Because http will be the most used protocol tags without any protocol will be assumed to be http. So url=domain.com will be trated like url:http=http://domain.com.
If desired a language code can also be added like url:http:en= or url:http:de. But if the website has a start-page allowing the user to choose his language himself this should be avoided.
Info: URL stands for Uniform Resource Locator, see Wikipedia for more information.
Applies to
This can apply to anything.
Rendering
Rendering in a map doesn't apply. But a click able link in applications would be neat.
Opinion
- why not just URL rather than info_url? Or WWW to denote a web address of a facility? info_url could be anything like a wikipedia entry on that amenity --spaetz 22:54, 25 March 2007 (BST)
- As a pedant, I'd certainly prefer url= as evolving technology may bring us useful URLs other than websites. However the Proposed features/External links proposal suggests using website. It is well developed, easily understandable and has been adopted unofficially for identifying cities, towns villages using a set of name=, place=, is_in and optionally website= and wikipedia=. I suggest this proposal be dropped? MikeCollinson 10:19, 11 June 2007 (BST)
- As a pedant, I'd replace url= with uri= ;) --Cohort 01:51, 8 July 2007 (BST)
- As a pedant, I'd certainly prefer url= as evolving technology may bring us useful URLs other than websites. However the Proposed features/External links proposal suggests using website. It is well developed, easily understandable and has been adopted unofficially for identifying cities, towns villages using a set of name=, place=, is_in and optionally website= and wikipedia=. I suggest this proposal be dropped? MikeCollinson 10:19, 11 June 2007 (BST)
- You need the http://, since it might be https:// (or something else) and there's no guarantees that a given url will be redirected from insecure to secure (even if most, in practise, are). Gravitystorm 17:22, 21 November 2007 (UTC)
- I'd suggest website= since a URL/URI can refer to other things, and this makes it clear what we're talking about. Also, it's probably best to insist on a full URI, including the http:// part, because then we can apply well defined validation rules to it (or rather editing tools and validators can). --Geoff 03:37, 22 November 2007 (UTC)
- Website= vs URI=
- Given that future expansion must be covered, website= restricts this tag to web sites; but leaves scope for webcam=, h.232= and any other future tag.
- URI= limits this, in my view. <pedant>Websites are a subset of URI so shouldn't have exclusive use of it</pedant>
- URI:service= works, and gives a degree of consistency, but has no advantage I can see as the 'service' part is going to resemble the website= part, so all we're doing is to add 10,000,000 copies of 'URI:' to the database. I'd prefer to keep to website=, and exclude the http:// for the same reason.--DrMark 15:46, 22 November 2007 (UTC)
- I think website= is better, because the URL for a node is something like http://www.openstreetmap.org/api/0.5/node/599877 ramack 21:31, 24 November 2007 (UTC)
- Website= vs URI=
- I´d suggest uri:<isocode>=http://foo.bar along with uri_description:<isocode>=<description>. This way you would get something like this for a Node:
- name:de=Braunschweig
- name:en=Brunswick
- uri:de="http://www.braunschweig.de"
- uri_description:de="Deutsche Webseite der Stadt Braunschweig"
- uri:en="http://www.braunschweig.de/english/"
- uri_description:en="English website of Brunswick (City)"
You would need one node for the official name and website and another node for e.g. each webcam. But that wouldn´t be any problem at all, IMO. And PLEASE leave the http:// in the uri, as URI is universal by definition :-) The Renderer can decide what Icons to show, based on this information. Everything else should go into the uri_description tag. -- motp 13:33, 25 November 2007 (UTC)
Reading the wikipedia page about url and uri, I would prefer url as we refer to an actual location. I would say website is too restrictive and url would be better. Please leave the http:// prefix, just in case we need other protocols (mappers will do it as they want to do it anyway. -- Ulfl 00:39, 26 November 2007 (UTC)
- Thank you for all the comments, I've read and considered them carefully before praparing the proposal for voting. I believe that the current proposal leaves open all options for the future but keeps tagging easy in the pragmatism typical for OSM. -- Fröstel 20:50, 16 January 2008 (UTC)
Having url:http and url:webcam seems me to be mixing up two totally different things. "http" is a protocol, "webcam" is a type of thing you find at the other end of the link. Anyway, the "http" is not needed, because it already is part of the URL. I strongly suggest not allowing domain names only as the value of this tag. The whole point of a URL is that it is universal, if you start abbreviating it, you'll get cases that are not unique/clear any more. On the other hand, I think allowing several sub-keys is a good idea. I could imagine something like "link" (short for say "link:homepage"), and then "link:webcam", "link:contact", "link:whatever" (I think I prefer "link" to "url"). Having said all this, I am not sure whether we really want a general URL tag. I forsee the day this will get spammed to death. -- Joto 21:25, 16 January 2008 (UTC)
- I like the idea of webcam tag, but I think plans should be made to easily show a webcam image directly on the map. For this, url:webcam is perhaps a bit too generic, as the webcam url could be anything from a framed web-site to a java app to a still image. url:webcam is fine for humans I guess, but for embedding the image to a map, something more detailed would be useful, like url:webcam:still for direct still images (like .jpg/.png), url:webcam:html for images inside some kind of html page, and whatever are the suitable protocols for embedding a video stream into the map. The Finnish road administration has quite a lot of weather cameras on the roads which can be used to look whether there's snow, ice etc and it would be quite nice to see the images (still images taken every 10 minutes or so) embedded in an OSM map application --Jkp 15:18, 7 October 2009 (UTC)
Voting
- I approve, disapprove or abstain this proposal. -- username date
- I disapprove this proposal -- Joto 21:15, 16 January 2008 (UTC) (the mixture of the several versions of this tag is rather strange and needs more discussion)
- I disapprove this proposal, but would approve url=domain.com (we might need/add url_webcam or url:webcam later) -- Ulfl 03:09, 17 January 2008 (UTC)
- I disapprove of this proposal -- Robx 11:22, 17 January 2008 (UTC)
- This voting is suspended until the proposal is modified according to the criticism above. -- Fröstel 12:32, 17 January 2008 (UTC)
See also
- Proposed features/External links - linking to Wikipedia
- Proposed features/Phone