A conversation with ClemRutter yesterday prompts me to ask whether we might give consideration to listing other forms of coordinates on an article page.
We traditionally tag using latitude & longitude. In the UK, most of us have OS maps which have their own grid coordinate system. Geohack gives us OS coords, should we want them. But I guess I have in mind the sort of person who might want to print out an article and then refer to it against an OS map when in the vicinity of the article subject ... said person would be better served by having the OS grid reference printed on the page than the lat & long.
And so I'm wondering if there is any support for {{coord}}, or else a bot working from {{coord}} (for I understand the conversion process is a bit maths heavy), adding OS coords for UK articles to the foot of the article? And the same principle for Ireland and other states that have their own grid systems. --Tagishsimon(talk)23:03, 27 November 2008 (UTC)
The point I sought to make was that divorcing the other coordinates from the article by placing them on a separate page frustrates the person who wants to print the article and who (by inference) does not want to print the Geohack page too. I'm saying explicitly that it makes more sense to provide the other coords on the article page. I grant that online users are just a click away from the information (if they have knowledge of what's available by clicking on the rendered latitude & longitude). But the offline user has no access to this facility, and so for these users we are hiding a useful piece of information. That's never a good thing for an encyclopedia to do. --Tagishsimon(talk)01:49, 28 November 2008 (UTC)
It's tractable by bot, for sure. I somewhat doubt that the template can do it. So we have a game of two halves: do we want to do it, and if so, how shall we arrange to do it. --Tagishsimon(talk)02:43, 28 November 2008 (UTC)
Might be an idea to see if the map references can be converted on the Geohack page first (are they already?) and then maybe a switch can be added to {{coord}} template to display those references too (either inline, title or both) so it would be up to individual editors or projects to apply the switches where required. What do you think? Might be the most democratic way of advancing. --smadge1 (talk) 03:14, 28 November 2008 (UTC)
They are already available on the geohack page. I appreciate the intent of the coord switch, I'm not sure that I support it, am undecided, but lean towards disagreeing, since I cannot conceive of the reason why we - any editor - might wish to omit giving information which on the face of it appears to have value. --Tagishsimon(talk)03:33, 28 November 2008 (UTC)
I think we've gone as far as we reasonably can with bots and templates alone in this area; having multiple forms of the same data marked up in different notations, and administered in an uncoordinated way by a variety of different means, is a recipe for confusion. The necessary computations are way beyond anything that could be done using templates. We need to get proper geodata support merged into the MediaWiki software, so coordinate transformations can be done directly by the software at page-rendering time using something like <geo> markup, which can then be invoked from within our standard set of templates. -- The Anome (talk) 03:35, 28 November 2008 (UTC)
My first thought was to use counties. However, on further inspection, I've found a baffling selection of apparently suitable entities; traditional counties, principal areas, administrative areas, unitary authorities, ceremonial counties, postal counties, preserved counties, districts, Government Office regions, Lieutenancy areas (!!), the list goes on and on; and there seem to be different structures used in England, Scotland, Wales and Northern Ireland. As Subdivisions of the United Kingdom says, "The subdivisions of the United Kingdom are complex, multi-layered and non-uniform. As a result of a lack of a formal British constitution, and owing to a convoluted history of the formation of the United Kingdom, a variety of terms exist which are used to refer to them." List of counties of the United Kingdom isn't particularly helpful; it just highlights the range of possible choices.
Can anyone suggest a rationally-chosen set of non-overlapping areas that completely covers the entire UK, and is most likely to align with WikiProjects and existing Wikipedia categories, and not cause flamewars? -- The Anome (talk) 03:30, 28 November 2008 (UTC)
I've had a quick look, and quickly enough run into sand.
Sorry I don't have more time to put into this, but I should probably get some sleep right around now. I think matching against existing subcategories is going to be your biggest issue; also think the first two suggestions are bankable enough to get you to a good start. --Tagishsimon(talk)03:58, 28 November 2008 (UTC)
After thinking about it some more, I've decided to use the names of the county-level geostub subcategories defined under Category:United Kingdom geography stubs. This at least has the advantage that these have been evolved by community consensus, and should hopefully align well with WikiProjects. -- The Anome (talk) 19:43, 28 November 2008 (UTC)
Update: even that's got its own problems; for example, it contains both Gloucestershire and South Gloucestershire, one of which is inside the other, and has to be special-cased in the code. -- The Anome (talk) 13:10, 30 November 2008 (UTC)
Progess report: There are now about 800 articles left in Category:United Kingdom articles missing geocoordinate data, from around 10,000 before. Of those remaining 800, about half can be bot-matched to more than one (typically two) of the subcategories, and the rest can't (at the moment) be matched to any of the subcategories by my relatively simple-minded pattern matching / graph traversal techniques. -- The Anome (talk) 02:13, 1 December 2008 (UTC)
Any objections to removing the link from, for example, Northumberland to the UK, so that we go from UK to England, Northern Ireland, Scotland & Wales, and beneath them, the counties? And thanks for subcategorising these, The Anome. I'll do some outreach. Probably. --18:34, 2 December 2008 (UTC)
I think we here in the geographical coordintates project aren't dealing with categorization, but there are other projects where I've seen regional categorization statements. Look for projects dealing with the regions which you're dealing with. -- SEWilco (talk) 17:14, 5 December 2008 (UTC)
Coordinates within articles
Following on from previous discussions, and looking at the 'blue globe' I find Grade I listed buildings in Cheshire marked thereon in multiple places. There are many items with coordinates on this list, nicely tabulated, but each has its own article (with coordinates) anyway, so it seems to me that one needs some way of indicating that the coordinates for say St Mary's Church, Acton should be taken from its article and not from anywhere else where its coordinates might be given (using name= , or using the hcard method of naming rows in tables favoured by Andy Mabbett). Also Navenby was placed in Lincolnshire (correctly) by 2 methods in the info box and also in Cheshire by inline coord in the article. Occuli (talk) 12:53, 3 December 2008 (UTC)
Yeah, that sucks, like data duplication always sucks. If the coordinates are exactly the same, you won't notice it on the WMA (sorry, blue globe), but if the coords differ... ...well, then there is something obviously wrong. This should never happen. --Dschwen13:32, 3 December 2008 (UTC)
I'm not sure I understand you guys correctly. I know that the Google Earth Wikipedia layer only uses the coords that have the display=title parameter (this was done for this reason).
To be honest, if you have a nice table of places with coordinates, the name= parameter should not be optional. I recently went through the "List of ships attacked by Somali pirates" article, adding information to the name= parameter, so they displayed properly in a "View All Coordinates" map view. I haven't really used any map software other than Google Maps/Earth, so my experience isn't that broad. --smadge1 (talk) 20:52, 3 December 2008 (UTC)
And after looking through the archives of this page the only previous discussion I find is you saying "As I've pointed out more than once before, naming coordinates [..] is harmful". Great. You didn't complain about the name parameter when we extensively discussed the merits of coord versus the old coor templates and the coordinate template. --Dschwen23:22, 3 December 2008 (UTC)
You didn't refer to anything with substance, that is the problem. You are just making vague claims here, quite similar to the concept of FUD. --Dschwen00:42, 4 December 2008 (UTC)
I do remember that. And I particularily remember not getting an explanation why it would break anything. Just what I mentioned above: a semantically ill-defined microformat. This is a minor issue which is the reason of an extra functionality that was piggybacked on the name= parameter. Instead of advising against the use of this parameter it should rather be fixed. If there is no reliable way of automatically generating a microformat, it should not be generated. --Dschwen19:42, 4 December 2008 (UTC)
Then you remember wrongly. Leaving aside the other red herrings in your post, the reason why the name= parameter was added to {{coord}} was to facilitate another editor's "show all coordinates" service, in (his) preference to the microformat-parsing services I introduced in {{kml}}. At the same time, a number of existing microformat implementations were also broken. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits00:02, 5 December 2008 (UTC)
Okay, can we do a reset here and restate from first principles what are the issues with the name= parameter, please, in the section below. --Tagishsimon(talk)19:34, 4 December 2008 (UTC)
Issues with the name= parameter
See above: If there is no reliable way of automatically generating a microformat, it should not be generated. This has nothing to do with the name= parameter per se. --Dschwen19:43, 4 December 2008 (UTC)
I realise that you're not doing so; but it seems that some editors prefer to repeatedly ask for the issues to be restated, rather than to address them. The issues are clearly and concisely laid out (but, sadly, not addressed) at Wikipedia talk:Coord#Removal of hCard microformat. Most, of not all, of them could be remedied by removing the hCard mark up from {{coord}} (which is a compromise proposal, rather than my preferred solution of removing the name= parameter entirely); since {{coord}} was never intended to emit an hCard microformat, only a geo microformat. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits23:56, 4 December 2008 (UTC)
I don't know where he is pointing with "See above"; none of the previous three sections were begun by Dschwen, so I have to ignore "See above" and use the rest of his paragraph. -- SEWilco (talk) 17:04, 5 December 2008 (UTC)
The see above refers to this [1] comment, which I merely repeated in abbreviated form here. An the above in that comment refers to [2]. --Dschwen17:10, 5 December 2008 (UTC)
Ok, say I wanted to list a bunch of coordinates on a page, such as here, and be able to view them on a map (such as Google Maps, for simplicity) with their appropriate names. Is there a way to do this without using the name= parameter? Bearing in mind, I'm not a coder of any sort, and have a basic understanding of wiki tags. I like to catergorise every coordinate I enter, I feel it gives each link an identity, and could be useful for future searches, etc. I will probably do a read up on the whole affair when I get time, but what advice can you give me today re this? --smadge1 (talk) 00:58, 5 December 2008 (UTC)
Well, we can still put the name in the link to the geohack page, and still have the MiniAtlas scrape the coordinates for those templates from the article source, even if we don't try to put the name in the microformat. -- The Anome (talk) 01:04, 5 December 2008 (UTC)
Exactly. It is not the name= parameter that is fundamentally broken. Let's remove the microformat and everybody will be happy. --Dschwen04:30, 5 December 2008 (UTC)
What about the users who use the name in their microformat readers, or those who prefer to map coordinates and their names with a microformat based tool, such as the last two in {{GeoGroupTemplate}}? --Para (talk) 11:00, 5 December 2008 (UTC)
The abuse of the electronic business card format on contact lists is widespread enough already for any efficient damage control to keep them for people only. In fact, the community pushing them in html intends for them to be used with all sorts of items unrelated to people. See Category:Templates generating hCards for examples. --Para (talk) 15:13, 5 December 2008 (UTC)
PS maybe it would be better to add a lable-class to the geo-microformat because name is confusing when geo is used inside vcard. But this is to address to the microformat board. Visi-on (talk) 13:12, 5 December 2008 (UTC)
The geo microformat has no name property; nor label, nor any need for one. If a label or name is desired, the hCard microformat should be used; but not as currently implemented in {{coord}}Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits14:13, 5 December 2008 (UTC)
First part: this is true
Second part: I wonder how you manage to tell (by correct use you can't) the browser-add-ons this vcard is not a contact and only present just for labeling a landmark. I will refuse to use vcard incorrectly! Visi-on (talk) 15:20, 5 December 2008 (UTC)
To return to Smadge's specific question, in his list at User:Smadge1/Coord (which uses name=), when I view it in Firefox with the viewer gadget (Operator) I see 32 nicely named items under the geo-tag (good) but the same 32 (nicely named) under the hcard-tag. Now in Andy's preferred solution, what is the 'parent template or element' of say the first one? Occuli (talk) 13:14, 5 December 2008 (UTC)
Wikitext should be kept as easy as possible to edit, without obfuscation by meta-elements for minor goals. Attempts to use templates created for microformat purposes only or inline markup in articles directly have failed. If the markup can be shoved inside existing templates where most editors will never have to see it, such as currently in coord or infoboxes, fine, but if the additional nice-to-have microformat elements require complicated constructs in articles, we can live without them. --Para (talk) 15:13, 5 December 2008 (UTC)
The name= parameter is a "meta-element for a minor goal". For "failed" you mean you removed them: you then replaced them with the broken implementation under discussion (and which you failed to adequately defend in the above referenced. discussion). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits17:21, 5 December 2008 (UTC)
And yet the associated microformat is just a sub-meta-element for a minor sub-goal. Don't put the ox in front of the cart. Name provides a means to assign individual names to coordinates, the microformat merely provides one way of making these names visible (albeit a slightl broken one, granted, but that does not make the idea of name broken). --Dschwen17:57, 5 December 2008 (UTC)
Andy you tell us that nothing is simpler then this. So please just show us a html-excerpt of correct named (noncontact) geo-microformat usage. I'm glad to see it.Visi-on (talk) 15:31, 5 December 2008 (UTC)
this page is well none but gives no example for naming a landmark not missinterpreted as contact information. It may be practice to handle a place as a contact, but this is not correct. I can only have a contact at a place but not with a place. Visi-on (talk) 17:31, 5 December 2008 (UTC)
look at this two persons to see that the vcard aproach for naming places does not work:
Andreas Platz, Alexander Platz, Berlin, Germany (52.5225977° N, 13.4148965° E)
Alexander Platz, Andreas Platz, Berlin, Germany (52.5140949° N, 13.4316199° E)
Ok, excuse me for being a bit thick here, but is this fixable in {{coord}}, yes or no? Can we use an autogenerated hCard from the name parameter? And if yes, why not? ;-) --Dschwen20:34, 5 December 2008 (UTC)
The fix is to remove the hCard mark-up from {{coord}} and thus allow it to be used as designed to generate a Geo microformat, and to be used as a component in other, hCard-generating, templates. A better fix would also remove the CSS-hidden output of the name parameter, since this does not "degrade gracefully". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits20:49, 5 December 2008 (UTC)
My understanding of parameter name is: It should only be used when the georeferenced object does not correspond with the article (title). But anyway: Template coord is *not* primarily designed to emit a microformat but to georeference an article or an object declaratively! So, please, Andy Mabbett alias Pigsonthewing: Acknowledge what Para said and propose either a way on how to emit a geo-microformat as an additional benefit to coord or we have to live without such a microformat in Wikipedia's coord template(s). I do like microformats but not by sacrificing state-of-the-art IT technology (i.e. keep it simple, avoid inline markup, don't use obscure/unparseable parent templates, beware piggybacking on parameters). --Geonick (talk) 23:14, 6 December 2008 (UTC)
As the person who originally came up with the idea of {{coord}}, and who designed it, I can assure you that it is primarily designed to emit a geo microformat. I have acknowledged what Para said; and pointed out that he was wrong. {{coord}} currently emits two microformats: a geo and an hCard; the latter is bogus, unnecessary and harmful, as described above and on linked pages, and I have made the case for its removal. No-one, that I ave seen, is proposing to remove the former. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits23:50, 6 December 2008 (UTC)
sorry Dschwen, but this makes realy no sence, forget it. Nobody likes a place in his contacts. We will solve it otherwise without microformat. Visi-on (talk) 21:00, 5 December 2008 (UTC)
when i see it right you are this community. what sense will it make to diskuss it a second time, when you don't like to see the problem. vcards for contacts is all right but not for places! geo-microformats are unnamed. For me her is EOD. — Preceding unsigned comment added by Visi-on (talk • contribs)
Question about precision
I was looking at Emery Theatre and the coords threw me off a bit. They seem to just go on a bit longer than I've normally seen. It seats 1600 people. What's the cutoff point for decimals for a building of this size? Thanks for your help. §hep • ¡Talk to me!01:36, 9 December 2008 (UTC)
As you might be able to deduce from WP:GEO#Precision, that's sufficient precision approximately for the location of subatomic particles. I would expect that 100 m or 10 m precision would be appropriate, which corresponds to about 0.001 or 0.0001 degrees respectively. —EncMstr (talk) 01:40, 9 December 2008 (UTC)
One solution is instead of using lat_degrees, lat_minutes, lat_seconds, lat_direction, long_degrees, long_minutes, long_seconds, and long_direction—use coords={{coord|…}} instead. —EncMstr (talk) 20:46, 23 December 2008 (UTC)
Deprecated template used on 'Cities of the Ancient Near East'
In which case {{coord}} would only be "not working" if it was designed to do either thing: it wasn't. The addition of a name parameter is sub-optimal, as I've described previously. that said, the simple fix is to rep-lace square brackets with the more correct (parentheses). As to displaying "N" and "E" instead of ve or -ve integers, that's a stylistic choice, not a bug. The fact remains, that {{coor d}} is deprecated by common consent and is not to be used; and {{Coord}}, including its display options, have been adopted, again by consent. If one or two editors wish to suggest changes to the war the template works, then there are ways for them to do that; edit warring to impose a template deprecated by the community is not one of them. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits21:28, 23 December 2008 (UTC)
Update: And I have again been reverted, with the deprecated template restored, under an edit summary of "deprecated does not mean wrong. and the template DOES NOT work, so stop changing the article. see talk page.". This is surely disruptive editing? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits13:26, 24 December 2008 (UTC)
Stop acting as if this were your private article. You are not improving the article by forcing a template that simply does not work properly as I have told you a number of times. I have referred you to Wikipedia_talk:GEO#Glitch_in_coord_template but you choose to ignore that. THAT is disruptive editing, especially since you never contributed anything to the article's content. I will not put further effort into finding out accurate coordinates of ancient sites if someone with your attitude keeps ruining the article by insisting on something as ridiculous as replacing a WORKING template with a BROKEN one.
It is you, not I, who needs to pay attention to WP:OWN. As has been pointed out to you repeatedly, you are restoring a template which has been deprecated by community consensus. You have yet to establish that {{Coord}} "does not work properly", as opposed to using a display format which is not to you personal taste. And please don't expect anyone to be impressed by your dramatic threats to stop working on an aspect of Wikipedia. You might also like to consider the possibility that the fact that no-one has replied to the supposed "bug" report means that no-one else thinks that the minor formatting preference raised is insignificant. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits
Just because you have no interest in the article in question and you obviously have no sense of aesthetics does not render my wish for its pleasant and legible appearance insignificant. You have reduced the coordinates to just numbers with no proper notation. I really do not see the advantage of using the new template over the old one. The produced link is not any better and its look is considerably worse. And stop pretending that the template's inability to produce N/S and E/W is not a fat BUG, because it clearly is, otherwise the template would not produce these letters at all. I am a software developer, I know a BUG when I see one. Cush (talk) 18:43, 24 December 2008 (UTC)
Hm, this is the third time that the Coordinate Mafia has broken Cities of the ancient Near East in the last couple months. Is there something in the basic structure of the article that is not proper syntax? Btw, this is not an isolated problem. I checked the contrib list of Pigsonthewing and looked at an article at random, Emerson Cavitation Tunnel. It was also broken by the changes. Ploversegg (talk) 01:14, 24 December 2008 (UTC)ploversegg
i.e. the actual wikilink term was munged so that it no longer points to the right place and
is Red instead of Blue. This would appear to be an unintended side affect.
Ploversegg (talk) 17:37, 24 December 2008 (UTC)ploversegg
Someone used an editor which was not unicode aware to perform the replacements. This has nothing to do with coord/coor d. --Dschwen18:39, 24 December 2008 (UTC)
Agreed. Thanks for fixing it. One assumes the editor involved will go back and fix whatever
other articles were similarly mangled.
Ploversegg (talk) 00:56, 25 December 2008 (UTC)ploversegg
"title" is being overloaded
As I understand it, the title tag is being used for two completely unrelated purposes: the original purpose was to have the parser place a copy of the coords near the top of the article (which people refer to as "title area", although it isn't) as a display hint. More recently, this tag has been re-used to identify the coords to Google Maps.
This is very bad. Reusing this tag for these two completely different purposes means that we need to place title tags on coords that we don't want in the title, like this example where the coords push the infobox down, and they really want to be in the infobox only. This sort of overloading of metadata is extremely bad programming form, and needs to be fixed.
Is there any reason why we can't have a tag, say main or something similar, that tells the geoscrapers that this is the primary coord set? It's much more specific than title, obviously, and properly separates display from instruction. Who do I need to talk to to get this fixed?
We do not need a main tag. main should be the default. If a coordinate is not the main coordinate of the article, it should have a name parameter supplied. --Dschwen23:03, 23 December 2008 (UTC)
Yeah, but in any case the users have to be aware of the functionality. If people had no idea about the main thingie suddenly no coordinates would show up in google ;-). I'd prefer to raise awareness about the name parameter, as you get two benefits with it (the other benefit would be describing coordinates - which are not to be directly identified with the lemma - with a machine readable meaningful description). --Dschwen23:39, 23 December 2008 (UTC)
Can someone explain how the name tag would be used in this context? I'm a little worried that if we require the user to put the name tag on everything but one of the coords that we'll end up with more problems than we have now. I'd like whatever solution we move forward with be as simple and foolproof as possible. For instance, "name=main" requires exactly the same amount of work as using "title", and only has to be placed in a single coord tag. Maury Markowitz (talk) 14:06, 24 December 2008 (UTC)
Only a fraction of articles contains more than one coordinate. Name is already being used in lots of articles and by at least one geodata scraper (me). If minimization of work were our only goal we could just stop working on Wikipedia entirely ;-). Name is set to a meaningful description of the coordinate or all non-main coordinates. --Dschwen15:34, 24 December 2008 (UTC)
Do you understand my concern here though? I want to make sure that scrappers, including your own, will have reasonable default behavior in the case that the user screws up -- which will be close to 100% of the time. If we rely on name tags on the coords that are not the "default", then it is VERY easy for this to break -- all that has to happen is that the editor doesn't know about it, which I didn't until just now for instance. I'm not opposed to using name to ADD information to the system, far from it, but I just want to ensure that everything works by default. Maury Markowitz (talk) 16:42, 26 December 2008 (UTC)
The database contained 18368 entries, of which, after removing article names that the bot had already logged as geocoded from previous runs, the bot judged around 6000 to be worth inspecting.
The file was UTF-8 encoded. 17628 of the entries had all-ASCII names. 723 had correctly UTF-8 encoded non-ASCII characters in their names. 17 entries had their names stored as undecodable byte sequences, which make sense neither as UTF-8 nor as mojibake.
During a truncated test run, 4022 of these 6000-or-so articles were visited by the bot (an estimated 200-or-so more were visited but didn't exist, but their names weren't logged at the time), of which:
1164 articles were judged to be eligible for editing by the bot (most of the rejections were because the article had already been tagged by someone else), of which:
402 had previously been marked with {{coord missing}}, and all seemed to be suitable for geocoding
714 had not previously been marked with {{coord missing}}, of which:
653 seemed to be suitable for geocoding
61 were, after manual inspection of the list of edits and manual inspection of articles with potentially unlocatable-sounding names, found to be about topics which should not have been geocoded, and had to be de-tagged by hand
Out of those 61, here are some examples of wrongly-tagged articles.
Some less silly examples: Hermia, Grain elevator, Cyclotron, Cenacle, Corniche, Fountain square, Hypocenter. Many of these are cases of insufficient disambiguation or insufficient specificity: for ezample, they may refer to the science park in Finland instead of the mythological figure, or a particular fountain square, grain elevator or hypocenter.
61 out of 1164 is an error rate of about 5%, which is uncomfortably high: I generally consider that bot-generated edits need to be at least 99% accurate in order to make sure that bot operation raises, rather than lowers, overall average data quality, and reduces, rather than increases, the requirement for human labour.
I haven't yet done any systematic review of coordinate quality, so I don't know how accurate the actual locations are. A very quick random check of 11 of the marked articles that were about validly geocodable topics all seemed to have reasonable coordinates; however, this is not a large enough sample to gain any real idea of the error rate.
Thanks. I've now finished the entire run: overall, there was a net gain of about 1700 newly-tagged articles, of which about 600 had previously been tagged with {{coord missing}}. -- The Anome (talk) 06:35, 27 December 2008 (UTC)
Update: the changes have detected another 23000 articles to be marked with {{coord missing}}. A short test run of a random sample from the data showed no errors, which gives me reasonable confidence that the overall dataset has a fairly low error rate. The run is now in the my to-do queue. -- The Anome (talk) 10:15, 6 January 2009 (UTC)
On which question, do we have a place to store false positive article names which come up as we (you) parse categories of articles which /ought/ to be geo-codable? Or do we need a new template to indicate that an article should not be listed as {{coord missing}} despite being n a likely category? --Tagishsimon(talk)01:26, 6 January 2009 (UTC)
At the moment, I just record all bot edit attempts, and do not repeat any previously made, so just reverting them will be fine. If you see any patterns in the mistakes, just tell me, and I'll go back and fix the lot, if possible. -- The Anome (talk) 09:43, 6 January 2009 (UTC)
Request for bot operators
Are there any other participants here who have programming skills, and want to become bot operators? There are a huge number of geodata-related maintenance tasks that need doing: any volunteers would be more than welcome. -- The Anome (talk) 09:22, 27 December 2008 (UTC)
twice in the geography section (wikified in degree/minutes/seconds and in decimal degrees). This includes a broken "city" (instead of "type:city").
once in the external links section through {{Mapit-US-cityscale}}, displayed there and in the article upper right corner. This includes "type:city_region:US"
While we probably all agree that that this should probably be limited to one or two place, the question is how.
Possibly solutions:
1. Use only the coordinates in the infobox, remove all others.
2. Convert mapit to coord with "display=title".
3. Remove mapit and add title display to the infobox or the coordinates in the geography section.
Changes to be made anyway:
If the coordinates in the geography section are kept, "city" needs to be changed to "type:city". The two formats of the coordinates (dms and decimal degrees) some somewhat redundant to me.
I think you meant "...have the coordinates specified..." not "...have the articles specified..." and have adjusted your post accordingly. My preference is "1"; with the display set to title also, if preferred. BTW,. please use "#" for ordered (numbered) lists, instead of "*1", "*2", etc. Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits13:21, 20 September 2008 (UTC)
Thanks for fix my comment. BTW it's a deliberate choice to use "*1" instead of "#": it avoids that the numbering fails if the formatting breaks. -- User:Docu
On attempting to clean up some mess, I;ve met with the opposition of a user who believes it is custom & practice to triplicate the coordinates on US town articles. I have invited said person here to set forth his/her argument for what seems to me an exercise in futility. --Tagishsimon(talk)04:46, 6 November 2008 (UTC)
Observing that 48 US states (Michigan and Minnesota, for some reason, excepted) have had these links included on all their municipality (except minor civil divisions, such as townships) and CDP articles, I daresay it is obvious that it is custom & practice to include such links in all places. Copying from my note on Tagishsimon's talk page:
We have several reasons to include the coords in multiple places: to avoid including the location of a city in its geography section is absurd; to avoid including such basic information as simple coords in the infobox deprives the infobox of important core information; and as the Mapit and Geolinks (and any other similar ones, if there are such) provide external links, it's logical to have them in the ELs as well.
To this I should add: the Cities wikiproject is also involved, and its standard city article layout has long called for the inclusion of such coords, making its decisions as relevant as this project's on this type of article. I acknowledge that, of the two locations that were removed by Andrew Kelly's suspended activity, the ELs are less important (the Mapit and the Geolinks were hidden for some months, some time ago, as you probably remember); but why would there be a reason to make the Geography section less specific on location? Infoboxes are meant to summarize information already in the article elsewhere, not to replace it; otherwise, we'd best remove the words "a city" and the 2000 census population from the first sentences of the first and second paragraphs of Cleveland, Ohio. Nyttend (talk) 15:01, 6 November 2008 (UTC)
And for the sake of convenience, you can refer to my arguments as "his" — I'm an Eagle Scout, as you can see from my user page, so I'm plainly male :-) Nyttend (talk) 15:02, 6 November 2008 (UTC)
Coords in the external links: madness. All coords are clickable. All readers know that coords are clickable 'cos they're in a light blue font. I simply do not buy the need: this is a hang-over from a first approach to coords from when? 2003? 2004? We can do better. Coords in the external links are absent from all of the featured article cities linked to from Wikipedia:WikiProject Cities/Guideline#References / Notes, (i.e. Minneapolis, Tumbler Ridge, British Columbia and Bangalore) implying that anyone who has given great thought to the content of city articles has reached the same conclusion - that they're redundant.
Coords in the geography section: they look ugly. They're a piece of tabular data. From a stylistic point of view, they ugly. From a standards point of view, they deviate from the established standard of coordinate in infobox or title bar. They're repetitious. On small articles with thee coords, they're simply nonsense. As far as the small sample of featured articles is concerned, 2 out of the 3 have happily dispensed with them.
I will agree that the "external links" coordinate is somewhat superfluous, but the fact that these locations are ubiquitous across so many articles leads to a certain level of expectation that one is going to find them in a given place. I can see some benefit to deprecating the inclusion in the links section, but the rest of them don't seem to be doing any harm .. Shereth17:57, 6 November 2008 (UTC)
Coords need to be in the title, because that makes them visible to Google Maps (and whoever else). Coords belong in the infobox, because that's the sort of summary information it's for. Having the coordinates in the Geography section is okay, and they might as well be linked, but they usually have the footnote "{{GR|1}}", which links to http://www.census.gov/geo/www/gazetteer/gazette.html, not a specific page, so that doesn't seem useful. Maybe link to the appropriate page in GNIS?
Having Mapit and Geolinks in the external links used to be useful — they provided one-click access to several maps, but now there're redundant links to geohack. (And they produce the title coords in decimal degrees, which I personally don't prefer.)
Oh, good Lord! There needs to be only one coordinate — probably in the Infobox, if there is one. All the rest are just silly. Sincerely, GeorgeLouis (talk) 21:20, 6 November 2008 (UTC)
Here via my digging from WP:BOTR. I'm not exactly sure about the working of Infobox Settlement, so here's what I'm thinking. If the coords are inputted into the infobox they should appear there and in the title. I see no need for the information to be in the "Geography" section and even less for {{coord}} to be in the EL section. Coords should be something that are summarized in the infobox and in the title. There's no need for them to be anywhere else; especially when they all link to the same place. §hep • ¡Talk to me!06:05, 7 November 2008 (UTC)
I concur. In the infobox, with display=inline,title , is all that's really needed. Having the {{coord|...}} tag more than once in an article is redundant, and future edits are likely to make the articles internally inconsistent when future editors don't realize that the coordinates are duplicated. Of course, if there's a valid reason to list multiple different coordinates (for example, the discussion of linear coordinates has proposed listing both ends and the middle), than that would override. Travisl (talk) 18:52, 7 November 2008 (UTC)
Agreed, having redundant coordinates is as silly as giving the elevation of a mountain repeatedly (though see Mount Hood#Height). Once in the infobox is sufficient, otherwise maintenance can be complicated. {{Infobox settlement}} has some additional parameters (added at my request) to allow coordinates to be listed only once. For example, I add these to fix overzealously coordinated Oregon articles:
Is this discussion enough to start modifying articles to remove excess coords...or would something like this need some sort of Rfc? §hep • Talk20:46, 8 February 2009 (UTC)
In order to avoid reformatting the articles too much, I'd simply remove the geolinks/mapit template and replace it by coordinates in infobox settlement or as coord with option "display=title". For now, I'd leave the coordinates in the geography sections (the ones in dms and decimal format).
The replacement should make sure to deal with the "external links" header properly. {{geolinks-US-cityscale}} is generally preceded by the "External links" header. If no other links are present, the section becomes empty section and the header should be removed. -- User:Docu
Redundancy and inconsistency
There is an additional problem, seen at Halls, Tennessee, which has in its source {{coord|35|52|50|N|89|23|60|W|city}} (35.880612, -89.399974). The parenthesised coordinates are redundant, as {{coord}} allows users to see coordinates in DMS, decimal, or both formats. I use the latter, and so see 35°52′50″N 89°23′60″W / 35.88056, -89.4 (35.880612, -89.399974), which has both redundancy and inconsistency. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits10:42, 12 November 2008 (UTC)
I would strongly prefer that {{coord}} would generate the N/S/E/W labeled output format by default, regardless of whether or not the input markup had N/S/E/W flags originally. -- The Anome (talk) 11:29, 18 January 2009 (UTC)
See this page on axis orientation confusion for why I believe we should always include the NSEW flags in both human and machine-readable outputs. In addition, it makes the data easier to scan for without any prior knowledge of data formats; always a good idea where long-term preservation of data for posterity is envisaged. -- The Anome (talk) 15:56, 18 January 2009 (UTC)
I agree that coordinates should always include NSEW. But I'm afraid that Pigsonthewing won't stop his little crusade. Cush (talk) 21:02, 18 January 2009 (UTC)
Normally, this wouldn't be a problem, because the infobox would then itself invoke the {{coord}} template. But {{Infobox UK disused station}} does not invoke {{coord}} at all, as far as I can see, making the coordinate data inaccessible to both readers and external data reusers. Could someone fix this, please? -- The Anome (talk) 11:28, 18 January 2009 (UTC)
The coord-enwiki.log on toolserver is now down to 18.4Kb (28 Jan 09 06:28). There are just a few points to fix. One of them is the following set of coordinates with "ValueError":
moot hill -- I haven't even begun to dig into the many coordinates in this article, but I note that many of them are specified to impossibly subatomic levels of precision.
I think that leaves Dheng as the last remaining unfixed entry. I can't make head or tail of what's intended by the current markup, nor can I find any other coordinates for it from other sources. Can anyone help? -- The Anome (talk) 20:58, 28 January 2009 (UTC)
Thank you for fixing the above. Looks like we will get close to have all entries in the log fixed! -- User:Docu
Coordinates error log cleanup: "Typeless"
The approx. 70 "Typeless" errors on coord-enwiki.log (28 Jan 09 06:28) are mostly due to the way coordinates have to be entered in {{geobox}}. There is a discussion at Template_talk:Geobox#type:_parameter_needs_sensible_defaults!. An eventual change will need to clean up a series of articles with geoboxes, including the 70 mentioned. -- User:Docu
The fixes for the geobox should be ready to go live.
BTW the log doesn't include all typeless entries. Most US rambot articles use "city" instead of "type:city", but these aren't included in the log. These make up the remaining of 24547 coordinates don't use "type:". -- User:Docu
Coordinates error log cleanup: database bugs
The following appear in the log, but there seems to be no way to fix them. One is even deleted.
Thanks for fixing those. The log is now below 10 Kb for several days (9.2 Kb on 9 Feb 09 06:28). It now includes mainly the database bugs, two or three invalid template uses and non-article namespace coordinates! Obviously, every day 2-4 new errors get added, but for now, we are close to target. -- User:Docu
This secrecy behaviour seems just wierd. If these are heritage sites that the said organisation is mandated to protect, then they should protect them, not engage in playground games. --ClemRutter (talk) 14:42, 17 February 2009 (UTC)
I tracked one down in the last year, which turned out to be a private occupied residence. Perhaps the NPS was helping protect the privacy of family living there? Surely there is adequate protection from common courtesy and/or legal concerns.
Another article we briefly debated whether to add coordinates was Paisley Caves, a remote site of archeological significance. While vandals might be encouraged/facilitated by a precise location to go there and dig, litter, etc., it's just as likely it will enable more honorable folks to be there to help keep an eye on them. What's the point of listing a national historic place if it is not known nor the public is not able to appreciate it from afar? —EncMstr (talk) 16:15, 17 February 2009 (UTC)
Right, to be included in Wikipedia, the site must have passed a notability test, at its simplest this means that it must be documented in a secondary source, we are reporting not doing original research. That said, the item/article is already known. If it is known to us, then it is known to the guys that want it. The guys, that the organisation mentioned above, should be protecting the item from. Their ineffectiveness is no reason while they should interfere with the task of ensuring all our articles are correctly geotagged. That Kent County Council so mismanages their budget (this article) so they allow wholesale theft is appalling - but irrelevant. Next they will be demanding that the Guardian doesn't report it and of course that we don't mention the Guardian. No -we oppose secrecy- not to do so would make our work political and biased. --ClemRutter (talk) 00:01, 18 February 2009 (UTC)
I'm not sure we can blame Kent County Council for this: protecting archaeological sites properly would be a massive task, involving fencing off large areas of open land and posting guards to patrol the fences 24 hours a day. No elected body is ever going to spend hundreds of thousands or even millions of dollars a year per site, for thousands of sites nationwide, in order to prevent depredation that to most people is of entirely academic value. This is one case where security by obscurity probably makes sense. -- The Anome (talk) 12:44, 18 February 2009 (UTC)
If location can be found from a source, then its already out in the open and adding to wikipedia makes no difference. If the secrecy has been well enough maintained that its location cannot be found without original research, then it (the location) shouldn't be on wikipedia anyway. Talltim (talk) 10:01, 18 February 2009 (UTC)
(unindent) The discussion at wt:NRHP was specifically at Wikipedia talk:WikiProject National Register of Historic Places#geotagging of historic sites. This was just the most recent discussion, there are others archived in the archives linked from wt:NRHP. I'm joining here in response to a claim elsewhere asserting the consensus here is that location of archeological sites can be disclosed fairly freely. That should not be consensus here, please, and is not the consensus in the NRHP discussions. Secret sites should not be disclosed, generally, and calling for coordinates generates "original research" or whatever that does disclose them. The Anome has been helpful in sensitively treating the U.S. NRHP sites, by taking steps not to mark "coordinates wanted" for the ones where they are not wanted. The fact that calling for coordinates gets locals to post them is proven by one case already. Of course, there are some cases where previously hidden archeological sites have become very publicly known, like when a state or local government opened an archeological site museum and encourages visitation. But i don't think we should actively undermine the security by obscurity method, like we should not describe how to make your own nuclear bomb, to use an extreme example. doncram (talk) 00:25, 12 March 2009 (UTC)
We don't describe how to make a nuclear bomb? There probably is or should be sufficient information in Wikipedia to do so with the right parts. --NE201:09, 12 March 2009 (UTC)
Cool. I was just about to write how good it was to have an up to date source, but I tried to query some of the lakes uploaded in the last three days, but they don't appear (yet).
BTW Wikipedia World has an interface at sample and source with older data (compare) -- User:Docu
I turned on the simulate flag for the enwiki since there was a huge inefficiency, as the database grew too large to fit in the memory (processing time jumped from 10 minutes to 30 minutes). I've turn that off, it'll update in the next few hours. It is accessible to Toolserver users (use phpmyadmin). The framework is now pretty flexible for other data processing applications. So I've wanted to write a few applications that use it but haven't found the time or motivation to do so. Something like region checker that reports that a coordinate is in the middle of the Atlantic. — Dispenser04:30, 19 February 2009 (UTC)
I've found that pre-binning data points into 5°-by-5° tiles (each on average covering about 1/2600 of the surface of the Earth, and it doesn't matter too much about their nonuniform shape and size, because the peculiar-shaped-and-sized ones are near the poles, and are thus very sparsely populated), and then doing the detailed select from that subset of tiles that have tile IDs from the specific set that overlap the desired region of interest, hugely reduces the amount of the database that has to be pulled into RAM for searches, since it allows very simple one-dimensional indexing to be used to rapidly select a small fraction of the total database prior to detailed inspection of the exact location values by the rest of the select statement. I generally precompute the set of keys in advance, and then issue multiple sub-queries, and aggregate the results; you can probably do the whole thing in a single SQL statement using either a subquery, or relying on the optimizer to quess for itself that scanning a 2600-entry table first, then indexing into a 350,000 entry table, would be more efficient than vice versa. -- The Anome (talk) 18:07, 19 February 2009 (UTC)
This was also requested on commons:Commons talk:Geocoding/Archive 1#Proximity, but it could be used for both images and articles. Limit the query to n results, split the range into three or so, round the boundaries appropriately and divide into groups. A pretty output like that would be nice, and it could be used on the GeoTemplate page, or with gadgets transcluded on pages where the graphical map way isn't appropriate.
On the API topic; we would probably see more of these applications using geodata from Wikimedia projects if the data was easier available for queries. A general MediaWiki API can however never trust any specific template use or their side effects, such as now here on the English Wikipedia. I believe mw:Extension:Gis or something similar would be necessary, so that the functionality comes from the software and the API module can detect its availability. The extension hasn't seen any real updates in ages and would probably need quite a bit of work to be considered for installation here. Can we figure out what exactly needs to be done? --Para (talk) 12:31, 20 February 2009 (UTC)
To celebrate the four years of this WikiProject, maybe we could give it another try with another extension. -- User:Docu
Template:Whereisit
I've just discovered {{whereisit}}. It's not much used, but it's definitely an accepted maintenance template, and has been in use since June 2007. Interesting. -- The Anome (talk) 13:21, 21 February 2009 (UTC)
I'd trash it in favour of {{coord missing}}, but it is useful to know that it was there for whenever we decide to promote geotagging more actively by taking up some article space.
I'd also trash it in favour of {{coord missing}}; what I find interesting is the precedent; the visible coord missing label in the top right hand corner was extremely discreet by comparison with this huge box. By the way, I've just added another 10,000 {{coord missing}} tags, this time mostly for articles about places in Poland. -- The Anome (talk) 22:27, 22 February 2009 (UTC)
Since there aren't any recent dumps, I don't have access to the full category tree, so this list of 10k articles had to be generated by banging through a list of about 3000 leaf categories one at a time using CatScan. The list was generated from a hacked up version of the old tree-traversal code, running on the last valid old dump.
Retrofitting U.S. state disambigation to the resulting mess just didn't seem worth it. I might go back and rework the U.S. and UK entries later, since these are currenly the only countries that use subnational subdivisions for {{coord missing}}, and the entries for these countries are only a small fraction of the 10k overall number of entries added in this run. -- The Anome (talk) 23:19, 23 February 2009 (UTC)
Update: it looks like a number of people are already working on fixing this for the U.S. articles, using script-aided tools. -- The Anome (talk) 00:48, 24 February 2009 (UTC)
Update 3: other editors have reduced these to just 11, all of which relate to locations that span multiple states. Done -- The Anome (talk) 09:46, 25 February 2009 (UTC)
I can't quite correlate the 3,491 article we now have in the US root, with Para's stats for additions and subtractions and the progress report above. But nice tagging, thanks. I'm not about to get involved with trying to push that many down to their child categories, though :( --Tagishsimon(talk)01:33, 27 February 2009 (UTC)
I see from elsewhere that you're going to do a second pass, and that the stats difference was the hour & a half after midnight in which your bot was slaving away. Good work. Thanks. --Tagishsimon(talk)14:03, 27 February 2009 (UTC)
I haven't seen it working entirely, but a starter project might to just get it running. BTW GeoRSS seems alive. -- User:Docu
I've recently put thought into the geocoding. I came to the conclusion that the extension should be limited to describing the location only (lat, lon, alt, globe, roll, yaw, pitch) and the extra stuff that we've been including to help geohack (region, population, area, size, class) should be parsed by a more general (semantic?) parser. — Dispenser06:24, 11 March 2009 (UTC)
Allow me to be the first to ask the naive question, what is an extension (okay, it's a gazebo built onto mediawiki) ... but what might it do / how would life differ under an extension? I'm thinking from the coordinate input end of things ... would we substitute square brackets for curly? I can vaguely appreciate that it might bring things like geohack in from the cold. --Tagishsimon(talk)06:45, 11 March 2009 (UTC)
It might be a good thing to suggest several projects, one mainly for the input side. At least now that your coordinates databases is updated daily, it's convenient to have additional information (region, type, etc) for checks on a daily basis as well. Much of it can be generated from infoboxes and leads one to discover how inconsistent these are used .. -- User:Docu
Geotag vandalism
I have discovered that vandals on a certain website have realized that by adding and changing coordinates, they can make the Wikipedia pins in Google Earth form a certain pattern. This effectively opens up Google Earth to vandalism. Any thoughts?--Ipatrol (talk) 03:25, 14 March 2009 (UTC)
There are at least two counterattacks:
Verify the point. Usually, the easiest way is to follow it to a map and seeing that what the coordinate expects there is on the map.
Check the source. Unfortunately, most coordinates aren't clearly cited, at least not on the articles I look into.
If it ever gets serious, an automated response is possible. Via bot, math routines can be used to monitor recent changes identifying points that are 1) in close proximity and 2) have geometric relations (eg. form straight lines or curves). Could be just for bird dogging suspected activity for the vandal patrol folks to check out. -J JMesserly (talk) 07:21, 14 March 2009 (UTC)
I originally uncovered the idea at http://encyclopediadramatica.com/Talk:Grawp (first turn off multimedia in your browser settings). No one has apparently taken up the plan yet, but if ite does begin, we can create a bot (or add functionality to ClueBot) to revert implausable geotag entries (like over oceans). We could also have a bot that searches for mass taggings that form a certain pattern, report them to its owner, then revert the taggings en masse if the owner authorizes it. Like the idea?--Ipatrol (talk) 15:34, 14 March 2009 (UTC)
Coordinates from other language versions
Using the interwikis in pages, I started to use my bot to check for coordinates templates in other language versions. As there are hardly two languages that use the same coordinates templates, one needs to make sure each template is parsed correctly. I suppose some of you went through this too.
On toolserver, dispenser's database includes the parsed coordinates of a series of languages (9 languages English might be available). I was wondering if there is already a query to get the coordinates directly from other language versions. The steps would be:
in this wiki: follow the language links to one of the languages in dispenser's database => article title in other language
in the other language wiki: article title => article id
in dispenser's database for that language: article id => check if it's the primary coordinates
from dispenser's database: output lat, long, scale, type, source, region, title etc
from this wiki: output article title
Possibly one would need to make one query per language. After some checks, the resulting list could easily be uploaded. Shall I ask for such a query on Wikipedia:Database reports? -- User:Docu
I use the external links tables to extract coordinates for the wikiminiatlas. You can obtain coords from any language easily this way (as all coord templates are supposed to link to the geohack (I know there are exceptions, but they are easy to cover, too)). --Dschwen13:15, 20 March 2009 (UTC)
I do the same. You can either get them from the live database via the API, or parse the dump files to find them in bulk. I use regexps to parse the URLs, then add other heuristics; most importantly, that only a single unique location is defined in an article for it to uniquely define the article's subject's position. Note that the many templates can generate the same geodata twice, with the same coordinates but slightly different URLs, so you need to canonicalize the data before performing this check.
Regarding the database reports; yes, please! This would save me a lot of work, and save a lot of server load. -- The Anome (talk) 16:07, 20 March 2009 (UTC)
Excellent. This is close to what I had in mind. For the upload part, replace.py on coord missing should do. -- User:Docu
Summary import
Import of coordinates from other wikis
conversions are done based on external links to mapsources in other languages
the iwlog determines primary coordinates for articles in other languages
only primary coordinates are imported to this wiki
coordinates are used to replace {{coord missing}} with {{coord}} with the parameter display=title
dms or decimal format is kept, format=dms can be added to decimal coordinates
negative coordinates followed by N or E are converted to positive coordinates followed by S or W
coordinates are not imported if:
degrees are out of range (90°/180°)
minutes or seconds >= 60
region doesn't start with [a-zA-Z][a-zA-Z]
type is not in list. A few are corrected (e.g. village=>city, lake=>waterbody, dam=>landmark, island=>isle). coordinates with type:state are not converted. Numbers other than population are stripped.
globe is present
scale is kept, zoom from nl: converted to scale. scale can be dropped if it's equivalent to the one determined by type
source is set to "xxwiki" (xx being the wiki the coordinates are imported from). An additional string can be added to differentiate one bot from others (e.g. "-x"). If source: is used in the other language, the previous element is added after a slash, e.g. source:gnis imported from xx: wiki => source:xxwiki-gnis
region is set to uppercase, type and scale to lowercase
other elements are discarded
Last updated: 14:26, 23 March 2009 (UTC)
I added above a short summary of how to import the coordinates. Please suggest changes and additions.
Going through the unsuitable ones, it appears that there a few infoboxes on the it wiki creating invalid external links, hidden by the outdated "hiddenstructure" workaround (it:Template:Infobox Belgio, it:Template:Comune_spagnolo). It's probably worth fixing the templates. -- User:Docu
I fixed a template on jp: and 5 on it: (the error log for it: dropped from 1.2 MB to 93kB). ro: and ca: have empty {{coord}} scattered in articles. I didn't bother with these. -- User:Docu
The bot is more or less ready to import the coordinates (samples: Ballystrudder, 1923 Great Kantō earthquake). Coordinates aren't imported if there are different coordinates in the log file (after rounding to 3 decimals). In addition, it checks if the coordinates are not in another country than the one given in the {{coord missing}} tag. -- User:Docu
I thought about doing that as I retrieve it from geohack to check if it is different than the country in {{coord missing}}. On the other hand, if geohack already knows it, there are less advantages adding it. -- User:Docu
I definitely like Dispenser's idea of adding the region: code based on the country or given in the {{coord missing}} tag, if possible. However, this is only a preference, and not something I feel particularly strongly about as a requirement.
By the way, if you could have the bot work on coord missing articles in Poland some time in the next couple of weeks, I'd greatly appreciate it: having real human-generated data will be very useful, not just on its own merits, but also for the forthcoming big push on disambiguating Polish articles sufficiently to allow them to be automatically geocoded, which is a chicken-and-egg effort that needs access to a critical mass of initial manually entered gmina-level geodata in order to prime the pump for machine-matching of articles with GNS data. See User:The Anome/Gminas for geocoding for a list of candidates. -- The Anome (talk) 20:43, 24 March 2009 (UTC)
Your relying on other applications to use the same database, which is not a good asumption. If your cross-checking them anyway you might as well put region in. — Dispenser02:34, 25 March 2009 (UTC)
Dispenser's list of 1500 is alphabetical by title and updated once per day. Eventually, I suppose I will get to Z and complete all articles including Polish ones. As the ones the bot skips remain there, the first 1500 might be invalid ones and coordinates that need more checking before it get to Z though. I also went through a series of infoboxes in other languages to reduce the number of invalid coordinates. -- User:Docu
Ok then, I will let it do the remainder of today's list. -- User:Docu
Update: It's done. Today's list of 1500 covers 890 articles. About 520 coordinates were uploaded. Battle of San Germano was the last one. Anything in tomorrow's log before Battle of San Germano was skipped.
BTW For the few unclassified battles, I added the region code when one was given. -- User:Docu
That's a terrific start. If you can keep this up day after day, this should start to make a substantial dent in the backlog. -- The Anome (talk) 00:59, 25 March 2009 (UTC)
I'm upping the limit from 15,000 (previous number was off) to 45,000, I'll see how this hits the servers. — Dispenser02:34, 25 March 2009 (UTC)
Would increase the limit a bit more and re-run it? Today the output was just 1825 lines/860 articles and I uploaded the results already. The last entry was Gmina_Kochanowice. Besides that, I think it works fine.
Currently the 860 articles include about 180 articles that failed the region check and 300 articles/870 lines where multiple coordinates are given in the other language(s). I might be able to add some of these after review. -- User:Docu
Thanks. I doing the 16k lines now. It takes some time just getting the regions. Anyways, once the list is done, I suppose a weekly run should be sufficient, but I'm not quite sure how many new ones to expect. -- User:Docu
It's more or less done. There are a few sets left, e.g. articles with multiple coordinates or coordinates with primary=no (there are quite a few rivers with several coordinates in de). Some of these may still yield additional coordinates after review (e.g. coordinates where geohack didn't supply a region). -- USer:Docu
Direct calls to tool server
I have seen a number of links being made as an external link to the tool server such as [http://stable.toolserver.org/geohack/geohack.php?pagename=Sphinx_Drive¶ms=52_24_04.97_N_1_28_19.13_W_region:GB_type:landmark Sphinx Drive]. Should this method of linking to the geo page be in use or should one of the templates be used? Keith D (talk) 22:05, 8 January 2009 (UTC)
That was my thought but I could not see a way of getting the template to output a link, as required, to a name without displaying the co-ordinates. Also I have no idea of how many of these there are around I have seen a number. Keith D (talk) 22:33, 8 January 2009 (UTC)
Even if it weren't possible, direct linking is still worse than adhering to the standard way of doing it and sucking up the fact that it doesn't look exactly like you want it. Hm, that sounds a bit harsh... so no offense, but you get my point? --Dschwen00:10, 9 January 2009 (UTC)
I'd go even further than that: if it actually were possible to have coord display a name in place of the coordinates it would be bad to use it that way. It would be confusing to the reader to have a name not link to a wikiarticle, but to a set of coordinates. The blue globe next to the link might help, but I still think it would be bad style. --Dschwen00:16, 9 January 2009 (UTC)
(edit conflict) I must say that I have not been adding these, I just spotted them been added and could not find a way to replace them with the template giving the output as currently it is in the article. Keith D (talk) 00:19, 9 January 2009 (UTC)
I remember this discussed before, but can't find it from the archives now. There were multiple good points on why the links should show the coordinate numbers instead of a name for them. Dschwen's point here is a good one already; the predictability of links and their position in articles. It's for the same reason that external links shouldn't be inserted in article body, but in the External links section or sometimes in the infobox. Another point is notability: usually when there's no article about a topic, Wikipedians create red links, and once there's enough links, an article will probably be created. If nobody cares, it'll either stay redlinked forever or the linking is removed. Making it an external link or a link to GeoHack instead is again confusing, detrimental for improving Wikipedia and a bad substitute to the usual practices.
The ones I have seen are for lower level English sports teams where the link is used in the infobox of the team for the ground location where there is no separate article for the ground as that is probably non-notable or has been merged in to the team article. Though looking at the list it appears to have been used for other things as well. Keith D (talk) 16:54, 9 January 2009 (UTC)
With apologies, I'm not entirely sure I buy into {{repair coord}}, having checked the three or four articles in Category:Coordinates templates needing maintenance. I cannot quite make out what's wrong with a couple of them ... do they point to the wrong place? If so, the best thing to do is to remove {{coord}} entirely and substitute in {{coord missing}}. If there's a gross error in the template syntax, would it not be possible to get {{coord}} to recognise the condition & auto-categorise the coord as faulty? (I respect this is the best driving out the good, and may in any event not be possible; apologies). I'm also trouble that I may fix the coord, and miss the {{repair coord}}.
If we are to persist with {{repair coord}}, a practical suggestion for improvement would be the expedient of encouraging the addition of a single parameter, being a textual description of the fault, so that whoever comes after the insertion of {{repair coord}} would be given a clue as to why the article has been marked as in need to repair. --Tagishsimon(talk)21:42, 14 January 2009 (UTC)
Here are some stats generated by inspecting by eye the results of clicking "random article" 274 times, until I got bored. Out of those articles, we had:
210 non-geotaggable articles or disambig pages (77%)
36 geotaggable pages actually tagged with coordinates (13%)
7 geotaggable pages tagged with {{coord missing}} (2.5%)
21 geotaggable pages not tagged as such (7.5%)
Wikipedia's current article count is around 2,735,000, so just crudely extrapolating from this rather small sample would suggest that out of that total there are currently approximately:
360,000 articles currently geotagged with coordinates
To get an idea of overall progress, I've just added up the columns in today's output from that very useful toolserver page: in total, between 2008-10-20 and 2009-02-11 inclusive, 13382 new pages have been tagged, and 19465 geocoded, and assuming that the reporting only applies to the days listed (some days in that period are missing), this gives an average rate of 121 articles per day added to the category, and 176 per day removed. If these rates persist unchanged, simple extrapolation implies that the existing 96984 articles will all have been coded within 18 months -- although by that time, another 66000 new articles will have been added to the category.
I would imagine that some of these are due to my bot, which has unfortunately been idle a lot recently because of the lack of dumps, but I don't have time to break them out from the overall count -- it would be interesting to see the underlying rate of human tagging. -- The Anome (talk) 13:31, 12 February 2009 (UTC)
The rate of human coding has been less than we might have hoped for. And I see in other news that Wikipedia:WikiProject Orphanage appears to be encouraging the tagging of pages with {{orphan}}. I'd be interested in us running an experiment by way of reinstating comparatively our very modest "Geo-coordinates needed - you can help" message for {{coord missing}} to see whether we get an upturn in tagging. I have pretty much established [4][5] that there is no policy on tagging in article space, and so think we are well within our rights to do something as bold as this. --Tagishsimon(talk)13:47, 12 February 2009 (UTC)
Yes indeed. The visible {{coord missing}} notices were much less conspicuous than the {{orphan}} notices, and there seems to be no real problem with these. Nor are there any community problems with {{fact}}, {{who}} and other "in-line" editorial tags, which the visible coord missing tags closely resembled. Now we have the monitoring software in place, we would also be in a position to definitively answer the question of whether or not these tags will stimulate article geotagging.
Although I think it doing is a really good idea, we will need to be 100% sure we have community consensus before doing so, to avoid a repetition of the previous flame-fest. I entirely agree with your comments on the Village Pump regarding this. Given the experience from last time, I suggest that any intention of doing this should be advertised there, and opened up to thorough discussion, well in advance of actually making it happen. -- The Anome (talk) 18:22, 12 February 2009 (UTC)
Yes, but the exact set of articles to be hit is determined through a global pass through the entire category tree, and it's too expensive -- not to mention antisocial -- to spider the whole category tree to do so. A dump is much easier to analyze. -- The Anome (talk) 18:15, 12 February 2009 (UTC)
Maybe your tool could be run on toolserver. CatScan yields some results as well. -- User:Docu
I'll see what I can do, but I worry that it might clobber the toolserver unreasonably in doing so: there are thousands of categories to check. It's much easier just to load the SQL bits from a dump (or partial dump) and traverse them myself. -- The Anome (talk) 18:46, 12 February 2009 (UTC)
Should {{GeoGroupTemplate}} be rolled out to all cats with location items?
One way, it seems to me, to get people more keen to add location data is to make it more obvious to them what is there and what is not, and what it can do.
In this spirit, is it time for a 'bot to roll out the wonderful {{GeoGroupTemplate}} to all categories containing any location items?
Or perhaps, to all categories full stop, with a mechanism to suppress its appearance if there are no location items in the cat?
IMO, this template is far too little known, but it seems to me (1) it's a wonderful advert that geodata is something valuable to an article; and (2) it's quite a good way of highlighting cats which fall short on how many of their articles have geodata.
I've now taken the opportunity to hammer the toolserver with CatScan requests, at a time when it was apparently less busy (and more responsive) that usual, and have now, after a bit of manual cleanup, got a new list of around 8000 more geostub articles which can be tagged with {{coord missing}}. The tags will be added by my bot as an when time is available. -- The Anome (talk) 19:37, 14 February 2009 (UTC)
GeoHack displaying out-of-region sections
I thought I had long seen the GeoHack page restricting itself to mapping services appropriate for a point's region. However, now I see most—if not all—of the world mapping services for Portland, Oregon. For example, the first Poland service doesn't work as expected. Is this intentional? —EncMstr (talk) 06:13, 20 February 2009 (UTC)
Good progress on geocoding articles, and sudden change in rate of geocoding
There has been good progress made in geocoding articles over the last few days. According to the coord missing counter at http://toolserver.org/~para/coordmissing/, the last five days have shown a particularly high level of tagging activity:
The "added" column is almost entirely due to my bot adding "coord missing" to more articles. The important figure is the "removed" column, which is almost entirely due to individual human editors adding coordinates to articles. (My bot only added coordinates to 23 articles during this period, even then only did so on behalf of the indefatigable human editors adding coordinates for disused railway stations using my UK railway stations tool. You should also ignore the figure of 1000 articles detagged on 2009-02-12 -- this was a technical adjustment to remove articles geocoded but not detagged) This is an average rate of 183 articles a day, entirely due to human effort. At this rate, the entire current backlog of 107,000 articles could be cleared in about 19 months, if no more articles were added to the queue, and tagging continued at a constant rate.
All of this is very significantly better than the period just a couple of weeks earlier, before the bot started its big run of adding new coord missing tags:
which rate is significantly lower that the roughly 100 articles per day being tagged when {{coord missing}} was visible in articles, prior to the Big Fuss back in October 2008 when it was removed.
So what has changed in the last two weeks? Did the big influx of new coord missing tags into articles somehow drive the greater rate of tagging? Are we perhaps hitting articles that people have watchlisted? Or what?
Beats me. I've been recently geotagging a huge stack of Polish commune-type stubs, for which none are even tagged with {{coord missing}}, but the news is quite encouraging. SpencerT♦C00:33, 20 February 2009 (UTC)
Following the links from the coordmissing tracker is very interesting: there seems to be a hidden army of silent geotaggers, including IPs, who are not participants here, yet are systematically working away on the backlog. -- The Anome (talk) 13:24, 21 February 2009 (UTC)
It could be competing bots: I see that D6 removed some (see, ,e,g., [6]) I wonder if your definition of coord missing is different from other editors? People are removing tags for articles without title coordinates (e.g., [7]) hike395 (talk) 13:41, 21 February 2009 (UTC)
The D6 de-tagging run was a special case, to correct the situation where about 1000 articles had been geocoded without being detagged; D6 very helpfully corrected that in a single bot run on one day. The second diff you cited added coordinates as part of the edit, so I think its editor's detagging of the article was correct.
Geographical coordinates from articles in Wikipedia
As we updated the layout of Template:GeoTemplate, I added a list of various ways articles from Wikipedia can be found through their coordinates at Template:GeoTemplate#Wikipedia_articles. I included an estimate when the various providers updated.
Sample display for Hamilton, New Zealand: coordinates
Please feel free to expand and improve the section. -- User:Docu
A question: What is the WP:GEO guideline for putting up coordinates for a particular street/road/avenue/boulevard? Should it be the start point of the street, or the mid-point? -- Ynhockey(Talk)02:19, 18 March 2009 (UTC)
Use care in selecting a midpoint: it need not be perfectly in the middle, but should be on a non-ambiguous point on the road near the middle. That is, not near an intersection nor areas where it is divided (as in urban one way street grids). —EncMstr (talk) 18:32, 18 March 2009 (UTC)
Analysis of tagging data
I've now generated a dataset from the output of Para's coord missing tool. In the period between 2008-10-20 and 2009-02-24 inclusive, 38932 coord missing tags have been added, and 22382 removed. I hope to be able to generate some plots from this: in particular, I'm interested in discovering if there are any significant correlations between tag addition and tag removal dates. More tomorrow. -- The Anome (talk) 01:19, 25 February 2009 (UTC)
It shows we have thought about the subject, and might well come in useful as the longform argument for our case. I think we need to think, about a couple of other aspects of approach.
I tend to think we should seek to get permission at Wikipedia talk:Template messages/Cleanup, since for me {{coord missing}} is most like {{Orphan}}, which lives within the wiki-tech section of the cleanup template tags. If we do, I think we should be quite succinct in our arguments, which might be:
Time limited experiment (see below)
Tiny template
Precedent of {{Orphan}} (recently tagged 114k articles with a typically large look-at-me banner.
I think we might do well, also, to offer an experiment - for instance, that we cause a half of the articles with {{coord missing}} to yield the helpme message, and t'other half not to. That might give us some insight into whether tags yield fruit.
To do that half & half experiment, I suggest we retag half of the pages with, for instance, {{coord missing visible}}, and use an edit summary which leaves the reader in no doubt that this article needs a geotag. --Tagishsimon(talk)22:57, 4 March 2009 (UTC)
I like the thought-out discussion and planning, instead of the somewhat rushed application of the templates at first. I've checked out the arguments, and I think that they're worthwhile. I can't think of any other ideas/arguments, but if I think of any, I'll post them. SpencerT♦C00:34, 5 March 2009 (UTC)
Is it possible to extend the experiment to include a talk-page tag, to get a comparison with how effective that might (or might not) be? --VinceBowdren (talk) 18:07, 21 March 2009 (UTC)
Such a tag should include a link to a page explaining how to get good coordinates, e.g. search US GNIS, etc., and how to format {{coord}}. Also the typical mistakes, such as taking coords like (12.3456, -78.9012) and formatting them as {{coord|12|34|56|N|-78|90|12|W}}.
Maybe we should also agree how visible they should be. I made a sample at Template:Coord missing/sample 1. This sample doesn't exactly include a tag, but just the usual "Coordinates" link. Nothing to do with the stub, orphan and other banners.
BTW Indian infoboxes already include a visible tag. -- User:Docu
I seem to remeber that one argument presented against it was that it spoke directly to the reader, rather than being an impersonal comment. I'd like to forestall as many objections as possible before presenting the proposal for approval. Can anyone remember what the de: Wikipedia use for their coordinate tag when no arguments are present? -- The Anome (talk) 23:58, 5 March 2009 (UTC)
Such an objector needs to read the circa 8 zillion stub messages in article space, each of which ends "You can help Wikipedia by expanding it.". --Tagishsimon(talk)00:05, 6 March 2009 (UTC)
Not that I'm seriously advocating it, but tags like this are used all over the place, apparently without any significant controversy.
-- The Anome (talk) 00:35, 6 March 2009 (UTC)
ambox is too large for my taste, but it looks like we keep getting more and more of those. Back to something entirely different:
I used sample 1 with Rhode Island (223 articles on 13:51, 6 March 2009 (UTC)) and Uruguay (47 articles) as a start. -- User:Docu
That looks great, but I'm going to roll it back for now; please, let's not make any unilateral changes before we have had a chance to get community consensus from a wider forum; otherwise, we will simply find ourselves revisiting the previous policy flamewar. -- The Anome (talk) 14:10, 6 March 2009 (UTC)
It affects just a small number of articles, so it shouldn't be a big issue. -- User:Docu
I agree with you completely, but lets proceed through channels, with due process. I think this is probably ready to take to Wikipedia:Village pump (policy) for community ratification; I really want to make sure we have consensus from the wider non-geodata community first, before implementing this, and thus avoid a replay of the rather heated dispute that occurred back in October 2008. -- The Anome (talk) 14:15, 6 March 2009 (UTC)
It might be a bit too abstract unless we can supply a couple of samples. If you prefer, we could pick a category with just 10-20 articles. The risk is just that they get done between the beginning and the end of the discussion ;) -- User:Docu
I agree. That seems to be both proportional and realistic. Let's pick a tiny subcategory, and do that, then post a summary of the proposal to the village pump. Would you like to make the proposal to the policy zone of the pump? Alternatively, I can draft a proposal here first, for others to review. -- The Anome (talk) 14:26, 6 March 2009 (UTC)
I think you already drafted it? You might want to get a bit more input here, just to make sure that there is a consensus within the project, but as this was already discussed in the past, we are probably ready to move ahead. -- User:Docu
I like sample 1 very much, but I think it should say "Coordinates: needed", rather than "Coordinates: define". For me, the latter is too cryptic, the former plainer and more to the point.
In this version, one can list regions where it should be visible after the switch function. -- User:Docu
I'm not sure I like or agree with this idea, but here it is anyway: Instead of asking the wider community should coord missing display something visible?, instead ask them which coord missing display should be used? —EncMstr (talk) 17:03, 6 March 2009 (UTC)
I've rounded up the suggestions I'm aware of. Most of these appear in the coordinate position (at the top right alongside the article title—for Monobook.css). All are intended to add the article to Category:Unclassified articles missing geocoordinate data or, if given one or more parameters, Category:(region) articles missing geocoordinate data.
This article is about a place, but does not specify the country, city or region where it is located. Please help improve it to include this information as Wikipedia is viewed by a worldwide audience. You can discuss the issue on the talk page.
I personally like {{Coord missing/sample 2}} the best out of what we have right now. I think we shouldn't really try to overpower an article with something even close to the size of {{unreferenced}}; missing coordinates don't affect a reader in a sense that: I would rather them know an article has no references over no coordinates. But that may just be me. §hepTalk07:12, 16 March 2009 (UTC)
In any help page there should be a reminder on how to tag the article saying coords not needed- I can never remember that tag and often need it! --ClemRutter (talk) 09:19, 16 March 2009 (UTC)
I've checked that one out- but it too has forgotten to say what tag to place on the article to prevent a visit by the nice bot in the first place ! Whoever named their child River Phoenix was not helping!
In the particular case of River Phoenix, the presence of a birth, death, or living person category (and a number of more-specific but arbitrarily-chosen other people-related categories) will stop the bot from editing that article. This is a run-time check made at edit time, so it will work even if the dump data is stale. -- The Anome (talk) 12:40, 16 March 2009 (UTC)
Comparison with Orphan removal
Para kindly put together a tool showing the daily additions and removals of the {{orphan}} template - that is a visible-in-article tag.
As the number of lake articles increased from 5445 to 6506, there are 700 additional lakes with coordinates in just 2½ months. Thanks to all those contributing. -- User:Docu
This is an excellent development. At the moment, these feature-specific categories are only being generated for lakes and observatories; there are lots of other infoboxes that could do with this treatment, which will in many case reach place articles my bot cannot, and help editors with feature-specific, rather than just country-specific, interests. Two good candidates for this might be Template:Infobox Airport and Template:Infobox Diplomatic Mission.
The lake category was created before {{coord missing}}. The disadvantage with the categories linked to infoboxes is that one has to move all coordinates into the infoboxes. This can create additional work. ::Now that most articles with an infoboxes are already in one of the categories by country/region, specific categories might not be needed. One could find them with CatScan (well, maybe given their size, they are likely to timeout).
BTW quite a few new lakes were imported from other languages together with the coordinates. I'm trying to complete this by adapting the interwiki bot to work with the coordinates. -- User:Docu
With this addition, only roughly 400 of Poland's 2,478 gminas now remain to be geocoded by hand: see this link for the full list. However, if every gmina on this list can be geocoded (and any of the few remaining to be created by Kotbot over the next two weeks as it finally completes its work) it should be possible to use the information derived from this to disambiguate many thousands more Polish place articles -- possibly up to 20,000 -- sufficiently to geocode them automatically from the GNS database.
Unfortunately, resolving these will require some knowledge of Polish geography, because of the very high levels on name reuse. Is anyone here sufficiently familiar with Polish geography, or willing to perform the necessary detailed cross-checks to avoid false positives, and willing to take this this task on? -- The Anome (talk) 17:49, 18 March 2009 (UTC)
I've now reduced the scope of the problem to coding only 26 powiat articles, reducing the effort needed by a factor of 15, to almost completely resolve this issue: see further down the page. -- The Anome (talk) 01:09, 25 March 2009 (UTC)
Ungeocoding the House of Commons and House of Lords
I've also taken the Parliament of the United Kingdom category out of the City of Westminster category for similar reasons. (It also gets rid of some silly paths through the category graph, which is how I originally found this.)
I wouldn't geocode House of Commons as it's about the institution of several countries. House of Commons of the United Kingdom and House of Lords are different. Personally I think they could be coded with the coordinates of the Palace of Westminster, possibly using type:event. -- User:Docu
I think the House of Commons is inextricably linked with the place where it sits. The chamber was specifically designed for it and has only ever been used by members of the Commons. Winston Churchill equates the institution and the place in his 'We Shape Our Buildings' speech. The members may sit there only by convention but convention is what large parts of british parliamentary democracy is base upon, with it's unwritten constitution. btw Anome, thanks for all the great work :-) -Grim23 (talk) —Preceding undated comment added 11:54, 26 March 2009 (UTC).
The last few Polish counties...
I've put out a request for help at Wikipedia talk:WikiProject Poland to geocode the last few Polish counties that lack coordinates. (See my comments earlier on this page for the reason why I want to get these coded accurately.) If anyone here is sufficiently familiar with the ins and outs of Polish geography to get this right (for example: the same name is often used for multiple places, sometimes even within a single district, and there are other peculiarities such as areas that do not contain their official seat) would they be interested in finishing these? The list can be found at User:The Anome/Powiat needing geocoding. -- The Anome (talk) 00:54, 25 March 2009 (UTC)
sk geo report
There is another report on coordinates, I just discovered. It's available at http://toolserver.org/~sk/geo/enwiki_error_geo_list.htm . It appears to have been prepared mainly for de/commons, but some of the errors are relevant for this wiki, even if they are generally covered by other means (list at Wikipedia_talk:WikiProject_Geographical_coordinates#Fix). It also includes a lot of noise would know about (rambot "city" parameter). Not quite sure why U.S. states and parameter "globe" appears on the list though. -- User:Docu
I've cleaned up all the Oregon entries, except for Oregon itself. The listing says that region:US-OR_type:adm1st_scale:5000000 has an error somewhere, but I don't see it. type:adm1st is documented at {{coord}} as a legitimate type. Perhaps the scale is beyond some limit? Help! —EncMstr (talk) 06:38, 25 March 2009 (UTC)
Hello, ok, now you have found my little secret. :-) This new list is part of a new strategy. I will create a report like this for all other languages. So that we get in all language good coordinates. At the moment I have this list for en, de and commons. See here. Also I will produce for every languages an output of all coordinates. At the moment I have test this with de see here. There are 150000 coordinates in de. Why I make this work? I will get a new dataset for the project Wikipedia-World. There we merge all coordinates from all languages to a very big dataset of coordinates. So we get all small villages from ru or pt or other supported languages. At the moment my script is in the alpha test, but this "List of Error" will updated every day. @EncMstr: My script say that "scale" is bad. We should use the parameter "dim". -- sk (talk) 07:11, 25 March 2009 (UTC)
Stefan, are you saying that scale:5000000 is improper and should be dim:5000000? I haven't seen that documented anywhere. See {{coord}}. Why doesn't Ohio appear there? It has similar parameters.... —EncMstr (talk) 07:23, 25 March 2009 (UTC)
I think the US states shouldn't be there. -- User:Docu
dim: is defined in meters, while scale: is a unitless ratio. It could be related in feet, meters, pixels, etc. — Dispenser13:18, 25 March 2009 (UTC)
@Docu: This is also an interesting tool. I think it is very good to work at this problem from different point of views. I prefer the scan of dumps and the scan of the last change and the scan of new articles. So I create the Check Wikipedia output. With the same script I support now a other project Codename: Templatetiger. Yesterday we had there a new highlight. And in the next days we can support with this project also the new dump in en. With this basis it was really easy to support also the coordinates with an error output and a collection of coordinates. - @EncMstr: Scale is an very problematic parameter. We had many problems with this. So in German Wikipedia we delete this parameter or replace all with dim. This "dim" is easy to use also for no cartographers. Maybe in en it is allowed, but I am not sure.-- sk (talk) 08:54, 25 March 2009 (UTC)
In my opinion dim: is vastly better than scale:, because it's actually physically meaningful, and not dependent on either device resolution or map size in pixels. If it's actually supported by geohack, I'd really like it if we could deprecate scale: and replace it by dim: everywhere. At the moment, it's faintly ludicrous to geocode large entities with coordinates: adding dim: would greatly help with this, by allowing these articles with areas rather than points, which would be a first step towards an eventual bounding-box/outline-based system like Wikimapia. This could be easily done by a bot... -- The Anome (talk) 13:38, 25 March 2009 (UTC)
@Docu: full pagename in the URL is just a matter of convenience. it is not actually needed if you perform a join with the page table. --Dschwen15:17, 25 March 2009 (UTC)
It improves the results with dispenser's tools. Maybe sk could change it for us? -- User:Docu
That doesn't help much. Meters of what? Say one wanted to add a dim to Mill Ends Park, a circular city park 61 cm in diameter (24 inches). dim:0.61? How is dim interpreted? —EncMstr (talk) 01:27, 26 March 2009 (UTC)
Arbitrary outdent. I'm still missing a few pieces of the puzzle. 1. Why is a requirement to know the diameter of the object easier than specifying a scale manually. How wide is Mt. St. Helens? Aruba? The A1 road? 2. What is the relationship between size and scale chosen? 3. How is this an improvement (per The Anome's comment) for dealing with coordinates for areas? We still have only a single coordinate. --Tagishsimon(talk)12:10, 26 March 2009 (UTC)
Defining a centre position and "dimension" (rough diameter of the object) on the Earth implicitly defines a bounding box. Given an aspect ratio for a window, this can then be used to automatically determine a good map projection, scaling and centre point for a map, that will work independently of the size at which it is displayed. Any given feature will have a well-defined width in terms of a fraction of the width of the map, and the map will representing the object at the same relative proportions within the map regardless of scale. This then trivially allows the map to be represented as scalable SVG, or as a high-resolution raster image which can be scaled down in the same way.
The scale parameter has the same intention, but isn't well-suited to this application. Strictly, scale is the ratio between distance on the ground and distance on the map. Thus, a 50000:1 map will represent 1km on the ground as 20mm on the map. However, we have no way of knowing what this should mean in terms of pixels, since "scale" can only mean something when it is a ratio between two different physical distances, and this isn't well defined in the context of digital displays.
For example, a map might be represented as a 1000x1000 raster in its full form, but displayed as 200x200px as a thumbnail in the article. Depending on the user's monitor's dot pitch, a desktop computer could display that 200x200px thumbnail as anything from 25mm to 67mm across, and the original unscaled image as anything from 125mm to 337mm across. Worse, in the portrait view on an iPhone browser, the 200x200 px image will initially be displayed scaled down by an extra factor of 3 to fit the nominal page width of 980px within its 320px screen width, which, displayed at its dot pitch of .159mm, will result in the thumbnail being displayed as only 11mm across. If the image is defined as SVG, scaled in or out within a browser (as for example in the iPhone case), or if the page is printed or saved as PDF, it's even worse to define what the real-world size of any part of a raster or SVG image should be.
Given this, it's impossible to define precisely how big a 1km feature should be on the map, either as a fraction of the picture width, or in terms of pixels. The best we can do is to assume some typical figures for original raster size, scaling into the raster that is sent to the user (perhaps 5:1 for the 1000px-to-thumbnail case on Wikipedia), scaling within the user's software, if any, and final display dot pitch, and interpret "scale" in that context. Unfortunately, this implies that changes in Wikipedia's default thumbnail size, browser scaling conventions, and monitor dot pitch will make the concept of "scale" more and more meaningless as time passes.
"dim" isn't perfect, either; it does not give cartographers any hint as to how much context should be shown around the object in any given map. But that's not in our remit, since we don't know what the user might want: do they want, for example, to see where New York City is in the context of the United States, or in the context of New York state, or to see the city fill the map from side to side? Gecoding is one issue, cartography another, and we shouldn't conflate the two. -- The Anome (talk) 13:20, 26 March 2009 (UTC)
Update: regarding roads and other linear features, I think the dimension should be the end-to-end distance, if we are coding the centre point. Thus, a map scaled to show "the A1 road" would by default show its entire length. -- The Anome (talk) 14:00, 26 March 2009 (UTC)
But if we accept that "defining a centre position and "dimension" (rough diameter of the object) on the Earth implicitly defines a bounding box", then, to take up your cartographic discussion, we are deciding that we would like to see the object fill the map from side to side, rather than showing the object in a larger context. That appears to remove choice from us and would lead to some standardisation ... at the cost of us knowing the circle diameter, which oft-times we will not without tedious research. It's different but I'm still not appreciating that it is better. It may well be better for the A1 road, but nor for Mill Ends Park? (All of that is not to imply any support for scale: ... I guess I tend to rely on type: being parsed to select a scale). I think we do need to mull this some more. There are at least three choices open to us: scale:, dim: and type:. Meanwhile what the diplsy does to the map, by way of on-screen size, appears to me to affect a scale: based parameter as much as a dim: based parameter. Neither will grow the iPhone screen beyond its small size. --Tagishsimon(talk)14:19, 26 March 2009 (UTC)
type: in effect provides a default value for dim:, and sensible defaults for each type should lead to good results in most cases, to be overridden by dim: if present. Where areas of geographical entities like lakes or counties are known, we can use a guess of a roughly circular shape to estimate the diameter. We should also be able to use population figures, where known, to give a good guess for the areas of cities, towns and villages. 3000 people per square km, and assuming a roughly circular shape, is enough for a good first hack: if we know the country, we can do somewhat better: see http://www.demographia.com/db-intlua-area2000.htm for some per-country estimates of urban population density. -- The Anome (talk) 16:31, 26 March 2009 (UTC)
The scale currently used on Wikipedia is an arbitrary number decided by some wiki user way back when. At best it indicates the size relation between features in Wikipedia articles, but as such doesn't say much about the size of the feature itself, and depends on that original undefined definition. With the help of GeoHack's conversions, we can get an idea using external services, but we wouldn't have to rely on all that. We can postpone the choice of external map scale to GeoHack, while in the articles we would just be giving information about the subject of the article. In practice it would be giving the same information as users are trying to give with scale now, only with more precision and a real world definition.
Anyway, to demonstrate this I created a simple tool that could later be used as a link from GeoTemplate to visualise articles with the dim parameter. See for example Mount St. Helens or Aruba. I got the dim by looking at the coordinates on Google Earth with elevation visible, and used the ruler tool to get the longest dimension that seemed to still be part of the object. I suppose that would have to be defined a bit better, but it probably has been already, outside Wikipedia. --Para (talk) 15:42, 26 March 2009 (UTC)
If you're going to change GeoHack, can I make one more suggestion? One problem with dim: is that because it is defined in metres, big dimensions lead to large numbers which are difficult to get right; it would be good if we could write something like "dim:300km" instead of "dim:300000", which is easy to mis-type or mis-read as "dim:3000000" or "dim:30000".
I suggest that "dim:" arguments should be capable of being optionally followed by an SI prefix/unit notation such as "m", or "km" or "k", with the obvious interpretation in each case. Since the Earth is only around 8000km in diameter, and tiny things can be represented using decimal fractions of a meter, I can't see any need for any other multipliers. I realise that this will need support in the various tools that generate or interpret these values, but the increase in human usability more than justifies the change, in my opinion. -- The Anome (talk) 16:31, 26 March 2009 (UTC)
I go with dim: and the SI suggestion. Looking forwards, do we deprecate scale: and the type: to scale: conversion in the documentation, and ignore them in a coord string if there's a dim: present? --Tagishsimon(talk)16:35, 26 March 2009 (UTC)
Yes to all of the above! I'd like to allow only "m" and "km" and forget about "k": "dim:40km" is pretty self-documenting. (An aside: for the ultimate in future-proofing, perhaps we should have "Mm" as a possibility in the software, just in case we ever want to geocode Jupiter's Great Red Spot using globe:Jupiter_dim:40Mm... although we'd have to decide on which system of Jovian coordinates to use, and to keep on updating the latitude as the Red Spot moves relative to it.)-- The Anome (talk) 16:41, 26 March 2009 (UTC)
Thank you for answering the question. Since the only tool I knew about for manipulating map context was scale, all my encodings using scale use one which establishes the major surrounding landmarks. However, this varies considerably for the type and location of object. For a point (such as a building) within Portland, Oregon, the city itself is generally of sufficient context, so a scale of 25,000 or so is adequate. But remote areas like in SE Oregon, such as Harney Basin have little well-known landmarks, so a much larger scale is needed to help show "where it is."
Even for uniform objects—say—cities of 250 people, it greatly matters where they are (suburb or wilderness frontier?) to choose a helpful map scale. I don't see how this can automated from either the size of the object or some set of regional rules. —EncMstr (talk) 16:57, 26 March 2009 (UTC)
But the converse problem is that map source A will take your coord & scale and show you a map this big ... say 5 miles wide; another with a different default map window will show you a map that big ...say 2 miles wide. Dim: says (or can be made to say through GeoHack) display this much within your window, whatever size the window is. It's The Anome's bounding box comment. --Tagishsimon(talk)17:30, 26 March 2009 (UTC)
That's correct. The concept of scale works fine in the context of paper maps, but does not work properly when displayed in a scalable medium for the reasons articulated above. Not only are physical maps not zoomable, but they have a constant size and shape, and their scale is irrevocably bound to their physical form, allowing the scale to be chosen appropriately for that particular physical form. For example, a scale that works well for a pocket-size city guide page may not be appropriate for a map designed to fill a whole wall.
Unfortunately, in the context of electronic media, scale: conflates determining the size of objects and recommended rendering intent, and ends up doing neither well.
dim: allows not only better handling than scale: in a generic context where the size of a display size of map is unknown, but can also allow systems which are aware of visible viewport sizes, resolution limits of map data, and user preferences to do even better. For example, there's no point in using 10000:1 scaling to display map data which does not contain detail smaller than 1km on a device with a viewport size of 10cm, whereas if the map data had detail down to 1m, 10000:1 would be perfectly reasonable.
On the other hand, with a zoomable electronic device, it might be better to start displaying the map at 50000:1, or even 100000:1, and allow the user to quicky grasp the context, before zooming in to whatever resolution they like.
Object size is the business of geodata. Determining the amount of context to be shown on a map is the business of map designers, mapping software designers (including in this context, the designers of GeoHack), and end users. Wearing a geocoding hat, we should not presume to know the context in which the map is desired to be used. Wearing a cartographic hat, it's clear that the correct rendering of a map is context-dependent, and is out-of-scope for the purposes of determining what should be in geotags. -- The Anome (talk) 17:54, 26 March 2009 (UTC)
Update: EncMstr, I take your point about the next reasonable tier of context up depending on the local geography: in a very sparsely populated area, the next village might be 200km away, as opposed to 5km to the next village in a densely populated area. I believe this is what the region: field is designed to encode. If the mapping system knows the bounding boxes of regions (and if it doesn't, we can data-mine this quite quickly for a great many national and subnational regions), it can choose the "context bounding box" using this field. -- The Anome (talk) 18:36, 26 March 2009 (UTC)
I'm a little late to this discussion but after thinking it over I like the idea of defining the area to be viewed in terms of a linear measurement. (Thinking about the future it might be meaningful to document both the north to south dimension and the east to west dimension. For example the Redwood parks in California have a north to south dimension that is way out of proportion to its east to west dimension. Computer screens are not square now days so if the map server could determine the display ratio of the viewing device then both height and width would be important to document.) For the present the aim it seems to me is to define the greater of the height and width of the area to be viewed making the assumption that all monitors (and printed documents) are square.
Being a backward American and being aware of the limitations of my fellow Americans, I question defining this dimension in terms of metres. For internal data storage it seems very reasonable to use metres, but input should be flexible. Let editors use kilometres or metres or miles or cubits and then convert the data. Another reason to have access to StringFunctions? Geo data is stored in web pages generated from wiki markup in decimal degrees no matter what format the data is entered in. It might be interesting to store this data in a class as geo is. I wonder if the microformat people have thought about this. --droll[chat]01:55, 27 March 2009 (UTC)
Well, the DNS people certainly have: see LOC record, which adopts pretty much the same strategy of lat/long in degrees and radius in meters. I don't really like the idea of having units other than meters: geotagging is a sufficiently specialist activity that it's reasonable to expect users to understand meters and kilometers, and having the unit in the representation makes this very clear; most people outside of the U.S., and to a lesser extent the UK, use the metric system already.
However, if this is a big barrier to adoption, we could always run a bot to normalize the data. Once non-SI data has been converted into meters, it should then stay in meters. I also suggest that radius only be indicated to a maximum of two significant figures of precision, whatever the source; this would also mean that 1mi would be converted to 1.6 km, not 1.609344km, 100mi to 160km, and so on.
Regarding N/S and E/W extent: yes, ideally we should have both, but it would be pragmatic to start with just a single number for the time being. Once the system is in widespread use, we can think about proposing extending the system further.-- The Anome (talk) 10:43, 27 March 2009 (UTC)
The LOC record RFC talks about defining a sphere with the coordinates and then using the sphere to refer to an area, but no longer about using the coordinates as a representative point of the entity. On Wikipedia we would be using coordinates for both defining the minimum bounding sphere and as a representative point for services that don't support visualising an area (most of them, at the moment). There are many cases where the two can't be done with the same coordinates, take Half Moon Island (South Shetland Islands) for example. The island's minimum bounding sphere has dim:2400, but the coordinates of its centre are not on the island. A more representative point, perhaps a centroid, might have dim:3200, a 33% increase in size. This case may be a bit extreme, but shapes like the one on the right would also have their minimum bounding sphere coordinates far from the center of the shape. For islands it might be clear even if they're outside, but for most other things it would be very confusing if the sphere can't be visualised at the same time. I've always disliked giving politically chosen coordinates for features, but this geographical or mathematical approach has its problems as well. --Para (talk) 14:28, 27 March 2009 (UTC)
#1: according to the "typeless" count on coord-enwiki.log, there should be about 24,000 city entries from rambot (today, it reads - 24408 coordinates don't use "type:"). The report skips "city" without type: as there would be too many. As the same coordinates are given elsewhere, it isn't crucial to fix them (one could just discard these).
#3/4/5/6/7: Named parameters can precede unnamed parameters, e.g. {{coord|display=title|33|N|83.5|W|region:US-GA_type:adm1st_scale:3000000}} at Georgia (U.S. state)
minutes/seconds >=60 should be caught by Category:Coord template needing repair. I'm not sure about the count, but there may be more than listed (frequently NRHP stuff). It seems to take a lot of time until pages show up in the category though.
#10 types: coord-enwiki.log has now a full count of types. This includes all namespaces though. The corresponding pages can be found with geosearch.py
#11 population is mainly handled by infoboxes (which may not be maintained). It seems to me that are many more. The field is generally named "population_total". Some infoboxes now add it to type:city if it's numeric.
We should consider duplicating some of these checks in GeoHack, at least as far as the numbers are concerned: it would be useful if readers following those links could be informed that coordinates are potentially duff, rather than just silently "correcting" them as it does currently. However, I don't know if this would result in end-user just "fixing" coords by tweaking them until the check passes, instead of doing the Right Thing and checking the coordinates against reliable sources. Perhaps GeoHack could display a friendly message suggesting the right course of action? -- The Anome (talk) 11:05, 27 March 2009 (UTC)
{{coord}} outputs a message when the coordinates are completely malformed. If the parameters were named, I suppose it could do even more of that. Anyways, I think the errors that are just formal (e.g. using a comma instead of a period, using template:coor title d instead of coord, or [8]) could be corrected by mediawiki directly. An odd thing about geohack is that it converts {{coord|48|135|N|11|573|E}} to 50.25, 20.55 -- User:Docu
i ran across Trent, Kentucky which has a pretty good citation for the coordinates, but it doesn't seem possible to put a footnote with the coordinates in the top-right corner, so it's only possible to use a footnote if the coordinates are given twice. —Chris CapocciaT⁄C14:54, 31 March 2009 (UTC)
It would be really good to be able to do this, but I can't think of any easy way of doing so within the current syntax that wouldn't break all sorts of things. -- The Anome (talk) 14:08, 7 April 2009 (UTC)
"OpenStreetMap maps will be added to Wikimedia projects"
There is an announcement on the Wikitech mailing list at:
This is very good news, particularly if we will be able to data-mine OpenStreetMap for coordinates, assuming that licensing issues don't get in the way. A two-way flow between Wikipedia and OpenStreetMap should greatly improve both the rate of geocoding and the accuracy of coordinates in Wikipedia articles. An interactive interface for manually geocoding articles using OpenStreetMap maps as a base would also be excellent. -- The Anome (talk) 09:41, 7 April 2009 (UTC)
I made a little presentation in my (german) point of view: File:Fossgis2009-WP-GEO.pdf It shows where we are and what we have. Sorry that is written in german but with a lot of images so I hope it can be interesting to look at it. This presentation shows at the end also that we can do more than only catch coordinates from OSM we can get whole objects. In the moment this project Query-to-map is here but with a maps-toolserver we can really improve it. --Kolossos (talk) 16:44, 7 April 2009 (UTC)
Mh, yeah. About that presentation. It contains an almost three year old super-outdated crappy looking screenshot of the WikiMiniAtlas. This is kind of embarrassing. :-( --Dschwen17:02, 7 April 2009 (UTC)
Oh, sorry. I take really some parts from a presentation of Stefan Kühn from 2007 and don't updated it. Sorry. --Kolossos (talk) 19:37, 7 April 2009 (UTC)
Reading through the notes, I was under the impression that the information was somewhat dated, especially compared to what several members of WP:GEO made happen during the last year. Anyways, I think the announcement is excellent news. -- User:Docu
A proposal to simplify and improve geo markup in Wikipedia
I've analyzed Wikipedia's HTML code for representing geographical
coordinates. The current code is verbose and does not support the Geo
microformat correctly. Three alternatives, differing on functionality
and code size, are suggested as replacements.
Where is the geotag of a city supposed to point to?
OK, this is such a simple question that I couldn't believe I couldn't find information about it, but at least in ten minutes or so of clicking around I didn't find an answer.
I expected the geotag of a city to point to the civic center/city hall. But in the first few I tried they seemed to be directed towards someplace that might be in the center of the city. How is that determined? Maybe those were wrong and city hall is the location that the coordinates should point to? If it is the "center" of the city does that mean a center based on some sort of center of gravity algorithm or maybe just a gut feel idea of roughly the center of the city or perhaps some other idea.
If it is supposed to the "center", is the fact that it ends up pointing to all sorts of things like people's private houses or the middle or a road, etc bother anybody?
I thought GNIS used the same point as the U.S. Department of Transportation (for indicating highway distance to a destination): the central post office. But a quick glance at a few cities in my region shows that isn't the case. It does tend to choose points that are on public right of way though. Which country are you geocoding? Perhaps there's an official reference? —EncMstr (talk) 22:09, 13 April 2009 (UTC)
I'm not sure what the USDOT has to do with anything; except for a few federal roads, the state maintains all major highways. I believe some states use the distance to the city limits (and yes, they change it when the cities expand) while others do use the center. --NE223:33, 13 April 2009 (UTC)
Sequence Latitude(DEC) Longitude(DEC) Latitude(DMS) Longitude(DMS) Map Name
1 33.8702924 -117.9253380 335213N 1175531W Anaheim
2 33.8775145 -117.9245048 335239N 1175528W La Habra
3 33.8847368 -117.8731144 335305N 1175223W Yorba Linda
Three different points depending on what map they were referencing. It looks like GNIS just picks a point that happens to lie within the feature, a populated place in this case, and lists that for the city.
The Wikipedia article lists this coordinate
33°52′48″N 117°55′43″W
This location is on top of somebody's private residence in Fullerton. It is fairly close to the North Orange County court house and somewhat farther away from the civic center. It is close enough to what looks like it might be the center of Fullerton based on some kind of algorithm that I couldn't say that it wasn't that.
This site (http://www.placenames.com/us/p1660658/) that was recommended by the Wikipedia article on obtaining geographic coordinates provide this coordinate
33.87028 : Longitude: -117.92444
This location was within about three blocks of city hall. It was also close enough to the center of the city that it is conceivable to me that by some algorithm it was intended to be the center.
So, at this point, I remain as confused as I was when I asked the question in the first place. What location is the geotag for a city supposed to point to? In my mind, the geotag should point to City Hall unless Wikipedia chooses to document a different option. If Wikipedia selects "center" as the appropriate location for a city's geotag to point to somebody needs to define an algorithm for determining what the "center" of a city is. —Preceding unsigned comment added by Davefoc (talk • contribs) 00:31, 14 April 2009 (UTC)
So I,m not a member of this project or anything but I heard somewhere (around a campfire I think) that the US Census Bureau is kind the official source in government circles for populated places. So if you look at the wiki article for Fullerton, CA you will see that the fips code is 60 28000 (don't worry about the dash. I don't.). Now go to [9] and you will see that Fullerton City corresponds to that code and gives the numbers 33884800 -117928054 which are sorta the coordinates for Fullerton which are 33.884800, -117.928054. (I guess they can't afford periods what with the deficit and all.) Plug those numbers into Google Maps and you'll find that they mark somewhere in Fullerton. How they figured that out cost us taxpayers a bunch of money so you better darn well believe them. At least that's the way it was told to me. --droll[chat]09:25, 14 April 2009 (UTC)
Thanks for the response Droll. I plugged in the GNIS feature ID into the GNIS database and came up with coordinates that were the same as the first in the GNIS list I posted above.
I tried the same procedure for Anaheim, CA. This time I came up with a location that was within a few buildings of the Anaheim civic center. I am now wondering if the GNIS coordinate isn't supposed to point to the civic center but there are errors in the system some place that puts them a little off. I am now beginning to suspect that there just isn't any standardized Wikipedia policy about where within a political division the geotag coordinates should point to. Or for that matter is there a policy where the coordinates should point to in general? This all started when I was trying to figure out what the coordinates should point to for a park that I wrote an article about. —Preceding unsigned comment added by Davefoc (talk • contribs) 17:25, 14 April 2009 (UTC) --Davefoc (talk) 17:26, 14 April 2009 (UTC)
The good news just keeps coming it seems. OpenLayers/OpenStreetMaps integration, semantic layer work, metavid, reworking of the Javascript core (incl jQuery). Now lets hope the student can bring the project to a good conclusion. (Unfortunately MediaWiki's experiences with GSoC have been flaky so far. Kinda strange actually, that so few people with skills are interested in such a large and widely deployed project. --TheDJ (talk • contribs) 00:11, 23 April 2009 (UTC)
My bot regularly converts new occurrences of these. Personally, I think they shouldn't be deleted, as it just breaks all archives. Besides that, their presence allows users to manually import templates from elsewhere.
The geolinks set of templates could use some conversion effort .. besides that, there are the usual reports at WP:GEO#Fix -- User:Docu
Hey, I had been interested in helping with this project. Now that I examine all the templates and parameters, I realized it may not be exactly what I thought it was. I had thought I could just use Google Earth to find coords and use the simple template to put coords in the top right. Is that acceptable, or do I need to use the specific parameters and incorporate it into the article or infoboxes? If some could clarify if I could be helpful by using the "quick how to" or if that would just hinder the specific goals of the project. Thanks! Brinkley32 (talk) 14:08, 12 May 2009 (UTC)
There are several answers: choose whichever you find easiest to read.
Adding coordinates without parameters is very useful. Someone (or a bot) likely will eventually enhance them. If you're adding coordinates to cities, etc. in Georgia, it's generally considered most proper—instead of using a map—to obtain them from GNIS which can be searched here and enter them to the proper fields in {{Infobox Settlement}}. Rather than reading that template's massive documentation, it's easier to comprehend by looking at examples, say at Portland, Oregon where, near the end it has
I wouldn't mess with things like cities. I was thinking more just points of interest around my hometown. Maybe some of the articles about places around my university. I also thought about looking at the page of articles needing coords for points of interest. If I just did those with the quick template would that be ok? Brinkley32 (talk) 21:34, 12 May 2009 (UTC)
That would be useful. Look at Mill Ends Park for an example of a small geolocated point of interest. Naturally, the more you understand about geocoding, the more polished the points you encode will be. Please ask questions you may have. —EncMstr (talk) 21:43, 12 May 2009 (UTC)
I generally disagree with specifying DMS format: it has elements of an archaic notation, consumes more space, gives undue weight to a coordinate, and is harder to verify, transcribe, and enter into handheld gadgets. Expressing a coordinate with appropriate precision is oftentimes more difficult with DMS. —EncMstr (talk) 16:16, 13 May 2009 (UTC)
My opinion is that dms format is likely to be more familiar to most users. Perhaps it is even the expected format. Clicking the link causes the geohack page to be displayed which shows the coordinate data in three formats: dms, decimal degrees and utm. It is my general practice to enter coordinates as decimal degrees and use the fomrat=dms switch. That way the specificity of the GNIS decimal degree data will be retained for use by geohack. I agree that entering coordinates using decimal degrees is far less time consuming and less prone to error in my own experience. --droll[chat]18:53, 13 May 2009 (UTC)
Copyright status of coordinates from maps
There's a bit of confusion at Wikipedia:Obtaining geographic coordinates on the copyrightability of facts when interpreted from a map. I remember this extremist view discussed many times before, but can't find it anywhere now. Since this project (Wikipedia and GEO) is all about assembling information from various sources, could anyone point to previous discussions so as not to have to start from scratch again? --Para (talk) 18:21, 20 May 2009 (UTC)
There's been some discussion at Wikipedia:WikiProject Council/Proposals/Street View on linking to panoramic photo services by geographical coordinates. Inspired by my findings there, I put together a simple Javascript to allow showing a Google Street View knowing only the object coordinates that Wikipedia articles have now: tools:~para/GoogleStreetView.html. It works with the Google API by looking for the nearest Street View. See for example the Washington Monument or the Statue of Liberty in Paris. Obstructions can be a problem, like with Sydney Opera House where the closest street is under water. Coverage is also a problem, as most requests around the world will most likely result in a "not available" response at the moment. Still, I think it would be great to be able to link to these views in some way. The API in those other services may not be as flexible as Google's, but I believe linking would still be possible if someone writes a bit of code in the middle or contacts the service providers for better linking methods. What would be the best way to put these types of services on Template:GeoTemplate when they don't cover the entire region? --Para (talk) 14:05, 21 May 2009 (UTC)
How about <slippymap>lat=48.850023|lon=2.279689|z=14|w=450|h=330|layer=googlestreetview</slippymap>? More seriously, on GeoTemplate, for some services, the description notes if the coverage is limited. Some services are listed in several regions, if they their coverage isn't global. For streetview, I don't think this would help though. -- User:Docu
Talk about an information overload, having to mention every covered city in the region, and then to choose from them manually... Perhaps with the upcoming OSM integration and map modification coming closer to Wikipedians, we could rethink the GeoTemplate system. Instead of matching coordinates to country regions the way it's done now, coordinates could be matched with community edited map service coverage regions. GeoTemplate could then be just a list of links and identifiers that correspond to those coverage regions, and GeoHack would show only matching ones. No more seeing irrelevant services, no more problems at country borders or waterbodies. The only problem I can see is to have a simple enough interface for "anyone" to try poking when a service improves its coverage, and OpenStreetMap:Editing does not look too promising to me. How do they get people on board? --Para (talk) 23:37, 21 May 2009 (UTC)
Google mapping
How often do Google's spiders come by an pick up new or updated coordinates? I ask because I know that text is often indexed by Google within a day or two, yet the work I did a couple of months ago (fixing the coordinates of the Liga 1 football stadiums in Romania) has still not resulted in the "W" markers moving (from Cluj) to their corrected locations in Google Earth. Astronaut (talk) 16:04, 21 May 2009 (UTC)
On the mapsources page, there is a section with various layers to use in google. The main one still seems to date from July 2008. Wikipedia-World updated this month. -- User:Docu 19:58, 21 May 2009 (UTC)
The months are estimates. Some of the other layers have newer data. You'd need to ask google for theirs. -- User:Docu 23:07, 21 May 2009 (UTC)
Adding coordinates to planned projects
There is a dispute about whether or not coordinates should be added to building projects which are planned but have not begun construction. Please join the discussion. Kaldari (talk) 22:33, 21 May 2009 (UTC)
How many coordinates is enough
I noticed on Myakka City, Florida and many other small community articles (in Florida and presumably elsewhere too), a lot of {{coord}} templates giving the same coordinastes up to 4 times. I agree with Wikipedia:WikiProject Cities/Guideline#Geography which suggests multiple coordinates is "confusing" and "uselessly redundant", however one editor keeps reverting my removal of the extra coordinates, claiming it is "standard for communities". Is more than one set of coordinates really necessary? Astronaut (talk) 00:34, 21 May 2009 (UTC)
I have discussed this issue with the same editor I believe. More than 200 of my edits where reverted because they did not comply with the so called standard. I think there needs to be some kind of guidance. Certainly using the {{coord}} template multiple times violates the multiple link policy. I've just edited over 4000 articles using AWB that transcluded {{Geolinks-US-cityscale}}, {{Geolinks-US-hoodscale}} or {{Geolinks-US-mountain}} and a considerable percentage of the articles had at least four coordinate citations. I know this is an old issue but a MOS guide line would be helpful in these disputes. I think two links would be more than adequate normally. I think once in an infobox (geobox) or the body of the article plus once in the title line would be sufficient. I like the title line link because it can be a consistent feature of all articles related to geological locations but I will to compromise on that as well. --droll[chat]01:57, 21 May 2009 (UTC)
I don't see anything there to encourage more than one coordinate for a city. What should change there? —EncMstr (talk) 16:28, 21 May 2009 (UTC)
The addition of an admonition that a single coord will suffice, and perhaps an explanation of the hazards of multiple coords. Currently an argument can be made that the MoS is silent on the matter. --Tagishsimon(talk)11:07, 22 May 2009 (UTC)
Articles dealing with multiple locations
I'm sure that this is covered somewhere (perhaps in this page's archives), but I'm not finding it easily: What is the best way to add coordinates to an article whose subject is an entity that exists at two or more locations—for instance, Monkwearmouth-Jarrow Abbey, which deals with two places seven miles apart? Deor (talk) 23:48, 21 May 2009 (UTC)
One could consider using Wearmouth as the main one. In any case, I'd use two "name=" parameters. -- User:Docu
Yup. {{coord|1|2|3|N|4|5|6|W|type:landmark_region:GB|display=inline|name=Wearmouth}}. And I guess that "Bede's World" deserves its own coord. --Tagishsimon(talk)11:04, 22 May 2009 (UTC)
Thanks. I'd considered such a solution but was hoping that there was a more elegant alternative. (I dislike in-text coordinates, since they break up the flow of the prose.) I'll follow your advice. Deor (talk) 14:02, 22 May 2009 (UTC)
Other coordinates
The templates {{Sky}}, {{Moon}} and {{Coor Mars}} were created, dedicated to celestial, Moon and Mars coordinates. Now they only link to external projects, but could be used in a similar way to the templates of this project. Telescopi (talk) 18:50, 28 March 2009 (UTC)
Some time ago we removed type:state from the list. It didn't fit in well with type:adm1st. I like to re-introduce it with a new definition. There are a series of former countries, principalities and administrative subdivisions with articles and coordinates. These no longer fit into Table_of_administrative_country_subdivisions_by_country#Table, but still need a type. I'd use type:state for these. -- User:Docu
For bridges, I'd like to add a specific type. They are frequent in structures tagged as landmark. -- User:Docu
I note that there is already a problem with lots of insect specimen photos in wikimedia with identical geotags. They come from the same region. I am photographing wildflowers within a small area, sometimes the same flower at different stages in development. I can imagine similar problems with images of fossils and minerals. Geotagging such images makes lots of sense, but they do not fit the standard type categories. Such photos frequently have a field of view under 1 meter and ought to be tagged to 7 meter or better accuracy. I think we need a category for them, perhaps type:specimen, documented as being for mineral, fossil, plant, or animal closeups. Douglas W. Jones (talk) 19:00, 8 June 2009 (UTC)!
This looks like a very interesting community-generated dataset. Does anyone know what the licensing situation is regarding this data? If it's GFDL-compatible, we should consider using it as a resource for finding new article titles for creation, and coordinates for existing articles. See Category:North Korea articles missing geocoordinate data for the 80-or-so North Korean articles currently missing coordinates. -- The Anome (talk) 14:39, 24 May 2009 (UTC)
Could the GeoHack maintainers please fix this? Given the above, it should be a trivial fix. I've now had a go at fixing this myself. Could someone else please review my change? -- The Anome (talk) 15:04, 24 July 2009 (UTC)
If a photograph is taken with a GPS device that also uses A-GPS (i.e. iPhone) and the location written to the photo EXIF is incorrect, is there any way to manually correct it/alter it?--James Bond (talk) 07:02, 30 July 2009 (UTC)
For Andrew Haswell Green I'd like to let people click on the location of his monument, but since that's not where he is, it should appear at the sentence that mentions the monument, rather than at the top of the article. Should I do this, and how? Jim.henderson (talk) 20:16, 26 August 2009 (UTC)
Thanks; now I'll know where to look to see a simple example of how the in-line option works. I failed to see it in the doc until now. Jim.henderson (talk) 03:40, 28 August 2009 (UTC)
Ruminations on tagging progress
Rate of append (blue) & removal (purple) of {{coord missing}}, 20-October-08 to 28-August-09
Here's a graph of the rate at which {{coord missing}} is being applied to & removed from articles, based on Para's tool. According to some rudimentary excel doodling, since 01-April-09 (a point just past the steep rise of the blue addition line) we have been adding 367 tags per day and removing 285. The first figure meshes well with a different doodle: number of new articles per day is circa 1500; The Anome's Article tagging audit, above, suggests that 24.9% of articles need geocodes - and of 1,500, that would be 374 per day. The implication, of course, is that our task will grow by 82 articles per day / 30,000 per annum. And there's still scope for The Anomebot2 to stumble upon hitherto unexplored seams of {{coord missing}} candidates.
Things are actually better than they look from the graph. The figures above do not include articles that were never tagged because they were either created with coordinates or had coordinates added before the tagging bot sees them. Of the new potentially-taggable articles in each bot run, more than half are now already geocoded by the time the bot gets to them. I believe that much of this is because the widepread presence of coordinates in articles has created an expectation that a well-written article on a geographic topic isn't finished until it has coordinates, and both creators of individual articles and mass-creators of geographic stubs are now taking the effort to add coordinates when creating new articles.
I'm actually quite encouraged by the figures above: that the {{coord missing}} backlog is only growing relatively slowly in comparison to the number of new geographic articles created each day means that we are getting quite close to the breakeven point where geocoding is keeping up with article creation. The rate of tag removal is pretty consistent over time, and the historical backlog of eligible articles without either tags or coordinates is slowly reducing. If we can increase the rate of geocoding of tagged articles by only 50%, the situation would be reversed, and the backlog will slowly tail off to zero over a year or two.
I've been tagging a lot of articles with geographical coordinates lately and one thing that comes up often is a personal conflict of what type of type I should use for marking a place. I would like to know where I can make a proposal for a new type and its corresponding scale value.
If this is the place to make proposals, one I would make is to add a "type:building" and have a scale of 1:5000. I've just been marking a lot of buildings as "landmark" and I'm not sure if I should continue doing it that way.
Is there any limit to how big a region we should apply coordinates to? Lately, I've seen templates assigned to regions that stretch across multiple degrees of latitude and longitude? Isn't it misleading, for example, for us to say that France is located at 47N 02W, when in actuality it stretches across about 10 degrees of latitude and longitude? Where do we stop? Do we need to assign coordinates to United States, Europe, and Western Hemisphere? Kaldari (talk) 22:36, 1 September 2009 (UTC)
Anything which has a location is suitable for coordinates. The size of the object affects the precision, which—to date—we've suggested be indicated with significant figures. There is now the dim: parameter where the largest dimension of the object can be specified. See User:EncMstr/Coord for a friendly explanation. The other way to do it—which isn't supported at this time—is to indicate the range: France is at (42.378836 to 51.087135 N, 5.130615 W to 8.22876 E) or (46.7329855 - 4.3541495, 1.5490725 - 6.6796875). It would be sufficient to locate France with (47 N, 4 E) and the knowledge that it is 600 km across (or whatever it is). —EncMstr (talk) 22:51, 1 September 2009 (UTC)
What about non-geographical regions (I've seen these tags applied to lists and even bios!), and electoral districts which are political matters of convenience which change and even move relatively regularly? Given that the results tend to show up on Google Maps, tagging absolutely everything in sight tends to make us look ridiculous (I remember the whole drama over "Nigger" being tagged with a coordinate somewhere near Baton Rouge and showing up on various maps as such). Orderinchaos03:57, 6 September 2009 (UTC)
Can you explain what a "non-geographic region" is. {{coord}} is not normally appropriate for a bio, though may play a part in a bio, indicating the location of something of significance. Lists of geographic items benefit from coordinates. Electoral districts are geographical entities which one can point to on a map. You case that "tagging everything makes us look ridiculous" is not made since a) we do not tag eveything and b) those things we do tag are geographic in nature, have a spatial location, and thus have coordinate data that can be attached. The argument that people misused {{coord}} is not veyr relevant. People misuse all sort of things in wikipedia - do you suggest we shut the whole thing down because of this? Yours is a very negative and thoughtless argument, but thank you for making it. --Tagishsimon(talk)09:16, 6 September 2009 (UTC)
And in what looks like one part WP:OWN and one part WP:POINT, Orderinchaos has reverted about 450 instances of {{coord missing}} on Australian electoral districts. {{coord missing}} has the relatively benign effect on the article of placing it in a hidden category. I hope Orderinchaos will come and explain to us why it was necessary to revert these articles so hastily, rather than first discussing the merits of the application of {{coord missing}} on those articles. --Tagishsimon(talk)10:01, 6 September 2009 (UTC)
Tagging biographies is legitimate, if the person is dead, has a known grave or other resting place which can be identified, and the coordinates are precise (i.e. to the grave, not merely the cemetery). After all they're hardly likely to wonder off down to the pub! Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits14:45, 8 September 2009 (UTC)
I can conceive of he is buried at XYZ (coord inline) but not the use of (coord title) - insufficient contextual information to understand if the coord is place of birth, place of death, gravesite, or location of other significant event. --Tagishsimon(talk)22:34, 9 September 2009 (UTC)
I support Orderinchaos removal of coords from electoral districts. Districts are political entities that can be changed at any time, they are not geographical features. I also support removing coordinates from any biography article as such use is rather absurd, as shown by my Kurt Cobain example. Kaldari (talk) 16:48, 10 September 2009 (UTC)
Done, using the new dim: parameter. {{coord|0|N|90|W|dim:10000000}}(0°N90°W / 0°N 90°W / 0; -90) marks it as an object of radius 10,000 km; geohack passes this on to map engines, and Google Maps, Bing Maps and Mapquest (and probably others) respond appropriately by giving us a world-scale view. The miniatlas does not do as well, but I imagine that can be fixed very easily, as it can scale to the necessary scale manually. Very-large-area features are entirely appropriate for very-large-area maps. -- The Anome (talk) 18:40, 10 September 2009 (UTC)
Ideally, extended objects with no natural central point should be represented by a bounding rectangle as suggested by EncMstr above. As this "isn't supported at this time", how difficult would it be to move to supporting it? -- Dr Greg talk 18:22, 10 September 2009 (UTC)
At the moment, the dim: parameter is the nearest we've got to this: the equivalent operation would be to encode the minimal bounding great circle, and to geocode its center and great-circle radius. This has the advantages of backwards compatibility, and that it has a well-defined meaning at places such as the polar regions where lat/long-based rectangles suffer from singularity problems. On the worse is better principle, I suggest we roll out dim: for the time being; the ultimate long-term goal, of course, would be to have actual vector outlines. -- The Anome (talk) 18:54, 10 September 2009 (UTC)
The Ypsilanti District Library article was recently tagged as missing coordinates. This is a library district, consisting of three branches (none of which are likely to ever get their own articles). Should the coordinates refer to the district as a whole, to the location of the main offices for the district, or be given inline for each branch? I can probably add the coordinates, I'm just not sure which coordinates would be best to add. Thanks, cmadler (talk) 13:12, 14 September 2009 (UTC)
As for schools. Reception area of the largest campus. I made a unilateral decision on school and no-one has challenged me! But put a comment and the tag you are using in the edit summary so other editors are warned. Iĺl add that to the paragraph above. --ClemRutter (talk) 13:57, 14 September 2009 (UTC)
Significant progress in tagging and geocoding
After numerous reports of articles that had failed to be caught by the {{coord missing}} tagger, I've had the opportunity to see in detail how many of them are getting missed. As a result of this, I've now rewritten the category tree scanner to scan the category relationships bottom-up rather than top-down, and to be a bit more forgiving about which category links it is willing to consider for traversal. This detects many more articles, at the cost of producing slightly more false positives. It has now found tens of thousands of new articles to tag with {{coord missing}}, although at the moment it is not yet capable of resolving the countries for more than a small fraction of them, and the accuracy is not yet good enough to feed it into the GNS auto-matcher.
The good news is that nearly all of these articles are part of the long-standing backlog of untagged articles, and do not represent an increase in the actual rate of untagged articles being submitted, which now seems to be lower than the rate at which articles are being geocoded.
Although in the short term tagging these articles mean that the {{coord missing}} backlog will build up from around 170,000 to well over 200,000, this should clear most of the historical backlog of articles that were being missed, and that once this is done the rate of new tagging should decelerate in future to a trickle, merely keeping up with new entries as they are added.
Given that several hundred articles a day are now being geocoded by hand, this raises the possibility that, if current trends persist, the {{coord missing}} backlog could be reduced to only a few thousand articles within a year or two.
Thanks for your work, The Anome. It all sounds positive, other than resolving articles to countries and ideally states / counties / districts. thanks --Tagishsimon(talk)16:36, 19 September 2009 (UTC)
Coor d
There are now only ~100 articles using {{Coor d}}, which is deprecated. All are for the List of United Kingdom locations series of articles, and cannot be converted to the superior and standard {{Coord}} immediately because there are so many, on some of those pages, that the maximum number of template calls is exceeded. The simple solution would seem to be to further subdivided those pages, which are too large in any case. Is anyone interested in working on this with me? Some scripting will be needed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits13:38, 21 September 2009 (UTC)
I think that you will find that server load is also involved here having converted some of the smaller ones back to {{coor d}} as they would not display when the server is heavily loaded. I do not see the need to push to change these as the old template is still operative and they are isolated to a set of articles. Keith D (talk) 16:41, 21 September 2009 (UTC)
The old template has fewer features and is less advantageous to both our casual readers and our data reusers. It's also clear that, while it still exists, people will continue to use it elsewhere, requiring extra effort to convert it. The issue is not with {{Coord}}, but with having to many entries on each of those pages - they should be reduced, usually by around half, in each case. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits17:06, 21 September 2009 (UTC)
As I have said previously on this one there needs to be a light weight version of {{coord}} for these pages not more splitting up of the information. The template is too heavy on resources and needs to have some sort of structuring so that a light weight back-end can be accessed directly, or may be cutting out some of the many options that it offers. There is already too many of these pages and there really needs to be combined. Keith D (talk) 17:52, 21 September 2009 (UTC)
New error reports and dumps
After a few attempts I've got a working version of regioncheck. This tool reads the country value of the region: parameter and retrieves all regions and if the coordinate is not in any of the regions it calculates the minimum distance to the closest one. Example: correcting US locations that are placed in India.
The data-set is 11 years old and lacks updates, country code (ex: HK, ME, HK, AE, UM, IM) do not exist in the database and will not be scanned. Likewise with some states (ex:US-PR) do not exist and appear to be far away from the mainland (I'll be white listing these). Additionally, since the country code is needed and I do not know of any other way of extracting this information the it will be limited to coordinates with region: parameter.
The scan is very slow (read: hours/days) so it will likely be run on demand. I've also added a new warning types to the ghel library, InvalidRegion for invalid ISO 3166-1 alpha-2 codes and RegionAndGlobe for when both region: and globe: are used. Finally weekly coordinate dumps are available, although I suggest you get in contact with me as to avoid duplicating effort if you intend to do anything serious with the data (like importing into OSM project). — Dispenser20:35, 18 July 2009 (UTC)
I had basically given up a week later because the results weren't good. Here were some problem I had:
It would find islands that we geo-located more accurately. Blame the WorldAdmin98 data set.
A compatibility conversion table (Puerto Rico: US-PR or PR? Samoa: US-AS or AS?)
Some of the polygon have a tiny piece extending protruding. IIRC Block Island was consider part of New Hampshire because of this.
Coordinate fliping (East with West and/or North with South) didn't pan out as well as one would think.
It only works on the data that has region given. This cripple the program to work on a very small subset of points.
While most of the above problems can be work around but it is not very much fun. The source code is available if you want to tinker around and suggest improvements. — Dispenser21:30, 3 September 2009 (UTC)
While it took a bit of practice to recognize overseas possessions and polygon problems, I found the process to be both useful and fun. I found lots of flipped coordinates and incorrect region codes. If I wanted to re-run the existing code, how would I do that? --Stepheng3 (talk) 00:47, 4 September 2009 (UTC)
Python with MySQLdb, presumability MySQL with ESRI country and state boundary data and a coordinate dump (see above) loaded, and ability to figure out what to undo since I left it in a half completed "upgrade". I will look at it again over the extended weekend and see if I can't make some improvements. — Dispenser05:17, 4 September 2009 (UTC)
I've rearchitected and regenerated the report. So it's rather rough, calculating euclidean distance instead using the spherical law of cosines and has trouble with the wrap around. It also needs an interface to keep track of what's been checked and more data for better cross checking. — Dispenser06:32, 28 September 2009 (UTC)
Use of co-ordinates in parliamentary constituencies
Hi folks
I am concerned about the practice of adding geographical co-ordinates to parliamentary constituencies, and of tagging those constituencies which lack such co-ordinates with {{Coord missing}}. I have edited all the articles on constituencies in Ireland and nearly all of those in the UK, and of late my watchlist has included a lot of co-ordinate-related activity.
Having seen both co-ordinates and {{Coord missing}} tags applied by several editors and by a bot, I am posting here to start a centralised discussion on the subject, per WP:MULTI. I will then notify some individual editors and a few wikiprojects, and post a list here of those I have notified.
First thing I want to make clear is that I see the application of geographical co-ordinates as being in general a great thing, which greatly increases the usefulness of geographical articles. Huge thanks to everyone engaged in the massive task of applying them.
However, I don't think it is appropriate to apply them to parliamentary constituencies, because as currently deployed they are misleading in several ways:
The co-ordinates identify a point, whereas a constituency is an area, usually a quite irregularly-shaped area. The mapping of one point in a constituency may mislead the reader into thinking it marks the approximate centre of a zone, whereas the boundaries can follow weird shapes.
A constituency may be named after an area, buts its relationship to that area may not be as straightforward. It's not uncommon, for example, for a UK constituency named after a town to include only part of the town, with other chunks of the town being in a nearby county constituency. Similarly, in Ireland the law requires a very consistency of electors-to-seats, so although constituencies are named after counties, most of them cross county boundaries -- sometimes significantly.
Both of those factors make single-point-mapping of constituencies a misleading exercise. It would be great to have a mapping feature which actually showed the real boundaries, but I quite understand that would be a huge job, and I wouldn't ask anyone to do it. However, in the absence of that sort of mapping, the single-point anchors can seriously mislead the reader.
There's a further problem which applies even if the objections above are set aside: constituency boundaries are not static. Some constituencies, such as Sligo-Leitrim retained the same name whilst undergoing massive revisions (see Sligo-Leitrim (Dáil Éireann constituency)#Boundaries); other more extreme cases include Newcastle upon Tyne North where the constituency after 1983 contained not one single voter who was in it before 1983. There are many more such cases, and in the UK there is the further complication that in 1885, county divisions (covering large areas of a county) were often named after previous parliamentary boroughs (which may have included only very narrow boundaries, omitting part of the town as it then existed, never mind what it has now grown to).
As a result, even an outline map of the boundaries (rather than just a point) would be misleading: for accuracy, what we would need is a series of outline maps of the boundaries, so that the reader was not misled into thinking that the map applied to previous constituencies using the same name.
It seems to me that neither the outline map nor the multiple versions are possible with the current structure of geographical co-ordinates, and that any use of such co-ordinates for constituencies should be deprecated.
I will contact the editors I have seen applying such tags, and a few related wikiprojects, and hopefully we can all explore this to see if there is a way of overcoming my concerns. But until we reach a consensus, please may I ask editors to stop applying either co-ordinates or {{Coord missing}} tags to constituencies or electoral areas?
Where to start? These are just my first thoughts. There does not seem to me to be any attribute of parliamentary constituencies which sets them apart from all of the other things which have coordinates on wikipedia. Quite why of all the objections to coord I can think of in the past few years relate to PCs baffles me.
Not one single one of the 500,000 coordinates on wikipedia denotes the position of a point. Everything that is tagged is either a building, town, lake, sea, etc etc etc, all of which share characteristics with the parliamentary constituencies in that they are, in plan, areas.
Many things with coordinates change boundaries. Counties. Rivers. Forests. Cities. Buildings.
Many things have indistinct boundaries that are not marked on many maps: Soho, Greater London, Small Heath, Battersea
Many things are named so as to confuse the unwary. City of Leeds. City of Bradford.
Do not expecting coords to do everything and reject them when they do not. The sensible way forwards is for the article to provide a boundary map, and the article to have a coordinate which takes the user to a commonplace map such that the user can - if she wishes - compare the wikipedia simple boundary map with the OS or Google or Whatever map she now has in front of her. The Dim: parameter, when used correctly, serves to enable focus to be in the centre of a rectangle bounding the area that is the subject of the article, and causing the mapping software to as near as possible show only that rectangle. 381 out of 640ish UK constituencies already have coordinates without apparent ill effect. And I for one think it's very handy, when visiting Berwick-upon-Tweed (UK Parliament constituency) to be able to hop off to google or multimap without having to visit any of Alnwick or Berwick-upon-Tweed or Amble. --Tagishsimon(talk)20:28, 29 September 2009 (UTC)
Tagshimon, it would be great for every constituency article to include a precise constituency map, or rather a set of such maps, but that's a huge job, and I don't expect it to be done any time soon. The question for now is what to do in the absence of such a useful addition.
It's a pity that the fact that all the objections over the years have been to parliamentary constituencies hasn't prompted you to examine more thoroughly why those concerns are expressed. I'm very disappointed that you don't even address my concern about the fact that a constituency name may refer over the years to two or more sets of boundaries which don't even overlap.
Your point about the Dim: parameter mapping a rectangle doesn't seem particularly relevant, because I'm not awar of any UK or Irish constituency which is rectangular in shape. Nor, I'm afraid, is the comparison with a lake or a building very relevant, because lakes and buildings don't move.
Please could you take a few minutes to actually consider my concerns rather than just dismissing them? And please will you hold off from such tagging of constituencies until we've discussed this? Thanks! --BrownHairedGirl(talk) • (contribs) 20:40, 29 September 2009 (UTC)
Bluntly you're making wild and bad faith assumptions, which is not a good thing.
"all the objections over the years" amount to the Australian complaint we had about a month ago and your complaint. It is difficule to ignore things before they've happened. Both complaints have and are receiving as much discussion as I have time for, and I have done my utmost to understand the nature of the issues raised. My disagreement is not equal to any lack of seeking to understand, merely a failure to agree with them.
"hasn't prompted you to examine more thoroughly why those concerns are expressed." Outrageous. Exactly what do you know of the extent to which I've examined the arguments and argued my point and against their point? You have just.no.basis.whatsoever.for.making.such.a.condescending.stupid.comment.
"could you take a few minutes to actually consider my concerns rather than just dismissing them". Outrageous. You may not yet grok my answer but you have no reason whatsoever to presume that I have not considered your arguments.
So.
"it would be great for every constituency article to include a precise constituency map, or rather a set of such maps, but that's a huge job, and I don't expect it to be done any time soon". Have you checked how many pages have maps, or are you making this up as you go along? My experience is that the vast majority of constituency pages have boundary maps. Next - thjough I did not say so above - for me even absent the boundary map in the article, a coordinate is useful in locating where the hell in the world this article might be talking about, even if it cannot convey the precise boundary. Just as it cannot convey the precise boundary of much else that is coorded. The boundaries of cities are indistinct on any map I've ever used. School boundaries can be indistinct. Lack of a distinct boundary is not a disqualification from geolocation.
"I'm very disappointed that you don't even address my concern about the fact that a constituency name may refer over the years to two or more sets of boundaries which don't even overlap." I tried to, but you completely missed it. I said "Many things with coordinates change boundaries". I should have said "Many things with coordinates change boundaries, sometimes such that they completely do not overlap". What can I say? Boundaries change. It is not an attribute particular to PCs. I have provided examples of other things that have changed boundaries. Don't assuming the people are dense. If you have an article about an extant constituency it is reasonable that the coord will represent the current state of things, not the historical state. If there is ambiguity, use the inline parameter not the title parameter so that it is abundantly clear to the reader.
"I'm not awar of any UK or Irish constituency which is rectangular in shape. " Yes, very droll. I talked about a rectangle bounding the area that is the subject of the article. I provided an example for Berwick, pointing to its treatment on google and multimap. If you are not prepared to put minimal effort into trying to understand these fairly clear explanations, then ... well, I don't know.
"Nor, I'm afraid, is the comparison with a lake or a building very relevant, because lakes and buildings don't move" I was talking about boundary changes. Their boundaries (can & do) change. And yes, in some cases, buildings move. I guess I cannot argue that for a lake.
I've set out in good faith why I think coordinates are a good thing. I don't expect you to attack me personally because you are disappointed that I have not grokked or responded to each point of your argument in the same post in which you seem entirely and deliberately to misprepresent the points made in my argument. Very annoyed.
I really do think that the bottom line here is that you are assuming users are stupid and will be misled. I'm assuming users will be smart and understand the limitations of a transition to an external map.
Taking your Sligo-Leitrim (Dáil Éireann constituency) example, on two levels: 1. Let's play a substitution game. Imagine we were complaining that the text of the article does not adequately represent the nature of boundary changes. What wwould we cite in support of that arument. Try the phrase in the 1961–1969 row which says "except for those areas which were included in the Roscommon constituency." ... that isn't anymore defined in the article ... the article text is failing to convey exactly how the boundary has changed ... we should remove the text. It's as absurd an argument, for me, as yours is. 2. Those who wish to know reliably what the boundary is, or what the boundary change is, will refer to the footnote. AS it currently stands, if I want to look at any of the vintages of that constituency on an external map, as I think is my god-given right in this linked economy of ours, I want to do it directly rather than fannying on clicking through to County Sligo or some town and then readjusting the map because the link I clicked is focused on and sized for a single town such as Carrick-on-Shannon and Mohill. Don't stop my valid aspirations merely because the technology does not meet your aspirations.
And finally, to wander off on the thread of point identification of large areas, here's the ordnance survey - no slackers when it comes to cartography - marking for Lee Valley Park. That the park is 26 miles long and of varying width, does not dissuade them from marking it, roughly, in its centre and omitting to indicate its boundaries. This, really, is how maps work irl. And people who use maps know this. --Tagishsimon(talk)22:29, 29 September 2009 (UTC)
"Have you checked how many pages have maps, or are you making this up as you go along?" <-- My question is, have you? Certainly with regard to Australia and New Zealand, only very very few actually have maps. (Most of those that do are very imprecise and blocky, and those that aren't, I designed, and it was hard work.) Orderinchaos10:36, 1 October 2009 (UTC)
Broadly speaking, I agree with Tagishsimon. It's true that single-point geo-tagging has a lot of limitations, but that doesn't mean it'd be better for the reader to omit geodata completely. Most readers will probably understand that a geographic polygon can't be conveyed with a single set of coords, much like readers do for cities. --Padraic21:52, 29 September 2009 (UTC)
A constituency may be named after an area, but its relationship to that area may not be as straightforward. This seems to me a very good reason to have coordinates, so that the political area can be distinguished from other areas of similar name.
constituency boundaries are not static. And when they change, the article will be out of date and will need editing. Not just the coords, but the text of the article describing which towns are within the area in whole or in part. Does this happen often where you live? In the United States, it happens about every ten years. Each time some congressional districts cease to exist, replaced by new ones in other states, while the rest shift their boundaries more or less drastically.
Due in part to gerrymandering, districts are a long way from nice, neat rectangles (see e.g. AZ-2, NC-3, and TX-19) but that doesn't make it any harder to pick a center and a diameter for a map that will display the area, than for e.g. Ladybower Reservoir or Pembrokeshire Coast National Park.
That's right. I'm happy to do so until this is resolved.
My position on this is as follows:
Providing it's not misleading, some data is better than no data; it can always be improved upon, and Wikipedia's peer review process exists for exactly that purpose. In my experience, geodata begets better geodata; the presence of geodata in an article leads to its being checked, corrected and maintained by those editors with a direct interest in the subject of the article.
Yes, some people might find it hard to believe that some group of random people would first go through this entire set of articles generating accurate coordinates for all these locations; but given that the Wikipedia Geocoding community has so far coded over 500,000 articles, another few hundred articles to be coded is no particularly big deal.
Yes, their boundaries can indeed change; but Wikipedia is a wiki, and coordinates can be updated in the same way that they were originally entered.
Yes, these areas are not well described by a single point, and a map showing the region would be better. These, and similar cases, are why the geocoding syntax has been updated so that it can now designate circular areas around a point, so that we should be able to automatically display the appropriate area on the map, at the appropriate scale, on demand. For example, using this system, we can describe North America as being located at 53°30′N105°00′W / 53.5°N 105°W / 53.5; -105 (with a dim: parameter of 3000km), which causes MapHack to select this Google map as being representative of that area. To give another example, we can assign the geocode 46°00′N94°36′W / 46°N 94.6°W / 46; -94.6 (with a dim: parameter of 400km) to Minnesota, with similarly effective results.
The fact that this is now available, and integrated with MapHack so that reasonable map views can now be generated for these areas from the geotags, is precisely why I have only just started to mark larger areas as {{coord missing}}.
As far as I can see, the complaints regarding the Australian constituencies were made before any of the constituencies were geocoded, and seem to be complaints about a problem that had already been resolved by the developments above, which were already implemented prior to their being tagged as geocodable. Since there is up-to-date reference material already available for these, I suggest that we should first geocode these areas, take a look at the practicality of the results, and see where this leads us. If necessary, the mapping tools can be improved, if the inital results are not satisfactory.
There is not an either/or choice between geotags and boundary maps in articles; the two are complementary, and the combination of both is better than either alone. See, for example, City of London for how this works in practice.
Every article describing a location needs a single geotag for its title.
The most recent known location is always used
Most of the articles that are missing a coordinate, lack one because the author did not know how to tag it. They are easily solved.
The articles that make their ways onto the County list backlogs are difficulty to tag. They are usually administrative districts, colleges on two sites or linear features such as canals rivers roads.
To clarify in my own mind what needed to be done, I produced the table above. PC are included. I asked for comments. I gave an example of a difficult constituency- Jonathan Shaw's Chatham and Aylesford. It is obvious that one cannot tag with a high degree of precision- placing this within 0.1 degree (1 dec place) leaves a latitude of -7km. The way one tags a PC is to read the article, which is invariably well written, and look for the wards named. This gives a fairly accurate guide- and a look on Google maps gives a good approximate mid location. Newcastle-upon-Tyne North was more fun as there was no ward details and it was necessary to add this information before a tag could be placed. [13] always gives this data. There were three possible areas that could have been tagged- I made a random choice. Could it be done better- yes, WP is about cooperatively refining articles.
In the process of doing the tag I was able to add to the article. Without the helpful co-ordinates missing tag none of this would have been done, and the good citizens of Fenham, and Gosforth East could not have checked on whether they had been included. Readers not familiar with UK geography, can click on the coord tag and immediately see that Newcastle-upon-Tyne North is north of Sunderland, not in Staffordshire north of Keele.--ClemRutter (talk) 23:31, 29 September 2009 (UTC)
Your proposition re wards may work in the UK, but it definitely doesn't in Australia. Due to the obsession with equal population in electorates mixed with rapidly changing population, you get boundaries that run up side streets and all sorts of things, and my state's electoral commission, while it releases maps, does not release geocoding information (only the federal Australian Electoral Commission does, and even that is in a proprietary format so can only be used with expensive specialist tools). Orderinchaos10:34, 1 October 2009 (UTC)
Mmm. The difficult cases are the interesting ones. There are two fascinating issues here.
For the general reader a title tag with 7km accuracy, which is what the table proposes will be sufficient. Using the Division of Oxley example, the text us that it falls between Brisbane and Ipswich which is really the point that needs tagging. So it is off to Google Division of Oxley BlairAdam Carr] provides a wonderful map. So it looks as if Inala is the point to tag. The more controversial the division, the greater the web trail. The more detailed coordinats can be provide in the article as inlines at 2 dec place precision, and here it seems they would be very helpful. As an aside- the area is similar in shape to Newcastle-upon-Tyne North, who's copying who?
The second interesting issue is that of MIF files. Firstly, you can read some of the content using a text editor, filters have been written to convert MIFs to XML which then can be imported into open source PD programs. But I think that there is some work to do to get it working with Inkscape (a project for someone),. The startingpoint could be :Andrew Bruno's site. Just a thought.--ClemRutter (talk) 12:46, 1 October 2009 (UTC)
Conclusions?
As far as I can see, most of the comments above suggest that there is a rough consensus that we should resume the tagging process, taking care to use the dim: parameter when we tag these large areas. User:BrownHairedGirl and User:Orderinchaos, can you tell me if you are OK with this? -- The Anome (talk) 09:49, 1 October 2009 (UTC)
I don't see any such consensus - this is quite an obscure talk page and many will not have found it, and the very location indicates a bias towards the proposition (I do, however, thank you for notifying me as to this discussion.) The main problem I have, and have had, with the geotagging of parliamentary constituencies is, apart from the OR aspects in obtaining a coord result, they change, and often frequently so. This is fine for say a local council or a suburb boundary or a lake as you can still isolate a key common element. But with constituencies, what happened in the past is often a lot more important than the present situation, and some things have been around an awful long time and have a changelog the size of one's left arm. The only way I could see that being resolved is to have a whole collection of coords on each article reflecting different points in history, which is not only an undesirable solution but an even bigger OR minefield. So simply dimensioning a particular area in the present does not account for the reasons for which the constituency may be notable - a perfect example is Division of Oxley, which has moved at least twice since the events of 1996 that made it a national byword. At the end of the day we are an encyclopaedia and the text and the knowledge is the centre of what we are about, with everything else only complementing that - I think sometimes people get a bit carried away and start thinking Wikipedia exists for rather different purposes (eg a social experiment, or a GPS information tool). It cannot be all things to all people, it can only be what it is. (also, do we really want Google Maps to look like a veritable pigsty when people turn on the Wikipedia layer? It really does not make us look professional in any sense...) Orderinchaos10:20, 1 October 2009 (UTC)
A "pigsty"? Really? I would have thought that people who use the Wikipedia layer are looking for...geotagged Wikipedia articles. Which is what we are creating. --Padraic11:26, 1 October 2009 (UTC)
the very location indicates a bias towards the proposition This discussion here was started by an opponent. But you're welcome to suggest that that is somehow bias on the part of proponents. I tend to doubt that any venue at which you did not get a desired response would be found wanting. If a constituency changes, there's nothing to prevent multiple coordinates being supplied, one for each epoch, with the title coordinate sensibly reserved for the current boundary. If your assertion with constituencies, what happened in the past is often a lot more important than the present situation is true, that seems to me to be a strong argument for coordinates so as to provide more information about that important thing, than to keep the reader in the dark. The text and the knowledge is the centre of what we are about - we see geocoordinates as part of that knowledge. YMMV, of course, but pejorative phrases such as "pigsty" merely undermine your own argument and underline its inherent prejudice. Whereas I do not anticipate being able to change your opinion, I trust you will be gracious enough to note that the majority - by 6 to 2, to date - supports the proposition that constituencies should have geographic coordinates. --Tagishsimon(talk)12:44, 1 October 2009 (UTC)
A consensus amongst a microscopically sized group in a geotagging project supports geotagging - this is meant to impress me? Several of our present arbitrators got over 300 votes in support, I can think of AfD debates affecting only a single article with over 30, RfA's rarely get less than 100 and some policy debates attract well over 1,000. This affects thousands of articles and I only see three here who directly edit them. That aside - I guess I come from a public service and strongly professional background as well, and I actually value professionalism in its appearances and ways as a way of creating respect or at least some basis for it. I also through some of my work and dealings, have a lot to do with non-Wikimedians who deal with Wikipedia, and I see it as vitally important that we improve our reputation in the broader community - and see maintaining a rigorous line consistent with my own training as a good way of achieving that. Others may disagree, but it explains a lot of the stances I take on here.
I don't think people are "left in the dark" at all - any good electoral article will explain its geography, and it is the great thing about the English language that it will be much richer and clearer in its nuance than geotagging ever will. The risks associated with misleading them are far darker than having to click on a couple of precisely defined articles with geolinks (and the extent to which geolinks are used is debatable, given the number of times I have to clean Google Maps links out of suburb articles).
It's probably amusing to some who know me that I see the situation that way given that my present major at university is Mathematics and Statistics and I have a strongly IT background (got a degree in that years ago and I teach it as well), but I guess my interests have always lain in the social sciences and in particular politics and geography (and to some extent, the territory where they meet - one of my offline projects is building maps of how people vote, but it's *way* too OR for Wikipedia). Orderinchaos13:18, 1 October 2009 (UTC)
Oh, and much as I'd like it to be otherwise, the fact is that even good articles about notable electorates attract very small numbers of viewers - we're not talking about the great hordes being left in the dark. stats.grok.se shows Electoral district of Perth, the only GA one in Australia, peaking at 18 hits per day, while Division of Moore manages 12, Oxley 13, and even Griffith, the Prime Minister's electorate, has a peak of 30. Most are well down in the single digits. Even the average Perth suburb (of which there is more than 300) gets more hits. Orderinchaos13:28, 1 October 2009 (UTC)
We're not trying to impress you. We're trying to get on with building the encyclopedia. Clearly our views do not coincide - and it is less that helpful of you to note that you "come from a public service and strongly professional background", as if any of the rest of us do not. The question is, will you give way, in view of the discussion here, which suggests that this singular characteristic of constituencies, that their boundaries change over time, sometimes radically, can be well met by supply a coordinate for each epoch. For really, the bottom line for the proponents is that neither you nor the person who started this thread have made a compelling argument for the sacred distinctness of constituencies over all other areas that have coordinates. --Tagishsimon(talk)13:30, 1 October 2009 (UTC)
In response to The Anome (talk·contribs), I'm sorry, but no I am not OK with the proposal to resume tagging. Most of my concerns have not been resolved. :(
The one thing which I think has been improved is the suggestion that there could be multiple co-ordinates where boundaries have changed. That is a welcome acknowledgement of the fact that constituency boundaries can change radically ... but I have yet to see any example of how this would be applied in practice.
I had hoped to give a longer response, but some other issues have taken a lot of my time and I will be offline for the next few weeks, so this will have to be briefer than I would like. Sorry!
Firstly, I am very disappointed at the tone and substance of Tagishsimon's responses. We are all' here to build an encyclopedia, and it adds nothing to the discussion to throw that line at an editor who has been kind enough to explain his/her particular expertise. Two editors with expertise in parliamentary constituencies have expressed concerns here, and sarcastic responses such as as "sacred distinctness" do nothing to help build a consensus. Please seek clarification rather simply trying to defend a particular view. I said that the outset that I wanted to "explore this to see if there is a way of overcoming my concerns", so I think it's great pity if my views are interpreted as "never use co-ordinates". What I trying to say is that I can't yet see any way in which the currently deployed map-linking technology can provide the useful link without misleading.
I don't see any satisfactory answer to two initial points were that a) a constituency is an area not a point, and b) it is usually a highly irregular area. I note the suggestion of using a DIM parameter to define an area, but AFAICS that can only define either a circular or a rectangular area. I have yet to encounter any constituency with either circular or a rectangular boundaries, so I don't see how a DIM parameter which produces a circular or rectangular box can do anything other than mislead the reader by implying that the box/circle denotes the extent of the constituency. I appreciate the good intent, but if anything, it seems to me to be rather worse than just having a point on the map.
I note Tagshimon's accurate observation that many other things on maps have irregular shapes, e.g. lakes or counties. I quite agree that for this sort of entity, a point link works well enough -- because when the user goes to the map, they can see the boundaries of the lake or county displayed on the map. (Well, usually! there was one lake I looked for recently on google maps, but it wasn't marked. However I could see it on satellite view). However, when a user goes to a point on the map indicating a constituency, they have no way at all of determining the boundaries of the constituency. The point may be at the top corner of an elongated L-shaped constituency, or at the right-hand end of a long line ... but there is nothing at all on the map to tell them. Constituencies are a form of data not included (AFAIK) on any of the current publicly available on-line electronic maps of the UK or Ireland.
To my mind, this wouldn't be a problem if the co-ordinates linked to the maps in some sort of qualified way which said "look, this isn't precise, but the boundaries are some sort of unpredictable shape which appears to include this point, and it's definitely somewhere in this part of the world". To my mind, both the point and the DIM solution mislead by appearing to offer greater accuracy than they actually do. I'd like to see a solution, but I have yet to see any way in which this problem can be overcome. Please folks, I'm open to persuasion -- is there any way to address this? Can the co-ord facility include some sort of disclaimer to be displayed on the map when it loads?
Taghsimon says "the vast majority of constituency pages have boundary maps". In my experience, that is the case for the current boundaries of electoral districts in the US, and for about half of the current boundaries of UK constituencies. I think there's better coverage for current Irish Dail constituencies, but even those maps are of limited use for comparing with the sort of detail in online mapping services, because they are of very low resolution as displayed, and even if expanded still don't show either towns of landforms (see e.g. File:Donegal_North_East_(Dáil_Éireann_constituency).png)
However, I am not aware of any Irish or British constituencies which include any maps for previous boundaries -- there may be some, but if so they are very rare. Yet Category:Ireland articles missing geocoordinate data already includes some (maybe all?) constituencies of the Parliament of Ireland, which was abolished 209 years ago. Getting maps for those constituencies isn't going to happen soon (and it'd be major piece of original research), and even for newer constituencies I'm not sure that maps would be readily available. Consider Dublin Townships (create 1937, abolished 1948) -- getting the maps of that would need an archive search in a specialist library.
Wikipedia is a work in progress. Some things are incomplete and leave the reader frustrated, such as the Sligo-Leitrim boundaries which Tagshimon wrote about above. I quite agree that the text there would be more useful if expanded: it currently includes a summary of the legal definition of the boundaries in column 3 ("boundaries"), and my brief explanation in column 5 ("notes"). There are no on-line maps of those boundaries.
Tagshimon says, "AS it currently stands, if I want to look at any of the vintages of that constituency on an external map, as I think is my god-given right in this linked economy of ours, I want to do it directly rather than fannying on clicking through to County Sligo or some town and then readjusting the map because the link I clicked is focused on and sized for a single town such as Carrick-on-Shannon and Mohill. Don't stop my valid aspirations merely because the technology does not meet your aspirations."
Hyperbolic langiage aside, that's great in principle. Bbut how does it actually work? How could we put a co-ordinates link beside each vintage of that constituency which doesn't simply mark a point somewhere in County Sligo, and still leaves the reader with a map which doesn't show any of the boundaries? If there's any way in which you think this can be, done, why not demonstrate it in a sandbox so that we can see how it works in practice?
It's all very well talking of your aspirations, and I don't want to impede them. The problem, however, is that as currently implemnted, the links mislead.
That's all I have time for now, and I'm going away for three weeks, so I dunno where this discussion will get to in my absence. But may I remind editors that there is no deadline? For most articles, adding geotags is uncontentious and much appreciated, so why not just work on those articles and leave the constituencies aside until some wider consensus can be formed on a way to satisfy the concerns expressed here by those whose expertise in in in constituencies rather than geotagging? --BrownHairedGirl(talk) • (contribs) 17:09, 1 October 2009 (UTC)
Your asking for non-street atlases. At the moment most of the online services provide either provide street maps with some geographic markers and/or aerial views. The collaboration with the OSM project will integrate their street maps and hopefully provides us with technology for producing other types of maps, like a bird atlas or political maps. You may find the discussion [Maps-l] OSM-Wikimedia collaboration : what next ? to be informative. If you want to change the GeoHack page to add a warning, just edit GeoTemplate. — Dispenser18:45, 1 October 2009 (UTC)
Thanks, Dispenser. There may well be interesting developments down the line, and it would be great if some of them allowed wikipedians to create political maps, but they evidently aren't here yet.. And even if/when we can create political maps, it doesn't mean that it's going to be quick or easy to create them for entities which pre-date the electronic era. Irish constituencies tend to be defined partly by "former rural district"s, so there's another set of historical data in there. I'm sure that in due course the energy and enthusiasm of wikipedians and other open-source projects will to start to make some really useful stuff like this available, but for now have to work with the software and data sets as they currently exist.
The current technology does some things very well, but that doesn't mean it is yet suitable for every purpose, and we still don't sem to have solved the problem here.
I'm not just going to edit GeoHack, partly because it's a complex template and I haven't studied how it works, but more importantly because we have discussed here what changes (if any) should actually be made to GeoHack.
You guys here are (I presume!) the people who understand what's possible with the current technology, so please can you help me out here? Is there any way that we can modify GeoHack and/or something else so that a disclaimer or explanatory note can be included for selected articles? --BrownHairedGirl(talk) • (contribs) 19:39, 1 October 2009 (UTC)
Unfortunately, GeoHack isn't advanced it just downloads the parsed paged and replaces the place holders keywords with the coordinates. The only way we can add warnings is by resorting to using JavaScript (maybe checking for layer: or aspect: or section: parameter). Maybe someone will write an app to provide context related services. Till then the best solution is to rename "Map" to "Streets" to better the particular aspect of the service.
Before Google Maps integrated the Wikipedia layer people were wondering why we should even include geocoding pages, before that debates about which mapping service we should be using. — Dispenser01:03, 2 October 2009 (UTC)
I have also been concerned at the application of coordinates. I objected on one or two when a coordinates missing tag was first applied, but was ignored. On furhter thought, it is probably better to have some sort of coordinate. The difficulty arises when boundaries change. Where there is a new name we have a new article, but there have been many reoganisations of British constituency boundaries. There have been South Staffordshire consituencies at two periods with very different extents. Bewdley was a borough constituency, effectively for a small town until 1832, when it became a county division. One answer might be to split the articles, but that will be a lot of work and raise controversy. Maps indicating old boundaries do exist, but compiling them all properly will require a lot of work in archives or libraries. This is something we need to have done one day, but probably not now - unless we have an enthusiast, willing to take it on. For the moment, I think we should carry on as we are, but we need a mechanism for pick up cases where the coordinates given are in fact outside the boundary. In these cases, some one will need to provide an indicator to the project as to where the marker should be placed. These comment apply primarily to the UK. Peterkingiron (talk) 16:29, 2 October 2009 (UTC)
As you say, this is something we need to have done one day, when we have enthusiasts willing to take it on. Using {{coord missing}} is the way to make that day happen as soon as possible.
Just to show you what can be done, we have for some time been carrying on a systematic effort to geocode every UK railway station ever created, even those which have been demolished since the 19th century. This has been attacked using a combination of bots, old maps, and the efforts of a number tireless researchers, some of whom have been posting here. Similar efforts are in progress all over Wikipedia: see http://toolserver.org/~para/coordmissing/ for just a partial view of some of those efforts (note that this does not include the many, many articles that are geocoded before the tagging-bot sees them, often by their initial creators.) If you build it, they will come.
Regarding the idea that we are filling up Google Maps with "garbage"; we were here first, and Google uses our tag data precisely because we are a source of high-quality data. We are driving innovation here, not the mapping providers.
Problems have solutions. If people are concerned about large numbers of historical articles appearing in the overlay, we can look into adding a "historical" flag to the {{coord}} template, to add extra metadata that might be useful to mapping providers. If people want a reference date to be added to historical coordinates, we can do that too. If people are worried about points for large areas appearing on lower-scale maps, we can work with mapping providers to help them use dim: data to filter the tags that appear appropriately. -- The Anome (talk) 16:37, 3 October 2009 (UTC)
FTR, I do think railway stations (including historic ones) are a good use of specific coords as, although maybe difficult, they can be narrowed down to a single point, and stations have an obvious link to place by their very nature. It certainly wasn't what I had in mind when I used terms synonymous with pollution. Orderinchaos14:58, 7 October 2009 (UTC)
Identified problems and proposed solutions
Following on from my comment above, here are what I believe to be the problems that have been identified so far, and some proposed solutions to those problems.
Problem - positions are coded as points, this is a poor solution for large areas
Proposed solution: already exists; using the current dim: parameter to specify bounding circle. Work needs to be done to make this usual practice, and to retrofit dim: parameters to older data where appropriate. It might be worth considering making dim: into a keyword parameter to the template itself, which would allow auto-categorization of these pages, and potentially different display formats if desired.
Problem - centre points of large areas show up as mysterious points when overlaid on maps with high zoom factors
Proposed solution: work with mapping providers to help them suppress display of points for large areas (as determined by their dim: parameters) on overlay maps when at high zoom factors
Problem - display of historic features can cause confusion on overlay maps
Proposed solution: add a "historical" parameter to the {{coord}} template that can be used to identify coords for things that no longer exist. Work with mapping providers to make them aware of this feature: they may, for example, want to put these points on a separate overlay
Problem - boundaries can change, things can move, no way of knowing which date geodata refers to
Proposed solution: add a "referencedate" parameter to {{coord}} to allow this to be indicated -- but there is no need to use this in most cases, because most things will not move...
Does anyone want to add any more problems to the list, or provide criticism for, or improve on, the proposed solutions above?
I've reformatted your commrnt (no content changes) for clarity; hope that's OK. Your proposed solutions are reasonable, if the problems are sufficiently severe as to warrant them. I'm not convinced that that's the case. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits22:11, 3 October 2009 (UTC)
It's also just occurred to me that we could also use a "future" parameter to identify coordinates for places that do not yet exist, such as a proposed railway station for which the site has already been determined but construction has not yet started... -- The Anome (talk) 12:20, 4 October 2009 (UTC)
Can I add a further problem. Losing simplicity. We have a backlog of unclassified articles, and I suspect this is caused by many editors finding the process a step too far. I already have 4 customised bookmarklets for generating the geotags that I am using to clear some of the backlog. What ever we do here I suggest must be achievable in four mouse clicks or you will lose willing volunteers and confuse further the miscreants. I can see the interface I would like- the prompt box is fine, if one of the buttons could open a drop menu to set the additional parameters, then I think it would be workable but I am not sure that Javascipt is up the task. Yes, lets boldly go.... but we have to keep the passengers on board. Discuss. --ClemRutter (talk) 19:11, 4 October 2009 (UTC)
Thanks! You're right, of course, and I hadn't considered that If it stops being user-friendly, people will stop using it. Perhaps we should address these issues one at a time, rather than trying to make several changes at once, and only think about adding new things once the previous change has bedded down and is widely accepted among the userbase.
I suggest that we try making dim: support more widespread first, because (a) it already exists, (b) it's optional, and won't be needed to be added to most geolocated articles, (c) it seems not to get in people's way at the moment, and (d) can be largely autogenerated for many cases [see below]. -- The Anome (talk) 22:43, 4 October 2009 (UTC)
Also: better tools for geocoding are urgently needed, and those bookmarks sound very useful. We should consider putting those scripts on the toolserver, so that they can be made quickly available to users in general. -- The Anome (talk) 23:02, 4 October 2009 (UTC)
Autogeneration of dim: data
Since a lot of the above hinges on the availability of dim: parameters for area-type objects, here's another idea.
If we have any given well-defined set of things with continuguous areas (countries, counties, states, gminas, school districts...), and we have all, or nearly all, of them already geocoded, we should be able to make a pretty good guess at their sizes, and thus dim: values, by computing the Voronoi map of their coded centers.
It'll be a hack, of course (things generally aren't Voronoi-cell-shaped, representative points are not always at geographic centers, the concept of "geographic center" is not well defined anyway, what do we do at the edges of a set of points, where the Voronoi cell's area is semi-infinite?) and in practice various fudge factors would need to be added to stop silly things from happening, but it would be a good start.
Once the algorithm is coded, it should be easy to generate dim: parameters for hundreds of thousands of articles which describe this type of object. -- The Anome (talk) 18:20, 4 October 2009 (UTC)
Done -- The Anome (talk) 01:56, 3 December 2008 (UTC)
Resolved
There probably is or should be sufficient information in Wikipedia to do so with the right parts. --NE2 01:09, 12 March 2009 (UTC)
_Circumscribed.svg)
.png){kind=link}