Template talk:Location/2013

Can we add a link?

Some may find this easier:

• http://toolserver.org/~locator/coordinates.php

It writes the syntax after you move the map, zoom, then double-click the point you want on the map. Could we put it in the see also section? There may be other pages that could use it as well.--Canoe1967 (talk) 21:24, 2 January 2013 (UTC)

Wow! Make it do headings too and it'd be perfect.  ;) Powers (talk) 03:07, 4 January 2013 (UTC)

I think that is more or less the same place where you go if you click on the globe. --Jarekt (talk) 03:44, 4 January 2013 (UTC)

@Jarek if you set the correct WMF page, then double click the map you will notice it writes the geo data template below the map for you. {{Location|51|18|36.05|N|5|12|27.07|E|...}} is close to the center of the home page.--Canoe1967 (talk) 06:31, 4 January 2013 (UTC)

Adding {{#coordinates:}}

{{Edit request}} As mw:Extension:GeoData is introduced, we can use {{#coordinates:}} parser function to geocode images. Is it needed to set "primary" on this template? – Kwj2772 (msg) 02:49, 23 February 2013 (UTC)

Note: Pages that have two or more primary coordinates will be categorized to Category:Pages with malformed coordinate tags. – Kwj2772 (msg) 03:06, 23 February 2013 (UTC)

There should not be more than one camera location per picture. So I suggest making it primary for {{Location}}. I suppose there may be a handful of fringe cases (collages?) with more than one Location template. If we find one of those, we'll have to add a parameter to suppress the primary flag, or remove Location templates from those images. Until then we should assume one Location template per image and go ahead. --Dschwen (talk) 14:57, 23 February 2013 (UTC)

 Done Added on {{Location}} & {{Location dec}}. – Kwj2772 (msg) 08:05, 24 February 2013 (UTC)

Ok, there are a handful of pages with multiple primary coords now. Mainly gallery pages (I guess the documentation pages for Location are affected as well). How about this: Add #coordinats: only when in file: namespace. --Dschwen (talk) 14:48, 24 February 2013 (UTC)

I was thinking File and Category, but than I remembered that categories should not have {{Location}} templates but {{Object location}} templates. So restricting it only to files seem fine. How about categories with {{Object location}} template - shall we add #coordinats to them? --Jarekt (talk) 14:29, 25 February 2013 (UTC)

Baby steps ;-). Let's do Location first and then Object location. Can you add the namespace conditional, I fear my template mojo is past its expiration date. We can trial adding coordinates to object location in category pages and then just see how many are added to that broken coordinates category. --Dschwen (talk) 14:53, 25 February 2013 (UTC)

 Done with restricting {{#coordinates:}} to files only. We seem to have over 3200 files in Category:Pages with malformed coordinate tags. Most of those I looked at, made sense. Apparently {{#coordinates:}} parser function checks for more issues than our templates. Template detected issues go to Category:Media with erroneous locations, which some unknown kind soul keeps clean. By the way I can not imagine scenario when we would need to use "secondary" parameter. Anybody knows when would we use it? But than again I do not know much about {{#coordinates:}} function. --Jarekt (talk) 16:33, 25 February 2013 (UTC)

Maybe files with both templates {{Location}} and {{Object location}}, I imagine, such as File:Schloss Büdingen.jpg. – Kwj2772 (msg) 17:29, 25 February 2013 (UTC)

I would absolutely reccomend against giving Object location a primary status on file pages. As a matter of fact in my opinion using Object location on file pages is mostly retarded. The only reason I can see is if no category for the depicted object exists. --Dschwen (talk) 17:36, 25 February 2013 (UTC)

There are certainly reasonable use cases for using object location on file pages. Consider File:MS Viking Cinderella.jpg. Geotagging the category for the depicted object hardly makes sense, since it's not stationary. The subject is more than 3 km from the camera, so it would be very hard for a third party to identify the location of the subject unless they were already familiar with the area. —LX (talk, contribs) 19:16, 25 February 2013 (UTC)

Yeah, I guess there are exceptions to every rule ;-). --Dschwen (talk) 19:17, 25 February 2013 (UTC)

The main point still holds. Location=primary Object_location=secondary on file pages. That keeps it simple and is the sensible choice for the vast majority of usecases. --Dschwen (talk) 19:19, 25 February 2013 (UTC)

Lets forget for a moment about {{Object location}}. Are there any cases where we would like to have {{Location}} used in the file namespace with "secondary" parameter? I am asking since users have choice now to make their {{#coordinates:}} "primary" or "secondary" through with a new parameter. I can not think of a scenario where that would be useful. --Jarekt (talk) 19:43, 25 February 2013 (UTC)

Well do we have any files with multiple Location templates? For a good reason? Only thing that comes to mind are collages. --Dschwen (talk) 20:53, 25 February 2013 (UTC)

Yes I guess it happens like in File:117 Herford Tafel 55.jpg. --Jarekt (talk) 03:50, 26 February 2013 (UTC)

10k files in Category:Pages with malformed coordinate tags

We have now over 10k files in Category:Pages with malformed coordinate tags with a large number of different issues. Some issues I observed:

1. ~1200 files which are also in Category:Flickr images reviewed by File Upload Bot (Magnus Manske), like File:Fumerole by Bruce McAdam.jpg. Those often have 2 issues:
   • "{{#coordinates:}}: cannot have more than one primary tag per page", caused by adding both {{Location}} and {{Location dec}}
   • '{{#coordinates:}}: invalid longitude", caused by negative degrees in {{Location}}.

   I do not know if that is an old issue with flicked uploads by user:Upload Bot (Magnus Manske), or is the bot still doing it.

2. files like File:Altstadt Mulhouse.JPG which had 2 separate location templates with different locations provided by different users ( I picked the one by the photographer). Other examples: here
3. files like File:Lago Todos los Santos.jpg with minutes or seconds values bigger or equal 60. Other example: here.
4. files with "Invalid arguments have been passed to the {{#coordinates:}} function", triggered by "invalid" attribute parameter. For example: File:Sutera BW 2012-10-07 18-01-21.JPG with empty attribute parameter, File:Jickovice okres Písek (28).JPG with seemingly correct attribute parameter. I have seen one triggered by "heading:22".
5. I have also observed one badly formed coordinates extracted from EXIF data, but I lost that file somewhere.

Over all random sampling of about 50 files showed that ~80% were already fixed by some recent change to {{#coordinates:}} and were no longer in the category, but I guess the database did not updated the category yet. --Jarekt (talk) 14:07, 26 February 2013 (UTC)

Number 1 is a case for a bot. If both locations are the same just kick out Location dec. I also observed files where the minute field in Location had a decimal point and yet the seconds were specified as well (No idea how to fix that). Complaints about heading should be filed as bugreports to Max Semenik. I'm going to meet him in 10days. --Dschwen (talk) 14:15, 26 February 2013 (UTC)

https://gerrit.wikimedia.org/r/51124 Max Semenik (talk) 10:44, 27 February 2013 (UTC)

Max, that diff seems to adress the fractional minutes when seconds are present. I thought this was already caught as an error. What I meant to be filed as a bug was the heading issue (if it is an issue). We allow degrees (numbers from -180 to 360) and compass names (N,NNE , WNW, SW etc.). --Dschwen (talk) 15:50, 27 February 2013 (UTC)

I already run a small bot run to remove duplicate location tags, removing exact duplicates in a string sense (~700 were found). There are still plenty cases where we have the same location specified by both {{Location}} and {{Location dec}}. Those will be harder, but a little smarter bot can remove locations which are the same up to displayed accuracy (1/100 of a second or less than 0.5 meter), or within 1, 5, 10 meters? The heading issues might be easier to handle once database updates the category, what might take a while since the change must have happened in {{#coordinates:}}. May be I will touch each file. --Jarekt (talk) 15:11, 26 February 2013 (UTC)

I do have the parser code to compare existing location templates in my GPSExif bot code. --Dschwen (talk) 15:13, 26 February 2013 (UTC)

A log of malformed coordinates is also at https://toolserver.org/~dispenser/view/File_viewer#log:coord-commonswiki.log --  Docu  at 20:13, 26 February 2013 (UTC)

Thanks, a 3rd system for catching malformed coordinate tags. Hopefully if we menage to clear the Category:Pages with malformed coordinate tags than that log will be clear as well. --Jarekt (talk) 00:57, 27 February 2013 (UTC)

I removed some more location templates that had 2 identical locations within a meter, and "touched" all the other files, so now we are down to 1700 files. Most of those are still 2 location templates and templates with numbers out of range. I will calculate distances between locations in files with 2 templates and remove some more. Also I noticed that error checking code that put files in Category:Media with erroneous locations is quite broken. Will probably have to fix it and point to Category:Pages with malformed coordinate tags of remove it since it is mostly redundant with {{#coordinates}}. --Jarekt (talk) 20:02, 28 February 2013 (UTC)

I'm for removing as much as possible. It'll make the template lighter. --Dschwen (talk) 21:24, 28 February 2013 (UTC)

776 files in Category:Pages with malformed coordinate tags

I cleaned up some more and all that is left are

1. 293 files with two camera locations templates more than 10 meters apart
2. 213 files with seconds or minutes equal 60
   • many of those were created by user:DschwenBot based on EXIF data, like this file
   • may be for those files we can re-run the bot again? Or we can figure out what they should have been and changed them.
3. 273 files with seconds or minutes bigger than 60
   • By the way, template itself does not care about the range of numbers, but those likely indicate corrupted coordinates.

Any ideas of how to clean those up? --Jarekt (talk) 02:05, 3 March 2013 (UTC)

Jarekt, I'm about to go on travel, but may have some intermittent access. I can certainly rerun the bot for files in that category. I'll check if the EXIF data or the bot was broken. Might take me a few days though. --Dschwen (talk) 03:55, 3 March 2013 (UTC)

No hurry, we will get there eventually. --Jarekt (talk) 14:05, 3 March 2013 (UTC)

Looking at only one image I find this (user meant to insert object location but used the wrong template). --Dschwen (talk) 18:08, 12 March 2013 (UTC)

File:No 6 Lombard Street, London.jpg

Hello,

Today I have added

{{Location|51|30|46.07|N|0|5|17.93|W|region:GB}}

to the above file.

It appears to be displaying in the summary as

51° 30′ 46.7″ N, 0° 5′ 17.93″ W

rather than

51° 30′ 46.07″ N, 0° 5′ 17.93″ W

i.e. there is a zero missing from the 46.07 parameter.

I would never normally notice this, as I usually use the "geohack" links provided by toolserver. But as that system seems to be momentarily unresponsive, I have today been double-checking co-ordinates by directly copying and pasting them from the file summary in to google maps. The result was that the location appears a few meters away from the intended position.

Thank you for any possible help, Rept0n1x (talk) 14:21, 13 April 2013 (UTC)

Additionally, just to say that it seems to be a generally occurring issue. I've since noticed the missing zero on three further files. It seems that if the fractional part of the latitude minutes is in the range .01 to .09 inclusive, then the zero is omitted. I'm not sure but I think the problem only occurs on the latitude component, as I haven't yet seen this occur on the longitude. Not a problem for me as I now instantly recognise this i.e. if the fractional part of the latitude minutes displays only one digit after the decimal place, then I can now workaround by manually inserting the missing zero digit between the decimal point and the following digit, before I use the co-ordinates. Regards, Rept0n1x (talk) 19:34, 15 April 2013 (UTC)

Camera location	51° 31′ 48″ N, 0° 33′ 00″ E	View all coordinates using: OpenStreetMap

Try it in decimal above?--Canoe1967 (talk) 19:48, 15 April 2013 (UTC)

Camera location	51° 30′ 46.07″ N, 0° 05′ 17.93″ W	View all coordinates using: OpenStreetMap

Should be fixed now see above. Thanks for reporting this, we had this bug for quite a few years. --Jarekt (talk) 20:08, 15 April 2013 (UTC)

Thanks both for the quick response. Thank you to Jarekt for fixing the problem. I can confirm it is fixed for the above file now. I removed the geodata and then re-added it in order to force a refresh of the file, and it's now appearing correctly in my browser. So that is indeed all fine now. Thanks also to Canoe1967 for the tip, yes if the problem had persisted I probably would have changed over to using decimal notation as you mentioned. Best Regards Rept0n1x (talk) 07:14, 16 April 2013 (UTC)

Decimals are an error?

See also COM:AN#Broken location template

I've just noticed that many of my uploads are in Category:Pages with malformed coordinate tags; for some examples, see File:First Christian Church, Charleroi.jpg, File:Abandoned buildings in Phoenix Hill.jpg, File:Cemetery at the site of Petersburg, Ohio.jpg, and File:Cemetery at St. Valbert's.jpg. I've looked at numerous images that are in this category, and all of them have decimals in the coords; what's more, if I remove the decimal point and everything after it (e.g. {{Location|40|14|26.7|N|84|27|50.4|W}} becomes {{Location|40|14|26|N|84|27|50|W}}), the error disappears. Why are we marking description pages as errors because of their increased precision? Meanwhile, when did this start? I've uploaded so many pictures that I don't often look at old uploads like these ones, so I have no clue whether this would be an old problem or a new one. Nyttend (talk) 02:29, 2 May 2013 (UTC)

You are right that is not right, and I have never seen this problem before while cleaning Category:Pages with malformed coordinate tags. You should not remove decimals from the coordinates. --Jarekt (talk) 02:53, 2 May 2013 (UTC)

I undid the last edit as it seemed to be a problem with {{Object location}} (every time a page transcluding it was edited it would show this error). Unfortunately the error is now showing up as the template is rerendered, dumping ~80000 images into Category:Pages with malformed coordinate tags. So it appears not to be the template; it seems to be a problem with the {{#coordinates:}} parser function: User:Moogsi/Invalid latitude –⁠moogsi (blah) 07:28, 2 May 2013 (UTC)

Fixed - it was an bug in the GeoData extension –⁠moogsi (blah) 10:14, 2 May 2013 (UTC)

Phraseology

The wording "This and other images at their locations on..." (from Template:Location/en) seems a little awkward to me. I'd propose something like "View the locations of this and other nearby images on...". Any thoughts?  An optimist on the run! 12:13, 7 May 2013 (UTC)

I prefer fewer words. May be "View this and other nearby images on..."? --Jarekt (talk) 14:09, 7 May 2013 (UTC)

The shorter the better. --Dschwen (talk) 14:54, 8 May 2013 (UTC)

I've put in an edit request for Jarekt's suggestion.  An optimist on the run! 06:30, 9 May 2013 (UTC)

 Done} --Dschwen (talk) 20:23, 9 May 2013 (UTC)

location template for Google maps

Is there a template location with respect to Google Maps? GM uses a different format (dd° mm.mm) by giving decimal values of the minutes. Some users use these values in Template:Location or template:Location dec, resulting in an error (see here). Should we consider an own Template fot users using Google Maps format? -- Wo st 01 (talk / cont) 11:01, 11 May 2013 (UTC)

Google Maps uses standard decimal notation as expected by {{Location dec}}.[1] The malformed notation on File:0x-kgl-saechs-altenb-1.jpg was added by DschwenBot. —LX (talk, contribs) 12:44, 11 May 2013 (UTC)

Hmm, yeah, in 2009. But the bot would probably do it again. This is how the data was encoded in the EXIF, and strictly speaking it is not really malformed. It points to the correct location. It is just the #coordinate extension (deployed a few months ago) that seems to be pissy about this particular format. Looks like I'll have to amend the bot to clean up the coordinate data even more. --Dschwen (talk) 15:27, 11 May 2013 (UTC)

I use http://www.wikimapia.org/ to get geodata if that is any help.--Canoe1967 (talk) 20:51, 11 May 2013 (UTC)

Altitude

How to insert the parameter for camera altitude in location formula? --CTHOE (talk) 11:46, 12 May 2013 (UTC)

With alt, like this:

{{Location|50|33.72592|0|N|10|44.27657|0|E|alt:440.8_source:exif_heading:SW}}

for example. With the altitude given im meters. --Dschwen (talk) 21:15, 13 May 2013 (UTC)

Is that altitude above local ground, or above sea level? Powers (talk) 15:19, 14 May 2013 (UTC)

My bot normalizes this to sealevel if an AlittudeRef field is found, otherwise sealevel is assumed implicitly (which sea? I don't know. Altitude references are pretty subtle. Google for Switzerland sealevel reference, they use both the North Sea and teh Mediterranean, which are 10cm different if I recall correctly :-) ). --Dschwen (talk) 16:31, 14 May 2013 (UTC)

My GPS-receiver says:"Höhe über Normal-Null". --CTHOE (talk) 10:48, 16 May 2013 (UTC)

Look this error: File:Wegweiser-1-CTH.JPG and tell me, what's wrong. What will say the "SW" at the end of the location expression? --CTHOE (talk) 10:55, 16 May 2013 (UTC)

heading:SW means that the camera was facing in south-west direction (please verify that this is true. I assume you just copied it from above). --Dschwen (talk) 14:54, 17 May 2013 (UTC)

Yes, now I changed it in NE. --CTHOE (talk) 11:53, 23 May 2013 (UTC)

Display the heading

{{Editprotected}}

The template should display also the heading (in the original form of the attribute, maybe also its conversion to degree azimuth and compass rose symbol). --ŠJů (talk) 20:03, 6 October 2013 (UTC)

Yes that would be nice so we can see which files have heading and which do not without looking at the code. We can use or . Any opinions on which one is better. I am more inclined to use the simpler one since it is more clear when small. --Jarekt (talk) 03:15, 7 October 2013 (UTC)

I would say if someone could make an svg version. --Zolo (talk) 06:38, 7 October 2013 (UTC)

What about to unify the symbols with the used at GoogleMaps linked through this location template? (Rotated logo of Commons.) It seems to have 33 (or 37?) variants (the filenames are 0.png to 32.png (36.png?), 0.png is a round symbol for images without heading. --ŠJů (talk) 12:25, 7 October 2013 (UTC)

Are those on commons? I don't think that is a great idea. The meaning of the symbol may be clear on the map, where it makes sense to indicate the "commons" context. That context does not need to be reiterated on the site. We rather should make absolutely sure that the meaning of "direction" is absolutely clear by using a symbol language that everybody understands. And that would be a compass. --Dschwen (talk) 12:57, 7 October 2013 (UTC)

The , , and icons are a dangerous choice. It would not indicate the heading, but it would show the direction of "north". This would need a convention as to where the heading points (always up?). This actually indicates the inverse of what I think is intuitive. I'd rather work with the assumption that north is top and have the arrow indicate the heading directly. The last icon also has poor readability at small sizes. --Dschwen (talk) 13:02, 7 October 2013 (UTC)

Daniel, check {{Compass rose file}}. I think it has the heading vs. direction of "north" resolved correctly. --Jarekt (talk) 15:00, 7 October 2013 (UTC)

Yeah, with the static parameter, but that image set also scales very badly. --Dschwen (talk) 17:26, 7 October 2013 (UTC)

The "rose" image set () does scale badly. The "north" image set () looks better but we have fewer angles and half of the time the "N" looks like "Z", which can be confusing. converted to SVG and rotated 32 times might be our best bet, but before we start asking if anybody would be willing to do the labor of creating those we should make sure we will use it. --Jarekt (talk) 17:49, 7 October 2013 (UTC)

SVG version , I hope it looks fine. We can also use CSS3 transform instead that will support <= IE9 and other modern browsers that plus display: inline-block; will become: ... −ebraminio^talk 09:27, 7 November 2013 (UTC)

 Done Implemented. But in every translation azimuth parameter should be passed to layout [2] −ebraminio^talk 12:49, 7 November 2013 (UTC)

ebraminio, I do not know about adding new input parameters to the template without prior discussion. We already have a way to add a heading to the image that is being used on few millions of files. I do not think it is feasible to change them all, so we should work with our current input parameters. --Jarekt (talk) 13:10, 7 November 2013 (UTC)

Seems I misunderstood the request. I reverted my edits. −ebraminio^talk 13:12, 7 November 2013 (UTC)

Thanks for creating File:North Pointer.svg, and I like the rotation of the figures approach. It does not fit well with our current {{Compass rose file}} approach but may be it should replace it, since it seems like a better way. May be we should write a new template for rotating images, which can be than tested for various browsers, to make sure we know the compatibility limitations. As for getting "azimuth" or "heading" for each file that is now part of parameter #9 ("attributes") of Template:Location (and equivalent for other 4-5 coordinate templates). As far as I see it we have 2 options:

1. Write LUA module for parsing "attributes" parameter and call it from Template:Location/layout to get the heading
2. Use approach ebraminio started implementing of adding a new parameter to the template and convert existing files.

The option 2 is what I would do if I was writing a new template, since it is more clean simple approach, but I do not like making such big changes to so widely used templates. Since they would impact a lot of other tools and processes which were designed to work with out {{Location}} templates and it would require large number of changes to existing files. Any other options? --Jarekt (talk) 14:14, 7 November 2013 (UTC)

@Jarekt: Okay. I made Module:ParseLocationAttributes, {{#invoke:ParseLocationAttributes|main|heading:asdasd_azimuth:123|azimuth}}. Is its format OK? Anyway I hope be useful. −ebraminio^talk 14:47, 7 November 2013 (UTC)

Ebraminio, I just synched {{Location/layout/sandbox}} with {{Location/layout}} so feel free to change {{Location/layout/sandbox}} anyway you want and see the results with calls like

{{Location/layout/sandbox
| lat             = 70
| lon             = 70
| attributes      = heading:NW_elevation:1000_type:landmark_globe:earth_region:US-AK_scale:150000_source:gnis
| NoError         = 1
| mode            = 1
| globe           = Earth
| Location-label1 = Camera location
| Location-label2 = Object location
| Location-label3 = Location on Earth
| Link-label      = View this and other nearby images on:
| GoogleMaps      = Google Maps
| GoogleEarth     = Google Earth
| OpenStreetMap   = OpenStreetMap
| Info-label      = Info
| lang            = en
}}

The "azimuth" you use is the same as "heading" (unless I am confused somehow), so we do not need both. Heading can be specified as a number 0-360 or as compass point abbreviation as defined in w:Boxing the compass. If you (or anybody else) come up with a good prototype which can be tested and agreed on by the community than you will be more than welcomed to roll it out by replacing {{Location/layout}}. I do not think other templates would have to be changed. --Jarekt (talk) 17:47, 7 November 2013 (UTC)

@User:Jarekt. I didn't know... okay, implemented. −ebraminio^talk 19:56, 7 November 2013 (UTC)

Ebraminio, I modified the template a bit: mostly added MOD 360 function and used 360-heading formula so that if image heading is NW then the north is NE from UP pointing vector. I tried several inputs to Template:Location/layout/north at User:Jarekt/e and it all looks fine. Does anybody else have an opinion on this task? Is the new proposed template graphically OK? I am not 100% sure if I like the placement of the and may be it should be smaller. --Jarekt (talk) 14:04, 8 November 2013 (UTC)

@Jarekt. I agree with any change you want to do (making pointer smaller or moving it...). IMO you should go ahead and implement it. We can discuss about other needed changes also after the change. −ebraminio^talk 13:43, 13 November 2013 (UTC)

 Done I renamed the module to Module:Coordinates and added good chunk of Template:Location/layout/north to the module. This way I did not need Template:Location/layout/north since it's content fit nicely in Template:Location/layout. Ebraminio, thanks for all your work on this, I learned a lot of new tricks. --Jarekt (talk) 14:19, 14 November 2013 (UTC)

Great! −ebraminio^talk 14:30, 14 November 2013 (UTC)

I just noticed the pointer the other day but didn't understand it because it was pointing incorrectly. File:Greyshot arch W62 east CP cloudy jeh.jpg for example is a picture I snapped looking west, but I see the arrow pointing to the right, which presumably is meant to be east. Jim.henderson (talk) 08:25, 17 November 2013 (UTC)

Oh. After some thought, I understand. The arrow is intended, just as its label says, to point north rather than the way the camera is pointed. Same as in Google Street View. It's obvious once I get my head into it. I hope it's just me being dense; otherwise many readers will be similarly confused. Jim.henderson (talk) 08:56, 17 November 2013 (UTC)

Yes it is tricky, especially for people who add the {{Location}} templates, since we have to figure out the heading by imagining north pointing up. I feel like with "old woman/young woman optical illusion", once you see it one way it is hard to see it the other way. --Jarekt (talk) 04:05, 18 November 2013 (UTC)

Were this a consumer product, we would want to devise tests for responses of naive users to this question and others, such as, do the white leaf and black leaf of the arrowhead look like two pointers rather than one? However, Commons is a back office to Wikipedia, and geography is a particular specialty, so we can expect our fellow specialists to study and understand. Jim.henderson (talk) 13:30, 19 November 2013 (UTC)

Remove link to icon svg

{{Editprotected}} Because the North Pointer is an UI element, it should not generate a wiki link or an alt string. In {{Location/layout}}, please replace

[[File:North Pointer.svg|20px]]

with

[[File:North Pointer.svg|20px|link=|alt=]]

to produce

Thanks! — hike395 (talk) 04:24, 27 November 2013 (UTC)

 Done thanks --Jarekt (talk) 13:46, 27 November 2013 (UTC)

Error

Just seen: On many pages an error Invalid arguments have been passed to the {{#coordinates:}} function occurs. --XRay ^talk 14:45, 7 December 2013 (UTC)

An example File:Dülmen, Wegkreuz (Coesfelder Straße) -- 2012 -- 3.jpg --XRay ^talk 14:48, 7 December 2013 (UTC)

Fixed I just turn off adding {{#coordinates}} for {{Object location}} in the file namespace. That should fix the issues we were having. Should those tags be added at some point? If so we should figure out why the current version was throwing errors. Is some pages still have an error than press "Purge" button to clear them --Jarekt (talk) 18:59, 7 December 2013 (UTC)

purge does not help, a nulledit does help. But there are still ~ 100.000 images involved. So maybe somebody central could do this. As there are some real errors. regards --Herzi Pinki (talk) 10:36, 9 December 2013 (UTC)

Template:Object location dec not displaying "nearby" icon on categories

Some seem to start using Template:Inline coordinates instead .. Would it be possible to fix the object location template instead. --  Docu  at 07:40, 3 December 2013 (UTC)

What is "nearby" icon on categories. I do not think I ever noticed "nearby" icon or it's lack. --Jarekt (talk) 13:16, 3 December 2013 (UTC)

You need to activate the feature on Special:Preferences#mw-prefsection-betafeatures. --  Docu  at 18:10, 3 December 2013 (UTC)

Why do we even still have {{Inline coordinates}}? I thought this (and {{Coord}} was deprecated a long tiome ago in favour of the box templates {{Location}} etc. --Dschwen (talk) 18:24, 3 December 2013 (UTC)

{{Inline coordinates}} suppose to serve different purpose, see for example File:Ordnance Survey Drawings - Dartmoor, Devon (OSD 22).jpg. However it is hard to say how often it is misused instead of using {{Location}}. But we have ~50k of them and it is not feasible to check them all. --Jarekt (talk) 18:48, 3 December 2013 (UTC)

Probably all uses in category namespace: list --  Docu  at 18:56, 3 December 2013 (UTC)

The problem with inline coordinates is the lack of semantic context information. It is impossible to extract the meaning of the coordinate data without reading the surrounding text. I imagine most occurrences in category namespace would be better served with {{Object location}}. But this digresses. The only reason I can see for the coords not showing up in the nearby search is a missing coordinates parser function in the template. Jarekt, I thought you added this to all coord templates? Can you confirm? --Dschwen (talk) 19:46, 3 December 2013 (UTC)

I do not remember much about it, but it seems like I only added it to {{Location dec}} and {{Location}}. I do not think we ever finished rolling it out for {{Object location dec}} and {{Object location}} templates, although it was already added to {{Object location}}. So Docu is correct, only {{Object location dec}} is missing it. {{Location dec}} and {{Location}} templates add "type:camera_" to the attribute list, what should we add to {{Object location dec}} and {{Object location}} templates. --Jarekt (talk) 21:11, 3 December 2013 (UTC)

Nothing. Those template currently add class:object_ to the attribute list. This is not ideal, but I believe several extraction tools are already using this syntax so it is probably best not to change and potentially break anything. --Dschwen (talk) 21:47, 3 December 2013 (UTC)

 Done I added class:object_ to the attribute list. I also did a big change of redirecting {{Object location dec}} to {{Object location}}, since the second one was always able to take either 3 or 9 parameters and there is really no need for 2 almost identical templates. If there are no negative effects, we should do the same with {{Location dec}} and {{Location}}. --Jarekt (talk) 03:05, 4 December 2013 (UTC)

There is still no "nearby" icon on, e.g., Category:Equestrian statue of Willem II (The Hague). --  Docu  at 07:01, 5 December 2013 (UTC)

User:Herzi Pinki pointed out a problem we have now with multiple {{#coordinates}} added by both {{Location}} and {{Object location}} templates. See for example File:Murau_Friesacher_Tor_2_2012-08-11.jpg which have both templates, each adding {{#coordinates}}. This causes {{#coordinates}} to throw "cannot have more than one primary tag per page" error message and be added to Category:Pages with malformed coordinate tags. Shall we tag all the {{#coordinates}} added to files by {{Object location}} templates as secondary? --Jarekt (talk) 12:45, 6 December 2013 (UTC)

For filenamespace yes, for categorynamespace no. --  Docu  at 19:49, 6 December 2013 (UTC)

good suggestion.-Dschwen (talk) 20:08, 6 December 2013 (UTC)

 Done, but unfortunately I get Errors for File:Murau_Friesacher_Tor_2_2012-08-11.jpg. Any ideas why?--Jarekt (talk) 04:34, 7 December 2013 (UTC)

There must be some subtle difference between File:Kysice KL CZ Muk Na kocourku Sorbus aria 100.jpg and File:Kysice KL CZ Lipa v Kysicich Tilia cordata 030.jpg - the first file is without any error message while the second file, whose description is C&P taken from the first one, shows the error. Maybe the cause is in differing digits in seconds. This is the only explanation I can offer, but maybe I'm completely wrong being unfamiliar with internal functionnig of the templata. --Miaow Miaow (talk) 14:06, 7 December 2013 (UTC)

And what more: When part of the description from the second file is further C&P used in Category:Lípa v Kyšicích, then the same second coordinates work fine. Maybe also the namespace is somewhat involved... --Miaow Miaow (talk) 14:14, 7 December 2013 (UTC)

I've the same problem. The error occurs after editing the page - without changing.--XRay ^talk 15:03, 7 December 2013 (UTC)

Here is a sample where the icon appears Category:Monument to the Tsar Liberator. Unfortunately, using the wrong template. --  Docu  at 05:29, 10 December 2013 (UTC)

I see it (first time) and it is quite cool. I never fully understood what {{Inline coordinates}} does: it takes simple task of displaying coordinates and makes it into a complicated 5 subtemplate mess, in other words the output of the template does not seem to justify it's complexity. I looked and looked and I do not see it calling {{#coordinates}} anywhere, so I have no idea how it is communicating with Nearby Pages. May be the lack of icon issue is something to report at mw:Talk:Beta Features/Nearby Pages. --Jarekt (talk) 15:21, 10 December 2013 (UTC)

It works now. --  Docu  at 15:04, 14 December 2013 (UTC)

It would be nice if categories would listed on "nearby" results as well. Currently just images appear. --  Docu  at 14:12, 15 December 2013 (UTC)

how to enter decimal coordinates?

I have coordinates in decimal notation. I found {object location dec}, that redirects to {object location}. But {object location} does not describe how to enter decimal values. My case is File:Placa Carrero Blanco.jpg. -DePiep (talk) 10:00, 19 December 2013 (UTC)

The documentation is at Template:Object_location#Alternative_Syntax --Jarekt (talk) 13:05, 19 December 2013 (UTC)

mw:Talk:Beta_Features/Nearby_Pages#Nearby_pages_on_Commons:_categories_not_listed

Please see the above. --  Docu  at 08:46, 21 December 2013 (UTC)

Add empty Template:Object location to categories ?

Shall we add empty templates to all categories for locations? The template could be modified to draw coordinates from Wikidata when or once available. --  Docu  at 08:57, 21 December 2013 (UTC)

I do not think we need to do it preemptively. Once the capability exists than lets worry about it. --Jarekt (talk) 04:00, 22 December 2013 (UTC)

Well it does.

We just need to find categories that have (1) a Wikidata item, (2) a Commmons interwiki link defined and (3) Wikidata:Property:P625.

Seems that Wikidata is somewhat stuck with adding (2). --  Docu  at 12:46, 29 December 2013 (UTC)