Template talk:Relation

This template is beginning to take way too much space, can't we make a nicer solution to get all those links in a more compact way? --Eimai 13:46, 13 May 2009 (UTC)

• What's abouts using one letter per link, f c b m, for full - check - browse - manage. Same could be done for the smal version "Template:BrowseRelation" --Behrica 19:56, 13 May 2009 (UTC)

To keep it as user-friendly as possible (and I'm talking for non-mappers who are browsing the wiki, as well as mappers), I think it'd be good to cut it down so that it links to 'browse' view from the number. From there you can get to the XML (API) view in one click anyway - or developers could just copy and paste the number. The two external tools (check and manage) could be included if you specified them as an option (eg {{Relation|12345|check=yes|manage=yes}}). Frankie Roberto 22:41, 28 June 2009 (UTC)

Okay, so I've hidden all the extra links, unless you specify tools=yes. This brings the template more in line with how the Node and Way templates work (which link to browse only by default). Frankie Roberto 14:18, 4 July 2009 (UTC)

And I've now reversed that behaviour so it hides everything when tools=no instead. Either that or change all pages using the template to show them with all tools so those pages don't become useless. --Eimai 11:30, 5 July 2009 (UTC)

Fair point. Happy for the default to be changed so that existing pages stay consistent. Frankie Roberto 21:35, 5 July 2009 (UTC)

• How about adding "view" and a link to e.g. http://www.openstreetmap.org/?relation=2345 ? --Wieland 11:45, 1 October 2009 (UTC)

• Long time ago a remark was made on this subject. I want to suggest to punt on the short tools part also the link to GPX creation. This would be very usefull. ( BrowseRelation = <number> (x a r j h g) ) g=http://osmrm.openstreetmap.de/gpx.jsp?relation=--ZMWandelaar 18:42, 17 April 2011 (BST)

Default value for tools parameter - revisited

It's been a long time, but I still think the default should be tools=no. Right now this template is inconsistent with Template:Node and Template:Way which by default only show the id with a link to osm.org. Many of the tools are somewhat redundant anyway - "view", "xml", "JOSM" and "Potlatch" are all available from the browse page - and most of the others specialise in route relations (i.e. only 10 % of relations). Is there a chance that we can switch the default? --Tordanik 10:25, 25 June 2013 (UTC)

I agree. If nobody objects I would try to change it. --Tigerfell  (Let's talk) 11:49, 2 September 2018 (UTC)

Change done! Hopefully nothing was forgotten. --Tigerfell  (Let's talk) 10:30, 29 September 2018 (UTC)

some pages broke with the last change

I got a report about Florida/Railroads#Main_2 - seems like this template is used without any params, and it breaks Lua code. Btw, you might want to use unit testing we have, check out this usage example (parses page titles into language, key, value) --Yurik (talk) 03:56, 30 September 2018 (UTC)

The option to use the template without an ID was dropped in this version. A list of dropped options is available in the documentation. The reasoning is also outlined there.

In a recent diary entry (section 2 bullet 2) I outline my suggestion to change the current situation. This would need some time, however, as I have to obey the Automated Edits Code of Conduct. I would actually prefer to change Template:Node, Template:Way, and Template:Area first to do all semi-automated edits in one go. --Tigerfell  (Let's talk) 10:37, 30 September 2018 (UTC)

Does the Automated Edits Code of Conduct even apply to the Wiki? I was not under the impression that it does. -- Prince Kassad (talk) 11:08, 30 September 2018 (UTC)

The answer at IRC was somewhat vague. It was said that it does not explicitly apply to the wiki, but it was suggested to follow it and start with an email to talk mailing list. --Tigerfell  (Let's talk) 14:32, 30 September 2018 (UTC)

It is great that we have unit testing. I will try it out. --Tigerfell  (Let's talk) 14:32, 30 September 2018 (UTC)

"Trying it out" is what is done with testing BEFORE code is deployed to the greater world. I've been a professional software engineer (sometimes in quality assurance) for decades and this rollout of Relation breaking existing wiki (in huge amounts, with huge BrowseRelation-with-empty-value calls) is unfortunate. Let's restore something like the old behavior of "Relation not defined yet" instead of LARGER TYPE RED TEXT LUA ERROR, please. The human effort to rewrite hundreds or thousands of wiki pages to back-fit this new code seems too high. For what? The cost of a few extra compute cycles to detect a well-established practice of embedding an empty-value function call and return a polite string, as our wiki code once did? The logic, reasoning given for this change seems wholly upside-down to me, especially as it dismisses that a fair amount of wiki is already written with this convention and its original expected behavior.

I think it's great that Relation is being "tuned up" (or improved, however you want to say it). However, breaking existing conventions of how wiki is written today is "a bridge too far." Stevea (talk) 19:43, 9 October 2018 (UTC)

There seems to be a misunderstanding (still). This is the 2nd change to these templates. The first one already happened (without objections), this is why the documentation on the flip side mentions the differences between the first and the second version (so the first change). Then Yurik approached me and I was informed about unit tests. There were other tests performed before the first change.

My plan is to use a semi- or fully-automated process to do the changes, hence the long time for people to speak up like you did. When talking of human effort please remember that this is a project of volunteers. In that light, I would guess almost every effort is wasted as I do not get a monetary advantage from that (nor someone else).

In my eyes, you miss the positive effects of this change: pages like Beijing Bus were rendered correctly for the first time as the parser could not cope with the old template version. --Tigerfell  (Let's talk) 22:42, 9 October 2018 (UTC)

It does seem things/fixes/consensus/approval/communication are happening in a bit of "slow motion" (hey, what's new: this is OSM!), and I do thank you for what this does improve up above. I think we are on the same page, it is just like "radio communication with Mars," a little bit of delay about what is being done, how we are communicating about it, what problems have been seen, what we are doing about those problems, etc. I don't get paid either, so thanks to all OSM volunteers who do NOT get paid! Stevea (talk) 23:03, 9 October 2018 (UTC)

That is good to know. I sent messages to all channels listed at Automated Edits Code of Conduct, wrote a blog entry, and basically wait since then for any form of reaction. As some users reacted, I guess it must have reached them, but if you have suggestions for better communication please speak up. --Tigerfell  (Let's talk) 23:29, 9 October 2018 (UTC)

Communication in OSM seems to have gone from "pretty good" (wiki, talk-pages for country/tech/import..., the forum, there are many that are "built-in" and "open") to "not so great" as we are turning into a "Tower of Babel" with such proprietary methods as Slack. IRC is good, but needs improvement. About five months ago, with another very techy and dedicated OSM volunteer he told me about and I began to explore some IRC/open-source bridges (Jabber/XMPP stream has also been bridged in both directions with the IRC channel, so that IRC users are equal participants. And, things like Pidgin, Swift, Psi+ and AstraChat surely could work). But very widespread communication about important changes in the project (OSM) are getting more difficult to successfully complete: we all seem to be so "fragmented" both by language/region/country and the tech we (both do and are willing to) use. For example, I won't / can't use Slack as I it is proprietary (very much against an "open data" project) and I cannot abide its license terms. Hopefully this will get better, but for now I'm not sure how.

It appears you did your due diligence to communicate your change intents, I'll take responsibility for not "seeing" them. On the whole, you and I are "good," but all of us in OSM should keep our eyes open to similar problems going forward into our future. Stevea (talk) 23:45, 9 October 2018 (UTC)

A minor correction to my last: this wasn't really that great of a problem, more like a difficulty of communication and how that seems to be happening more often in OSM. Stevea (talk) 05:22, 10 October 2018 (UTC)

Thanks for clarification and your comments regarding my proposed changes. As a precaution, I will wait until the weekend with the preparation just in case someone just found this. I recently thought of sending such emails to [talk-de], [talk-gb], and [talk-us] too as they seemed to be fairly used, but I guess it would fail its purpose as this is not related to the countries. If a new form of communication comes up which seems acceptable to me (optimum: open source, appropriate terms of use and privacy, some digest option so you are not force to stay online for hours, basic topic filtering) I am happy to join!

Just as an information: I am currently looking for a new map extension to be installed in this wiki. Link to the discussion --Tigerfell  (Let's talk) 08:06, 10 October 2018 (UTC)

Do you mean something like the present-day "slippymap" capability? (An example is here, but for a year or two it has "API Key Required" watermarked over the top of it, like we need to renew an API license). It is Andy Allan (with whom I've exchange many emails, often thanking him for his tile rendering) who provides the tiles, but he has yet to answer my question about this. Stevea (talk) 08:20, 10 October 2018 (UTC)

Ah, yes, I followed the link and I'm continuing the discussion there. This thread has gotten too long anyway! Stevea (talk) 08:26, 10 October 2018 (UTC)

Tools: OSM Route Manager

How about adding https://osmrm.openstreetmap.de ? As far as I know, this is the one-and-only Super-Relation tool around ... --Kannix (talk) 07:45, 25 April 2020 (UTC)

This is kind of ironic. There used to be a link to this service. When I refurbished this template in September 2018, I noticed that OSMRM was not reachable for several days. Then I emailed the official email address of openstreetmap.de webmasteropenstreetmapde on 19 September 2018 asking whether it would be an issue if I would remove the broken links. I never received a reply. A week later, this same webmaster stopped their tile stitching service which was heavily used by this wiki, breaking thousands of map displays in this wiki. This same webmaster also refused to find any solution (see a hidden GitHub issue and [1] publicly visible). I learned that openstreetmap.de is apparently unreliable and not cooperative when supporting OSM.

Those three reasons resulted in removal of the links. Is there a compelling reason that this has changed now? --Tigerfell  (Let's talk) 10:38, 25 April 2020 (UTC)

sad story...

who maintains https://www.openstreetmap.org/relation/ ? pimping this to visually support Super-Relation might be the way to go? --Kannix (talk) 17:15, 25 April 2020 (UTC)

osm.org is maintained by the Operations Working Group. You can propose changes at openstreetmap/openstreetmap-website ^GitHub. --Tigerfell  (Let's talk) 17:18, 26 April 2020 (UTC)