Module talk:Coordinates

Module:Coordinates has been template protected indefinitely because it is a highly-used or visible template. Use {{Edit request}} on this page to request an edit.

alt= for the compass-icon

{{Editprotected}} I would like to see the original value of the heading (in the original letter/number format as given in the parameter) as the "baloon help" (using "alt="?) when I put the mouse cursor on the compass-icon. --ŠJů (talk) 23:00, 26 March 2014 (UTC)[reply]

Lets see. I tried:

{{abbr|[[{{Compass rose file|200|style=heading}}|40px|link=|alt=]]|200}} ->
[[{{Compass rose file|200|style=heading}}|40px|link=|title=200°]] ->

The first example using {{Abbr}} seem to work, except for a doted line but the second one using alt does not seem to work --Jarekt (talk) 03:32, 27 March 2014 (UTC)[reply]

Done. But needs further tweaking, Jarekt can you have a look? ~~Probably 202.500000° on this sample doesn't look good.~~ (fixed −ebraminio^talk 16:31, 20 May 2014 (UTC)) −ebraminio^talk 16:12, 20 May 2014 (UTC)[reply]

Hey I had a chance to look at it and it looks good and seems to work fine. Thanks. --Jarekt (talk) 02:59, 21 May 2014 (UTC)[reply]

Mark primary coordinates as such

Hey, in order for GeoData to make any sense, files need to have primary coordinates. The following change to lines 476-478 would fix it:

			if args.namespace == 'File' and Status == 'primary' then -- TODO enable for secondary cases without throwing errors
				--coorTag = string.format('{{#coordinates:%f|%f|%s|%s}}', frame.args.lat, frame.args.lon, args.attributes, Status)
				coorTag = string.format('{{#coordinates:primary|%10.6f|%11.6f|%s}}', lat, lon, args.attributes)

However I'd like to confirm first that this will not cause widespread duplicate primary coordinates errors. Max Semenik (talk) 07:06, 29 May 2014 (UTC)[reply]

Max, thanks for looking into this. It is part of the code I did not think was right, but the version I thought was right gave me errors. All I know is that current version:

			if args.namespace == 'File' and Status ~= 'secondary' then -- TODO enable for secondary cases without throwing errors
				--coorTag = string.format('{{#coordinates:%f|%f|%s|%s}}', frame.args.lat, frame.args.lon, args.attributes, Status)
				coorTag = string.format('{{#coordinates:%10.6f|%11.6f|%s}}', lat, lon, args.attributes)
			end

works, and my original idea:

			if args.namespace == 'File' then 
				coorTag = string.format('{{#coordinates:%f|%f|%s|%s}}', frame.args.lat, frame.args.lon, args.attributes, Status)
			end

, which followed https://www.mediawiki.org/wiki/Extension:GeoData documentation, caused "widespread duplicate primary coordinates errors". Shouldn't the solution allow for the coordinates to be marked as secondary. --Jarekt (talk) 12:57, 29 May 2014 (UTC)[reply]

Every coordinate not marked as primary is consdered secondary. I think it should work as long as we mark everything from {{Object location}} as secondary. Max Semenik (talk) 18:54, 2 June 2014 (UTC)[reply]

Done The following code was deployed:

			-- add {{#coordinates}} tag, see https://www.mediawiki.org/wiki/Extension:GeoData
			if args.namespace == 'File' and Status == 'primary' and args.mode=='camera' then 
				coorTag = string.format('{{#coordinates:primary|%10.6f|%11.6f|%s}}', lat, lon, args.attributes)
			end

--Jarekt (talk) 23:46, 2 June 2014 (UTC)[reply]

Woohoo, thanks a bunch! Now Special:Nearby actually works:) Max Semenik (talk) 22:11, 5 June 2014 (UTC)[reply]

Wow, it is impressive. It figured out my location based on my IP? --Jarekt (talk) 03:39, 6 June 2014 (UTC)[reply]

Toolserver moves

{{Editprotected}} I've taken my toys off the Toolserver. Please change:

fullurl:tools:~para/GeoCommons/earth.php to fullurl:toollabs:geocommons/earth.kml
fullurl:tools:~para/GeoCommons/proximityrama to fullurl:toollabs:geocommons/proximityrama
http://toolserver.org/~para/GeoCommons/GeoCommons-simple.kml to http://tools.wmflabs.org/geocommons/web.kml

--Para (talk) 23:37, 30 June 2014 (UTC)[reply]

Done Thanks for heads up. --Jarekt (talk) 14:35, 1 July 2014 (UTC)[reply]

linked services

Shouldn't this link to OSM, Google and Bing, like Template:Geogroup? The Google Earth link does not work for me, I guess because I don't have any Google Earth software installed – which we cannot expect users to have. FDMS 4 02:39, 14 September 2014 (UTC)[reply]

The special links are only to 3 systems for which we have special interface to show images from the neighborhood. As for GoogleEarth, if someone do not chose to install this free software than I assume will not be clicking the link to it, and the ones that have it will. I do not think we can check from the browser if someone does have the software or not. --Jarekt (talk) 11:08, 14 September 2014 (UTC)[reply]

It is theoretically possible to show nearby images in Bing maps – at least the URLs, which should be fixed. I don't it's possible to check whether GoogleEarth is installed either, especially as there are different kinds (plugin and desktop) of installations. But don't we just generally try to avoid links to services requiring additional (commercial) software to work properly? FDMS 4 15:02, 14 September 2014 (UTC)[reply]

If someone develops bing to the same level the other 3 links are, I am sure we can add it if there is consensus. I also doubt you would get consensus about removing GoogleEarth. We had a link to it for years and this commercial but free Google Earth seems to be standard software for many that do things with geographical data. --Jarekt (talk) 04:22, 15 September 2014 (UTC)[reply]

Hm. @Jarekt: Actually, could you fix the Geogroup Bing links? They work in the English Wikipedia version, but not here … FDMS 4 17:55, 9 October 2014 (UTC)[reply]

In case you didn't use preview: You only changed the UK version, the default bing link still doesn't work. FDMS 4 20:17, 13 October 2014 (UTC)[reply]

I guess I am not sure how to fix it. Lets find someone more familiar with that template. --Jarekt (talk) 03:34, 14 October 2014 (UTC)[reply]

Sorry, but I've found out it wasn't a problem with the links, but with kmlexport … Appears to be fixed now. Thanks for looking into it anyway! FDMS 4 14:17, 14 October 2014 (UTC)[reply]

I am glad it is resolved--Jarekt (talk) 15:42, 14 October 2014 (UTC)[reply]

"Nearby images" too often out of service

Displaying of "other nearby images" is (in last years) too often out of service. Maybe, more time is out of service than in service. By my rough estimate, in 7 of 10 attempts to use the function, the "other nearby images" are not displayed (although the linked maps are opened in correct place with correct coordinates). That causes that many of Commons users don't know what the functions should really do. I propose to add a noticeable warning about it to the text of the template, bellow the links. Would be possible also any detection of the tool which can e.g. red/green icon dependently signalizing that the tool is out/ready? (This discussion was started at Template talk:Location.) --ŠJů (talk) 00:56, 28 January 2015 (UTC)[reply]

Geocoding link

Currently geocoding link leads to en version page only.

str4 = '[[File:Circle-information.svg|18x18px|alt=info|link=Commons:Geocoding]]'

If it is possible to pass link to the lua code, it will be useful to other languages also.--Praveen:talk 06:13, 4 March 2015 (UTC)[reply]

Good point. I will look into it. --Jarekt (talk) 14:52, 20 November 2016 (UTC)[reply]

It looks like I fixed it in March. --Jarekt (talk) 02:38, 21 November 2016 (UTC)[reply]

Map links

Tracked in Phabricator
Task T151152

In recent weeks, two different "magnifying glass" icons are displayed past the coordinates which call an identic map link. In addition, both the links miss a tooltip. --ŠJů (talk) 10:43, 20 November 2016 (UTC)[reply]

That is new. I searched phabricator and it seems to be related to phabricator:T145176 change. I will work in the tooltip. --Jarekt (talk) 15:02, 20 November 2016 (UTC)[reply]

Done Should be fixed now. --Jarekt (talk) 03:44, 21 November 2016 (UTC)[reply]

Prefilled quickstatements

Hi everyone, Jarekt. As i understand there is a way to prefill quickstatements. This would make the cumbersome tab replacement procedure obsolete. For example for Category:Schutterquelle (Wellheim) the link would look like this: https://tools.wmflabs.org/wikidata-todo/quick_statements.php?list=Q180300%09P625%09@048.82818/011.08982%09S143%09Q565. (did not executed but it think it works). Maybe you could add this to the module? --Arnd (talk) 08:55, 7 February 2017 (UTC)[reply]

I am using that already with Module:Authority control, but did not implemented it yet for Module:Coordinates. I will try to get to it soon. --Jarekt (talk) 12:38, 7 February 2017 (UTC)[reply]

Hi Jarekt, i'd like to cleanup category:Pages with local coordinates and mismatching wikidata coordinates. To do that quickly i would appreciate to have a direct this quick_statement link. I would change the coordinates module by myself but i am not allow to do so. I guess it is not a big change. --Arnd (talk) 08:21, 24 February 2017 (UTC)[reply]

Arnd, I am sorry I was doing something else and forgot. It is done now. --Jarekt (talk) 04:35, 25 February 2017 (UTC)[reply]

Works perfectly, Jarekt. Thank you a lot. --Arnd (talk) 07:58, 25 February 2017 (UTC)[reply]

Hi again Jarekt, could you please update the quick statement link, specially by replacing /wikidata-todo/quick_statements.php?list= by /quickstatements/#v1=. Thank you in advance, --Arnd (talk) 16:23, 10 July 2017 (UTC)[reply]

Done I updated the links and tested it on some category. It seems to work fine. --Jarekt (talk) 18:56, 10 July 2017 (UTC)[reply]

QuickStatements icon?

Should we somehow get the QuickStatements icon to the QS links? (To have the text and the image as two html elements with two links isn't very attractive tho.) --Marsupium (talk) 17:28, 18 February 2018 (UTC)[reply]

Localization issues

@Jarekt: The function _deg2dms pads the minute and second strings of latitudes and longitudes with a '0' if they are below 10. This is fine for those languages which use Latin numerals, but it causes issues with rendering in other scripts, such as Bengali, where the location here is rendered "৪২° 0০′ 0০″ উত্তর, ২১° ২৬′ 0৩.৮৪″ পূর্ব "—notice the interspersed Roman '0' among the other Bengali digits. Perhaps this problem can be rectified by passing the '0' through Lang:formatNum? Mahir256 (talk) 05:45, 12 April 2018 (UTC)[reply]

Fixed Mahir256 thanks for reporting this. Such an obvious issue, but nobody reported it before. --Jarekt (talk) 12:11, 12 April 2018 (UTC)[reply]

Lua error in Module:Coordinates at line 699: Tried to read nil global frame.

DschwenBot added {{Location|54|35.4543|0|N|5|55.9848|0|W|alt:5.9953_source:exif_heading:82.23566}} for File:Belfast Dublin Road Shaftesbury Square Reformed Presbyterian Church 2018 08 22.jpg which resulted in a Lua error with following backtrace:

[C]: in function "error"
Module:No_globals:4: ?
Module:Coordinates:699: in function "_LocationTemplateCore"
Module:Coordinates:776: in function "chunk"
mw.lua:511: ?
[C]: ?

This is just one example, the same problem occurs with other users of {{Coordinate}} as well. --AFBorchert (talk) 07:33, 25 November 2018 (UTC)[reply]

Hm... this appears to be related to this edit which introduced

require('Module:No globals') -- used for debugging purposes as it detects cases of unintended global variables

which triggered the error. Regards, AFBorchert (talk) 07:41, 25 November 2018 (UTC)[reply]

And the reason for this is apparently this line:

coorTag = frame:callParserFunction( '#coordinates', { 'primary', lat, lon, args.attributes } )

where frame is nil. Before the most recent change we had

function p.LocationTemplateCore(frame)

by which frame was defined as local parameter. This has been updated to

function p._LocationTemplateCore(args)

which leaves frame undeclared and thereby a reference to a global variable that does not exist. This happened apparently when the original p.LocationTemplateCore was wrapped and renamed. The wrapper function is now at line 768 which has frame but does not pass it on to p._LocationTemplateCore. --AFBorchert (talk) 08:57, 25 November 2018 (UTC)[reply]

So when is this going to be fixed? --HyperGaruda (talk) 09:19, 25 November 2018 (UTC)[reply]

Zhuyifei1999 has fixed it. Thanks! --AFBorchert (talk) 09:42, 25 November 2018 (UTC)[reply]

Lua error in Module:Coordinates at line 603: Tried to write global link3

Antoher error popped up, saying:

Lua error in Module:Coordinates at line 603: Tried to write global link3.

Backtrace:

    [C]: in function "error"
    Module:No_globals:10: ?
    Module:Coordinates:603: in function "_externalLinksSection"
    Module:Coordinates:726: in function "_LocationTemplateCore"
    Module:Coordinates:777: in function "chunk"
    mw.lua:511: ?
    [C]: ?

--HyperGaruda (talk) 10:02, 25 November 2018 (UTC)[reply]

Hm... variable declarations for link3 and link4 appear to be missing at line 593 in function p._externalLinksSection. Do you have a sample page where this error occurs? --AFBorchert (talk) 10:40, 25 November 2018 (UTC)[reply]

Category:Nasir-ol-molk Mosque. --HyperGaruda (talk) 11:28, 25 November 2018 (UTC)[reply]

Here too: Category:Pinneberg (Heligoland) --Milseburg (talk) 12:08, 25 November 2018 (UTC)[reply]

Can you just roll it back to the version before Jarekt's edits on 25.11? Still broken at "line 699: Tried to read nil global frame.". Retired electrician (talk) 15:50, 25 November 2018 (UTC)[reply]

ah, never mind, purge cleared it at last Retired electrician (talk) 15:52, 25 November 2018 (UTC)[reply]

I have just reverted today's changes for a short while and found out that they cause the error. Unfortunately, I do not know Lua, so I am leaving debugging for the authors. --jdx ^Re: 16:35, 25 November 2018 (UTC)[reply]

User:Jdx and User:Zhuyifei1999 thanks for stepping in and fixing the issues. Adding Module:No globals causes modules to throw errors when unintended and potentially dangerous global variables are detected. I thought I got them all as I could not find any pages that throw the error. After the change I monitored the Category:Pages with script errors for a while with no errors showing up, before signing off for the night. However it seems some small fraction of pages using the module did show the error. I think we got them all by now. Thanks again and sorry for all the excitement. --Jarekt (talk) 18:42, 25 November 2018 (UTC)[reply]

Comment If one still can see the error on a page, please purge the page's cache. --jdx ^Re: 19:26, 25 November 2018 (UTC)[reply]

Done Category:Pages with script errors is empty now. --Jarekt (talk) 19:47, 25 November 2018 (UTC)[reply]

Globe problem

{{#invoke:Coordinates| GeoHack_link | globe = Mars | lat=10.0 | lon=5.0}} should link to Mars, but instead it links to Earth: 10° 00′ 00″ N, 5° 00′ 00″ E . Looks like the globe parameter is not being passed through correctly? @Jarekt: maybe you could have a look? Thanks. Mike Peel (talk) 06:51, 7 January 2019 (UTC)[reply]

Fixed here. Thanks --Jarekt (talk) 13:30, 7 January 2019 (UTC)[reply]

Thanks, seems to be working nicely, e.g. at the bottom of the infobox at Category:Olympus Mons. Thanks. Mike Peel (talk) 14:11, 7 January 2019 (UTC)[reply]

Breaking bug after patch

@Jarekt: after your commit there is an issue breaking the module in some cases seen at Template:Location --GPSLeo (talk) 06:41, 17 October 2019 (UTC)[reply]

I've undone the edits temporarily, I hope Jarekt can fix it when he's next online. The error was "Lua error in Module:Coordinates at line 826: attempt to index field 'lat' (a number value). " Thanks. Mike Peel (talk) 07:57, 17 October 2019 (UTC)[reply]

@GPSLeo and Mike Peel: , Thanks. I fixed the issue in line 826. I will flush Category:Pages_with_script_errors so there are no issues there, and reissue the commit when I have more time to watch Category:Pages_with_script_errors for issues. --Jarekt (talk) 11:14, 17 October 2019 (UTC)[reply]

@Jarekt: This patch seems to break {{#coordinates}} in some way, files with location / object location now loose their GeoData coordinates on save. --DB111 (talk) 13:28, 19 October 2019 (UTC)[reply]

@DB111: Do you have a specific example? It makes debugging a lot easier. —Tacsipacsi (talk) 13:51, 19 October 2019 (UTC)[reply]

Take a file of your choice that uses the Location template, lets say File:Cape Cod Rail Trail sign.jpg. 1. The API returns the coordinates: [1], 2. Now make a null edit of the pic (no change necessary), 3. Look in the API again, now the coordinates probably disappeared - or get changed in other cases. I'm not sure, if it is really due to this change and it will probably not happen on all files, but it started at the same time as the patch.--DB111 (talk) 14:17, 19 October 2019 (UTC)[reply]

DB111, I tried it on a few files and I see coordinates before and after. Also My work was only on input parameters and I did not touch any functions related to {{#coordinates}}, so it is not likely that part would be affected. --Jarekt (talk) 03:23, 20 October 2019 (UTC)[reply]

Look a the sample file above: Location|41.690057|-70.152178, but API now returns (after someone saved the file) "lat": 41.69005667,"lon": -70.15217833, somehow rounded. And File:Boston - S Market St - panoramio.jpg lost it's coordinates after my save right now. So maybe an other MediaWiki / GeoData change, I will look, thank you. --DB111 (talk) 08:54, 20 October 2019 (UTC)[reply]

@Jarekt: After a code review I think I found the bug in your change, breaking GeoData: Please replace "mw.title.getCurrentTitle().namespace" by "mw.title.getCurrentTitle().nsText". Thank you, --DB111 (talk) 22:31, 20 October 2019 (UTC)[reply]

Thank you, this fixed it, files saved on the last few days probably lost their GeoData, but will regain it on next save (my nearby tool https://tools.wmflabs.org/wikimap depends on it). --DB111 (talk) 08:47, 21 October 2019 (UTC)[reply]

DB111, Great thanks for identifying the issue. I guess In the past I was always providing namespace from the template and never hit my bad call to "mw.title.getCurrentTitle().namespace". In retrospect it all makes sense. The GeoData part of the template is a bit mysterious to me, as are the tools that depend on it. --Jarekt (talk) 12:11, 21 October 2019 (UTC)[reply]

Glad to help! It's "Vodoo" for me too, so I'm always happy when GeoData is working :-) To be honestly, it's a crutch, and will be sooner or later get replaced by Wikidata. --DB111 (talk) 19:28, 21 October 2019 (UTC)[reply]

Kartographer image not unlinked

It seems that "|link=" in OSM = frame:preprocess(add_maplink(args.lat, args.lon, icon, '[[File:Openstreetmap logo.svg|20px|link=|Kartographer map based on OpenStreetMap.]]')) -- fancy link to OSM does not function. Icon has hand and it should not have anything (only cursor arrow and hover) such as here: . --Obsuser (talk) 14:20, 29 October 2019 (UTC)[reply]

It does function—there’s no link to the image description page. The image itself gets into a link (like <maplink text="[[File:Openstreetmap logo.svg|20px|link=|Kartographer map based on OpenStreetMap.]]" …>…</maplink>), which is what’s intended. —Tacsipacsi (talk) 18:16, 29 October 2019 (UTC)[reply]

Lua error in Module:Coordinates at line 237: Tried to read nil global nul.

Something's wrong with these coordinates: File:Widum Vinaders.JPG, and I don't know what it is. --Herzi Pinki (talk) 06:43, 11 November 2019 (UTC)[reply]

@Herzi Pinki: I think this was a typo of 'nul' instead of 'nil', I've changed the code and that seems to have removed the error message. @Jarekt: , please confirm! Thanks. Mike Peel (talk) 07:22, 11 November 2019 (UTC)[reply]

seems to solve the case mentioned above, thx. --Herzi Pinki (talk) 07:32, 11 November 2019 (UTC)[reply]

Categorizing error

depending the Category:Media with coordinates in DMS format: there are now 3 possible input fomats,

decimal, e.g. 4.092322|-116.156819
dms_std, e.g. 34|5|32.36|N|116|9|24|55|W
dmstyp2, e.g. 34° 5′ 32.36″ N, 116° 9′ 24.55″ W

The category is set at dmstyp2, but not at dms_std; it is erroneously set at decimal input.

In the sandbox I made a correction, which sets as well Media with coordinates in DMS format as Media with coordinates in dec format; as an addition it differs the two DMS inputs and categorizes dmstyp2 to Media with coordinates in dms format.
As far as I understand, "dec" is not intended to categorize, but both DMS should categorize Media with coordinates in DMS format ? I am not sure whether that category is very useful – but when it is used, it should be done in a correct way. -- sarang♥사랑 16:59, 30 November 2019 (UTC)[reply]

@Sarang: . Yes Category:Media with coordinates in DMS format is not working as planned. It was meant to catch:

dmstyp2, e.g. 34° 5′ 32.36″ N, 116° 9′ 24.55″ W
dmstyp3, e.g. 34° 5′ 32.36″ N| 116° 9′ 24.55″ W or Lat=34° 5′ 32.36″ N|Lon=116° 9′ 24.55″ W

style inputs but is also catching all the decimal ones. It might be a bad category name as logically it should include dms_std. I created it because I still think that we should just convert them occasionally by bot to dms_std. Your sandbox does not seem to handle dmstyp3. I will try to fix it. --Jarekt (talk) 17:39, 4 December 2019 (UTC)[reply]

Sorry, I did not yet know about dmstyp3, with 1 pipe – I just knew dmstyp1 with 8 pipes and dmstyp2 with no pipe. And the decimal type, of course. I cannot see any advantage in converting the input to another format, as long there is no problem for the template? I can mention typ3 in the examples of {{Location/general documentation}} where this case is not shown. -- sarang♥사랑 18:05, 4 December 2019 (UTC)[reply]

I did mentioned dmstyp3 in the {{Location}} documentation but more examples are always good. I was thinking about keeping the actual number of formats used low mostly for readability purposes. But you might be right, that it might not be necessary. Maybe I should just remove the category. --Jarekt (talk) 19:26, 4 December 2019 (UTC)[reply]

add parsing Ordnance Survey grid references (for GB and IE)

{{editprotected|answered=no}} In Great Britain and Ireland, locations can be specified via Ordnance Survey (OS) grid references (e.g., TQ344914 or V969909). There are more than 500 files on Commons that use such grid references: right now, they just link to geohack, but do not get the full benefits of geocoding via the {{Location}} template.

In the sandbox, I've adding OS grid reference parsing to the Coordinates module. See the diff. I just ported over Module:Oscoor from en, and so I required that in the Coordinates module. What the new code does is attempts to parse the first argument (or args.OS) as an OS grid ref. If that is successful, then the grid reference is converted to a lat/long pair and the rest of the module uses that as input. If the parse fails, the code functions as usual. (I'm assuming that people will not enter raw Wikidata strings like Q729478 as locations in args[1]).

As an extra benefit, using an OS grid reference as a location to this module will automatically set both the region parameter to geohack and the precision. Both are deterministic given the OS grid reference string.

Two new OS grid ref testcases have been added to Module talk:Coordinates/sandbox/testcases. The other testcase outputs remain unchanged.

If this looks OK, please copy the sandbox to the main module. Thanks! — hike395 (talk) 22:19, 21 December 2019 (UTC)[reply]

hike395, Module:Coordinates is used on 27M pages and feed the data into great many tools. I do not think we need to expand the template to add support for some regional georeferencing systems used by 500 images (0.000018 %). A better approach would be to just convert the locations to regular latitude and longitude and store those. --Jarekt (talk) 20:58, 22 December 2019 (UTC)[reply]

@Jarekt: Very well. I will put the new code into Module:Oscoor and make a new wrapper template. It'll be a little less elegant. — hike395 (talk) 21:11, 22 December 2019 (UTC)[reply]

Lua error in Module:Coordinates at line 258: attempt to call method 'getBestStatements' (a nil value).

@Jarekt: Your recent edit most probably just surfaced the problem with {{Object location | Wikidata= PA00094132}} on File:Rodez-Hôtel Le Normant d'Ayssènes-20140622.jpg (notice the garbage Wikidata ID). Obviously this won’t work, but it should fail more nicely (either give a specific error message, or simply ignore the unknown ID). —Tacsipacsi (talk) 20:25, 29 January 2020 (UTC)[reply]

Fixed Module:Coordinates fails more nicely now. --Jarekt (talk) 21:02, 29 January 2020 (UTC)[reply]

Coordinates and SDOC

(Discussion copied from User_talk:Jarekt )

Hi Jarek, the new MediaWiki version got deployed so I was able to add heading! I'm quite happy to see that we now have Category:Pages with local coordinates and matching SDC coordinates and that I seemed to have added quite a few files already. As you can see in the previous edit, we also have object location (coordinate location (P625)). Maybe make the same system for that one? Multichill (talk) 18:39, 15 February 2020 (UTC)[reply]

Multichill, We do have 2 templates: {{Location}} accesses P1259 from SDS and reports results using one set of categories and {{Object location}} accesses P625 from wikidata and reports to other set of categories. I guess we could allow {{Object location}} to access P625 from SDC when in file namespace and we could add words "camera" and "object" to category names. As for heading it still does not work for me, as I still can not add units using the GUI. --Jarekt (talk) 03:25, 16 February 2020 (UTC)[reply]

So {{Location}} uses coordinates of the point of view (P1259) and adds things like Category:Pages with local coordinates and missing SDC coordinates and Category:Pages with local coordinates and matching SDC coordinates. What's the other set of categories for {{Object location}}? Haven't spotted them. Or is that just the regular (not SDC) categories? Adding camera and object probably is a good way to make it clearer.

Heading got implemented on the infrastructure side, but not in the user interface yet. Seems to be nearly done.

Bonus points if you can also add tracker categories for the heading. That only makes sense on {{Location}}/coordinates of the point of view (P1259). Multichill (talk) 10:32, 16 February 2020 (UTC)[reply]

The {{Object location}} categories are Category:Pages with local coordinates and matching Wikidata coordinates (in most cases if page has {{Wikidata Infobox}} than {{Object location}} is longer needed), Category:Pages with local coordinates and mismatching Wikidata coordinates (with pages like Category:Battle of Kandel memorial where wikidata and commons location of the monument is 1.5 km apart) and similar which we had for many years now. Yes heading categories would be nice too. I guess matching/mismatching/missing again. --Jarekt (talk) 15:08, 16 February 2020 (UTC)[reply]

You're talking about Wikidata, but I'm talking about SDOC, see this example. Multichill (talk) 16:25, 16 February 2020 (UTC)[reply]

Multichill Yes so I was thinking about following changes:

I am working on new version of Module:Information where that template can take over adding camera and object locations from SDC, in addition to fetching author/source/date info in case they are missing. --Jarekt (talk) 16:52, 16 February 2020 (UTC)[reply]

Looks good to me! Multichill (talk) 16:57, 16 February 2020 (UTC)[reply]

Multichill, based on resent discussions at Village_pump or COM:CFD there seem to be a lot of users interested in minimizing number of hidden categories including SDC related categories, so I wonder which coordinate categories are really needed and which just nice to have. I feel like the "missing" and "mismatching" categories are needed, but the "matching" one would be only needed if we want to be removing coordinates from the wikitext, which I might do to my files, but will not be doing to other people files at this point. Would it break any of your processes of I remove "matching SDC coordinates" category? Another approach of making the categories less visible would be to make them shorter. I usually like category names to be descriptive but maybe changing Category:Pages with local coordinates and mismatching SDC coordinates to Category:Files with mismatching SDC camera coordinates, Category:Files with mismatching SDC P1259 or even Category:Mismatching SDC P1259 would make them more acceptable? --Jarekt (talk) 18:55, 21 February 2020 (UTC)[reply]

@Jarekt: Feel free to drop the matching categories. Only having categories for to do or to fix is fine. Multichill (talk) 17:22, 22 February 2020 (UTC)[reply]

Lua error in Module:Coordinates at line 769: Tried to read nil global dist_str.

I noticed this error at U.S. Space & Rocket Center, and I wonder if it is related to changes in this edit. Jarekt, can you diagnose? — Huntster (t @ c) 18:15, 19 March 2020 (UTC)[reply]

Fixed Thank you for reporting. --Jarekt (talk) 12:15, 20 March 2020 (UTC)[reply]

SDC link doesn’t work

On description pages like File:18-as villamos (4097).jpg, where the coordinates are from SDC, there’s a little logo (File:Commons structured data logo.svg) that tries to link to the statement—but it doesn’t work. I don’t know whether some JavaScript needs to be added to SDC to handle it, or simply the link should be removed (or changed to link to a help page), but the current situation is certainly inferior. —Tacsipacsi (talk) 11:25, 23 March 2020 (UTC)[reply]

Tacsipacsi, We are waiting for phabricator:T241338 to be completed, for those links to work. Leave a note there and maybe it will come sooner. --Jarekt (talk) 11:55, 23 March 2020 (UTC)[reply]

@Jarekt: Thanks, I hope it will work sooner or later. (By the way, this ping didn’t work. No problem, as the page is on my watchlist anyway, but pings only work if the edit in which they appear is properly signed. Or if they are in the edit summary, not in wikitext.) —Tacsipacsi (talk) 15:11, 23 March 2020 (UTC)[reply]

External link "View this and other nearby images on:" in Location template no longer shows images

When this module is used in {{Location}}, it creates external links which are introduced with "View this and other nearby images on:". One of the links goes to OpenStreetMap. Previously, that link lead to a map which showed other nearby images, as the name suggested. But this no longer happens. The map is still shown, but it contains no images at all. I have seen some discussion which seems to be connected to this problem, e.g. at https://phabricator.wikimedia.org/T201111. If I understand it correctly, it seems that there are some problems with a backend which has problems with maintenance. Someone suggested switching to https://tools.wmflabs.org/wikimap/?wp=false (which routes to https://wikimap.toolforge.org/?wp=false). And it seems that this tool does what the other previously did but no longer does: link to all images on Wikimedia Commons which have been taken nearby. So, my suggestion would be the following: Switch the variable "OpenStreetMap1" from "//tools.wmflabs.org/wiwosm/osm-on-ol/commons-on-osm.php?zoom=16&lat=$lat&lon=$lon" to "//tools.wmflabs.org/wikimap/?lat=$lat&lon=$lon&wp=false&zoom=16". (Maybe the variable name and the link name in the template then should also be changed, because we no longer directly use OSM.) But I should say that I have only taken a very casual look at this problem and I have no knowledge about coding in Commons. So it is possible that I misunderstood something completely. Spike (talk) 23:49, 20 July 2020 (UTC)[reply]

Agree over the last decade we have quite a lot of tools displaying nearby images on Google maps, Bing Maps, Google earth, and 3 or 4 different implementations of OSM maps. The often work for couple years than stop working or stop showing nearby images, than work again. One issue if is that it is often unclear who maintains the tools and corresponding databases. Maybe the best way would be to create some table off all the tools, maintainers and their capabilities and add it to com:geo somewhere. Such table should have some test links so we can more easily verify that the tool is still working. In the mean time I will look into swapping the OSM link. --Jarekt (talk) 15:12, 21 July 2020 (UTC)[reply]

Category:Media with erroneous locations - Object location template

Several articles in Category:Media with erroneous locations, e.g Lyon, display "Error: Invalid parameters! (coordinates are missing or not numeric)" due to Template:Object_location being used in namespaces where the template was not intended to be used. Thanks to User:Roan_Kattouw_(WMF) who pointed out that “Inside the if entity then ... block, the lat/lon lookup only happens if namespace === 'File' or if namespace === 'Category', but if the namespace is anything else it doesn’t happen”. --Zilant17 (talk) 00:32, 28 July 2020 (UTC)[reply]

Edit request

{{Edit request}} Please change

	OpenStreetMap1 = '//wiwosm.toolforge.org/osm-on-ol/commons-on-osm.php?zoom=16&lat=$lat&lon=$lon',

to

	OpenStreetMap1 = '//wikimap.toolforge.org/?wp=false&basemap=2&cluster=false&zoom=16&lat=$lat&lon=$lon',

The old version obvious doesn't work. Habitator terrae 🌍 10:23, 17 August 2020 (UTC)[reply]

Done thanks that does work better. --Jarekt (talk) 14:34, 17 August 2020 (UTC)[reply]

Warning should add links

We see

There is a discrepancy of 3691 meters between the above coordinates and the ones stored at SDC (24°9′0″N 120°52′37″E, precision: 5 m). Please reconcile them.

Link whatever "SDC" means.
Link to whatever reconcile steps there are. (We updated the {{Location}}, causing the warning.)
Link to where to discuss this warning. We only got here via the Category.

Jidanni (talk) 17:50, 23 September 2020 (UTC)[reply]

OK I removed the "Structured Data" item, but the warning remains in the page. Jidanni (talk) 18:07, 23 September 2020 (UTC)[reply]

Consider ranks for `function getSDCoords()`

function getSDCoords() should consider ranks. That it doesn't results in picking the not preferred (and old) coordinates from d:Q2133582#P625 and displaying them at Category:Rautenstrauch-Joest-Museum and erroneously setting Category:Pages with local object coordinates and mismatching Wikidata coordinates there for example. --Marsupium (talk) 17:59, 7 October 2020 (UTC)[reply]

I will look into this. --Jarekt (talk) 20:17, 7 October 2020 (UTC)[reply]

Fixed @Marsupium: --Jarekt (talk) 01:46, 9 October 2020 (UTC)[reply]

360 degree deviation produces error

File:Glass_Dome_of_Reichstag_building,_Berlin.jpg produces a warning because the SDC heading is 360 degree but the template input of 360 degrees is converted to 0 degree (in p._getHeading(attributes)). The two are obviously the same direction and the error can't be removed by changing the template parameter. As far as I can see the problem is triggered by local function compareCoords(loc, sd, mode, source) and in particular line 291: local dh = math.abs(loc.heading - sd.heading) together with the following check if dh>1. Just fixing a disagreement of exactly 360 degrees is easy by adding %360, but if we change the code I suggest to do it more generally, to also cover cases like 0 and 359 or 1 and 360: Change line 291 to local dh = math.abs(loc.heading%360 - sd.heading%360) and 292 to if dh>1 and dh<359 then. --mfb (talk) 15:29, 30 October 2020 (UTC)[reply]

Done mfb I agree that is a better way to calculate it, and I implemented your suggestion. --Jarekt (talk) 21:20, 30 October 2020 (UTC)[reply]

Is it intentional that the font in "embedded" mode, i.e. |bare=0 is so tiny? Compared to the fields displayed by {{Information}}, the font size is considerably smaller which makes for a weird layout when {{Location}} is used together with the information template. De728631 (talk) 23:07, 14 January 2021 (UTC)[reply]

The module does not directly set the font size. In case of template without "bare" option the content is added to a table with some formatting set somewhere else. In case of "bare" option there is no outer table or formating so the font setting depends on HTML around it. --Jarekt (talk) 04:35, 19 January 2021 (UTC)[reply]

Loss of categories

Special:Diff/405212917 by Jarekt commented out the code that categorised pages using this module into Category:Media with locations, Category:Galleries with coordinates, or Category:Categories with coordinates. This has apparently taken a little while to have effect, but Category:Media with locations is down to 123,402 members. Are these categories being deliberately phased out? If so, I'll make an effort to remove references to them. --bjh21 (talk) 21:49, 24 March 2021 (UTC)[reply]

bjh21, that was a while ago and I totally forgot about it. The categories Category:Media with locations, Category:Galleries with coordinates, and Category:Categories with coordinates seemed to be redundant to Category:Pages with maps, which is somehow added to all the pages using Module:Coordinates. It did not seem necessary to have both. Also categories with large fraction of images we host do not seem useful, as they are too broad to do anything with. --Jarekt (talk) 00:21, 25 March 2021 (UTC)[reply]

@Jarekt and Bjh21: Pages with maps is added by the Kartographer extension, and it’s not exclusive to pages using this module—for example, it also contains pages that display maps in the {{Wikidata infobox}}, as well as eventual pages using raw <mapframe> and <maplink> tags. —Tacsipacsi (talk) 23:52, 27 March 2021 (UTC)[reply]

Just to note that the infobox uses this module. Thanks. Mike Peel (talk) 08:13, 29 March 2021 (UTC)[reply]

@Mike Peel: But only to show the GeoHack link. The GeoHack link alone doesn’t put the page into Category:Pages with maps, it’s the direct {{#tag:mapframe}} call in the /core source code that causes the category to be added. (Category:Categories with coordinates wouldn’t be added if only the GeoHack link is requested from this module.) —Tacsipacsi (talk) 19:53, 29 March 2021 (UTC)[reply]

True, but both should be shown together if coordinates are present (never one and not the other), unless it's not on Earth (Q2). At least as presently coded. Thanks. Mike Peel (talk) 08:12, 30 March 2021 (UTC)[reply]

Broken where link attributes are entered and coordinates are fetched from Wikidata

{{Edit protected}} The following template parameters result in an error after recent changes to this module by User:Verdy p:

{{Object location|scale:3000|Wikidata=Q2669946}} (usage example)

The issue is not there if version of this module as of 30 April 2021 is used in sandbox:

~~{{Object location/sandbox|scale:3000|Wikidata=Q2669946}} (usage example)~~ (example no longer work after Verdy's subsequent sandbox change)

So probably version of this module as of 30 April 2021 should be restored. Category:Pages with script errors currently includes 2463 category pages that use {{Object location}}. Presumably most, if not all, of these pages are affected by this issue. 2001:7D0:81DA:F780:604B:475D:A352:7506 11:15, 23 October 2021 (UTC)[reply]

This cannot be a "simple" restoration, there's been numerous other fixes (notably for broken URLs and borken services that caused many more failures elsewhere). May be there's some remaining case that cases this "nil" value being passed instead of a string, but it should be easiy to isolate (and such case was not part of any preexisting testcase that were existing at that time). And this is not affecting a lot of pages so its fix will be easy to isolate

For long this module was left unmaintained, passing incorrect URLs and using old external services that either did no longer exist or were not updated. Ad well the URL encoding was wrong in many cases. I have dramatically reduced the number of these errors, but of course I could not test thousands of pages (and it took a long time for other categories to reflect the change, now it's just a few pages). I'm sure it is easily fixable. Reverting all would just reintroduced the various old bugs that were patiently fixed one by one. I can test many things, but undocumented testcases like this can always produce such caveat. Many modules don't have enough test cases for their actual usage, or there was un related changes elsewhere outside this module that caused it to bug now (this module has dependencies...).

For your statement that "resumably most, if not all, of these pages are affected by this issue", this is wrong as given by the statistics of usage (there are 4,781,095 inclusions of the module, and just 0.05% pages broken; I thinkg that Wikidata now no longer returns some info as an empty string as it did in the past but now just as nil and if so this is easy to isolate and fix). verdy_p (talk) 14:36, 23 October 2021 (UTC)[reply]

For your information, I've also added a few testcases at that time and fixed those that were no longer working: Module_talk:Coordinates/testcases. There are probably more testcases to do. HEre it seems that the coordinates from Wikidata are now returned in an unparsable format, so the 4 parameters returned by splitting transforming and the string on "/" do not return always 4 strings but less: this causes the "nil" value to occur. I think that now coordinates from Wikidata are returned in decimal format and the module expected the string to be in degree/minutes/seconds/fractions: there's no test about this as this is inside an internal local function, not exposed directly into existing testcases. The parsing code seems to make fragile assumption about the input (but it has always been the case). verdy_p (talk) 14:52, 23 October 2021 (UTC)[reply]

Note: the sandbox now includes the very simple fix (without reverting everything): it just checks that there is an actual value for the 4th parameter (h) which should be a heading direction. If this is not the case, the function returns nil and the caller function returns the unparsed string that is already in decimal format. For various reasons, the heading direction (in h: could be "n", "s", "w", "e") could be in lowercase and the lookup table is indexed on uppercase values only. There was already a test if the lookup failed but there was no test prior to calling "upper()" which does not work with a "nil" value. For some strange reason, the "deg2dms()" function is intended to convert dms to decimal but can also receive a decimal value in borderline cases, inc which case the caluie should used as is... None of the documented testcases where testing that "feature". verdy_p (talk) 15:04, 23 October 2021 (UTC)[reply]

Also this case occurs in categories where {{Object location}} should NOT even be used at all in categories (it adds an unnecessary top banner, which duplicates what is rendered in the infobox, which was not affected at all and correctly displayed the coordinates). Those ~4000 categoies should be fixed to drop this template use (if they have an infobox: no need to keep both). verdy_p (talk) 15:13, 23 October 2021 (UTC)[reply]

Note: you artificially created this bug months after the module was changed, just to "pseudo-demonstrate" a bug that should not exist and did not exist: you added the {{Object location}} template in that category, which should not be there as there was already an infobox. {{Object location}} was not made/tested for inclusion in category pages, and was designed only for use in file description pages, that don't exhibit this bug. verdy_p (talk) 15:31, 23 October 2021 (UTC)[reply]

As well there are FAR LESS pages actually affected (most category pages are already correct, but the tracking category has kept some categories that were affected by other unrelated bugs, that no longer apply. So pages/catergories listed in this tracking category should be refreshed (you can visit them: no such error is reported; "null-edit" them to purge them from the tracking category). You can do that manually or using a slow bot to perform null edits (at least on categoy pages, most of them for "<year> in <US state name>" and which should no logner be tracked there. Tracking categories are not purged instantly, MediaWiki reprocesses these pages automatically but at very slow speed (this could take months before they are parsed again to remove them from the tracking category). verdy_p (talk) 15:24, 23 October 2021 (UTC)[reply]

Eh, you mix up several things and all in all this myriad of text is not quite helpful as it seems to have very little to do with given issue. Firstly, if only you cared to check page history you'd see that I *did not* create or "pseudo-demonstrate" the issue, the issue is present in category page version prior to my test edit, and also on many pages in given tracking category, e.g. on Category:San Cristóbal (Galápagos) and Category:Hervormde kerk (Noordhorn). Thirdly, contrary to your claim, the issue sure does affect file pages as well, from the same tracking category you can find file pages with the same error, e.g. File:Tinténiac (35) Église Intérieur 24.jpg.

Broken/outdated or badly encoded URL-s that you talk about are apparently those that are handled by toollabs:geohack service and in part are maintained on Wikipedia pages like en:Template:GeoTemplate. Given module/template only links to GeoTemplate links page. So it's hard to see what bugs you think you "patiently fixed one by one" really here in this module. You now say that earlier you added some other broken testcases, but page history reveals that really you did not. Neither can I find older talk comments showing what exactly was broken before you touched this module and needed to be fixed.

I see that out of all pages using this module the percentage of those with errors isn't very high, but really there shouldn't be any errors, and as demonstrated, errors currently present definitely didn't exist before you touched this module. While it's unclear if there were more issues or any other issues before. I also see that given template may not be necessary on many category pages, but so far it's in use and errors are there, and as said, not only category pages are affected.

Generally, your changes would be much more helpful if you'd fix particular (demonstrated) bug by changing as little as possible. If you make minor changes throughout the code, then your changes are more or less unreviewable, it's hard for others to tell what bug exactly you intended to fix with exactly what change. In this situation it's still likely reasonable to revert all and start over, if necessary.

Your latest sandbox change may be a sufficient fix. However, please note that while you suggest to purge category pages in order to fix the issue, you actually did not apply this fix in production code.

@Jarekt: I see you have been maintaining this module before. Could you please check if Verdy's changes are worth preserving, or if their latest sandbox change'd be sufficient to fix current script errors. 2001:7D0:81DA:F780:E97E:D9EC:CA5:461E 09:44, 24 October 2021 (UTC)[reply]

Done I rolled back the changes to April version. Jarekt (talk) 21:22, 24 October 2021 (UTC)[reply]

That's a very unfair revert that reintroduces various bugs (including dead URLS, broken URL encoding...). The only fix was to apply a check of nil in that function and it was working AS IS with a single line for this borderline case that was NEVER tested before, and for a new usage added months after in a category for which the template was explicitly documented as being not made for. Do you really test things? I made many tests that you did not do before, and have still nor done. There was an unrelated changed mademonths after me. There was no problem at all for months until a borderline usage case was added that was extremely easy to fix. But now we've got many more errors with your reverts (all those that I had patiently fixed months ago.

This module has never caused any errors for months, it occured jsut a few days ago, but did NOT affect the ~4000 categories listed except those where the banner template was added recently, which passes incorrect parameters when it is included in a category (that banner explicitly documents it is made for file description pages only, and that's how it has always been used).

Detecting the nil value of the "heading" parameter was fixed in the sandbox version (and tested successfully on the reported category). It was only caused by the call to "upper(h)" which could be nil when there was a single parameter passed (i.e. when there was no conversion at all for angles in decimal degrees). I've passed a long time to investigate various bugs (in sandbox and testing in all documented cases and manually in hundreds of pages) and test them before applying them. And there was NO bug at all for many months, so that bug can only be caused by a recent change made elsewhere, in another module or template.

Also I could apply the simpe fix because you've blocked the module, but the oneline fix in the sandbox was working.

There's not been a correct estimation of the effect of that bug occuring in such borderline case (which occurs extremely rarely).verdy_p (talk) 22:08, 24 October 2021 (UTC)[reply]

Your claim that broken use cases were introduced months after you changed this module is simply not true. Everyone can check from module page history that you made your changes in early September this year, while example category pages with errors referenced above were last changed long before that.

I didn't realise you no longer have the right to change the module itself. It appears that reasons around revoking your rights, as outlined on your user talk page, are pretty much the same as the problem here. In both cases you make extensive and unreviewable changes to "fix" god knows what bugs, and afterwards you are incapable to admit that you have broken things. It's probably for the best if you have to recommend and justify changes on talk page as the rest of us do.

I suggest you start new topic for each of these possible other bugs and demonstrate each of these in clear a manner. As far as I can see, all tests that there are and that worked before, are still working now after your changes were reverted. 2001:7D0:81DA:F780:30C1:70CD:3B89:EE96 08:05, 25 October 2021 (UTC)[reply]

Incorrect DMS categorization

Hi, there seems to be some kind of bug in this module with regard to the DMS maintenance category and wikidata. For example, the file File:Ancy-le-Franc (89) Château - Intérieur - Cabinet de Pastor Fido - 02.jpg is incorrectly added to Category:Media with coordinates in DMS format by this statement {{object location|region:FR|Wikidata=Q579961}}. Potentially it has to do with the Wikidata reference. Could someone have a look? --Schlurcher (talk) 22:32, 5 January 2022 (UTC)[reply]

Broken OpenStreetMap links

@Jarekt: Your recent edit has broken the OpenStreetMap links in every use of the {{Location}} template. I'm not sure what Lua errors you were trying to fix, but I've reverted your edit. —RP88 (talk) 03:34, 23 January 2022 (UTC)[reply]

Lua Error if Wikidata Info is missing

Hi, i've encountered a Lua error thrown by Module:Coordinates if the Template Object location is applied on a Commons Category lacking a Link to Wikidata. The error is: "Lua error in Module:Coordinates at line 168: attempt to index local 'entity' (a nil value)." This happens if the template is added to a commons category that has no link to wikidata (e.g. using the Wikidata infobox Template). For example: 3_Sadovskoho_Street,_Lviv. Adding a wikidata item removes the error. This may affect a lot of commons categories lacking a wikidata link. Is there a way to solve this issue? Fl.schmitt (talk) 08:36, 30 June 2022 (UTC)[reply]

Addendum: This seems to affect the vast majority of Categories using the Object location template. Currently, there are 28.213 Subcategories in Category:Categories with coordinates. 28.180 of them are lacking a Wikidata item, thus the Object location template doesn't work there. Fl.schmitt (talk) 09:06, 30 June 2022 (UTC)[reply]

@Jarekt: Thank your for fixing this one - now it's working again!

Fixed Fl.schmitt (talk) 13:59, 30 June 2022 (UTC)[reply]

Why not

shorten the table defs ? (all linefeeds etc. are contained in the following source code)
stmt 84ff: -- files to use for different headings local heading_icon = { [ 1] = 'N', [ 2] = 'NbE', [ 3] = 'NNE', [ 4] = 'NEbN', [ 5] = 'NE', [ 6] = 'NEbE', [ 7] = 'ENE', [ 8] = 'EbN', [ 9] = 'E', [10] = 'EbS', [11] = 'ESE', [12] = 'SEbE', [13] = 'SE', [14] = 'SEbS', [15] = 'SSE', [16] = 'SbE', [17] = 'S', [18] = 'SbW', [19] = 'SSW', [20] = 'SWbS', [21] = 'SW', [22] = 'SWbW', [23] = 'WSW', [24] = 'WbS', [25] = 'W', [26] = 'WbN', [27] = 'WNW', [28] = 'NWbW', [29] = 'NW', [30] = 'NWbN', [31] = 'NNW', [32] = 'NbW' }

stmt 813: local fname = 'File:Compass-icon bb ' .. heading_icon[k] .. '.svg'

-- sarang♥사랑 11:51, 16 October 2022 (UTC)[reply]

show OpenStreetMap1 also on categories

Currently the second link points to different places depending on whether {{Object location}} is used on files or on categories.

On files, OpenStreetMap1 is used (wikimap.toolforge.org).

On categories, this is OpenStreetMap2 (tools.wmflabs.org/osm4wiki).

I still haven't figured out how to use the later, accordingly I'd use OpenStreetMap1 on both. Enhancing999 (talk) 20:40, 16 October 2022 (UTC)[reply]

To change this, please replace line 130 with:

OpenStreetMap2 = OpenStreetMap1

Thanks. Enhancing999 (talk) 18:25, 25 October 2022 (UTC)[reply]

Enhancing999, I just noticed this edit request, but do not understand the reason for it. OpenStreetMap1 is a basic OpenStreetMap link and OpenStreetMap2, which is only used for categories, shows OpenStreetMap with locations of all the photos in that category marked on the map. I just tried it on Category:Tiruvannamalai and it still seem to work. --Jarekt (talk) 02:07, 19 June 2024 (UTC)[reply]

@Jarekt Forgot about that. In the meantime the osm4wiki-tool got fixed. Also, it has a new url (for the sample):

An additional link to Wikimap could still be useful. Not sure which one to suggest: the infobox has one for the category and personally I mostly work with the one for surroundings (as present on files).Enhancing999 (talk) 08:05, 19 June 2024 (UTC)[reply]

Enhancing999, I think the reason I have a link to osm4wiki instead of wikimap is for categories instead of keeping wikimap link and adding osm4wiki, due to naming issues. At some point we could overlay nearby images on top of Google Maps, Google Earth, Bing Maps and OpenStreetMaps, so we had all of them listed in the template and it was too crowded to add a 5th one. Then we lost ability to overlay images on anything but OpenStreetMaps through wikimap.toolforge.org and another OpenStreetMaps through osm4wiki.toolforge.org. I think it is fine to have them both for categories but I am not sure what to call them as I can't call them both "OpenStreetMaps". I noticed, default layer for wikimap.toolforge.org is now "Wikimedia maps" and not OpenStreetMaps so maybe I will switch the name of the link to wikimap.toolforge.org to "Wikimedia map". Any thoughts? --Jarekt (talk) 19:39, 19 June 2024 (UTC)[reply]

Apparently there is some politics involved why "wikimaps" doesn't use OSM-OSM (which I prefer) as default, but WMF-OSM.

The disadvantage I see with osm4wiki is that it limits the results to the category, a thing the "wikimaps" can do (and does in the infobox), but I don't find that useful. Obviously, the usefulness depends on the search being done (and type of category). Enhancing999 (talk) 22:20, 19 June 2024 (UTC)[reply]

require('strict')

{{Edit protected}} As per the new lua feature mentioned at m:Tech/News/2022/42, could require('Module:No globals') be replaced with require('strict') -- WOSlinker (talk) 17:21, 25 October 2022 (UTC)[reply]

Done. Jonesey95 (talk) 04:46, 26 October 2022 (UTC)[reply]

Reconcile by one click (or even automatically)

Would be possible to create a script which would reconcile the SDC coordinates and camera heading by one click from the warning box, instead of linking Commons:Structured data/Reconciliation page? That can help also bypass the bug phab:T313638 that remains unsolved for two years.

Alternatively, SDC update could occur automatically without user intervention.

Alternatively, it is possible to distinguish in SDC how the coordinates were entered.

If they were filled in automatically from the location template, then they should also be automatically updated based on a change or deletion of the location template. If the source Location template is deleted from the file page, the SDC data taken from it should be automatically deleted as well, since it can be assumed that there was a reason for deleting the template (coordinates error, or specifying coordinates is undesirable).
If the SDC coordinates were created directly from Exif, or entered manually, then the conflict with the Location template can be considered "manually", by any user. But it is probably better to assume that the coordinates from the Location template are always superior to the coordinates in the SDC. At least until this duality is overcome.

ŠJů (talk) 23:27, 14 August 2023 (UTC)[reply]

Template Globe location doesn't work for non earth globes

Cross-posted here, from Template talk:Location#Template_Globe_location_doesn't_work_for_non_earth_globes, because the template directly calls this module {{#invoke:Coordinates| LocationTemplateCore |mode=globe}} (Note: the other comment was written at Template talk:Location, because the talk page for Template talk:Globe location redirects there)

In the documentation of this template ("Location") it states "{{Globe location}} used to provide object location on other globes, like Moon, Mars, etc." and in the documentation of Template:Globe location there are examples for that:

{{Globe location|34.02427|-116.15830|moon}}

which creates

Location	34° 01′ 27.37″ N, 116° 09′ 29.88″ W	View all coordinates using: OpenStreetMap

and

{{Globe location|34|1|27.37|N|116|9|29.88|W|mars}}

which creates

Location	34° 01′ 27.37″ N, 116° 09′ 29.88″ W	View all coordinates using: OpenStreetMap

However, both links show the earth in Geohack. The problem is that the template creates the parameter "globe:Earth_moon" and "globe:Earth_mars" in the URLs respectively, which causes the problem. If the output was "globe:moon" or "globe:mars" it would work. This should be fixed by somebody who has the right to edit the code of the Module:Coordinates (and knows what they are doing), as the template itself just calls {{#invoke:Coordinates| LocationTemplateCore |mode=globe}}.

Also the documentation of the Template:Globe location should be expended to better describe the use of the globe parameter, and not just have it hidden in the example. But this should be done, once the main issue is fixed.

A workaround would be to directly call the function of the module that creates the link: {{#Invoke:Coordinates | GeoHack_link| lat=34.02427 | lon=-116.15830 | globe=Mars }}} will create 34° 01′ 27.37″ N, 116° 09′ 29.88″ W (an issue with that was addressed in the section #Globe_problem from above)

Thanks, DFichtmueller (talk) 10:04, 12 January 2024 (UTC)[reply]

There seems no issue with the module, the example syntact on the template is incorrect. Let's continue the discussion there. --Schlurcher (talk) 20:42, 13 January 2024 (UTC)[reply]

Non-existent categories

Is it this module which is populating lots of categories which don't exist? For example Category:Files with coordinates missing SDC location of creation (53° N, -2°E) on File:Moore Avenue - geograph.org.uk - 603371.jpg? — Martin (MSGJ · talk) 15:11, 8 May 2024 (UTC)[reply]

Usage of P625?

@Jarekt: sometimes people use coordinate location (P625) instead of coordinates of the point of view (P1259) here. Can we flag this with a category so it can be cleaned up? Multichill (talk) 17:20, 13 August 2024 (UTC)[reply]

@RZuo and Multichill: , I can add a tracking category for files using coordinate location (P625) in SDC; However I can not tell if they meant it as camera location or object location. Photos of specific statue, house, or other immovable object often have {{Object location}} template or coordinates of depicted place (P9149) property, and if someone add coordinate location (P625) instead of coordinates of depicted place (P9149) to such a file then it is not ideal but understandable. There are 165,398 files using coordinate location (P625) in SDC. Do we want a category for them? --Jarekt (talk) 15:05, 16 August 2024 (UTC)[reply]

@Jarekt: 165,398 is quite a lot. Maybe we can split these out?

coordinate location (P625) exactly the same as coordinates of the point of view (P1259) -> 309, not much
coordinate location (P625) exactly the same as coordinates of depicted place (P9149) -> 1947, not much better
coordinate location (P625) exactly the same as {{Location}}
coordinate location (P625) exactly the same as {{Object location}}
coordinate location (P625) with coordinates of the point of view (P1259) and coordinates of depicted place (P9149) -> 931
coordinate location (P625) with coordinates of the point of view (P1259) -> 2486
coordinate location (P625) with coordinates of depicted place (P9149) -> 2198
The rest?

That way we can at least clear some out? Let's see how much matches. Multichill (talk)

Multichill some files with P625 are sound clips like File:Margarornis squamiger - Pearled Treerunner XC249506.mp3 for which other 2 properties do not seem to fit. I would leave those alone. I tried to remove some P625s statements with QuickStatements ("-M85011849 P625 @47.07875833333333/-22.875841666666666" for example) but for some reason it is not working. I never used QS for removing coordinates, so I am not sure what is going on, but I think there is some issue with insane number of digits in many of the coordinates (precision in above example is 100 nanometers or about size of DNA) which is not returned in full in SPARQL queries and is not handled correctly by QS. Maybe it is something you can remove with python code? --Jarekt (talk) 04:38, 17 August 2024 (UTC)[reply]

@Jarekt: For sound we use depicts (P180) too. It's not what you see, but what you hear. Same the coordinates. Where is the sound coming from and from where did you hear it?

My plan is to set up a bot to fix some things automatically. Need some tracking categories for that so I know what to work on. Multichill (talk) 10:40, 17 August 2024 (UTC)[reply]

Multichill, I am adding categories now. See Category:Media with locations group 3, although it might take a long time for the categories to populate unless my purge them somehow. --Jarekt (talk) 14:10, 19 August 2024 (UTC)[reply]

Multichill, I was thinking about capturing files using P625 without using {{Location}} template as those will not be categorized. I can not think of a way to search for them, as I do not recall any tools that combine SPARQL and SQL searches. I can't even think of a way to add a category to 165k files using P625 or convert 165k M-ids to filenames. Even hard to use Module:SDC tracking as there is no template to add it to, other than {{Information}}. Some examples:

--Jarekt (talk) 14:37, 19 August 2024 (UTC)[reply]

Jarekt I see I used the old property in one of my batch uploads and changed it later in the code.

I think most if not all of these 209,184 files were affected, but some were already fixed. I'll have a bot touch some files and I'll ask User:Schlurcher he can have his bot monitor Category:Media with the same P625 and object coordinates.

Coordinates templates are not in search and not in the database. I think I'm just going to add {{Object location}} to the files to get the tracking up and running. Multichill (talk) 17:17, 19 August 2024 (UTC)[reply]

Jarekt looks like the usage of {{object location | Wikidata = Q3517702}} on File:Salinelles-Temple Protestant-20160615.jpg adds Category:Media with P625 and object coordinates. I don't think that is intended, right? Multichill (talk) 18:21, 19 August 2024 (UTC)[reply]

Multichill, Category:Media with P625 and object coordinates is for files that have different coordinates in P625 and the template. We should also have Category:Media with P625 and camera coordinates. See the code in Module:Coordinates lines 707-733. By the way, I am touching Category:Photographs_by_Vlaamse_Gemeenschap, so no need to bother with that one. --Jarekt (talk) 20:03, 19 August 2024 (UTC)[reply]

@Jarekt: I think you missed the point, have a closer look at the wikitext: It only has {{object location | Wikidata = Q3517702}}, nothing else and nothing in SDC. The only coordinate location (P625) is on Temple de Salinelles (Q3517702). I don't think this file should have any tracker category. Multichill (talk) 20:19, 19 August 2024 (UTC)[reply]

Multichill, I did missed the point. Yes I will try to exclude files like this. --Jarekt (talk) 03:00, 20 August 2024 (UTC)[reply]

It was even worse than I thought as the P625 was not on SDC but on Wikidata. I think it is fixed now. --Jarekt (talk) 04:04, 20 August 2024 (UTC)[reply]

Jarekt thanks! Easy to miss with all the date being pulled from different sources and glued together. Looks correct now. Multichill (talk) 16:43, 20 August 2024 (UTC)[reply]

I think coordinate location (P625) should just not be used at all and phased out. --Schlurcher (talk) 09:41, 20 August 2024 (UTC)[reply]

Schlurcher completely agree. If I recall correctly, we started with coordinates of the point of view (P1259) & coordinate location (P625). We realized coordinate location (P625) was ambiguous, so we got ourself a new property: coordinates of depicted place (P9149). I don't think we ever did the clean up after the switch.

I would propose we just switch every instance of coordinate location (P625) to coordinates of depicted place (P9149). Multichill (talk) 16:43, 20 August 2024 (UTC)[reply]