Template talk:Ordnance Survey coordinates

Un-coordinated coords

(Reposted from VPT)

Here is an extract from the table in Grade II listed buildings in the London Borough of Wandsworth:

Name	Location	Type	Completed	Date designated	Grid ref. Geo-coordinates	Entry number	Image
Wandsworth Common Windmill	Wandsworth Common	Windmill	19th century	7 March 1983	TQ2657774519 51°27′18″N 0°10′41″W	1183658	Wandsworth Common Windmill More images

If I click on the Lat/Long coordinates, the GeoHack page gives me an OS ref of TQ2657774519, which matches the OS ref in the entry. If, however, I click on the OS ref in the entry, it gives me a GeoHack page with OS ref TQ2646474573 (51° 27′ 19.83″ N, 0° 10′ 46.59″ W) - nearby, but significantly different. Looking at the template source, this seems to be a problem with #invoke:Ordnance Survey coordinates.

Note: The EH header parameters include references to Barking and Dagenham. I think this is an old cut-and-paste error, unconnected with this problem.-- Verbarson  ^talk_edits 13:51, 15 December 2023 (UTC)

To save anyone else jumping to the same conclusion as I did (oh, it's just rounding): although the longitude is essentially identical in both, the latitude is out by 2 seconds. (51° 27′ 19.83″ N rounds to 51° 27′ 20″ N). 𝕁𝕄𝔽 (talk) 18:12, 15 December 2023 (UTC)

Judging by their plots on OpenStreeMap (though that brings in another whole layer of communication and conversion) the longitude is more different (in distance) than the latitude. -- Verbarson  ^talk_edits 18:31, 15 December 2023 (UTC)

Having done some conversions myself about three decades ago, I suspect that the algorithm being used performs the correct conversion between lat/long and eastings/northings (within the same "datum") but does not perform a "change of datum". The "datum" specifies where the centre of the spheroid is. The worldwide datum is WGS84, but Ordnance Survey uses OSGB36. There is something about this at Ordnance Survey National Grid#Datum shift between OSGB 36 and WGS 84. I seem to remember that the fix involved converting lat/long to xyz, applying an offset, and then reconverting back to lat/long. Without the fix, you get an error of the order of 100 m to 300 m, depending on which part of the country you are in.  Dr Greg  talk  18:56, 15 December 2023 (UTC)

The instructions, from the OS themselves, appear to be here, for anyone who wishes to check or update the code. -- Verbarson  ^talk_edits 19:36, 15 December 2023 (UTC)

@Hike395, is this something you can help with?  Dr Greg  talk  20:05, 15 December 2023 (UTC)

@Verbarson, Dr Greg, and JMF: This is a bug in geohack, not in Module:Ordnance Survey coordinates. I have had a fix all ready to go for four years (see ) but no one seems to want to take the fix. It's unclear whether geohack is being actively maintained any more. Perhaps if other editors upvoted it at bitbucket.org? — hike395 (talk) 22:29, 15 December 2023 (UTC)

More specifically, the OS grid ref in the table (above) is incorrect (probably copied from geohack's buggy output). If you want "ground truth", try the calculator here. Entering (51.455,-0.178) at that calculator yields TQ 26690 74465. Clicking on that link gives you back (51.455, -0.178) at the top of geohack. Everything works and is consistent. Geohack's own conversion to OS coords is broken. Someone needs to fix Grade II listed buildings in the London Borough of Wandsworth (and probably lots of other pages) — hike395 (talk) 22:54, 15 December 2023 (UTC)

I have certainly used it to put OS grid refs into many {{PoIgb}} lists, assuming it was authoritative. But until I found the EH listing templates, I didn't know of any way (other than manually locating the numbers on an OS map) to check the output. The good news is that using {{GeoGroup}} on the Wandsworth Grade II listing page shows most coordinates in pairs on the same location. The reason I noticed the Wandsworth windmill is that it was a single flag; I found the OS ref for it originally pointed to Clapham Common's Windmill Drive! I 'corrected' it using GeoHack, and then I realised it was still incorrect. -- Verbarson  ^talk_edits 23:04, 15 December 2023 (UTC)

Oh dear. Would it be possible for you to go back and fix the entries in the {{PoIgb}} lists? I would hate to see geohack errors propagate out into the world. — hike395 (talk) 23:30, 15 December 2023 (UTC)

Yes, over time. Mainly lists of stations on historic or heritage railways. I can search for articles with PoIgb and Verbarson in the source, and check them. Is there a bulk translation tool? -- Verbarson  ^talk_edits 23:42, 15 December 2023 (UTC)

There appears to be a batch conversion tool here, but I haven't tried it yet. — hike395 (talk) 00:09, 16 December 2023 (UTC)

Spot checked it against the first 5 entries at Grade II listed buildings in the London Borough of Wandsworth: it matches my code and preserves round-trip accuracy. It should be fine to use. — hike395 (talk) 00:18, 16 December 2023 (UTC)

@Verbarson: I see that you pasted TQ2657774519 into the article today. As you can see, you cannot trust geohack's OS grid refs. The calculator at movable-type is reliable. — hike395 (talk) 23:01, 15 December 2023 (UTC)

@Verbarson: I just updated this module in a way that may make your life much easier. I've added the inverse code (that takes lat long and produces OS grid refs, by porting my fixed PHP to Lua). What we can do is change {{PoIgb}} to automatically generate the OS grid ref from the lat long provided, without you having to look it up manually for many cases. You just leave the fourth parameter blank for {{PoIgb}}. I've implement this in the sandbox over there. You can see it in action at the testcases. I'm not sure which is better: should the generated OS grid ref be a map link or just a plain OS grid ref string? Either is very easy to do at this point. Which would you recommend? — hike395 (talk) 08:19, 16 December 2023 (UTC)

@Hike395:, that sounds wonderful; so I could just blank the (incorrect) OS refs and they would be recalculated each time the page displayed? If I used SUBST:, would that store the answer the first time and save recalculation every time?

Map links: a 'problem' I see with {{EH listed building row}} is that it emits two map links, one for the lat/long and one for the OS grid ref. When displayed by {{GeoGroup}}, this shows every map location as a double marker. This is only really helpful when one of the values is wrong, which is how I spotted this issue in the first place. Therefore I would suggest that the lat/long remains the only map link in {{PoIgb}}. (And if you can change {{EH listed building row}} similarly, it would improve the map for that as well!)

Ideally, perhaps both of these templates should accept a lat/long and/or a grid ref, and calculate whichever is missing, and emit a single map link, but I don't know what effect that would have on the existing code or current articles. (It's very easy to think up hifalutin' ideas for other people to implement.) -- Verbarson  ^talk_edits 10:11, 16 December 2023 (UTC)

...and thanks for sorting out the windmill. -- Verbarson  ^talk_edits 10:29, 16 December 2023 (UTC)

Yes, you would simply blank any OS ref and it will get recalculated from the lat/long. I'll modify the main template to use a plain string (with 6 digits, like TQ123456).

I would not use subst, because that will confuse and cause more work for other editors. Remember that Wikipedia caches pages between edits/image/template updates, so subst does not save money when people read WP. Also, this is a microscopic amount of computation: it would take roughly 4 million edits (per module invocation) to cost Wikipedia one British pound. I think it would be better for the community if you just donate a quid to WMF. Or I can, if you like.

Your other ideas are good, but will take more work/investigation. I will try them out sometime soon, but am busy IRL right now, so it won't be immediately. — hike395 (talk) 16:55, 16 December 2023 (UTC)

Six digits sounds a bit approximate - isn't that a 100m resolution? I generally use at least 10m resolution for buildings and other railway features. GeoHack always returns ten digits, but eight is quite acceptable. -- Verbarson  ^talk_edits 21:07, 16 December 2023 (UTC)

Six digits is indeed 100 metres; eight is 10 metres; and ten is to one-metre accuracy, which is well into WP:OPCOORD for most locations. --Redrose64 🌹 (talk) 21:25, 16 December 2023 (UTC)

Very easy to change directly in {{PoIgb}}: I'll change it to 8, but feel free to adjust. — hike395 (talk) 21:34, 16 December 2023 (UTC)

I have gone back over the PoIgb entries I have created, and blanked the OS refs. Many were 10-digit refs I took from GeoHack; some were 6-digit refs I took from other pages (usually station articles). They are all now consistent and accurate to the lat/long. -- Verbarson  ^talk_edits 23:57, 16 December 2023 (UTC)

Non-wiki links disguised as wikilinks

@Hike395: is there a reason that this generates a Wikilink when it is actually an external link? Compare:

• {{gbmappingsmall|SU616687}} → SU616687 vs SU616687

Zackmann (^{Talk to me}/_{What I been doing}) 18:48, 31 May 2026 (UTC)

The former has an extra span wrapping it:

<span class="plainlinks nourlexpansion" style="white-space: nowrap">[https://geohack.toolforge.org/geohack.php?pagename=Template_talk:Ordnance_Survey_coordinates&params=51.413982_N_1.115628_W_region:GB_scale:25000 SU616687]</span> →

SU616687

[https://geohack.toolforge.org/geohack.php?pagename=Template_talk:Ordnance_Survey_coordinates&params=51.413982_N_1.115628_W_region:GB_scale:25000 SU616687] →

SU616687

I don't remember why this extra span is there -- I think it's historical from the old template before Lua conversion. I can poke around. — hike395 (talk) 19:10, 31 May 2026 (UTC)

The code was added by Ahecht back in 2020. Perhaps they remember why this span was added? — hike395 (talk) 19:16, 31 May 2026 (UTC)

More digging --- Ahecht ported {{Ordnance Survey coordinates}} over to Lua in 2020. The original choice for using these span classes was done in 2015, also by Ahecht. hike395 (talk) 19:19, 31 May 2026 (UTC)

Just to be clear, did NOT mean to "blame" you for this, I just saw that you had done a ton of work on this module. Do you (or Ahecht) have any objection to removing this span? I generally think it is a bad idea to disguise non-wikilinks as wikilinks. Regardless of the initial reasoning behind it being done in 2015 (which I will be VERY impressed if Ahecht can remember 11 years later), does it make sense to keep it now? Zackmann (^{Talk to me}/_{What I been doing}) 22:05, 31 May 2026 (UTC)

I wouldn't remove the span, but instead just remove "plainlinks" which implements the behavior you find objectionable. "nourlexpansion" only affects the output when printing (i.e., without it, the full URL gets added to the page when printing).

I don't object to removing "plainlinks". — hike395 (talk) 23:33, 31 May 2026 (UTC)

Facepalm Sorry that was what I meant... Remove the behavior, not the span as a whole. Thought one thing, typed another. Zackmann (^{Talk to me}/_{What I been doing}) 23:46, 31 May 2026 (UTC)

 Done Zackmann (^{Talk to me}/_{What I been doing}) 23:49, 31 May 2026 (UTC)

@Zackmann08 It's been a while, but I believe it's because generally toolforge links done with [[toolforge:geohack]], as opposed to using external link syntax, show up without the external link icon, e.g. toolforge:geohack. It was toollabs, not toolforge, at the time, but the same logic applied. Looking at the history, it was removed when the link target was changed to a non-WMF server, and then re-added by @Hike395 in Special:Diff/912981712 when switched back. No objection to removing it if there is consensus to do so. --Ahecht (TALK
PAGE) 01:16, 1 June 2026 (UTC)

@Ahecht: your memory is far better than mine. Unsurprising that in the 11 intervening years things have changed! Went ahead and removed the plainlink class but can of course always be readded if needed. Zackmann (^{Talk to me}/_{What I been doing}) 03:23, 1 June 2026 (UTC)

New proposal --- I didn't remember that geohack doesn't have the little external link icon (i.e., it is a wikilink). I have a new proposal.

By default, this module creates a geohack link. But if |direct=1, it generates a direct link to a external service that provides an OS map. Thus, I propose adding an if statement: if |direct= evaluates to "yes", suppress "plainlink", otherwise add it. What do editors think of this? — hike395 (talk) 08:21, 1 June 2026 (UTC)

Template talk:Ordnance Survey coordinates/Archive 1#Please use protocol-relative URL for tools.wmflabs.org link is from when plainlinks was added. --Redrose64 🌹 (talk) 16:53, 1 June 2026 (UTC)

Thanks, Redrose. It's clear that the span has been there for a long time. Upon reflection, I think I misfactored the code when I ported to Lua. All OS links should be wrapped in the span (with nowrap).

I've reflected this in the new sandbox code --- now there is one single function in _main that returns a span around an anchor when rawurl is false. "plainlinks" is added when it's a geohack link (per Ahecht), but not when it's a direct external link (per Zackmann). The _oscoord entry point remains but is an alias for _main. I modified the test cases to reflect the new behavior -- all sandbox tests pass.

Any comments or suggestions before I make this go live? — hike395 (talk) 14:39, 5 June 2026 (UTC)

 Done Promoted sandbox to main. Please let me know if there are any issues. — hike395 (talk) 14:43, 7 June 2026 (UTC)