Wikipedia talk:Coordinates in infoboxes/Archive 2

coordinates param
Planet	TEST
Coordinates	1°N 2°W / 1°N 2°W

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Process seems to be losing coordinate citations

I have noticed that the bot that is doing this is not doing anything to preserve the citations for coordinates (and yes, of course they need to be cited—I've run into a number of cases where someone seems to have just pulled coordinates out of the air). This is playing havoc with the lighthouse infobox because I'm seeing other people coming along afterwards and just deleting the citation because someone else change the template to eliminate the citation parameter. Sometimes the citation doesn't get entirely lost because it is often used for one of the other values (focal height, for instance) and ANOMIEbot comes along and at least undeletes it. Can we do something about this? Mangoe (talk) 02:31, 14 March 2017 (UTC)

@Mangoe: Any examples? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:48, 14 March 2017 (UTC)

@Jc86035: Could it be the loss of the coordinates_footnotes parameter from the Infobox lighthouse template? -- WOSlinker (talk) 13:08, 14 March 2017 (UTC)

@WOSlinker: I've readded the parameter, as that was almost definitely an oversight. @Jonesey95: do you think this happened to any other infoboxes? I do think the parameter isn't totally necessary, but it isn't included in any of the replacement wrappers AFAIK. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:10, 14 March 2017 (UTC)

Do we see any way to go back through and fix these? I personally don't have time to work through the details of WP automation to fix this. Mangoe (talk) 15:14, 14 March 2017 (UTC)

The case I noticed was Lake Borgne Light: you can see the bot goes through, and then someone else came through with AWB and lopped off the citation because it's attached to the lost parameter, and then ANOMIEbot came through after that and "rescued" the citation because it was used for another parameter but no longer defined. Mangoe (talk) 15:14, 14 March 2017 (UTC)

This was my error. I don't think I removed |coordinates_footnotes= or |coords_ref= or similar parameters in any other cases. I looked through all of my edits to Infobox templates for the week before and after this edit, and I found no other instances of removal of such a parameter, and two or three cases where I left it in, explicitly moving it to the right place.

I don't see any other edits by JohnBlackburne (who removed the coordinates_ref parameter when it was temporarily unsupported) to lighthouse articles, and there are no other articles in Category:Pages using infobox lighthouse with unknown parameters that are listed there because of |coordinates_footnotes=. Someone might be able to use a watchlist to look at the changes in that category's membership to see if there are other articles that were removed from it by removing the coords ref. – Jonesey95 (talk) 16:37, 14 March 2017 (UTC)

Yes I removed it when it was breaking the map; I did look at the template for a coords_ref or similar field but failing that and not seeing anywhere else to put the ref I removed it, and a spare "$4" that somehow had ended up in there. I did look at it again after the most recent changes, to see the ref had been restored without breaking anything (it was in the category for templates with unsupported parameters then, but that now seems fixed).--JohnBlackburne^words_deeds 16:44, 14 March 2017 (UTC)

Can coordinsert include display=title?

It's been a while since I updated any of these infoboxes, and I either never knew this or forgot: when the module is invoked, can you use "display=title" with coordinsert? I know that you can use "type" and "region", but I haven't been able to get "display" to work. Thanks. – Jonesey95 (talk) 00:50, 27 March 2017 (UTC)

@Jonesey95: No, you can't (only the six GeoHack values are changeable, and then only for the URL and not in the parser function). I think this would be possible, but only for changing |display=inline to |display=inline,title (since the parser function can't be changed or removed by coordinsert). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 03:11, 27 March 2017 (UTC)

This is going to create a mess

Why have I only just found out about this? I have been messaged by EP111 (talk · contribs) at User talk:Redrose64#Deprecated latitude= and longitude= in UK disused station infobox regarding this change to an infobox doc page, my revert and their re-revert.

People who know anything at all about geographical coordinates will understand that latitude and longitude are fundamental concepts. They will know that given these two items of information, a point on a globe may be located. They may feel - rightly or wrongly - that those two items of information are all that is necessary, so for them, filling in a pair of parameters that are named |latitude= and |longitude= will come naturally; they won't worry about what happens to those figures. They see the coordinates link at the top right, and think "OK, job done, now move on". They may try out the coordinates link, and that's good.

The infobox in question is {{Infobox UK disused station}}, and given |latitude= and |longitude= alone - let's say |latitude=51.7213 |longitude=-1.2432 - will construct a {{coord}} on your behalf. For this specific case, the template that is automatically constructed for you is {{coord|51.7213|-1.2432|type:railwaystation_region:GB|display=inline,title}} and this has everything that you require with no need for further information.

Here's my problem. If we're getting rid of the |latitude= and |longitude= params, and replacing them with a single |coordinates= parameter, the people who know about geographical coordinates may not know what to put in there. They might simply enter bare figures and assume that the infobox knows how to process these - after all, it knew how to process the latitude and longitude when they had their own parameters. Are these people going to examine the template doc page, and (assuming that they do find the mention of the {{coord}} template) follow the link from there to another doc page which tells them how to fill in a {{coord}}? It's not a simple template: although there can be up to thirteen parameters (which can be daunting for some), only four of them are named. Quite apart from the fact that it allows the latitude and longitude to be provided in several formats, using anything from two to eight parameters for that purpose, it then has a mysterious unnamed parameter which appears after the coordinates proper, containing such codes as |type:railwaystation_region:GB - what on earth does "railwaystation_region" mean? It's only if you understand that an underscore is being used as a parameter separator, and not as part of a value, that it becomes clearer: two independent settings, type:railwaystation and region:GB. These are not intuitive settings, either - on occasion, I still have to explain to people why region:GB is important, so if they are expected to build their own {{coord}}, the probability of the region:GB being omitted is not low. Then, if they omit the |display= parameter, which is easily done if (again) its importance is not understood, they will not get the desired result of the coords appearing top right.

So instead of having hundreds of articles using {{Infobox UK disused station}} with |latitude= and |longitude=, producing consistent results, we will apparently have a similar number of articles using |coordinates={{coord|...}} and no guarantee of consistency. If people do their jobs properly, some will have |type:railwaystation_region:GB but others will lack one or both components of this.

Who is expected to periodically clean up the mess that will inevitably result? I spent several weeks checking every single transclusion of {{Infobox London station}} to ensure that the coordinates were given as |latitude=|longitude=, at the end of which we had remarkable uniformity. None of these articles have drifted away from that consistency of presentation. --Redrose64 🌹 (talk) 00:48, 22 March 2017 (UTC)

Just a quick comment: ~~It was this other change rather than this change to an infobox doc page.~~ (edit: Redrose64 has fixed it) I'll now leave this discussion to those more able to edit locked templates. Regards, EP111 (talk) 00:59, 22 March 2017 (UTC)

I recommend leaving the documentation in the former state (with the old lat and long parameters) until the template is converted. Once the template is converted, the region and type and display parameters will still be added automatically by the template when {{coord}} is used; editors will not have to add or understand those parameters and Redrose64 will never have to do any explaining. Editors will only have to add {{coord}} with a lat and long. Look at some of the converted templates on this project page to see how this has been accomplished.

Expect conversion of all of these templates to take at least a few months; there are hundreds of thousands of pages that need to be edited by the bot.

As for the fundamental question, if you read the RFC, it explains that before the RFC, there was quite a mix of lat and long parameters in infoboxes, leading to the exact opposite of the situation that Redrose64 describes; editors could never be sure of the lat and long parameter names. Once the conversion is done for all of these infoboxes, editors can always be confident that |coordinates=, using the {{coord}} template, will work in infoboxes and related templates (including Location map and Geobox), because we have created a standard. That is how standards are useful. It may not be the standard that 100% of editors may have wanted, but it was the one that gained consensus. – Jonesey95 (talk) 03:29, 22 March 2017 (UTC)

@Jonesey95: What a fuss... Just caught up in the crossfire. I'll stick with using |latitude= and |longitude= in the UK disused stations infoboxes, until it becomes clear that things are definitively different, and the bot can change whatever. Redrose64 (talk · contribs) is welcome to re-re-revert(!) my infobox UK disused stations/doc edit. Would you care for the body of Tuttle or Buttle? Regards, EP111 (talk) 04:33, 22 March 2017 (UTC)

@Redrose64: The proposal was advertised on WP:Centralized discussion for two weeks and received overwhelming support, and I don't think another RfC would garner enough support to overturn that decision. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:07, 22 March 2017 (UTC)

The coordinsert function can be used in the template to add in any missing params: {{#if:{{{coordinates|}}}|{{#invoke:Coordinates|coordinsert|{{{coordinates|}}}|type:railwaystation|region:GB}}}} -- WOSlinker (talk) 09:02, 22 March 2017 (UTC)

@Railwayfan2005 and Jonesey95: If the coordinates are not in the infobox, but elsewhere in the article, these edits mean that a "Coordinates" row is now added to the infobox where previously it was absent. See for example Horsham railway station. --Redrose64 🌹 (talk) 10:36, 31 March 2017 (UTC)

@Redrose64: Fixed. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:04, 31 March 2017 (UTC)

That's not a problem, it's the intention to have the coordinates in the info box. Just delete the coord from the bottom of the page when you stumble into one with both set. Railwayfan2005 (talk) 22:14, 1 April 2017 (UTC)

And yet I had to fix this mess. Leave things alone please. --Redrose64 🌹 (talk) 11:23, 2 April 2017 (UTC)

That was a mistake by Railwayfan2005, and the edit was not even necessary, since there were no deprecated coordinates parameters in the infobox. I don't know why they deleted useful information instead of just moving the coord template or leaving it alone. I have cleaned it up. The bot would not have made that erroneous edit. – Jonesey95 (talk) 13:33, 2 April 2017 (UTC)

The info box adds type:railwaystation_region:GB to the {{coord}} so it's not necessary to keep the those parameters in the edit. What else did Redrose64 find wrong with my edit? What information was lost? Railwayfan2005 (talk) 19:18, 2 April 2017 (UTC)

The previous version had coordinates top right as they always are for railway stations, also three complete rows in the "Location" section of the infobox. That by Railwayfan2005 (talk · contribs) added a row not previously present, and did not display coords top right. That by Jonesey95 (talk · contribs) left a blank row in the "Location" section. These edits had no positive benefit that I can find. Not only did Deor (talk · contribs) and myself expend time cleaning up after the two of you, I am clearly wasting time explaining something that you should have seen for yourselves. --Redrose64 🌹 (talk) 20:02, 2 April 2017 (UTC)

Scale issue in Infobox mountain

@JJMC89: I notice that scale:100000 seems to have been added to coordinates calls for {{Infobox mountain}} (and scale:300000 for range coordinates, see, e.g., Alps) This is unfortunate, because it overrides the dim value that is computed from length and width by {{Infobox dim}}. It's also mostly unneeded, because Geohack defaults to scale:100000 for all coordinates of type:mountain (see Template:Coord#type:T).

Can we have an automatic bot go through and remove scale: from mountain coordinate calls? I could do it with WP:AWB, but it would literally take me years. —hike395 (talk) 10:21, 19 May 2017 (UTC)

Later: I see that {{coord}} defaults to scale:300000 for coordinates with no type: parameter, so I would suggest keeping type:mountain, but no scale:100000 for |coordinates=; removing both type:mountain and scale:300000 for |range_coordinates=. This makes sense, in that range coordinates aren't really for single mountain peaks. —hike395 (talk) 10:32, 19 May 2017 (UTC)

@Hike395: When the bot edited Alps there were no values for |dim=, |length_km=, |length_mi=, |width_km=, |width_mi=, |area_mi2=, |area_km2=, and |scale=, so the bot added the scale to match the scale passed to {{infobox coord}} by {{infobox mountain}}. If any of those had a value, a "default" scale was not added. The bot is supposed to modify parameters in this manner so as to not effect the edited pages. I can write a script to remove those, but you'll need to start a discussion on Template talk:Infobox mountain to get support for it. (I need to show consensus for a BRFA.) — JJMC89 (T·C) 02:24, 20 May 2017 (UTC)

Infobox settlement: deprecated parameters removed

I have removed the deprecated parameters from {{Infobox settlement}}. It has a couple of wikidata calls in it, and I tried to preserve those as well as I could after some successful testing in the sandbox, but I will not be surprised if odd situations crop up. I have only rudimentary familiarity with wikidata. Feel free to check and improve upon my modifications to the infobox settlement template.

@JJMC89, Frietjes, and Jc86035:, could you please keep an eye on this talk page and on Template talk:Infobox settlement so that we can deal with any edge cases that crop up? Any article-space pages still using deprecated parameters should appear at the end of the unknown parameters category. Thanks. – Jonesey95 (talk) 13:49, 29 May 2017 (UTC)

It looks like there are nearly 5,000 pages with the following block of text in them:

| latd                    = 
| latm                    = 
| lats                    = 
| latNS                   = N
| longd                   = 
| longm                   = 
| longs                   = 
| longEW                  = E
| coordinates_display     = inline,title

Here is an insource search that lists them all, along with a few false positives. They will all show up at the end of Category:Pages using infobox settlement with unknown parameters eventually. Does anyone have a good idea for getting rid of these blocks of text? A bot request would probably work. Any other ideas? – Jonesey95 (talk) 17:22, 29 May 2017 (UTC)

There are a lot more than 5000 pages with the empty old parameters on them. This search which is just looking at Infobox settlement as well, lists over 60,000. -- WOSlinker (talk) 18:53, 29 May 2017 (UTC)

The empty ones do not concern me as much as the populated parameters, but there appear to be well over 10,000, maybe as many as 40,000 with |latNS=N or |latNS=S. It must have been part of a copy/paste template example for a while. We're gonna need a bigger bot. – Jonesey95 (talk) 19:53, 29 May 2017 (UTC)

Infobox coord nominated for deletion

{{Infobox coord}} is no longer used in article space. I have nominated it for deletion. – Jonesey95 (talk) 06:21, 5 June 2017 (UTC)

Infobox bridge

Why is the pushpin not displayed at Crumlin Viaduct? It uses {{infobox bridge}}. --Redrose64 🌹 (talk) 14:33, 7 June 2017 (UTC)

Because the |map_image= field was used rather than |map_type=. I've fixed it. Deor (talk) 15:13, 7 June 2017 (UTC)

Thank you --Redrose64 🌹 (talk) 15:30, 7 June 2017 (UTC)

Getting close to being done

I am working a little at a time on this list of infoboxes, and I've made a lot of progress (with help from a couple of other gnomes and a very productive bot). Most of them have been straightforward, but I need help with:

the Australia templates
Berg and Gebirgsgruppe Done
military conflict (Lua)
the Russian templates

Any assistance with modifying those to use |coordinates= in a reasonable way is appreciated. – Jonesey95 (talk) 16:46, 2 June 2017 (UTC)

Pinging Frietjes‎ for help with these. I can take care of the rest of the list (ski area, U.S. county, etc.), but the three remaining bullets above are too tricky for me. – Jonesey95 (talk) 20:23, 6 June 2017 (UTC)

Jonesey95, I will add transitional code to military conflict in a moment. can you provide a list of the Australia and Russian templates? I already did a load of work on {{infobox Australian place}} to make it compatible. you just have to be careful when converting the coordinates since it uses abs to force the correct hemisphere. Frietjes (talk) 20:36, 6 June 2017 (UTC)

now "military conflict", "Australian Electorate", and "Australia state or territory" should be ready for the articles to be converted. just remember that the Australian templates implicitly assume the correct hemisphere. Frietjes (talk) 21:02, 6 June 2017 (UTC)

and "Russian district" and "Russian federal subject" are ready as well. Frietjes (talk) 21:21, 6 June 2017 (UTC)

Excellent. Thank you. I have placed notes on the project pages and updated those templates' documentation pages. It looks like {{Infobox Australian road}} and {{Infobox Russian inhabited locality}} are the only ones left from the above list. – Jonesey95 (talk) 04:15, 7 June 2017 (UTC)

"Russian inhabited locality" should be ready to go. it looks like "Australian road" is mostly done, but could probably use some coordinsert. also, it looks like |coordinates= was removed (replaced with coordinates_a), so some tracking may be needed to find/fix any that were using that parameter. Frietjes (talk) 14:30, 7 June 2017 (UTC)

I have fixed all of the |coordinates= parameters in "Australian road" that I could find. I also removed it from the unknown parameter check, so it will turn up in that category if someone adds a new one. – Jonesey95 (talk) 00:47, 8 June 2017 (UTC)

Rounding issue in Infobox mountain

There's an unpleasant rounding issue that is cropping up in the conversion of |lat_d= and |long_d= to |coordinates= in {{Infobox mountain}}, especially for |range_lat_d= and |range_long_d=.

A bit of background: there are potentially two different coordinates in a mountain infobox: |lat_d= (etc.) and |range_lat_d= (etc.). The former is used for high-precision coordinates of the highest point on the mountain or range, while the latter is used for the approximate center of the range.

Feeding the raw values of |range_lat_d=, etc., to {{coord}} is not equivalent to what is currently happening in the template. The template carefully round the values to the nearest 0.01 degrees (if |range_lat_s= is not specified), in order not to violate the guideline on overprecise values. If |range_lat_s= is specified, the value is rounded to the nearest 0.0001 degrees. This is because the center of a range is rarely well-specified to hundreds of meters.

The template also takes care of rounding |lat_d= to the nearest second (because format=dms is the default)

Unfortunately, many editors (including myself) know that the template takes care of the rounding and tend to dump very-high-precision decimal coordinates into both the |lat_d= and |range_lat_d= fields, because that's easiest to get from sources like NGS.

My ask --- if a bot is going to convert |lat_d= into |coordinates= and |range_lat_d= into |range_coordinates=, if the value given is in decimal with more than 3 digits after the period, can we add |format=dms to the call to {{coord}}? Otherwise, I fear we'll be creating overprecise coordinates.

Thanks! —hike395 (talk) 08:41, 17 April 2017 (UTC)

I do not see any rounding happening in the normal coordinates, but I do see it happening in the range coordinates in the previous version of the template. JJMC89, I wonder if the bot could be programmed to subst the "decdeg" template invocation that is used to calculate lat_d in the range coordinates while it is doing the conversion? – Jonesey95 (talk) 13:44, 17 April 2017 (UTC)

@Jonesey95: I be would be very reluctant for the bot to automatically apply a lossy transformation, because the bot does not have context. That's why I suggesting adding formatting, as opposed to losing data.

The {{Infobox coord}} naturally applies rounding, e.g.

produces

This may be an issue in any infobox that uses {{Infobox coord}}, including ones you've already converted. —hike395 (talk) 14:25, 17 April 2017 (UTC)

The bot was already adding |format=dms when |format= is not specified to match the output from {{infobox coord}}, which defaults to |format=dms. — JJMC89 (T·C) 01:23, 18 April 2017 (UTC)

Note: {{Infobox coord}} was deleted in June 2017, since it was no longer transcluded in article space. – Jonesey95 (talk) 01:55, 13 June 2017 (UTC)

Tracking progress using Geobox coor

I don't know if it is valid to track our progress by counting transclusions of {{Geobox coor}}, but if so, today's transclusion count is 397,915. I expect that this is a floor for the number of articles that we need to convert, rather than a ceiling, but it may give us some indication of how we are doing. – Jonesey95 (talk) 00:49, 13 December 2016 (UTC)

A few infoboxes use {{Infobox coord}}, which has 16,468 transclusions. — JJMC89 (T·C) 04:42, 13 December 2016 (UTC)

Current status: {{Geobox coor}} = 350,500; {{Infobox coord}} = 16,198. – Jonesey95 (talk) 16:12, 27 January 2017 (UTC)

Current status: {{Geobox coor}} = 9,431; {{Infobox coord}} = 614. Some of the Geobox coor transclusions are calling wikidata, so it might have to stay. Infobox coord should be able to be deleted once all of the transclusions are converted. Progress! – Jonesey95 (talk) 17:43, 2 June 2017 (UTC)

{{Coord}} can call Wikidata, so {{geobox coor}} should be converted to {{coord}}. — JJMC89 (T·C) 20:44, 2 June 2017 (UTC)

{{Infobox transmitter}} needs to be converted to use {{coord}} instead of Geobox coor for Wikidata, but I was unable to find documentation explaining how to do it. Anyone? {{Geobox coor}} currently has 90 transclusions in article space. – Jonesey95 (talk) 02:53, 13 June 2017 (UTC)

Never mind, I figured it out (see {{Infobox transmitter}}). I have replaced all stray transclusions of {{Geobox coor}} and nominated the template and module for deletion. – Jonesey95 (talk) 03:11, 13 June 2017 (UTC)

Geobox conversions

Copied from User talk:Jonesey95 on 2017-01-25.
I added support for |coordinates=, |capital_coordinates=, |highest_coordinates=, |lowest_coordinates=, |source_coordinates=, |source1_coordinates=, |source2_coordinates=, |source_confluence_coordinates=, |management_coordinates=, and |government_coordinates= to {{geobox}} (search the geobox code for coord= to find them all). the core code is in {{geobox2 coor}} which is called by {{geobox}}. when converting transclusions to the new format, |display=inline,title should be added to the coordinates passed through |coordinates=, if it exists, otherwise added to |mouth_coordinates=, otherwise added to |capital_coordinates=. however, if |coordinates_no_title= is non-empty, then |display=inline,title should be added to none of them. the {{geobox2 coor}} template uses {{geobox2 coor type}} to determine the region: and type: for the coordinates. I may need to tweak the insert code in {{geobox2 coor}} if there is a problem with how the default and override works. let me know if you see any problems. Frietjes (talk) 15:45, 20 January 2017 (UTC)

Frietjes, all of the geobox pages have been converted. Would you be willing to remove the corresponding lat_d and long_d parameters from the {{geobox2 coor}} template? I started to clean it up, but it was too tricky for me. – Jonesey95 (talk) 03:29, 13 June 2017 (UTC)

Jonesey95, updated and I added some aggressive tracking for finding spurious left over parameters. if there are too many pages in there we can reduce the sensitivity. Frietjes (talk) 14:16, 13 June 2017 (UTC)

Very nice, thank you. I see only one article in the tracking category right now, so either you are fixing them as they arise, or there are not very many out there. – Jonesey95 (talk) 03:31, 14 June 2017 (UTC)

Last template converted! (not yet...)

I have converted the last set of infobox templates, along with their documentation, to use |coordinates=. I am sure that there are one or two (or ten) that we have missed somehow, but when the bot is done with the remaining templates, we can remove the last latitude/longitude parameters and this project should be able to wrap up. Great work, everyone! – Jonesey95 (talk) 14:51, 9 June 2017 (UTC)

I spoke too soon. I have been scrubbing through template space looking for parameters like |latitude=, and I turned up a few more templates with about 2,600 transclusions. I have added tracking categories to them and added them to the list, but I have not done full conversions to them yet. – Jonesey95 (talk) 06:15, 15 June 2017 (UTC)

About 10 months and you guys actually put something to bed rather than adding it to the ever-growing WP:WIP pile. Pure awesomeness and a great example of how to get something done. Thanks. ―Mandruss ☎ 07:11, 15 June 2017 (UTC)

Mercury crater

Anyone up for a puzzle? {{Infobox Mercury crater}} has some interesting processing of the lat and long that feeds {{Mercury quadrangle category}} and assigns a category. I tried to do math on the lat and long, but values over 180 appear to cause some effect that I do not understand. Converting Caloris Planitia changed the category when I tried it. {{Infobox Mars crater}} and {{Infobox Venus crater}} have similar category processing. – Jonesey95 (talk) 14:54, 16 June 2017 (UTC)

It also adds the page to Category:Pages with malformed coordinate tags. 189.8W should also mean 170.2E but the dot on GeoHack is not quite in the same spot. -- WOSlinker (talk) 15:04, 16 June 2017 (UTC)

Mercury_(planet)#Longitude_convention suggests that longitudes should only be "W" on Mercury. Hmm. – Jonesey95 (talk) 15:17, 16 June 2017 (UTC)

Just noticed that as long as globe:xxxx is included directly in the {{Coord}} params rather than added later with coordinsert then the page doesn't get added to the error category. I've also added {{#expr:abs(NUMBER)}} to the code in {{Infobox Mercury crater}} so that the lat/long are always returned as a postive value. I've updated Caloris Planitia and it seems to work now. -- WOSlinker (talk) 16:27, 16 June 2017 (UTC)

Ah, well done. I see that I had the lat/long mixed up in one of the formulas as well, a result of changing the order of things to make more sense. – Jonesey95 (talk) 18:52, 16 June 2017 (UTC)

Including "globe:" in the Coord template should not be necessary, I don't think. I wonder if the error category is being applied incorrectly when "globe:" is added by coordinsert. Maybe Frietjes could tell us. – Jonesey95 (talk) 18:55, 16 June 2017 (UTC)

Jonesey95 and WOSlinker, if you look in the code for Module:Coordinates you will see that "greater than 180" error check is only turned off if globe is specified. hence, the error occurs before the coordinsert can process it. I don't think there is a simple fix. the easiest thing to do is to explicitly specify the globe in the coordinates call in the article. it's either that, or turn off the "greater than 180" check everywhere. Frietjes (talk) 20:14, 16 June 2017 (UTC)

Unsupported globes

How is this going to work for bodies that the template does not support? (ie. coordinates on celestial bodies that the template does not allow in "globe" parameter.) It should allow coordinates for bodies not supported via "globe", but that will always break {{coord}} -- 65.94.169.56 (talk) 06:56, 21 June 2017 (UTC)

Note that this is a fork of Wikipedia talk:WikiProject Astronomy#Converting crater infobox templates to use the coord template. – Jonesey95 (talk) 14:37, 21 June 2017 (UTC)

No, I don't have an example on me right now. But it is blatantly obvious that this use case will occur in the future, since there is a limited number of "globe" options available at {{coord}} while there are many more celestial bodies with imaged surfaces than that list of bodies. If the infobox will not support generic coordinates without the need for using {{coord}} then the template is borked. It's not like the universe only consists of the bodies listed at the globe parameter list. -- 65.94.169.56 (talk) 05:05, 22 June 2017 (UTC)

Please post here and ping me when you have an article that demonstrates this error. I, or another editor, will be happy to help you fix the problem at that time. – Jonesey95 (talk) 05:53, 22 June 2017 (UTC)

That's hardly a solution. How am I supposed to be the only user to ever encounter this problem? I'm not the only astronomy editor on Wikipedia, am I? This lack of futureproofing is clearly not thought out well. And the assumption that the entire universe is already addressable with {{coord}} is a very inward-looking way of thinking of things, since science continues apace, and astronomers observe more celestial bodies with better resolutions all the time. -- 65.94.169.56 (talk) 13:13, 23 June 2017 (UTC)

COPIED from WT:ASTRONOMY

{{coord}} does not support Charon, which apparently has a coordinate system set [1] ; and for which we already have several location articles. (Though currently without infoboxen) -- 65.94.169.56 (talk) 13:31, 23 June 2017 (UTC)

As you will see below, {{Infobox crater data}} currently has the same issues with unknown globe settings, so converting it from using the latitude/longitude to coordinates parameter with the {{coord}} param will make no difference. Changes will need to be made either way to support new globe values. -- WOSlinker (talk) 15:58, 23 June 2017 (UTC)

Related discussion

For those still watching this page, a possibly interesting discussion: Standardising map parameters in infoboxes. – Jonesey95 (talk) 14:22, 28 August 2017 (UTC)

Inheritance by Location map many?

@Jonesey95 and JJMC89: I was under the impression that all location maps could now inherit coordinates from the infobox, but in this article I don't get the marker when I remove the |coordinates= from {{Location map many}} (using Preview). ―Mandruss ☎ 12:39, 2 October 2017 (UTC)

@Mandruss: That only works if the location map is built into the infobox like |pushpin_map= (as opposed to |image_map=) in {{infobox settlement}}. {{Infobox civilian attack}} does not have it, but it could (probably should) be added. You are using |map={{location map many|...|coordinates={{coord|...}}}} in 2017 Las Vegas Strip shooting. {{Location may many}} needs its own |coordinates= since it does not have access to the coordinates provided to {{infobox civilian attack}}'s |coordinates=. — JJMC89 (T·C) 16:58, 2 October 2017 (UTC)

I see, thanks. ―Mandruss ☎ 17:16, 2 October 2017 (UTC)