I am unable to find step-by-step directions for geotagging/geocoding that actually work. This page says "Place the cross hair exactly over the place and click on it. Then copy the template Location to Commons (Copy+Paste)." Where in Commons does one paste the link? Commons is a large place. I have geotags for my images but I cannot figure out where to input them.
What do you think about building the location tag according to the english georeferncing project?
{{location d|48.776667|N|121.814167|W|}}
{{location dm|48|46.600|N|121|48.850|W|}}
{{location dms|48|46|36|N|121|48|51|W|}}
advantages:
only minor learning efforts
programs allready in use for building the coords tag could easyly be adapt to.
the templates are "speaking" : e.g.: location dms says that it wants degree minutes and second
We should use only one template and stick to it. Everything else makes it too complicated for new people who are not so familiar with geocoordinates. I think the alignment with the already existing information template is very important from a layout perspective, and helps with later maintenance. You can change the layout of the geocoordinates without breaking the surrounding text. this is not possible with a template like "coor dms" that is surrounded by text. I cannot see the advantages of introducing three separate location templates like Arcy proposes, as it makes it more difficult for people who want to build applications around it. If we keep it as simple as possible, we reach maximum impact. Greetings, Longbow4u21:51, 26 February 2007 (UTC)[reply]
I don't agree with all of your position. We should offer the minimal set that covers our needs, and help new people by not telling them about anything but the most basic features. For example, I really dislike working with DMS, some people really dislike working with decimal degrees. Fortunately the computer can easily handle both. It is VERY important that we do not continue to expand the API once we've established it. Once we're confidence that we've covered all the details I'll setup a bot to watch for the creation of any new unapproved templates which add links to mapping sites or the media with locations category. :)
I do agree that the inline text ones are not the templates we should be using for identifying the camera location. See below where I propose an alternative use for them. To geocode the images use a location infobox, to geocode things you are discussing in the description, use an inline text template. --Gmaxwell22:10, 26 February 2007 (UTC)[reply]
No, they should be all be swapped to a small set of consistent tags and the extras eliminated. The large number of tags is a nightmare for maintainability. Even if you write code to read all of them once you have more than a couple people will keep creating more of them. --Gmaxwell20:22, 10 March 2007 (UTC)[reply]
I understand your point. One comment about any template that is decided upon... I like the way that {{Geolinks-US-hoodscale}} provides mapping, and hope that whatever is decide upon will include those functions. --Evrik20:33, 10 March 2007 (UTC)[reply]
We can add extra flags to whatever template we keep so that they will have all the features we want. That said, I do see two issues with the way we're linking in some of these templates... 1) This shouldn't be an uploader preference, it should be consistent for all images and if anything it should be a user preference. 2) We should probably move more towards getting people to use own own mapping interface rather than external linking to lots of commercial providers. --Gmaxwell20:37, 10 March 2007 (UTC)[reply]
I whipped up some (crappy) perl code to extract location data from the commons XML dump. Check it out here. So far it only detects a disappointing 3023 geocoded images. I'm thinking of creating a modified WikiMiniAtlas with thumbnails on the map. Should be easy to implement... --Dschwen12:18, 25 February 2007 (UTC)[reply]
3220 images in Category:Media_with_locations right now... either you're missing some or we've gained about 200 since the last dump. Gaining 200 isn't that unlikely, since I know that I've geocoded a lot of images in the last month. --Gmaxwell16:19, 25 February 2007 (UTC)[reply]
It's yesterdays dump, so I guess I am missing some :-). But as the page says I'm not parsing all templates yet, and some templates might have syntactic quirks. Is it still not working? Did you try the page on the toolserver? --Dschwen17:10, 25 February 2007 (UTC)[reply]
Gah it works fine, I didn't realize that I had to click on the globe.. I thought someone changed the template to include that icon. :) Works fine. It's Fantastic. I little more smarts about what images to display at a particular zoom level would help. --Gmaxwell17:28, 25 February 2007 (UTC)[reply]
Looking at downtown DC and seeing image like Image:Martha-Washington-by-Andrews.jpg makes me think we may need to make sure we get people putting scale hints in the geocoding sooner rather than later. :) I think at low zoom levels we probably want to see outdoor images of large structures. Perhaps we could also bump featured image up in their priority for display. This is an issue for points for articles too, but it's a bit worse for images because they take more space to display. --Gmaxwell18:08, 25 February 2007 (UTC)[reply]
Those are two good suggestions. I'll add scanning for featured picture status and try to check the scale to generate a score that determines at which level a pic is shown. On another note, I suggest that you do not copy the whole script into your monobook.js, just include it, then you'll instantly profit from any enhancements I make... --Dschwen18:22, 25 February 2007 (UTC)[reply]
Ok, the new version now assigns scores depending on marker templates (FP=100, QI=50, POTD=20). Hmm, I guess we can endlessly debate over the scores :-). But right now they have the desired effect: showing my own images at all zoomlevels (just kidding). --Dschwen13:38, 26 February 2007 (UTC)[reply]
Great, I'm sure there is a lot we can do to improve things over time. Lots of little tweaking. I like the results it is producing right now better. ... I wish that people on commons were not so opposed to large non-humban browsing intended categories. I'd love to go through our entire collection and apply Category:Outdoors to every outdoor image so we could bump up those priorities for higher zoom levels. Alas, I think I'd be burned alive. Perhaps in a few more weeks once mayflower supports more fully generalized category intersections. --Gmaxwell22:14, 26 February 2007 (UTC)[reply]
Should we have some flag on the location template to indicate an expected level of accuracy? The reason I would see this as useful is because there are situations, such as with the images on Category:London_Eye, where I could mass tag images to within say a quarter mile of correct with almost no effort... but thats far less accurate than most of our tagging, so I'd feel bad doing it unless it was clear that the tag was a first-order approximation which should be improved. --Gmaxwell17:28, 25 February 2007 (UTC)[reply]
We can decide that our geocoding is either always accurate, or that it isn't but we admit that it isn't. Since there are people who prefer vague geocoding to no geocoding, it seems there is no other way than to start using an accuracy flag. On reuse those images could be given lower priority or filtered out altogether, and with tools to improve geocoding they'd have higher priority. Should we again go for the simple solution of adding another parameter to the parameter field of the location tags? What should it be called, accuracy maybe then? Would it be defined in metres, or perhaps kilometres, miles, seconds, ...? Most people probably wouldn't use the parameter even when instructed to, so a template parameter wouldn't be necessary even if it allowed some nice wiki-visualisation. I see it being used by the few who monitor the quality of our geocoding, who could apply or request for it to be applied to some sets of images with input from the photographer. But we need to instruct that geocoding the camera location properly is much preferable to leaving it done half way. Otherwise it's an invitation for someone to start copying coordinates to all images by following the interwiki links in galleries. If it can be done more accurately than the location of the object(s) on Wikipedia, it's better? --Para17:24, 14 June 2007 (UTC)[reply]
I have been working through my back catalogue of submissions dutifully retagging them using Method 1- to 4dp. Today looking at the Google map, now with 200+ extra icons, I noticed that many images are 0.0031 degrees out in both Latitude and Longitude. Has anyone any ideas why? I am using Firefox 2.0.0.8 on an XP Pro Thinkpad R50e. I have two tabs open- one for Google Maps, one for the image. I locate where the shot was taken from (or if a ship the centre of the object-leaving note) then tab to GM, find the spot double click, bookmark, CtrlC, Cancel,tab to image, edit, in description, CtrlV, in Summary Ctrlv, Save, Back,Back,Back then start again. To retrieve the image from Google Map, I click on Icon, Click on Picture- read Geocode and compare! See image below which should be at 51.4062 0.5412. Could it be because my browser is not in a full screen window? I will do the rest of the shots on Ubuntu 7.04 to see if I can gather any further information.ClemRutter18:32, 1 November 2007 (UTC)[reply]
A useful tip when editing is to goto My preferences.Edit and change the edit screen to 13x80 then there is no need to scroll down to get to the Save button.ClemRutter18:32, 1 November 2007 (UTC)[reply]
The Object, for instance the Kölner Dom. This would be good to use a bot to use automatically the coordinates from Wikipedia. But all Images of this Object would be on one point. But why we need then a duplicate project on Commons if we have so much coordinates in Wikipedia? Ok, for a whole city it is ok, to specify the positions of the single images.
The Position of the Camera, so we would have in a latter map-usage, on the example of the Kölner Dom, many positions around them. This methode could be usefull if more cameras have in few years an integrated GPS/Galileo receiver and EXIF-GPS-Export. But then I also want to see the view-direction of the camera.
Right now I was going with my common sense (yeah, I know, a dangerous thing to do...). I.e.:
use the camera position for panoramic images
use the center of the visible area for totals
use the location of the object for close-ups
I'd vote against using less specific coordinates from Wikipedia articles to autotag images. If only for the reason they'll all show up at one point on my map :-). --Dschwen10:52, 26 February 2007 (UTC)[reply]
With the exception of long telephoto shots the distance between the object and the photographer is probably pretty much within the margin of error of our measurement. I think in general the position of the photographer provides more information. For anything but tiny subject you can find the subject on high res orthophotography if you know the location of the photographer, but vice versa is not as often true.
We could make an argument to the template to indicate which is provided, but most people will only do what we tell them to do by default. So we should get the default right. Perhaps the solution would be to use the location boxes to denote the location of the camera, then use the inline text coord templates for the location of subject(s) we discuss in the description. Make sense?
Getting a heading will likely remain problematic. You can't derive it from an instantaneous GPS reading, and all cheap methods (compass, accelerometer) have poor long term stability.
As far as the bot mode goes, I don't like it... except as perhaps used like {{location|foo...|inaccurate=1}} which would make the template say "This location is inaccurate, you can help wikimedia commons by improving the accuracy, read more here". As I mentioned above we should also have a estimated error field.
There are two points. The location of the camera and the location of the object photographed. People could provide both. The location of the camera (By default ?) and secondary the loacation of the object. --Arcy20:11, 27 February 2007 (UTC)[reply]
Often in photos there are many features that may interest some reader, and we can't possibly plot all the objects. A heading would however solve the problem; if the features themselves are tagged in Wikipedia articles for example, the heading together with the location of the camera will show whether the feature could be in view or not. Google Earth for example supports this with the <heading> element, a ±360 value with north as 0. It could be visualised as orientation of an appropriate icon. --Para11:43, 19 March 2007 (UTC)[reply]
You make a good point here. The camera position is unique, the object positions can be extrated from linked Wikipedia articles. I'd say an approximate heading is better than no heading. We should add a parameter to the Location templates. It would be easy to make the WikiMiniAtlas display arrows depending on the headings (and point icons if the headings are ommitted (360degree panos)). --Dschwen17:36, 27 March 2007 (UTC)[reply]
We can just use the parameters field with a heading:n keyword and not have to change all the templates. Otherwise it would be too complicated for reusers if Commons had different templates than Wikipedia. But about tagging images, people's accuracy in estimating directions is probably limited to around 45°, so a tool for finding the heading by pointing on the map would be nice to get people use the parameter in any significant number of images. Angle of view or altitude might be interesting, but there's not really any good way to visualize that information, so it's not going to get too popular. --Para19:11, 27 March 2007 (UTC)[reply]
Does heading: exist, can we just make it up? It would be a coherent way to add the info. A parameter on the other hand would allow us through some template magic to display a string like looking north-east depending on the heading entered. --Dschwen19:19, 27 March 2007 (UTC)[reply]
I suppose officially it's called azimuth, but Google Earth and NASA World Wind call it heading. I think that's good enough for us. Template magic sounds intriguing, but for most people a compass point alone probably doesn't mean much without a map. And if there's a map, there might as well be a visualization of the heading, which makes the text representation less useful. --Para20:41, 27 March 2007 (UTC)[reply]
To make the wikitext more readable, we could allow compass point abbreviations as defined in w:boxing the compass to be used instead, if someone doesn't think well in degrees. The regex for allowing both is still simple enough. --Para21:12, 27 March 2007 (UTC)[reply]
I have now implemented the heading:x parameter on Google Earth with GeoCommons, a project to plot the geocoding from the dumps. If a heading has been specified (the x can be either a 0-360 float or a compass point abbreviation), the icon will point to that direction, otherwise it defaults to pointing "up". Currently there's only one image that has the parameter, you can see it on Google Earth after installing the KML file.
Now, as much as I like the simplicity of just using the information attributes field of the location templates, the idea of templates changing it to words sounds very nice. People are sometimes writing it already and it would be a shame to have to reduce those into numbers or abbreviations, or having to write the same info twice in different ways. My first thought was to have a nested template that could be used in the attributes field to not have to change the location templates themselves, but output from there seems to break the location link. Is there something that can be done to make it work this way or should we think of something else? --Para01:15, 1 May 2007 (UTC)[reply]
I have actually found the heading information very useful with panoramas, where it's sometimes hard to find a reference point in both the satellite image and the panorama. The heading provides that, but like Dschwen above, people do not think that a 360° image would have a heading, and I've actually seen the information being removed from some images. What could be done to make this information seem more relevant, even with panoramas? Should we, after all, make the parameter a template parameter, so that it can be visualized with something like "middle of the image heading north-northwest"? --Para12:24, 12 November 2007 (UTC)[reply]
Points are fine if we are just documenting the location of the camera. Do we need to have tags for specifying polygons for any reason? I suspect this would be far more interesting a question on enwiki. --Gmaxwell23:20, 26 February 2007 (UTC)[reply]
Polygons would be the ultimate goal IMO. They would need an editor extension to make them easy to handle. But if implemented they could be used to generate dynamic maps. I started to write an extension for that two years ago (check this). There were some unsolved issues, such as using a proper mapprojection library, performance issues for the data extration. And I shifted my development focus to the miniatlas. Anyways, the extension allowed to generate a map with a certain number of wikipeda articles on it. The information how to put the articles on the map was taken from the articles. Points being the old hat, but the example shows the Suez Canal, which (in my demowiki) contained a polygon definition... --Dschwen07:20, 27 February 2007 (UTC)[reply]
The above goes for the wikipedias. I'm not so sure this is that relevant for commons. A direction parameter would be interesting though. But as you said, it's not easy to determine. On the other hand, if we allow camera position and object positions to appear, the direction vector follows naturally. Basically we have to settle on an default, and I agree that camera position probably is a sensible choice. Then we allow to deviate from the default by using a parameter, and we allow to use coordinates of both types on the images. --Dschwen07:25, 27 February 2007 (UTC)[reply]
Polygon descriptions would be useful for maps and aerial/satellite images. One could (theoretically) create a scene-coverage display similar to the browse interface in some satellite data archives. --Davepape20:35, 27 February 2007 (UTC)[reply]
Ohhh.. Yes, that is an application for polgons on commons. (/me begins converting orthophoto images to djvu and uploading muhah). We should define a syntax. --Gmaxwell20:39, 27 February 2007 (UTC)[reply]
Wouldn't it be the easiest to create a template
{{GeoPolygon|52.0|10.2|52.1|9.2|51.0|9.2}}
where we stuff in the coordinate pairs. It wouldn't have to display all the parameters, maybe just a litle tag (and a category label). This would be easily parsable and flexible for future use (like an extension spitting out an inline SVG). --Dschwen20:43, 27 February 2007 (UTC)[reply]
How about GeoPolygon|52.0~10.2|52.1~9.2|.. This will avoid an off-by one causing weirdly corrupt coorids. Also, it should start off with a mandatory type= argument at the end that indicates what it's describing. {{GeoPolygon|52.0~10.2|52.1~9.2...|type=coverage}} or {GeoPolygon|52.0~10.2|52.1~9.2...|type=object|title=[[en:Mount doom]]}}. This also would allow altitude to be specified to notate volumes if we wished. I don't think we would define more than coverage, (used to indicate the area the page its used on covers) and object (used to indicate the area of whatever is named in title). --Gmaxwell21:04, 27 February 2007 (UTC)[reply]
I wrote , at first but then my cultural sensitivity kicked in. Everything else I could come up with seemed no better than ~.. & perhaps? yucky to url code. How about ";"? --Gmaxwell21:43, 27 February 2007 (UTC)[reply]
On second thought delimiting the coordinates with |s has a distinct disadvantage. It prohibits us from accessing the whole polygon as one parameter. That would enable us to construct links from the polygon strings. Links to external tools which could visualize the polygons, just like the Map sources/GeoHack page on the toolserver. what about using spaces as delimiters. Although those are kind of taboo in URLs as well, but then again we won't be able to stiop people from inserting spaces and linebreaks into the polygon strings just to make them easier to read...--Dschwen22:35, 27 February 2007 (UTC)[reply]
I whipped up a little template at Template:GeoPolygon. Feel free to play around with it. As of now it looks like the Location template, displays the title argument and the polygon data in an unfoldable block. In blatant disregard of cultural sensitivity (I'm supposed to be a decimal comma user as well...) I suggest "," as a lat,lon delimiter, and ";" as a lat,lon;lat,lon pair delimiter. Commas are used for enummerations and semicolons are used for higher level superenumerations in many languages (I'm pulling this out of thin air ;-)... ...but in my experience it seems valid). Anyways maybe we can find a better solution, but this one just seems so natural. --Dschwen22:48, 27 February 2007 (UTC)[reply]
How about ;\w+ and \w+ (whitespace) instead? GeoPolygon|1 1;2 2; 3 -3|type.. ? I just think that 1.1,2.2 is really confusing to folks that use . and , in reversed roles.--Gmaxwell22:54, 27 February 2007 (UTC)[reply]
Hmm. Looking at it, I see you're using type in the class sense. I think it's important that we have some mandatory flag which tells us if the polygon is describing the page itself (i.e. the covered area of a map) or if it's describing something that we're talking about or can simply see in the picture. If I upload a raster image showing the rainfall density of the US, I want people to be able to hit a button in a mapping tool and display that as a layer. :) --Gmaxwell22:59, 27 February 2007 (UTC)[reply]
Pheww, that would require additional projection information, wouldn't it? Maybe that's something for a different template. But you are right about the type parameter. I just copied the example from {{Location}}. Those parameters make sense for points, but for polygons we should generate a new set of parameters. like view (for the area visible in the frame), subject (for the outline of a depicted subject) etc. --Dschwen23:04, 27 February 2007 (UTC)[reply]
Every orthophoto I've ever worked with is UTM, although, they might be referenced against all sorts of fun corrid systems. :) Bleh, you're right though.. The maps we have will not be well enough projected to just toss them onto a mapping tool as a layer. --Gmaxwell23:22, 27 February 2007 (UTC)[reply]
I think this is good example of the need for 'this is the view from here' tagging (which would go on most photographs) vs (this is the subject of the image) which would go on images like this and optionally on photographs. Thoughts? --Gmaxwell01:32, 28 February 2007 (UTC)[reply]
Granted, it is a bit hefty, but it works, and thanks to {{urlencode:}} whitespaces are no problem anymore (,and ; is accepted as separators, uhmm, but only decimal points work right now....):
Geocoded outline
Südkurve
no polygon data. Check GeoPolygon for instructions.
Fantastic. Perhaps there should be an argument which switches it between the big box and a more subtle inline link? It would be nice to use the same template for both applications... and I don't think people are going to like this big box on wikipedia articles if we use the same interface. And I don't expect to see that many polys on commons. --Gmaxwell22:31, 9 March 2007 (UTC)[reply]
Hm, yeah, you're right. I thought for wikipedia we keep the syntax of the template but edit the template code to render differently. And there is another issue, raised by Arcy on de. There is a limit for the amount data that can be passed through GET requests. This could limit the polygons to a few hundred points. An idea would be adding polygon data on article subpages and just pass along the subpage name to the toolserver script. --Dschwen23:08, 9 March 2007 (UTC)[reply]
Or pass the page name with the template and the name of the polygon and have in the page itself. This avoids spreading data around to too many places. I think something that *required* a subpage would be somewhat bad, even if a subpage might make sense sometimes. --Gmaxwell00:10, 10 March 2007 (UTC)[reply]
Ok, my rationale was avoinding to pull large amounts of data from the servers, but then again Wikitext is smaller than the HTML pulled anyways by just looking at the page. I guess we can just add a large=true parameter to the template or something like it. --Dschwen08:03, 10 March 2007 (UTC)[reply]
It'll take time (until after the next database dump). Don't sweat it, I can add the template to the code, but for future tagging it would be nice to stay away from "deprecated" templates. --Dschwen22:23, 27 March 2007 (UTC)[reply]
Mh yeah, it is scare-quote-deprecated :-). We'll have to be strict and limit the usage of these kinds of special purpose templates to encourage the use of a small set of general purpose templates. I could add a conversion function to my Dschwen/Coordinate conversion helper. --Dschwen23:00, 27 March 2007 (UTC)[reply]
That might be good. The one feature that it offers that I really like is the way it formats map functions within the article. The others don't do that. --Evrik18:09, 28 March 2007 (UTC)[reply]
Is there a way to reference coordinates from articles or is it possible to do so. This can be very useful for locator maps. also posted here and on bugzilla [1] but no replies --Planemad10:46, 1 April 2007 (UTC)[reply]
It appears that enwiki is changing it's geocoding API yet again. I like the new template... it consolidates a few things... but it doesn't go far enough to save us from an unreadable sea of infinite templates. :( --Gmaxwell14:30, 2 April 2007 (UTC)[reply]
New templates should only be introduced if there is a consensus to migrate. I.e. if the old templates are deprecated and a bot is launched to convert to the new templates. --Dschwen22:06, 2 April 2007 (UTC)[reply]
Agreed. Could you please go say that on enwiki? I actually like the new template, but it's not quite good enough to migrate everything else to it yet.
What do you think of a {{coord template which had multiple output modes, one of which would be something like loc_lat=lat|loc_long=long|loc_params ... so if you wanted to have the location pretty printed by an infobox, you could do {{infobox_stupid .... |{{coord|lat|long|output=vars}}|}} This way machine readers could just scan for {{[Cc]oord|.*?}} and reliably extract locations? Use of an output= variable would also allow things like coor title to be collapsed into that single template. --Gmaxwell22:19, 2 April 2007 (UTC)[reply]
I created Template:Location request to be added on images where a location could be useful, but isn't provided at the moment. The main reason I created it is that I intend to add coordinates to all my images, and thought it would be convenient to have the images lacking coordinates tagged somehow (making it easier to search through the images using CategoryIntersect). Before I start using it on larger scale, I would like to know if the community think it is a good idea. Väsk19:04, 6 April 2007 (UTC)[reply]
Everything in a wiki needs work, unless it's specifically marked as done. With geocoding that's either a location or currently inclusion in Category:Location not applicable (there is a deletion request for the category though). Anyway, a category intersection with CatScan or Mayflower for images not in Category:Media with locations or images not tagged with Template:Location will tell you which images still need to be tagged, without having to use a new template. It's better giving images a definitive geocoding status (done or won't be done) rather than temporary (should be done, which is the default anyway). --Para20:16, 6 April 2007 (UTC)[reply]
I didn't know Mayflower had that feature (CatScan doesn't have an "exclude category" button yet, though). That makes "Location possible" redundant, and I will stop using it. Thanks. Väsk21:30, 6 April 2007 (UTC)[reply]
As nice as Mayflower and CatScan are, I've started to notice that they're not ideal for this purpose. So I wrote a simple tool to show non-geocoded images by category. Geocoding an image will make it more visible in various reuse cases, and this tool shows a gallery of images where it's easy to choose which should be promoted in this way. --Para14:52, 17 June 2007 (UTC)[reply]
Since the best geocoding results come from the photographers themselves, I added the feature to find non-geocoded images uploaded by a user. Enter your username in the geocodingtodo tool and you'll get a gallery of images to work on; either to add a location template or now that Category:Location not applicable is safe, add the image there. --Para16:38, 25 July 2007 (UTC)[reply]
Great! A long awaited tool. If I am to make some suggestions, it would be to split the result into several pages (with around 100 images on each). When I type "Väsk" I get over 1300 images, which takes time to load and is heavy on my slower computer. Väsk09:31, 26 July 2007 (UTC)[reply]
Featured Pictures on the English Wikipedia from Commons are a bit better, but still a mess for geocoding. I'd like to suggest some work in the Things to do section of the project front page, preferably something that always has some material, but I can't seriously expect anyone to work on such a mess. How can we get anyone interested of this project and to work on random images, when we can't give pointers of what needs to be done? --Para12:17, 26 August 2007 (UTC)[reply]
Can we add a parameter for whether is is the camera's location or the subject's location which is being geo-tagged? i.e. whether it is the location of the photographer is standing, or where the camera positioned. It may be possible to automatically add the photographer's location (from a GPS) so this information could be useful, but needs to be distinguished from where the subject is (although in many cases they may be close enough to be a trivial difference.) But in extreme cases, with telephoto lenses, the locations may be quite different. Pengo03:54, 14 April 2007 (UTC)[reply]
This has been (or is) discussed above. I'd say tag the cameras location and link to subjects as wikiarticles (which could be geocoded themselves). --Dschwen08:08, 14 April 2007 (UTC)[reply]
I'm currently working on a live update mechanism for the coordinate database on the toolserver at User:Dschwen/Coordinate-Updater. This would make newly tagged images show up instantaneously on the Commons:WikiMiniAtlas. You could help test a proof of principle version, which already transmits the data to the toolserver. The final step of inserting the new data into the DB is still missing, but I'm working on that. The more people help testing, the more data I have to work with. --Dschwen07:12, 16 April 2007 (UTC)[reply]
This is very mad scientist of you... :) It's smart but you could just poll recent changes and check every image page revision for coords. Commons edit rates are not all that high. --Gmaxwell23:28, 16 April 2007 (UTC)[reply]
Isn't there even a recent changes channel on IRC? Good idea. I might try that approach for commons, but the updater has to work on the big wikipedias as well. --Dschwen06:31, 18 April 2007 (UTC)[reply]
On this subject, can you make your updater write a publicly available log listing pages were broken geocoding has been found? (i.e. geocoding templates which are non-readable for some reason or otherwise contain insane values?)--Gmaxwell23:37, 16 April 2007 (UTC)[reply]
All changes to geocoding of Commons images are now visible in GeoCommons Recent Changes, updated once a minute. Only changes to the geocoding list an image on the page, and not changes to the rest of the description of a geocoded image. It's a work in progress, but currently works fine for people who want to monitor the quality of geocoding here, and highlights invalid template use as well. --Para22:35, 15 July 2007 (UTC)[reply]
The fact that one of the location templates inserts a microformat and the otherone doesn't is not a property of the templates that should be advertised in the usage instructions. The {{Location}} template should just be fixed to also support the microformat, and the whole thing could be explained somewhere further down on the page. I realize that it is not trivial to ad the Geo microformat to the dms template, but using the parserextensions an internal conversion to decimal could be achieved. I'll get on that as soon as I have time. --Dschwen15:02, 16 April 2007 (UTC)[reply]
Agreed. I found a way to add the microformat to {{Coor dms}} using a hidden span tag. Maybe we can borrow the intestines of the coord template on en to rework {{Location}}. We wouldn't have to bother with inline or title display, as every image should only contain one coordinate (at most), the camera viewpoint (plus I like the current look of the Location template, matching the information box :-) ). --Dschwen08:45, 19 April 2007 (UTC)[reply]
Is there any way that upload files could be parsed for geodata that is already part of the file (which I believe can be done through Google Earth) --Padraic21:32, 18 April 2007 (UTC)[reply]
We cannot do this directly on the Commons server yet, it would require a codechange of Mediawiki. But I could parse the commons database dumps, which contain extracted geodata. I'll check this today. --Dschwen07:23, 19 April 2007 (UTC)[reply]
Ok, it would be feasible to create such a bot. But currently out of the million files only a whooping two images contain a GPS position tag! image:DubocePark.jpg and image:San_Francisco_Mint_2007.jpg. (many more pics contain incomplete GPS tags which only indicate the time of the exposure but no actual coordinate data). I'll keep the idea in mind, but right now it's not worth pursuing. --Dschwen08:27, 19 April 2007 (UTC)[reply]
Certainly the number of files will increase in time, and it migh have increased since last comment but it seems that commons exif parser still do not grab exif info properly. ie. I copied Exif info of this file extracted by Irfanview and compared it to those shown on commons file summury. Clicking on Open in google earth in Irfan properly opens GPS location of image in GE. Since the coordinate info is missing on commons but the altitude data is not, it might be better to do a search for altitude parameter to have a guess of the number of geocoded images on commons. It would certainly be a number greater than two. --Nevit Dilmen10:09, 9 May 2008 (UTC)[reply]
If most users will just manually add the geodata, then not a problem. I was thinking if people were geotagging their photos for personal use, then this could make it easier - but perhaps Commons users are too dedicated to be worrying about personal use! --Padraic16:27, 22 April 2007 (UTC)[reply]
I'm not sure I understood your last comment? And I'm not sure you understood mine. So let me reiterate: Nice idea, I checked that it is indeed doable, it will be done, but currently there are virtually no images with in-file geo metadata present on commons. --Dschwen17:37, 22 April 2007 (UTC)[reply]
Yeah, I get it. As a side note - do you happen to know if geotagging on Flickr adds any kind of metadata, or whether those coordinates are only useful within Flickr? --Padraic02:13, 23 April 2007 (UTC)[reply]
I understand that there is currently no possibility to extract GPS coordinates directly from the EXIF tags, but it would be possible to create a bot doing this. I have many of my own photographs geotaged the usualy way, but I just bought a GPS device and plan on getting the GPS coordinates into the EXIF tags. So an automated parser would be very useful to me. ;-) Dschwen, if you ever get to create such a bot, I will therefor gladly help you. I am no programmer or such, but technically experienced, including just a tiny bit of programming. I would try to help you (or anyone else interested in this) in any way possible. --Florian Prischl16:12, 2 October 2007 (UTC)[reply]
I just started whpping up some python code to query the DB on the toolserver for images containing Geo EXIF data. I'm specifically looking for the GPSLatitude tag. But there are only three(!) images in total on commons containing this tag (same for GPSLongitude obviously). Am I missing anything? If I'm correct there just is no demand for such a bot yet. Although it would be fairly trivial to implement, starting from what I've already got. --Dschwen22:02, 2 October 2007 (UTC)[reply]
Yes, I read your earlier comment about only two (now three) images that are geotagged directly in the EXIF data. Of course, coding for such little demand is rather futile. As for you missing something, I doubt it from what you present so far here. The GPSLongitude would obviously be present in a correctly tagged image, and I don't think there is a more definite EXIF GPS field (that is, it does not matter). You probably have one already, but here is a list of GPS data fields from the website of ExifTool. If you need more material to play around with, I'll gladly provide some in time. I just bought my GPS receiver (the Sony GPS-CS1KA) today, so I only have two images tagged so far. By the way, is there a simple way to find EXIF-GPS-tagged images with the search provided by the Commons? Apparently not, as you had to write something to do that job... ;-) What such a bot would have to do is, as you say, rather trivial: Take the information from GPSLatitude/GPSLongitude, put it in a {{location dec|Lat|Lon}} template and put that template in a specified location of the image page. Since things like heading, etc. are not stored, that's really all, right? Thank you for thinking about this! --Florian Prischl23:03, 2 October 2007 (UTC)[reply]
Dschwen noticed below that this is a problem in MediaWiki; the geocoding information from the EXIF data isn't imported in the database, though other information is. There's also demand for a bot to transfer geodata from external sources where we have imported an image without the metadata. Both data sources will need a bot to write the information here using our location templates. --Para12:48, 19 October 2007 (UTC)[reply]
I just checked in the Google Earth layer, and my photos are showing up there. So clearly the geodata is in there somewhere...--Padraic00:24, 24 October 2007 (UTC)[reply]
At the moment the wikitext is all that matters, and that's why only Image:BonnechereProvincialPark-Sign.JPG and Image:MeechLake-OBrienBeech.JPG of your images are visible there. The rest needs work. It's a problem that people would have to enter the data twice, but it might also be creating problems to just have a bot copy the exif data over to wikitext, as we'd end up forking the metadata and seeing the same location drift to two separate locations; which one could then be considered better? --Para20:40, 24 October 2007 (UTC)[reply]
Sorry, I don't get how this creates two locations if a bot copies the EXIF data and pastes it in to Wikitext. Can you elaborate?--Padraic13:44, 25 October 2007 (UTC)[reply]
Everything in a wiki is up for improvement, including the geocoding. The photographer may try their best to geocode their work, but that may not always be up to par with the rest of the community, and even the reference data changes, especially when the location has high elevation. The best solution would be if MediaWiki could keep certain data from the wikitext in sync with the exif data. I remember this was discussed somewhere with author and license information, which would profit from a similar metadata treatment, but can't find now where that was. --Para14:26, 25 October 2007 (UTC)[reply]
For the record, I think the answer is easy -- have the Wikitext be the "better" data, since it could be edited. For now, I'm not going to bother adding templates to the many of my photos which have geodata in the EXIF, when I strongly suspect this process will be automated. Hell, maybe I'll just use the Flickr bot (which automatically creates the template) and route my photos through there. --Padraic14:15, 22 March 2008 (UTC)[reply]
It seems that the EXIF parser does not read the EXIF Geolocation info properly. ie. in - this - image geocoded with GPISYNC EXIF info shows North or South Latitude:North latitude, East or West Longitude:East longitude, Altitude: 899. I Checked the image with ACDSee to see if the Latitude and Longitude is existing and it seems to be no problem. I support automation of geocoding. It would be mandatory if commons desires to use camera location instead of structure location. Most of manually coded tags indeed show structure location despite the tag says it shows camera location. Since the tagging system does not work automatically, I just coded the category with structure location, hoping that EXIF tags will be effective in future. --Nevit Dilmen00:13, 9 May 2008 (UTC)[reply]
I've been working on an EXIF read-out bot. It does not yet modify pages, but that's just a formality. Current output looks like this:
dschwen@hemlock:~/qic_bot$ ./gps_exif_bot2.py
/home/dschwen
Checked for running processes. 4 processes currently running, including the current process.
0-4-2_Hawthorne_Leslie_Blackie.jpg
downloading http://commons.wikimedia.org/wiki/Special:Filepath/0-4-2_Hawthorne_Leslie_Blackie.jpg ...
analyzing GPS EXIF data ...
{{Location|33.000000|55.000000|16.750000|S|18.000000|25.000000|33.600000|E|alt:0.000000_source:exif_heading:?}}
01-Rundflug_29._August_2007_(1355643347).jpg
downloading http://commons.wikimedia.org/wiki/Special:Filepath/01-Rundflug_29._August_2007_(1355643347).jpg ...
analyzing GPS EXIF data ...
{{Location|49.000000|56.000000|20.843988|N|9.000000|3.000000|20.556000|E|alt:156.000000_source:exif_heading:?}}
01_Boyne_Viaduct_Drogheda_2007-10-5.JPG
downloading http://commons.wikimedia.org/wiki/Special:Filepath/01_Boyne_Viaduct_Drogheda_2007-10-5.JPG ...
analyzing GPS EXIF data ...
{{Location|53.000000|42.000000|52.034400|N|6.000000|20.000000|45.182400|W|alt:36.297000_source:exif_heading:?}}
01_de_Lacy_bridge_Drogheda_2007-10-5.JPG
downloading http://commons.wikimedia.org/wiki/Special:Filepath/01_de_Lacy_bridge_Drogheda_2007-10-5.JPG ...
analyzing GPS EXIF data ...
{{Location|53.000000|42.000000|52.034400|N|6.000000|20.000000|45.182400|W|alt:36.297000_source:exif_heading:?}}
01a-Clarkestown_mast_2007-09-06.JPG
downloading http://commons.wikimedia.org/wiki/Special:Filepath/01a-Clarkestown_mast_2007-09-06.JPG ...
analyzing GPS EXIF data ...
{{Location|53.000000|27.000000|43.038000|N|6.000000|40.000000|25.680000|W|alt:106.386000_source:exif_heading:?}}
There are three things to note: it reads out altitude and puts it in the extra parameters, it adds a source tag, and it adds a heading:? tag. The heading:? might be controversial. I added it for now, as it might encourage people to quickly add a heading, and it saves typing. Will it cause any problems during data extraction? Oh yeah, and the trailing decimal zeroes are annoying, I know... --Dschwen18:43, 17 May 2008 (UTC)[reply]
Looks like we have 1600 images of bugs geocoded to the exact same location. Great photos, but the geocoding part is rather disappointing. An approximate location like that will no doubt help someone using the photos, but I'm not sure geocoding is the right way to do it, especially since with these photos it's probably impossible to make it any more precise. I have been geocoding our Quality Images lately, and there are many images of animals with very little background. Should they maybe go to Category:Location not applicable or some intermediate category? Should an image be geocoded if something typical or distinctive to the location can be seen, even if only partially? Note the accuracy proposition above might be related. --Para13:58, 2 May 2007 (UTC)[reply]
Locations are very relevant for biological recording and associated images - somebody might be interested in, say, the colour variation of a species of moth between its Northern and Southern range limits. I'd go so far as to say that deprecating the geo-coding of such images might very well persuade photographers to not bother submitting them. Pigsonthewing14:31, 2 May 2007 (UTC)[reply]
That makes it even more important to geocode an accurate location. By coding to an approximate location (and thus coding 1600 bugs to the same point on earth) you degrade data by making the implicit assumption, that the chosen point is a center of gravity for those bugs. Bogus geocoding info might as well be deleted from those pictures. --Dschwen14:55, 2 May 2007 (UTC)[reply]
They're coded to the nearest second, which is a precision of ~ +/- 15m, AIUI. That's precise (as opposed to "accurate"; low precision does not equate to bogosity) enough to say "in this field" or "on that nature reserve", and sufficiently vague to not give away the exact location of a nest or colony of an endangered species. What's the problem? Then again, one person has found over 700 species on one square metre of garden... Pigsonthewing15:18, 2 May 2007 (UTC)[reply]
What is the point of this comment? Have you even looked at the pictures in question? Apparently not. The text says taken in the high ardennes, the bg varies considerably, and the coordinates are precise to the second. This is bogus. Full stop. If the point of the geocoding was to code the high ardennes, the precission is to high. If the point was to geocode the location of the pictures, the coordinates are obviously wrong -> bogus. --Dschwen15:30, 2 May 2007 (UTC)[reply]
"Have you even looked at the pictures in question? Apparently not." Your telepathy device is malfunctioning, HTH.
"If the point of the geocoding was to code the high ardennes" Having apparently done more research into these pictures than you, I can state categorically that it is not.
All the images are coded to the single location the photographer gives on his village ecology page. Looking at a satellite image of the area, the location is a bit off from the center of a village, so it's probably the photographer's home or an official kilometre post or some similar point which most certainly is not within 1 second distance of the locations the images were taken in. On a warning page he says that the photos have been taken on a radius of 4km from the village, which corresponds to about 7 minutes range of variation. I don't think we can rely on implied precision when problems like this come up, but there are not many cases where people would actually tell which level of accuracy they expect their geocoding to have. In this case I say remove the geocoding from all these images and put it on the category page instead. --Para16:35, 2 May 2007 (UTC)[reply]
That sound like good solution to me. The approximate geocoding info won't be lost and the category gives a context. Bot anybody? --Dschwen17:28, 2 May 2007 (UTC)[reply]
Hi, I'm the guy who uploaded the pictures. I have no experience with coordinates, so it looks like i got the resolution wrong by just pasting the coordinates from lindsey's site. what would be the appropriate resolution if one wanted to designate it's say in a 4km radius? and why not put this resolution in each picture page? at least i would not look at the category page for this information. i'm planning to put geo-coordinates into my pictures whenever possible in the future, because i find it very useful to see where the creature lives, but would rather not like to create more problems than i'm trying to solve :) cheers, and thanks for trying to rectify my mistake. --Sarefo22:45, 6 May 2007 (UTC)[reply]
I'm not sure that the image page is the right place for the rather general uinformation of where the bug lives. I'd expect pictures to be coded with the specific location where the photo was taken. So that's why the category solution makes sense to me. Maybe even the articles on the species would be an appropriate place. --Dschwen16:45, 7 May 2007 (UTC)[reply]
i did not intend it to be information where the species lives, but where this *specific* individual lives. which is of course also where the picture was taken. this way, in the future information like species variation could be read from the data, which would not be possible if it is noted on the species page. also, all species in Commanster occur in many parts of Europe, so it would be very misleading to tag the species pages with the commanster coordinates. so, without having too much authority in this field ;), i would propose to change the lindsey picture coordinates to a resolution that designates a 4km radius around commanster. --Sarefo13:03, 9 May 2007 (UTC)[reply]
That would be more appropriate, but still an unsatisfactory solution. There should be a sensible relation between object size and coordinate precision. I'd rather have ten exact coordinates than hundreds of pic tagged with the same 4km radius coordinate. But that's just my opinion. --Dschwen13:13, 9 May 2007 (UTC)[reply]
I put together a script to give helpful people some work: Top 50 locations of inaccurately geocoded images - choose a location where the images have something identifiable and fix the geocoding. It's not useful for this 1600 case, but there are other groups with fewer images. Changes will be visible on GeoCommons within minutes. --Para01:05, 14 May 2007 (UTC)[reply]
I've had a try at geocoding this satellite image of Hurricane Isabel; I've used the location that the National Hurricane Center gives for the storm at about the time of the image. As this in open water away from land its probably a good one to discuss for this: Would it be useful to geocode widescale satellite images? If so should the approximate centre of the image be used, or something else (the location of the camera perhaps). Thoughts?--Nilfanion10:38, 6 May 2007 (UTC)[reply]
There are now a bunch of Map templates being used on image pages... I don't think coordinate use in galleries or categories is in this project's territory, but image page geocoding should definitely follow Commons:Geocoding. Therefore I put together a query to list image pages that link to map services without using the Location templates: commons-maplinks-report. Automatic link and template replacement would be nice, but isn't really possible as the people who have added the links have probably never heard of having to geocode the camera location. Could we get a collaborative effort going to review those images and replace the links with Location templates? --Para02:44, 12 November 2007 (UTC)[reply]
Will only images could be shown on maps or galleries/categories for same subject with location template could be displayed too? --EugeneZelenko14:33, 10 May 2007 (UTC)[reply]
There are probably Wikipedia articles in some language about all the categories and galleries we have on Commons. That's where the geocoding should go, and we don't need to duplicate the data here. The Wikipedia-World project has worked on making the Wikipedia data available for use. --Para15:42, 10 May 2007 (UTC)[reply]
Someone recently copied 27 geocoding templates from enwiki. I've deleted them, protected them against recreation, and added a note to the page here requesting people not do that. We really don't want to adopt the enwiki mess without consideration. --Gmaxwell07:06, 11 May 2007 (UTC)[reply]
Boilerplatetext for a friendly geocoding request[edit]
What do you think of the following (to be subst'ed onto users talkpages):
I've been browsing pictures from Africa (a white spot on the geocoding map) and figured out a few pics, but many will be much easier when done by the photographers. --Dschwen11:39, 31 May 2007 (UTC)[reply]
That's a nice idea. The problem is how to identify the users that could be invited with the message? I put up a geocoding density map (based on geonames), which shows lots of areas in the dark (or white), but it would be nice to have some sort of javascript thing with category names overlayed, and maybe somehow even the names of the biggest contributors. Generally, people who geocode random images on Commons could use some help as well in finding good images to give a location to. --Para18:00, 31 May 2007 (UTC)[reply]
and I think it could be a vision for the future. The video is nice but the live demo is not running in the moment on my desk. Kolossos12:42, 1 June 2007 (UTC)[reply]
Holy f*&k! Wow, just wow. This must be the most impressive thing I've seen in quite a while. Nothing less than jaw dropping. I imagine with a huge image base like commons or flickr this would make a pretty impressive browsing experience. --Dschwen19:10, 1 June 2007 (UTC)[reply]
That's amazing indeed, in a perfect world... They seemed to be using Flickr material to demo with, but Flickr people certainly have a way to go to get their geocoding that precise (currently the quality is horrible, see kml above). I hope we can aim for quality over quantity here on Commons. --Para21:49, 1 June 2007 (UTC)[reply]
From user perspective, Google Maps works much faster, street/hybrid map is useful, satellite images could be in better resolution. Anyway, I'm using Google Maps for finding coordinates, could I do so with WikiMiniAtlas? --EugeneZelenko15:14, 2 June 2007 (UTC)[reply]
No, that´s not a serious option. But please bear in mind that the high res satellite pictures and streetmap data is not free. And there is no way of inserting GoogleMaps maps into Wikipedia pages. --Dschwen14:37, 3 June 2007 (UTC)[reply]
I am perfectly aware about the technical feasibility, but API keys are not simply handed out to high volume sites like candy. And again I'm not sure that embedding copyrighted content is in the spirit of wikipedia to begin with. --Dschwen08:04, 4 June 2007 (UTC)[reply]
Advantages of Panoramio: KML of Panoramio contains miniature images; with GeoCommons, you have either to download large image to see what's there, or to rely on the title. Also, in Panoramio the uploader feels much safer, because in Commons an image may anytime be questioned whether it contains valueable educational or informational content or just wastes space on the server, and then deleted. —Mithgol the Webmaster05:51, 5 June 2007 (UTC)[reply]
The WikiMiniAtlas already displays thumbnails. I didn't put thumbnails on GeoCommons because I think they hide so much underneath them that you can't see where exactly the photo was taken, and you lose the camera direction information. But if some people really prefer, I'll see if I can add a url parameter to get that and some more sparse results then. Panoramio images are quite good quality and pertinent to the location, at least the ones in the GE default layer (which doesn't have thumbnails, btw). In Panoramio's own layer there are sometimes images that don't have much to do with the location, and even more so on the Flickr layer. Since Commons is not a webhost, such images might get deleted from from here, and that's a good thing to maintain the quality. --Para06:31, 5 June 2007 (UTC)[reply]
The Google Earth Commons-layer works pretty much the same way as the Panoramio layer (except that updates are almost instant). With Google Maps the same layer kind of works [2], but they have a limit for the number of placemarks, so people can't go scrolling wherever they want from the given location. Also I'm not sure how to calculate the bounding box coordinates from the center point and random scale number, so I haven't worked on it a whole lot. Perhaps these "mapplets" can help make it dynamic then, I'll look into it at some point. --Para20:40, 1 June 2007 (UTC)[reply]
KML 2.2 (now beta) is going to have photo-related markup[edit]
Look at KML 2.2 Reference (Beta: May 31, 2007). For me it seems like after aquiring Panoramio they started a photo-related improvement in KML. Especially the new shapeEnum datatype, Camera element, PhotoOverlay element. We also could take advantage of atom:link elements when attaching links back to Wikipedia, though it's not the time yet to be sure where (and whether) they are to be rendered. —Mithgol the Webmaster07:26, 4 June 2007 (UTC)[reply]
Google recently demonstrated the photo overlay feature at a conference. There's a video of it (starting around 1:30) so you can all see what this is about. The audience sounded impressed, but personally I don't see much to it. In terrain view mode, looking at accurately placed panoramas displayed with correct geometrics will obviously be better quality than the satellite terrain data combined with 3D building models or seeing panoramas in normal flat view mode, but there are just too many parameters, and I don't think we can ever achieve the required level of quality for that in our geocoding for random images. The additions will no doubt be useful for Google themselves though, following their recent Google Maps Street View feature, where they have 360° panoramas of major US cities at about 10 metre intervals. Gadgets are cool, but that's all. --Para09:41, 4 June 2007 (UTC)[reply]
I found no discussion of what datum is to be used on the project page. I assume it should be WGS84 (WGS84/NAD83 in North America). Unfortunately, the default on topozone is NAD27. I think that elsewhere, the default is WGS84. This is important. Compare the same coordinates near El Capitan.[3][4] One is on a trail. The other is 100 m west and about 70 m lower on the steep wall of a ravine.Walter Siegmund(talk)04:54, 10 June 2007 (UTC)[reply]
WGS84 seems to be the sensible choice as it is the datum used in most of the recent data sets. WGS84 also is the official standard of the german geocoding project (most likely of the english too). --Dschwen20:38, 10 June 2007 (UTC)[reply]
It seems to be working fine here. The problem is probably in the browser that opens the link, though I'm not aware of any that translate urls like that. Have you tried opening the link in an external browser, or the internal one, whichever you're using now (Tools/Options/General/Display)? I put the kml for this image, its html as it's currently, and a html with links urlencoded up for testing, try opening them with both browsers. Do they work, and do any work better than the other? Thanks for the report. --Para17:54, 10 June 2007 (UTC)[reply]
I use Mozilla Firefox 2 on Windows XP.
Problem is only in external browser. Internal works fine and also address in location properties is correct. From other side address in properties was shown in unencoded form (http://commons.wikimedia.org/wiki/Image:Ühisgümnaasium.jpg). So may be problem lies in passing unencoded address from Google Earth to browser through command line?
A new basemap for the Commons:WikiMiniAtlas is ready. It is based on VMAP0 (and data from the US National Park Service (because I am a NPS fan, and they freely distribute great data sets :-) ). The new basemap has lots more data layers and makes orientation over inland areas way easier. Currently it still has to be selected in the settings (down arrow icon on the WikiMiniAtlas window), but I plan to make it the default map. Sure, the contry border data is a tad outdated. But IMO it is better than nothing (sorry GUS). If you have a free up-to-date countra border dataset (preferrably in shapefile format) please send it to me. --Dschwen20:44, 10 June 2007 (UTC)[reply]
I have geocoded some maps, see Special:Whatlinkshere/Template:GE-Map and Image:Erfurt-1650-Merian.jpg a long time ago (2005). So you get an image-overlay on Google Earth. I use a foreigners wiki-server.
Perhaps somebody see a chance to realize such a thing independent from an other Server. I see that it is now possible to create kml-files on commons (see Commons:Geocoding/Compass_overlay.kml), so we could use perhaps this way. But it's a little bit uncomfortable, because there is no header for "click and surf"-feeling, you need to use Copy and paste.
I believe kml is a standard which we can later also transform in an other format which we want. Should we use subpages or what? And in which namespace?
The capabilities of fitting an image in KML are limited, so large areas with an other projection aren't possible and the maps shouldn't be too old, but ok... Meanings? Kolossos19:00, 18 June 2007 (UTC)[reply]
This is an interesting suggestion and seems perfectly doable. Let me suggest two minor things: let's find a standard for the subpage name )/overlay.kml is a bit more descriptive than just kml) and let's create a template to tag and (automatically) categorize overlay-coded images. The template could generate a link to a toolserverscript which creates a point and click GoogleEarth link (probably not doable directly in the template). --Dschwen19:19, 18 June 2007 (UTC)[reply]
Yes, if the script would make access to one of the wikipages (like the geohack it do) this would be great. But who? This can also comes later. Unfortunally in the image-namespace there are no real subpages possible. But we can link it perhaps manually. Kolossos19:34, 18 June 2007 (UTC)[reply]
Why? The example you gave looks like a subpage to me. Ok, it has this Image-Namespace functionality prompting you to upload a file. But we could either ignore that, or... ...upload the KML as a file :-) (is it possible yet? too lazy to check myself right now). And a toolserver script that generates a GoogleEarth link is approximately one line of PHP. --Dschwen19:40, 18 June 2007 (UTC)[reply]
I just realized that the GoogleEarth-Link is just a link to the KML file anyways, so I guess an ?action=raw&ctype=application/vnd.google-earth.kml+xml would do the trick inside the template without additional scripts. --Dschwen19:45, 18 June 2007 (UTC)[reply]
Sounds great, especially for historical maps which can't be found in any geocoded map service. Alhough copy&paste isn't really that hard as the kml content can be pasted to GE directly without creating a file, the click and surf feature would make it that much more attractive for users. But unfortunately the kml content type isn't supported by MediaWiki, so the ctype url trick won't work. I think we could go for a kml-independent "dynamic" solution, where the data is entered as template parameters, and the template creates a link to a toolserver script which returns a kml file or any other future format that might be available. It's not really necessary to make it dynamic like that and dependent on the toolserver, since the data is static, but it easily solves all the problems above. The template could be like {{Imageoverlay|north=50.982|south=50.961|east=11.046|west=11.003|rotation=54.681}}. --Para20:05, 18 June 2007 (UTC)[reply]
The advantage of using kml would be, that you can using Google Earth as a tool and than use copy&paste to write it directly in the wiki-text and it is perhaps more flexible. A Script that can read this XML later shouldn't be a problem. Or?
The only other application in my mind would be en:GRASS GIS that would be interesting to know how they save their datas or what other open standards are on the world. --Kolossos20:29, 18 June 2007 (UTC)[reply]
Nice work. Thanks. My only question is: Could we get trouble if we use the image-namespace? Kolossos16:22, 19 June 2007 (UTC) Perhaps, we should realy rename the "toolserver" into "tollserver". (The english tranlation of the german "toll" is "great and huge" but also "mad".) [reply]
Are there any tools to help geocode maps? Something where you just click on a few points both in the satellite image and on the overlay image, and it'd compute the rest, would be great. It takes ages using the standard Google Earth overlay tool! --Para21:39, 19 June 2007 (UTC)[reply]
Have the KML sources been deleted recently? The "source" pages are empty and the kml.php isn't working... am I missing something? - gobeirne18:31, 3 November 2007 (UTC)[reply]
They were inadvertently deleted as image pages without an image, and have now been restored. The admin won't repeat the mistake, but someone else doing cleanup might, so is there something we could do to prevent it in the future? Subpages in the Image namespace are displayed somewhat confusingly, "No file by this name exists", "There are no pages that link to this file". The subpage path at the top of the page (like on Commons:Geocoding/Overlay for example) doesn't seem to be working on Image pages either. The "/" character is probably allowed in image filenames, so there aren't subpages for images really. Bugzilla? --Para15:40, 6 November 2007 (UTC)[reply]
With $wgNamespacesWithSubpages in DefaultSetting the Admins could make subpages possible in image-namespace. Offcourse, only if no image use a "/" in the Name. The reason for prevent such a way on Wikipedia Article-namespace was the Objects with a "/" in her name. But perhaps another Namesspace would be really better. --Kolossos16:35, 6 November 2007 (UTC)[reply]
I took the picture of Trinitary Monastery in Vilnius (54°43′53″N, 25°17′27″E) with a long zoom from the location of Verkiai Park (54°44′49″N, 25°17′30). As you can see, these are quite far away. I understand that we should be using location of the camera to tag the image, but in this example this could result in misinformation, as the image of the Trinitary Monastery would be located next to Verkiai Palace, while in reality they are quite distant, this is clearly visible if you check it on the map. There are more examples, I only provided this one to present the problem. Any ideas ? Wojsyl09:22, 21 June 2007 (UTC)[reply]
What about the photo ? To an average user it will look like a mistake if we assign the location of Verkiai Palace to Trinitary Monastery. I'm sure that when people click on Google Earth icons, they expect to see the images of the objects they click on, not some other (distant) ones. Wojsyl10:15, 21 June 2007 (UTC)[reply]
I expect to see pictures of the view I'd have at that position. The location of the object can be inferred from the articles (linked or hinted) in the image description. Determining the location of the photographer would be much harder, thus it makes perfect sense to specify it on the image page. --Dschwen11:56, 21 June 2007 (UTC)[reply]
Well, you do expect to see pictures as seen from the location (besides, you'd need to have binoculars to see it) but most of the users don't. I've tested this with google earth on couple of my friends and members of the family, and all expected to see Verkiai Palace when they clicked on the location of Verkiai Palace, not Trinitary Monastery. (well in fact I tested it on Image:Vilnius HMG Orthodox church.jpg and Image:Vilnius Gediminas tower.jpg but nevertheless the result was the same). One of the principles of designing a user interface is to respect the users. I think the same holds here. Wojsyl20:16, 21 June 2007 (UTC)[reply]
This whole thing was discussed before. Still though, it would be best if we geocoded both, but that's too much to ask from people who mostly aren't doing either. Half of the work would also be redundant as Wikipedia is geocoding the object locations already. What we could do is try to find a meaningful machine readable way to link to the Wikipedia articles, though that wouldn't be called geocoding anymore. People on the Commons mailing list have recently been talking of annotating images with rectangles, which might in the future provide useful information for displaying images of a single object only. With the current tools the visualisation of all that information on a map would make the user interface too busy however, and would also lose the feature of being able to observe an object from different angles, not to mention cluster most images to unusable lumps. Most photos here aren't taken with a long zoom, so you are testing with extreme cases, outliers that may as well be ignored. Perhaps the thumbnails layer of Wikipedia-World is more usable for you? --Para23:20, 21 June 2007 (UTC)[reply]
Thanks. Basically, it should be represented with a vector then, but you are right that the GUI would get too cluttered displaying them. Wojsyl14:16, 22 June 2007 (UTC)[reply]
I disagree. What I want to find is what the object is that is on the photograph (or even better, whether Commons has any photographs of the location I want imagery of), not where someone stood when it was taken. What usage would the second have for the user who wants to have a picture of something. Sure, it could be they are interested in the view from that object, but it's much more likely that they are interested in a view of the object. What you are saying is that in that case they should find the object on Wikipedia, note which objects on common show that object, and those are the pictures they want. Would it not be much better for them to have the coordinates available, and then with those coordinates be able to find what pictures on commons there are around those coordinates? I will keep geotagging with object location, and in rare cases with double tagging of both object and camera location. - Andre Engels11:03, 5 July 2007 (UTC)[reply]
Unless you are flagging the template appropriately to indicate that you are coding object locations this maverick behaviour will ultimately hurt the Geocoding project. It makes the coordinates inconsistent and unreliable. Many pictures show several objects of interest, are you geocoding all of them? Why duplicate the location data from Wikipedia? Data duplication is never a good thing. --Dschwen12:31, 5 July 2007 (UTC)[reply]
There are various tools to use the data from Wikipedia, either by name or by coordinates. Wikipedia articles link to galleries or categories here, so almost all our images are already connected to a geocoded object location. Is it just the direct link or gallery of all related Commons images that is missing, ie. are the user interfaces not good enough? In the GeoCommons interface you can choose which side of the object to look at, and the Wikipedia-World thumbnails layer (currently showing images of objects placed to their Wikipedia location) could be extended to show images linked with en:Template:Commons and en:Template:Commonscat. Or are you looking for a browser interface, such as an automatic semi-panorama based on the geocoded camera locations, as proposed on a mailing list? If we geocode object locations, we'll end up duplicating information, that's for sure. To avoid that, we'd need an additional link layer, such as image annotation, to link to a Wikipedia or even a Commons article, both of which can have coordinates. People are working on this at the moment to make it happen on Commons as well. Do any of these suit your purposes, or is there a need for some new tools? Meanwhile, please do not degrade the quality of our geocoding with object locations that other people will have to clean up afterwards. --Para14:10, 5 July 2007 (UTC)[reply]
No, I don't see how any of those would do. In many cases there is neither the category or gallery on commons nor the article on Wikipedia. Because of that I don't see why it would be a duplication of effort either. And geocoding the object at least has some clear usage, as I see it: Create a Wikipedia page about a new location, or take one that does not have an image, and check whether there is a (geocoded) image on commons showing that location. I don't see that much of a use case for camera location. For every person looking for a picture of the view from a certain place, there will be 100 looking for a picture of that place. That is, in my opinion, what we should be doing on commons: Give people the possibility to find and use images they need for their article, book or webpage. And that's mostly done by having searchable, indexed or whatever descriptions of what is on the image. - Andre Engels23:53, 5 July 2007 (UTC)[reply]
If the picture is not in a category or gallery add it to a category or gallery and geocode the category or gallery. What is so hard about that?! It kills two birds with one stone. It makes media retrievable on commons and makes it easy to automatically geocode the categorized pictures. If the category or gallery already exists its even better, then you automatically geocode a whole bunch of images by adding just one Location template. --Dschwen10:54, 6 July 2007 (UTC)[reply]
Camera locations are mostly unique, but object locations are not. There will eventually be more images of the object, and if you feel it's interesting enough for its location to be geocoded, then it may well deserve a Commons or Wikipedia article too. If not, then geocoding the object location every time will be duplicating information. Also compare the usability of querying with the coordinates of the object and getting 100 images placed in the same location, to querying with the coordinates of the object with some radius and getting 100 images placed in a circle, pointing towards the centre point. With the first I'd have to look at all the images, whereas with the latter I'll already know which view of the object to see. That also answers the needs of the use case of finding a representative image of an object for an article; you'll be mostly looking for images of the facade and not just any random image with some view of the object. --Para11:44, 6 July 2007 (UTC)[reply]
"Camera locations are mostly unique, but object locations are not." - not necessarily. A high point in the landscape may have several pictures taken from it, an object location can often be split in several locations. Also, object locations can often be given much more precision than camera locations. If I take 3 pictures at three places 50 meters apart of 3 objects 50 meters apart, it isn't hard to give separate locations for the objects, but it is to give separate locations for the photographer positions (unless you happen to be the photographer and still remember).
"if you feel it's interesting enough for its location to be geocoded, then it may well deserve a Commons or Wikipedia article too." Why that? Every picture that is of a specific location deserves to be geocoded, in my opinion. That doesn't mean that it necessarily deserves an article. And even if it does, why would I be the one to write it?
"Also compare the usability of querying with the coordinates of the object and getting 100 images placed in the same location, to querying with the coordinates of the object with some radius and getting 100 images placed in a circle, pointing towards the centre point." - Now compare getting 10 images placed in the same location with 100 images placed in a circle around that location, 10 of which are of that location. With the second you have to look at all the images, with the first only of the 10 that are of the object that you want.
"you'll be mostly looking for images of the facade and not just any random image with some view of the object." - I don't think so. You want a picture of 'the church of Loppersum'. Probably the picture looks better from one position or the other, but the easiest way to find out which you want is to see the pictures from a few directions and compare. If you want a picture of the north façade of the church, and you find there is none on commons, would you prefer a picture of the west façade or a picture of the north façade of the building next to it? - Andre Engels14:24, 6 July 2007 (UTC)[reply]
As you say, "an object location can often be split in several locations", whereas with each image there is only one camera location. That something is easier to do shouldn't be a reason to do it that way over something slightly more complicated, where the results can better be used. For example, I recently geocoded the images in Category:Trevi fountain quite easily, and while geocoding the object locations would have been even easier, the camera locations provide much more information of what you'll be seeing in the image and from which angle. Can you give a similar example of a big group of images on Commons where the camera location would not be enough information? How can you find the church pictures for example from the few expected directions, when you only have the church location? With camera locations you can "walk" around the object in the correct order, and choose images taken from the same distance only. It's true that minor details or huge structures would not fit into this model with the currently entered information, but they are only the tails of the bell curve. Commons articles are not a whole lot of work to create, and many of them are already divided in sections such as "north side" or "bend near Schipborg". If a location tag at the top of the article for the center point is not enough, you can put one in each section. --Para08:41, 7 July 2007 (UTC)[reply]
I don't agree that the camera location gives more information about what you see than the object location. To me the information that something is part of the right half of the fountain tells me more about what I'll be seeing than the information that it is on a picture taken from the right front side. As for the church pictures: Just go through the pictures until there's someone you like. In your case you would do the same, except that the pictures you don't like are not of the church at all, but of neighboring objects. If I want a picture of the church, I go through the pictures of the church. If I want pictures of the north side of the church specifically, I do the same. In your way, if I want pictures of the church, I go through the pictures of the church and a great many objects around it, and if I want pictures of the north side of the church, I go through pictures of the north side of the church and some pictures around it. The first is easier in my method, the second is slightly easier in yours (but only slightly so - if you have trouble distinguishing a picture from the north side from a picture from the south side, you are probably not interested in a specific direction anyway).
"That something is easier to do shouldn't be a reason to do it that way over something slightly more complicated, where the results can better be used." - Often it will be more than 'slightly' more complicated. Direction is easy to judge in most cases, but I'm not good at judging distance at all. And I still disagree that 'the results can better be used'. I think distinguishing between pictures of the church, pictures of the church tower and pictures of the building next to the church is much more useful than distinguishing groups of pictures of all three by direction and distance from which they are taken. - Andre Engels07:02, 4 August 2007 (UTC)[reply]
Just reiterating disbelief in each others arguments will not bring us one step further. You basically just state a personal preference. The only convincing argument I've heard in favour of object-location-coding was brought forward by Kolossos (the city location no-redundancy argument). Fine, so we should come up with a way to code either. Nonetheless current de-facto policy is using the camera location as a default foremost due to its uniqueness. --Dschwen13:44, 5 August 2007 (UTC)[reply]
I would also prefer to have the possibility to geocode the object or the cameralocation. We have in the wikipedia many city articles with all object in this article and only one coordinate, so there is no redundant in this case. Kolossos10:38, 24 June 2007 (UTC)[reply]
That's inevitable I suppose. When people run out of articles to geocode, they'll want to geocode smaller things mentioned within the articles. The image annotation idea for Commons would work great if we could link an area in the image, or maybe the whole image, to a coordinate somewhere. In my opinion it would be best with named coordinate tags on Wikipedia, though with separate wikis with no real dependencies the links would probably rot quickly. Just copying inline coordinates from Wikipedia articles would be much harder to keep up to date if no automatic comparison of the information is possible. We could of course improve on that, like we have with coordinates more precise than Wikipedia coordinates, by geocoding the exact location of the side of the object visible in the image, but I'm not sure if that's so useful really. --Para11:13, 24 June 2007 (UTC)[reply]
One idea I have is that: If the Geotag has no heading-parameter it is automaticly the geocoding of the object, else it is the geocoding of the camera. Opinions? Kolossos20:31, 6 July 2007 (UTC)[reply]
I would propose separate geotags for photographer and object location. The general tag should then only be used where they are close enough to be put on a single geolocation. - Andre Engels21:21, 6 July 2007 (UTC)[reply]
Most geocoded images unfortunately don't have the heading information yet. It's just an optional parameter and doesn't change the outlook of the template, so I don't think we can give it such a big side effect. Same goes for other additional extra parameters; as long as they're not rendered, we can't make them too important. Perhaps a new template parameter could be added then, I don't know. I think any object location tagging will have to be tied together with image annotation (see example) somehow, and it must not be too similar with the camera location geocoding of this project so as not to confuse people. At the moment the best rule of thumb is that articles and galleries are about objects and their locations, and image pages about the location they were recorded in. --Para09:01, 7 July 2007 (UTC)[reply]
If distant camera locations are supposed to be marked, what is the proper geocoding for a satellite or airplane? What markup is to be used on the picture of Earth from a Mars rover? (SEWilco13:25, 28 July 2007 (UTC))[reply]
An altitude parameter might be useful even in more common locations such as underground, inside a building, or above it. It's the lack of reference data that would make use and review of such a parameter hard. Vertical angle of view would also be good to know whether the photo is of something on the ground or the spire of a church for example, but I'm not aware of any way to visualize the information. Perhaps we can see the situation with the non-outlier images again if a 3D scene browser such as the ones from the University of Washington and Microsoft (mentioned above) become available. --Para16:36, 28 July 2007 (UTC)[reply]
The Google Earth KML format which is being used for location identification is also able to include camera position and polygon drawing, so it would technically be possible to view a region from a certain location and orientation, and polygons could frame views or mark viewed regions on terrain. (SEWilco21:01, 5 August 2007 (UTC))[reply]
I've been getting the following Google Earth error message for the past several days. "The GeoCommons database is currently unavailable, please try again later." I wonder if anyone can provide more information? Thank you, Walter Siegmund(talk)04:17, 28 June 2007 (UTC)[reply]
The new database server will likely be installed during or after the weekend. The current one keeps crashing all the time, so it will also be reinstalled at the same time for the tools that continue using it. Until then you can keep an eye on the replication lag graph where the downtime is visible quite clearly, and perhaps catch some moment where the database is available. This is all very exceptional. --Para 08:46, 28 June 2007 (UTC) --Para08:46, 28 June 2007 (UTC)[reply]
The maintenance with Commons related tools is now done and everything is back to normal. The replication lag is also steadily going back to 0, which means that geocoding updates will be visible instantly. Lots of images left to geocode! --Para22:28, 4 July 2007 (UTC)[reply]
But please seperate from photos, so use an other template than Location (perhaps Flag-location) or use an additional parameter. I think this should be a good job for a bot, because we have many coordinates on wikipedia. --Kolossos18:57, 2 July 2007 (UTC)[reply]
Just keep the same template! The extraction script filters using the categories the image is in. No need for multiple location-type templates. --Dschwen20:17, 2 July 2007 (UTC)[reply]
If it is so, then ok. An other question is the same like all other objekts, a flags is valid for an area not for a point. So for instances the flag of germany marks an area which contains other flags. Perhaps a type:country/state/adm1st/adm2nd/city would be useful as additionally parameter in the template. Kolossos21:00, 3 July 2007 (UTC)[reply]
Doesn't work in Konqueror either. The safest bet would be either a getElementsBy class on the span class="geo" Elements, or getElementsByTagName('A') and filter out all links pointing to the geohack page. --Dschwen22:14, 11 July 2007 (UTC)[reply]
After some discussion, elsewhere, of the possibility of a date-time stamp for pictures, I came up with the following mark-up;:
<div class="vevent">
<span class="summary">Unveiling of the Equestrian Statue of Robert E. Lee.</span>
<span class="dtstart">1890-05-29</span>
<span class="geo">37.553861;-77.460194</span>
</div>
Alternatively:
<div class="vevent">
<span class="summary">Unveiling of the Equestrian Statue of Robert E. Lee.</span>
<span class="dtstart">1890-05-29</span>
<span class="location">Richmond, Virginia</span> (<span class="geo">37.553861;-77.460194</span>)
</div>
Both include an hcalendarmicroformat (classes vevent, summary, dtstart and location). If desired, the location could also be in an hCard (classes vcard, adr, locality, region, geo; could also include street-address, country-name, etc.; if there is insufficient granularity for "adr", then "label" could be used instead) and adr ("address"; subset of hCard) microformat:
<div class="vcard vevent">
<span class="summary fn org">Unveiling of the Equestrian Statue of Robert E. Lee.</span>
<span class="dtstart">1890-05-29</span>
<span class="adr location">
<span class="locality">Richmond</span>,
<span class="region">Virginia</span>
</span>
(<span class="geo">37.553861;-77.460194</span>)
</div>
The final example gives:
Unveiling of the Equestrian Statue of Robert E. Lee.1890-05-29Richmond, Virginia (37.553861;-77.460194)
which could be prettified, if desired.
Where known, the "dtstart" can also include a time:
I suggest we wait for the "eventually": microformats and other additional output formats should be generated by MediaWiki. If they are desired now and implementing them in the existing templates is possible without any change to which templates people use and how they use them, then by all means go ahead. If however editors would have to jump through hoops, such as use some special template instead of the existing ones just to get a microformat generated, then it won't be acceptable. At the moment the data required for this microformat is entered with {{Information}} and {{Location}} or {{Location dec}}, so it won't be possible to start and close the microformat from a single template. If the description field is enough for the microformat instead of the image file name, the Information template could be modified to take coordinates as well, making microformat generation possible, but coordinates may not be used widely enough yet to support the addition now. It's best to turn to Bugzilla to have properly tagged and generated additional output from MediaWiki, and all these problems will be solved. --Para09:25, 28 July 2007 (UTC)[reply]
Contrary to your misleading edit summary, what I suggested is all "do-able", by modifying existing templates or creating a new one - ether would work. There's no point waiting for some hypothetical change in MediaWiki software, which could be literally years away. Andy Mabbett09:58, 28 July 2007 (UTC)[reply]
New templates to enter the same data that is already entered with the existing templates will not be supported, and will probably end up deleted sooner than later. The last time this modification for the Information template was brought up, it didn't get much support, and nothing has changed since then. --Para10:15, 28 July 2007 (UTC)[reply]
What has changed since the edit-request you cite is the suggested inclusion of hCard and hCalendar microformats; which is what this suggestion is all about, and which were not mentioned in the previous request, which you supported with the words "I still agree with changing this template though. It would be good to have an optional parameter for the location, because currently it can be scattered anywhere on the page and it would be best if you could always find each piece of information from the same place". GMaxwell's suggestion to use Location={{Location dec}} was right on the ball. The request was withdrawn by its proponent, but only for unrelated reasons, to do with coordinate conversion. Andy Mabbett10:30, 28 July 2007 (UTC)[reply]
The previous discussion's lack of support actually was lack of participation, and the topic was DMS coordinates (there was also an irrelevant complaint that en's "coord" was complex when the issue seemed to be a single DMS format). How can one tag the time of an item? I can mark an image's geographical coordinates but not its time coordinates. The unveiling of a statue a century ago is indistinguishable from a recent photo. (SEWilco13:15, 28 July 2007 (UTC))[reply]
The date of images here is entered in ways too varying to be machine readable. The somewhat unreliable EXIF data can be read directly from the database and would easily be usable, but where the data would actually be useful, the historical images, it's written as free format text in the information template's date field at best. In the tools that visualize geo- and timecoded data, does the user interface have something to control the display depending on the time dimension? There has to be a workable use case to get people interested. --Para15:35, 28 July 2007 (UTC)[reply]
Indeed, Flickr for example works great with the EXIF mined dates [5]. But Mayflower has a long way to go, since search requires machine readability, without which an image's timestamp can't be compared with the requested date. Historical images, if they're not pngs with no metadata, probably have the scanner's date or nothing at all. The Commons database currently shows about half of all image pages using the Information template, and there has never been any requirement to fill in the date field following a certain format. This would be a good opportunity to encourage the developers to allow the fields of the information template to be filled in separate html fields, so that their contents can be sanity checked and some formatting enforced. That would still only affect new uploads, leaving a lot of work to go through the existing images. --Para17:15, 28 July 2007 (UTC)[reply]
Well, we need to start somewhere. For new image uploads, with EXIF, we could say something like "it appears (from EXIF) that this image was made on xxx, is that the date we should use". We can also accept any EXIF dates from before the introduction of EXIF (~1998), since they must have been set deliberately. For all metadata (addresses, as well as dates, for example), a high degree of granularity is essential. A bot could probably trawl the date field, and convert clear examples, reporting any ambigious cases for human intervention. But first we need to provide the relevant containers for granular data information - and that's what's proposed here. Andy Mabbett18:59, 28 July 2007 (UTC)[reply]
The containers already exist. Combining them is a job for MediaWiki. I don't see how this bad idea of implementing microformats in templates should be any reason to have to change the well established use of existing templates just so that microformats could be implemented. What you're proposing with the dates is also a modification to MediaWiki. Before you can generate any output that expects the input to be in a specific format, you need to ensure that all existing and future data is in that format. Garbage in, garbage out, and to fix that you need both the bot run and changes to MediaWiki. Again, Bugzilla is that way. --Para10:17, 29 July 2007 (UTC)[reply]
You have yet to demonstrate the existence of suitable containers, or why you believe this proposal to be "bad". You certainly haven't detailed how the equivalent services could be provided to Commons' users, in a similarly short time-scale. No change to MediaWiki is included in this proposal (if you think there is; please point it out). Your claim about the supposed "need" to demonstrate data formats is also unfounded; and recent experience on Wikipeida - where many thousands of microformats have been published, easily and quickly - is to the contrary. The proposal is not "just so that microformats could be implemented" - it uses them in order to facilitate machine-readable date-time- and location- stamping of images, to allow searching and filtering, as already described. Do you have anything positive to contribute? Andy Mabbett11:08, 29 July 2007 (UTC)[reply]
So now that you're facing a ban on the English Wikipedia, you'll be coming here to fuss with that style of argumentation? I'll try my best to adjust and re-explain everything:
{{Information}} has a suitable container for a date, and {{Location}} is a suitable container for coordinates. If you want to see the two displayed together in another format than what they're now, it's to be done by tagging the data appropriately and then creating a software interface where a certain set of tags with the content can be requested to be output. It is not to be done by following your proposal and forcing the data to be entered through a single element just because some poor output implementation might need it done that way. This requires a MediaWiki modification to (1) support semantic data entry and queries. You say above that the dates in the microformat are expected in a specific format. Since only 50% of the files here have a date field at all and the format of that field is unspecified, applying a tag to the unknown data stating that the data is given in that specific format would be entirely invalid when we have no way to be certain of the format of the actual data. This requires a MediaWiki modification to (2) allow the Information template to be filled in in parts through separate html form input fields and to (3) check the validity of the given date against a decided date format on image upload. All information for file uploads is requested before the actual upload, so any EXIF checks and subsequent human intervention will need a MediaWiki modification to (4) allow file metadata to be entered before and after upload. You have failed to explain why Commons users would need microformats in any short time-scale and couldn't wait for proper support in software, be it months or years away. There is no hurry, and implementing things badly instead of doing them properly is not helping anyone. --Para12:55, 29 July 2007 (UTC)[reply]
The way that you resort, not for the fist time, to ad hominem, suggests that you may be aware of the inadequacy of your argument. While {{Information}}has a container for a date, it does not have the container for granular date information which was being discussed. Nobody - other than you - has suggested "applying a tag to the unknown data stating that the data is given in [a] specific format" and - once again - no MediaWiki modification is necessary to carry out this proposal. The sooner the proposed solution is implemented, the sooner people can begin work on systems which allow advanced searching and parsing. You have still not demonstrated that any harm would be done by this proposal, so your allegation of "implementing things badly" is bogus. I'm sorry that it seems that you do not, after all, have anything positive to contribute. Perhaps you might stand aside so that those who do have space to comment? Andy Mabbett17:00, 29 July 2007 (UTC)[reply]
Do you understand what it means when you say that "Dates use ISO8601/RFC3339"? If there is even a single file on Commons where the date is not in that format, your format requirement breaks. Most of the files currently on Commons do not have the date in ISO8601/RFC3339-format, and we can't say anything about future files. A single bot run or even a recurring one won't help. If the microformat html is applied to the Information template now or anytime soon, it will generate broken microformats with most images. Enforcing the validity of granular date information is not really even possible on Commons as long as we're running on wiki where everything is free to edit. An upload time check would help the current situation but it wouldn't solve the problem. Which part of this is so hard to comprehend? --Para17:45, 29 July 2007 (UTC)[reply]
"Do you understand what it means when you say that Dates use ISO8601/RFC3339"? Yes. The rest of your comment appears, once again, to be tilting at windmills, since what you describe is not what is proposed. what you fail to comprehend is that these issues have already been successfully addressed in Wikipedia-EN. Andy Mabbett19:08, 29 July 2007 (UTC)[reply]
The instructions at Special:Upload say that the field is the "date of creation or publication if the former is unknown", so the event date is actually preferred. Not that we can expect anyone to read and follow instructions though; it would have to be two separate date inputs. Most people are probably interested of the event date, but on Commons we also need the publication date for copyright and source verification purposes, especially with historical images. Both would be ideal, but again, there's no format requirements. --Para08:49, 31 July 2007 (UTC)[reply]
There is no reason why the above proposal could not be modified to include separate "event date" and "upload date" fields - again, this is all about improving data granularity. Andy Mabbett09:14, 31 July 2007 (UTC)[reply]
Actually {{Information}} uses as documentation Commons:First steps/Quality and description#Good file descriptions. The "Information" Date is apparently the date of publication. Possible dates are "date of event" (what I want to label due to its relevance to Wikipedia articles), "date of publication", "date image file created" and "date image uploaded to Commons". I'm looking for a way to indicate "date of event" so as to have a more complete time/space label. (SEWilco16:45, 31 July 2007 (UTC))[reply]
Google Earth has time capabilities now, although I only know of their being used for map images (time lapse animations). I expect that they'd soon use time for point info, such as to help separate current images from Benjamin Harrison coming ashore. (SEWilco01:45, 29 July 2007 (UTC))[reply]
It seems to support a timestamp for placemarks, showing a slider where the range of visible placemarks can be chosen, with the scale computed from the min and max timestamps. There's an image of the control here. Most people interested of images of a location probably don't mind getting historical images of the place, but images of events other than from modern day may not be expected, such as a statue unveiling or something moredramatic. Anyhow, I'm not entirely happy with the Google Earth time interface, mostly because of the linear scale, lack of time transition effects for placemarks, and a missing time of day selector. All these missing features could of course be hacked to the server side and used with special url parameters, but...meh. --Para09:12, 29 July 2007 (UTC)[reply]
Unfortunately I don't know of any time formats which Google is recognizing in WM searches. Google Earth is time sensitive but I haven't seen any description by GE people of time detection by googlebots. (SEWilco03:24, 31 July 2007 (UTC))[reply]
That's because they don't recognise any in other searches either. If we can't demonstrate something ourselves, even though we have easier access to current data than someone external, we can't reasonably expect anyone else to grab the ball first. Mayflower is undoubtedly the first that could have a date search feature, but implementing it would be hard as the dates aren't in a single database column like the other data it uses, but as free text. If the date information in images was machine readable, I could easily add it to our Google Earth Commons layer even if the GE time interface isn't top notch. But just as with microformats, it wouldn't work with the current unspecified data. --Para08:49, 31 July 2007 (UTC)[reply]
"just as with microformats, it wouldn't work with the current unspecified data" - this proposal allows for the use of "specificed" date-time data. Andy Mabbett09:14, 31 July 2007 (UTC)[reply]
Does it seem reasonable to add to {{Location}} two optional terms for more complete space/time coordinates? A "height" term and a "time" term. I say "term" because several template parameters might be involved, such as an optional "Above Sea Level" parameter. The "time" would indicate the time of the event which is imaged. I'd like to allow such tagging now, and the exact display format can be adjusted when standards appear. There is no elevation microformat yet. A time/space geo format has stalled, although a datetime pattern has been noted which is not yet used in a time microformat. (SEWilco16:45, 31 July 2007 (UTC))[reply]
This is a tentative proposal for Location in context of the above discussion. If there is interest then it would be proposed again in the template's Talk page, where such proposals seem to belong. (SEWilco16:47, 31 July 2007 (UTC))[reply]
I would support that, in principle, and would encourage templates designers to allow, if not mandate, extra granularity, as described, for instance at [6]. (Th microformat design process can be, regrettably, slow. Feel free to voice your support for proposals, and to participate in their development, on its wiki and/ or mailing list!) Andy Mabbett17:29, 31 July 2007 (UTC)[reply]
Data entry templates shouldn't be designed based on possible output formats, and time isn't an attribute of a location. That said, you can put any parameters you like in the parameter field of the location templates, but they can only be used by external tools. Actual template parameters shouldn't be added to mess up all the tools that rely on the current format unless it's something indispensable. All the additional parameters proposed on this page, heading, altitude, vertical angle of view, etc are in the "nice to have" category, but not essential. --Para21:40, 31 July 2007 (UTC)[reply]
Well, Location would of course show time in some reasonable format. But you're right, it would be too awkward explaining that time is also a coordinate. A different template should be used... Event date? {{Yearcategory}} seems broken. Don't want to use Image date or Photo date so as to avoid confusion with publication date. (SEWilco04:03, 1 August 2007 (UTC))[reply]
The contents of the date field in the Information template could perhaps use templates to signify the possible types media recording date (event date) and media publication date. Start and end wouldn't make sense unless the recording time was really really long. But that should be discussed at the Village pump since it doesn't have anything to do with geocoding anymore. If the dates here can be made machine readable and appropriate interfaces become available to use them with geocoded data, the tools that use the current geocoded data will adapt. --Para08:50, 1 August 2007 (UTC)[reply]
Dates can and have been made machine readable (note the Wikipedia example I posted about 15 hours ago); and tools already exist which read dates and coordinates from within hCalendar mark-up, as proposed here. While this isn't a geocoding issue per se, it is a proposal to add dates and coordinates within one, unified, metadata framework. Andy Mabbett09:27, 1 August 2007 (UTC)[reply]
By way of showing what is possible, I have added hCalendar to the Infobox Space mission template on Wikipedia-EN (See for example, Apollo 11), with dates entered using the Start date template, which degrades gracefully when CSS is not available. Work needs to be done to add HH:MM:SS to the latter, and there are issues around hCalendar's clunky non-inclusive end-dates, which are not relevant to this proposal; but if I can do that in half an hour, the combined talents here can easily implement this proposal. Andy Mabbett18:54, 31 July 2007 (UTC)[reply]
I use a personalized information template, and added support for Latitude and Longitude parameters, which were then passed to {{Location dec}}. However, images using this showed up with a red background and with no coordinates at the recent changes page. I changed one of these images so that it calls Location dec manually, and it started working. Is it really not possible to call Location dec from another template? If not, why not? This seems like a pretty severe flaw. --bdesham★14:40, 30 July 2007 (UTC)[reply]
Because following through a chain of templates from the wikitext requires a copy of all involved templates (which could be hundreds, due to all the fancy parserfunction wrapper templates) and a complete mediawiki parser with parserfunction support. No such parser exists, except the one in Mediawiki itself. This is why Commons:Geocoding is quite specific at directing you not to make your own custom geocoding templates, so please don't. Just pretend that {{Location dec}} is a part of the wikitext syntax and not a 'template'. --Gmaxwell15:30, 30 July 2007 (UTC)[reply]
This is really annoying :-/ Hopefully wrapper templates such as mine will be possible in the future, but in the meantime I'll change all of my images to the standard templates. (I don't think that the article was really clear on this, so I've updated it. I didn't really "make my own" geocoding template; I was just calling one of the standard templates, which would have the desired effect on anything using MediaWiki as a parser.) I noticed that you've already changed some of my images—thanks! --bdesham★17:15, 30 July 2007 (UTC)[reply]
I see you're also introducing licensing to the page via your custom template. Bad bad bad. User templates that introduce licensing data must be substed per commons policy. We can't have people instantly changing the licensing on hundreds of pages by making a single edit to a user template that no one is watching. Instead, why not just add a chunk to your monobook.js which pre-fills the standard information template with your normal licensing data? --Gmaxwell15:34, 30 July 2007 (UTC)[reply]
I only use the template on the images to which I own the copyright, so I don't really see a problem. I anticipate switching to the CC 3.0 licenses for my photos, and I don't want to have to change sixty images by hand when that happens. (This would less of a problem if there were a publicly-usable bot that could do simple search-and-replace; is there such a thing?) --bdesham★17:15, 30 July 2007 (UTC)[reply]
I take such requests for people.. I've done it for a half dozen users in the past. I don't know where to advertise that.. however. Anyone who wants to take the time to figure it out can use pywikipedia bot to make changes like that.--Gmaxwell18:21, 30 July 2007 (UTC)[reply]
Some very very interesting SVG-links - Web mapping within Wikipedia ?[edit]
Here's a question: For any given geocoded image, is it possible to create a template for the image's summary page which could show other geocoded images within a certain radius?
For example, for Image:WAGovernmentHouse1crop_gobeirne.JPG (location: 31°57′27.3″S, 115°51′42.6″E), you could have a box showing:
That would be "Images taken from within...". I'm not sure we should make this a static template. Rather link to a script from the map-hack page. --Dschwen06:38, 21 August 2007 (UTC)[reply]
Geograph.uk is a large database of freely licensed images covering most of the UK. Basically purpose of the site is to build a well covered 'photo map' of the UK.
We sometimes import images from the site, and I'm thinking about doing a large scale automated import of many of their images. I'm wondering what the tagging on an ideally imported image would look like. Here are some pre-existing examples: this imported as Image:Truro_leats.jpg, and [7] this imported as Image:Truro_cathedrallane.jpg. Sadly most of the people uploading these to commons thus far are not entering the geodata (UGH!).
One interesting tidbit is that geograph geocodes the subject location and the photographer location, but usually only provides the photographer location when its outside of the margin of error of the geocoded subject location. I'm thinking we should put the photographer locatiom if provided in the tagging on our articles, and if it's not assume the subject location field is close enough. Thoughts?--Gmaxwell04:07, 26 August 2007 (UTC)[reply]
We have around 2500 images from this page[8]. So it would be useful to use a bot to transfer the geo-informations to commons. I also think that a automatism could be useful to transfer a image from there if it is needed, but for automatic transfer of boring images like http://www.geograph.org.uk/photo/179774 I'm not sure. Kolossos10:31, 26 August 2007 (UTC)[reply]
The site has been a great reference resource when I've geocoded some UK photos here, and I suspect not many people are aware of it so an import of some kind might help making the material better available. But there are over half a million images and not every square kilometre of the UK is interesting or useful for us, like Kolossos pointed out. Would a FlickrLickr-type collaborative review and upload interface be overkill for this site?
For geodata transfer, I think there is a need for a metadata comparison bot for all images that come from a site where users can redefine the data, whether our current copy already contains some or not. Only Flickr and Geograph come to mind, but there are surely others. The foreign data may not always match our standards in precision or with the subject/photographer location choice, so it would have to go together with a review system of some kind. One possibility could be having a bot note any geodata differences on the image page, making the suggestion visible for all viewers, and an editor working to check the differences could then dismiss the suggestion so that it's not shown to viewers anymore, but preserved in the wikitext for the bot to see as handled. Going through all the images from the few identified source sites once a month or so ought to be enough. With this kind of system in place, the original imported location would be up for review already. --Para11:41, 26 August 2007 (UTC)[reply]
The difference between Geograph and Flickr is one has high quality images and the other high quality metadata. Obviously, we would like both in our images. One thing I think it would be worth preserving is both the WGS84 datum and the OS grid reference; its easier to add them both at upload than work out the grid location again from the WGS84 lat/long; its possible the double conversion (the original uploads are to the OS grid) might result in the occasional error. My biggest concern would be about images that are not correctly geotagged in the first place.
To say not every square kilometre of the UK is not interesting for our needs may be missing the point.. I'd like it if we could have images from every square km of the planet with compatible licensing (imagine the mosaic we could make!). As for that image Kolossos pointed out; a possible use it to illustrate cornish hedge. A high quality image of a random location is pretty useless if we do not know where it is; but if we know where it is we may find a use. Sure its not that useful but I don't see that much harm - the copyright is clear, and server space is cheap ;)--Nilfanion22:14, 30 August 2007 (UTC)[reply]
It's one point that server-space is cheap, but we also need human-power for categoriesation, prove geocoding, integration in wikipedia and so on. For human-power we need motivation and for this point we need that a major part of our images are high-quality, interesting and motivating images. So I think a human selection at the begining seem useful for me, the rest can be automation. An other critical point is the resolution of 640px, so if we wait, I think we can get better images of Great Britain, which are directly uploaded here. --Kolossos08:20, 31 August 2007 (UTC)[reply]
I am in the process of uploading a significant number of images using Commonist. One of my images was subsequently tagged- so I followed the link here- fantastic idea- but how do I insert a geocoding tag while using Commonist? Or is there I tool that will trawl through my contributions and allow me to geocode- post upload? If so how? ClemRutter08:48, 23 September 2007 (UTC)[reply]
Geocoding on Commons is done by adding a location template to the image description page, so it can be done before or after upload. If you have a big batch of images on your computer, I'd recommend using Picasa and Google Earth. There's instructions at Commons:Geocoding and w:Wikipedia:Obtaining geographic coordinates#Google tools. After you've geocoded the images locally, you can convert the resulting KML to wiki format and paste each tag on the image description pages or to Commonist's upload form. The instructions page mentions many other methods too if you'd rather use other tools. --Para15:03, 24 September 2007 (UTC)[reply]
The obtaining of the co-ordinate presents no problems, Google Earth with the coordinate grid set on- then dumped to printer is excellent. (I no longer use a sextant!).
But it is where to place the {{location dec}} in the commonist description boxes that is confusing. There is an instruction not to wrap the template in your own custom wrapper. There is an instruction to put the template on the first line. I have trial image here where I have included the the template at the last line of the commonist image description box. .Will this placing be good enough for the bots?
Will this necessitate a bot rewrite? If this breaks the bot, is it better to leave the template out out, or put it in and believe in the future?
Ah. The appearance of the Location templates has been designed to fit above or below the Information template, but it shouldn't be a problem for any parsers if it's inside the description field. The wrapper mention refers to templates which take some numbers and may or may not feed them to the coordinate templates. If the coordinates have been given in the image page wikitext as described on the instructions page, it doesn't matter if the coordinate template string is nested in another template. To prettify what Commonist generates though, you should contact the author to ask him add some new fields for geocoding. Seeing empty fields would be a good reminder for other users too to geocode their images. --Para16:45, 24 September 2007 (UTC)[reply]
I take it that there is currently no freeware that allows one ot edit GPS Exif tags? Opanda IExif allows me to read those tags just fine, but not to change them. Luis Dantas03:53, 24 September 2007 (UTC)[reply]
I recommend ExifTool. It is a mutli-platform Perl programm multi-licenced under the same conditions as Perl (GNU GPL or Artistic Licence) and is therefore free (both as in beer and as in speech). It may seem a little inaccessible at first because it is a command line tool, but the website provides excellent help and examples. --Florian Prischl16:06, 2 October 2007 (UTC)[reply]
Thanks! ExifTool isn't really all that difficult to use. I managed to add GPSLatitude and GPSLongitude info on a couple of images already. However, I am disappointed to see that (1) I do not know how to add heading information and (2) apparently neight Flickr nor Wikimedia Commons do recognize what I assumed to be standard Exif Geocoding information. See for instance [9] which as far as I know has perfectly fine Exif GPS info, yet is not recognized as such. Any help? Thanks! Luis Dantas11:36, 3 October 2007 (UTC)[reply]
I can see (using ExifTool) the GPS info you added on that picture in the EXIF information, but it does not show up in the EXIF data provided on the image page at the Commons (go to the Image page, and in the "Metadata" section click "Show extended details"). This is likely because you did not enter several, at least in some cases important, GPS information fields, such as GPS Date/Time and, probably most importantly, GPSLongitudeRef and GPSLatitudeRef, which you mentioned. Without these two any position information is useless, so this might be the reason it is not recognized. The ExifTool information page on GPS data seems to corrobarate this: "When adding GPS information to an image, it is important to set all of the following tags: GPSLatitude, GPSLatitudeRef, GPSLongitude, GPSLongitudeRef, GPSAltitude and GPSAltitudeRef. ExifTool will write the required GPSVersionID tag automatically if new a GPS IFD is added to an image." For further reference, I have uploaded a photo of mine about which I am very sure that it is tagged correctly (because this was done by software). However, even my picture lacks the GPSAltitude and GPSAltitudeRef fields. Yes, the Commons currently have no way of automatically handling GPS information stored in the EXIF data. Please read the File metadata section above, where I am currently discussing that topic with Dschwen --Florian Prischl12:36, 3 October 2007 (UTC)[reply]
The example image you gave Tre_01.jpg is not yet in the toolserver database due to a lag of almost five days. I'll check back in a couple of days. --Dschwen14:18, 3 October 2007 (UTC)[reply]
I think that my recent uploads, e.g. Image:Arctostaphylos uva-ursi 25923.JPG, have all the GPS tags set including GPSAltitude and GPSAltitudeRef fields. I use Geotag Automator running under OS 10.4.10 to add GPS fields to .jpg files from .gpx files that I download from a Garmin GPS.[10] To read the file metadata, I use EXIF.py, a Python package.[11] I wrote a Python script to extract the location information from the EXIF fields and generate the location tag fields, as well as the information tag fields. This approach has reduced the effort required to geocode my images. Walter Siegmund(talk)02:14, 4 October 2007 (UTC)[reply]
Ahrgh, what am I doing wrong?! I cannot find your picture in the DB. But it should be there as it also shows up in Check usage. --Dschwen03:11, 4 October 2007 (UTC)[reply]
select img_name, img_metadata from image where img_name like '%rctostaphylos%uva-ursi%25923%';
I think I'm getting to the bottom of this. First of all I queried an out of date database server. Now that I query the correct one I see the images. But the Metadata that is extracted my Mediawiki and stored in the DB is incomplete. It seems to extract only the main-namespace tags. There are GPS tags in that namespace but they are not widely used. The Arctostaphylos uva-ursi 25923.JPG pic uses a separate EXIF sub-section (or whatever the correct terminology is) which is completely ignored by mediawiki. To extract the geo information a bot would have to download each and every image and do the exif extraction on its own. This is calling for a mediawiki patch! --Dschwen20:04, 7 October 2007 (UTC)[reply]
Is Wikimapia cross-polinization a possibility?[edit]
Wikimapia offers to let visitors indicate a Wikipedia article for marked places. And some versions of Wikipedia (pt at least) allow one to indicate the GPS coordinates for a place (allowing among other things a direct view from Wikimapia).
Could both resources be used to feed each other? Perhaps some sort of bot could be written to look for Wikimapia places that have Wikipedia articles that in turn inform their coordinates in a way consistent to Wikimapia's own info _and_ feature a Commons picture. Then, in the absence of other coordinates info, the bot could supply the one from Wikimapia, or that from the Wikipedia article, or perhaps some average from both - or perhaps only include it when it is identical/"close enough"/independently verified.
Wikimapia is an odd site: they have hardly anything written about what they do, there's no licensing terms mentioned anywhere, no API, and the data is only available overlayed on the maps with Javascript. While it might still be technically possible to screen scrape the data automatically, it wouldn't be an acceptable solution to import the data here. There are some bots on Wikipedia (en:User:The Anomebot2 most notably) that transfer coordinate data between Wikipedias. What else can we do to improve geocoding in Wikimedia projects? What is Wikimapia used for that our projects aren't? --Para12:33, 19 October 2007 (UTC)[reply]
I doubt there's room for confusion with our geocoded non-profit media repository and their heatmap project. I personally like calling my pet project that, but our project in whole should be identified as Wikimedia Commons or Commons Geocoding, and tools to maintain or help use the data can have unofficial nicknames but they are still only contributing to Commons. While its kml is only supported by Google Earth, it can be called Commons images layer for Google Earth or so, but NASA Worldwind and Microsoft Virtual Earth aren't far behind in making kml a universal format... --Para15:38, 16 October 2007 (UTC)[reply]
Heh, that's cool. A link could be added to our location templates and the GeoTemplate, as they still allow location linking (to Tower Bridge for example). I'm not entirely happy with the KML support though, looks like it doesn't support the full specs. Everything with styles, such as icons and the popup balloons look kind of funky. Should I implement workarounds or wait for them to possibly improve their support? Who knows if they consider it a finished implementation already? --Para11:54, 19 October 2007 (UTC)[reply]
I would say wait a week or so. Perhaps you need an aditional parameter for special styles for Google Maps or something. It's also possible to include Google Maps with an iframe into the geohack, but do we want this? I have also adopt my Wikipedia-World-script, but have some problems in some areas of the world.Kolossos13:29, 19 October 2007 (UTC)[reply]
There's already a proposal to put the WikiMiniAtlas to the top of the GeoHack page (see example). Since most of the GeoHack requests come from Wikipedia where the scale is often much larger than our landmark scale and we should promote the use of free data wherever it's possible, I don't think a Google Maps iframe would be justified. But on Commons we could still link to services that can visualize Commons geocoding, as long as the number of links stays below five or so, or can otherwise be fit in a compact area in the location templates.
About Google Maps' KML: now they have only announced the networklink support, while simple kml files have worked on the service for a long time already. As far as I know, styles have always worked just as badly, so I'm not too hopeful on them improving it anytime soon. --Para14:33, 19 October 2007 (UTC)[reply]
You have right, Google Maps in the geohack wouldn't be a good solution. Google Maps has some advantage ( high performance, working in very small areas,easy to use,realtime Commons-support by paras-script ...) but without showing the names of wikipedia-article or the images of commons directly it is not useful to use software which is not opensource/opendata. Kolossos15:10, 20 October 2007 (UTC)[reply]
I added links to the location templates then, but it's a bit Google centered. Would be nice to have a link to a full screen size WikiMiniAtlas with the location of the image centered and zoomed. When someone implements a proximity gallery tool, that'll fit in well too. --Para23:51, 20 October 2007 (UTC)[reply]
This is a quick hack http://tools.wikimedia.de/~dschwen/wikiminiatlas/fullscreen.html (proof of concept). But a fullscreen WMA is a bit slow. I've been given SVN access and Tim Starling will help me turn the WMA into an extension to be eventually hosted on the Wikimedia servers. I'm confident we'll see huge performance gains once this happens. But don't hold your breath, I'll have to do some code restructuring which will take some time. --Dschwen21:21, 25 October 2007 (UTC)[reply]
I can't get click to centre to work on Firefox. Double click to zoom and centre does work- though a error is thrown if you are already on maximum zoom- so panout and it is centred.
I do find 14 decimal places a little like overkill so I have modified the Javascript to give 4 decimal places by using the .toFixed method. It now looks like this.
Click on "Satellite" if it helps to find the location more easily, and zoom in.
Double Click on the exact location the media was recorded to zoom and center the map.
Click on your bookmark and you'll get a prompt with the geocode tag to add to the image.
Click Ctrl-C to copy this tag.
Switch to Commonist, click on the description field of the target image, click Ctrl-V to paste the tag.
As this is the tutorial page for geotagging, I feel that a specific section is needed for Commonist- to facilitate searches. Yes it is a little repetitive. I have posted this here as I am not sure exactly how to place it- and leave members of the project decide whether and where to include it.ClemRutter22:48, 19 October 2007 (UTC)[reply]
I don't know how, but it works! Tested in Firefox 2.0. I think only the first step is a little bit difficult, is there a idea to make it easier? Thanks. --Kolossos15:20, 20 October 2007 (UTC)[reply]
Use Google Maps to get latitude and longitude[edit]
Yes I think so, because it is reasaonably fast, but with the images I coded the location shown is systematically a few 10m off from the location I coded using the tool. Any idea how to avoid that? -- Klaus with K21:16, 18 January 2008 (UTC)[reply]
The visualisation of our geocoding in Google Maps is faulty, and all the icons there are a bit off. This is mentioned at Commons:Geocoding#Use of the information and is a problem with Google Maps only. It's a drawback to the ability of seeing Commons images together with high resolution imagery, and could be a problem if people trust the position of the icon more than whatever indicator they had when they located the point, and start correcting, but luckily I haven't seen anyone doing that so far. One possible fix would be to change the icon to another that shows the location at its centre point at the bottom, but giving up the Commons icon would show them less well connected to Wikimedia Commons. Another possibility would be to put up a separate GM page somewhere and move the icons with Javascript, but that's a bit of a hack, would identify as yet another instance of GM with barely anything added but still without all the GM features, and I'm not sure we have anyone who's prepared to maintain such a thing. We certainly don't want the reputation of being "off" either though. --Para15:08, 19 January 2008 (UTC)[reply]
That section and #Camera vs object location also mentioned that the object locations can be put on Wikipedia. There's even a possibility to use inline coordinates for locations that don't have an article of their own. --Para20:46, 24 October 2007 (UTC)[reply]
And what wiki should I choose to put coordinates to? What if there is no corresponding article in any wiki? And what about image galleries?
Do we geocode them? And if so, how do we do it? Say I have a map like this. It shows the location of a town within its Landkreis (a kind of district). Which location would I enter and which scale? --rimshottalk11:26, 25 October 2007 (UTC)[reply]
I'd say if the map depicts one point of interest then use the points coordinates. If it is a general map I'd take the approximate center of the map. The scale/dim argument would be the size of the shown area, that way a search for maps around a certain point with a given scale could be implemented some time. --Dschwen15:23, 25 October 2007 (UTC)[reply]
We have the /overlay-subproject here, but I found say that it is not useful for this kind of maps. --Kolossos
Right, I almost forgot about that. For real maps or satellite images this is definitely the way to go. But for pointmaps I'd do the simple point geocoding. --Dschwen14:53, 26 October 2007 (UTC)[reply]
I have several svg map images. What location do I code/tag. You suggest the centre. Can you explain why you would code the centre- and not the lower left corner. I am easy, but I think the reasoning should be explained. ClemRutter19:49, 3 November 2007 (UTC)[reply]
Why not upper right or upper left or lower right? There are four corners but just one center -> less discussion ;-). No but seriously, it just seems to make more sense to me to geocode a point that is in the map as opposed to on the edge or even on the corner of the map. If I'd be looking for maps which show a certain point I wouldn't want to end up with maps that show the point all the way in the corner. --Dschwen21:47, 4 November 2007 (UTC)[reply]
Many UK articles and images contain the UK grid system in the format say TQ 345 123 or TQ 3456 1234. en:British national grid reference system explains and the maths can be found through a link to OS. Question. Has anyone written a template that translates these to a geocode? Is there a BOT that I could run on a cattree to translate all these references? Should there be? How do I write one? ClemRutter15:35, 21 November 2007 (UTC)[reply]
It's important that we keep to a single coordinate system so that it's easy to use the data. If there is a considerable amount of images here with a UK grid reference only (or if there's going to be?), then they should all be converted to WGS84 and the Location templates. No information will be lost, as the grid reference can be kept with a source parameter, and clicking on any UK coordinates on Wikipedia or on Commons shows a converted reference anyway. The best way to go about this is to download a database dump, read through all the image pages in it and try to find the pages that contain an OSGB reference, perhaps with a regular expression. --Para16:53, 21 November 2007 (UTC)[reply]
Thanks, thats useful information but the propblem is UK specific. For forty years every eleven year old learned about the Grid Reference at school, all the walking maps prominently display grid references. The grid is based on OSGB36 and the conversion trivial. It is not a trivial Helmert calculation, hence the conversion question. The standard tag we use is {-{location dec|51.3815|0.4670}-} Iam looking for something that like {-{gridconvert|TQ 345 123}-} that could become {-{location ukg| TQ 345 123}-} or maybe a little javascript so I can highlight TQ 345 123, bookmark it, and be given the WGS84. I just hope that someone else has already done it. ClemRutter19:11, 21 November 2007 (UTC)[reply]
See Commons:Geocoding#Geodetic system - please don't introduce new geocoding templates, it will make the data harder to use. What you could do if you only have coordinates as an OSGB reference, is use one of the available conversion programs and enter the resulting coordinates here as any other coordinates. Wikipedia links seem to use http://www.rhaworth.myby.co.uk/oscoor_a.htm by User:RHaworth, so you can use that with TQ34561234 for example and either copy&paste the WGS84 coordinates from the GeoHack page the tool redirects to, or hack some Javascript together to screen scrape them. Or, since that tool is open source, you could just implement the whole thing in Javascript and be done with any cross-site scripting problems. --Para20:05, 21 November 2007 (UTC)[reply]
Great links- and all the hard work with calculations has been done! So, I can start being creative- don't worry I won't be creating any extra templates! Not yet! Javascript seems to be the way forward. Thanks.
Many thanks. On reflection, it would be sensible (and greatly appreciated) if you also published the coordinates using the Geo microformat (i.e. include one of the above patterns in your HTML source code, as well as outputting them for copying). Andy Mabbett11:45, 21 January 2008 (UTC)[reply]
I haven't got my head around microformats- why- or where you would want to use them, and brain is reaching capacity. If you show me which ones you want- then I'll have a go.ClemRutter13:46, 21 January 2008 (UTC)[reply]
Is there a way to do some magic on my own monobook.js file, so when clicking into the Location, Coor dms, and the alike, it takes me directly to google maps instead to geohack.php? I've seen js that converts from decimal to dms and viceversa, so I guess that isn't the hard part. However, how would I override in my monobook the link to geohack for one to googlemaps? -- Drini18:37, 30 November 2007 (UTC)[reply]
Should be easy: just find the GeoHack link, parse it, place the coordinates to your favourite map link, and replace the original link you found. I wrote something like that a while ago above to replace the Geolinks-US-hoodscale template. However, now that Gadgets is getting enabled in various projects and people don't have to edit monobook.js anymore, I'd like to make this more general. The idea is to have a script that adds user configurable links next to the GeoHack link, or replaces it.
There are a couple of options to get the list of possible map services:
Download the GeoHack parsed list of services using the coordinates as parameters - Could be slow and add unnecessary load to the toolserver if done on page load. If it's done on request, the experience would be even slower.
Download the unparsed GeoTemplate from Wikipedia, and essentially do in Javascript what GeoHack does now - Because of the Javascript sandbox, the requests would have to pass through the toolserver anyway, so there's little advantage to this approach.
Fork an appropriately pre-parsed GeoTemplate inside the script that will be cached locally - Downloaded only once or on refresh, so no additional delay. Forking might be bad, though it's done between Wikipedias for internationalisation already.
The ids to identify each service would either have to be defined in GeoTemplate, or given as a hostname and/or url prefix in case there are many services on the same host. The user preferred services could then be matched with those ids through Javascript configured and set cookies, or monobook.js settings. A tiny gadget to enable each would work too, but that'd be flooding the gadgets list. There could perhaps be some gadget combinations of the most popular services though, leaving the rest for monobook.js edits.
On Commons this could be used just to add links, but on Wikipedia it could be a popup. On en:WP:GEO there's been some disagreement on getting rid of the direct map service links in articles, and a user configurable list right there on the article would solve those problems at least for registered users. --Para03:04, 4 December 2007 (UTC)[reply]
I think... I dind't make myself clear. What I want is that, when I click on the text of a link like 68°34′6.2904″N15°5′42.774″E / 68.568414°N 15.095215°E / 68.568414; 15.095215 instead of being taken to geohack.php on the toolserver, I get taken to googlemaps (thus bypassing the need to click on the link at geohack.php). I don't want to modify the global behaviour (for all users), and frankly, I'm useless regarding to javascript, so coding it myself it's almost impossible. If someone could actually give me a hand here I would greatly appreciate it. -- Drini05:09, 4 December 2007 (UTC)[reply]
I actually plan to use this on eswiki, but I believe people here is far more knowledgeable about how the coor templates work and thus more liekly to be able to help. -- Drini05:13, 4 December 2007 (UTC)[reply]
I understood it the first time. :) I would just like something more general that works with more services than just Google. But oh well, I wrote something then, perhaps it will encourage others to continue. Try includePage('User:Para/Google Maps Love.js'); in your Special:Mypage/monobook.js. --Para20:38, 9 December 2007 (UTC)[reply]
Displaying Geotagged images from a single Category[edit]
Hi, I Geotagged a lot of images in Category:Warsaw Uprising and its subcategories is there a way to view a map with overlaid images but only from that category or only of pictures from some time period (1943 to 1945 for example)? and if so than is there a way to provide a link in a category description to that map?--Jarekt19:20, 31 December 2007 (UTC)[reply]
Not yet, due to technical limitations. The queries involved in such a scheme are very costly, or alternatively prefiltering the data takes up way more memory than the limitations on the toolserver would allow me to use. --Dschwen20:27, 9 January 2008 (UTC)[reply]
We now have 31398 geocoded images. That is quite an impressive number. Thanks to all you diligent contributors, and a Happy New Year! --Dschwen20:27, 9 January 2008 (UTC)[reply]
Yes, Geocoding rocks. I am proposing a new concept called Valuable Images, where I propose to make geocoding a requirement for promotion unless there are good reasons not to geocode. -- Slaunger21:38, 9 January 2008 (UTC)[reply]
I've just fixed the coordinates in Image:Niagarafalls.png from {{location dec|43.075,-79.0722|}} to {{location dec|43.075|-79.0722|}} (changing the comma to a pipe).
I put up a tool to list all sorts of mistakes: commons-geocodingerrors. They should be reviewed manually and corrected if it's possible to verify the camera location, or geocoding removed if not. It's likely that the quality of the geocoding isn't very good when the result of the template wasn't verified. --Para13:54, 21 January 2008 (UTC)[reply]
It's likely that the quality of the geocoding isn't very good when... that's a strong assertion; I doubt it has much basis in fact, particularly when a comma is not changed to a pipe during cut & pasting. Andy Mabbett14:56, 21 January 2008 (UTC)[reply]
Would it be a good idea to let the template perform a check on the parameter, and see if it is numeric ? If not, it could issue a warning to the user, and also put all other images that already have erroneous locations in a special category. - Erik Baas14:48, 23 January 2008 (UTC)[reply]
That'd be great yes, and looks like parserfunctions could handle it too. But then we come back to the old question of accuracy; are empty parameters allowed with dms coordinates? --Para16:27, 23 January 2008 (UTC)[reply]
Looks good. The category could be yet another mutually exclusive one with Category:Media with locations and friends, since images with geocoding errors don't have a valid location. Media with erroneous locations? meta:Help:Category#Using templates to populate categories says that the categories added with templates aren't updated until all the members are edited, so we'll have to do null edits on the existing ~160 image pages with errors after the dms template has been modified to do the same check and category structure. --Para18:49, 23 January 2008 (UTC)[reply]
I attended KDE 4.0 release event and talked with Inge Wallin (one of KDE Marble developers) about inclusion of GeoCommons in Marble by default. Probably some tweaks in GeoCommons KML will be necessary. --EugeneZelenko17:04, 21 January 2008 (UTC)[reply]
Sounds like a good match. Any implementation of KML 2.1 should be able to use the feed, but I can make dumps of the database available in different formats or tweak the KML slightly to use a schema for the metadata instead of the description field, if necessary. --Para18:33, 22 January 2008 (UTC)[reply]
I hope that a solution would be also possible for project Wikipedia-world. In spring 2007 I had also contact with a marble-developer (Torsten Rahn), but now we support all (>200) languages of wikipedia. I think thats could be also interesting. The only problem I see is that we need free icons for different types of objects. --Kolossos08:08, 23 January 2008 (UTC)[reply]
I noticed 2 - 3 day ago some nude images in GeoCommons recent changes. I think will be good idea to add possibility to flag such images and filter them out. Panoramio and Flick have such feature. I think it's good idea from point of view to promote GeoCommons as educational content (see #GeoCommons in KDE Marble) or people may explore GeoCommons in public places. And frankly said I don't understand value of geocoding for nudity images. --EugeneZelenko16:13, 25 January 2008 (UTC)[reply]
People have very different ideas on what geocoding could be used for, though most people on this page have the same idea. Geocoding is however the replacement for any location related categorisation, so users could for example use the information to see what people in a certain area of the world typically look like, though the images we have now aren't very representative. Most of us probably don't expect to use the information that way, and what seems to be common with these images and others we have found problematic before is that they and their geocoding has been imported here from an external source, instead of contributed by our own users. Often with external sources the quality of the geocoding isn't up to our standards, and the decision on which images to geocode doesn't match with what our users normally do. When the quality is bad and some identifiable background in the image can't be found from the aerial view of the area or is unlikely to be from there, we might as well remove the information. It would be great to be able to keep our data better than on other sites with similar functionality. I think the idea in your next section will help with the filtering. --Para19:29, 25 January 2008 (UTC)[reply]
I think will be good idea to start separating images on groups like "permanent features" (landscapes, architecture), "nature" (plants and animals) which in general case not really linked to this particular place, "events". This is done currently for maps and not-maps. I think we could use existing categories (of course if image categorized). --EugeneZelenko16:14, 25 January 2008 (UTC)[reply]
The need for this was noticed above with small scale nature images, but without a solution. On various Commons related wish lists there have been hopes of a tag system instead of the categories we currently use. Categories are unfortunately unusable for filtering by category tree branches because of the very quick semantic drift they have. They may be usable through a few levels, but after that the ideas of all the commoners are just a big mix to further filter the current category view, without thought of the next or previous levels. The separation of maps sort of works, because most maps are directly in a category that has the word "maps" in its name, but there aren't many topics as clear as that.
Geocoding on Wikipedia uses a tagging system with the type parameter, which can be used as icons and linked to a scale. What you're suggesting is a tagging system as well, and even though there's no Mediawiki support for it, we could just create a simulated tag system of our own for geocoding only inside the location templates, or for Commons generally, using exceptionally named templates/categories/page links and a Javascript interface to easily manipulate them. The difference with the Wikipedia system is however that Wikipedia has locations of single objects, while our geocoded camera locations are often related to many objects. Also, would people be prepared to maintain two concurrent classifying systems? In Wikipedia it works because of the map scaling side effect, but here the only advantage would be the filtering of geographical image browsing. Is it enough? --Para19:52, 25 January 2008 (UTC)[reply]
I don't think that it's good idea to maintain two separate categorization schemes. I think we could use existing categories. In ideal world categories tree doesn't have isolated parts or cycles and all images are properly categorized. So let's stick with ideal world for awhile :-) In this case we could create map from every single Commons category to GeoCommons sublayer. If we can't find current category mentioned in image (or page where image included) in map, we traverse all parent categories until reach one which is already in the map or fundamental ones (Category:Plantae, Category:Animalia, Category:Cities, Category:National parks, Category:Nudity and so one), so in this case we add entry in map with value of fundamental categories. However I don't know how much resources will be require to rebuild this map at least once a day. And, of course, isolated entries and cycle detection will complicate process. May be similar approach was used in other tools implementation so we could share some code/databases. --EugeneZelenko18:19, 26 January 2008 (UTC)[reply]
Cycles and isolated branches aren't the problem, they're easy to find and fix, but having those fixed doesn't make the categorisation ideal yet. In an ideal world Commons wouldn't have semantic drift in categories, but alas we're so far from it that I doubt it will ever be possible to fix with the existing system. It looks fine when browsing, but automatic traversal or filtering won't work. The fundamental categories are especially useless, as almost all images are in a couple of them even when they shouldn't be. See for example all the paths and categories the badly geocoded but location related half-nude Bad Ass Mystik.jpg is in. You can try with other images too to see just how unusable categories would be for us. There was some discussion on commons-l of the category problem some months ago, and what was suggested is essentially a tagging system. Tagging categories instead of images sounds interesting and would be much easier than tagging images, but that works for major objects only, as many other location related images don't have a category for the object(s) visible in the image, but only for the location. --Para21:07, 26 January 2008 (UTC)[reply]
For the purpose most people on this page geocode their images, it would not be useful to geocode this image. Some people might however like to compare the general look of river water around the world or something like that. It would be really good if someone could come up with a solution to the above categorizing problem, so that the content could be filtered at the time of viewing and not on entry. --Para13:40, 2 February 2008 (UTC)[reply]
I disagree: there is a limit on the number of images that Google Maps can show within a certain area; for every useless picture like this one, some other (probably much nicer and more useful) one will not be shown. Anyway, who cares where this picture is taken ? - Erik Baas21:15, 2 February 2008 (UTC)[reply]
So we should remove possibly useful data because it will make Google Maps less effective? That's not the way forward. The way forward is to find a way of tagging images for downstream users to filter results; perhaps adding categorisation or some sort of prioristing to the geotagging? I also note someone cares enough to include it.--Nilfanion21:51, 2 February 2008 (UTC)[reply]
Who said anything about a map? There is more to geocoding than Google! It is potentially useful to know where a photograph is taken. Removing useful data is a step back, adding effective filtering is the way forward (see above thread).--Nilfanion10:44, 3 February 2008 (UTC)[reply]
One use case could be that you could be interested in geocoded images from Category:Rivers of the United States (and sub-categories) relating to ships, which has been stuck. Since the image is categorized with Category:Potomac River (I just added that cat, a prerequisite for being useful is proper categorization), which is a subcategory, this would show up, if we had that possibility to make these kinds of searchs. I agree completely with Nilfanion on that point. It normally adds value to the image page to geocode it. Although this image may seem utterly useless for you (I do not find it very useful either), there may be other users with other interests who could find the geodata and image interesting. -- Slaunger09:14, 4 February 2008 (UTC)[reply]
Another naive question. Which template do you use to geotag a Category? For instance, I am chasing around an en: article, adding en:coord tags to sundial captions. I have found the images on Commons and using French, English and German found the Scientific park where the image one is located, but Google Satellite is of low resolution in that region of France, so I can't place the camera. Instead, I want to add a 2 dec place coordinate to the images'category. Using google method 1- I get a location tag that is too precise and refers to the Camera location. Its the easy questions that stump me!ClemRutter16:30, 18 February 2008 (UTC)[reply]
We are geocoding here only images. (So far I know.) Categories can geocode in Wikipedia. If the Google Maps resultion is too low then it is difficult or do you have a GPS device? It's such a shame. Perhaps we can use an other mapsource like openstreetmaps, but I believe not [16]. --Kolossos18:51, 18 February 2008 (UTC)[reply]
I am lucky enough to live and photograph in an area with excellect Google resolution. I am talking about retrogeotagging other users images or categories, of images or objects uploaded from nl: fr: de: wikipedia. It would cost me a hell of lot in diesel to go a get a GPS fix on some images. I use the satellite image to position the camera, using clues such as the trees and lampposts and the focal length from the EXIF.
We need the coord to navigate to and from the category, later the location can be read back by bots and the categories plotted in the same way as images. This doesn't occur when you are doing a geographical article but is important when you are trawling for images to represent say Sundials or Piers. So if this doesn't exist- this is what I would like to see. The location template to be recast, so it takes a further parameter if {{{3}}}= cat, then a tag will be generated that can be placed on the Category page, it will have text "Location centred around:{{{1}}}{{{2}}}". Alternatively, if the template could parse the call, and detected that the calling page was a category or a page not an image, than the additional parameter is not needed. As yet- I don't edit templates ClemRutter19:34, 19 February 2008 (UTC)[reply]
It is a good source, and their Gridref to location conversion is accurate to a sub 7 metre level. I anyone can give me the URL of that source code I'll attempt to write a replacement for our tool.
ClemRutter09:41, 29 February 2008 (UTC)[reply]
When the Geograph images come over- woulod it be possible to give them a meaningful name- even a name showing the grid square would be better than the format many seem to have e.g //Image:2074077019 e2771ccc43 o.jpg// which represents 53.46219° N, -1.96725° E, or Grid Square SK0296, or SK 02272 96161 to be more accurate.
ClemRutter18:58, 3 March 2008 (UTC)[reply]
I hope the source code of geohack can help you for transformation. I know the transformation WGS84 to OSGB36 is the false direction, but there are also some weblinks at the beginning of the code. --Kolossos19:13, 3 March 2008 (UTC)[reply]
Done. Well almost. I have put up a beta version of my new tool here, [OSGB grid references to WSG84]. It is quick and simple, and produces two templates at the moment- you just decide which one to cut and paste. There is also a link to [Magnus'Hack] Comments please. ClemRutter 18:01, 25 November 2007 (UTC)
![[5]](https://commons.wikimedia.org/wiki/Image_talk:Tour_eiffel_at_sunrise_from_the_trocadero.jpg){kind=link}
![[9]](https://commons.wikimedia.org/wiki/Image:Tre_01.jpg){kind=link}
![[12]](http://tools.wikimedia.de/~daniel/WikiSense/CheckUsage.php?i=Rachel_Lake_26444.JPG&w=_160&m=&x=&go=Check+Usage&b=0){kind=link}
