Talk:Key:website

Simple vs. specific URLs

I object to the recommendation against using specific URLs. They might last longer, but could in many cases make the whole URL more or less useless. Consider the case of hiking route relations: A hiking route relation describes a hiking route, so defined often my a destination company or hiking association. An example is this URL http://www.hovden.com/no/TellusView/?&TLl=no&TLp=564065 which points to a page about that specific route. The simple URL would be http://hovden.com. If you go to the latter, you could spend quite some time trying to find the information you want, while if you go to the first you get there instantly. --Dittaeva 16:26, 22 February 2012 (UTC)

As far as I am concerned, this recommendation means that you should choose simple URLs over complex URLs if they basically point to the same content. So for example, you would use http://www.bahn.de instead of http://www.bahn.de/p/view/index.shtml, because while both get you to the front page of that website, the second variant depends very much on the current implementation of their site and doesn't add any maningful information. --Tordanik 17:13, 22 February 2012 (UTC)

I see. I'll try to edit it to reflect your understanding of it which does make sense. --Dittaeva 10:23, 23 February 2012 (UTC)

separating multiple values with space

hi,

it seems reasonable to to divide multiple values not with a semi-colon in this case but with a space. I just tried it and was surprised that it actually already works on osm.o: (see 1941952571 1941952571)

--Shmias 22:42, 1 October 2012 (BST)

Multiple values are unnecessary for a website tag, though, because it is meant to contain "the official website". This might be a useful suggestion for Key:url. --Tordanik 12:50, 2 October 2012 (BST)

as far as I can see, this feature is deprecated. I also had a problem with multiple values because urls are usually long and values may not be longer than 255 characters. does anyone have a better idea where to place that stuff? --Shmias 10:44, 3 October 2012 (BST)

We shouldn't encourage crippled URLs

I really don't like the idea of omitting the http:// because it cripples the URL. The article should not written in a way that users may be encouraged to omit the "http://" (or "https://"). Remember, the string is not neccessarily the same string which is presented to the user, it is stored in a file, waiting to be processed by software. There are quite some programs which expect to parse URLs. Not crippled URLs, almost-URLs or "urls without the scheme". The good thing about URLs is that most programs already understand how they work; no extra code has to be written. . The purpose of an URL is to get munched by a program directly. It is generally a bad idea to require applications to give OSM a "special treating" because there has to be extra code just because OSM doesn't give a damn about Internet standards. What comes next? Suggesting to drop the "www."?

There should be at least a pointer to RFC1738 section 3.1, section 3.3 (for the http scheme) and RFC2818 section 2.4 in the article for reference. (Update: I just did it anyways --Wuzzy 23:44, 28 November 2012 (UTC)) And there should be a clarification that the value should be a valid URL. You really need only to read these three relevant sections to understand URLs and these are rather short. You don't even need to fully understand URLs to use them: Just copy the frikking address bar of your browser! Nothing can be easier than that. ;-)

I know at least one program which interprets the value always as an URL and fails badly if it is not an URL. It is a plugin in JOSM which adds an entry to the context menu for the website tag. I think this plugin does it absolutely right, and this definition made it wrong.

Here's my suggested new definition for the website key:

Just copy the frikking address bar of your browser! ;-)

I personally consider it an error if I encounter a "website" tag without the proper scheme. I always add the scheme in front of it, check if it works and if it does, I upload the change, if it doesn't, I remove the website key. By the way: Is there any quality assurance tool in the wild which checks URLs for (syntactic) validity?

If there are no serious objections within a week, I would change this wiki page in a way that it clearly expresses that only full URLs should be used and not crippled ones. I also would remove the "no scheme if http" exception then. --Wuzzy 23:15, 28 November 2012 (UTC)

Disagree with the suggested "Just copy the frikking address bar of your browser!" definition because of the #Simple vs. specific URLs issue. But otherwise, yes, the http:// should imo be included in the value. I've always read that section as a suggestion to application authors for a potentially useful fallback, not as a guideline for mappers. So I would support a clarification in that direction. --Tordanik 17:03, 29 November 2012 (UTC)

Okay, my friends. The time is over! I just removed the section in discussion, with respect to Tordaniks little objection. --Wuzzy 20:27, 6 December 2012 (UTC)

If this would be a generic URL field I would fully agree, but it is not. It is a tag to specify a website. Apart from the very, very few websites that can only be reached via https all of them use http. Adding the protocol does not give OSM any advantage and is redundant. The argument of "some software" that needs to parse URLs is also invalid. The content of the field are not full URLs, so no URL parser is to be expected to be able to parse it. A scheme of "crippled" URLs (they are not URLs actually, the wording is wrong) are used for wikipedia articles too and works very well and has been so for a long time. The removal of the section explaining all this (IIRC) and abandoning the scheme by a single user is... at least impolite, Wuzzy. --Stefanct 23:01, 13 January 2013 (UTC)

The old definition (before I touched it) was too ambigious. I am aware that https-only websites are rare but https-enabled websites are not. Even Google has HTTPS! And if I have the choice between the HTTPS and the HTTP version of a certain website, I’d rather link to the HTTPS version (except when it’s broken). And there are way more HTTPS-enabled websites than you’d believe, so I don’t think that HTTPS is a strange side case. Don’t believe me? Look at HTTPS Everywhere! Also note that the old definition in fact already included the abbreviation “URL” some times, so one may legitimely think to use a full URL as value. On the other hand, the definition allowed to drop the “http://” part. This was a contradiction, so the definition HAD have to be changed. I chose full URLs because URLs are very common and standarized. I call the other definiton “crippled” URLs because the definition implied (sort of) that one could “omit the ‘http://’ part”. Sorry, but this sounds very much like “URL without schema”, I fail to see how this definition does not relate to URLs. My software argument is not invalid. The big advantage of strictly using full URLs only for this scheme is a software may not have to parse the URL at all, it could simply blindly give the value to a browser (for instance). I also don’t think it a good practice to mix well-defined standarized URLs with “crippled” URLs (or call them “non-URLs” or “strings that look like URLs but aren’t” or whatever).

The wikipedia argument is a false analogy because the wikipedia tagging scheme is not even similar to an URL, because the common format is "lg:Pagename" with lg=language code and Pagename=name of page (usually with spaces). You never have real spaces (read: unencoded) in an URL and the “:” character has a completely different meaning in URLs. Most important, the wikipedia scheme is clear and unabigious, therefore I didn’t touch it.

In my view, the current definition is clear and unabigious. The old definition was ambigious. Someone had to change that. I hoped some more people would discuss with me but only one was interested who also agreed on the important part, then I got tired of having a ambigious definition and just went on. Yes, I may be bold. But be bold is a common wiki motto. And I didn’t simply edit, nope, my edit was based on a rational decision. As there are still no serious counter-arguments (I just have dismantled your counter-arguments.) after about one-and-a-third months, I do not regret this decision.

If you are still not convinced, please keep in mind that a simple revert would not help, because you’d revert to all the problems the old version had. --Wuzzy 20:48, 17 January 2013 (UTC)

+1. The Protocol belongs into the tag value. I would even suggest to prefer specifying HTTPS whenever the website supports it. Well maybe except for self-signed certificates but that is a tricky question anyway.--Scai 09:29, 18 January 2013 (UTC)

Deprecate this tag when it is used to provide contact information in favor of contact=*?

Reason: contact=* is more clear and precise way to link URL with world/POI objects. Xxzme (talk) 06:52, 20 July 2014 (UTC)

When I look at the relative popularity, I think it makes much more sense to deprecate contact:website. --Tordanik 14:06, 20 July 2014 (UTC)

Yes but you look it in wrong way. contact=* is not single tag but group of tags, to compare them fairly you have to sum all contact tags vs something. You have to use website=* 3 times vs there precise ways of contact contact:twitter=* contact:facebook=* contact:webcam=*. Contact is not limited to websites. IMO website=* should be deprecated when it is used to provide contact information, contact=* does this job better. Xxzme (talk) 06:50, 22 July 2014 (UTC)

Alright, if you want to look at contact as a group, let's compare the full range of contact keys.

	no prefix	contact:*		2019 no prefix	2019 contact:
website	551 879	43 154	[1]	1 876 455	249 677
phone	363 319	66 195	[2]	1 505 277	327 212
email	69 684	25 787	[3]	364 760	126 833
fax	47 138	17 807	[4]	126 181	61 044
facebook	778	849	[5]	18 198	51 844
twitter	372	236	[6]	1 991	14 608
webcam	58¹	213	[7]	51	1 479
sum	1 033 228	154 241

¹ I used url:webcam here

(I was curious what the numbers would be today, so I added columns for 2019.--Look4book (talk) 08:14, 6 December 2019 (UTC) )

I don't think this looks better for the contact keys. Except with the rarely used facebook and webcam keys, the usage counts are clearly in favour of the alternatives. --Tordanik 18:52, 25 July 2014 (UTC)

Well, okay, they are 10 times more popular. But again, my point is still valid. Contact: namespace is precise way to specify information linked with phone number or facebook page. Some of phone=* values are not contact phones, but emergency phones. I personally use delivery: namespace to specify delivery phone (quite often this is different from contact phone where you can book table). To avoid confusion we need to use namespaces for each purpose, contact: is just one of them. Xxzme (talk) 05:06, 19 August 2014 (UTC)

Most phone numbers are contact phone numbers. It makes much more sense to use emergency:phone for a exception. Also if you care that much about contact then you should remove 50% of the Social Media pages, because you can't actually reach most businesses that way. --AndiG88 (talk) 20:49, 21 October 2014 (UTC)

Administrative vs Tourist Website

Many countries, states, cities have both an administrative website and a tourist website, I understand website= should be the admin website, but how can we also store the tourism website? Aharvey (talk) 11:02, 16 June 2017 (UTC)

Website with more languages

Is it ok to use website:en for english website see node/1547924149 - Salgo60 (talk) 14:52, 11 January 2019 (UTC)

I'd say it's ok, although I wouldn't exactly recommend it in most cases because it's extra manual work. Ultimately, I would consider it the website owner's responsibility to direct the user to their language of choice, for example by respecting the Browser's language setting. --Tordanik 20:30, 14 January 2019 (UTC)

Key:website#Best_practice modification

Last year following information was added to the Key:website#Best_practice:

* Facebook and Twitter pages are fundamentally not websites. You should not link to them with the website tag, even if this is the only presence of the place on the web.
while edit: https://wiki.openstreetmap.org/w/index.php?title=Key:website&diff=1672887&oldid=1648838
* Pages on social media are fundamentally not websites. You can use contact keys for that: contact:mastodon, contact:facebook, contact:twitter…
while edit: https://wiki.openstreetmap.org/w/index.php?title=Key:website&diff=next&oldid=1725102

Was this done based on any discussion before? --Huuser (talk) 11:46, 15 October 2019 (UTC)

Hi, no, this was done based on the notion of website, there was no OSM-specific discussion as far as I remember. For Facebook pages, there are specific tags. —M!dgard [ talk ] 06:59, 22 October 2019 (UTC)

Thanks for response and information. For my understanding the osm website tag is a wider concept as you can also find in the notion of website (maybe check wikipedia), like web presence (as you also wrote in your first edit), or see dutch wording "aanwezigheid op het web", or german "Webpräsenz". From this background i see websites (with sub-page structures) inside of social websites also good for osm website tag (e.g. for cases when a small business don't want pay money to a web-hoster and instead "want" pay data to any social media "web-hoster"). For demonstration 2 examples (facebook / wordpress) website inside of websites with sub-directory structure

mainpage facebook https://www.facebook.com/small-business-name/ (home)

sub-pages: https://www.facebook.com/small-business-name/about/

sub-pages: https://www.facebook.com/small-business-name/photos/

sub-pages: https://www.facebook.com/small-business-name/events/

sub-pages: https://www.facebook.com/small-business-name/posts/

sub-pages: https://www.facebook.com/small-business-name/videos/

sub-pages: https://www.facebook.com/small-business-name/reviews/ and so on

mainpage wordpress https://small-business-name.wordpress.com/ (home)

sub-pages: https://small-business-name.wordpress.com/about/

sub-pages: https://small-business-name.wordpress.com/contact/

sub-pages: https://small-business-name.wordpress.com/how-we-work/

sub-pages: https://small-business-name.wordpress.com/members/

sub-pages: https://small-business-name.wordpress.com/products/ and so on

For cases there is only web presence on social media hoster and this is currently used for website i'm okay to tell people (in Key:website#Best_practice) it would be a good idea to write down this information also to the more specific social media contact: tags, but i would not recommend to delete this from osm website tag as said again if this is the only web presence. Also because many (most) data consumer (e.g. apps like osmand, maps.me, an so on) don't use the osm social media tags for evaluation, but most start with evaluation of osm website. Do you know any application which is currently read out tags like contact:wordpress ?

By the way, there is not only website available (where this best practice could apply), there are also url and contact:website available.

So would you agree the modify the best practice advise

from current

* Pages on social media are fundamentally not websites. You can use contact keys for that: contact:mastodon, contact:facebook, contact:twitter…

to

* Pages on social media should be better placed to the contact scheme keys for that, see: contact:mastodon, contact:facebook, contact:twitter, contact:wordpress and so on. If a social media web presence is the only web presence of the POI (point-of-interest) on the web, then it is okay to leave such a redundant item at website…

Although I don't know the full history, I would not consider a Facebook page (even with subpages) a "website" and would therefore prefer to uphold the currently documented best practice. Supporting the contact: keys is very easy, so if applications do not display links to social media platforms, this is most likely a conscious choice by the application authors. Imo, that choice should be respected, not undermined by copying the desired URLs into website=*. --Tordanik 17:18, 17 November 2019 (UTC)

That sounds like tagging for the renderer to me. It is not up to the application developer to decide that a Facebook page cannot be an official website. If a Facebook page is the organisation's only presence on the web, then we need some way of indicating that it is the official presence. Leaving out the website may mean that the website is simply not known and using website=no or website=Facebook doesn't make sense, so I've gone ahead and added the text: Pages on social media should be tagged with the contact scheme keys for that, see: contact:mastodon, contact:facebook, contact:twitter, contact:wordpress and so on. If a social media web presence is the only web presence of the POI (point-of-interest) on the web, then some taggers prefer to also list the url on website to indicate that no other official website exists. -JoeG (talk) 01:04, 31 January 2021 (UTC)

This is a rather roundabout manner of expressing that no official website exists, and I can see several issues:

• If the POI has no website, but multiple social media presences, which of them should be copied into website=*?
• If the POI has no website and no social media presence, how would we then indicate that no official website exists?

I feel that what's needed is precisely a "website=no" tag (e.g. nowebsite=yes – we already have noname=yes and noaddress=yes). Why do you believe that doesn't make sense? --Tordanik 20:18, 13 February 2021 (UTC)

Thanks! Multiple social media presences seem to not be that common (except for Facebook mirroring photos to Instagram) precisely because the organisation is often using the social media page as its sole official website. The second issue is more convincing to me - I would support a nowebsite=yes tag, but the proliferation of noX=yes tags might become an issue. The reason I didn't support website=no is because it mixes urls and "no", but I suppose it's not a big issue if data consumers are made aware this can occur. I think we are still left with a situation where organisations sometimes do use a social media platform as their official website, but now agree that this could be dealt with in multiple ways. website=no seems like the most elegant but least convenient option... -JoeG (talk) 21:10, 13 February 2021 (UTC)

New key website:orders

Rtfm (talk) This tag, website:orders, has only been used one time. Please make a proposal if you wish to add it to this page or Map Features. Otherwise, it is now documented at Key:website:orders - also please don't include links to commercial websites like bleiblokal.wirvsvirus.net - I assume you have no bad intentions with this, but it's inappropriate to link to for-profit websites not related to Openstreetmap. --Jeisenbe (talk) 13:50, 28 March 2020 (UTC)

Mobile URL

Should the use of mobile URL be discouraged? Overpass: https://overpass-turbo.eu/s/1Qb0

Example: Prefer https://facebook.com/example/ over https://m.facebook.com/example/ ecc. --Ivanbranco (talk) 22:31, 23 August 2024 (UTC)

I support adding this to the Best Practices section. Even though mobile browsing is becoming more and more common as time goes on, most regular links will redirect to mobile versions on relevant platforms or screen sizes, but opening a mobile link on the desktop doesn't usually redirect to the normal version. Lumikeiju (talk) 17:09, 24 August 2024 (UTC)