Template talk:Location/2019

Problem

When I use Google maps to look up one of my locations it does not give me numbers like you have used in your example: 52°09'03.7"N 9°57'02.8"E

It gives me numbers like this: 52.151028, 9.950778

So I cannot use your template, I expect because I live in a different hemisphere or something

Is it not possible for the template to do the necessary calculations? Thanks, Eddaido (talk) 10:49, 5 January 2019 (UTC)

Hi Eddaido, of course you can. See Template:Location#Examples. --Arnd (talk) 13:08, 5 January 2019 (UTC)

Aha! Thank you! - but its not exactly prominent is it. Thanks Arnd, Eddaido (talk) 13:15, 5 January 2019 (UTC)

Wikidata complaining about the location

Category:Bradleys Head Lighthouse has this statement

{{Object location|-33.853487|151.246664|Wikidata=Q897057}}

which is complaining

There is a discrepancy of 33 meters between the above coordinates and the ones stored at linked Wikidata item Q897057 (33°51′13″S 151°14′49″E, precision: 11 m). Please reconcile them. To copy Commons coordinates to Wikidata, click here

I get the coordinates from the Wikipedia article, I double-check them in Google Maps, I update the coords on Commons (the ones above). Still complains. So I "click here" as instructed. I login in, I run the tool it presents. The error persists. Now what? Kerry Raymond (talk) 23:20, 27 February 2019 (UTC)

• Ignore Wikidata. It’s a useless GIGO machine with an atrocious UI. -- Tuválkin ✉ ✇ 23:57, 27 February 2019 (UTC)
• @Kerry Raymond: I've just checked, and saw no error, so maybe you had a caching issue (try doing a page-purge). However, I have removed the {{Object location}} template, as the category page also has a {{Wikidata infobox}} template, which incudes the coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:28, 28 February 2019 (UTC)
  • Maybe the tool (which I don't recall having a name) should tell you to purge as it's a real time-waster sitting there trying to fix a problem if it isn't really there. And it should include instructions for installing the page purge gadget as I doubt everyone has it. Also, please don't remove the Object Location on Commons. At the moment, I am trying to connect up all the New South Wales State Heritage Register articles with their Commons category (or create a Commons category if photos exists but aren't in a category). Often the naming of files and categories on Commons makes it unclear whether or not they are the photos of a particular NSWSHR place, e.g. is Category:Narrandera railway bridge the heritage-listed railway bridge in Narrandera? Are the photos of St John Uniting Church in Orange the heritage-listed Uniting church in Orange? After a fair bit of investigation, I think they are for a different bridge and a different church. Indeed, I think the 3 photos in the bridge category are not even of the same bridge. I have to use every clue about locations of the photo, of the category, etc to try to resolve these things. If the source of ground truth is in the article, or the photo, or the commons category, it should never be removed from there just because it has been copied onto Wikidata. At the moment, I am seeing people systematically removing Commons Categories from WP articles with edit summaries that this information is already on Wikidata, but did those people know enough to be sure that was the right Commons category on Wikidata or are they operating on the principle of "the name is similar", a behaviour encouraged by by MixNMatch. Kerry Raymond (talk) 23:14, 28 February 2019 (UTC)
    • @Kerry Raymond: The problems arising from Wikidata’s initial inability to link between a Wikipedia article and a Commons category have recently become much less annoying and it’s almost trivial to ensure the correct interlinking is showing on both sides, by means of Wikidata. The manually filled-out {{Commonscat}} is replaced by «In other projects: Wikimedia Commons» on the sidebar (it can be used to override Wikidata, when really necessary). It’s good to see Wikidata working as intended, even if only after several years and a few million dollars. -- Tuválkin ✉ ✇ 07:24, 1 March 2019 (UTC)
  • A second question. I note that the error message related to a 33m difference and an 11m precision. For a lighthouse which has a relatively small footprint, 33 metres difference may be significant, but for heritage-listed lighthouses, we are often dealing with a lighthouse precinct consisting of the lighthouse, a lighthouse keeper's cottage, and other infrastructure, for which there are boundaries and the single coordinate will usually be a centroid and not necessarily the lighthouse itself, in which case 33m might be quite acceptable as a difference. Similarly I can't imagine that 33m is a meaningful discrepancy if you are talking about the location of something with a very large footprint, such as an abandoned mining town. How is it decided if a discrepancy is significant? Kerry Raymond (talk) 23:14, 28 February 2019 (UTC)
    • @Kerry Raymond: I’d guess it simply reacts to the values not being identical, without any attempt at considering scale and precision (which is okay, since Wikidata and Commons should have the same criteria and therefore any discrepany is an error, albeit small). -- Tuválkin ✉ ✇ 07:24, 1 March 2019 (UTC)
  • @Pigsonthewing: You did what? You actually removed the coordinates as stored locally in this project, trusting that the remotely hosted geolocation data will not get corrupted? You’re either haven’t been paying attention to what’s going on about Wikidata’s issues with low volunteer activity, peameability to vandalism, unreliable results, and opaque mechanism — or you’re willing to sacrifice the health of our content to prove a point. (A point which I agree with, in theory, but I value the practical aspect of having healthy data way more.) -- Tuválkin ✉ ✇ 07:24, 1 March 2019 (UTC)
    • I'm not going to respond to such hysterical, ad hominem nonsense. If you wish to have a discussion, rephrase your post more reasonably. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:11, 2 March 2019 (UTC)

We have 2 categories for pages with commons/wikidata geolocation discrepancies:

• Category:Pages with local coordinates and mismatching Wikidata coordinates
• Category:Pages with local coordinates and similar Wikidata coordinates

in both cases distance is measured between 2 location and divided by precision taken from wikidata. In the first category, there seems to be a clear mismatch, in the second one is more mild mismatch. Some places like country, city, national park, etc. should not use precise locations with sub-meter accuracy, so many issues are due to Wikidata "precision" field which should be fixed there. However a Lighthouse, statue, etc. could be very precise, so the most pressing issues is to reconcile locations of such objects. --Jarekt (talk) 20:34, 1 March 2019 (UTC)

Leading zeros

In this Template there shoud be integrated leading zeros in the E-W coordinates. East-West coordinates have 3 digits since they vary fom 0° to 180°. The print out in this example should be 016°54'25.16"

Object location	25° 06′ 13.26″ S, 16° 54′ 25.16″ E	View all coordinates using: OpenStreetMap

--Hp.Baumeler (talk) 10:05, 20 March 2019 (UTC)

I never see coordinates written in this format. For me, "16°54'25.16"" looks much more natural than "016°54'25.16"". Any other opinions? --Jarekt (talk) 00:29, 21 March 2019 (UTC)

In aviation and other fields where coordinates are crucial they are written with leading zeros to show to the reader that no number is missing. (See German page: Darstellung von geographischen Koordinaten.) The template already includes a leading zero within the minutes: --- 06'---! Coorinate-Minutes vary from 00 to 60 minutes, hence are expressed with two digits. The East-West degrees vary from 00 to 180 and hence should be written with 3 digits! --Hp.Baumeler (talk) 13:50, 23 March 2019 (UTC)

I can see a use for leading zeroes in numeric-only tabular formats, but with the proper symbols I don’t think they add any value. IMO the minutes & seconds are quite a different case from the degrees: they do frequently appear with leading zeroes, almost as often as in time formats, but I’ve very rarely seen degrees printed that way in gazeteers, maps, navigation manuals, or the like.—Odysseus1479 (talk) 23:13, 10 April 2019 (UTC)

Google Earth

Link doesn't work. It was very useful when it worked. It has been broken for weeks and no indication that someone will repair it this year. Until it works, this and other templates should use something else instead, such as Bing Maps. Jim.henderson (talk) 13:54, 9 April 2019 (UTC)

@Para: , Any chance Google Earth tool can be fixed? --Jarekt (talk) 18:20, 10 April 2019 (UTC)

Fixed. All it needed was a webservice start after WMF shut down the previous servers. --Para (talk) 20:14, 10 April 2019 (UTC)

@Jim.henderson: the links are to tools which are capable of displaying locations of other files. There is not tool to display them on Bing Maps or other map providers. --Jarekt (talk) 18:20, 10 April 2019 (UTC)

@Jarekt: @Para: thanks to both; that useful feature is indeed working well for me. Template:Geogroup still isn't working. Sometimes I think, every time something is repaired, something else will stop working. Jim.henderson (talk) 04:05, 11 April 2019 (UTC)

Target maintenance category - proposed name change

A CfD (Commons:Categories for discussion/2019/06/Category:Pages with maps) has been started which will require a change to this template. Please comment there regarding any possible impact on this template or pages that use it. Josh (talk) 22:14, 10 July 2019 (UTC)

Josh, neither {{Location}} nor Module:Coordinates sets that category. I think it is added by the Kartographer software itself. --Jarekt (talk) 02:32, 11 July 2019 (UTC)

Thank you for the clarification. Still, if anyone has input on the discussion I would encourage their contribution on the CfD. Josh (talk) 17:05, 11 July 2019 (UTC)

Sky coordinates

I've tried searching, but is anyone aware of a template like this that supports astronomical coordinates? It seems like a lot of our space-related images could benefit from it. — Huntster (t @ c) 23:25, 15 August 2019 (UTC)

This template can handle other globes like moon or mars; however I am not familiar with astronomical coordinates. It sounds like kind of data that should be stored on Wikidata. --Jarekt (talk) 16:43, 17 August 2019 (UTC)

3rd format

(copied from User talk:Jarekt#Location)

Hi Jarekt, you did a lot with the template {{Location}} so I suppose you are the right one to de asked. I intend an expansion to that template: often I got geodata in the format e.g. gg° mm′ ss″ N gg° mm′ ss″ E and needed to replace all the symbols by the pipe character. I am thinking that I am not the only one wishing a third input format.

I wrote a template {{Loca deg}} to convert the symbols to pipes, and to pass the the parameters to {{Location}}. It works fine, and it is documented with example at Location/doc. But IMHO it would be better to use the original template name. I expanded the /sandbox to enable it to work with all three input formats, and it works also fine - the user just enters one of the three formats without needing to use another template name, and the conversion occurs automatically.
Examples: File:Cimetière de Saint-Romain-d'Ay 00.jpg with Template:Loca deg, Cimetière de Saint-Alban-d'Ay 00.jpg with Location/sandbox
Now my question: Do you also think it a good idea to have that expansion? I want to use my possibilities as a template editor with responsability. In advance I am seeking a wider consensus with competent user(s). While ((T0|Loca_deg}} does not alter anything and is finally using Location, the other version will expand the code of the template. I am a bit hesitating to edit that template, it is transcluded 12.5 Mio times. The current functions are not influenced, just a third function is added. -- sarang♥사랑 15:42, 5 October 2019 (UTC)

sarang, I do prefer as little variation in {{Location}} inputs as possible, but this could be a fine change. I looked through Module:Loca deg and simplified it a bit in Module:Loca deg/sandbox. We would have to change both {{Location}} and {{Object location}}. --Jarekt (talk) 03:06, 7 October 2019 (UTC)

Thank you - as you can see, my LUA knowledge is rather poor, and your simplifications are fine.

I suggest to change the mode=camera in {{Location}} to mode={{{mode|camera}}}, so we can have a very simple {{Object location}} which just passes the parameters to {{Location}} with mode={{{mode|object}}}; but the “one-parameter-version” should default to object because the geodata string never will come from a camera but from wikimapia or other extern sources.

When attributes should be passed positional, it can be done as 9= with 8 parms, or 3= with 2 parms and also 3= with the new possibility of 1 parm.

BTW, there is no possibility to invoke a module with parameters from an invocation? I think on {{{#invoke:Coordinates| LocationTemplateCore| ... |lon={{#invoke:Loca_deg...}} ...}} but the parameter(s) are passed without solving the inner invocation before; it's only possible to transfer the complete work of the inner Loca_deg into the outer Coordinates?

It did not work when I tried it, but your version does. -- sarang♥사랑 06:52, 7 October 2019 (UTC)

For last decade or so {{Location}} was for camera location and {{Object location}} for object location and their behavior is very predictable. I would be OK with making {{Location|mode=object}} equivalent to {{Object location}}, but I do not think {{Location}} should switch to object location mode just based on the input format. I understand that string in the format gg° mm′ ss″ N gg° mm′ ss″ E is more likely for objects not cameras, but format and mode should stay independent. Another possibility is to keep (tl|Loca_deg}} as is and run a bot job every year or so to convert all files using that template to proper {{Object location}}. Another possibility is to expand Module:Coordinates to allow 2 parameter input in the form: {{Object location|gg° mm′ ss″ N|gg° mm′ ss″ E}}, that way there would be very minimal changes to the current code (I would just add a bit of code to function p.LocationTemplateCore(frame)) and the only change you would have to make to string like gg° mm′ ss″ N gg° mm′ ss″ E would be to add one pipe character.--Jarekt (talk) 11:59, 7 October 2019 (UTC)

Ok, when you think that format and mode should stay independent. Location without the mode= parameter displays a neutral version (neither "camera" nor "object") which IMHO is in many cases sufficient, the mode-specification is not always such a necessarity. How about that:

• {{Location}} defaults to mode=camera, if not specified otherwise
• {{Object location}} switches to {{Location}} with the default mode=object, if not specified otherwise
• in both cases it is possible to specify an empty parameter value mode= which will avoid the defaultings.

At the moment most of my locations got (erroneously) the “camera” prefix because I used the simple Location instead of the other one.

About the format version with one pipe I understand that it would minimize the needed coding changes; on the other hand, I think that input should be as easy (and self explaining) as possible, even when it is only one pipe that comes to a copy/paste action: the software should do the work, not the editor! So I am not so happy with this idea. -- sarang♥사랑 12:30, 7 October 2019 (UTC)

We had this template since 2006, and when I started working on it in 2009, the interface was mostly agreed on and unchanging, since a lot of images were already using it. Through all the changes since, the basics of the interface did not change, so I am weary to introduce too many changes now. I do not think we need "neutral" mode, especially since the difference between two modes is not just label, but also how images are interacting with external tools. I am a bit unsure about what to do about the fact that the last unnamed parameter was always "attributes"; we allowed at some point to use it as a named parameter, but the default is that it is OK to use it as unnamed last parameter. So we should expect to see some tags like {{Object location|gg° mm′ ss″ N gg° mm′ ss″ E|heading:N}}. May be the best way is to just leave it as is, and occasionally run a bot job to convert from {{Loca deg}} to {{Object location}}.--Jarekt (talk) 13:33, 7 October 2019 (UTC)

We do not need a bot, there are only very few images with the test version “Loca_deg” – I can do it swiftly and manually, even not needing VFC.

As far as I can see, we will need to distinguish whether parameter 4 exists, and if not whether parameter 2 is specified. So in the latter case, two pipes between the location string and the last, unnamed parameter seem to me not too bad, to have no parameter 2. The last parameter is either no. 9, or no. 3 in the other both formats.

Agreeing with all other aspects mentioned by you, I assume that the sandboxes can be brought to real use, und the test template loca_deg will become obsolete. Thank you -- sarang♥사랑 14:47, 7 October 2019 (UTC)

Proposal: Object location can be simply that stub

{{Location
 | mode       = {{{mode|object}}}
 | 1          = {{{1|}}}
 | 2          = {{{2|}}}
 | 3          = {{{3|}}}
 | 4          = {{{4|}}}
 | 5          = {{{5|}}}
 | 6          = {{{6|}}}
 | 7          = {{{7|}}}
 | 8          = {{{8|}}}
 | 9          = {{{9|}}}
 | attributes = {{{attributes|}}}
 | prec       = {{{prec|}}}
 | lang       = {{{lang|}}}
 | bare       = {{{bare|}}}
 | secondary  = {{{secondary|}}}
 | wikidata   = {{{Wikidata|{{{wikidata|}}} }}}
}}<noinclude>
{{Documentation|Template:Location/doc}}
</noinclude>

instead of containing own code (at the moment would work only with Location/sandbox). -- sarang♥사랑 11:25, 8 October 2019 (UTC)

Another possibility if you don't like the additional pipe to make attributes the third parameter and letting the seond empty: When there are two parameters, a (rather simple) check enables the decision. When p2 exists and it is numeric, it is the second location parameter lon, otherwise it is unnamed attributes following the one-parameter string format. It allows to code attributes as p9, p3 and also p2 – the unnamed parameter can always be the last one. -- sarang♥사랑 15:52, 8 October 2019 (UTC)

Jarekt: as far as I understand everything is discussed – if you don't have objections I will transfer within the next days the well tested /sandbox, as it is now.

Because of the 12.5M transclusions, I will wait some days for the servers to calm down, and then change the Object location (another 3.2M transclusions), and then this template won't need further action to be able to accept all three input formats. Thank you for your competent aid! -- sarang♥사랑 11:30, 9 October 2019 (UTC)

sarang, sorry for the silence but I was quite busy lately and not spending much time on Wiki. I was experimenting with adding support for single input and 2 dms inputs directly to Module:Coordinates as much cleaner solution. Unfortunately I did not get it to work yet. As for your suggestion to simplify Object location, you might be right, It is done the current way in order to minimize number of indirect calls of calling a template that calls some other template that calls a module, etc. However extra complicating code that could be simplified might not be worth it. --Jarekt (talk) 04:09, 11 October 2019 (UTC)

Jarekt: Of course will that be a better solution. To me, it is much too difficult, but if you want to try it I will wait and let you develop that solution. In the meantime I edited {{Location/sandbox}}, {{Object location/sandbox}} and {{Globe location/sandbox}}, all at the state of the art before coordinates-upgrade. -- sarang♥사랑 15:18, 11 October 2019 (UTC)

I am almost done with allowing all 3 formats to be sorted out in lua. Only error handling is left. That should drastically simplify the template. --Jarekt (talk) 20:33, 11 October 2019 (UTC)

Just deployed a new version. Please report any issues. --Jarekt (talk) 03:39, 17 October 2019 (UTC)

Great work you did, Jarekt! Just a small request: at code line 816 of Coordinates you check whether parm2 exists; it should check whether an existing parm2 is a numeric value – because in case of one single location string, parm2 can be an attribute (which is never numeric). Thank you -- sarang♥사랑 08:53, 20 October 2019 (UTC)

GeoData extension empty

For some days coordinates in the GeoData extension disappear on save, null edit ist enough. Example File:Boston - S Market St - panoramio.jpg, the API doesn't show coordinates anymore: https://commons.wikimedia.org/w/api.php?action=query&titles=File:Boston%20-%20S%20Market%20St%20-%20panoramio.jpg&prop=coordinates. Any ideas? Thank you! --DB111 (talk) 09:08, 20 October 2019 (UTC)

Maybe found --DB111 (talk) 22:57, 20 October 2019 (UTC)

Redundant Geo templates

We have a lot of categories which are linked to Wikidata and do have {{Wikidata Infobox}} template displaying a little map and place coordinates, and they have {{Object location}} template displaying the coordinates. I think those categories will be less cluttered with redundant data if we remove {{Object location}} templates for cases where they agree. Pages where local coordinates agree with wikidata coordinates can be found at Category:Pages with local coordinates and matching Wikidata coordinates, sub-categories of that category which also have {{Wikidata Infobox}} template should loose {{Object location}}. @Mike Peel: --Jarekt (talk) 13:56, 11 November 2019 (UTC)

@Jarekt: I agree, will you do this, or do you want me to write a bot script to do this? Thanks. Mike Peel (talk) 15:04, 11 November 2019 (UTC)

I can remove them but wanted to to make sure I am announcing my intentions so my actions are not a surprise to anybody. --Jarekt (talk) 16:31, 11 November 2019 (UTC)

Great. :-) Go for it! Thanks. Mike Peel (talk) 16:33, 11 November 2019 (UTC)

Agree. If you can confidently do that, it would be good if you could move infobox to the top of the page (at least above the language templates like {{En}}, {{Fr}} etc. and {{Mld}}). Sometimes they got placed below the just-to-be-removed coordinates template in order not to break its layout, sometimes simply Mike’s bot was too shy to put it above the language templates. —Tacsipacsi (talk) 20:21, 11 November 2019 (UTC)

Blank line added at top

This template used to merge into the {{Information}} at its bottom. It no longer does so, and looks orphaned, and wrong. Please remove this blank line. Rodhullandemu (talk) 12:45, 13 November 2019 (UTC)

Rodhullandemu can you provide an example? I just picked some random image with location on the bottom and it looked fine to me, as it looked like location was merged with the {{Information}}. I purged the image and it was still OK. There is a new version of {{Information}} template and there might still be some issues with it, but I can not reproduce what you described. --Jarekt (talk) 16:44, 13 November 2019 (UTC)

• @Jarekt: It happens here. Perhaps it's {{Object location}} instead as I believe they have been merged? Rodhullandemu (talk) 17:00, 13 November 2019 (UTC)

Fixed --Jarekt (talk) 05:04, 14 November 2019 (UTC)