Commons talk:Geocoding/Archive 3

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Upload script for photographs

Hi all,

I have written a Perl script, Nichalp's upload script, that you can use to batch upload your photographs to Wikimedia Commons. The script has a lot of functions including:

  1. adding infoboxes, categories, and geoboxes;
  2. embedding your name, caption, and GPS data as Exif data;
  3. autorotation of images to correct the orientation;
  4. renaming images on-the-fly; and
  5. rigorous checking to ensure that categories, licences and descriptions are added.

Do have a go at testing it. Regards, Nichalp (talk) 07:03, 8 September 2008 (UTC)

Geolocations on a pizza ?

User:Thisisbossi puts a location template on each and every one of his pictures, including a pizza and a hamburger, which seems not only useless to me, but also quote annoying for people who browse Google Maps/Earth (like I did, that's how I found them). Removing the template is no use, he just puts it back again (and again). We had a discussion like this before, about this picture of some water (see it's talk page). After someone wrote "It is a picture taken outside, so that a meaningful location can be given." I let it go, but this time I can't, this seems too rediculous... What do you think ? - Erik Baas (talk) 21:10, 14 September 2008 (UTC)

Erik: I've used the geolocation tag a lot, and am fairly liberal in its application, but I do agree that it's not necessarily helpful or appropriate for all photos. The geolocation tag exists to help users identify the geographic location/position/viewpoint of a photo, information that's generally not pertinent when the subject is non-geographic or when it's not really specific to any particular location. (e.g.: I could photograph my fingernail for the article on the subject, but I can't imagine how any user would possibly be served by me indicating my nail's exact location when I photographed it.)
The statement suggesting that just because something is outdoors, that makes tagging meaningful, also seems a bit shaky. I've tagged indoor photos before when it seemed appropriate (inside arenas, museums or other important structures) and have also sometimes skipped tagging certain shots taken outdoors when they showed nothing location-specific (certain closeups). I also tend to disagree that geocoding is justified just because an image survives a deletion request — the merit of an image seems unrelated to the question of its relationship to a geographic place.
IMO, the decision should be made on a case-by-case basis, and should depend on the answer to the admittedly subjective question, "would tagging this image add value for other users?" If so, tag it; if not, it's probably best not to. Huwmanbeing  22:49, 14 September 2008 (UTC)
I agree that this issues needs further discussion and I thank Erik Bass for taking the initiative to raise it here. My opinion is that any sort of unique object that is specific to a particular location should indeed be geotagged. To take on the previous example: my fingernail is pretty much the same no matter where it is. However, culinary items (in my opinion) are certainly unique to a particular place, unless it's a generic chain items like a Domino's Pizza that could be purchased anywhere. Photos of water and silt may not be the most interesting, but my mindset was that this water and silt is certainly unique as compared to another river's color & composition. I also geocode all my photos of flora. My general viewpoint is that someone touring about on Google Earth may not only be interested in photos of landscapes and city streets, but some may also be interested in culinary creations, flora, fauna, etc. Basically my opinion comes down to a general disagreement that geocoding be limited to structures and geography. --Bossi (talkgallerycontrib) 02:15, 15 September 2008 (UTC)
How about a rough thumbrule: Geotag anything that is unique to the location. A building, a geographical feature, a landmark. Avoid geotagging generic items such as pizzas, hamburgers and other such stuff. Nichalp (talk) 05:42, 15 September 2008 (UTC)
Nichalp: I agree with the first part: buildings, landmarks and other clearly geographical or unique subjects clearly should be geotagged. I think certain non-unique subjects such as flora may also qualify, though. When I photograph wildflowers, for instance, I sometimes geocode them, since some people may be interested to know where certain species grow, or want to see the flora of a particular geographic area or region.
I suppose a similar case could be made for photos of cuisine, though in the examples we're considering it would've been nice to see the setting. Including more of the restaurant, people, etc. in the shot (even if just in the background) would make a more compelling case that the photo's definitely specific to a certain place. Huwmanbeing  10:39, 15 September 2008 (UTC)
Yes, flora is a valid addition. Thanks for brining it up. But I'm not too sure about cuisine. I don't expect cuisine or restaurants to be as localised to add a geotag. I mean, if w:momo (food) are specific to Tibet, how will precise geotagging help? Nichalp (talk) 15:17, 15 September 2008 (UTC)
True. I'd agree that photos showing just food shouldn't be tagged unless there's some very particular reason for doing so. Huwmanbeing  16:11, 16 September 2008 (UTC)
Thanks all for your input and a quite interesting discussion. I'll remove the location templates from the pizza and the hamburger. - Erik Baas (talk) 22:47, 20 September 2008 (UTC)
It no longer sounds like a consensus has been reached; and why not comment them out rather than replace, in case future technology can sort geocoded media? --Bossi (talkgallerycontrib) 02:39, 21 September 2008 (UTC)
Would it be possible for the user to select categories of interest when viewing Google Maps/Earth? That way, someone interested in flora or food would see icons for only pictures in the corresponding category. Walter Siegmund (talk) 04:08, 15 September 2008 (UTC)
It may be possible in the future if Google reads Exif data. I embed categories and keywords into the Exif data of my photos before uploading. My script above can do that. Nichalp (talk) 05:41, 15 September 2008 (UTC)
It sounds like the general consensus is against geotagging cuisine. I recommend, then, that any geotags be commented out rather than removed outright. Anyone (dis)agree? --Bossi (talkgallerycontrib) 00:00, 17 September 2008 (UTC)
I don't see how that helps. But if you insist on having geotags, I'd suggest you leave it as plaintext in the description field of the information template. Nichalp (talk) 14:10, 21 September 2008 (UTC)
I support geotagging cuisine! Someone may deduce extra information about it. One could similarly argue, say, for the willful omission of the specific registration number of an airliner in a photo of a Boeing 737. Except then the precise photo cannot be retrieved in case this specific airliner crashes and could well be illustrated. You just never know. --Specious (talk) 03:35, 17 September 2008 (UTC)
In the case of aircraft, one could reasonably expect people to use the registration number to identify the model being shown. In the case of cuisine, people are less likely to use latitude and longitude to identify a particular piece of pizza. Huwmanbeing  01:33, 18 September 2008 (UTC)
To be clear, I wasn't referring to the "737-500", which identifies the model, but to the "VP-BKO", which identifies this particular vehicle, and does not indicate the model. --Specious (talk) 18:56, 18 September 2008 (UTC)
This is a wonderful idea! My views are rather liberal when it comes to geocoding, as I firmly believe that the greatest portion of the value inherent in Wikimedia projects is yet to be discovered. We don't know what the greatest uses of our information will be. While it's true that in the meantime we are cluttering up the Google Earth layer with images loosely related to their geographical coordinates, in the future we may be able to alleviate this with better sorting. I would be in strong favour of an effort to create multiple types of geocode. In general, I believe we should concentrate on adequately categorising our collectively contributed information rather than deleting the "extra". --Specious (talk) 03:29, 17 September 2008 (UTC)
Could an additional parameter be provided to ID the type of media being geocoded? For example: geography, structure, flora, fauna, cuisine, sky, subterranean, etc...? Perhaps it might be easier to convert these into Google Earth rather than waiting to be able to read EXIF data. --Bossi (talkgallerycontrib) 03:44, 17 September 2008 (UTC)
I think that would be redundant information. And I hate, hate, hate, ++tripple-hate redundant information (tough lessons from my professional life)! Rather we should use the information, which is already there in the categories of the image page. If it is a "flora image" it will be in the flora category tree. A future improvement would be to let the tool which extract the geodata also make its own super-categorization of an image based on analysing which category trees the image belongs to. This should be used to allow the user of Commons layers to filter for the type of media the user is interested in. A quite challeging task, I know, but possible. The information is there. It is "just" a matter of extracting it.
Fully agree: redundancy is evil. More (unclear) rules and requirements on commons users are even more evil. And if they are able to extract the geo data from commons, extracting a number of root categories should be relatively easy and make them autonomous in organising their classification system. --Foroa (talk) 08:05, 17 September 2008 (UTC)
I agree that we should more try to prepare and filter data when it's viewed, rather than control its entry in this environment that anyone can edit, or sometimes, poison. A tag system would be nice, but since it's so hard to get users to categorise their images to begin with, it shouldn't be done while we're still using categories. So some other solution would be needed...
This was discussed at Commons talk:Geocoding/Archive 1#GeoCommons categorizing among others, and the semantic drift problem is still as strong as ever. This fine image of an airliner is sensibly categorised, but when we follow the parent categories, it actually belongs to such categories as animals, art, buildings, history, maps, models, paper, people, symbols, tools and war (see results of a long query for more). A solution I remember mentioning somewhere might be to define in each category the scope of its parent categories and the type of relationship it has to them, which the tools related to geocoding or any other Commons use could then read and display the requested information with improved semantics. It's as immense as any other solution I can think of, but it would be serving more than just one purpose. --Para (talk) 12:51, 17 September 2008 (UTC)
Sigh, just another example of how broken our category system is (see mailinglist). It is just beyond my comprehension why we aren't just using categories as tags. This would be so much more useful and would make life so much easier for tool developers. --Dschwen (talk) 14:25, 18 September 2008 (UTC)

Geocoding images created with WorldWind

Clearwater Lakes

Does it make any sense to geocode images created with NASA's World Wind software (or with Google Earth)? If it's a simple satellite image with the camera looking straight down, I guess the coordinates of the object can be used as camera location. However, the question about camera location for synthetical images which show a oblique view of Earth's surface (like the image shown at right) is difficult to answer. So I would welcome any comments on that matter. --Vesta (talk) 11:47, 17 September 2008 (UTC)

Terminology

Geocoding generally refers to converting a textual address to a latitude longitude (and reverse geocoding is converting a lat/lon to a street address). Check the first 30 hits on any web search or look at dictionaries on google book search to confirm this usage; it's very well established.

The concept discussed on this page is associating a lat/lon with a piece of media, which is more properly called geotagging. Let's not mess up this distinction by misusing the terms; it's the equivalent of an encyclopedia using "web server" as their idiosyncratic term for what most of the world calls a "web page", two distinct concepts with well established meanings.

(Of course, geocoding is one way of coming up with a lat/lon to be used for geotagging, along with GPS and map click methods - but the concepts are distinct). — Preceding unsigned comment added by 74.85.19.241 (talk • contribs) 02:45, 18 September 2008 (UTC)

Quoting from en:Geocoding: Media can also be geocoded, for example where a picture was taken. --Dschwen (talk) 03:00, 18 September 2008 (UTC)
And see en:Geocoded photograph. --Dschwen (talk) 03:04, 18 September 2008 (UTC)

Can anyone explain this

Click on Google Maps in the region of Image:Hôtel de la Communauté urbaine de Dunkerque Grand littoral.JPG ( 51°2′9.783157350948386″N, 2°22′18.951873779296875″E) and this image appears in the left panel Image:Medieval crane - Brugge.jpg. Zoom right in, and move from Dunkerque so there is no marker icon on the map, but the said image remains in the left panel. (Firefox 3.0 XP-SP2) but not on (Firefox 2.0 Linux on AsusEEEPC)? ClemRutter (talk) 21:44, 21 September 2008 (UTC)

Geocoding userpages for a purpose

copied from the Village pump

It would be a piece of cake with the given infrastructure to write a little bot, that correlates geocoded photography requests with the names of users which geocoded their userpages (and deploy automatic messages). This would make geocoding userpages on commons useful! It would also be possible to query wikipedias which provide photo wanted templates and geocode their articles. This would have to be announced broadly, as to be remotely useful we'd need a large userbase with geocoded user pages.

And/or we could correlate requests with existing geocoded pictures and their uploaders. The location of existing pictures may either be close to the users' homebase or the user might have further pictures from that region which he hasn't uploaded yet. --Dschwen (talk) 00:47, 26 September 2008 (UTC)

Any comments? Should I pursue this further? Contact other Wikipedia Geocoding projects? --Dschwen (talk) 00:48, 26 September 2008 (UTC)
If it is easy- ~yes. Though, personally my images reflect the roads I have already travelled. Then again, a bed for the night, some good company and some good food I can be persuaded to go anywhere that Ryanair flies.ClemRutter (talk) 15:57, 26 September 2008 (UTC)

Yes, it is easy, this page could be linked from the site notice for a short while. It would need a FAQ and maybe some more text. --Dschwen (talk) 16:19, 30 September 2008 (UTC)

I don't want to get a mail that I should do something, i.e. photograph an ugly train station or so. But what I would like, that if I plan a little trip that I can get a map of where I can see where images are wanted. So we don't need geocode userpages, but they are also not wrong for other reasons. The other idea with the "wanted images"-template is very good. --Kolossos (talk) 13:58, 1 October 2008 (UTC)
Absolutely no mail! Less obstrusive, like a bot edited subpage in your userspace that you can transclude anywher eyou like and that keeps an up-to-date list of requests in your area. For trips you could generate such lists as well. How ever the majority of users are slowpokes ;-). If a system where the user has to take initiative to look for requests would work, then we wouldn't have any open requests anyways. You can already sift through the articles requiring images categories on Wikipedia. --Dschwen (talk) 14:39, 1 October 2008 (UTC)
A usage in my mind is also a site where I can see new images in my area. Thats would be interesting.
An own application that I use for more than a year is Wiki-article without an image. Perhaps I should make more advertisment for it. --Kolossos (talk) 17:54, 1 October 2008 (UTC)
We need to collaborate even more :-). You data set is not up to date. Forget about these fracking dumps. A little SQL query can get you all the data you need. The query will take a few minutes, but I guess its enough to run it once a day. --Dschwen (talk) 19:26, 1 October 2008 (UTC)

Roads

Is there an accepted good practise for adding a geolocation to road categories, should I add two tags for the two ends of a road,or choose a single point approximately in the middle. Thanks. KTo288 (talk) 09:56, 26 September 2008 (UTC)

Hm, I don't think we have any policy for geocoding categories yet. But for long roads either of you approaches woul be unsatisfactory (think of route 66, several 1000 miles). We had a proposal for line-like geocoding here some time ago Commons_talk:Geocoding/Archive_1#Polygons_rather_than_points.. --Dschwen (talk) 13:20, 26 September 2008 (UTC)
I also don't think that it is a good idea. With a GPS device and a syncronice software you can geocoding each image of the category. Or if the street is important enough then write a wikipedia article and some other people can create a map with the street. Kolossos (talk) 14:46, 26 September 2008 (UTC)
It essentially boils down to the question whether we should ever explicitly geocode categories, or have them geocoded implicitly by the point cloud of geocoded images in that category. --Dschwen (talk) 16:05, 26 September 2008 (UTC)
You're assuming that roads are in a straight line. Many are not, and a geolocation for the mid-point of such roads might be incorrect. Nichalp (talk) 15:30, 26 September 2008 (UTC)
Hmmm, I was thinking of roads on a much more modest scale than Route 66, a few miles at most, when creating categories for places and buildings I've been adding geotags, so was wanting to do the same for a road I categorised. KTo288 (talk) 10:15, 2 October 2008 (UTC)

Milestone

Promising turn!

Hey guys, we passed 100000 geocoded images a while ago. Current count is 102534. Congrats to everyone here! --Dschwen (talk) 13:15, 26 September 2008 (UTC)

Who was the lucky uploader? Nichalp (talk) 15:28, 26 September 2008 (UTC)
Line 100000 in my extracted coordinate data is Image:Catharijnebaan_UU.jpg (uploaded Sept 15th). I don' t know for sure if it sorts for uploading time or geocoding time (which in the case if this image were the same). So yay Victor van Werkhooven :-)! --Dschwen (talk) 16:04, 26 September 2008 (UTC)
Tell me when you approach the next milestone. I'll use my script to batch upload a whole series of new photos. :) Nichalp (talk) 16:23, 26 September 2008 (UTC)
Good thing you waited a couple of thousand past the milestone, so that all the inaccurates aren't fluffing up the count too much! I updated the graph too, and it looks like geocoding has become increasingly more popular during the last couple months. Yay! --Para (talk) 16:52, 1 October 2008 (UTC)
86% of our tagged images is lacking heading. What can we do about this? Writing a cool tool comes to my mind... --Dschwen (talk) 14:48, 3 October 2008 (UTC)
w:User:Teslaton/Tools/GeoLocator seems to be almost there, though people may think that tools with such a layout are a bit geeky. Still, the idea is there and it works great. All we need now is an easy way to add the resulting tag and having the tool work on a series of images. With this method we could perhaps get the coordinates of the main object as well, without really having to talk about headings at all. "Click on the main feature seen at the center of the image", with a vertical line drawn on a thumbnail of the image for guidance. --Para (talk) 13:43, 6 November 2008 (UTC)

Tagging a gallery. tagging a category

I have just been helping out User:Multichill/Category suggestions attempting to put at least one category on each image in a gallery using Template:Populate category. Thats why I have been looking at galleries of beautiful images of churches in Poland. I would be really useful to geolocate some of these categories- firstly to maintain my sanity, and secondly it would give a base location that could be used to tag all the images in these galleries at a later date.

  1. So can we reverse the policy of not geotagging categories?
  2. That done can we agree a tag that should be used for a category-object rather than the camera-object?
  3. What will it be?ClemRutter (talk) 16:26, 26 September 2008 (UTC)
Wouldn't that geolocation be pretty arbitrary? For Chruches in Poland would you just take the center of Poland? Is that useful at all? How would it help to to tag all the images in these galleries at a later date? As I said above, aren't categories implicitly geocoded by the geocoded images within them? --Dschwen (talk) 16:54, 26 September 2008 (UTC)
Theoretically, I agree with you totally- I am dead against using the Location dec tag. It must be totally different- maybe Catlocation and Gallerylocation. But I will put forward a few ideas.
Chruches in Poland- yes a nonsense, but if you are working on a bunch of images, using the Googlemap method. You find an image on another page to open Googlemaps, then troll across the continent until you home in on the village. Putting Catlocation on the category, means one less tab and a far shorter troll. Nonsense- but it could be useful. My European Geography is pretty good, but how about Chruches in Nicaragua or in my case Chruches in North Dakota, neither of which I can easily place.
To be honest, I wasn't thinking of top level categories. I was thinking of a category like Category:Mill Gate in Strzelce Krajeńskie- (wherever that may be). Neither of the images are geotagged and don't give enough information to help me start. The categories I have been working on, have images with no tags and often no textual information, but each of these images have been lovingly placed in a gallery and many are annotated there (often in Polish and English).
There are some editors who spend a lot of time making galleries. Many Gemeinde in Germany for instance have a complex gallery page- but few in England. I don't use them, but for their sake a Gallerylocation would add to their page. If galleries are used to display the very best images in a category-- these images will be examined for a geotag, and if this is missing than a Gallerylocation will be the starting point.
It doesn't replace image tagging- but maybe compliments it, elucidates rather than confuses. ClemRutter (talk) 20:02, 26 September 2008 (UTC)
You should be aware of en:Wikipedia Template:GeoGroupTemplate which, as mentioned in Wikipedia:WikiProject Geographical coordinates, shows all coordinates in an article or articles in a category. en:Category:Lighthouses in Michigan has in the upper right the GeoGroupTemplate box "Map of all coordinates" with a Google Maps link (click "[show]" for KML version). For your community activity interest, you should be aware this template also has uses such as in subcategories of Category:Wikipedia requested photographs in the United States. It doesn't work now in Commons, but consider the uses and technology. -- SEWilco (talk) 02:42, 4 October 2008 (UTC)

Hiccough with Google Maps

I have just spent the odd few minutes uploading some 100+ images centred around Image:ChathamAmherst6610.JPG. I used Google maps method two- as I did in Friday with this series Image:Sommières7346.JPG. So do I claim credit for taking out Google Maps? It appears to be refusing to display the new Commons icons- all through Saturday and Sunday. ClemRutter (talk) 20:05, 5 October 2008 (UTC)

The toolserver had some problems[1], and replication for Commons was interrupted. Looking at the weekly replication graph, it's slowly catching up. --Para (talk) 22:04, 5 October 2008 (UTC)
Here we go again, some more replication downtime. --Para (talk) 14:54, 13 October 2008 (UTC)

Sarajevo

Hi. I've been geocoding my images for some time and now I did a little test. As can be seen (for example in wikiminiatlas) Czech Republic is geocoded quite well, not many mistakes and lot of images, however smaller countries do have much worse coverage. I looked on Sarajevo in Google maps and it is really bad. I don't mean lack of pictures with coordinates, this can be resolved later. What interests me is fact, that the pictures are placed really wrong, about 500-2000 metres away from their current location. I know that mistakes do happen and I sometimes do a lot. However, such a condition is good to announce in order to focus on some places and solve the problems. Well it is nice to put a graph how a quantity of geocoded images grows, but however with useless coordinates it loses its meaning. Thanks. --Aktron (talk) 18:19, 8 October 2008 (UTC)

Show wikicommons photos layer on wikimapia

Hi, recently wikimapia beta added panoramio photos layer on wikimapia as we can see on map type menu here: http://www.wikimapia.org/beta/#lat=-16.3569461&lon=-46.8994439&z=6&l=9&m=p&v=1 I think will be great if wikimapia add wikicommons photos layer too. So I created a topic about it, look: http://www.wikimapia.org/forum/?t=3134 If someone here is interested in see this option on wikimapia, post there. Thanks.

Great idea, Vlunal! I've been a contributor to both projects for some time now, so I personally would like to see the hundreds of pictures that I geocoded on the Wikimedia Commons to show up on WikiMapia. Unfortunately, WikiMapia is not an open-source project, so it's up to the developers whether they decide to do this. I sure hope they do! --Specious (talk) 05:11, 4 November 2008 (UTC)

How are the "Headings" Useful?

In the Location Template is also a Heading request... but how is ist used? The Template doesnt provide this Information? wbr --Stefan-Xp (talk) 17:47, 16 November 2008 (UTC)

Commons:Geocoding#Parameters should help you. And yes, I believe this parameter is very usefull in map-applications. --Kolossos (talk) 18:12, 16 November 2008 (UTC)
I read that before, but my question was also not pretty accurate. I would like to know for which purpose they are expected ... --Stefan-Xp (talk) 18:42, 16 November 2008 (UTC)
The coordinates, represended by a little round icon, show where the camera stood, and the heading shows up as a tiny arrow pointing from there, to clarify where the camera was pointed. For example, there's lots of them here. It wouldn't make so much sense if we geocoded the object, rather than the camera location. --Specious (talk) 20:14, 16 November 2008 (UTC)
Ahh :) very cool! But perhapps it could be integrated in the Template as a small compass? So users could see whether or not the Geotag has a Heading :-) --Stefan-Xp (talk) 20:52, 16 November 2008 (UTC)

How can I Find coordinate templates which don't have a Heading in my images? --Stefan-Xp (talk) 22:49, 29 November 2008 (UTC)

Very cool indeed. My camera automatically geotags about half my pictures but does not know headings, so days after uploading I insert the heading, for example in File:Spuyten Duyvil Br Bx jeh.JPG. By default all headings are due north, so when Google Maps shows a field of Commons roundels, the ones with the arrow pointing straight up will be mostly uncoded headings. I have made a rule to adjust my headings at least ten degrees off due north to distinguish from uncoded headings. 'Twould be pleasant to have a less ambiguous method of showing the unheaded roundels. Jim.henderson (talk) 15:16, 2 May 2009 (UTC)
Oh. Whine and ye shall be heard. Last couple days, pictures with coordinates but without headings have been showing up on Google Maps as fully round roundels without points, slightly bolder than the pointed roundels. So, at a glance we can see which pix have known headings and which don't, which a person familiar with the location can usually identify to useful precision more quickly than we can identify the location. Way cool. Life keeps getting better.
Now for another whine, as urban locations become carpeted with red/blue location roundels, they crowd the maps. Even prettier and more useful would be if the scale of the initial map could adjust automatically to show a limited number or density of roundels in the frame or central part of the frame, rather than wait for us to zoom. Always hoping the smart people, who understand whether this is difficult and how to make it work, will be listening. 05:05, 6 May 2009 (UTC)
Hmm; I seem to be mistaken. My own pictures that have the default zero Heading are shown in Google Maps by a roundel with arrow pointing north, while pix by other photographers have the round, arrowless roundel. I don't understand. Jim.henderson (talk) 17:50, 8 May 2009 (UTC)
BAM

This is someone else's picture, which correctly has a round symbol on Google Maps, apparently because its heading is shown with a ? question mark. This one was processed by the same bot that incorrectly gives a zero in the heading for my pictures. So, jt seems there's some kind of difference in my pix, which are tagged automatically in the camera, that causes the bot to give a heading when there is none. Perhaps the bot owner can make it work correctly. Jim.henderson (talk) 16:43, 11 May 2009 (UTC)

Assign a Bot?

Why does nobody programm a bot which will replace old {{coor}} and {{coordms}} etc. templates? wbf --Stefan-Xp (talk) 17:49, 16 November 2008 (UTC)

No Comments? --Stefan-Xp (talk) 10:39, 17 November 2008 (UTC)
Because these templates to not contain well defined coordinate data! An automatic replacement is not feasable as the coor templates were used before we agreed on geocoding the camera location. Oftentimes these templates contain object locations in the image description. --Dschwen (talk) 13:40, 17 November 2008 (UTC)
Thats bad... Is there a possibility to use it for myself? ;) --Stefan-Xp (talk) 21:03, 17 November 2008 (UTC)

Template No Location Needed

Hi, is there already a template which tells, the Geocoding Todo tool that an Image doesn't need a Location? F. Ex. Food (Pizza and Hamburger), Cars, Close-Ups etc. ... wbr --Stefan-Xp (talk) 21:32, 18 November 2008 (UTC)

Adding an image to Category:Location not applicable will make the tool ignore the image. It wasn't made a tag since people probably aren't interested in that non-information, and so it doesn't need to be displayed, hence the hidden category. --Para (talk) 10:58, 20 November 2008 (UTC)
Very Well! Thank you! I already hardworking ;-) But it exposed another Problem ... My Category doesn't show me all my images :(--Stefan-Xp (talk) 22:50, 20 November 2008 (UTC)
What do you think about the inclusion of this category in some templates f.ex. Coat of Arms? --Stefan-Xp (talk) 19:57, 25 November 2008 (UTC)

No Location Template

What do you think about this one? :) I was not really sure about the text... --Stefan-Xp (talk) 12:29, 24 November 2008 (UTC)

"C&P" needs to be spelled out, I think. --Padraic 16:31, 24 November 2008 (UTC)
Thanks for this Hint! --Stefan-Xp (talk) 20:19, 24 November 2008 (UTC)

There's also {{Location possible}}, which puts the images to Category:Location possible. I suppose there's no difference with the intended use. --Para (talk) 22:05, 27 November 2008 (UTC)

The "new Tool" looks useful, but there are 2 major disadvantages. First the tool can't add a heading, second it can't use Coords/Search features as startingpoint. --Stefan-Xp (talk) 07:41, 28 November 2008 (UTC)

What about Coat-of-Arms?

Hello, during a Discussion Flominator advised to geolocate those media... what dou you think about? Why does the Geocoding Project page not contain information about what to geocode and what not? --Stefan-Xp (talk) 20:01, 27 November 2008 (UTC)

I don't think we should be spending time geocoding things that are already geocoded on Wikipedia, but instead work on better linking to Wikipedia, or to propose different solutions for reusers. For example, a way to browse coats of arms on maps could be to replace the usual placemarks by the coats of arms Wikipedia editors have chosen for articles. Wikipedia infoboxes, their variables and relations to their parent areas probably need work, and it'd be better to direct the efforts there instead of duplicating data here. Image:Coat of arms of Kingdom of Hungary.jpg and the like could use some geocoding, but I'm not sure anyone has tried putting any guidelines in simple words yet. --Para (talk) 16:50, 29 November 2008 (UTC)
The answer is pretty much implied by the fact, that we are geocoding the camera position and heading while a picture was taken. No camera position => no geocoding. That goes for maps as well, by the way, we have the overlay template for those. --Dschwen (talk) 17:27, 29 November 2008 (UTC)
The first bold bit on the project page actually says that we geocode where the media was recorded, and I've taken it to extend to the views shown in paintings as well. For example, Image:Francois-Etienne Villeret St Sulpice Paris.jpg and Image:Canaletto (I) 020.jpg are geocoded to a point where someone would see a present view of the depicted location, but others might prefer geocoding the location of the work today. Again I see the duplicated museum locations as less interesting, even if someone has managed to pinpoint the exact spot on the museum corridor. With other works of art that aren't so clearly related to a location, that would however be the only possibility. To geocode or not to geocode? --Para (talk) 20:17, 29 November 2008 (UTC)
For the COAs I would propose to make nails with heads ;-) and add the category:Location not applicable to the template :-) --Stefan-Xp (talk) 22:29, 29 November 2008 (UTC)

Problem with Google Maps Method 1?

There seems to be a problem with the Google Maps Method 1 for geotagging. When I click on the link to geotag, I get an error message of "File not found at http://tools.wikimedia.de/~...." I know there has been some maintenance with the tools, could this be the cause?--HoboJones (talk) 02:19, 31 December 2008 (UTC)

Yes. Maintenance is still ongoing. --Dschwen (talk) 02:49, 31 December 2008 (UTC)
Now geohack is spitting out gibberish like "h%y��5�}����=��V"-- is that related to maintenance too?--HoboJones (talk) 17:10, 2 January 2009 (UTC)

Post-hoc geocoding

I've just read that the camera position should be geo-coded.

But for many pictures of geographic objects this information is not available, whereas the the coordinate of the object can be found and added post-hoc.

IMHO having (also) a object location would help finding images for not yet existing articles. The rationale, that the object location can be found in the article which uses the image only applies to existing articles.

--Pjacobi (talk) 11:03, 4 January 2009 (UTC)

this has been discussed numerous times. If you can find the object location, it is not that hard to infer the camera position. Camera position is usually very close to the object (unless you have super tele shots). And we might just as easily find images for new articles given the camera coords. --Dschwen (talk) 17:45, 4 January 2009 (UTC)
Yes, it looked like an issue, which has been discussed ad nauseam. Nevertheless there your response doesn't address the problems in the field in which I stumbled about it: Mountain photography.
  1. Given only the camera position, there is no good guess about the object location (somewhat better if the camera heading is encoded).
  2. Given a not geocoded photography, it has uncertainties of kilometers about the camera position
Looking for photography of certain lake in the alps (unfortunately not mentioned in any image), I had to search for all peaks in the surrounding. A geocoded search based on object location would have been very helpfull.
Anyway, I don't expect to successfully re-open the entire discussion. For a pragmatic solution, may I assume that adding guessed camera locations to not geocoded images is OK?
--Pjacobi (talk) 10:16, 5 January 2009 (UTC)
I thought I addressed these points (1. camera location being close to the object, 2. see 1). If you look for images of a certain lake, open up GoogleEarth add the commons layer, fly to the lake and look which markers point to the lake. And yes adding guessed camera locations to not geocoded images´ is not only OK, it is highly appreciated, and it is how a good part of the geocoding here is done. Indicate the accuracy of your estimate by using the appropriate number of decimal digits. --Dschwen (talk) 13:27, 5 January 2009 (UTC)
Let me elaborate further. It seems to me that the underlying problem are insufficient descriptions and missing categories. Instead of solving this by changing the geocoding paradigm in a way that most likely is too complicated for the casual user, we should just keep using the means we have: enhancing descriptions, adding categories. --14:16, 5 January 2009 (UTC)
Thanks for your replies and suggestions. --Pjacobi (talk) 19:52, 6 January 2009 (UTC)

Placement of location template

Hi.

I'd like to quite strongly disagree with the following recommendation in this article:

Simply add {{location dec|lat|long}} to the top of the image page, filling in the lat and long from the procedure above.

Doing this places the location of the image as the most important thing we know about the image, over and above (say) the descriptive caption of the image. That is plain silly. Clearly the camera position of an image is useful and potentially important information, but equally clearly (IMHO) it is less important than a decent caption or description of the image. I'd like to change the statement to something like:

Simply add {{location dec|lat|long}} to the image page, filling in the lat and long from the procedure above. If the image page has an {{Information}} template, or similar, the {{location dec|lat|long}} should come immediately after it.

As an example of what I'm talking about, see File:Starcross railway station 1.JPG, as amended by Dschwenbot, and as further amended by myself.

Any objections?. -- Chris j wood (talk) 17:56, 8 January 2009 (UTC)

No objection. This is a reasonable approach and I also do the same. Sv1xv (talk) 18:33, 8 January 2009 (UTC)
Copying the reply from my talk page. It would be possible, but would require substantially more effort. I'd essentially have to parse the wikimarkup, counting opened and closed templates to determine the end of the Information template. Finding the beginning of the Information template is much easier, I just have to find a single string. Now I am currently working on a more intelligent template parameter extraction routine, and as a side-effect I would be able to get end-of-template positions, which I could use in the dschwenbot. Don't hold your breath though ;-). --Dschwen (talk) 18:36, 8 January 2009 (UTC)
  • If you are actually asking: No, please don't reopen that discussion ;-). It looks fugly. There are more templates in this style now and they are designed tool look better when stacked. --Dschwen (talk) 23:25, 8 January 2009 (UTC)
  • I don't mean nesting it within the template, which is indeed fugly, but made a part of the template itself, as an extra field: Description, Camera Location, Source, Date, Author, Permission. Cheers - gobeirne (talk) 00:47, 9 January 2009 (UTC)
  • Making it a part of Information doesn't seem like a good idea to me either. It was recently discussed on the mailing list. One point was that Location has order based parameters, while Information has name based parameters. Merging them would make things more complicated. Having different templates is a nice semantic separation. It keeps the picture meta data modular. --Dschwen (talk) 04:02, 9 January 2009 (UTC)
Yes, please don't include the location template into the information template. It looks good so how it is an is easier to extract. --Kolossos (talk) 09:53, 9 January 2009 (UTC)
IMHO the page needs a good shaking, to translate it into readable English suitable for our target audience. The sentence in question is now just wrong, and the improved wording will help. As long as it doesn't become prescriptive. For a Commonist user, the location tag has to be written into the Description field. For example File:Restoration House Winter 8856.JPG. The W:Wikipedia:WikiProject Geographical coordinates article which is also a dogs breakfast uses the idea of a quick howto which may be useful here. ClemRutter (talk) 10:05, 9 January 2009 (UTC)
Ok, I finally got around to change my bot to place the Location template right after the Information template. --Dschwen (talk) 16:32, 25 February 2009 (UTC)

vEvent generating templates

I am working on a set of templates that generate hCalendar metadata that couples time with place. This is for categorization and user navigation purposes, so the location information is fuzzy and therefore useless for precise mapping. Users of the template are instructed to use Template:location if they have precise coordinates. These decade templates do not generate location templates. They can emit geo coordinates [edit- currently disabled], but the default mode is to request users to provide adr placenames, which they will probably do, since it is a lot easier. Besides, the scripts for Google/Yahoo/Mapquest appears to toss the geo coordinates anyway, and lookup based on adr location name. The current implementation works with Operator and will interoperate with yahoo & google calendar/contacts/map type applications, though the operator scripts do not appear to pass all information to all sites, and some have limitations with dates from prior periods of time.

Comments, please leave on Template talk:Places_by_decade Thanks -J JMesserly (talk) 17:29, 22 January 2009 (UTC)

I have had no response on this so perhaps I could elaborate. The fundamental puzzle I have with this template stems from the fact that an event is a compound object that specifies time and place. Many events recorded in Commons images do not have precise identifiable locations, but since a vEvent must specify a location, such vevent template can provide general adr locality information. The template emits an hCard for the location so that the event location can be viewed by end users, and so that authors can verify their encoding of placenames. The technical challenge is that if templates like {{Places by decade}} are to emit vEvent microformat, then either they share data with the {{Location}} template, or they provide redundant location information. Since wikitext is not a high level language, proper encapsulation of data is not practical. Because of this and the previously mentioned need for fuzzy location support, vEvent templates will potentially provide conflicting information if a location template is also used on a page.
The Problem: The potential for redundant data can already be seen- for example if you view with Firefox's Operator extension this Goring image page you will see that it has two hcards for the same location. This is not an acceptable situation but it is manageable with practical methods.
Proposal: My proposal is that vEvent emitting templates have a flag for suppressing vcard location information. This way, when a Bot notices a location template on the same page as a Vevent template, it will set the flag on the vevent template to cease emiting the hcard. This way, the folks authoring historical event templates can quickly indicate a general location for their event, and a later author can refine it to exact coordinates with the location template. Many authors will not know to do this, but a Bot very happily can do the fixup. Future bot runs might be more elaborate. When historical vEvents become popular, then we might consider re-introducing geo support and making bot runs that transfer the precise coord from the location to the future vEvent templats. For the time being, I think we can wait until such applications to develop, and not confuse users with the provision of a geo option on vEvent templates. At this juncture, it appears to me that any precise specification of location should use {{Location}} -J JMesserly (talk) 17:28, 25 January 2009 (UTC)
As explained on the template talk page; the proposal is redundant, and the current implementation broken and emitting bogus metadata. A more elegant solution (which I have been working towards, intermittently, since I first raised the idea in 2007) is to use {{Information}} to emit the hCalendar microformat; then include within that sub-templates such as {{Photographer}} to emit hCards for "attendees" (including human subjects) at the event; a similar template (new, or an expansion of {{Location}}) for the venue or place-subject of the picture; {{Location}} for the coordinates and {{Date}} or similar for the event's date. Rather than rehashing this discussion on several pages (which I'm as guilty of as anyone), perhaps it should be centralised? Andy Mabbett (talk) 19:26, 25 January 2009 (UTC)
As explained in the text above, the event data is inherently redundant. Andy has some opinions and proposals he has expressed voluminously on sites such as his blog and microformats.org. I am interested in practical solutions for Commons. If folks doing geocoding templates have any specific recommendations, then please contact me. -J JMesserly (talk) 20:49, 25 January 2009 (UTC)
I'm also interested in practical solutions for Commons (and am basing my suggestions on extensive experience of implementing microformats on a number of high-volume sites, not least Wikipedia,, and assisting in the development of both microformat specifications and microformat parsers, including both Operator and Swignition). To suggest otherwise, would be tantamount to a personal attack; and I'm sure you don't mean that, Perhaps, in the light of your recent apology for wrongly calling me - several times - a vandal, and your other ad hominem attacks, for which you have not yet apologised, you could confirm so? Andy Mabbett (talk) 21:19, 25 January 2009 (UTC)
Perhaps a cool down period is in order. -J JMesserly (talk) 23:30, 25 January 2009 (UTC)
I'm perfectly cool; and waiting for you to reply to the request in my previous comment on this page. If you require to cool off first, that's OK. Andy Mabbett (talk) 23:52, 25 January 2009 (UTC)
Andy, as I have said, my response is that I have taken note of your concerns and comments. I appreciate your input. -J JMesserly (talk) 23:59, 25 January 2009 (UTC)
And I note your reluctance to confirm that you were not suggesting that I am not interested in practical solutions for Commons. Andy Mabbett (talk) 00:26, 26 January 2009 (UTC)
If you took some offense, please accept my apologies. -J JMesserly (talk) 00:37, 26 January 2009 (UTC)

Is it good practice?

Hi, for existing, non-geotagged pictures about subjects situated inside a building, say for instance works of art in a museum, would it be ok to tag them with an approximate geotag corresponding to the one of the building? Or is it better to leave the image page as is? --Eusebius (talk) 18:10, 23 January 2009 (UTC)

I believe Category:Location not Applicable would fit much better :) --Stefan-Xp (talk) 19:16, 23 January 2009 (UTC)
Why? we're talking about geographically situated pictures, so why wouldn't it be applicable? OK, for well-taken pictures of paintings (PD-art stuff, with no frame) it may look stupid, especially if the "painting" template is properly filled (and yet, I wouldn't find that strange to see a geotag). But let's take this random example, would you say it's more useful to tag it as "location not applicable" or to give it the geotag of the Royal Belgian Institute of Natural Sciences? I like the idea of being able to see stuff like that on Google Earth or whatever tool you use, but I just thought that maybe it would be like "spamming" the maps, with many pictures on a single spot. --Eusebius (talk) 20:23, 23 January 2009 (UTC)
I like geocoding and seeing geocoded images with stationary elements that show something of the location. I don't like seeing images of some other things only, but what the hey, that's my problem, and I can easily ignore hundreds of uninteresting images geocoded to the same coordinates. If a painting or drawing depicts elements that actually exist, I would prefer geocoding it to that location, instead of a museum room. I started looking for paintings I've geocoded before, and remembered I commented on this before. --Para (talk) 22:26, 23 January 2009 (UTC)
But templates as {{Location}} are intended to pinpoint the location of the camera, right? From the reading of the first section of this page I understand that it is "what's done on Commons". Or do you use {{Object location}}? What do you think about using both in the same image page in the case you mention? Questions answered by reading the discussion about CoAs. I see there that this issue (geotagging paintings) came to no conclusion? I find it interesting though, I find value in both kinds of geotags (geotagging the painting, and the painter's vision). --Eusebius (talk) 22:41, 23 January 2009 (UTC)

Where to Geocode from

Just to confirm, you do Geocode the camera location don't you? i.e. where you were stood if you like, rather than what you are photographing. I want to Geocode my images but I just need to check to see whether if, for example, I zoom in to take a picture of an object far away, I still Geocode where I was stood. Thanks for any help!! Arriva436talk/contribs 21:03, 31 January 2009 (UTC)

Your right :-) the Location template mirrors the Camera Location, some people also add the Object Location ... see also {{No Location}} Best Regards, --Stefan-Xp (talk) 01:29, 1 February 2009 (UTC)
Thank you. Arriva436talk/contribs 15:56, 1 February 2009 (UTC)

Usage outside maps

It's great to see Commons images plotted on maps and satellite images, but other uses of the data can be interesting as well. I remembered an old request from User:Gobeirne at Commons talk:Geocoding/Archive 1#Proximity and an old mailing list message from User:LA2 about showing images in a gallery, ordered by geodata. So I implemented Lars's suggestion of going through images around an object counterclockwise; see images of The Great Sphinx of Giza, Chichen Itza or Arc de Triomphe. I think it's pretty cool! Can anyone think of objects we have lots of images of, and which don't look so much alike on all sides?

We run into small problems when there's something obstructing the view, like in some of the images geocoded around Tower Bridge and probably many other busy places. Even though the camera points towards the bridge, it's inside or behind a building, so we don't see what we expected to see. The current limits I happened to choose were camera distance from the object (0.005°) and difference between the heading and the vector to the object (angle of view, 45°). What would greatly help is object annotation in images, distance of farthest visible object (related to previous; if everything is annotated, distances to known objects can be calculated), and field of view (is it possible to get it from exif data?).

Anyway, how can we put this or a similar tool visible somewhere to display related images? The Wikipedia GeoTemplate would be one place, though it's not that good for promoting Commons content. The tool I wrote now requires object locations ... and the only way I can think of to have it on Commons pages is a gadget that would look for coordinates in Wikipedia articles linked from the description, and query the tool for images of the object(s) at those coordinates. But would such an opt-in gadget be that visible, really? --Para (talk) 02:44, 21 February 2009 (UTC)

Looks great. But you could also fetch a set of camera locations around a target point with headings approximately towards the target. --Dschwen (talk) 02:50, 21 February 2009 (UTC)
Indeed, and it is done already, in the sense that if the heading is over 45 degrees off the target, the target probably won't be visible and the image is discarded. To take an example, some images have been geocoded on top of Arc de Triomphe, pointing away from the target, and those aren't shown in the gallery. That helps a bit with not having any image annotation, but isn't quite enough with the problem of obstructing objects. Still, this should be useful already for noticing errors in geocoding; if the order of the images doesn't seem quite right when "walking" around an object, the geocoding needs fixing. --Para (talk) 02:58, 21 February 2009 (UTC)
as for the occlusion: keypointmatching could help to detect similar features. I started working with a SIFT feature vector extrator, but only recently I gained enough experience with kd-trees for actually searching similar feature vectors. For a small set of images, prefiltered from geodata this could be a feasible approach! --Dschwen (talk) 03:43, 21 February 2009 (UTC)
Have you seen the open source Finding Paths through the World's Photos project? The rotation and stabilisation features are absolutely amazing! --Para (talk) 13:41, 22 February 2009 (UTC)

Geocoding To-Do

I tried this but I absolutely don't get it why File:Sonic.jpg shows up... has someone a clue? --Stefan-Xp (talk) 12:35, 22 February 2009 (UTC)

You uploaded a file by that name in 2005[2], and the tool is simply going through the logs. But since files sometimes do get deleted, I changed the tool to look at the latest uploader only. In case of derivatives uploaded over the original, or vandalism reverted by someone else or something, it might hide some uploads though. Maybe at some point I'll further change the tool to go through logs and make a stack of each file to see if their uploaded version is still visible in the history. Though sometimes versions in the middle get deleted and not just the latest one, so that might be problematic too. Latest uploader it is. :) --Para (talk) 13:15, 22 February 2009 (UTC)
Thanks a Lot! Maybe you could also pass the choice to the user, the first not deleted Upload would be the best solution for me ;-) --Stefan-Xp (talk) 20:25, 22 February 2009 (UTC)

Internationalization of {{Location}} template

I would like to propose the following changes to this template:

Shall we merge them somehow and delete the doubles?

--Jarekt (talk) 14:21, 3 March 2009 (UTC)

I'm totally out of the loop with internationalisation, autotranslate templates and whatnot. But I don't think anyone would object if the little text the template has matched the language in the user's preferences.
There have been arguments that links to external services are useful and we should link to the best, or that the links should be to Commons content in external services, or that any external links obscure our own free map, the WikiMiniAtlas, and we should work to be independent.
On truncation, I think people should be encouraged to strip excess precision themselves, and when that doesn't happen, we could have a bot do it for them to raise attention. Displaying something else than what was entered wouldn't be good.
Commons:Geocoding#Adding a location template documents {{Location}} and {{Location dec}}. I don't see a need for the other templates when geocoding camera location, especially not the degrees and minutes ones. The various redirects might be better removed to keep template usage consistent. --Para (talk) 13:38, 9 March 2009 (UTC)
I created internationalized versions of 4 location templates:

Here is test image with those 4 templates: in english and polish version. All 4 templates use the same set of translation phrases and the same layout template. I am seeking comments before asking for upload of the first 2 templates. --Jarekt (talk) 03:35, 10 March 2009 (UTC)

Geocoding other people

I've added geocoding to a couple of images where I was familiar enough with the subject to not only place the subject, but the camera as well. Is this cool, or should I only be tagging my own shots?--SarekOfVulcan (talk) 14:48, 6 March 2009 (UTC)

That's very ok, unless it's a private place and the uploader doesn't want its location exposed, but it's apparently not the case here. Thanks for helping! --Eusebius (talk) 15:12, 6 March 2009 (UTC)
I agree that geocoding is very appreciated whenever you are confident that you can perform it with sufficient accuracy. I would not worry too much about the privacy concerns. If you are able to tell the location from the picture, it basically exposed itself. And the uploader put the picture on a very public website by choice. --Dschwen (talk) 16:19, 6 March 2009 (UTC)
I even would be fine, if you geotag some of my leftover pictures ;-) --Stefan-Xp (talk) 09:41, 7 March 2009 (UTC)

Text location -> Geo

I noticed it is possible in some cases to derive Geo's automatically via bot. For example, in File:Bahnhof Alexanderplatz mit Königskolonnaden, 1904.jpg, on that page, there is an event template that knows the location is : Alexanderplatz, Bezirk Mitte, Berlin, Germany. It knows this for an unrelated purpose: categorization of location. Anyway, a bot can scoop up that data and send it to google's handy tool, for instance:

http://maps.google.com/maps/geo?q=Alexanderplatz,%20Bezirk%20Mitte,%20Berlin,%20Germany&output=json

Produces:

{
  "name": "Alexanderplatz, Bezirk Mitte, Berlin, Germany",
  "Status": {
    "code": 200,
    "request": "geocode"
  },
  "Placemark": [ {
    "id": "p1",
    "address": "Alexanderplatz, 10178 Berlin, Germany",
    "AddressDetails": {"Country": {"CountryNameCode": "DE","CountryName": "Germany","AdministrativeArea": {"AdministrativeAreaName": "Berlin","SubAdministrativeArea": {"SubAdministrativeAreaName": "Berlin","Locality": {"LocalityName": "Berlin","DependentLocality": {"DependentLocalityName": "Mitte","Thoroughfare":{"ThoroughfareName": "Alexanderplatz"},"PostalCode": {"PostalCodeNumber": "10178"}}}}}},"Accuracy": 6},
    "ExtendedData": {
      "LatLonBox": {
        "north": 52.5255346,
        "south": 52.5192393,
        "east": 13.4172199,
        "west": 13.4109247
      }
    },
    "Point": {
      "coordinates": [ 13.4148965, 52.5225977, 0 ]
    }
  } ]
}

The bot would then insert a {{Location dec}} using the extracted values.

It's no silver bullet with geocoding because it probably requires some user effort. Many google map expressions will return multiple hits, and for those, google returns no geo information. But oftentimes, information quickly derived by the user is sufficient (File:Berlin, Mitte, Schloss & Schlossbrücke, 1901.jpg, File:75-Paris-Porte Saint-Denis-1908.JPG, File:Fête de la Concorde 1848.jpg). I am going to revamp my event templates and will probably create a bot that grovels them to produce a location dec when a value is returned. In any case, I thought it was interesting and thought I'd pass it along in case others might want to mess with it. -J JMesserly (talk) 23:11, 9 March 2009 (UTC)

Google's geocoding is useful for many purposes, but it unfortunately can't find camera locations based on the current name of a street, other object in the image, or much else than current street intersections. So far the Commons geocoding project has worked on quality over quantity, and I would like to see it continue be done as accurately as it has been, with manual contributions. Flickr's geocoding of the Alexanderplatz area for example is completely useless, and to me seems like their images have been randomly scattered around that possibly automatically found location. Please don't run a bot to spider Google's geocoding here. --Para (talk) 01:03, 10 March 2009 (UTC)
Okeydokey. That's a completely reasonable call. I have figured out the coordinates for a few battles and paintings by hand and it is sometimes exceptionally hard to do, but the results are worth it. A Civil war event on the Mississippi river where the river no longer runs was probably the worst. -J JMesserly (talk) 02:59, 10 March 2009 (UTC)
I think such bot could be used to create {{Object location dec}} templates. They are less preferred than {{Location dec}} but much better than no geocoding. --Jarekt (talk) 16:02, 9 April 2009 (UTC)

Template jungle

At the moment we have several different types of coordinate templates:

There is {{Coor}}, which is relatively unelaborate (first parameter is the coordinates encoded as GeoHack URL, second parameter coordinates for display). Then there is {{Coor d}}, {{Coor dm}} and {{Coor dms}}. The {{Location}} ( {{Location}}, {{Location dec}}, {{Location deg min}} ) and {{Object location}} ( {{Object location}}, {{Object location dec}}, {{Object location deg min}} ) families are both based on the {{Coor dms}} code, but show boxes around it.

{{Coordinate}} is rather elaborate with several additional parameters (some of them useful, some of them not [like population, useful on Wikipedia as a property of a place article, but not on Commons as a property of a file]). There's {{Map}} which displays a box with several map services.

And finally there's {{Flickr map}}, which takes no coordinates at all, but a Flickr URL related to a coordinate.

In my opinion, it would be good to replace all these different formats (perhaps there are even more I'm not aware of?) with a single template. That would have several advantages. Uniform look, easier maintenance, and it would be easier to extract the geodata for tools etc.

I already converted all occurences of {{Flickr map}} to real coordinates. And I think, {{Map}} is not the right way to display geo information. It should be replaced.

Some templates use minute/second notation, some decimal notation. For calculations decimal notation is easier.

Ideally we should replace all occurences of the templates by bot with a new template: first two parameters decimal coordinates (with negative values indicating coordinates on th Western/Southern hemisphere), an optional "text" parameter to change the displayed text (like {{Coor}} allows it), and some optional additional parameters like {{Coordinate}} allows them ("globe" for ecample, or "dim").

Display in a box like {{Location}} and {{Object location}} provide it, should rather be done by adding a "location" parameter to {{Information}}. Cause after all that's what the box tries to emulate with its look.

The difference of "camera location" versus "object location" could be made by actually adding two parameters to {{Information}}. That would at least be a more correct representation of the relations than making it a parameter of the location template. --Slomox (talk) 02:15, 17 March 2009 (UTC)

We've been over the adding location to information thing already. Location takes numbered parameter, information takes labeled parameters. Conversion will be complicated, and the new format harder to use. There is nothing wrong with modularized templates. The ones we should keep are Location, Location_dec, Object_location, and Object_location_dec (although, if you are asking me, the last two or three can go, as I don't see much point in coding object location on commons and I dislike the decimal degree look). In any case it should be clear from the project page that the rest of the templates is deprecated. If it isn't we should make it more clear. --Dschwen (talk) 02:40, 17 March 2009 (UTC)
Slomox, other complication with adding location field to {{Information}} template is that it has long been proposed to add such a field for word description of the location. See {{Information2}} or example File:US Army paratroopers Fort Bragg.jpg.
I agree that many of the templates should be retired and deleted. Redirected location templates: ({{Location d}}, {{Location dec US}}, {{Location dec min}} & {{Location dms}} are obvious candidates, so is {{Flickr map}}. {{Map}} (I think) can be safely redirected to Location_dec, and probably deleted as well.
But I agree with Dschwen that "we should keep Location, Location_dec, Object_location, and Object_location_dec". I am also not a big fan of Object_location and Object_location_dec but I can see some limited use for it. Today I also discovered {{Location deg min}} template, which I changed to use template:location/layout but which I would prefer to retire as well. --Jarekt (talk) 04:02, 17 March 2009 (UTC)
Okay, if they officially deprecated that means that they can be safely replaced by bot and deleted. Cause deletion is the only way to really deprecate something in an open system like a wiki.
And if location is okay in {{Information2}}, it should be okay in {{Information}} too, ain't it?
Location takes numbered parameter, information takes labeled parameters I don't understand that. We would have something like:
{{Information
|Description={{en|foobar}}
|Source={{own}}
|Date=2009-03-17
|Author=[[User:Slomox|Slomox]]
|Permission={{PD-user|Slomox}}
|other_versions=
|location={{loc|53.597|9.188}}
|object_location={{loc|53.561|9.186}}
}}
(Or without "object_location" if it is agreed upon that it is not useful.) The location is a property of the file and thus belongs into the {{Information}} template.
And one more point: You say, everything except Location, Location_dec, Object_location, and Object_location_dec is deprecated. But what about the features of {{Coordinate}}? I agree, that {{Location}} provides all the basic functionality needed (although I dislike the fact that it uses 8 parameters for a thing, that could be done with 2 parameters easily), but for some cases it would be useful to be able to specify more details:
  • "globe" to specify the relevant celestial body (this could be done with special templates for Moon, Mars etc. too but there's few reason to handle them differently)
  • "elevation" or "height" to specify the height from which the image was taken, for example for aerial photos
  • "orientation" to specify the direction the photographer looked at (and perhaps another parameter for the angle against the horizon; those parameters could be useful for photos of the nightly sky for example)
  • a title to display instead of the coordinates (like {{Coor}} allows it; this should rarely be necessary, but it should be possible)
  • perhaps there are even more attributes that could be useful to specify? --Slomox (talk) 11:09, 17 March 2009 (UTC)
Nah! Then people have to remember another template parameter for information and the rather obscure loc template (doesn't that stand for library of congress ;-)?). We do not need title for Location, as that should be unique for each image (and again I think Object_location is a bad idea to begin with). All the other functionalities are implemented using heading:, alt:, globe: in the extended parameter section (with type:). Again I ask, why cram everything into Information in the first place. There are several other templates (map overlays, panoramavierer) which stack up in the same modular manner. Should they also be integrated into information? We cannot just delete the old templates because a replacement with the new ones is non-trivial! A bot cannot make sure that the uses of coord adhere to the geocoding conventions. How do we know whether camera location or some arbitrary object are geocoded? It is best to leave that to humans. What we could do is have a bot tag all those images and notify their uploaders (I can do that if we can agree on that). --Dschwen (talk) 13:35, 17 March 2009 (UTC)
Dschwen you're right. Perhapps someone could create a tool which proposes the cameraposition in relation to the old template, users could check or modify it. --Stefan-Xp (talk) 14:01, 17 March 2009 (UTC)
I also think that current approach where {{Information}} stays as it is and we use additional templates to add to it is fine. The only think I would add to {{Information}} is an optional text location field so we can retire {{Information2}}. I would like to trim down the number of Geo coding templates. Lets start with deleting the easiest - already redirected ones. Can we just slap {{Bad name}} tag and let delinker do all the replacements? Does this work with templates? Than we can tackle more complicated ones like {{Location deg min}} and {{Coordinate}} where manual intervention might be needed. If we agree (and may be we should invite more people to this discussion) that those 2 should go than I like the idea of giving uploders chance to change them. --Jarekt (talk) 14:13, 17 March 2009 (UTC)


doesn't that stand for library of congress Was just some random example for the template name.
We do not need title for Location, as that should be unique for each image Yes, but if somebody wants to set a link like See Google Maps (for whatever purpose) this should be possible without having to resort to another template.
All the other functionalities are implemented [..] in the extended parameter section Yes, but in a format not accessible via wiki syntax.
There are several other templates (map overlays, panoramavierer) which stack up in the same modular manner Yes, if those templates represent basic properties of the image, it should be in information. Whether this is the case for the two examples is another question. {{Overlay}} is a badly designed template, IMHO. Instead of saving the kml file in a place of its own, the values should rather be put into the template as parameters. Being overlayable is a basic feature of maps, so it should be put together with other map related properties.
It is best to leave that to humans. Which humans? Who likes to change thousands of inclusions of boring templates? And I guess, actually most coordinates manually inserted by users are not even exact enough to tell the difference between camera location and object location...
A uploader notification bot will not solve the problem. It will first of all annoy the uploaders.
The only think I would add to {{Information}} is an optional text location field What would be the purpose of that? The name of the place is language-dependant and should be mentioned in the description parameter. --Slomox (talk) 15:11, 17 March 2009 (UTC)
most coordinates manually inserted by users are not even exact enough to tell the difference between camera location and object location, so let's just throw our quality standards out the window? Which humans? uhm, maybe the ones who already inserted 150000 geo-cordinates?! --Dschwen (talk) 15:28, 17 March 2009 (UTC)
Or dear, silly me. I was worried how to take camera shake into account, when you code to 9 decimal places it does cause a moral dilemma! (Humour-in case you thought this was a proposal).--ClemRutter (talk) 14:44, 23 March 2009 (UTC)
Or maybe: They really are the same look at File: Commons editor on ground with experienced photographers foot on his throat.aah!--ClemRutter (talk) 14:44, 23 March 2009 (UTC)
You should be more worried how to get your point across or your indentation right. I frankly have no idea how what you just wrote relates to my comment. --Dschwen (talk) 14:52, 23 March 2009 (UTC)

Geocoding a gallery

Hi, what is the right way of adding a geotag to a gallery? What's the state-of-the-art template for that purpose? --Eusebius (talk) 13:51, 23 March 2009 (UTC)

To my knowlegde we don't geocode gallerys. On commoms, we tag the photographer not the object- so it wouldn't make sense.--ClemRutter (talk) 14:44, 23 March 2009 (UTC)

I would like to propose to retire {{Location deg min}} and {{Object location deg min}} templates. I think templates {{Location}}, {{Location dec}} and the Object location counterparts provide enough ways to define coordinates, without need for those two. The only way for {{Location deg min}} to be precise is to store minutes as a real number with about 3 decimal digits, if that is not done than location is very imprecise. In order to retire those templates one would have to replace by bot {{Location deg min|a|b|c|d|e|f}}}} with {{Location|a|b|0|c|d|e|0|f}}}}. --Jarekt (talk) 12:46, 24 March 2009 (UTC)

 Support. --Dschwen (talk) 17:11, 24 March 2009 (UTC)

All instances of {{Location deg min}} and {{Object location deg min}} templates were replaced and the templates are listed for deletion Commons:Deletion requests/Template:Location deg min. Please voice your opinion. --Jarekt (talk) 03:53, 31 March 2009 (UTC)

Triming down rarely used geocoding templates

I was lately replacing and deleting, rarely used geocoding templates. Please voice your opinion at:

--Jarekt (talk) 04:15, 14 April 2009 (UTC)


Map overlays Google Earth/World Wind

I am trying to make me more familiar with map overlays at the moment and I have a question: Does Google Earth or NASA World Wind support overlays of maps that are not taken orthogonally to the ground, but from a different angle? Or, if not, is there any other software that does this? --Slomox (talk) 15:19, 25 April 2009 (UTC)

To give an example: Would it be possible to create a map overlay with File:Attack on Pearl Harbor Japanese planes view.jpg? --Slomox (talk) 15:19, 25 April 2009 (UTC)

What you can use in your case with the aerial image is: http://code.google.com/intl/de-DE/apis/kml/documentation/photos.html
In project /Overlay we support each KML, so it should work.
For maps take a look at: http://labs.metacarta.com/rectifier/
You should deformed the image with the help of refence points and can use it than also with GoogleEarth/NASA. This isn't possible with KML, you can only rotate and scale . An interesting blog to this topic is oldmapsonline. --Kolossos (talk) 10:04, 26 April 2009 (UTC)

Google Maps updates

How long does it take for the toolserver to display a Location on Google Maps (using GeoCommons-simple.kml)? I uploaded quite a few geocoded images on Commons ten days ago but the locations are not shown yet. In the past it took only minutes to update the database. Sv1xv (talk) 08:48, 27 April 2009 (UTC)

Normally only minutes, following toolserver replication lag. Recent geocoding changes however shows that the last update to the db was on 18 April, and when I check my various mailboxes, turns out I have 12000 warning mails from the update tool because of some lockup problem. It's updating again now, but perhaps I'll have to rethink the error recovery there... Thanks for the note! --Para (talk) 10:26, 27 April 2009 (UTC)
Hmm, it seems the system uploaded a few files and then crashed again. Sv1xv (talk) 13:47, 27 April 2009 (UTC)

Free sources should be given preference

I am of the strong view, that this page should strongly recomend the use of 'free' data sources , over propiteary ones like Google or Yahoo.

Opinions? Sfan00 IMG (talk) 19:52, 19 May 2009 (UTC)

Perhaps we need a page comparing the virtues of the various alternatives. Meanwhile could you be more specific? For my urban pictures I use Windows Live because of its smooth integration with the EXIF editor of the free Vista Pro Photo Tools 2. Where Microsoft leaves doubt, I use Google Maps for its Street Views feature and mostly accurate street addresses. On computers that can't see MSN or Google I use Yahoo Maps; plenty better than nothing usually. None of them cost me money, though of course that's not exactly what you mean by 'free'. Which mapping sites work better for your various purposes, and which ones are likely to serve less experienced geoeditors who need advice on this matter? Jim.henderson (talk) 20:09, 19 May 2009 (UTC)
Opinion. I am proud that I have erased all Redmondware (XP-Vista) from from all of my computers, but when it comes to mass geotagging the critical issue is efficiency and speed. A bookmarklet that refers to the ubiquitous search engine does the job. I am not going to fight a tsunami in a hair shirt, or fight a tank with bows and arrows The issue is simple. Google maps- returns information. Information cannot be copyrighted. Firefox on Linux processes it for me- and from the point it hits the computer I use Tickerty-boo software. Our mission here is to provide universal access to images- restricting that access by not providing information (a geotag) is a sign of failure. Not promoting the quickest and most accurate tool to do the job- so others can assist in the revolution is a counterrevolutionary act. It is also an act of intellectual arrogance suggesting that we understand higher morals but our readers don't. Until we are denied the use of the tool, by government or corporation we should promote it. --ClemRutter (talk) 08:33, 20 May 2009 (UTC)

Tagger in camera

Seems I wasn't clear in my recent addition to the article. Someone misconstrued my problem as time misalignment between geotracker and camera, and added a well written bit about getting them properly synchronized. Very good for those with separate camera and tracker, but not relevant to me. My GPS is inside the Nikon P6000 camera and fully integrated with it, so there's no such thing as mistaking the time. No, the problem is, I'm a hit and run photographer. I take a pic, hop back on my bicycle, pedal along a few minutes, see another target, snap it, and continue.

Reception being spotty in urban areas, usually the recorded position is a few minutes stale, which even with my feeble pedalling may often be as much as a kilometer or rarely even a mile. There is no consitency in how stale the position information is. The only cure I have found is direct corrections of the recorded coordinates, and the best tool I have tried is the free download Microsoft Pro Photo Tools 2 program. Last night I found out about Geosetter, and a site about free geotagging programs. Must study those and eventually write a good review of the problem and cures.

No big hurry to do a proper writeup about geotag corrections, since it seems a geotagging camera like mine is still pretty rare, but eventually the supplied advice about synchronizing two devices should be supplemented with advice on adjusting stale coordinates. Jim.henderson (talk) 09:09, 3 June 2009 (UTC)

Moving geocoded images from other projects

I just noticed following text in description of image resently moved by CommonsHelper:

<!-- Templates "Template:Coord/dec2dms", "Template:Coord/dec2dms/dms", "Template:Coord/display/inline,title", "Template:Coord/input/dec", "Template:Coord/link", "Template:Coord/negzeropad", "Template:Coord/prec dec", "Template:Copy to Wikimedia Commons", "Template:File other", "Template:Main other", "Template:Max", "Template:Movetocommons", "Template:Precision/tz", "Template:Precision/tz/1", "Template:Precision1" were used in the original description page as well , but do not appear to exist on commons. -->

The uploaded image did not have geotagging and I can only assume that the original did. Does anybody know how does process of template conversion works and is there anything we can do to keep existing geocodding tags. --Jarekt (talk) 17:43, 5 June 2009 (UTC)

Geocoding tool addition to Special:Gadgets

To simplify viewing a given category on a map, I'd like to add a new option to Special:Gadgets. It would allow any user to enable an additional tab on category pages by choosing it on Special:Preferences ("Gadgets" tab).

The link would work similar to the one on Category:Sculptures in Canberra through {{GeoGroupTemplate}}.

Detailed additions are below. They were partially tested and worked (not sure if it will work on every other browser, but it should be similar to the way the tineye link addition works).

MediaWiki:Gadget-Gmaps.js
//* based on [[MediaWiki:Gadget-Tineye.js]]
importScript('MediaWiki:Extra-tabs.js');
 
addOnloadHook( function() {
 if (wgNamespaceNumber != 14) return;
 if( global_append_tab ) global_append_tab('http://maps.google.com/maps?q=http%3A%2F%2Ftoolserver.org%2F%7Epara%2Fcgi-bin%2Fkmlexport%3Fproject%3DCommons%26article%3DCategory%253A' + encodeURIComponent (wgTitle.split(" ").join("_")), 'Map', 'ca-mapg');
});
MediaWiki:Gadget-Gmaps

''View cat on Google maps'': gives a quick link to view geocoded images in a given category on Google map.

MediaWiki:Gadgets-definition

Gmaps|Gmaps.js

I'd be glad to have your thoughts on this. I left a note also on MediaWiki_talk:Gadgets-definition. -- User:Docu 15:25, 16 June 2009 (UTC)

I just started using the gadget, and this would be used by me for sure. HBR (talk) 22:17, 16 June 2009 (UTC)
I like this idea, but I have a few comments. I think this tool should work with galleries and categories. Also one should be able to add number of recursive levels allowed. For example I would like to see the map of Warsaw Uprising images but most of them are in some narrow categories. --Jarekt (talk) 20:37, 17 June 2009 (UTC)
  • Galleries probably don't work with the current tool. We could define another link/gadget for recursive levels, but the way outlined here currently doesn't seem to work for commons. -- User:Docu June 18, 2009 (revised comment
People on the pedias have been wondering how to set the recursion level, too. Here it might be easier since with gadgets we'll have to use Javascript anyway. With the unpredictable unlimited recursion, it takes about 10 seconds to generate a list of Category:Warsaw Uprising with 200+ geocoded images. It happens to work with that category as it's not so deep, but more general categories take too long and things start timing out. Galleries do work, but they need a special parameter in the tool link. Usually the tool is used to map coordinates written directly on a Wikipedia page, but here we need to map pages linked from the given page. With the Warszawa gallery it would currently be three measly images. Thinking of the limits, that's still fine, as mapping services stop at around 200 images (check with Google or "Bing").
Another question is where will this actually be useful? Someone asked me a map of all sundial images a while ago. Okay. I could see it used to map areas that don't yet have images of a given topic, for people to fill in the blank spots. But what types of requests would really be common then, and how likely are they to hit the limits? --Para (talk) 14:50, 19 June 2009 (UTC)
We could have separate pre-defined links just for a recursion level of 1 or 2. The gallery option could be integrated into the above. -- User:Docu 15:54, 19 June 2009 (UTC)
Concerning use, one type of use which I have thought of for a long time is the ability to make autogenerated "distribution" maps af living organisms, which has been geocoded. Interesting at the species level, genus level and higher taxa. Useful also for studying regional variances in the way living species look. Actually I was wondering if some kind of distribution link could be built into the taxonavigation templates practically embedding {{GeoGroupTemplate}}. Genus level taxonav templates should then have a recursion limit including the species and so on. That would be kinda cool as then users would not have to specifically enable a gadget to have this distribution map possibility. --Slaunger (talk) 15:59, 19 June 2009 (UTC)
If the template is already on categories, it should be fairly easy to do. Which templates do you have in mind? -- User:Docu 16:37, 19 June 2009 (UTC)
I have already contacted Rocket000 as he is the template coder. He is already on it, but thanks. --Slaunger (talk) 16:38, 19 June 2009 (UTC)
Looking at Template:Taxonavigation it might not be as easy as I thought, if one wants varying recursion. To start, one could just at {{GeoGroupTemplate}} to this template. In the meantime, I will ask to add the above to gadgets. -- User:Docu (talk) at 09:48, 20 June 2009 (UTC)

It should be available on Special:Preferences now. -- User:Docu (talk) at 19:55, 26 June 2009 (UTC)

I've enabled it. Works like a charm for me (FF on Vista). To quote from "The Wrong Trousers":

It's a valuable addition to our modern life style!

--Slaunger (talk) 20:10, 26 June 2009 (UTC)
Docu; this is very cool! It works with Camino 1.5 running under Mac OS 10.5.7 with Category:Ribes sanguineum but not with Category:Ribes (too many geocoded images?). With Safari 3.2.3, I got a map of the relevant region, but no icons. Walter Siegmund (talk) 00:59, 27 June 2009 (UTC)
Thanks for your feedback. Ribes has just four geocoded images [3], Ribes sanguineum 15 [4]. Sometimes the tool times out. If you call it with [5], timeout is less likely. For Ribes, I get just one result. This is likely due to filtering when there are several images with (nearly) identical coordinates. Para would know more precisely. -- User:Docu (talk) at 06:13, 27 June 2009 (UTC)
This cool new toy has great potential as a tool of geography. The main thing holding it back is the paucity of geotagged pictures; most categories that I look at have none and many including Category:New York City Subway stations in the Bronx have only a few. Category:The Oranges, New Jersey has mostly tagged pictures, but only because I bicycled through there a month ago with my geotagging camera. When small but heavily photographed places like Category:Rockefeller Center have many tagged photos, the lack of headings will become a more glaring shortcoming. Anyway with a bit of development and many more coded pix this tool will become useful in ways we (or I, anyway) have difficulty imagining now. Jim.henderson (talk) 15:47, 28 June 2009 (UTC)
That's right, Wikipedians requested removal of duplicates, and those 4 geocoded Ribes images are all at the same coordinates. I just dropped that feature from category lookup, since over-categorisation shouldn't happen anyway. Google Maps doesn't make the 4 overlapping markers any different so it's not much good, but at least they're on the list now. --Para (talk) 15:53, 28 June 2009 (UTC)

In response to a DR I replaced all occurences of {{Location dm}} wiht {{Location}} and deleted it. The template was created by mistake (with a fixed location) and was the cause of many problems because it transcluded itself. Sv1xv (talk) 15:25, 29 June 2009 (UTC)

Thanks for cleaning it up. --Jarekt (talk) 15:39, 29 June 2009 (UTC)

Step 7a (optional)

If one feels like writing one, maybe this intro could include an (optional) step about adding geocoding. Obviously, it's still fun to add geocoding to someone else's pictures. -- User:Docu at 09:53, 10 July 2009 (UTC)

✓ Done --Jarekt (talk) 12:46, 10 July 2009 (UTC)

Good. Thanks! -- User:Docu at 14:14, 10 July 2009 (UTC)
Should all the optional steps be in an optional section? Jim.henderson (talk) 00:11, 12 July 2009 (UTC)

Geocoding tools (Special:Gadgets)

To simplify access to some of the geocoding tools, I'd like to add the following to Special:Gadgets:

MediaWiki:Gadget-Geotoolbox.js (new)
//* based on [[MediaWiki:Gadget-WhatIsThat.js]]

addLoadEvent(function() {
    addPortletLink('p-tb', 'http://toolserver.org/~para/GeoCommons/recentchanges.php', 'Geocoding Recent Changes', '', 'Recent geocoding additions');
    addPortletLink('p-tb', 'http://toolserver.org/~dispenser/cgi-bin/geosearch.py?site%3Dcommons', 'Geocoding Search', '', 'Search through coordinates in external links table');
    addPortletLink('p-tb', 'http://toolserver.org/~dispenser/view/File_viewer#log:coord-commonswiki.log', 'Geocoding Daily Log', 'Daily geocoding error log');
});
MediaWiki:Gadget-Geotoolbox (new)

''Geocoding tools'': adds three [[Commons:Geocoding|geocoding]] links to the toolbox: [[tools:~para/GeoCommons/recentchanges.php|recent changes]], [[tools:~dispenser/view/File_viewer#log:coord-commonswiki.log|daily error log]], [[tools:~dispenser/cgi-bin/geosearch.py?site=commons|search]]

MediaWiki:Gadgets-definition (to add)

Geotoolbox|Geotoolbox.js

Category tool addition: Geocoding to-do
MediaWiki:Gadget-Geocodecattodo.js
//* based on [[MediaWiki:Gadget-Gmaps.js]] as revised by [[User:Lupo]]
if (wgNamespaceNumber == 14) {
 
importScript ('MediaWiki:Extra-tabs.js');
 
addOnloadHook( function() {
 if( global_append_tab ) global_append_tab('http://toolserver.org/~para/GeoCommons/geocodingtodo.php?category=' + encodeURIComponent (wgTitle.split(" ").join("_")), 'Geocoding todo', 'ca-geocodecattodo');
});
 
} // end if
MediaWiki:Gadget-Geocodecattodo

''Not geocoded images in category'': adds a tab to the category linking to the [[Tools:~para/GeoCommons/geocodingtodo.php|tool]] allowing to view images that are not [[Commons:Geocoding|geocoded]]

MediaWiki:Gadgets-definition (to add)

Geocodecattodo|Geocodecattodo.js

The first one adds three links to the toolbox on the left side of the interface. The second one links the "geocoding to do" tool from category pages. -- User:Docu (talk) at 11:50, 6 July 2009 (UTC)

Given that there were no objections, I maded a {{Editprotect}} request on MediaWiki_talk:Gadgets-definition. -- User:Docu at 09:37, 14 July 2009 (UTC)
✓ Done Huib talk 18:11, 14 July 2009 (UTC)

According to the above request, the bot would be adding {{Object location}} to images. -- User:Docu at 19:25, 13 July 2009 (UTC)


What happened July 6 ?

Looks like Commons:Geocoding was really popular that day, at least according to http://stats.grok.se/commons.m/200907/Commons%3AGeocoding -- User:Docu at 19:25, 13 July 2009 (UTC)

It might be a coincidence that on that day I changed (by bot and some by hand) to {{Location}} files using: {{coord}}, {{Coordinate}} {{Geolinks-US-hoodscale}}, {{Location d}}, {{Location dec US}}, {{Location dec min}}, {{Location dms}}, {{Map}} and {{Map-LatLong}}. See [6]. I do it occasionally because apparently some users (mostly very new) often add geocoding templates in the format used by their wiki. For example see German response to Commons:Deletion requests/Template:Coordinate. --Jarekt (talk) 21:17, 13 July 2009 (UTC)
I redirected {{Coordinate}} to {{Location}} and replaced its documentation with an appropriate message. I also replaced it on four image files. However it is still used in User space. Should I protect the template redirect page? Sv1xv (talk) 03:43, 14 July 2009 (UTC)
Problem with redirecting {{Coordinate}} to {{Location}} is that they use very and totally different and incompatible formats to encode the same information. Can you undo it? --Jarekt (talk) 03:57, 14 July 2009 (UTC)
I can do it immediately, but how can we stop people using it? Should I delete it completely? Sv1xv (talk) 03:58, 14 July 2009 (UTC)
I doubt that the conversion of a few templates would generate that much traffic (unless you converted >10,000) and your edit summary didn't even link the page.
In general, I think it's a good approach to convert them by bot once in a while. Geocoding isn't already simple to start with. Redirecting the template is likely to create invalid values. We could just add a notice to the other template indicating that a bot is eventually going to convert them to, e.g. {{Location}}. -- User:Docu at 09:37, 14 July 2009 (UTC)
I converted few hundred not thousands, so it might not be it. As for how to stop people from using retired templates - I have no idea, I tried deleting them but that does not stop anybody from using non-existing templates just look at dozens of deleted {{coord}}, {{Location d}} and {{Location dms}} that accumulated since last week when I changed them all. All uploaded by new Commons users with empty talk pages and no edits in Commons. I suspect that they use some upload or transfer tools that is out of date. I will try to ask some of them how they did it. But in the mean time whenever there is enough images to run a bot on I fire it of. --Jarekt (talk) 12:59, 14 July 2009 (UTC)

I removed all additional templates used internally by {{Coordinate}} from image pages and deleted them. When Category:Coordinate template shows as empty, I shall deleted it as well. Sv1xv (talk) 07:23, 20 July 2009 (UTC)

ResolvedI emptied and deleted Category:Coordinate template. Cleanup is complete. Sv1xv (talk) 07:26, 20 July 2009 (UTC)
File:Kaiservilla vorderansicht.jpg is still using it. As Jarekt mentions, even deletion doesn't seem to prevent people from using it. Possibly with the new map/semantic forms features, we get another (possibly better) way to specify coordinates, but maybe it wont change. -- User:Docu at 07:43, 20 July 2009 (UTC)
This file was uploaded yesterday. As it is a recent image upload, let the uploader fix the problem. Sv1xv (talk) 07:54, 20 July 2009 (UTC)
I doubt he will do anything about it. I wonder if we should use a similar message as on {{Coordinate}} for some of the other templates listed at Commons:Protected_against_recreation#Geocoding_templates_that_break_machine_readability (especially coord). Does anybody know which machine this would break? BTW currently there are 26 files at Special:WhatLinksHere/Template:Coord. -- User:Docu at 09:13, 20 July 2009 (UTC)
Regarding {{Coord}}, it could be redirected to {{Object location}}. Alternatively I can change it by hand on all pages (not too difficult). Sv1xv (talk) 09:19, 20 July 2009 (UTC)
Update: I changed all transcluded templates with {{Object location}}. Sv1xv (talk) 09:37, 20 July 2009 (UTC)

(unindent) If it's redirected, I'm not sure if new entries would show up correctly on tools:~para/GeoCommons/recentchanges.php (en:Template:coord has a series of possible input formats). BTW the 26 are just from two weeks (with one week uploads only partially working). I changed {{Coordinate}} to:

{{Coordinate}} is deprecated on Commons, please use instead:

Camera location is preferred.

The advantage of showing a similar message to uploaders using {{Coord}} is that they "might" consider picking themselves. -- User:Docu at 09:40, 20 July 2009 (UTC), edited 09:45, 20 July 2009 (UTC)

I created {{Coord}} with a similar error message and protected it. Sv1xv (talk) 10:10, 20 July 2009 (UTC)
Thanks. I just noticed that tools:~para/GeoCommons/recentchanges.php is broken. -- User:Docu at 10:18, 20 July 2009 (UTC)
Anyway, I also protected {{Coordinate}}, as there is always a chance that a frustated user copies here the template from en-wiki. If you want to edit it, just ask me to unprotect it. Sv1xv (talk) 10:24, 20 July 2009 (UTC)
No need to edit it. Recent changes is back BTW. -- User:Docu at 10:29, 20 July 2009 (UTC)

Pardon my ignorance :)

OK - I guess I'm not new to this but I am looking at things differently now. I've been geotagging my images for a while now but while browsing a few sites (as you do) I came across geosetter for windows ([7]). I also came across MS's tool for photographers (didn't know they did anything useful....:)). Can we import geo data from EXIF or am I waay out here? Thanks --Herby talk thyme 12:38, 22 July 2009 (UTC)

Excellent stuff. My camera geotags EXIF internally but the location is usually stale because I shoot on the run, so I use Microsoft Pro Photo Tools 2 to adjust before uploading. Often I adjust the Commons location later as well. Jim.henderson (talk) 13:38, 22 July 2009 (UTC)
DschwenBot converts EXIF to {{Location}} (#Automatic procedures). -- User:Docu at 13:57, 22 July 2009 (UTC)

Templates cleanup - current status

Sv1xv (talk) 18:14, 25 July 2009 (UTC)

I suspect that it is not users who still upload new files using them but some tools which help with moving images to Commons. A lot of those users seems very new and would not know about templates deleted before they first showed up at Commons. I also agree that {{Coor}} family cannot be completely replaced I think those are useful templates especially in galleries, categories, etc. I also see them as better alternative to {{Object location}} templates since you can use them in a text explaining which object you are labeling (in case it is not obvious), but I suspect that in most cases, in File: namespace, they can be replaced with camera {{Location}}. Also I do not think we need 3-4 of them. --Jarekt (talk) 03:51, 26 July 2009 (UTC)

I just noticed edit supposedly done by AddCoordinates.js which added {{Location dec}} with incorrect parameters: {{location dec|43.775899074524766|N|0.4284353254479356|W}}. I am unfamiliar with AddCoordinates.js, but can someone fix it? --Jarekt (talk) 14:41, 29 July 2009 (UTC)

I fixed it. {{Location dec}} does not require N and W, it uses + and - to denote N/E and S/W. Sv1xv (talk) 15:39, 29 July 2009 (UTC)
Thanks for fixing the image, but I meant fixing AddCoordinates.js which possibly creates {{Location dec}} templates with incorrect format. --Jarekt (talk) 15:54, 29 July 2009 (UTC)
The script doesn't format the template, but adds it to the file description page. It could be used from any tool. Multichill uses it from his coordinates tool. The tool seems to provide a series of different formats including some that aren't compatible. -- User:Docu at 17:29, 29 July 2009 (UTC)
Is there a way to find which tool created incorrectly formatted {{Location dec}} template?--Jarekt (talk) 13:12, 31 July 2009 (UTC)

CommonsHelper dropping location template parameters

I just filed a bug report related to CommonsHelper dropping all parameters in {{Location}} template during transfer from En Wiki. See before and after views.--Jarekt (talk) 13:01, 4 August 2009 (UTC)

According to http://lists.wikimedia.org/pipermail/commons-l/2009-August/004973.html
a new version is being developed. -- User:Docu at 18:16, 4 August 2009 (UTC)

Proximityrama

A link to tools:~para/GeoCommons/proximityrama is now on {{Object location}} and, if used on categories, on {{Location}}.

As most categories are made by object location rather than camera location, one should use {{Object location}} rather than {{Location}} on categories, but {{Location}} is frequently used there.

To see how it works, try the link on Equestrian statue or Arc de Triomphe. As images are not displayed for all categories, I was wondering if I should remove the link again. -- User:Docu at 17:18, 27 August 2009 (UTC), edited 18:08, 27 August 2009 (UTC)

I like it. I think it could be also useful for files with {{Location}} template, since many photos are of nearby objects. --Jarekt (talk) 17:54, 27 August 2009 (UTC)
To some extent, it works only if the headings are set correctly and point towards the object. To view nearby images directly, tools:~dispenser/cgi-bin/locateCoord.py could be used, but currently it doesn't output thumbnails. -- User:Docu at 18:08, 27 August 2009 (UTC)

"Geocoding todo" and User pages

User pages, currently include tabs for:

  1. gallery
  2. orphans
  3. untagged

Shall we add another tab with "geocoding todo" linking to http://toolserver.org/~para/GeoCommons/geocodingtodo.php?user= ?

This would be similar to the tab available for categories through Special:Preferences, but available to all users. -- User:Docu at 12:54, 25 July 2009 (UTC)

Sure, why not. -mattbuck (Talk) 17:33, 25 July 2009 (UTC)

To answer Lar's question on VP ("Could you summarise what is being asked for?") and attempt to summarize the already short request: "Shall we add the link to the interface?" -- User:Docu at 18:50, 25 July 2009 (UTC)

I think this tab has "odd" name and gives me feeling of only a part of specific wikiproject. In consequence, A gadget would be better than common script. Kwj2772 (msg) 15:00, 27 July 2009 (UTC)
Geocoding isn't really part of a specific WikiProject, but rather one of the elements of adding full descriptions/categories to images contributed to Commons. The link is mainly of use for those that don't do this regularly and a gadget would somewhat defeat that point.
I agree that the name isn't ideal, but there wasn't another one that came to my mind. Can you suggest a better name? -- User:Docu at 16:07, 27 July 2009 (UTC)

Let me get the straight. You're asking to add a tab called "Geocoding todo" (or whatever) to all user pages so they can see all their non-geocoded images and potentially geocode them? Well, I just looked at the first 500 files I uploaded and none of them can be geocoded (the few photographs are from third-party sites which did not give any coordinates). I'm not sure how relevant this is to a large amount of our files. Moreover, don't most people who geocode already do? I doubt a new tab will make others start. I'm thinking a gadget is the way to go since this seems pretty specialized. Maybe added to Geocoding tools. Rocket000 (talk) 06:05, 31 July 2009 (UTC)

"not geocoded" might be better. Let me work through your contribs and you will see it makes much more sense. You got too many graphics ;). -- User:Docu at 07:13, 31 July 2009 (UTC)
If you look at your contributions, you will see easily which ones could be geocoded. There are several of the more recent ones. For all the others, you have two options: ignore them or add Category:Location not applicable. The later solution removes them from the list, but by just looking at the page, you will see which ones can't be done.
Even if you upload images of someone else, you may still want to geocode them. Obviously it's easier to do this with one's own images. The link would give everyone a quick way to see what still could be done. User:File Upload Bot (Magnus Manske) will have the link too, but it's unlikely to be helpful there (as is User talk:File Upload Bot (Magnus Manske) etc.), but we wouldn't want to change it just for that user. -- User:Docu at 09:49, 31 July 2009 (UTC)
I don't see which ones can be geocoded. You mean ones that have a general location like "Homerville, Georgia, US" (the most specific I found)? I only ever geocoded files where I had coordinates from the camera or for landmarks which I can look up. Is it normal to locate to such broad areas? What is the standard threshold? Cities are specific enough? What about a U.S. state or small country? Usually that's all I get. Rocket000 (talk) 17:56, 31 July 2009 (UTC)

The general idea is to code the camera location (with {{Location}} or {{Location dec}}) with a precision of a couple of meters (ideally). This is mainly interesting (and possible) for outdoor views. After skipping all the graphics, I came to the following ones:

I didn't try the Bergen ones, but for the other ones I think I was able to find a more or less accurate camera location and heading. For one, I limited myself to object location ({{Object location}}). I didn't add the coordinates to the images yet, so you could have a try too. Even after geocoding articles at Wikipedia, at the beginning, it's quite a learning curve. -- User:Docu at 03:43, 1 August 2009 (UTC)

To reduce the output on [8], I added Location not applicable to some of the images. File:Whitevale Bluevale flats.jpg has coordinates, but in the wrong format. There are few others that could be geocoded with some research:
I might give it a try later. -- User:Docu at 06:19, 1 August 2009 (UTC)
Wow! Thank you. (And thanks for making my watchlist explode! ;) I guess I have a lot to learn. After this little demonstration, I have no objections to such a tab. Rocket000 (talk) 15:25, 1 August 2009 (UTC)
You are welcome. Thanks for your support. BTW I figured out one of the two Bergen images and reduced your list a bit more. -- User:Docu at 08:29, 3 August 2009 (UTC)
So I just now clicked on my Untagged tab and got "Notice: Undefined offset: 4 in /home/daniel/public_html/WikiSense-live/common/WikiSense.php on line 1017" and no pix. Any idea what's broken? Jim.henderson (talk) 20:10, 28 August 2009 (UTC)
"untagged" is the link to the tool that checks for images without categories. "not geocoding" isn't activated. The necessary request would be at MediaWiki_talk:Extra-tabs.js#Tab_for_user_pages_(Geocoding), but I left it for now, as there didn't seem to be a lot of interest. -- User:Docu at 12:47, 29 August 2009 (UTC)
I thought this was added. I see in the gadget menu three geocoding things and assumed one must be for this (didn't pay too close attention). We have "Geocoding tools", "View category on Google maps", and "Not geocoded images in category". Surely this can be combined with one of these.. Actually, do we even need to split these up? I would think that anyone interested in geocoding would like all of these, right? Maybe have two, one for readers (that have no intention of doing any geocoding themselves but are interested in seeing things place on a map), and one with the remaining tools for geocoders? Rocket000 (talk) 02:20, 30 August 2009 (UTC)
This proposal was to add the link directly as Extra-tab, rather than as a gadget (see my explanation above why).
We could add a geocoding section to preferences. The advantage of keeping them separate is that they are easier to re-use in other projects. tools:~para/GeoCommons/geocodingtodo.php works only for commons, but the others can be of use to all projects. For readers, we could offer other maps to choose from, but there doesn't seem to be any demand. -- User:Docu at 11:32, 31 August 2009 (UTC)
I just now clicked all three to "on" and got the tab in Category:Harlem that shows ungeotagged pix. It works nicely but there is no additional tab on my userpage. So, apparently I shall have to hit the request page also. Don't have time right now to check the results carefully before leaving, so it will wait to tomorrow.
Ah. My mistake. Yes, the clickbox to show my ungeotagged pix is indeed showing on the geocoding menu. Perhaps the cat in Google Maps thing is also waiting for me to take a more alert look. Jim.henderson (talk) 03:13, 30 August 2009 (UTC)

ImageAnnotator#Geocoding with annotations

Please see Help_talk:Gadget-ImageAnnotator#Geocoding_with_annotations. -- User:Docu at 06:33, 10 September 2009 (UTC)

Thanks for providing the link Docu, but it might be better to discuss the geocoding aspect of this proposal here. I assume that we will be able to create annotations which provide geocoding anchors to few specific locations of the image. As I mentioned, I imagine that gadgets can be written which would be able to automatically create Geocoding overlays or Panoramas based on few such anchors (3 ?). If possible that might greatly simplify creation of such overlays and allow wider use of them. Is that possible to do? --Jarekt (talk) 13:19, 10 September 2009 (UTC)
Care must be taken not to disrupt the coordinate extraction process. If an image suddenly contains dozens of coordinates the resulting URLs to the geo-hack page (URLS from the externallinks table are used to extract coordinates) must distinguish camera locations and object locations. I added such distinction to the ObjectLocation template. And it will have to be added to teh coor family as well. --Dschwen (talk) 13:26, 10 September 2009 (UTC)
The location templates do not work well for this purpose so so far I used {{Coor d}} template. However I do not like it much since it has different syntax from {{Location}}. An example can be seen in File:Bundesarchiv Bild 183-S53511, Warschau, Weichsel, Brände.jpg where I added 3 tiny annotations with coordinates using that template. Does this template cause any problems? --Jarekt (talk) 13:46, 10 September 2009 (UTC)
I just discovered (or rediscovered?) {{Location-Panorama}}. I will try to use that. For panoramas, the current tools don't seem ideal. Even annotated, it's hard to set the screen to see image and notes in a sufficiently large scale. I tried to use an annotation to mark "N" in 360° degree panorama. Maybe coordinates can give even better results. -- User:Docu at 04:14, 11 September 2009 (UTC)

Headingless Google

Is it only my computer that changed yesterday, or do others see that the Google roundel for geotagged Wikipix has become less informative? For example in this map the roundels are squashed into oblacity and the arrows all point north even though for the majority the camera was facing some other direction. Has there been a change at Wikimedia's end or Google's? Jim.henderson (talk) 16:35, 4 September 2009 (UTC)

The content on the map you are pointing to is provided by a toolserverscript written by User:Para. GoogleMaps is merely a vehicle for visualizing it and providing a background. While it may be a bug/API-change at GoogleMaps, I'd talk to Para first. --Dschwen (talk) 16:50, 4 September 2009 (UTC)
Google Maps seems to have changed the way they identify themselves in requests to the toolserver. That matters because Google Maps supports only a subset of the KML standard, so it needs to be served simplified content. I fixed the detection now and it looks the way it used to again. --Para (talk) 17:53, 4 September 2009 (UTC)
Thanks; I shan't look up KML, however. Even nicer if the Wikidots on the map of a category could also have heading arrows, but I imagine that's someone else's department. Jim.henderson (talk) 21:23, 4 September 2009 (UTC)
Oh! Now I'm seeing arrows on maps of categories! Very pleasant and it has led me to correct some headings. Thank you, somebody. Jim.henderson (talk) 00:02, 13 September 2009 (UTC)

It was requested here to delete this template. As I don't want to screw anything up, I just wanted to make sure if it's used anywhere or planned to be used anywhere? Please let me know. Thank you. --The Evil IP address (talk) 09:22, 13 September 2009 (UTC)

Category maps

Yes, the Google map showing all the geotagged pictures of a category is quite pleasant. No, I don't mind clicking three times to get all the various map tools. I found two little bugs, or more likely one with two manifestations:

  1. When there's no tagged pic in the cat, instead of saying so, Google gives us a blank world map. It perplexed me for half a minute.
  2. When there is only one tagged pic, Google zooms in to the max and then usually says no, there's no aerial photo at this scale. The system ought to be bright enough to realize there's no aerial view, and zoom out to whatever scale is possible. It's another snag that indicates this useful tool is still too quirky for general release.

Also there's no pointy roundel saying which way the camera is looking. Not a bug but rather a wish. Oh, and another wish is that some other template besides the "location" one be used in category descriptions, since cats are usually about an object, for example Category:Newark Bay Bridge, not a viewpoint, so usually must code the object instead of the POV. These little bugs and littler wishes haven't kept me from going back and adding tags to some of my old pix made with the old non geotagging camera, but I hope someone's working on them. Jim.henderson (talk) 04:56, 2 September 2009 (UTC)

These sound like they're Google's problems in presenting KML data, and should be reported to them as bugs. However...
  1. I have now added a 0 results note to the pane that usually shows a list of placemarks. Maybe Google should show some meta-information about the data it's asked to show, or maybe they don't want to poke into people's data. I'm reluctant to add a "This page is intentionally empty" type notice to the actual map area, because it would have to be a placemark or a persistent image overlay, and in some applications is maybe difficult to differentiate from real data. Maybe the newly added blue notice on the side pane is noticable enough?
  2. Google helpfully chooses a zoom level that shows all the placemarks in the given data file. The priority then seems to be on showing the placemarks, even when the service doesn't have any imagery of the area. A couple of months ago Google Maps introduced a feature to find the maximum zoom available for a location[9], but it seems they're not fully using it themselves. Bug or feature? It would technically be possible to work around it on the toolserver side by calculating the zoom level it takes to show all the placemarks, and then take the minimum between that and Google's best zoom level at the center of the area. It just sounds like a lot of work and I'm not keen on reinventing all that when at Google's end it'd be a quick and tiny fix.
You noticed the roundels being fixed already. On adding coordinates to galleries and categories, the advice has been to use {{Object location}}. I'd much rather see a Javascript solution do that though, by getting the information from Wikipedias when availableexample and then showing it as if the template had been used. Since the object location data saved on Commons is not exposed on any maps the same way Wikipedia data is, it's less likely to be corrected when it's erroneous, and we'll run into problems with toolsexample that try to use it. --Para (talk) 12:08, 14 September 2009 (UTC)
So I learned about the object location template and, while looking for something else, encountered File:Greenwich town hall.jpg with two camera locations, not one, both pointing north. Obviously this was a place for my newfound knowledge, so I converted the southern one to object form with "heading:?" and put a south arrow on the other. The south arrow shows up properly on both the category map and the local one, but somehow the object template failed to kill the north arrow on its roundel. So, something else is happening here that I don't understand. My own preference would be that the object template produce not a red and blue roundel at all, but a spike, thumbtack or other entirely different symbol.
Blue notice on the side pane? Drat; earlier today I looked at a few blank cat maps but didn't notice the, umm, notice. I'll have to look again later.
I figured the dual locations on one picture would solve the excess zoom problem but this case, with camera and object only a few tens of yards apart, still showed too much zoom. I'll have to experiment with some other picture that's the sole geotagged one in its cat, and see if dual tags have the desired effect for a shot across a river or other substantial distance. My aging mind has developed stiffness against new theory, for example KML coding, but remains flexible enough to accept trial and error. Anyway the whole complex of geotagging ideas present lovely new toys and the feeling that I'm accomplishing something useful with them, for which I offer gratitude. Jim.henderson (talk) 02:20, 16 September 2009 (UTC)
Bugs, that's what. :) I fixed some on both Commons and in the tool, and made the unknown headings and object location icons work the way you wished. Thanks for all the observations and ideas, new perspectives are always welcome. There have been discussions before on this page about the default zoom the location templates should link to, and a pair of camera and object locations provides a good bounding box to limit that view. It works for categories now (when imagery is available), will have to find a way for the links from images too... --Para (talk) 11:04, 16 September 2009 (UTC)
Hey, it probably wouldn't hurt to use this opportunity to plug a link to this tool. It might just be me, but I've just been looking for a few minutes and haven't found it (is it KML Export on you ts page, para? Is there an interface for it? Or to I have to construct a url by hand?). --Dschwen (talk) 14:22, 16 September 2009 (UTC)
Huh, based on Docu's topic above and various other pages, I thought it was enabled for everyone. But looks like it's still just the "View category on Google maps" gadget, which creates a new "map" tab on all category pages (to call KML export yep, no there's no other interface). I can't think of a really cool link to give, so here's a view of a lonely category with an object location and a busy view with an outlier. This category mapping thing has shown to be useful with spotting errors in geocoding both on Wikipedia and here, when some items are way further from the rest of the group than they should be. --Para (talk) 15:03, 16 September 2009 (UTC)
That gadget has.. ..room for improvement, such as an interface to specify category tree recursion level, which your tool seems to support. --Dschwen (talk) 16:32, 16 September 2009 (UTC)
Oh, good; my grumbling attracted the attention of smart people, and good things happened. The black and white object roundel is very pleasant, prominent without blocking the view of what's under it. I notice the geocoding page is instructing us to use {{coor dms}} for objects, but I've been using {{object location}}. Is one of us wrong? I too have found outliers in category maps, mostly due to object/camera confusion or outright location errors easily adjusted. When you good people figure how to do some kind of neat treatment for totally unlocated categories, for example simply not showing the map tab, and something for the default zoom nuisance, then perhaps the catmap feature will be ready for prime time. That is, ready to be turned on by default rather than let the user find out how to activate it.
Not the "geotags to do" tab, however, which should remain the domain of inveterate map-lovers. Even I haven't actually put it into useful service, because almost all pix in almost all the cats I see are unlocated anyway. Where I am locally familiar, as with Category:Newtown Creek and there's already one located pic, I merely pick the most easterly or southerly or whatever extreme is most extreme from the tagged one. Nail it down as the second tagged pic, and we've got a working catmap. Of course, the second or third nailed location in one category may be the first in another, leading on and on to ever more Googly fun. Jim.henderson (talk) 01:53, 18 September 2009 (UTC)

Map Images

Scanned maps are often quite extended, usually covering a significant range of coordinates. There should be a designation of one point on the image as "the" location for it; the upper left (northwest) corner seems to be most common as in a world_file. In general the information in a world file would be best to include here, but at the very least the extent of the image should also be defined and requested for uploads; it could be encoded as a second location, viz. the lower right (southeast) corner. A separate piece of important information here is the map projection, if it is known.

This suggestion is redundant to Commons:Geocoding/Overlay. --Dschwen (talk) 22:00, 5 October 2009 (UTC)

Geocodding mars

I noticed that File:Nereus crater Mars (Opportunity) 2009-09-19.png is attempting to geocode location on Mars using globe:mars in the optional parameter. Current template work fine when clicking on the coordinates, but do not handle it properly when clicking on Google Maps (I did not try Google Earth). To fix the template we need to alter the link to google maps from "http://maps.google.com/maps?ll=-02.115303,-05.521192" to something like: "http://maps.google.com/mars/#ll=-02.115303,-05.521192". I am not sure if we can parse the optional parameter within the template, but we have to do either that, introduce a new globe parameter to the template, or create new template(s) for other globes. --Jarekt (talk) 15:33, 22 October 2009 (UTC)

Why doesn't use a seperate template for the mars. It's more flexible and we can concentrate to earth. How many pictures do you think that we have from mars with geocoordinates? --Kolossos (talk) 15:58, 22 October 2009 (UTC)
So far I found one, so there is no urgency here but it would be interesting addition to geocodding templates. I will look into creating a new template for other globes (mars, moon, sky, etc) utilizing the current template:location/layout and localization templates. --Jarekt (talk) 17:00, 23 October 2009 (UTC)

Copyright

Using Google Maps to get information should not be recommended. The OpenStreetMap project discourages or prohibits using geodata from Commons because of that: openstreetmap:OpenStreetPhoto#Wikimedia_Commons_photos, openstreetmap:Collaboration_with_Wikipedia#Importing_geodata_from_Wikipedia. --AVRS (talk) 23:00, 26 October 2009 (UTC)

I am under the impression that facts, such as the longitude and latitude of Mt Everest, cannot be copyright, but maybe I am misunderstanding either the law or this application of law. Jim.henderson (talk) 03:49, 27 October 2009 (UTC)
You are right, the fact that a certain object is at some specific geographic coordinates is not copyrightable. Sv1xv (talk) 19:09, 28 October 2009 (UTC)
I am all for closer integration with OpenStreetMap. If someone knows a way to get coordinates out of OpenStreetMap than please share that knowledge at Commons:Geocoding. Not all geocodding is done through google-based tools: some cameras have GPS devices and store GPS locations in EXIF data (see Category:Media with GPS EXIF). --Jarekt (talk) 04:05, 27 October 2009 (UTC)
Sure. My Nikon P6000 does that. But it isn't always correct, so I use Microsoft Pro Photo Tools 2 to check and adjust the EXIF location before upload. MSPPT has a very good slant view but poor precision, so after upload I use Google Earth to recheck and readjust. Last year I didn't have a geotagging camera, so File:Under Hamilton Br Harlem jeh.JPG was untagged until two days ago. Google Earth's terrain exaggeration feature kept me from erroneously putting the tag too low towards the Harlem River. As for a claim that Microsoft or Google own the fact that I was standing where I say I was standing, no, as far as I see this information has no copyright because nobody owns a fact. And yes, I would be pleased if OpenStreetMap and similarly non commercial sites would provide factual locations as conveniently as Microsoft Bing and Yahoo Maps and other commercial services do, but as far as I know they don't. Jim.henderson (talk) 17:27, 28 October 2009 (UTC)
OSM should be fine with Yahoo's aerial imagery. Don't know how its precision compares to others'. --AVRS (talk) 20:11, 28 October 2009 (UTC)
"a way to get coordinates out of (anywhere)" - why would I need to switch, ever? Are they in a different coord system? Would coords from Google give a different location in Openstreet, or vice versa? That said, the goofle interface via http://www.giswiki.org/hjl_geocoding.htm which I use could do with some serious improvement. NVO (talk) 15:23, 5 December 2009
The two linked statements are more or less nonsense. Too bad OSM thinks that way. In principle they are trying to do the right thing, but the potential copyright infringement scenario they construct is implausible (to say the least). Coordinate data in commons does not contain meta information about the map, and it does not even systematically contain points located only on roadways for example. Deriving copyrighted information from the commons pointcloud is simply impossible. For Wikipedia you could argue that Metadata exists, and unlike commons, where camera positions ar coded, wikipedia codes object positions. However the level of detail that is geocoded is not in any way comparable with copyrightable mapping databases such as Google Maps. You'd be hardpressed to find information in the Wikipedia Geocoding dataset that could not easily be obtained using free sources. --Dschwen (talk) 18:08, 28 October 2009 (UTC)
I was sleepy and shouldn't have written the first sentence like that.
As for using a few coordinates vs deriving copyrighted information, see openstreetmap:Copyright Easter Eggs and openstreetmap:Copyright Easter Eggs#Digital_Maps.
--AVRS (talk) 20:11, 28 October 2009 (UTC)
I am fully aware of mapping "eastereggs", and you should realize that they are completely irrelevant at least with respect to commons coordinate extraction. --Dschwen (talk) 15:17, 30 October 2009 (UTC)
I am less famliar, but this concern seems possibly relevant, if anywhere, to people who trust Google enough to simply copy their geographic information. To me this seems exceedingly unwise anyway, due to the great number of plain errors in Google's geography, nevermind whatever imaginary places may heve been inserted for purposes of en:steganography or setting traps. Two days ago for example I was coding my last year's File:Our Lady of Mount Carmel Bayonne.JPG and discovered that Google Earth reversed the locations of the church and its associated school.
Last week it was my File:Univclub54.JPG. Google's aerial views and maps handled this part of 54th Street correctly. However, Google Street View (via GM or GE) does not show this door but rather shows pictures taken a block south on 53d Street. This entire block of 53rd is duplicated as also being 54th; the real 54th is missing. I know 53rd well, having walked it thousands of times since 1963. I tried entering the error in Google Maps' error reporting page but must have messed up because nobody answered or did anything. Too bad they don't have a Wikilike correction mechanism; errors like this are likely to persist a long time. Or maybe that's the idea; the errors are their method of trapping copyists.
Anyway, don't trust Google or other sources so much that you copy their material. I love the detail supplied by Google Street View but errors are extremely common and I often give up tagging a location when my sources behave suspiciously and alternate sources or my own knowledge cannot resolve the question. Most of my photos are from places that I don't know as well as 53rd Street. By comparison, falling into a trap deliberately created by imaginary streets and buildings seems a remote possibility, but you won't fall into the trap anyway if you take Google, Bing, Yahoo and other sources as guidance rather than absolute truth. Jim.henderson (talk) 03:40, 1 November 2009 (UTC)

Minor thing really, but shouldn't it be named "Media with location"? -- User:Docu at 13:32, 15 December 2009 (UTC)

Files can have locations other than the camera location now. --Para (talk) 13:56, 30 December 2009 (UTC)
Yes, but this is rare. -- User:Docu at 17:24, 30 December 2009 (UTC)

Shorter GeoHack URLs

GeoHack URLs are rather long. So I propose the following shortening scheme: drop pagename= as it can be gotten from the referer, make the language= and params= part of the request path using a rewrite rule. The effect is illustrated below:

http://toolserver.org/~geohack/geohack.php?language=de&pagename=PAGENAMEE&params=45_N_123_W_&title=NAME
http://toolserver.org/~geohack/de/45_N_123_W_?title=NAME

Other schemes under consideration are /~geohack/de/PAGENAMEE?params= and /~geohack/wikipedia/de/PARAMS. I am interested in hearing the thoughts from Toolserver users and others who parse the external links table. I will post the rewrite regular expression if we have finalized a scheme. The discussion is centralized at English Wikipedia. --Dispenser (talk) 03:28, 3 January 2010 (UTC)

Removed Locations of some Pics, but Tags are still in Maps

I've recognized, that tagging too many pics to almost the same location pushed away other tags done by other users.
Therefore I've removed the location in most of the pics in Bird Care Centre of Castel Tyrol. But they are still shown in GoogleMaps.
How can I get rid of them?Lord Koxinga (talk) 12:13, 2 January 2010 (UTC)

Please don't do that. The geocoding does not revolve around GoogleMaps. If some images pushed away other tags done by other users that is unfortunate, but the solution is not removing geocoding data! --Dschwen (talk) 17:14, 2 January 2010 (UTC)
True but the importance seems small. If a hundred pictures in a category or page (for example Category:Views from the Tour Eiffel) have all approximately the same camera location, a single tag for each such page or category ought to suffice. Jim.henderson (talk) 19:18, 4 January 2010 (UTC)
Please do not make such assumptions. Fudging around with the data in such a way degrades the quality of the dataset and has a negative impact on the reusability. There already are a few tools which use the location data (and countless more are imaginable). Removing location data from images makes it unnecessarily hard for tool developers to gather the data they need. --Dschwen (talk) 20:11, 4 January 2010 (UTC)
I can copy back the locations out of the history of the respective files. That's no problem for me, since I've documented my changes quite well.
But – before I do any changes – my question: Is that OK or do we get some problems with that?
On the other hand, how can the problem be solved, that some pics with location are shown neither in the list nor as tags in the map anymore?
According this discussion the more pics are geotagged the better, since other tools could use any of them (e.g. wikispecies). Therefore it has to be ensurde that all those pics are shown correcty on the map. --Lord Koxinga (talk) 17:58, 6 January 2010 (UTC)
That problem should be addressed by the application developers. Reverting the changes would be nice. The person to talk to about the GoogleMaps commons layer is User:Para. I could imagine a pushpin in GoogleMaps with a link to "More images at this location" wherever you have too large a cluster of images to properly display on the map. --Dschwen (talk) 18:40, 6 January 2010 (UTC)
Thanks a lot for quick answer. I will proceed as follows:
- Put the affected pics to "inuse"
- Add location and heading again out of my db (no reverting in wikimedia, since additional changes were done in between. --Lord Koxinga (talk) 19:05, 6 January 2010 (UTC)

Highlighting featured/quality images on GeoCommons

I think will be good idea to highlighting featured/quality images on GeoCommons (special icons, color of Commons logo, etc.) I think this especially make sence after latest low-resolution Geograph.uk mass uploads. Panoramio also differentiate size of images based on their popularity. --EugeneZelenko (talk) 15:53, 1 February 2010 (UTC)

Agree - while the Geograph ones give us volume they do not generally give us quality. --Herby talk thyme 16:08, 1 February 2010 (UTC)
Agree - In densely covered area, it would be helpful to look at the best images. Walter Siegmund (talk) 16:53, 1 February 2010 (UTC)
Agree as well. In the (currently hamperd by server switches) Wikiminiatlas I calculate the priority of images to be displayed by feature statuses (FP, PotD, QI etc.) and size. Furthermore <1MP images (as most of geograph images) are displayed smaller. If it were up to me that geograph crap wouldn't be displayed at all... --Dschwen (talk) 17:17, 1 February 2010 (UTC)
"Geograph crap" - ditto :) --Herby talk thyme 17:21, 1 February 2010 (UTC)
Some of the geograph images made me wonder if the zoom link was broken. Today I read that they had a fairly low size limit until recently. Anyways, if one is looking for nice places to take pictures, even thumbnails can help. -- User:Docu at 17:50, 1 February 2010 (UTC)
Leaving aside the quality of the images for a second, the quality of the geocoding isn't fantastic either. Geograph's goal is to get every grid square populated with images, so the geocoding merely indicates which 1km grid square it is in. Its better than nothing of course, but we can be more precise than that.--Nilfanion (talk) 23:07, 1 February 2010 (UTC)

Sunset in Siberia

Featured pictures POTD 28 January 2010

With date and camera location, it should be possible to work out a fairly precise heading for File:Kuznetsk Alatau 3.jpg‎. Still, I didn't get further than "NW" yet. -- User:Docu at 10:44, 24 January 2010 (UTC)

According to [10] Sunset azimuth for that time of year and a city at a slightly more northerly latitude is 257 degrees or 13 degrees south of due West. Since the aimpoint is a bit to the right of the Sun, and the Sun is many minutes away from setting, I estimate the aimpoint as between 260 and 270, or between due West and WbS. Darn it, there must be a sunset calculating Web site somewhere that allows picking an arbitrary location but I don't know where. Jim.henderson (talk) 19:13, 24 January 2010 (UTC)
Thanks for your help. Finally I got to [11] which gives 226° for the sun (if exif time is GMT+5). I will try to find a few links to add to mapsources . -- User:Docu at 17:50, 1 February 2010 (UTC)
Sunrise/sunset azimuths may be found at http://www.rsimons.org/sunmoon/, i.e., 254°. The frame is 44° wide (17mm/22.2mm, convert to degrees). The heading is about 8° north of the sunset point (the solar path is at an angle of 54° to the horizon) or 262°. Walter Siegmund (talk) 18:01, 1 February 2010 (UTC)

Splendid work. Perhaps there will be a more automated way to convert pixel counts, latitudes and other data to headings. Of course all this would be easier if cameras were set for GMT instead of whatever civil time zones the local authorities proclaim; time zones sometimes give me errors in using shadows to figure the headings of photos taken by tourists from across an ocean. Easier yet, if autogeotagging GPS cameras like mine were not rare. And if image processing software could use EXIF to preserve angle data for cropped and distortion-corrected pictures, aww, that would make it too easy! Jim.henderson (talk) 18:43, 3 February 2010 (UTC)

geograph.co.uk upload

With the forthcoming geograph upload- Commons:Batch uploading/Geograph we are faced by having many 100,000s files upload with a built in geotag. Maybe 50% will be labelled erroneously with a OSGB36 geotag- and require a Helmert correction (approx 112m error), 50% appear to have WGS84. Often the BOT will know in advance that the geotag is about to use OSGB. In cases like this would it be helpful to have a parameter

  • globe:OSGB
  • error:OSGB

As sometime the object not the camera is tagged

  • error:object_tagged
  • error:grid_square-precision
  • precision:1km

I presume that using extra tags would allow a further bot, to do the Helmert, or flag for manual correction. Any thoughts? I have left a comment on Commons:Batch uploading/Geograph.--ClemRutter (talk) 18:24, 11 March 2010 (UTC)

Just for the record: The batch upload was a bad idea. --Dschwen (talk) 19:03, 11 March 2010 (UTC)

Location indoors or outdoors

It might be an interesting idea to tag photos as indoors or outdoors. Programs could choose to use this information or not depending on the purpose. Jason Quinn (talk) 22:46, 18 March 2010 (UTC)

Google Maps not updated

I've uploaded and geotagged several pictures (try e. g. Praha-Vysocany Underpass Enter.jpg) on Commons but they don not appear in Google Maps overlay layer. It shows only some older pictures. I've also updated heading of picture CD class 451 braking in railway station prague-vysocany.jpg, but the change did not propagate to overlay. How often is the update performed? Or is there something wrong with my geotagging? --Oprendek (talk) 05:42, 2 April 2010 (UTC)

It's usually updated live (if there is now lag on {{Toolserver}}). tools:~para/GeoCommons/recentchanges.php shows it to be stuck on 2010-04-01 10:36. If it persists, you might want to ask para to check. -- User:Docu at 06:08, 2 April 2010 (UTC)
Problem must be somewhere else: I've geotagged the picture (with Location dec template) on 31. 3. 2010 at 19:29 CEST and there are changes after this moment in tools:~para/GeoCommons/recentchanges.php. Can you please check my geolocation of that image, if I've done it correctly? --Oprendek (talk) 06:32, 2 April 2010 (UTC)
The look ok to me. From a debug log (3MB), it looks like some of the scripts don't like the caps on "Heading" here. Maybe this explains it for that image. Not sure why this makes it skip the location entirely though. You might want to ask Para about this and why the second image didn't update. It might be due to some troubles with the toolserver being re-arranged. -- User:Docu at 06:57, 2 April 2010 (UTC)

Google Earth

Yesterday and today Google Earth doesn't show me Wikimedia Commons roundels, though Google Maps does. Is it me, or is it a bigger problem? Jim.henderson (talk) 18:54, 15 March 2010 (UTC)

It works fine for me today.--Kolossos (talk) 21:07, 16 March 2010 (UTC)
Me, too. I checked a few hours after writing that. It was working then, and has kept on working, when I used it a few times per day as usual. I don't know whether somoeone who knows where to kick saw my question and kicked the motor, or it simply restarted itself. Jim.henderson (talk) 22:51, 16 March 2010 (UTC)
Today again. No Google Earth roundels. Jim.henderson (talk) 22:11, 29 March 2010 (UTC)
I think this must have again coincided with some toolserver maintenance that was performed today. There is a status page for the toolserver which you can check http://status.toolserver.org/ . Is everything working again? --Dschwen (talk) 01:01, 30 March 2010 (UTC)
Sorry; no, I don't understand what that page is trying to tell me about Google Earth. And no, I still have no Commons roundels on Google Earth. Jim.henderson (talk) 04:44, 30 March 2010 (UTC)

But, a minute ago I gave it another try and up popped a swarm of roundels. Thank you, if someone who reads this did something to make it work. Jim.henderson (talk) 15:23, 30 March 2010 (UTC)

Alas, though there are many roundels for old pictures, I spoke too soon. Something still isn't working, or is bogged down by a backlog, or something. The pix I uploaded yesterday (29 March, New York time) including File:Newark Av freight bridge from PATH jeh.jpg do not show a Google Earth roundel. Jim.henderson (talk) 17:43, 30 March 2010 (UTC)

Twelve hours ago, this was still true. Now I checked again, and all the pix I've looked at (all three) now have their roundels. Thank you. Jim.henderson (talk) 05:21, 3 April 2010 (UTC)

And now, after returning from a ten hours absence, I see that all roundels have disappeared from GE, while they remain in Google Maps. Jim.henderson (talk) 05:21, 7 April 2010 (UTC)

They were still absent seven hours ago, but now they have returned. Jim.henderson (talk) 23:08, 7 April 2010 (UTC)

New Template:Coord template

User:Adam Cuerden resurrected Template:Coord template. It is well documented and likely useful for adding inline coordinates to categories or galeries, but I have 2 concerns:

  1. I am not sure if this template is suppose to supplement or replace {{Coor d}}, {{Coor}}, {{Coor dm}}, {{Coor dms}} and possibly other inline geocoding templates. I would be OK with replacement and retiring of those templates and this one seems cleaner.
  2. It might make sense to not allow use of this template in File namespace, since we do prefere use of {{Location}} templates for files.

--Jarekt (talk) 17:38, 21 May 2010 (UTC)

WTF. Couldn't he have discussed this beforehand. We didn't delete this without a reason in the first place. Now a user who has zero invelvement with the geocoding project "resurrects" it? This is BS. --Dschwen (talk) 18:09, 21 May 2010 (UTC)
I needed some way to put coordinates inline, so I could explain my justification of a location. The location template is not an inline template. As for discussion: if you think people know every single obscure Commons project, just because you're involved with it, then I don't know what you're thinking.
And before you go and break an explanation of an estimated geolocation, by deleting it, you MIGHT have looked at File:Polarlicht_2.jpg and seen that {{Location}} was in use, as is proper, for Geolocation, and {{Coord}} was used to point out one of the features on the map used to determine the geolocation. Using {{Location}} for that purpose would have only served to confuse the issue.
Further, I also modified {{Coord}} to be only inline, to remove the competition with {{Location}}. You didn't notice that, because you didn't care to look. Adam Cuerden (talk) 18:30, 21 May 2010 (UTC)
Adam, how about {{Coor d}}, {{Coor}}, {{Coor dm}}, {{Coor dms}} inline geocoding templates. Did you try them? I think Dschwen point is to ask first, the page was protected for a reason. --Jarekt (talk) 18:38, 21 May 2010 (UTC)
In fact I did try ([12]), but ran into the problem that they have no documentation whatsoever, and thus are a crapshoot as to syntax. Coord uses the same syntax as {{Location}}. Further, I was trying to set things up to explain events in a currently active discussion at COM:VIC, speed matters. I don't have a week for discussion before I'm able to do basic documention of my work, since VIC only runs 5-10 days or so. I needed a working inline template, with known parameters. I did take care to remove the functions that would make it compete with {{Location}}, which you'd have seen if you hadn't engaged in delete first, ask questions later. I felt that handled all objections to it. Adam Cuerden (talk) 18:43, 21 May 2010 (UTC)
Further, if you really cared about people using {{Coor d}}, maybe you should have had it added to [13], instead of having it suggest coord or location as the only possiblities. And have documented it. And have done a thousand other things that would show this wasn't all some grand power play, with people upset that someone didn't ask them before doing something necessary to his work attempting to improve the project.
I'm livid at how this was handled, mainly by Dschwen. Adam Cuerden (talk) 19:03, 21 May 2010 (UTC)

Hint: If you want people to engage in calm discussion, don't break their time-sensitive work by deleting the templates they were using, then complain about them for having dared not to use your obscure, undocumented non-standard parameter'd features that you'd rather they use. Particularly when they actively modified the restored template° to address the stated concerns. Adam Cuerden (talk) 19:05, 21 May 2010 (UTC)

Inline coordinates are useless and harmful. There is no reason for them on commons. We are not writing articles, we ar collecting media files. If there is a need for multiple inline coordinates something is wron with the page they are on. A gallery should not need them, coordinates shoud go on the image pages. An image should not need them, an image has exactly one camera location. Inline coordinates in the description text are ambiguous and useless for data extration. When using multilanguage descriptions inline coordinates lead to harmful data duplication. Coord was deleted to streamline out template collection for the geocoding project and avoid template bifurcation. Simply restoring them without prior discussion was wrong, we do not have to waste any further time about that. Attempts at saving face will only distract and inflate the unnecessary discussion. Focus on the facts. The template was deleted for a reason, that reason still stands. Please leave it deleted. --Dschwen (talk) 19:17, 21 May 2010 (UTC)

I somewhat disagree with Dschwen here. I occasionally find inline coordinates useful especially for galleries and categories. For example at some point I was experimenting with adding geocoded points of reference to aerial images, for example here). I would prefer well documented {{Coord}} template if we can use it to replace {{Coor d}}, {{Coor}}, {{Coor dm}} and {{Coor dms}} templates. That would reduce redundancy and confusion. The only danger I see is when users use it instead of {{Location}} templates. --Jarekt (talk) 19:42, 21 May 2010 (UTC)
If they're harmful, why do we have several unexplained and undocumented inline templates? {{Coord}} is documented, accepts any kind of reasonable parameter input, and, if you had looked at how I used it, you'd have seen that it was being used to give thelocation of a detail near the back of the picture. {{Location}} would be completely inappropriate for that, as it automatically sorts images into Google and such as originating at that location.
Further, by deleting it, you vandalized a three-hour, multi-person attempt to geocode an image. This claim that inline templates are supposedly harmful, in all cases, no exceptions, but we'll let you have these undocumented barely-functional ones to make it really hard for you if you have to use it is passive-agreessive bullshit.
In addition, because it accepts any reasonable parameter setup, I believe we could redirect the entire {{Coor d}} set to it. Adam Cuerden (talk) 20:19, 21 May 2010 (UTC)
The undocumented templates are deprecated, and it is a mistake that they haven't been deleted. Another problem with coord is that it will encourage people to blindly copy coordinate data the find on Wikipedias without bothering to check the geocoding standards on commons. Every inline coordinate that could have been a location is harmful. You may be interested in {{Object location}} which is intended to geolocate the objects shown. It avoids the inline problems with multilingual descriptions, by forcing centralized tagging. Using inline coordinates to geocode each and every object seen on the image distracts from the primary purpose of commons geocoding. Coordinates can help find images of a specific location. In theory the camera location should be sufficient for that. But as information on the field of view, distance covered, object occlusion is lacking, adding coordinates of visible objects or points of coverage can actually enhance the geocoding. However it cannot be the purpose of commons to generate our own data set of object specific coordinates. The way our data is organized this would lead to an immense data duplication. Keep in mind that many objects or landmarks are covered by many pictures, adding an object specific coordinate on every image showing that landmark would generate a very redundant dataset. Object specific coordinates should stay in Wikipedia. One article per object, one coordinate per object (possible multiple objects per article, but that is what named coordinates on the wikipedias are for). I realize that it is tempting to do something because it looks doable, but it is a bad idea if it takes focus away from the important goals, makes maintenance harder, and adds to confusion by increasing the choices the users must make (yet another template to choose from). I am absolutely convinced that we were on the right track with our focus on {{Location}} and {{Object location}}. Sorry if I was a bit (a lot) jagged (dickish) about this, but we had long discussions about this, leading to the current status quo, and think we are in good shape currently and I am frightened to see this fall apart. --Dschwen (talk) 20:42, 21 May 2010 (UTC)
Look at File:Polarlicht 2.jpg. See how Coord is used there. There's no way that that could be done with the template you propose to substitute in, since we don't even know what the building is - it's just being used as a reference point for a glow on the horizon that we need to identify.
How about this suggestion: Rename {{Coord}} to {{Inline coordinate}}, and do not leave a redirect. It'll be categorised into Category:Geocoding templates, so people can find it, but people won't be able to just copy over from en-wiki (since it's named differently), which should limit it to the few uses that're relevant. Adam Cuerden (talk) 21:15, 21 May 2010 (UTC)
First of all that evidence section belongs on the talk page. Secondly all my concerns about multilingial descriptions and data duplication due to inline coords are still there. I'm not disputing that you can come up with a use for coord. What I am saying is you shouldn't. Either just link to a wikipedia article, or if ther is no article, then leave it out. It is not relevant. It just is not worth polluting the template space with yet another coordinate template, when all we've been doing here is consolidating and minimizing our template selection. This was hard work. Throwing it away at a whim is not acceptable. I noticed that you restored the template again. This is not acceptable either. A short look on the deletion log of that template should have given you enough hints. You made a bold move, I reverted it, now we are discussion. Nowhere in that procedure there is place for you restoring it again. Please do the right thing here and delete it yourself. Point to three hours of geocoding effort is not acceptable. You should not try to create a fait accompli to justify the template. I can point to over three years of work on the geocoding project. --Dschwen (talk) 21:34, 21 May 2010 (UTC)
I'm not even going to bother discussing this. You vandalized the documentation of a careful geocoding work, and are now complaining that your vandalism was undone. {{Coor d}}, {{Coor}}, {{Coor dm}}, and {{Coor dms}} now redirect to {{Coord}}, for which the only difference is that it accepts any of those inputs, instead of just the single one each, and has documentation, which they don't. Any further attempts to passive-aggressively force people to use undocumented templates will make me request your block. Adam Cuerden (talk) 21:48, 21 May 2010 (UTC)
Please stop with the hysterical screaming for one second and read the various arguments against the restoration of coord. You plain editwarred against the established consensus that coord has to die. Nothing more nothing less. --Dschwen (talk) 22:45, 21 May 2010 (UTC)
Seriously, if anything, the best thing we could do is to make {{Location}} call {{Coord}} for the coordinates: {{Coord}} handles inputs much, much more cleverly. It can handle either decimal, dm, or dms input; {{Location}} can't. Why not use it for {{Location}}'s backend? Adam Cuerden (talk) 22:08, 21 May 2010 (UTC)
Even if there is a {{Coord}}, it is preferable that this uses another name. Otherwise people start using {{Coord}} instead of {{Location}}/{{Object location}}. BTW redirecting {{Coor}} seems to create borked links. -- User:Docu at 23:30, 21 May 2010 (UTC)
...Wow, {{Coor}}'s input is weird. Anyway, I'll move {{Coord}} to {{Inline coordinates}}. Adam Cuerden (talk) 23:45, 21 May 2010 (UTC)


No matter how you call it, inline coordinates are still a bad idea on commons. With Location and Object location we were at a point where our coordinates on commons were semantically well defined. Inline coordinates are not well defined, natural language processing is necessary to extract their context. This pollutes our well formed dataset. problem of using inline coordinates in multilingual descriptions hasn't been adressed yet either. Only downsides. The template had been deleted twice. It has been community consensus to avoid bifurcation of our coordinate templates. Now a single user comes and without any discussion decides to throw over this consensus. And, please, it is 2010, who uses <big> tags these days?! --Dschwen (talk) 00:15, 22 May 2010 (UTC)
Yes, yes, we know your opinion. Adam Cuerden (talk) 00:21, 22 May 2010 (UTC)
And you blatantly ignore it in your unilateral consensus breaking editwar. --Dschwen (talk) 00:22, 22 May 2010 (UTC)
Says the vandal. You vandalized a multi-person geocoding project, and made me spend two hours dealing with you. I don't care what the hell you think. Inline templates are used. This one is documented, and better coded, and accepts any reasonable input the ones we had fit none of those descriptions. Basioc usability says we should use documented, well-coded, easy to use templates. You have no consensus for removing inline templates completely. So you can sod off. Adam Cuerden (talk) 00:25, 22 May 2010 (UTC)
Mh yeah, more name calling. So you don't care what the hell your contributors think? They can sod off? Are you sure this is where you want to go in this project? --Dschwen (talk) 00:40, 22 May 2010 (UTC)

Tha fact that inline coordinate templates are uses is itself no justification to have them. Most uses are in filedescription pages predating the standardization of our templates. They are used in places wher either {{Location}} (ex.) or {{Object location}} (ex.?) would be the appropriate choice. Just because we lack the manpower to swiftly clean up this mess doesn't mean we should just give up. Unfortunately in many cases the inline coordinates just lack information on whether a camera location, or a subject was geocoded ex.. Those coordinates are not very useful. They just pollute the data set we can extract from commons. Unfortunately the scope of the situation does not seem immediately clear to people that are not familiar with the geocoding project. I'm confident that sooner or later a few other regulars will offer their opinions here. In the meantime I suggest that not too much time is wasted on inline coordinates. --Dschwen (talk) 00:50, 22 May 2010 (UTC)

Pot. Kettle. Black. You're hardly one to talk, Mr. "I'll delete this before Adam ever gets a chance to comment. I'm happy to læisten to anyone but you, as your actions have ruined your credibility completely. Adam Cuerden (talk) 01:20, 22 May 2010 (UTC)
Well, you had plenty of chances to comment before undeleting a template that was deleted twice before. As for you credibility comments, I'll just ignore those. --Dschwen (talk) 12:29, 22 May 2010 (UTC)
How about just adding a very optional parameter so people can specify that their use of coordinates is not appropriate for the Google map functionality (which is extremely cool BTW). (And no, I haven't read the silly screaming and carrying on above, so my apologies if I missed something important). Wknight94 talk 01:17, 22 May 2010 (UTC)
No,because if you look at the usage I linked above, you'll see that a box would be giving way too much weight to a link that simply serves to explain how we know where Bear Lake is, which was previously unclear. Not linking to the coordinates would ruined the collaborative work to find the correct Geocoding, and putting them in a {{Location}}-style box would serve to confuse our users about where we're proposing the camera is. 01:20, 22 May 2010 (UTC)
Ok, how about we restrict usage of inline coordinates to talk page an project space. If you want them as a collaboration tool for things like your Polarlicht example that should be fine and would adress both out concerns. --Dschwen (talk) 01:25, 22 May 2010 (UTC)
Data extraction and reusability is one of my major concerns. I suggest you read the discussion above for further points. (you can safely skip the paragraphs containing bold and/or enlarged text) --Dschwen (talk) 01:23, 22 May 2010 (UTC)
Which is why inline is better for these purposes: It makes sure that supporting information gets treated differently from the most relevant information. Data extraction that can't tell the difference between the most relevant and information likely to be irrelevant to such extraction isn't as useful. Adam Cuerden (talk) 01:57, 22 May 2010 (UTC)
I read the above in its entirety - it's pretty much as I thought. If restricting inline use to project and talk space satisfies everyone, it sounds good to me. Wknight94 talk 02:28, 22 May 2010 (UTC)
And who is going to fix the literally thousands of uses of the inline templates we've had in existance long before this discussion? [14] [15] [16] [17]
That horse bolted years ago. Literally the only change that got made today was a better-coded and documented backend for something in massive use. If you want to restrcit it, have fun cleanign up everything so it works. Note {{Coor dm}} uses a syntax not accepted by any location template, so even if you wanted to half-arse it... Adam Cuerden (talk) 02:40, 22 May 2010 (UTC)

We have a mess, we need to clean it up, not ignore it or make it worse. Detecting images, that need our attention is fairly easy. I wrote a bot yesterday, that can add a category to image pages that are only tagged with an inline template and not with a location or object location template. One possibility would be treating them as not geocodes and throw out all those templates. That would be analogous to deleting bad stubs, as a red link at least does not pretend to be an article. However that would make retagging the images with the correct templates much harder. The alternative would be having the bot translate the coordinates into the format of location or object location and comment them in the wiki source. The translated versions could more easily be used to fix the coordinates. The best solution would be to add a review tool that would give quick access to a satellite image or map and would make it easy to just accept or modify the coordinate. --Dschwen (talk) 12:26, May 2010 (UTC)

Deleting the templates by bot would have a very high chance of accidental vandalism. I don't think that ending up with half-completed sentences, deletion of irretreivable information (such as geocoding in the wrong form) and the liike would be at all acceptable. That would not be analogous to deleting bad stubs, that'd be analogous to going through and deleting a few specific words from all Wikipedia articles. Adam Cuerden (talk) 17:06, 22 May 2010 (UTC)
Yes, just leave the inline versions alone. Let the bot constantly check for inlines but no location tags (or once per week or whatever), and add a corresponding location tag. The end. Problem solved. For a bonus, the bot can harass people into doing it correctly as Multichill's uncategorized bot does. Wknight94 talk 17:30, 22 May 2010 (UTC)
Just adding a Location tag automatically is not a good idea. As I said above, it is not easy to determin whether an inline coordinate template is coding the camera location or an object location. Simple conversion would degrade the quality of our geocoding effort considerably. --Dschwen (talk) 18:27, 22 May 2010 (UTC)

I just replaced Template:Object location by Template:Location on File:Pont de Normandie from above-edit.jpg, because the file didn't show up on Google Maps. Not sure about the cause, but this fixed the problem (for now)... - Erik Baas (talk) 15:00, 15 June 2010 (UTC)

A test with 3 other files (File:Airport PAD Abflughalle.jpg, File:Stadttheater-OS.JPG and File:Schellinkhout, Dorpsweg 20.jpg‎‎) shows the same result: the location is correct, but the object is not shown on Google Maps (via toolserver.org/~para/GeoCommons/GeoCommons-simple.kml). - Erik Baas (talk) 15:16, 15 June 2010 (UTC)
Please be careful when replacing those templates. The mean different things. Location codes the camera location and heading, and is the preferred way of geocoding on commons. Object location coded the location of an arbitrary object on the picture (those won't show up on the map). --Dschwen (talk) 15:18, 15 June 2010 (UTC)
Is there a way to show symbols for location templates? For some objects, such as Category:Outerbridge Crossing we have only one or two geotagged pictures from far away, hence the location of the object won't be apparent on Google's various maps. Even when the location template shows a valid directional arrow, a map symbol for a category's object location would be highly informative. Jim.henderson (talk) 04:50, 17 June 2010 (UTC)

No Google Earth roundels

Google Maps is still showing me the red and blue symbols to indicate the direction of photos such as File:Woodhaven Junc dead end jeh.JPG but Google Earth shows no symbol for the photo. Jim.henderson (talk) 00:20, 21 June 2010 (UTC)

All appears fine to me. -mattbuck (Talk) 00:57, 21 June 2010 (UTC)
Drat; it must be something in my end though the usual complaint applies that I did nothing to my computer. I'll have to try uninstalling and reinstalling GE after a good night's sleep; the alternative of using GM to see the arrows is intolerably clumsy on my slow DSL connection. Thanks for checking. Jim.henderson (talk) 03:17, 21 June 2010 (UTC)
Jim.Henderson, I have the same problem: since two days the camera location symbol of any Commons image with a {{location}}-template still shows up in Google Maps, but does not show up anymore in Google Earth. Updating to the latest GE version did not help me either. Other users on my home wiki (nl:wiki) also have reported that they can't see the camera location symbols in GE. I use XP and FF 3.0.19. Wutsje (talk) 21:29, 21 June 2010 (UTC)
Update: exactly the same thing happens when I use my ancient IE6 (6.0.2900). Wutsje (talk) 22:16, 21 June 2010 (UTC)
Status unchanged. I uninstalled and reinstalled GE six hour ago. This is under Vista Home Premium SP2. MSIE 8.0.601.18928 and Chrome 5.0.375.70 are my two browsers. Google Earth 5.2.1.1329 (beta) with either browser is showing a pentagonal house outline over whatever location is indicated by a picture's coordinates that I click on, but no roundels or arrows. Four hours ago, even Google Maps was failing to show any roundels but now they are present with their arrows. So, something is going wrong and my suspicion is it's in Google's Earth server's connections to Commons. My poorly informed guess is that the problem is not on my browsers, though I am at a loss to explain why you and I are failing while someone else is succeeding in seeing the arrow roundels of GE. Jim.henderson (talk) 00:32, 22 June 2010 (UTC)
Update: Now, a few hours later, it's working for me as well as ever. I did nothing since then to repair it, so either someone found and fixed a problem, or it was an unexplained two days glitch. Jim.henderson (talk) 21:17, 22 June 2010 (UTC)
All is now working fine again here too. Whoever fixed this: thanks! Wutsje (talk) 11:58, 23 June 2010 (UTC)

Geocoding at Wikimania

Apparently there was a presentation on this a couple of days ago. It's available at File:Wikimania2010-WP-GEO.pdf. Interesting work!  Docu  at 07:02, 21 July 2010 (UTC)

Thanks for finding it. It was quite interesting. --Jarekt (talk) 13:35, 21 July 2010 (UTC)


Google roundels gone again

Neither Google Earth nor Google Maps is showing symbols for where my photos are or which way my camera was pointed. Jim.henderson (talk) 10:03, 23 July 2010 (UTC)

There is a problem with a database server, see here. - Erik Baas (talk) 11:38, 23 July 2010 (UTC)
Roundels have partially returned. On either Google Maps or Google Earth I now get roundels with arrows, but only for nearby pictures other than the one that I clicked. With GM, that picture gets nothing except the honor of the center point of the window. With GE, that picture gets a thumbnail on the spot, instead of a roundel or any directional indicator. I assume the repair will be finished soon. Jim.henderson (talk) 17:12, 26 July 2010 (UTC)
Correction; in Google Earth the thumbnail appears instead of the roundel for some pictures, such as File:Kings County Savings shady 135 Bwy jeh.jpg. However, for others such as File:James Cathedral north jeh.jpg the roundel appears with its helpful arrow. I have no idea why there is a difference. Jim.henderson (talk) 11:52, 28 July 2010 (UTC)
It was working ok for me last night. -mattbuck (Talk) 12:38, 28 July 2010 (UTC)

Geocoding tool broken

The coords for Wikipedia tool appears to be broken - it does the loading thing, but ends up with the red indicator in the middle, and won't respond to refresh. Is this just me, or are other people having problems? -mattbuck (Talk) 11:41, 23 July 2010 (UTC)

I had problems too indeed, the database seemed to be unavailable for some days last week. But now it has been repaired I can access again.Jeriby (talk) 17:25, 28 July 2010 (UTC)

Headings in WikiMiniAtlas

I wanted to add this a long time ago, now I have. Camera headings are now visible in the WikiMiniAtlas. --Dschwen (talk) 22:55, 30 July 2010 (UTC)

Alas, I am not seeing such an indicator for recently coded pictures including File:Maimonides Medi Cent 49-10 jeh.JPG. Jim.henderson (talk) 21:14, 24 August 2010 (UTC)

We on OpenStreetMap

Now we have our geocoded images on OpenStreetMap with OpenLayers in the background, so we are complete on OpenSource/CreativeCommons-base:

If it works ok, it should be included into location-templates. --Kolossos (talk) 20:37, 29 July 2010 (UTC)

  • I wonder what is so hard about displaying little thumbnails instead of rather meaningless symbols? The pop-up tooltips with the thumbs are flickering by the way if you move the mouse on them near the underlying symbol. --Dschwen (talk) 21:23, 29 July 2010 (UTC)
    • The symbols are not meaningless, they show in what direction the picture was taken. --Ainali (talk) 17:38, 30 July 2010 (UTC)
      • Well, I know. I was being a bit pointy I guess. Nothing stops you from adding direction icons to the thumbs. I find it much more compelling to see an overview of thumbs. That makes it much easier to discover interesting images when randomly browsing the map. --Dschwen (talk) 18:04, 30 July 2010 (UTC)
That is a great news. Thanks a lot. I added new OSM link to all location templates. --Jarekt (talk) 02:51, 30 July 2010 (UTC)

It is pleasant. Tastes and purposes will differ; that's why some Web sites use cookies or other methods to store user home locations and preferences. My preference is the way it is now, showing the map filled with pointers and only showing thumbnails as tooltips. Indeed I wish the pointer would be a trident or indicate in some other way the the viewing angle of the picture, so I can distinguish the telephotos from the wideangles. And respond to headings in single degree precision rather than, what is it, increments of 11.25 degrees? But that's this particular geotagging fan's perspective; we all have our peculiar wishlists. Jim.henderson (talk) 23:34, 30 July 2010 (UTC)

Great news. Would be problem to add OpanCycleMap (it has countour lines, in contrast with hikebike map) layer? I have also problems with direction icons in Opera 10.70 - it is always heading north, and is stretched. Petr Dlouhý (talk) 08:33, 25 August 2010 (UTC)
I added OpenCycleMap, also if I'm not so happy with the style. So I added also hill-shading Layer. About your Opera problem I can say nothing. Do you have the same effect on Google maps Commons Layer with your browser? --Kolossos (talk) 19:56, 25 August 2010 (UTC)
No, the problem is present only for OpenStreetMap.--Petr Dlouhý (talk) 09:42, 16 September 2010 (UTC)

Contour maps are very pleasant; hill shading is less interesting, at least to me. Alas, I don't see my roundel arrow in the cycle map, for example for File:RI Bridge temp walkway jeh.jpg though this and the roundel arrows of other recent pictures are now, after more than a week of absence, being happily shown on Google Earth, Google Maps, and OpenStreetmaps. Jim.henderson (talk) 23:10, 25 August 2010 (UTC)

Is possible to filter images by category as on google? Parameter "article" is not working. --Petr Dlouhý (talk) 08:38, 17 September 2010 (UTC)

approximate location

On some historical images I know the town or the landscape, but not the exact place or the object. I think its better to add an approximate location than nothing. How do I add an approximate location of the object, place or landscape? (Sorry for my bad english) --Slick (talk) 08:44, 17 September 2010 (UTC)

Categories?  Docu  at 08:51, 17 September 2010 (UTC)

GeoCommons duplicates

I don't know if this is the right place to ask, but does anyone know an answer to the question I asked here? In short: Why does an unexisting image show up in geocommons, although the image vas renamed and the rd deleted more than a week ago? --Albval (talk) 10:14, 22 September 2010 (UTC)

Not sure, but seems to be a refreshing. I could see some pictures edited from "Location" to "Object Location" remaining some days with the "Location" blue icon instead of the "Object Location" black icon of the GeoGroupTemplate, and remaining visible during some days in the Google Earth Plugin, whereas "Object Location" pictures are not visible. Jeriby (talk) 12:33, 22 September 2010 (UTC)
So the solution is just to wait, although the unexisting file has stayed in GeoCommons for three weeks now? Or can the db be refreshed somehow manually? --Albval (talk) 15:14, 22 September 2010 (UTC)

New tags not producing roundels

As has happened before, images tagged this week such as File:Lincoln Building jeh.JPG do not show their locations in Google Earth, Google Maps, or OpenStreetMaps. Jim.henderson (talk) 13:52, 24 September 2010 (UTC)

And now they are producing roundels. Thank you, if somoene reading this is responsible. Jim.henderson (talk) 01:02, 25 September 2010 (UTC)

{{Museum}} template

{{Museum}} template uses {{Inline coordinates}} to add coordinates of the museums. Category:Museum templates are then used to provide information where the artworks reside. As a result 16k files are tagged with coordinates. As number of Category:Museum templates grows (we have 60 in one month) we will have a handy way of identifying locations of the museums. Would it make sense to show those locations on the on Google maps and others? --Jarekt (talk) 03:03, 29 September 2010 (UTC)

I think the question is similar to one raised by applying object location templates included in categories to all images in the category. They are less accurate then the ones we would generally like to have on images themselves.  Docu  at 11:36, 30 September 2010 (UTC)


Please see #Add { {object location}} to categories based on interwikis. ---  Docu  at 11:36, 30 September 2010 (UTC)

Category mapper

Has something gone wrong, or is it just me? When I click the map tab of Category:Parachute Jump I see roundels for many pictures that are not in the category. Jim.henderson (talk) 11:04, 27 October 2010 (UTC)

Yes indeed because the template used here, when you click on "see on google maps" is able to see any pictures of the map without regarding on categories. For watching only category pictures, it would be better to use the GeoGroup template on the category page instead (or just below the actual template). I've tried (I previewed the page, I didn't submit it) and the GeoGroup template works properly, I just see pictures of the category (besides there are only 4 geolocalized pictures on this category, you can see here http://maps.google.com/maps?q=http%3A%2F%2Ftoolserver.org%2F~para%2Fcgi-bin%2Fkmlexport%3Farticle%3DCategory%3AParachute_Jump%26project%3DCommons%26l%3D99%26usecache%3D1). Jeriby (talk) 14:19, 27 October 2010 (UTC)

Ah. Thank you; it's a useful tool and I'll keep it in mind when handling other geographical categories. Perhaps it should be categorized in Category:Geocoding templates and mentioned in a category help page and in descriptions of template:Location and others. Jim.henderson (talk) 15:38, 27 October 2010 (UTC)

No new roundels

Recently tagged pictures including File:Greeley City Hall Pk snowy jeh.jpg are failing to show their symbols on Google Earth. Jim.henderson (talk) 01:37, 30 December 2010 (UTC)

Indeed we can't see it yet, but the edit has been confirmed because I can see it here:
http://toolserver.org/~para/cgi-bin/kmlexport?article=Category:Parks_in_New_York_City&project=Commons&l=99&usecache=0
Then maybe we just have to wait Jeriby (talk) 16:13, 30 December 2010 (UTC)

I carried out that edit somewhat blindly, but otherwise waited and it came, for File:Herald Sq entry arch snow jeh.jpg and others. Don't know whether it was just a matter of waiting or someone saw it mentioned here and kicked it into action. Jim.henderson (talk) 22:19, 30 December 2010 (UTC)

No new roundels

New pictures such as File:Coney Island Memorial Chapel snow jeh.jpg (and old pix with new Location templates) are again not showing roundels. Jim.henderson (talk) 21:39, 9 January 2011 (UTC)

So, this morning the roundels were showing. Alas, the EXIF bot failed to find coordinates for the Coney Island pictures I uploaded on January 8, so I had to retag them manually. Too bad the system isn't entirely reliable but then I also make mistakes (some of which are shown to me by the roundels). Jim.henderson (talk) 14:19, 10 January 2011 (UTC)
Works fine for me (last upload 17:34, 10 January 2011 is on google). NVO (talk) 18:24, 10 January 2011 (UTC)

The pictures I uploaded on Jan 9 and 10 were also tagged properly in the morning and showed roundels soon after. There must have been a one day glitch, either in my pre-upload EXIF tagging process, or in the EXIF reader. Just have to accept that there will be glitches, I guess, in such a complex system. Jim.henderson (talk) 23:53, 10 January 2011 (UTC)

The above generally include {{Location}} instead of {{Object location}}. This displays "Camera location" on the category description instead of "Object location". There are a few categories that are actually done by camera location, but these are rare. Shall we change the text to display "Object location" instead of "Camera location". For the few exceptions, we could create a "cameralocation=y" parameter. --  Docu  at 17:57, 1 January 2011 (UTC)

I think we should change all the {{Location}} to {{Object location}} if used in a category--Jarekt (talk) 21:34, 1 January 2011 (UTC)
It would be the cleaner solution, but more work. We still might want to skip the ones that use something like "cameralocation=y". --  Docu  at 21:38, 1 January 2011 (UTC)
Changing them all is easy for a bot, except for those that should not be changed. Is there a way to tell them apart?--Jarekt (talk) 21:57, 1 January 2011 (UTC)
Category:Views away from State and Madison and Category:Views from Roter Turm (Kamenz) might be the only exceptions for now. There are quite a few "Views from"-categories, but they don't have coordinates yet. --  Docu  at 22:03, 1 January 2011 (UTC)
✓ Done I changed all {{Location}} to {{Object location}} when used in categories, exept for a few "Views from" categories. --Jarekt (talk) 15:16, 3 January 2011 (UTC)
Thanks. BTW, I'm wondering if I shouldn't make two subcategories at Category:Categories with coordinates:
--  Docu  at 20:07, 9 January 2011 (UTC)
✓ Done. --  Docu  at 20:07, 2 February 2011 (UTC)
Apparently there is a third group: those using {{Globe location}}. I added them to Categories with globe location coordinates. --  Docu  at 13:12, 5 February 2011 (UTC)

No new roundels

Recently uploaded photos such as File:145th St Bridge Harlem west rain jeh.jpg are having their EXIF coordinates converted to Location templates, but the roundels are not appearing on Google Earth. Jim.henderson (talk) 11:31, 4 March 2011 (UTC)

Indeed, maybe another bug, we'll have to wait a little as usually I think. Jeriby (talk) 14:49, 4 March 2011 (UTC)

Google Earth

Is there a way to stop google earth viewing the images in google earth rather than opening firefox? It's doing my head in. -mattbuck (Talk) 21:51, 24 March 2011 (UTC)

You mean? Avoid that Google Earth opens the web page itself? Jeriby (talk) 22:30, 24 March 2011 (UTC)
Yes, when I click view image on commons I want it to open a firefox window rather than having to click the open in firefox button on the google browser. -mattbuck (Talk) 22:41, 24 March 2011 (UTC)
Ok, I don't know if you have the same version as me, but on Google Earth 5 you have to go in "Tools" menu, then "Options", in the "General" tab, the 2nd option on the top-left corner of the options windows, you check "Show Web results in external browser" (or the equivalent in your language if not english), and then click OK. It will open your default browser. If you have version 6 it may be on the same place, or kinda ^^ Jeriby (talk) 23:26, 24 March 2011 (UTC)

Eiffel Tower in Brooklyn

The image to the right shows up in Brooklyn due to the Institution template including coordinates. Not sure what to think of it. Should we set additional coordinates for the image or not display images based on Institution templates? --  Docu  at 08:15, 11 June 2011 (UTC)

For a picture of a distant place, I feel the coordinates should point to the distant place and not to an institution holding the picture. Categories should say where the painting or diorama or other representation is stored or displayed. Jim.henderson (talk) 11:16, 11 June 2011 (UTC)
I am not sure what you mean "shows up in Brooklyn". Brooklyn museum coordinates show up only when you expand the institution template otherwise there are no coordinates on the page. Once you expand the template I think it is rather clear that those are coordinates of Brooklyn Museum and not objects in the the photographs held by the museum. {{Institution}} uses {{Inline coordinates}} to display coordinates and I do not think you can use it to show image icon on the map. Of course anybody can add {{Location}} to the image, if one can figure out location of the photographer. --Jarekt (talk) 13:09, 11 June 2011 (UTC)
It show ups with Brooklyn if you click on the "GeoGroup" link on Category:Eiffel Tower from a 30 degree angle. --  Docu  at 15:39, 11 June 2011 (UTC)
In the meantime, I added coordinates. Now that I added {{Location}} it's there twice, at two different locations. Maybe this is ideal. --  Docu  at 15:50, 11 June 2011 (UTC)
I see what you are saying - That is confusing. May be {{Inline coordinates}} location should not be stored/cataloged or whatever we do to get geo location. Since each institution has single set of coordinates a large set of images will have the same location. I am not sure what is the ideal solution here. --Jarekt (talk) 16:04, 11 June 2011 (UTC)
Maybe there is something we can do to {{Institution}} to avoid that these get inserted? --  Docu  at 04:08, 12 June 2011 (UTC)

Geocoding of a painting

"Lady at the Paris Exposition" by Luis Jiménez Aranda

There is some discussion how to geocode the above painting (independently of {{Institution}}):

Personally I opted for (3). Obviously one might want to add {{Object location}} for the Eiffel Tower. --  Docu  at 13:07, 12 June 2011 (UTC)

Yes, some clarity here would be good. As regards the painting in question, I changed option 3 to option 2 with some explanatory text in the description because, to me, option 3 suggested that that was the location where the painting was photographed (which was not the case here because the image was taken from a website and not photographed in person). Do we need a new template? — Cheers, JackLee talk 13:22, 12 June 2011 (UTC)
We could add an option to change the "Camera location" label on {{Location}} to something matching the context, e.g. "Viewer location". --  Docu  at 18:59, 12 June 2011 (UTC)
Sounds like a good idea. But "viewer location" is not very clear. What about "location in the image" or something along those lines? — Cheers, JackLee talk 06:54, 13 June 2011 (UTC)
Eiffel Tower from Montmartre
I'm not sure if this isn't slightly confusing as well. "Location in the image" might describe {{Object location}} rather than {{Location}}.
For photographs, e.g. for File:Paryż wieża.JPG (see left) {{Object location}} would be the location of the Eiffel Tower, {{Location}} is the one of the camera on Montmartre. {{Location}} uses heading, while {{Object location}} doesn't.
When adding coordinates, we attempt to add primarily {{Location}}. Commons:Geocoding describes this as "we identify the latitude and longitude from where the media was recorded".
At File:Barrière d'Italie (Paris) 1819.jpg, I used {{Object location}} as it's hard to figure out the location of the observer's vision. The location I gave for the painting of Luis Jiménez Aranda is meant to be the one of the observer/painter. --  Docu  at 08:41, 13 June 2011 (UTC)

I see what you mean. Well, I guess "viewer location" is OK. Where should this change be made – {{Location}}? — Cheers, JackLee talk 09:24, 13 June 2011 (UTC)

Or "Point of view", a term sometimes used figuratively but having great clarity when used literally. Jim.henderson (talk) 11:20, 13 June 2011 (UTC)
I am fine with "viewer location", if change is needed, but I do not think "camera location" needs changing - it will be a very rare case that we will know location with enough precision to provide the tag in case of paintings, etc. Another complicating factor is that "camera location" is translated to 30-40 languages in Template:Location/en, Template:Location/de, etc. files and all those translations should be changed. --Jarekt (talk) 11:28, 13 June 2011 (UTC)

Firefox add-on (Wikimapper)

In the 'Wikimapia' section is a recommendation for the 'Wikimapper plus' Firefox add-on, which has apparently been disabled by an administrator. --Gaidheal1 (talk) 22:36, 28 June 2011 (UTC)

GeoCommons database

I usually use google maps to view geocoded images. But google maps give an error "The GeoCommons database is currently unavailable, please try again later" very frequently. May I know why this happens every couple of hours?--Praveen:talk 04:33, 13 June 2011 (UTC)

Sometimes toolserver is too slow to respond and it times out. In this case, one needs to reload it.
BTW if, on a category, you use {{GeoGroupTemplate}} with the option {{GeoGroupTemplate|level=1}}, it works slightly differently. The link goes to the toolserver, loads the coordinates, and once completed, redirects you to the maps. This avoids the timeout problem. To try, check the "Map of all coordinates from .." links on Category:Remote views of the Eiffel Tower. --  Docu  at 12:06, 13 June 2011 (UTC)

Too bad Template:Location cannot be made to work by this apparently more reliable method. Jim.henderson (talk) 20:13, 1 July 2011 (UTC)

Firefox plugin disabled!

Firefox add-on linked here has been blocked by a Mozilla administrator. Check it out! -- Massic80 Contattami 00:33, 3 September 2011 (UTC)

Privacy option

This page needs clear information on how to prevent an image from being geocoded for privacy reasons. For example, I take photos of objects that illustrate articles at my home and I do not want my location publicized in that way.--agr (talk) 12:42, 5 September 2011 (UTC)

If they were taken at your home, they probably cannot be geocoded manually (if they can AND you want your privacy protected, you probably don't want to upload them in the first place). That leaves location information from the EXIF metdata, which would be used by bots (and available even before geocoding). Maybe they should be detected by the upload tools, and a warning should be displayed with the option to remove them. --LBE (talk) 16:09, 5 September 2011 (UTC)
See Category:Location withheld, which I created recently.—An  optimist on the run! 20:43, 9 September 2011 (UTC)
It would be nice to create a template which adds the category automatically and which warns people not to add coordinates of the file if they know the location, with a little banner like for Template:Location possible. Jeriby (talk) 13:05, 10 September 2011 (UTC)
✓ Done - see Template:Location withheld—An  optimist on the run! 08:06, 17 September 2011 (UTC)
Very nice! Thanks :-) I've done the translation in french. Cheers :-) Jeriby (talk) 16:21, 17 September 2011 (UTC)

I see that agr takes pictures with his iPhone which stores location in the image EXIF data, see for example File:VERSAbus memory card.agr.jpg. May be iPhone has an option not to store location (or it is possible to turn off GPS while taking pictures). Otherwise you might want to use some software to edit EXIF prior to upload. Bots on Commons only know your location if the files you upload provide it. Even if it is not displayed on the file page, it is there and anybody can find it. --Jarekt (talk) 21:05, 9 September 2011 (UTC)

You can use Exifer tool or ExifManager tool (they are freeware) to edit or remove Exif data. There is also Exit Tag Remover but in shareware. Also, for erasing any EXIF data you can just save the file as Bitmap (bmp) file, and then convert it again in Jpeg (JPG) (in order to avoid quality loss during conversion you can use tools like Jpeg Optimizer which allows you to choose the compression rate precisely). Jeriby (talk) 13:03, 10 September 2011 (UTC)

Changes in google maps

(it's about manually encoded coords, not coords from GPS-enabled cameras)

Last night Google updated sat photos of en:Kozelsk. The new photos are shifted some thirty to fifty meters east relative to the old ones - quite a lot for tagging individual houses. Everything tagged earlier is now way off mark. Alternative map services, of course, did not change, but I suspect most users will not even consider them - at least as long as Google is the only service with high-res sat photos. Going there and fetching real GPS coords on site is not possible yet.

Should I change existing geotags to match the change in underlying sat photos, or - ?? NVO (talk) 07:45, 29 September 2011 (UTC)

I noticed sometimes Google satellite images do not align with the vector data, for example in Casarano, Italy [18]. One of them must be wrong but it is hard to tell which one. So I am mot surprised that Google occasionally updated sat photos and everything shifts. NVO, I think it is fine to update our tags as well, if you can figure out which ones (boundaries?). --Jarekt (talk) 12:58, 29 September 2011 (UTC)
I noticed also, about changes in Google Maps, the the link "open in google earth" has disappeared when showing a GeoGroupTemplate map on Google Earth. It's a bit annoying when using this template with a level of multiple subcategories, because the direct link (when available) of the GeoGroupTemplate to Google Earth shows only the main category and not the subcategories. If anyone has a tip... Jeriby (talk) 13:44, 30 September 2011 (UTC)

Ignore me if this is too wacky- centre point

One on the unintended side effects of the current problems with the tagging bot and the whole display of roundels is the appearance of the warning triangle: the Geodatabase is currently unavailable icon. As this is in the dead centre of the window it make tagging images using the javascript:void(prompt(,%22{{location%20dec.... method so much more precise and faster. <Switch into irony mode> Would some one with copious free time </Switch into irony mode> like to modify the GUI so that each time the roundels are displayed- a little unobtrusive red and blue dot / or cross hairs are displayed at the dead centre of the display, to help us target out new tags. Just a thought- but as the program is being examined at the moment it may be a simple change to affect. --ClemRutter (talk) 10:21, 6 October 2011 (UTC)

The image on the right links to http://stable.toolserver.org/wma but looks like broken, isn't it supported anymore? emijrp (talk) 13:21, 23 October 2011 (UTC)

The URL should be http://www.toolserver.org/~dschwen/wma the stable server ironically has been discontinued... --Dschwen (talk) 19:56, 24 October 2011 (UTC)

Positioning pics in google maps, # of pics

Hi, I'm positiong my pics usually on google maps. When there are too many pics in a small – or sometimes wider – area, not all of them are shown, even the positioning after clicking on <Google.maps> is absolutely correct (centered ot the position entered). How can we change this? --Lord Koxinga (talk) 17:46, 27 October 2011 (UTC)

Positioning pics in google maps, duration of actualization

Hi, Sometimes it needs hours or days until actualized positioning after edit is done. I'm used about this but other people could be confused. --Lord Koxinga (talk) 17:46, 27 October 2011 (UTC)

No new roundels

New files, or even recently tagged old ones such as File:138gconcourse.jpg, are not showing roundels on either Google Earth or Google Maps. Jim.henderson (talk) 11:40, 1 August 2011 (UTC)

There seems to be a problem with Para's scripts. Neither Commons on OSM (which is based on Para's database) nor Commons on Google show our geotagged photos. Are there other services or is there a manual how coordinates are extracted and shown on Openstreetmap? Vermip (talk) 13:39, 14 August 2011 (UTC)
Meanwhile we can workaround with the GeoGroupTemplate, I tried with File:138gconcourse.jpg upon its category and it shows the roundel correctly with this template on both Google Maps and Google Earth. Jeriby (talk) 16:08, 14 August 2011 (UTC)
But will we see all pictures on a map, or only those categorized correctly? What about OSM? Vermip (talk) 19:00, 14 August 2011 (UTC)
Is anyone working on this bug? -- smial (talk) 17:13, 16 August 2011 (UTC)

The template will only show categorized pictures, as far as I know. Anyway even this much often doesn't work. Usually in the past week Google Earth and Google Maps have failed to show me any roundels, no matter whether the picture or tag is old or new, but when roundels are seen, usually both old and new ones are present. I assume the biggest problem isn't me or Wikimedia or even Google, but Toolserver which is necessary to connect them and indeed to do almost any geographical Wikitask. I hope someone can figure how to repair or strengthen or deload or bypass Toolserver or otherwise make the geographical features work reliably. Jim.henderson (talk) 11:40, 18 August 2011 (UTC)

Hello Jim, thanks for reply. The extraction of coordiates of Wikipedia database fails. One upon a time this link presented all pictures, similar to Google's Panoramio. The author, Kolossos, checked the script. It works fine but has problems to access data. This is why this fails as well.
Short answer to Smial: I don't know whome to ask. See my question in German board. Vermip (talk) 18:54, 19 August 2011 (UTC)

It seems to work again ! File:138gconcourse.jpg appears correctly on Google Earth layer, with the right roundel, and my latest coordinates are also appearing some minutes after adding them. Thanks to anyone who fixed it! Jeriby (talk) 16:59, 21 August 2011 (UTC)

You are right! Someone helped a lot. As far as I understand this service is not part of wikimedia software. What can we do in order to broaden reliability? Vermip (talk) 17:17, 21 August 2011 (UTC)
I too found the roundels a few hours ago, though my recent uploads had not been bot-tagged. I used the roundels to correct some headings, then went out on errands and returned to find no roundels, old or new. I entered a few headings and a few coordinate templates, semi-blindly, and after half an hour the roundels, old and new including File:Peter of Alcantara RCC PW jeh.jpg with corrected heading, suddenly appeared. So, no, I do not think the problem with Toolserver, whatever it is, has been repaired. It operates sporadically. Jim.henderson (talk) 19:12, 21 August 2011 (UTC)

In the past few minutes several of my recently uploaded pictures have had their GPS EXIF botconverted to Wiki geotags. In the past twenty hours the category maps have also been working. However, during those twenty hours I have not seen any roundels for old pix or new ones. So, if I'm interpreting correctly, at least two of the geographical services that depend on toolserver are working, and at least one is not. Jim.henderson (talk) 12:48, 24 August 2011 (UTC)

"operates sporadically" sounds for me like that the script is very often nearly to the connection limit to mysql. This limit is on toolserver 10 connection per user. So if User:Para (all his scripts) has less than 10 connections the script work fine else it doesn't. To solve the problem you need mostly a higher performant database structure and query strategy or you need to shoot down some inefficient/long-running tools. But that's only my personal theory for the outside, because I can't see what's going on . --Kolossos (talk) 16:15, 25 August 2011 (UTC)
Checking a few times every day at different times of day, it has been about half a week since I saw any roundels. So, if this service is working at all, it's so rare that we shouldn't be making promises. Template:Location promises that the viewers can see the location of this photo and nearby ones, and it isn't true. This suggests that the template ought to be changed so it no longer makes this promise. The template remains useful because it allows the viewer to see the camera location, and it also feeds the GeoTemplate category map (at least, usually) but it isn't able to keep its main promise. Unless, of course, there's a good reason to hope it will soon stop being a false promise. Jim.henderson (talk) 23:47, 27 August 2011 (UTC)
In this moment pictures are shown in both maps:

Vermip (talk) 18:53, 29 August 2011 (UTC)

Yes! Sunday morning, the day before you wrote that, I noticed the roundels but didn't dare hope. Returning in the afternoon from a hunt for pictures of devastation by the departing hurricane, we still had them, and in the evening, and every day all day ever since then, every time I look. Well, except for about ten minutes, ending about twenty minutes ago. A short interval like that doesn't count against the idea that a severe problem, whatever it was, has been repaired or has spontaneously disappeared. It is very pleasant. I have been finding pictures for places that lacked them, correcting headings, relocating pictures to correct locations or categories, and otherwise making use of the feature. Thank you, whoever did the work, assuming this is not a spontaneous remission. Jim.henderson (talk) 00:51, 1 September 2011 (UTC)

+1 -- smial (talk) 07:32, 1 September 2011 (UTC)

That was good for more than a week, but now another week has passed without roundels for new files including File:Septuagesimo Uno inside jeh.jpg. Jim.henderson (talk) 13:46, 19 September 2011 (UTC)

I am a patient soul- but, I do find seeing roundels to be kind of satisfying- I am old enough to remember them. See if sarcasm works. --ClemRutter (talk) 21:09, 25 September 2011 (UTC)

Two weeks. Old roundels are plentiful but none for File:Lemon Ice King of Corona 52 Av 108 St jeh.jpg and other relatively recent pictures. Also no tagging bot. I think the problem is, unlike regular Wikimedia features, only one person runs each, or more likely both. When he is active, they may operate fairly regularly, but when not, there is nobody to keep them going. Perhaps eventually another competent operator will be recruited to handle those services or similar ones, or perhaps comparable geographical features will be incorporated into Wikimedia and get proper support. Some day. Jim.henderson (talk) 00:17, 27 September 2011 (UTC)

Tagging bit is inactive?! Hm, I'll have a look, but indeed I'm currently out of the country on vacation. --Dschwen (talk) 11:36, 27 September 2011 (UTC)s

I awoke a couple hours ago and was pleased to see new roundels for my recently manually tagged pictures of Queens Zoo, High Line etc. Tagging bot, however, has not yet tagged any of my uploaded EXIF geolocated pictures of Coney Island, etc. Jim.henderson (talk) 12:54, 29 September 2011 (UTC)

Six hours later I saw no roundels at all, old or new, and that's how it is right now. On different occasions we have different failures, which I think can be classified into three most frequent ones:
  1. No tagging bot to read EXIF and convert to Template Location.
  2. No template reader to convert new templates to new roundels.
  3. No roundel feeder to give old and new roundels to Google and other map servers upon demand.
When the EXIF reading bot doesn't do its job, I work around that by entering the template manually online, but when the coordinates in the template don't get sent to Google, I don't know of a way to work around. Apparently all three of these vulnerable steps are managed by one thoughtful and well qualified Wikimedia technical volunteer, but when he's not available the various parts can and quickly do break down. Jim.henderson (talk) 10:54, 30 September 2011 (UTC)
And now, the wohle http://toolserver.org/ - server is down... Vermip (talk) 12:43, 2 October 2011 (UTC)
And now everything is up, so today has been pleasant. Yesterday, no. Tomorrow, unknown. Jim.henderson (talk) 21:49, 3 October 2011 (UTC)

And, since I said that, no more bot tags. Jim.henderson (talk) 00:35, 6 October 2011 (UTC)

"The GeoCommons database is currently unavailable, please try again later.". Business as usual? -- smial (talk) 14:58, 6 October 2011 (UTC)

Google Earth was showing roundels for a couple hours yesterday. Not today, thus far. Jim.henderson (talk) 12:43, 8 October 2011 (UTC)

I tried now and it's working, but sometimes when I ask it too many times it doesn't want any more ^^ Jeriby (talk) 18:32, 8 October 2011 (UTC)

Yes, GE has been showing me roundels for five hours, which I have used to tag or adjust 20 pictures offline or on. This is the more important part of the geographical services. Whether this service is subject to overload and quit when we use it many times per hour, I have no idea. It would be pleasant also to have the bot running, which it hasn't done in the past week, but at least we can work around that. Jim.henderson (talk) 03:15, 9 October 2011 (UTC)

And now, for a couple weeks, no roundels at all, old or new, in Google Earth or Google Maps. However, GeoGroupsTemplate is still working. Perhaps it is less dependent upon Wikimedia resources. Jim.henderson (talk) 15:36, 4 November 2011 (UTC)

After a month of inactivity the bot has now been working a week, and Google Earth is showing me old roundels, but not showing roundels as added or adjusted in October or November. Jim.henderson (talk) 13:14, 8 November 2011 (UTC)

Again: "The GeoCommons database is currently unavailable, please try again later." -- smial (talk) 16:06, 30 November 2011 (UTC)
And this time yesterday, new or adjusted roundels were showing their new location and arrow within a very few minutes. So, it's highly intermittent. The improved upload wizard seems to have solved the problem of EXIF coordinates not getting read, but I have no idea whether the function of feeding coords to Google and other mappers can similarly be insourced or the intermittently operating outsourced server made reliable. Jim.henderson (talk) 01:02, 2 December 2011 (UTC)

Link commons categories of buildings to the OSM ID

Hi, I read yesterday a blog which about a feature of Flickr. (in French) [19]. In brief, photographers can link a picture to the OSM ID of the building. I think this feature could be really interesting for Commons categories in addition of the traditional and useful coord template. The advantages are center view on map of the subject and with the best scale. Otourly (talk) 19:56, 4 November 2011 (UTC)

[20] Otourly (talk) 20:16, 4 November 2011 (UTC)
Well in fact it's easy to do a template with. Otourly (talk) 20:27, 4 November 2011 (UTC)
Here is the test :

This subject has an entry on OpenStreetMap. (show) Otourly (talk) 20:38, 4 November 2011 (UTC)

I have added a parameter to choose the type of OSM's information: node, way, relation by fault it's the type way which is shown :

This subject has an entry on OpenStreetMap. (show) for the Lake Geneva. (a way is compounded of two or more nodes, and a relation is compounded of two or more ways). Otourly (talk) 21:53, 4 November 2011 (UTC)

I think it is a good idea. May be it would be a part of location/building/institution en:authority control like {{Authority control}} is for people. It also should be a part of {{Institution}}. Thanks for pointing it out. --Jarekt (talk) 23:15, 4 November 2011 (UTC)
It would be better to include this in {{Object location}}, Wikipedia or in gallery namespace. The standalone template on category descriptions needlessly clutters them up. --  Docu  at 20:21, 6 November 2011 (UTC)

Follow up (started 18:08, 7 November 2011) discussion is here: Template_talk:Location#Add_an_optionnal_parameter_for_OpenStreetMap. --Saibo (Δ) 02:10, 2 December 2011 (UTC)

Help on GPS EXIF

I had a look at Category:Media with GPS EXIF. File:Birmingham Back to Backs interior.jpg has GPS info. properly embedded but when I pull down "show extended details" in the image description it just says "North latitude, West longitude". File:Nanterre - La Folie P1000122.jpg is exactly the same. Indeed all of them are the same except for File:Addington Road Health Centre 11CT23.jpg which I uploaded today. What is happening? (File:Banco de Venezuela, Coro.JPG is even worse - it has alleged co-ordinates of 0,0!)

To save me re-inventing the wheel, can anyone point me to the code in the mediawiki software which examines an image and extracts its EXIF metadata?

The project page states that Picasa will allow you to add geographical information to images from a map. I misread this! On Picasaweb I added geographic information to this image. But when I download the image from Picasaweb I still get my original. Picasa appears to be storing the location information somewhere outside the image. — RHaworth (Talk | contribs) 20:52, 17 December 2011 (UTC)

Forget about "Extended details" the EXIF data extraction of mediawiki is broken. It does not handle geodata at all. There is a bot running daily that detects newly uploaded images with GPS EXIF data and adds the {{Location}} template. --Dschwen (talk) 23:57, 17 December 2011 (UTC)

It can't be that broken - it is working for my recent upload. — RHaworth (Talk | contribs) 22:50, 18 December 2011 (UTC)

I'm using Geosetter to add coordinates to the exif, allways the same workflow, and all my other software like exifview-plugin for firefox, or irfanview, shows correct data. But not mediawiki preview: Sometimes it works, sometimes not, sometimes incomplete. That's broken. -- smial (talk) 06:43, 19 December 2011 (UTC)
Hm, ok, it used to be 100% broken, now it seems that it got somewhat fixed. --Dschwen (talk) 22:08, 22 December 2011 (UTC)

Yes, the Upload Wizard extracts EXIF geotags well in most cases. I have used three different methods to add tags before upload. Microsoft Pro Photo Tools has good slant views which help me find a building. Format is DM.xxx which is my favorite format. Google Picasa gives higher precision, so I use it to refine rough MSPPT coords. It also converts to D.xxx which I mildly dislike. Picasa in combination with Google Earth provides good street views (in DMS.xxx format) but the wizard often fails to read its output, so I don't use it anymore to apply coords but only to improve my understanding of the locality. Jim.henderson (talk) 15:09, 24 December 2011 (UTC)

Highly biased

What does this phrase in the caption mean? Do some regions show a systematic locational offset, like, 20m to the southeast of true location? Or maybe, some have a higher percentage of ungeotagged Commons pictures? Jim.henderson (talk) 11:08, 23 January 2012 (UTC)

This, I guess.--LBE (talk) 12:28, 23 January 2012 (UTC)
Ah. So, it means some areas are sparse. Or dark. Either way yes, some areas have few Wikiphotographers and we would be glad to have more, but I'm not sure this needs saying in the caption. Anyway it's a pleasant surprize to see that almost a quarter of our pictures are tagged. Jim.henderson (talk) 03:11, 25 January 2012 (UTC)
Sounds more like the graphic represents the coverage of some areas in a biased (or exaggerated) way. --  Docu  at 18:30, 25 January 2012 (UTC)
That, I think, is a good reason for not saying our coverage is "biased", which implies a conscious decision. The reality is more like Jim suggests above, that our contributors tend to live in, and photograph, areas more close to hand than elsewhere. Unless we can find well-funded volunteers, or some funding strategy, to widen our coverage, we are stuck with whatever contributors provide of their own media, or those in the public domain for some other reason. As for tagging, nearly 7000 images are currently tagged as needing geocoding, and I suspect there are many others that could benefit from geolocation. GPS data isn't yet that common in the EXIF data of uploaded images, but this may well alleviate over time. Rodhullandemu (talk) 02:24, 28 January 2012 (UTC)
So, I eliminated the phrase as contributing naught but confusion. We have 12 million pix altogether, including ones of manufactured items sold worldwide and photographed in studio, and others lacking geographic relevance. 3 million are geotagged, and only 7 thousand await tags. Obviously almost all our pictures are of places where prosperous people live or habitually go, since the Wikimedia Foundation doesn't buy equipment or connections for photographers, or pay us to go anywhere. Judging by my visits to sellers, geotagging cameras like mine seem scarcer, not more plentiful than when I bought mine. Except smartphones, of course, which still seldom provide as good pictures as separate cameras do. Jim.henderson (talk) 00:03, 30 January 2012 (UTC)
Just wondering, do we have that many geocoded images of Iceland or is just the projection? --  Docu  at 04:55, 30 January 2012 (UTC)

commons-on-osm

commons-on-osm shows pictures on an OSM-map (great!), if pictures got location tag.

  • Pictures tagged as object location are not shown, right?
  • If object location was evaluated the tag of all object located pictures would be represented by only one single marker on the map, right?

What is the conclusion? Should we add location tag even if we know object location coordinates only?

Travus (talk) 17:13, 3 June 2012 (UTC)

No. If you simply copy "object location" to "[camera] location", you defy the purpose of "location".
You can either attempt to determine "[camera] location" depending on the picture itself or change the way commons-on-osm works. --  Docu  at 01:57, 4 June 2012 (UTC)
At the risk of repeating myself: Object location should be applied at category level, if the category exists. If the category does not exist, create it! If there is only one image, and a category thus does not make sense yet, then by all means code the image. But in that case you will only have one image per marker. Unless object location gets used in this way it is a particularly retarded way to geocode images that involves a ton of data duplication. --Dschwen (talk) 14:51, 4 June 2012 (UTC)
In some rare cases the object location is the only one possible to locate a picture (for example a picture taken from an airplane showing a monument on the ground). And unfortunately some users of Commons locate their pictures only with "object location" and undo any other user who wants to add camera location on their own files. I don't know why they do this^^. But if the commons-on-osm (and the google earth/google maps plug-in) shows only location markers, the Template:GeoGroupTemplate is able to show both camera locations and object locations (the camera are located as a blue marker, the object as a black marker). Why this difference? It would be great that osm and google earth could also show these black markers (and show only camera location on pictures which have the 2 templates). Jeriby (talk) 15:46, 4 June 2012 (UTC)
They do not own the file description pages, and it best be made perfectly clear to them. As you said, there are rare cases, where object location may make sense, although in most cases a reasonably good camera location can be deduced from the images. But all this does not affect my main conclusion above. Use {{Object location}} at category level!. --Dschwen (talk) 16:20, 4 June 2012 (UTC)
Thanks for clarification. Do you have examples for Template:GeoGroupTemplate? What about Template:Institution? Travus (talk) 19:22, 6 June 2012 (UTC)
GeoGroup only makes sense on gallery pages. For images just specify location (and object location, if you must). We had a discussion about the institution template recently, and how broken it is. It basically spams our coordinate dataset used for dispaly on maps with hundreds of points at the exact same coordinate. This is plain retarded and should not happen. --Dschwen (talk) 21:41, 6 June 2012 (UTC)

GeoGroupTemplate can be indeed used in Gallery pages, but also on Categories. On a category page you can add the template in order to show locations of the pictures in this category. Optionally you can choose the subcategories level to show also pictures on subcategories. Example here with 1 level of subcategory. Jeriby (talk) 22:24, 6 June 2012 (UTC)

Downloadable database with geocodes and titles?

Is there a place where I can download a complete list of geocoded content, including geocodes, titles and associated information for each item? PeterEastern (talk) 10:54, 15 June 2012 (UTC)

Database dumps from en:User:Dispenser's GHEL project are available at http://toolserver.org/~dispenser/dumps/ . May I ask what you intend to do with this data? If you are making a project that is potentially useful for many commons/wikipedia users you might consider applying for a Toolserver account. You'd have direct access to SQL databases containing this data, and copies of the wikimedia wiki databases. --Dschwen (talk) 16:35, 15 June 2012 (UTC)
  • Thanks for responding. My company, ITO World, does a lot of map work with OpenStreetMap content and we have been working on some maps that show both geocoded Wikipedia content and OSM content together with a view to helping people improve the geocoding accuracy and completeness of both projects. We were alerted to the amount of geocoded content in Wikipedia Commons content by a tweet a few days ago and it is clear that we should integrate WC content into our service as well. We will indeed apply for a Toolserver account and will aim to get something online for general usage soon. PeterEastern (talk) 23:49, 15 June 2012 (UTC)
  • Just taken a look at the English file from the aboce download site and it contents seem to be geocoded Wikipedia content (which we already have) and not geocoded Wikipedia Commons content which we are after. Have I missed the point? PeterEastern (talk) 00:05, 16 June 2012 (UTC)
  • Yes, the commons content is in coord_commonswiki.sql.gz, not the english wikipedia file. And do you know about the various existing projects that superpose geocoding data on maps, like the WikiMiniAtlas? --Dschwen (talk) 00:10, 16 June 2012 (UTC)
  • Of course, sorry about that, I missed the commons file in the sea of wikipedia files for different languages. Yes, I am familiar with WikiMiniAtlas but we are currently focusing in on cross referencing information in Wikipedia/Commons/OSM to help people investigate and sort out inconsistencies and omissions across the different projects, which some something I am not aware of anyone else doing. For example: 1) a place in OSM has a different coordintate from the geocode for the same place in the Wikipedia article. 2) A monument with a Wikipedia article is not on OSM. 3) A Museum on OSM does not have a link to the related Wikipedia article. etc etc. Specifically I am following up on this tweet which read "RT @peter_weis : @openstreetmap data visualisation: http://www.itoworld.com/static/data_visualisations.html via @itoworld Wouldn't that be epic for ‪#GLAMwiki‬ partners?". Possibly I should continue this conversation on the GLAMwiki project page now that I have access to the data we need? PeterEastern (talk) 10:17, 16 June 2012 (UTC)

Coordinate duplication

/* Count the number of coordinates that occupy the same point
 *
 * Run time: About 1 minute
 */
SELECT COUNT(*) AS Duplicated, gc_lat, gc_lon, gc_name AS Example
FROM u_dispenser_p.coord_commonswiki
GROUP BY gc_location
ORDER BY COUNT(*) DESC
LIMIT 25;
Duplicated Lat Lon Example
84,545 39.000308 -76.959665 Category:National Archives at College Park
78,259 40.752700 -73.981800 Category:New York Public Library
34,719 38.892781 -77.022975 Category:National Archives and Records Administration
19,218 39.296077 -76.615305 Category:Walters Art Museum
8,013 48.860395 2.337599 Artwork:Kaufmann Head - Louvre Ma 3518
5,181 40.671139 -73.963453 Category:Brooklyn Museum
2,852 51.291123 0.159301 File:10rrejx - Flickr - The Car Spy.jpg
2,471 43.661667 -79.395000 Category:Thomas Fisher Rare Book Library
2,308 51.519444 -0.126944 British Museum
1,790 40.7 -74.0 File:"SUPER" FLUSHES LITTER FROM 172ND STREET WITH FIRE HYDRANT WATER - NARA - 549838.tif
1,734 52.359969 4.885325 Category:Rijksmuseum Amsterdam
1,571 59.941000 30.312900 Category:Hermitage Museum
1,445 40.413689 -3.692297 Category:Museo del Prado
1,432 43.768639 11.255214 Category:The Birth of Venus
1,430 48.861944 2.394167 Category:Grave of Pierre Perrin
1,355 52.232267 21.005945 File:Flickr - europeanpeoplesparty - EPP Congress Warsaw (1165).jpg
1,350 51.508600 -0.128300 Category:National Gallery, London
1,330 40.779447 -73.963110 Category:Metropolitan Museum of Art
1,229 43.593948 1.44914000 Category:Biface from Algeria - MHNT PRE.2009.0.196.4
1,223 43.609325 3.88468000 File:Éric Herenguel - Comédie du Livre 2010 - P1400127.jpg
1,128 48.805000 2.11944400 Category:Palace of Versailles
1,108 50.859771 -0.753078 File:???? - Flickr - exfordy.jpg
1,089 43.593897 1.449229 File:Édouard Filhol Projet Phoebus.jpg
1,020 59.329167 18.093333 Category:Nordiska museet
1,020 48.203661 16.361378 Category:Kunsthistorisches Museum

Templates such as {{Institution:New York Public Library}} should at least have &title=/|name= so to avoid marking this location as the primary point for these images. —Dispenser (talk) 01:31, 18 May 2012 (UTC)

Wow, this is messed up. That template should contain the coordinates wrapped in noinclude or better not at all. It should be policy that this type of geocoding only be limited to categories and under no circumstances spill onto file pages. --Dschwen (talk) 02:33, 18 May 2012 (UTC)
See also Commons_talk:Geocoding/Archive_3#Eiffel Tower in Brooklyn. --  Docu  at 18:21, 18 May 2012 (UTC)
I'm written code to unset the primary flag for clusters. Unfortunately this steamrolls any legitimate markers in the area, but given how slowly things move its a better. —Dispenser (talk) 06:19, 20 May 2012 (UTC)
Institution templates with coordinates do not use {{Location}} templates and are not meant for geocoding images. They are using separate {{Institution/coordinates}} template, and I do not think anybody looking at the file description would be confused about it. See for example here, that file have 2 locations: one for the there the image was taken and one for where is the institution that holds it. If this is confusing to some automatic processes, we can add stuff to that template to tag the links or mark them in some way to make sure the situation is clear. --Jarekt (talk) 01:27, 4 June 2012 (UTC)
If I filtered out pages with {{Institution/coordinates}} would remove valid coordinates as well, such as your example. And I'm not writing and maintaining an extraction program for each of the 70+ wikis I support and Wikipedia-World, WMA, and Wikilocation want to avoid reinventing the wheel. So there needs to be some easy differentiator in this list, something like _class:location-spam or _type:institution-spam. —Dispenser (talk) 23:48, 15 June 2012 (UTC)
I've gone ahead and unlinked the coordinates in the template as they're redundant to the linked Wikipedia page. This should also help with error correction work. Dispenser (talk) 04:24, 23 June 2012 (UTC)

I reverted this edit. The purpose of providing coordinates to all the institutions is so they can be easily located. Your edit broke links on 400k files, including links to google maps, OSM, polygons defining building outlines and links to OSM pages for the institutions. Please do not do this kind of edits without discussing it on relevant template talk pages first. Sorry I missed your reply here but I stopped checking after a week of silence. I like the idea of differentiator better. We already use _class:object for {{Object location}}s and _type:camera for camera {{Location}}s (why one uses word class while the other uses type?). So I added _type:institution to the links generated by this template. Should we add some differentiator to links generated by {{Inline coordinates}}? --Jarekt (talk) 04:18, 10 July 2012 (UTC)

(edit conflict) How is transcluding (then collapsing!) pages from the Institution namespace more useful than linking to the institution page (still one click)? The only explanation that makes sense in my eyes is an w:SEO linking scheme to benefit institutions. I unlinked it as I saw no value and realizing that 400k junk coordinates (~13%) were to be extracted, processed, and stored to be thrown away. It also unmasks other cleanup work (e.g. 63k type:landmark of 75k type:camera overrides and duplicate point work). The _class: is a remnant from WikiMiniAtlas extraction system, we are currently using as extra error checking information. {{Inline coordinates}} doesn't have documentation on how it's meant to be used, but I'd suggest adding _class:reference (mention). —Dispenser (talk) 01:18, 11 July 2012 (UTC)
I do not like new changes to the Institution template, they do not solve the basic problem that most coordinates are meant to be clickable and having them working in some namespaces and not working in other is very confusing. I also do not like making undiscussed changes to a template used by 400k files. Common practice is to test such changes in sandbox first so a consensus can be reached. As I mention I added _type:institution differentiator to links generated by institution templates. Was there a problem using this differentiator the way it is done with {{Object location}} template? --Jarekt (talk) 00:58, 11 July 2012 (UTC)

Remove_type:landmark_from_Template:Location

See Commons:Bots/Work_requests#Remove_type:landmark_from_Template:Location for discussion related to geocoding. --Jarekt (talk) 17:39, 6 August 2012 (UTC)

Location not applicable

There are categories that only contain images that do not contain location information. Should the Category:Location not applicable be added to these categories, or to each individual file in the category? See for example my edit http://commons.wikimedia.org/w/index.php?title=Category%3ALocator_maps_of_municipalities_in_Landkreis_Goslar&diff=77287853&oldid=69158705 . Now i am unsure if that was a good idea. --Gormo (talk) 18:20, 4 September 2012 (UTC)

I agree. I also do not see much meed for Category:Location not applicable since we would have to add to that category large fraction of files/categories we hold on Commons. Does anybody use that category? --Jarekt (talk) 18:47, 4 September 2012 (UTC)
I rail instinctively against negative categories, if only for the size they might grow to be, but looking at the talk page and accompanying deletion discussions, I'm not convinced of its uselessness. It prevents a bot, for example, adding a "geocoord required" template, and the only difficulty with this category I see is that the various upload bots aren't clever enough to determine that, and the various other uploaders don't realise it's available to prevent that happening. However if a category (as opposed to a file) is never going to contain geolocatable content, I don't see a problem with categorising the category as such. Rodhullandemu (talk) 19:04, 4 September 2012 (UTC)
It is used by the Commons geocoding to-do tool. --AVRS (talk) 19:24, 4 September 2012 (UTC)
This seems to be the main use of the category.
BTW, I don't understand the sample in the initial question. It seems possible to geocode files in Category:Locator_maps_of_municipalities_in_Landkreis_Goslar. --  Docu  at 11:42, 9 September 2012 (UTC)
Well, as they are maps, they do posses geographic information. I only thought about the Location template, which clearly specifies that the Location where the media was recorded should be used. As this location is not meaningful in a map, maps cannot (my understanding) sensibly geocoded with the location template. They could, however, be geocoded by different means (corner coordinates, etc.). SO: oops, my bad. Bad example. Take this as a better one. --Gormo (talk) 13:11, 11 September 2012 (UTC)
We have {{Overlay}} for maps and areal photos. You could also use {{Object location}} although it would be a stretch to do so. --Dschwen (talk) 16:10, 11 September 2012 (UTC)

Endangered species

Hi, the issue of endangered species has come up a few times on this talk page (e.g. Commons talk:Geocoding/Archive 2#Precision, and elsewhere, and it is an exception at Commons:Valued image criteria. I am sure everyone agrees that we need to provide a location with endangered species, and that geocoding is the most accessible way to provide the location. However the geocode needs a lower precision for endangered species, and we should add guidance to Commons:GEOCODE#Precision. There may even be laws about reckless endangerment that could apply. e.g. USA has a federal w:Endangered Species Act, and Western Australia has Endangered Species Protection Act 1992 (Cwth). John Vandenberg (chat) 02:01, 13 September 2012 (UTC)

That is why we have Template:Rare species location. --Jarekt (talk) 03:31, 12 December 2012 (UTC)

Reverse Geocoding

What if we use a reverse geocoding tool determine the adress from the coordinate? So there exist nominatim as part of OpenStreetMap project. It gives for this image the following informations[21]:

National Center for Studies and Documentation, شارع خالد بن الوليد, North Remal, Gaza, 970, Gaza-Streifen
building:National Center for Studies and Documentation
road:شارع خالد بن الوليد
suburb:North Remal
city:Gaza
postcode:970
country:Gaza-Streifen
country_code:il

A bot could import this information and we could use it in our fulltext search. Information about the streetname is not on the description page and so not avialable. To not confuse the user, the information could be hidden in template and have a warning that it's not 100% correct.

Largest problem I see in the license of OSM (ODBL), if applicable. Perhaps we are able to use the OSM data license conform [22], by setting the part of the description page with this data under ODBL.

Alternative we could open little iframe on the page to deliver address, but this seems not so useful for me.
Comments? --Kolossos (talk) 19:45, 11 December 2012 (UTC)

That sounds like an useful capability. I think it might be more useful for Categories that only have partial descriptions, but it would be quite useful in case of the image you mentioned. We could provide it inside some collapsible template which could also mention the license. --Jarekt (talk) 03:36, 12 December 2012 (UTC)
What is the quality of the data in OSM? Last I checked it was lacking (to put it mildly). --Dschwen (talk) 05:28, 12 December 2012 (UTC)
There's two problems I can see (leaving aside the unreliable data quality, even in Western countries). First is this only makes sense for urban imagery, not the substantial fraction of rural stuff. Adding a street to a picture of wilderness is somewhat bizarre, if not downright silly. A second problem, which is a bigger issue in urban locations, is geocoding is done by camera location. Description and categorisation is (primarily) by subject location. eg this file returns this street. If someone uses a search to look for images of West 33rd Street and it returns that image of the Empire State, then at best that image is noise to ignore and at worst they may assume the Empire State is on West 33rd. Not a good example - but then the geocoding is clearly wrong there ;)
In short, I'd be very cautious about using geocoding to provide address info for files. However, this task may make more sense for geocoded categories.--Nilfanion (talk) 12:42, 12 December 2012 (UTC)

Low quality photos of bike infrastructure with geoinformation wanted?

I have and I am taking photos of bike route infrastructure in Brandenburg, Germany. The photos are technically quite bad. They are useful for my purpose to plan a new bike route, however. I'm geocoding the photos manually. What do you think: are these photos within Commons' scope despite the bad quality? Please check a few of the photos at [23]. The photos there are only thumbnails. I would upload the original jpegs to Commons. Nillerdk (talk) 08:48, 23 December 2012 (UTC)

Sure, why not. If those pictures are just the thumbnails then the original pictures will already be better than the Geograph.co.uk pictures that were uploaded here a while ago. It would be nice to get as many pictures on the map. The very least this does is giving context to other images (like a cheapo StreetView ;-) ). --Dschwen (talk) 20:07, 23 December 2012 (UTC)
Ok, thank you for your opinion. I will start uploading them this year (-; Nillerdk (talk) 18:21, 1 January 2013 (UTC)

Android

I am not surprised that the stock software of my new Samsung Galaxy Tab 2 10.1 lacks the ability to add or adjust geotags or even to show the location of an already tagged picture. In Google Play I see many apps that claim to do these things, but before I start downloading and trying them, is a more experienced Android user able to offer suggestions, guidance or informed opinions? Jim.henderson (talk) 15:21, 10 February 2013 (UTC)

When I look at maps such as http://toolserver.org/~kolossos/openlayers/commons-on-osm.php?zoom=12&lat=32.369444444444&lon=119.39444444444 , I see that they only reflect Commons images that have Template:Location, but not those that have Template:Object location. I am aware that using Template:Location is considered more "correct" than Template:Object location (and for good reasons), but in practice many images do have the latter template (and for good reasons too: often it's pretty clear where the pictured object is, but it is not as easy to guess where the photographer stood). Would it be possible to enhance tools such as http://toolserver.org/~kolossos/openlayers/commons-on-osm.php to reflect images with either kind of tag? -- Vmenkov (talk) 19:26, 12 January 2013 (UTC)

P.S. It also would be nice to have options for displaying, on the same map:

Indeed it would be great, I agree. Meanwhile it's possible to use Template:GeoGroupTemplate, for example on a whole category (for having a good look of a particular region, then choose the region category and its subcategories with "level" argument on this template, and it would show almost the same pics than the other commons tools) with the object locations too! Depicted with black roundels instead of usual blue ones. Just a little problem: the GeoGroupTemplate shows only on Google Maps and Bing Maps, it would be great to show also on OSM. About your example, you can show this and you can see Location and Object Location roundels for Yangzhou . Jeriby (talk) 19:51, 12 January 2013 (UTC)
{{Location}} is more correct for tagging images. To permit the use of {{Object location}} on images was mistake. It has led to a confusing situation for the users and to a degradation of geotagging quality. However, use of Object location on Categories is fine. I'll look into putting categories on the map as well. --Dschwen (talk) 18:17, 12 February 2013 (UTC)

Dead images

Using the Google Earth tool, I can find one of my images on the map near 51 28 50 N 2 38 54 W, IMGP7953_(3212682937).jpg. Only problem - I moved this image without leaving a redirect 2 months ago, and changed the geocode on the new name. So this nonimage with a bad geocode is showing, and the renamed one with correct geocode isn't. It's not a server update issue, as more recent images are there. -mattbuck (Talk) 05:13, 15 January 2013 (UTC)

File:Montpelier railway station MMB 12 (1).jpg, a deleted duplicate of a different file, also shows up, as do many, many others. -mattbuck (Talk) 06:51, 15 January 2013 (UTC)
Indeed I noticed also that on Google Earth tool we can see roundels of deleted pictures, and roundels of pictures with erroneous coordinates that have been erased from the picture page but without new coordinates (when we don't know where it is, but we know that this is not on the place the roundel is). The system seems to be different from the wikipedia layers, these ones take a long time to be updated but the old erroneous coordinates are deleted, whereas the Commons tool updates nearly in real time, but erroneous coordinates are deleted only if we have corrected them with new coordinates. Jeriby (talk) 17:08, 15 January 2013 (UTC)
The WikiMiniAtlas has a more up-to-date coordinate database. --Dschwen (talk) 16:28, 4 February 2013 (UTC)
WMA indeed has merits compared to GE, including smaller and more informative roundels. However, the great concentration of thumbnails that I see create difficulties using them. Is there a way to turn them off and still see the roundels? Jim.henderson (talk) 00:51, 12 February 2013 (UTC)
not yet, but this would be trivial to implement. good suggestion. --Dschwen (talk) 05:10, 12 February 2013 (UTC)
And maybe if we could improve zoom levels, because we can't see all pictures of a place where there is many many pictures (in a downtown for example), or maybe I don't know how to do^^. Jeriby (talk) 17:47, 12 February 2013 (UTC)
There is virtually no limit on zooming in WMA since I implemented client-side rendered tiles. Which browser are you using? This unfortunately won;t work in old Internet Explorers <=IE8 --Dschwen (talk) 18:08, 12 February 2013 (UTC)

please have a look at this discussion. there are already users who change precise coordinates to less precise ones (by removing .xx bits at the end if in minute/second format) to circumvent displayed errors. i think that the location templates should be fixed so that we can still use exact coordinates, or those coordinates should be transformed into decimal format consequently. Holger1959 (talk) 02:59, 2 May 2013 (UTC)

Toolserver to WikimediaLabs transfer

Fewer and fewer tools running on toolserver are still running. Geohack used by most of our geocoding templates was still operational, but I noticed that the its clone on WikimediaLabs is already running and I updated {{Coor URL}}. --Jarekt (talk) 12:44, 5 June 2013 (UTC)

Introducing new {{Map}} template

Introducing new {{Map}} template. Please come and help designing and developing it. --Jarekt (talk) 13:40, 20 June 2013 (UTC)

Building new photo loc templates

Why not indicate further information on what information the geo data is based upon? I have the following templates in mind:

The following Geo data was added according to EXIF data and the location has been approved: <coord>
The following Geo data was added manually and the location has not been approved: <coord>

or similar ("approved" would mean the geo data is true (according to reality, not EXIF). Readers must evenutally trust the approval (which could be set by anyone, even if that user did not perform a check, so that remains a little problem.) At a glance, no one knows what the geo data in a file is based upon (and if it's according to reality). What do you think? Thanks for your comments. --Mattes (talk) 12:47, 6 July 2013 (UTC) see also User_talk:Life_of_Riley#Geo_data_templates

Details on coord provenance can indeed be valuable to us geocurators. I mostly do historic building images in my home town, where coords are often wrong for a number of reasons:
  1. Database errors in official monumental lists.
  2. Lists giving the location of the museum or other repository that supplied an old picture, rather than the depicted object.
  3. Commons editors mistaking an object location for a POV location (or more rarely vice versa).
  4. Commons editors (this time including me) failing to catch our own typos, paste errors, or misidentifications.
  5. GPS inaccuracy.
Anytime I look at a picture or Wikipedia article that has a location, I bring up Google Earth. Often I make a small or less often a large adjustment, and the explanation is usually just in the edit comment. So, yes I can see the need for more information. Problem is, I don't see how your method of three templates suffices. For one thing, who "approves"? Admins? It seems highly improbable. Any editor except the original coord inserter? Perhaps more difficult, don't we need more details, which means either more templates or a less clumsy method? Jim.henderson (talk) 23:07, 7 July 2013 (UTC)

Use of the information

Point 4 doesn't work. :-( --Andreas Schwarzkopf (talk) 10:19, 13 August 2013 (UTC)

Sorry, now I discovered the hidden link. :-) --Andreas Schwarzkopf (talk) 11:05, 13 August 2013 (UTC)

Wrong Location with Automatic procedures

"the Upload Wizard adds the proper Geocoding Templates from the GPS data stored in your images"

Sometimes this kind of automatic procedure gives a very approximate location. not sure that it is very useful. by exemple, automatic procedure point to a location in the middle of a city, for a place that is somewhere around in that city. it is enough to indicate the city in the categories, this kind of location is useless. Moreover, it is misleading because it can make people believe that it is accurate information and they will not give it if they have actually the accurate information. so I suggest that this approximate location should be deleted as soon as the correct category is found.

to give an exemple : some photos with GPS data were taken in the jewish quarter of the old city of Jerusalem. the automatic procedure add the same geocoding located in the middle of the neighborhood for all the photos. when the appropriate category is found (ie "Category:Jewish Quarter, Jerusalem"), this approximative location is useless and misleading.

At least it must be clearly stated with a special mention, that this location is approximate, and not accurate.

Djampa (talk) 11:41, 21 August 2013 (UTC)

However, if EXIF comes from an automated process, for example the GPS in my camera, it is usually given with many digits indicated precision, regardless of how many satellites were in view or whether Wi-Fi confirmation was available. This means there's no automated way for Commons to guess whether the location is correct within the breadth of a hand, or on the wrong side of a street or town. So yes, provenance should be indicated as EXIF or whatever other source the coords may have, and perhaps there should be some way of flagging for human check. Jim.henderson (talk) 12:45, 21 August 2013 (UTC)
Note, sometimes the exif will have the GPSDOP field, which can indicate how precise a measurement it is. Bawolff (talk) 09:04, 31 August 2013 (UTC)
I never heard of the DOP field, though that's not a surprise. Is it rare in photos uploaded to Commons? Jim.henderson (talk) 23:42, 1 September 2013 (UTC)

Display camera headings on maps

Hey there,

a question came up at Commons:Forum#Richtungsangaben: In the location-template(s), one can use the heading:-parameter to specify the camera heading. However, only the WikiMiniAtlas makes use of that so far. Isn't there any way to forward the heading to – let's say – OSM or Google Maps and make them display some kind of arrow pointing the direction instead of the default map marker? --El Grafo (talk) 10:24, 2 September 2013 (UTC)

Good idea. Google Earth for Windows also shows roundels with arrows; indeed that's the principal method for my frequent adjustments to picture heading parameters. The loss of the Wikipedia layer in Google Maps for Android last month makes me doubt, however, that Google will take much interest in improving its coverage of Wikiprojects in general. So yes, I would be very pleased if OSM could be improved and put on my smartphone with optional layers for Wikipedia articles and Commons photos including direction pointers. Jim.henderson (talk) 15:41, 2 September 2013 (UTC)
Maksym Kozlenko (User:Maxim75) maintains a mappable database of geocoded images from Commons and other sources.[24] Unfortunately, it doesn't seem to show camera headings. Perhaps, he would be willing to add that feature. --Walter Siegmund (talk) 17:15, 2 September 2013 (UTC)
user:dispenser has the most comprehensive and current coordinate extraction project, it's called GHEL. Using his db this is trivial. ---Dschwen (talk) 01:48, 3 September 2013 (UTC)
Thanks for the replies and thoughts about Wikipedia Layers etc. I don't want to stop you thinking in that direction, but I was actually thinking about something more relevant for the everyday visitor: the links provided through the {{Location}} template. Let me show you an example:
  1. File:Cranbury, New Jersey 005.jpg has a {{Location}} with heading:SSE.
  2. when I click on the coordinates provided at the file description page, I end up at the GeoHack tool at wmflabs: [25]
  3. If you examine the URL, you will see that it contains the heading as well: …heading:SSE…
  4. when I then click on the two most prominent links at the top of the page (View this location …), I end up at Google Maps or OSM.
They both show the location of the photograph with the usual map marker. While other things which can also be set in {{Location}} (such as the region or zoom level) are being "forwarded" to the map provider through the URL, the heading is being dropped → question: Why? I'd guess that they (Google, OSM) simply don't provide the option of changing the map marker into an arrow showing a heading? Then there's probably not much we can do, at least when it comes to Google. --El Grafo (talk) 09:28, 3 September 2013 (UTC)
Just use the direct links to Google Maps or OSM in the {{Location}}. They provide heading markers. --тнояsтеn 06:51, 19 September 2013 (UTC)

Heading would be a nice addition to photo details. As far as I know, there is an EXIF tag to store that information, but I don't know any camera application which stores that data when photo is taken.

--Maxim75 (talk) 13:16, 12 September 2013 (UTC)

There are some hot-shoe-mounted GPS-units which communicate directly with the camera and store at least the coordinates in the EXIF, and I think the Pentax O-GPS1 (which I intend to get for my K5 as soon as I find that pot of gold at the end of the rainbow) also stores the heading. Nifty! --El Grafo (talk) 16:08, 12 September 2013 (UTC)

Easier if you buy a camera with GPS built in. My Nikon AW-100 has GPS with magnetic compass, and its location and heading are pretty reliable, sometimes even in the inner city. Alas, it barely qualifies as a mediocre camera. My Nikon P330 is a much better camera, but it has no compass and often it fails to record even the location. My HTC EVO V4G camera phone is the most reliable for reporting its location, but doesn't record the heading of the built in magnetic compass, and it makes really poor pictures. Sometimes I snap a picture with two cameras to increase the chance of good photo and good EXIF. Does anybody know of a mediocre or good camera with good GPS and heading? Jim.henderson (talk) 23:04, 13 September 2013 (UTC)

Mobile maps

My main way of finding unillustrated Wikipedia articles in the field is by Google Maps for Android, showing the Wikipedia layer and going from one W mark to the next, snapping the pictures. However, Google is getting rid of that feature. Could we get a mobile app to replace it? If you take a look at our sister (or customer) project Wikivoyage, you'll see a square on the right side of voy:Lanai which leads to a Voyage map of the central city. Could that become the basis? Even better if it could also show arrow roundels or other symbols for existing geotagged pictures. Jim.henderson (talk) 01:46, 15 September 2013 (UTC)

GeoLocator tool

Hello!

For those who are used to GeoLocator tool, it seems it doesn't work for some days. A script which seems to be from Google Maps (gstatic.com) uses the CPU until we can force script's stop. Do you have the same problem? I hope it will work again in some days^^. Jeriby (talk) 23:46, 22 November 2013 (UTC)

I've tried again, and it seems the bug is only on the global world map when starting to use the tool. I stopped the script but I entered coordinates in the field, then clicked on "apply" and the map finally appeared. Great that it can work anyway^^. Cheers. Jeriby (talk) 03:15, 23 November 2013 (UTC)

OpenStreetMaps

Silly question from a grey-hair Google maps geolocator. How do I extract the location of the pointer in Commons location tag format. What is the equivalent in firefox of the javascript:void(prompt('',%22{{location%20dec|%22%20+%20gApplication.getMap().getCenter().lat().toFixed(4)%20+%20%22|%22%20+%20gApplication.getMap().getCenter().lng().toFixed(4)%20+%20%22}}%22)); applet. We are obviously good mates with the OpenStreetMap crew- they link to this page, It would be nice to move over but has it been written? Is it a secret? --ClemRutter (talk) 22:10, 23 December 2013 (UTC)

In firefox we store such "applet" in a bookmark (mine is " javascript:void(prompt(,"{{location%20dec|"%20+%20gApplication.getMap().getCenter().lat()%20+%20"|"%20+%20gApplication.getMap().getCenter().lng()%20+%20"}}")); "), you bookmark some random page (Crtl-D) and later replace the URL with the javascript code above. I put my bookmark on he bookmark toolbar. --Jarekt (talk) 12:40, 24 December 2013 (UTC)

Forcing updates

Is there a way of forcing an update to a KML file when its underlying category has changed? It would be useful when using a map to diffuse large categories that ones you've already dealt with are no longer shown. Cheers. Rodhullandemu (talk) 23:28, 18 January 2014 (UTC)

It seems in the Google Maps export tool URL there is a property called "usecache", I don't know if it's what you looked for, but when usecache=0 the KML file downloadable is updated. Jeriby (talk) 00:23, 28 January 2014 (UTC)
Thanks, I'll try that. Rodhullandemu (talk) 00:47, 28 January 2014 (UTC)

Understanding GPS precision

I was wondering how exactly "Measurement precision" in EXIF metadata works. My Camera has an in-build GPS receiver, so many of my photos are geo-tagged, but obviously precision varies. Some of my shots out of a car a off by quite a bit (e.g. this, shot out of moving car) while others are very precise (e.g. this, confirmed it on a map). So far so good. But the "Measurement precision" in EXIF data doesn't correlate with the actual precision at all. In both photos, it is "Poor (50)". In others, it is "Poor (4.2)". In none of my photos it seems to be anything but "Poor".

Does the number correspond to what is described here? If so, then 4.2 is actually Good, not Poor. Or am I missing something? And why is the precision "Poor (50)" even in the picture with precise coordinates mentioned above? Best regards, --Tobias (talk) 10:53, 6 February 2014 (UTC)

I don't know, and don't see great reason to worry as it only attempts to measure GDoP which is a minor source of error. For the thousands of GPS photos I have uploaded to Commons, I don't trust the automatic location. I completely ignore the indicated precision. Every single picture, I check and adjust by map. Most of them, twice. First, by Microsoft Photo Tools before uploading. Second, by Google Earth after uploading. Most my photos are urban with tall buildings all around, or with trees overhead, or I don't know what else is making errors of 10m or 30m or sometimes more and don't care. GPS is only a first guess and always must be compared to maps. Jim.henderson (talk) 14:30, 6 February 2014 (UTC)

Why are there links to google maps and google earth?

"View this and other nearby images on: OpenStreetMap - Google Maps - Google Earth". Google is a commercial provider such as bing or others. Does google pay more money to wikipedia or what is the reason to support this quasi-monopolist? --91.0.169.170 10:53, 31 January 2014 (UTC)

Google does not support Wikimedia in any way (beyond not blacklisting us anyway). I imagine the Google Earth link is there because it's a common piece of software. -mattbuck (Talk) 11:38, 31 January 2014 (UTC)
Google does not support Wikimedia in any way really? That doesn't reflect that view. 87.78.29.43 17:29, 11 February 2014 (UTC)
If you click on the coordinates you will find dozens of map providers. But those links are unique because several tool developers managed to create servers that can store image locations in some big database and display on those maps locations of other nearby images. Go to Category:Times Square and click on the links in the {{Object location}} template, also try clicking on the globe with the down arrow. --Jarekt (talk) 12:59, 31 January 2014 (UTC)
Typing from my Win 8.1 RT tablet which has built in Bing Maps and can't run GE. I would be very pleased if we had similar support for this. Presumably it would take a lot of work which, since this setup is less common, won't be done anytime soon. Jim.henderson (talk) 14:25, 31 January 2014 (UTC)
I do not know much about Win 8.1 RT tablet but you should be able to access Google Maps through your browser. I assume that if someone creates server that works with Bing Maps than we will add it too. Although we might run out of space for full names and would have to use icons for each map provider. --Jarekt (talk) 15:26, 31 January 2014 (UTC)
Yes. I make do with the Google Maps Web site. It's not bad. The Bing Maps app, however, is better, in similar ways and to a similar degree that the Google Earth app is better than that company's mapping Web site. Faster, for one thing, on my slow connection and slow tablet processor. Maybe the internal BM app will some day be supported in Commons, though what I would like even better would be support for a similar Open Street Maps app for my tablet. Alas, no such app is likely to exist soon, even for Android or iPad, much less any connections between it and our various Wikimedia apps. Jim.henderson (talk) 02:43, 1 February 2014 (UTC)

Google Earth tool broken

The page linked for the Google earth geocoding tool is now a 404, so it doesn't work anymore. -mattbuck (Talk) 15:20, 1 February 2014 (UTC)

Comment out or remove? --Dschwen (talk) 15:28, 1 February 2014 (UTC)
I just tried the link on Commons:Geocoding and it seem to work just fine. I do not see any problem --Jarekt (talk) 20:07, 1 February 2014 (UTC)
It's 404 for me. Is there any chance of some sort of add-on to just generate it from GE without going via an external website? -mattbuck (Talk) 20:20, 1 February 2014 (UTC)
To clarify, the link seems to be working, but the tool isn't. -mattbuck (Talk) 15:19, 6 February 2014 (UTC)

The tool link we can see directly on file pages seems to work (it links toward toolserver, example.) But the link we can see in the detailed tools page (example) links to an external site like this. If the alder-digital.de site is temporary broken we can wait, but if it's definitely broken, we may replace this by the toolserver link which still works. If someone has administrative rights to edit the GeoHack page, I also noticed that we could update the ViaMichelin link (still works but not exactly the same URL, must replace ".com/search/Cartes" by ".fr/web/Cartes-plans" for French version and ".com/web/Maps" for English version. Jeriby (talk) 20:35, 1 February 2014 (UTC)

www.alder-digital.de link works for me. --Jarekt (talk) 16:36, 6 February 2014 (UTC)

Hooray, it appears to be working again! -mattbuck (Talk) 21:44, 11 February 2014 (UTC)

Future of Toolserver and Geocoding tools

Is there anyone working on moving the tools to WMF labs? In the location template I see two tools still on the Toolserver, just Geohack was moved. If the Toolservers goes off so do the important tools. --Denniss (talk) 20:41, 23 May 2014 (UTC)