Geographical coordinates
GeoGroup is of interest to WikiProject Geographical coordinates, which encourages the use of geographical coordinates in Wikipedia. If you would like to participate, please visit the project page, where you can join the project and see a list of open tasks.Geographical coordinatesWikipedia:WikiProject Geographical coordinatesTemplate:WikiProject Geographical coordinatesGeographical coordinates

Archives

Archive 1 Archive 2

The map created from List of eponymous roads in London has numbers for all but two of the coords rendered on the map. I'm somewhat stumped. Would someone advise where I went wrong. thanks--Tagishsimon (talk) 01:16, 19 September 2008 (UTC)[reply]

At the moment I see three coords on that page with a Name parameter instead of name, and since template parameter names are case sensitive, they don't show up. Another part of what you saw is because Google caches the data it retrieves for some minutes. You must have looked at the Google view before doing the edits, then quickly putting them through and on checking again, got the same cached view as before, with the original two named coords. This is probably a common scenario, though I don't know how long on average it takes people to enter the names and how long Google caches things. Rapid refreshing may possibly even extend their cache period. Perhaps a timestamp should be added to the top of the list (the only place possible), or would the use of UTC confuse people who have localised the times Wikipedia shows? --Para (talk) 09:25, 19 September 2008 (UTC)[reply]

Thanks. I've amended the three Names. Not sure if that was it or if it was a cache problem (my actions were as you surmised - look, edit, look, &c.), as you suggest, but today it all works. Excellent. --Tagishsimon (talk) 09:44, 19 September 2008 (UTC)[reply]

What I may suggest is you add the following string to your Google Maps query: "&refresh=" followed by a random number. This will bypass Google's cache. --  Denelson83  17:36, 6 January 2009 (UTC)[reply]

A couple of months ago, I saw the kml template added to Nanboku Line (Sendai). After reading about the template today (I guess I'm a slow reader?), I noticed it could be used on categories. So, after I added it to Category:Sendai City Subway Line an annoying problem surfaced: since the coords are included in a table in the main article, and again in each individual station article, the map reference comes up with two sets of coords for each station. So, is there a better way to use the template that prevents this? Or, would it be possible to add some sort of markup like {{kml-category-off}} for articles like Nanboku Line (Sendai) so that when the category is parsed, those coords are skipped? Or, another approach might be a parameter inside the template on the category page which lists pages that are to be ignored when scanning the cat? Thanks! Neier (talk) 12:17, 29 December 2008 (UTC)[reply]

I've changed that to use {{GeoGroupTemplate|article=Nanboku Line (Sendai)}}. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:29, 29 December 2008 (UTC)[reply]

Hmmm. I guess that will work for now; but, things would get messy once there is more than one "index" articles in each category. And, it sorta defeats the whole purpose of having the category be recursively monitored if only a single article is relied on. Neier (talk) 09:14, 30 December 2008 (UTC)[reply]

You are actually pointing to a much deeper issue here: Do we want redundant geocoding with data from individual articles being duplicated in list articles? This has been giving me a headache for a while now. Glad you brought it up. --Dschwen 21:15, 8 January 2009 (UTC)[reply]

Yes, that's why I was hoping there was an "ignore" parameter as it would avert a long discussion. :-)

I can see points for and against. For lists with many missing articles, it is nice. For lists which are contained in a category, it is redundant and harder to maintain; and, if I was writing a bot to parse the codes, having multiple (and, likely different) coordinates for the same place would cause many headaches. I guess I'm mostly on the side that they aren't needed in lists; but, I'm not real involved with the geo tag projects, so, take that advice with a large grain of salt. Neier (talk) 13:17, 11 January 2009 (UTC)[reply]

The Map of All Coordinates link this template produces at the bottom of the table in the Vancouver Island Ranges article works nicely except that it produces one spurious location for Golden Hinde (mountain) off in China somewhere rather than on Vancouver Island. I have hunted through the code and can't figure out why. Could someone have a look? It is probably one of those things another set of eyes will pick out right away. --KenWalker | Talk 21:21, 16 February 2009 (UTC)[reply]

Seems fine now. Oosoom ^Talk 09:45, 17 February 2009 (UTC)[reply]

I'm using the French version of this Template. When an article has its coordonates all in one table, the template works fine. However, when there is two or more tables with coordonates, Google gives "errors in data" fomr kmltool. Any idea of the cause and how to make the call to kmltool work on multiple table articles ? Pierre cb (talk) 20:07, 22 February 2009 (UTC)[reply]

It's actually not about multiple tables. With fr:Liste de tripoints Google Maps was having trouble with the é in the Amérique heading. It was sent as U+00E9 and Google refused to parse the data, but when sent as U+C3A9, it works. According to UTF-8#Description, only the 7-bit ASCII printable characters are allowed when content-type is said to be UTF8, and everything else needs to be in the longer format. Google is not enforcing that very well though, as they require ASCII encoding for document titles even when the entire document is supposed to be in UTF8. Oh well, the output should be to their liking now. --Para (talk) 21:49, 22 February 2009 (UTC)[reply]

Thanks for the info but how do you force the ASCII table in an article ? 70.52.11.52 (talk) 00:23, 23 February 2009 (UTC)[reply]

Well, Wikipedia transfers all its content in UTF8, so as long as the text in an article looks fine in your browser, you don't need to worry about encoding. The kmlexport tool however needs to do some conversion to provide the data to Google and things can go wrong sometimes, so please report any further problems here. --Para (talk) 01:03, 23 February 2009 (UTC)[reply]

If quite frustating in fact. klmexport works on some article and other are refused (like fr:Liste des volcans d'Afrique) for no apparent reason in the coding. Only the multiple tables seemed the common denominator but you ahve proved that iti is not. Is there a utility program to check the ASCII interpretation problem that diagnose and correct the files sent to Google ? Pierre cb (talk) 01:24, 23 February 2009 (UTC)[reply]

Ah, that's again another issue the people editing this template had some trouble with in the beginning, and in that case you do have to delve into encoding, though this time not in ASCII but nested urlencoding. On the French Wikipedia the article parameter in the link is currently article%3DListe%2Bdes%2Bvolcans%2Bd%2526%252339%253BAfrique. If you go to the English Wikipedia page of the same name and preview {{GeoGroupTemplate}} there, the parameter is article%3DListe_des_volcans_d%252527Afrique. It was indeed incredibly frustrating to get it right, and the only advice I can give you is to duplicate the encoding from this template. Maybe allowing Google to show "file not found" is not the best error message to relay Wikipedia's 404 Not Found message though... --Para (talk) 01:54, 23 February 2009 (UTC)[reply]

If {{Coord}} is used with "|display=inline,title" to delineate the primary article coordinate (e.g. The Lone Sailor), then kmlexport produces two copies of the coordinate. I'm aware there is some debate about Coord displaying two places, however I don't think anyone would debate kmlexport only including it once. I suppose if kmlexport is just scraping the geo microformats, then it is really Coord that needs fixing to emit only one. However I'll start asking here. --J Clear (talk) 00:17, 23 February 2009 (UTC)[reply]

So much information in duplicated in Wikipedia articles, for summary style, ease of access, consistency, etc. In most cases it probably doesn't matter to a normal reader if an article has duplicate coordinates. I however can't think of a situation where the duplicates would be interesting in an exported list of coordinates, except maybe when the duplicates are in different sections, grouped differently or something. I modified the tool to remove duplicates within sections. So far that's only exact duplicates, and there are probably articles which give the same coordinates in different formats that the tool won't prune. I don't know if it's possible to detect that from cases where an article mentions things very very close to each other. --Para (talk) 01:09, 23 February 2009 (UTC)[reply]

It looks like you covered the case I was concerned with, thanks. Although if my surmise is right, you're covering for a bug elsewhere. And yeah, I just edited Marietta, Ohio to prune three different Coord entries for the town down to the infobox one. --J Clear (talk) 04:06, 26 February 2009 (UTC)[reply]

Good good, WP:USCITY#Geography has already been updated to no longer encourage all that redundancy typical to US articles. The effects of the previous guideline will probably continue to be visible for quite a while, for example in one of the categories that article is in, United States colonial and territorial capitals.

Removing the duplicate markup from the Coord template might be difficult without redesigning the template structure, as the bit just does a double transclusion of the where the additional spans and classes are added. But that's not a problem here as the kmlexport tool doesn't parse microformats. --Para (talk) 14:10, 26 February 2009 (UTC)[reply]

I've seen there is a section above about getting no data with the option GeoRSS. Is there any correction to that problem in the future as I get this response too ?Pierre cb (talk) 22:28, 23 February 2009 (UTC)[reply]

The format doesn't seem to have had much interest, but reading up on it, it would allow showing Wikipedia data in Microsoft Live Maps and Yahoo Maps. To replace the broken Suda tool, Microsoft has an online KML to GeoRSS converter, which can give GeoRSS of fr:Liste de tripoints, or even a Live Search Maps view of fr:Liste de tripoints. This might be worth adding to the various templates, as aerial imagery from Live Maps is often better than that from Google. --Para (talk) 01:07, 24 February 2009 (UTC)[reply]

Thanks. I think I will add the second one. Pierre cb (talk) 04:23, 24 February 2009 (UTC)[reply]

Me too, the bird's eye imagery in urban areas and easy navigation between the points is possibly the coolest option ever! (No I don't work for them :)) --Para (talk) 11:09, 24 February 2009 (UTC)[reply]

I notice that the kmlexport script already handles nested categories, is there a way to add the nesting level to this template, so that Category:Castles in England could show all the positions of the castles in its county subcategories. Discretion would be needed to avoid huge data volumes. Vicarage (talk) 06:29, 7 May 2009 (UTC)[reply]