Commons talk:Geocoding

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

Template:GeoPolygon not working[edit]

I just noticed that Google Map display of object outlines provided by Template:GeoPolygon and written by @Dschwen: does not work anymore. Same with "geopoly" parameter in {{Institution}}. Probably the same issue that does not allow us to display nearby images in Google Maps, see here and lead to removal of Google Maps link from {{Location}}. For issues with Template:GeoPolygon see for example Category:Place du Bouffay or Institution:Cimetière du Père-Lachaise: Google Maps link does not do much but OSM link works. {{GeoPolygon}} wasn't used much since user:Dschwen wrote it 7 years ago, but I always liked this tool. Is it going to be restored (rewritten?) or should we remove those options from the templates as we did with "nearby location link" in {{Location}}. --Jarekt (talk) 13:03, 12 March 2015 (UTC)

Since Google decided to remove kml support from Google Maps, it currently doesn't make sense to have a link to Google. From what I've read, re-writing it could take quite some time, so it's probably best to just remove it for now. Unless you want aerial images, OSM is usually superior anyway. --El Grafo (talk) 13:48, 12 March 2015 (UTC)
I often take outdoor photographs and in many cases OSM has nothing about the locations, see for example OSM link in File:Joshua Tree - Room to Shroom.jpg. For such files aerial photograph is the only way to go. --Jarekt (talk) 16:13, 12 March 2015 (UTC)
@Jarekt: Totally agree with that. Since KML still works in Google Earth, why not add a link for that? If it works with {{location}} it should work with {{GeoPolygon}} as well. I dissected the url for the KML from the Google maps link of your example, downloaded it to my HD and opened it in Google Earth – works perfectly. All that needs to be done is to change the link to Google Maps to directly point to the KML file and the name of the link to Google Earth and you should at least have the same functionality as with {{location}}. Can't seem to figure out how to do this, though … --El Grafo (talk) 10:07, 13 March 2015 (UTC)
Also, for viewing stuff directly in the browser with aerial images, we could simply switch to Bing maps: Base URL is, just append the url to the KML to that: Would probably work for {{location}} as well. --El Grafo (talk) 10:17, 13 March 2015 (UTC)
I think I got it. For example Category:Place du parlement de Bretagne generates link #1 to which is converted to link #2 to google maps, and which is dead. But we could change it to the link #3 to Bing and tht one works. I do not think that is something I can change on this end. I think that is something user:Dschwen would need to change on wmflabs.
--Jarekt (talk) 12:11, 13 March 2015 (UTC)
@Dschwen: Do you think that would be possible without too much of a hassle? --El Grafo (talk) 11:15, 4 May 2015 (UTC)

I just checked and {{Overlay}} template for overlaying images on top of maps using KML format also does not work. Neither Google earth, Google Maps or Bing link. See for example File:Albertstadt Map 1895.jpg. --Jarekt (talk) 13:10, 12 March 2015 (UTC)

Geotags for non-geographical images[edit]

Hi, folks. User:Junkyardsparkle has been doing a lot of "Commenting out geotag for non-geographical image"s for images of celebrities, book signings, etc. I'm not sure that's the best idea. Clearly the most useful use of geotags is for geographical images, landmarks, monuments, landscapes, buildings, etc, but I always thought it could be useful to have geotagged images of book signings, celebrity appearances, and such, to see what happened in such and such a place. In any case, Commons:Geocoding should say, one way or the other. So we've decided to bring it up here. Look well, O Wolves! --GRuban (talk) 13:23, 1 May 2015 (UTC)

I find geotags on images like this or this to be totally useless, because the picture could have been taken anywhere in the world. If the location is embedded in EXIF I would leave it alone. Otherwise I think it is waste of time to either add or remove them, but if someone else wants to do it, it is their time. --Jarekt (talk) 15:35, 1 May 2015 (UTC)
What I was kind of hoping to propose here, in addition to adding some guidelines as already mentioned, is an additional template that could be used on such images, which would make the data available in a nicer way than just converting it to plain text (which would almost certainly end up getting put back into a location template by "helpful" bot or human anyway), and would make it easier for mapping applications, etc. to stick to geographical images if that's the intention. Any reason why this would be a Bad Idea? --jnkyrdsprkl (talk) 19:37, 1 May 2015 (UTC)
Pictogram voting comment.svg Comment For the usual user, there are basically two different use cases for location data on images:
  1. I'm looking at an image and want to know where it was taken → click on coordinates on file description page to see it on a map
  2. I want to see images of a certain place → use the geocommons overlay for GoogleEarth or OSM to see what pictures are available in my area of interest
  • From a case 1 user's POV, I don't see any reason for removing geocoding from any image (exception: actually wrong coordinates). Even if it's a studio shot. They may be useless, but they don't hurt. And who knows, maybe some statistics nerd will find an application for data like that.
  • From a case 2 user's POV, things may look different. If you're looking for architectural shots of Hollywood, thousands of celebrity pictures on the map will probably annoy you. But where do you draw the line? Take this image for example. It's just two sausages in a bread roll, so at first sight, having this image pop up on the map seems about as useful as having a geocoded image of a BigMac. But when you read the description, you'll see that it's a local specialty and they were shot where they were bought, so it starts to make sense. I think ideally we should have multiple layers for different types of pictures (landscape, architecture, flora, fauna, people …) that the users can switch on and off themselves based on what they'd prefer to see. That would, however, require a major overhaul of our current system on multiple levels and I don't think it would be wise to start working on that before COM:Structured data is finally up and running.
TL;DR: I don't think removing geocoding is a good idea unless it's actually wrong. --El Grafo (talk) 12:23, 4 May 2015 (UTC)
The only case where I would advocate the actual removal of coords would be cases like these where the use of a phone has (probably unintentionally) produced a geocoded image where the coords are not only totally unrelated to the image, but may constitute personal information about the uploader. Otherwise, I like the idea of retaining all of the data, but in a finer-grained form than the location template offers in it's current form. The number of GPS-enabled photo-taking devices in circulation is growing every day, and while it's great to be able to say "there are over a bazillion geocoded images on Commons!", that's going to mean less and less without some organization of the data. It's probably better to start thinking about this sooner than later, even if any implementation would have to wait for COM:Structured data (although I don't think that would have to be the case, if implementation involved simply adding a parameter or two to the location template).
To avoid redundancy with the existing category structure, my thought is that distinctions should be based not on type of depicted thing, but the relationship of the geo data to the depicted thing... whether a person could reasonably expect to encounter this same thing at that location at any given time, for instance. This would be very much the case for a mountain, somewhat for a building or tree, somewhat less for the food of a given restaurant or a museum exhibit, and not at all for a photo of a person or object at a one-time event, or a building already demolished. I personally think a classification system of this sort would add greatly to the value of the data, for whatever current and future purposes. There could even be a dropdown menu with choices on the upload wizard for any uploaded photo with coords. Does this interest anybody, or is it just me? :tongue: --jnkyrdsprkl (talk) 19:09, 4 May 2015 (UTC)
I do not mind removal of geotags from files like the ones given as examples by jnkyrdsprkl, but I see it as a pointless exercise if it is done without removal of the information from EXIF, because a bot will come and add it again. We can add parameter to {{Location}} template that will keep the metadata but will hide the coordinates. We did have a case when some guy uploaded iPhone pictures of his wife private parts and was understandably distress when they show up hovering over his house in Google Maps. He tried deletion of the tags and they were re-added by the bot and he tried deletion request but it was not granted, before he come asking for help. Yes such geotags occasionally "constitute personal information about the uploader".
If I understand it correctly jnkyrdsprkl is proposing creation of category tree within Category:Media with locations. I think it would be usefull to have additional category for historical images like this there we know the location but the city does not look anything lite the image, but such images might be hard to identify. I do not see much use for other categories. --Jarekt (talk) 11:56, 5 May 2015 (UTC)
Is there anything to work with Template:Location withheld ? Some improvement regarding this? If we add this template to a picture, it would be interesting that bots detect the template for not adding geotags again? Jeriby (talk) 12:33, 5 May 2015 (UTC)
{{Location withheld}} is strange. At the moment it is used very rarely and all the files using it are either geocodded (and probably meant to use {{Rare species location}}) or do not need geocodding. I see the need for {{Rare species location}} but not for {{Location withheld}} and I would rather see nothing on images that do not need it. --Jarekt (talk) 14:33, 5 May 2015 (UTC)
Also, if the coords aren't actually stripped from the exif info in the file, it could still end up being used by any outside harvester which ignored the tag. Right now, the Upload Wizard does nothing to indicate to a user that an uploaded image contains coords, unless they manually uncollapse the section for adding the info and see that it's already there... this should probably be changed. If it instead displayed a notice that the image contained coords, it could also ask about the nature of the image ("Is this an image of a fixed geographical feature?") for classification. --jnkyrdsprkl (talk) 18:44, 5 May 2015 (UTC)
I was imagining that the category structure would simply mirror whatever the hypothetical parameter was set to in {{Location}}, but maybe just having manually sorted subcategories would be enough. I don't know what the implications for machine-readability are for one method vs. the other. --jnkyrdsprkl (talk) 18:44, 5 May 2015 (UTC)

Broken template[edit]

The "Location" template with coordinates in it has links for openmaps and google but the Google link doesn't work anymore. Should be updated? Also the geolocate helper tool is completely broken now too, is it going to be fixed? Nesnad (talk) 07:39, 4 May 2015 (UTC)

Google maps doesn't support KML files anymore, so it seems there won't be a quick fix for this. See also archive & above. The link for Google Maps could probably be replaced by Bing Maps, but as Jarekt pointed out above, that would probably require Dschwen to make some changes on wmflabs. --El Grafo (talk) 10:59, 4 May 2015 (UTC)
Just to clarify: The Google Earth link in {{Location}} seems to work fine for me. The Google Maps link has already been removed, but Bing Maps should probably be added so we have aerial image overlay in the browser. --El Grafo (talk) 11:04, 4 May 2015 (UTC)
Symbol keep vote.svg Agree --Jarekt (talk) 11:34, 4 May 2015 (UTC)
That could be done by editing the template (just look at how the GoogleMaps link looked like). --Dschwen (talk) 13:27, 4 May 2015 (UTC)
@Dschwen: Yes, sorry, I got confused: It should work like this but I get a message that the file is either broken or doesn't contain a supported data type ("Der Dateiinhalt ist entweder beschädigt, oder er enthält keine unterstützten Datentypen.") plus an endlessly spinning loading wheel in the left sidebar. Neither zooming in nor changing https to http seems to change that. The polygon kmls mentioned above do work, however (example). Any ideas, anyone? --El Grafo (talk) 13:58, 4 May 2015 (UTC)
Well, the web.kml document is a meta document that should tell Bing where to pull the actual KML data for the current viewport. It is quite possible that this functionality is not implemented in Bing. --Dschwen (talk) 23:11, 6 May 2015 (UTC)

Google Earth not working today[edit]

Template:Location not working

Fourteen hours ago, it was working properly. In the past two hours, clicking on Google Earth for this picture or others does nothing. Jim.henderson (talk) 11:52, 18 June 2015 (UTC) is down, so none of the tools are working. See phab:T102925. --тнояsтеn 12:00, 18 June 2015 (UTC)

Wow, the outage lasted all day. Anyway it works now; thanks. Jim.henderson (talk) 12:39, 19 June 2015 (UTC)