Template talk:Ordnance Survey coordinates

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

503 service unavailable?[edit]

Links to OS coordinates via this template currenly (2 July) are returning

Toolforge

No webservice The URI you have requested, /os/coor_g/?pagename=Swanbourne_railway_station&params=SP832316, is not currently serviced.

If you have reached this page from somewhere else...
This URI is part of the os tool, maintained by RHaworth .

That tool might not have a web interface, or it may currently be disabled.

If you're pretty sure this shouldn't be an error, you may wish to notify the tool's maintainers (above) about the error and how you ended up here.

If you maintain this tool

You have not enabled a web service for your tool, or it has stopped working because of a fatal error. Please check the error logs of your web service.

Would someone (RHaworth?) who knows about these things please investigate? --John Maynard Friedman (talk) 16:35, 2 July 2019 (UTC)[reply]

RHaworth is aware, see e.g. User talk:RHaworth/2019 Apr 27#OS coordinates down; User talk:RHaworth#Grid references. --Redrose64 🌹 (talk) 20:27, 2 July 2019 (UTC)[reply]

Getting back up 2019[edit]

To Op47, hike395 and any one else with the skills to fix this matter.

As noted above circa 2019 April my conversion tool which this template calls stopped working. I thought it was removed because the tools.wmflabs.org server was being shut down so why is geohack still there and running? I will be delighted if someone will take over responsiblity for this tool.

Clearly, a first check to be done by someone who knows their way around wmflabs is: are the oscoor files still there but disabled? Assuming they have gone, please download rhaworth.net/tmp/oscoor.zip. In this zip:

  • The entry point for Grid Ref to lat/long conversion is /os/coor_g/coor_g.php. (I think there should be a file /os/coor_g/index.php but its content would be simply: require_once("coor_g.php"); )
  • I think that /os/coor_g/geohack.php is a version of a (probably long out of date) state of https://tools.wmflabs.org/geohack/geohack.php modified to do an Helmert transformation between the WGS84 --> OSGB36 co-ordinate systems. (They don't tell you when you visit the RGO at Greenwich but the prime meridian now lies about 100 metres east of the observatory!)
  • The contents of /geohack/ are probably long out of date files from https://tools.wmflabs.org/geohack/ .
  • /1doc/ is just other stuff on my computer which may prove useful.

If you have any queries please contact me - phone calls are welcomed - numbers here. — RHaworth (talk · contribs) 19:48, 14 August 2019 (UTC)[reply]

silly question: why use wmflabs at all? wouldn't it make sense to write the "conversion" in lua, and generate normal {{coord}} template?
surely the conversion can't be _that_ complex. i can't think of something this conversion does which is that much simpler in php than it will be in lua.
if anyone can point to some source for "the formula", i'm reasonable certain this can be done without shedding too much of either blood, sweat, or tears. peace - קיפודנחש (aka kipod) (talk) 16:38, 15 August 2019 (UTC)[reply]

It is probably just as easy to write in lua. I wrote in PHP because that is a language I speak and, more importantly, because that is what geohack.php is written in. You need to download oscoor.zip - don't be put off by the size of the file - 95% of it is a zip-within-a-zip that is probably of no interest. As I explain above, the only files needed are in the /os/ directory. The heart of the conversion is /os/coor_g/transversemercator.php. — RHaworth (talk · contribs) 17:52, 15 August 2019 (UTC)[reply]

@RHaworth: I have NGR2LL ported over to Lua on my own computer, but I'm finding an issue exactly reproducing the coordinate of this template. For British OS coordinates, I have to append a "5" to the northings and eastings strings. But, for Irish OS coordinates, I don't need to do this. If I handle these cases differently, then I can reproduce what this template does.
As I understand it, there is a square on the surface of the Earth that is consistent with any one OS string. Appending a "5" shifts the coordinate to point to the center of the square, right? Otherwise, without the 5, the coordinate points to the southwest corner of the box. Wouldn't this be true of both British and Irish OS strings? Shouldn't I append a "5" to both? Or are Irish OS strings differently defined than British ones?
Once you can help straighten this out, I will wikify the Lua (hooking the NGR2LL code to the geohack/coordinate system), and then hopefully we can eliminate any dependency on wmflabs or other external servers. —hike395 (talk) 16:18, 18 August 2019 (UTC)[reply]
The convention with OS grid refs, at least the Great Britain ones, is that you never round up - excess digits are simply ignored. That means that a gridref indicates the southwest corner of a square, and the size of a square is indicated by the number of digits. So grid ref SU5290 is a 1km square which includes the 100-metre squares from SU520900 to SU529909 inclusive; also the 10-metre squares from SU52009000 to SU52999099 inclusive. --Redrose64 🌹 (talk) 20:11, 18 August 2019 (UTC)[reply]
@Redrose64:, can you confirm that OS grid refs in Ireland behave in the same way? With the new Lua code, it's trivially easy to flip between sending geohack the center of the square or the SW corner of the square. I am happy to defer to the experts in how to set the flag for both GB and IE. —hike395 (talk) 00:17, 19 August 2019 (UTC)[reply]
I should clarify: whilst the calculation involves the southwest corner of a square, the feature may lie anywhere within that square. So if the marker is positioned at the southwest corner, it has something like a 75% chance of being further from the true position than a marker positioned at the centre. --Redrose64 🌹 (talk) 07:54, 19 August 2019 (UTC)[reply]
@Redrose64: I agree that the center of the box produces lower error on average. Do OS grid refs in Ireland behave in the same way (e.g, referring to the SW corner?) Found this document from the OS of Ireland which says that the Irish OS grid works the same way. Therefore, I would be in favor of using box centers for both GB and Ireland. —hike395 (talk) 11:56, 19 August 2019 (UTC)[reply]

@RHaworth and Redrose64:  Done --- IE OS grid refs now have geohack coordinates that are in the center of the grid box, rather than SW corner. Easy to revert if there are any issues. —hike395 (talk) 17:43, 24 August 2019 (UTC)[reply]

It just occurred to me that there is no "right" answer for rounding: it depends on the mental model of whomever creates the lower-resolution grid ref. If the editor (or reliable source) truncates the string (TZ 1234 5678 -> TZ 123 567), then we should add a 5 to be more accurate. If the editor or reliable source rounds the string to the nearest grid point (TZ 1234 5678 -> TZ 123 568), then we should truncate.
Is there a custom for this in the UK or Ireland? Otherwise, I have to go through a sample of articles and see if I can figure out whether low-resolution grid refs are rounded or truncated. I'll start doing that. —hike395 (talk) 18:31, 24 August 2019 (UTC)[reply]
Later --- I did an analysis of 40 sampled articles, comparing their lat/long values to their OS grid ref values. Of these articles, 26 had lat/long values within the precision of the OS grid values. If we treat the lat/long values as the ground truth, 14 would be more accurate using the SW corner of the box, while 12 would be more accurate using the center of the box. So it looks like a toss-up.
What I've done is removed the box-centering for GB and IE. For editors who use infoboxes, I fear that the box centering will appear to be mysterious and broken. Better to produce values that they can verify against external OS grid calculators. Comments or thoughts? —hike395 (talk) 01:07, 25 August 2019 (UTC)[reply]
Truncation is not just a "custom", but a specification. At one time, OS maps had a detailed description inside the cover, this later got moved to the sheet margin where it still is (bottom right corner of 1:50000 Landranger). The most recent that I have is from 2016 and includes the text Locate first VERTICAL grid line to LEFT of point and read LARGE figures labelling the line ... Estimate tenths from the grid line to the point It's clear that if rounding had been intended, they wouldn't have stressed the word "left" but would have used wording like "Locate nearest grid line to left or right of point". See also The National Grid FAQs and the links under "Useful downloads" in the right margin. --Redrose64 🌹 (talk) 07:37, 25 August 2019 (UTC)[reply]
Thanks, that's helpful. The FAQ links to a batch converter. I've been playing a bit with OS kilometer values (e.g., SK1373), and the batch converter doesn't round --- it reports the lat/long of SK1373 to be the SW corner of the SK1373 box. That's useful to know. I'm analyzing further data, will report back if I find anything definitive. —hike395 (talk) 15:40, 25 August 2019 (UTC)[reply]
I think, by the way, that we have bigger problems that deciding on whether to shift coordinates by 50 meters to the NE. All five of the OS grid refs for Irish villages seem to be hundreds of meters off. This seems to be very old data in WP, before there was careful data verification. We may need to do something about that. —hike395 (talk) 15:47, 25 August 2019 (UTC)[reply]

Fixed it myself … sort of[edit]

I uploaded the files to a location that they used to occupy and to my delight they worked instantly. What is needed now is:

  • someone please take me by the hand and show me how to upload these files on to a Wikimedia server
  • add the Helmert transformation into geohack.php. See this example using Nutbourne Windmill: coor_g.php takes the gird ref of TQ 07840 18863 and translates it into lthe correct lat/long then geohack.php translates it back to a grid ref of TQ 07730 18923 - an error of 110 metres on eastings and 60 metres on northings.

— RHaworth (talk · contribs) 21:31, 15 August 2019 (UTC)[reply]

I'm afraid I cannot help with wmflabs, but hopefully someone else can? I would suggest asking for help at WT:WikiProject Geographical coordinates. —hike395 (talk) 04:38, 18 August 2019 (UTC)[reply]
Which is a redlink. The corresponding non-talk page doesn't exist either. --Redrose64 🌹 (talk) 10:48, 18 August 2019 (UTC)[reply]
Probably meant Wikipedia talk:WikiProject Geographical coordinates Keith D (talk) 14:58, 18 August 2019 (UTC)[reply]
Yes, sorry. Fixed. —hike395 (talk) 16:18, 18 August 2019 (UTC)[reply]

Now converted to Lua[edit]

@RHaworth:  Done --- I finished the Lua code today, now live at Module:OS coordinates. I have changed the template to use the Lua code, instead of calling out to RHaworth's server. This is not a big computational burden: it takes <10 milliseconds to convert from an OS grid ref to lat/long, when an article is edited.

I've left the rounding as RHaworth had it in his server code (GB = center of box, IE = SW corner of box).

Let me know if you see any problems! —hike395 (talk) 00:17, 19 August 2019 (UTC)[reply]

Great. Coords now working again. Many thanks Hike395. Dudley Miles (talk) 18:03, 24 August 2019 (UTC)[reply]
You're welcome! This has been a fun little programming project. —hike395 (talk) 18:20, 24 August 2019 (UTC)[reply]

Module name[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: pages moved: - Module:OS coordinates → Module:Ordnance Survey coordinates, Template:OS coord → Template:Ordnance Survey coordinates, based on consensus below. I've also updated the documentation, let me know if I've missed anything. (closed by non-admin page mover) Steven Crossin Help resolve disputes! 14:07, 23 September 2019 (UTC)[reply]


– Match module name with template * Pppery * it has begun... 19:43, 25 August 2019 (UTC)[reply]

I would prefer if we moved the template to have a name with full English words (per WP:TPN). Thus, I would suggest instead Template:OS coord → Template:OS coordinates. Or, if we must, name them both "Ordnance Survey coordinates" (although I believe that is overkill) —hike395 (talk) 19:59, 25 August 2019 (UTC) --Relisting. –Darkwind (talk) 07:30, 19 September 2019 (UTC)[reply]
Agree with the template move being a better name and tbh, the full name you wrote would be even better. The short (redirect) version will always be available, but it will make the name understanable right away. To me "OS" is "Operating system" which made no sense in this context. --Gonnym (talk) 20:09, 25 August 2019 (UTC)[reply]
As usual with these requested moves, I only care that the module and the template have the same name, not what that name ends up being. * Pppery * it has begun... 20:12, 25 August 2019 (UTC)[reply]
I can see Gonnym's point that "OS" is not a well-known acronym for "Ordnance Survey" outside of people who use maps in the UK and Ireland. So, I would propose
Module:OS coordinates → Module:Ordnance Survey coordinates
Template:OS coord → Template:Ordnance Survey coordinates
—hike395 (talk) 01:58, 26 August 2019 (UTC)[reply]
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

External service for Wikidata[edit]

@Hike395 and RHaworth: You've done a great job inlining this as a Lua module, and incorporating the Helmert transform -- but would it be possible to get the external service up and running again too? It was being used for Wikidata property OS grid reference (P613) on Wikidata, which can't call a template, only include the string in a URL to send to an external service.

It would be great if this could be got working again -- eg I'm just about to upload a quantity of 'official' grid references for Scottish listed buildings, and it would be nice if they could be working links rather than just strings. Jheald (talk) 13:24, 22 November 2019 (UTC)[reply]

I can't really help with setting up a new external page, maybe RHaworth can. If Lua doesn't work on Wikidata, maybe we can try to get geohack to accept OS grid refs as input directly? It has code (albeit buggy) to convert OS grid refs back to lat/long. I haven't had any success in getting the geohack owners to fix the bugs, so getting them to accept OS grid refs may be difficult. — hike395 (talk) 20:49, 22 November 2019 (UTC)[reply]

Failure 2020[edit]

For some reason use of the template now brings up a 404 error on the geohack site. Can anyone help, I freely admit I'm way out of my depth on this! Murgatroyd49 (talk) 20:01, 28 June 2020 (UTC)[reply]

Thanks for reporting it. Looks like geohack has changed. I've got a fix. — hike395 (talk) 06:23, 29 June 2020 (UTC)[reply]
Thanks very much. Murgatroyd49 (talk) 08:15, 29 June 2020 (UTC)[reply]
Further thanks for the fix. The links can produce different results eg [1] and [2] and a third version similar to the Wey Mills result but without the Great Britain table alongside at the top. I cannot find an example quickly but recall it being a problem somewhere and will supply an example if and when I find one. The Great Britain table can be particularly important as it includes the National Library of Scotland (NLS) historic maps link. Why are different results possible and how can an editor choose which results are shown? Ping Murgatroyd49 for info.SovalValtos (talk) 09:13, 29 June 2020 (UTC)[reply]
The presence or absence of the GB table alongside the main list is controlled by the region: option: your second example has region:GB but the first does not. Valid region codes are listed at ISO 3166-2:GB so you could use region:GB-DEV for Meldon Viaduct, but in practice, refining beyond GB doesn't make a difference. --Redrose64 🌹 (talk) 09:40, 29 June 2020 (UTC)[reply]
User:Redrose64, hike395 the region code fix will suffice for now for my level of editing and should be helpful for Tony Holkham who has come across the same problem. One might expect the region code to be added automatically depending on the coords region, but then that could introduce other problems and be less flexible. How comes a map is sometimes displayed; it does not seem to depend on the region? Can the particular map be changed to suit context or is it best to keep to a simple general map? I will understand if you tell me to research it myself!SovalValtos (talk) 10:14, 30 June 2020 (UTC)[reply]
a map is sometimes displayed; it does not seem to depend on the region? Which map? On which pages does this happen? --Redrose64 🌹 (talk) 18:32, 30 June 2020 (UTC)[reply]
An example before Murgatroyd49 recently changed it is [3]SovalValtos (talk) 19:51, 30 June 2020 (UTC)[reply]
So you mean the "Wikimedia maps" map on the GeoHack page - this is used as a placeholder when no region is specified and so there cannot be a "Great Britain" table (or similar) to show. --Redrose64 🌹 (talk) 22:32, 30 June 2020 (UTC)[reply]

This template always uses either GB or IE region codes, because OS grid refs are only defined for those two countries. The general {{coord}} template does not.

I'm planning to change what maps this template displays -- I'm curious what other editors think. Given that this template is for an OS grid reference, it makes sense (to me) that the link click through to an Ordnance Survey map, as opposed to giving users a huge number of map choices. If they want a large number of map choices, they can click on the {{coord}} link.

The most robust server for Ordnance Survey maps is Bing, so I was going to hardwire the Bing OS map into the URL.

Another advantage of avoid geohack is that now WikiMiniAtlas grabs all of the coordinates on a page and shows them as dots. The OS grid ref is usually close, but not identical to, the lat/long coordinates. Thus, there are now two confusing dots on the WikiMiniAtlas. Directly linking to OS maps will avoid this.

What do editors think of linking directly to OS maps? — hike395 (talk) 21:07, 30 June 2020 (UTC)[reply]

I'm against it. When I'm editing the article of a long-closed railway station, and am adding the OS grid ref, I verify that by clicking it and selecting one of the various services that show historic (or just plain "old") OS maps. I can't verify it by using Bing, because it may be buried under a supermarket. --Redrose64 🌹 (talk) 22:39, 30 June 2020 (UTC)[reply]
Time for caution in making changes. Perhaps a new section is needed to get opinions as this is complicated?SovalValtos (talk) 02:35, 1 July 2020 (UTC)[reply]
OK, it sounds like there is utility in allowing a choice between OS maps. I don't know how to do that without linking to geohack. @Redrose64: do you happen to know a way to suppress the WikiMiniAtlas for a specific link? I have been poking around, but have not found one. — hike395 (talk) 22:14, 3 July 2020 (UTC)[reply]
Yes: make sure that a region is provided. --Redrose64 🌹 (talk) 23:01, 3 July 2020 (UTC)[reply]
GeoHack with the Great Britain region having been selected and provided supplies my needs within GB. Other readers or editors may prefer the Wikimedia maps instead of the region options. Why though does the article Sardis, S Pembrokeshire act as if a region had been selected when I cannot find it as having been added in edit mode? I do not understand what exactly GeoHack is and despite having read articles and edited for years had not noticed one could scroll down for more regions. If a region outside Great Britain is selected for the link to GeoHack the options are more limited and further many links in GeoHack do not work, so Wikimedia maps is better than the local links. eg [4] with Bulgaria selected (actually region:BG) where neither region link works for me, nor does the "Popular link" to Google Earth which tries to save!SovalValtos (talk) 00:35, 4 July 2020 (UTC)[reply]

@SovalValtos: The template authors are trying to help you out, which may be leaving you confused. The Sardis, S Pembrokeshire article uses {{Infobox UK place}} which automatically injects "GB" as a region into {{coord}}, so the region shows up in the title link and the link at the bottom of the infobox. The |os_grid_reference= parameter internally calls {{Ordnance Survey coordinates}}, which uses region:GB for the OS grid ref link, also. Contra RedRose, both of the links also have WikiMiniAtlas globes. — hike395 (talk) 05:00, 4 July 2020 (UTC)[reply]

As noted by Hike395, Sardis uses {{Infobox UK place}} which includes code to inject two parameter values into {{coord}}. It's this block near the bottom 
{{#if:{{{coordinates|}}}|{{#invoke:Coordinates|coordinsert|{{{coordinates}}}|region:{{#ifeq:{{{crown_dependency|}}}|Isle of Man|IM|GB}}|type:city{{#iferror:{{#expr:{{formatnum:{{{population}}}|R}}*1}}||({{formatnum:{{{population}}}|R}})}}}} 
|}}
see Module:Coordinates. These injected values are: (i) either region:IM or region:GB, depending upon whether |crown_dependency= is specified or not; and (ii) either type:city or e.g. type:city(12345) depending upon whether |population= is blank or not.
If many links in GeoHack do not work, that is something to bring up at Template talk:GeoTemplate (this is the first "Talk" link in the left sidebar of the GeoHack page), but you need to specify the article that you reached the GeoHack page from, besides the non-working links.
I don't see what Bulgaria has to do with anything: this is the talk page for discussing improvements to the template {{Ordnance Survey coordinates}}, and O.S. coordinates are not defined outside the British Isles (they're not even defined for the Channel Islands, even though the true origin for OS grid refs lies a few miles to the south of Jersey).
Nobody mentioned a globe until today. I had previously asked which map was meant, and the reply given by SovalValtos led me to believe that the "Wikimedia maps" map on the GeoHack page was meant. Nobody then corrected my misapprehension. I wish people would be precise about the problems that they perceive, so that I don't have to waste time running along false trails. Anyway, assuming that "WikiMiniAtlas globes" means the globe displayed in the article before clicking the link, that cannot be suppressed. --Redrose64 🌹 (talk) 09:42, 4 July 2020 (UTC)[reply]

Adding name parameter[edit]

Hello! I'd like to add a name parameter, which adds a custom title (&title=...) to the Geohack URL.

This uses the same parameter name that is used on the Coordinates module. It's useful when the page name isn't an appropriate title and the caller wants to override it. It's also useful on pages with many grid references, where they can be mapped using the {{GeoGroup}} template which uses the name parameters.

I've implemented it on the sandbox and added test cases, they pass and it seems to work well.

Thanks - odg (talk) 17:25, 16 August 2020 (UTC)[reply]

 Done Very nice! Thanks! — hike395 (talk) 04:12, 17 August 2020 (UTC)[reply]
@OliverGalvin: As an extra bonus, I modified the following templates:
{{gbmappingsmall}} now takes |name= and passes it along to {{Ordnance Survey coordinates}}. Quite handy for list articles (see List of lighthouses in Wales that I just modified).
{{gbmaprim}} uses its second argument both for the display string and for the custom Geohack title.
Hope this helps! — hike395 (talk) 06:33, 17 August 2020 (UTC)[reply]
That's great, thanks! They were going to be my next edit requests. I also changed {{English Heritage listed building row}} so that it passes the name parameter to {{gbmappingsmall}}. - odg (talk) 17:53, 17 August 2020 (UTC)[reply]

Un-coordinated coords[edit]

(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 [note 1]Date designated Grid ref.[note 2]
Geo-coordinates 		Entry number [note 3]Image
Wandsworth Common Windmill Wandsworth Common Windmill 19th century 7 March 1983 TQ2657774519
51°27′18″N 0°10′41″W / 51.455°N 0.178°W / 51.455; -0.178 (Wandsworth Common Windmill) 		1183658
Wandsworth Common Windmill
Wandsworth Common Windmill
More images
  1. ^ The date given is the date used by Historic England as significant for the initial building or that of an important part in the structure's description.
  2. ^ Sometimes known as OSGB36, the grid reference is based on the British national grid reference system used by the Ordnance Survey.
  3. ^ The "List Entry Number" is a unique number assigned to each listed building and scheduled monument by Historic England.

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  talkedits 13:51, 15 December 2023 (UTC)[reply]

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)[reply]
Map this section's coordinates using OpenStreetMap

Download coordinates as:

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  talkedits 18:31, 15 December 2023 (UTC)[reply]
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)[reply]
The instructions, from the OS themselves, appear to be here, for anyone who wishes to check or update the code. -- Verbarson  talkedits 19:36, 15 December 2023 (UTC)[reply]
@Hike395, is this something you can help with?  Dr Greg  talk  20:05, 15 December 2023 (UTC)[reply]
@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 [5]) 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)[reply]
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)[reply]
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  talkedits 23:04, 15 December 2023 (UTC)[reply]
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)[reply]
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  talkedits 23:42, 15 December 2023 (UTC)[reply]
There appears to be a batch conversion tool here, but I haven't tried it yet. — hike395 (talk) 00:09, 16 December 2023 (UTC)[reply]
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)[reply]
@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)[reply]

@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)[reply]

@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  talkedits 10:11, 16 December 2023 (UTC)[reply]
...and thanks for sorting out the windmill. -- Verbarson  talkedits 10:29, 16 December 2023 (UTC)[reply]
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)[reply]
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  talkedits 21:07, 16 December 2023 (UTC)[reply]
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)[reply]
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)[reply]
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  talkedits 23:57, 16 December 2023 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Ordnance_Survey_coordinates&oldid=1213301493"