Wikipedia talk:WikiProject Geographical coordinates/Archive 13

Suggested geolinks compromize

Above, on this page, for those who have the patience to follow comments, there has been a lengthy series of discussions about the Geolinks templates. Opinions are strong on both sides of an argument.

Viewpoint one: There should be no links on a Wikipedia article page to third-party mapping sites. The place for those links is on another page. We'll call this other page "Geohack".

Viewpoint two: There should be links on a Wikipedia article page to third-party mapping sites, alongside a link to Geohack.

There have been strongly-held arguments made for both viewpoints. Viewpoint one has been most vociferously defended by two users in the most recent discussion: SEWilco and Para. Viewpoint two has been recently promoted by Orderinchaos, TRS-80 and myself.

Viewpoints one and two have been supported by other users. I don't wish to downplay their opinions - I'm going on column depth!

I opened the Geolinks-cityscale discussion (see above) on Christmas Eve and added an RFC last week.

On Saturday 6 January I thought to myself "Aha. Two weeks have passed. I have a majority of votes in my favour now. Why don't I close the vote, revert the page and relish my win?".

To confirm how I'd been right all along I decided to read some Wiki articles just so I could wallow in my victory glow before reverting geolinks-cityscale. I started with Wikipedia:CONSENSUS which lead me to Wikipedia:What_"Ignore_all_rules"_means and finally to Wikipedia:Truce.

I have no legal training but I have found the Wiki articles quite stimulating. It has made me think about why I have got so passionate, why any "opponents" have got passionate, why I feel empathy with people who have supported my viewpoint and why I dismiss those with the other viewpoint.

I also realise, having read more, that consensus wasn't reached earlier and it hasn't been reached now. Before I started on December 24, I had an opinion that the previous 4:7 (see way above) vote was flawed - no changes should have been made to any template as consensus was not reached. To now say that this position is reversed by a 5:3 vote (see not so way above) is equally flawed. There is still no consensus. Never was. Isn't now.

I have to recognise that proponents of "viewpoint one" have their own reasons, equal with proponents of "viewpoint two". As others have pointed out, nobody is right or wrong actually. We just have opinions.

Now we need a way forward. We certainly don't need an edit war.

Here is a suggested compromise.

Both sides recognise that both viewpoints are passionately defended, have a basis and we do not need to argue them again for the while.

Viewpoint one holders: Accept that two templates invoke particular feelings: Mapit-AUS-suburbscale and geolinks-cityscale. Allow a compromise to be reached where these two templates, and these two templates only, are reverted to their state in November 2007. All other Geolinks templates not to be reverted.

Viewpoint two holders: Accept that the changes in November were done and live with it. Accept that there is no point in having an edit war, going off on our own etc. Revert Mapit-AUS-suburbscale and geolinks-cityscale only - leave all other geolink templates in the post edit state. Do not fiddle further with these two templates either - this is not an opportunity to streamline sources etc. This has to be done in good faith.

Both viewpoint holders and other parties: Keep monitoring the situation until Geohack matures (which may be soon) or in-line solutions found and/or agreed to. Come back to this discussion. Indeed use the partial revert as an opportunity to see how both styles are being used by Wikipedians - perhaps we could get some statistics. Try not to keep returning to the arguments as we all know where we stand. Try not to sneak other arguments/changes in under the wire. We have two reverts and many more keeps. We all live with this for a while. Period.

This may look like me suggesting that I have my cake and eat it. However I strongly want all geolinks templates back to their pre-November state but if I can't have that, I'd agree to this.

Other opinions on this compromise or other ideas for moving forward, speak now. (Please: Try not to reopen the original debate. This is about finding a compromise). Let's add a deadline: Tuesday 15 January 2008, Noon GMT. --Scotthatton (talk) 01:58, 8 January 2008 (UTC)

Seems a reasonable compromise suggestion to me. Orderinchaos 03:12, 8 January 2008 (UTC)

None of the discussions on this page have been votes and they should not be counted as such. You really need to read through all the arguments. And so far I can't agree that the "viewpoint two" side has had any basis, as there hasn't been any reasonable argument for keeping geolinks, except maybe the one about GeoHack supposedly being difficult to use, which unfortunately hasn't been detailed further. To move forward, how about following well explained opinions of people entirely unaffiliated with articles of any single region, geolinks templates or other coordinate projects, such as this comment from User:Wikidemo: "for the sake of consistency and fairness, where we have essentially the same need on 300,000 articles we shouldn't be linking to external web services on an ad-hoc basis. Best to have a standardized, predictable way of doing it so that all the users know what to expect and we're not in the position of favoring one advertising-supported commercial service over another." Any others? --Para (talk) 04:24, 8 January 2008 (UTC)

Para - I acknowledge the arguments on both sides of the debate. Are you happy with the compromise proposal? --Scotthatton (talk) 09:25, 8 January 2008 (UTC)

No I am not happy with it, and can't see how anyone could be, other than the people who have been maintaining the soon-to-be-deleted templates. It would leave about 3,200 articles of the total 300,000 location related ones with redundant links just because of opinions that come down to WP:USEFUL and WP:ILIKEIT. It seems to me that the people supporting geolinks are ignoring all the issues mentioned in the above discussions, are not elaborating on what is wrong with the alternative, and are trying to act on the basis of WP:OWNERSHIP. One possible compromise for keeping the two geolinks templates for now could be to add a supported coordinate template to those 3,200 articles with a bot, and leave it for other editors (none of us) in the normal editing process to remove the redundant geolinks templates from the articles. --Para (talk) 12:45, 8 January 2008 (UTC)

"other than the people who have been maintaining the soon-to-be-deleted templates". Soon-to-be-deleted? Now I think I need to know more. Please explain. --Scotthatton (talk) 14:35, 8 January 2008 (UTC)

Since the geolinks templates (except perhaps two of them then?) no longer serve any purpose, and as the second stage of the changes will be substing the templates to text and coord in articles, the unused geolinks templates should then naturally be deleted. For those remaining two templates the community will no doubt later do the right thing and get rid of such redundant external links, eventually leading to the deletion of the two templates as well. In a project with relatively few interested contributors, "soon" can be a longer time than it might normally be on Wikipedia. --Para (talk) 15:44, 8 January 2008 (UTC)

I am finding all this a bit arrogant, dismissive of others views and presumptive but perhaps that's me. --Scotthatton (talk) 15:52, 8 January 2008 (UTC)

It's you and others who missed the many mentions of this long-running discussion. This discussion (spread across this Talk page) has tried to be inclusive, which is why there was a suggestion to perform an interim change so as to help alert interested people. And if we were indeed being dismissive, I'd have already begun the substitution process which I stated I was delaying until after the holidays. I'm waiting for a decision, although someone else might decide there has been a decision. -- SEWilco (talk) 17:10, 8 January 2008 (UTC)

Some of us didn't notice these above discussions until too late for which we will never be forgiven. Who is the mysterious "somebody else"? --Scotthatton (talk) 21:32, 8 January 2008 (UTC)

I think I said that you didn't notice the discussions, but that was stated as a fact and not a sin. No specific "somebody else" is intended, it's simply that my lack of action does not affect the decision of others. -- SEWilco (talk) 22:36, 8 January 2008 (UTC)

I was hoping this subsection would cool everything down and a discussion would ensue. Instead I feel anything I contribute is treated with contempt by SEWilco and Para. Fair enough. I am obviously not seeing the light of pure reason. --Scotthatton (talk) 21:44, 8 January 2008 (UTC)

If I was treating this with contempt then I'd have continued the updating process. Instead I'm reading the contributions. -- SEWilco (talk) 22:36, 8 January 2008 (UTC)

Please note that any further work on these templates needs concensus or at least agreement. At the moment there is no mandate or agreement to do absolutely anything at all, whether trashing the templates or reverting. --Scotthatton (talk) 19:50, 10 January 2008 (UTC)

What's your (and others') opinion on the compromise I proposed above at 12:45? That would leave it to individual article editors to decide what to do with geolinks. --Para (talk) 15:52, 11 January 2008 (UTC)

In the absense of any other ideas, that would be a way forward. We seem to have few other people interested in anyh of these issues right now. --Scotthatton (talk) 17:05, 12 January 2008 (UTC)

I'm starting to think that dispute resolution is necessary, as certain editors are acting completely contrary to the spirit of Wikipedia and have already made up their mind what they're going to do regardless of what anyone else says. Orderinchaos 13:34, 20 January 2008 (UTC)

It would be good to hear your opinion on the compromise proposals as well. Also, seeing as you were the only one opposing the move to GeoHack with an actual reason, what do you think of the usability of the page now that it's more organised and much of the distracting text is gone? --Para (talk) 00:22, 21 January 2008 (UTC)

I don't even understand the compromise proposal - if someone can explain it to me, I can offer an opinion on it. Meanwhile, between 100 and 200 instances of Mapit-AUS have been converted amateurly to manual links to mapping services by other users who think the changes are errors - so the evidence is that users clearly want the links at the bottom and not from some less-than-obvious page less-than-obviously linked. Orderinchaos 12:54, 22 January 2008 (UTC)

The proposal was that Template:Mapit-AUS-suburbscale and Template:Geolinks-cityscale would be reverted to their external linking state, changed to display inline coordinates or none at all, and {{coord}} added to all the articles using the templates. The other geolinks templates would be subst'd in articles to use {{coord}} directly and without the external links. Individual article editors could then choose whether the remaining geolinks uses are necessary in articles or not. I am however not thinking so highly of this proposal anymore...
Wikipedia is written for the readers, and this whole issue being based on principles, we don't need to give way to the ignorance of editors who have been working on Wikipedia for a long time and are used to seeing external map links in articles. They do many things that are against Wikipedia guidelines, such as add direct links to Amazon for more information about a book in a book article, instead of or in addition to ISBNs (see for example A City In Winter, A Corner of the Universe, A Dance with Dragons, A Dancing Bear, A Forest Apart, A Funnier Approach, A History of Christianity (Paul Johnson), A History of God, A History of Knowledge, A History of ?, A More Perfect Constitution, A Quiver Full of Arrows, A Random Walk Down Wall Street, A Rebel Life: Murder by the Rich, A Slight Trick of the Mind, A Swift Pure Cry, A Theory of Fun for Game Design, etc). They can simply be instructed on how these references to external services are given on Wikipedia and reverted, if they don't read the article the way an unbiased reader would, by seeing that the set of numbers are coordinates, that links on Wikipedia give more information about the linked topic, and that the tooltip confirms all this. Could you point people to the conversion evidence, so that an orientation project could be started for the old timers and also for the newcomers who don't know how to insert coordinates yet?
Also, again, how is the linked page less than obvious, and how can it be improved? You mentioned that the page may be difficult to use for visually impaired people, but there have been changes since your observation. Is this still the case, and why? --Para (talk) 15:10, 22 January 2008 (UTC)

The big blocking point surrounding this project is that there are no editors making bold moves. The stuff in the sandbox stagnated for half a year with little change. We need to standardize on appearance so that readers (who vastly outnumber editors) can expect the same interface on each article. And the standardization should extend to the markup level so people don't have to support the 3 or 4 coordinate schemes when parsing pages. I think geolinks should be removed from the external links section moved to the title with {{coord}} and tread like any other meta-data information. And I'm sure that this viewpoint is disliked but it'll ultimately be better for Wikipedia, just like the Ambox was. — Dispenser 00:23, 23 January 2008 (UTC)

I agree that it's for the readers, but from there we seem to take opposite views. I'd argue that it's not at all obvious to readers that if they click on some numbers that it's going to take them somewhere. The new version of GeoHack is certainly a big improvement, I might add - cutting all the text was a great move, I was actually able to find Wikimapia on the first screen (probably the link I use most consistently along with the street-directory one for Australia). If we could find a compromise which tells readers what they'll find if they click on the link, and at least where desired, renders as dms (as the present geolinks for Australia does), we might just have this one sorted out. Orderinchaos 13:54, 24 January 2008 (UTC)

The instructive and non-printable "(click for maps)" text after the coordinates, mentioned at #CLICK ON COORDINATES, would suit there just fine, wouldn't it? I don't think it's necessary, but wouldn't oppose if such a thing was added to Template:Geolinks-start and all the geolinks uses then substituted in articles to coord level using all the parameters the current templates call it with. --Para (talk) 20:40, 25 January 2008 (UTC)

References for geographical features

There's a discussion at Wikipedia talk:Citing sources#References for geographical features on the use of references for geographical information, for example with coordinates. Comments would be appreciated. --Para (talk) 23:10, 8 January 2008 (UTC)

A similar discussion on map links generally, excluding reference use, is now at Wikipedia talk:External links#Issues with inclusion or exclusion of map service links. --Para (talk) 17:07, 2 February 2008 (UTC)

Really strange how many emotional responses you get, just for cleaning up the map link mess. I wonder if you cleaned out someone's link farm. -- User:Docu

Indeed. It may be a personal issue with argumentation styles or just a downside of the difficult process of improving the deeply rooted status quo in a consensus driven environment. I have been somewhat busy lately and unable to keep on pushing the project goals on various pages – could someone else step in please? --Para (talk) 17:52, 25 February 2008 (UTC)

"Various pages"? Where have the discussions scattered to now? -- SEWilco (talk) 17:57, 25 February 2008 (UTC)

The latest is on Wikipedia talk:External links#Edit warring again on external links to map services, but other similar discussions and possible disputes related to other guidelines can sprout anywhere. WikiProjects generally seem to be shunned by the rest of the community when something is questioned, so even though we do a lot of work on projects for coordinating and organising articles, we'd need to better spread those ideas and knowledge on related pages, and watch for any developments. Would it be useful to have a list of Wikipedia project pages where geographical coordinates are mentioned, so that geo-participants could keep an eye on them and help other well-intentioned editors from going astray? Or should we wait for something like mw:Extension:Labeled Section Transclusion? --Para (talk) 19:25, 25 February 2008 (UTC)

I saw that WP:BRIDGES has a list of articles about types of bridges, and some article talk pages have this project's template on them. But stuff like WP:EL perhaps would belong in a "Related topics" list. -- SEWilco (talk) 20:00, 25 February 2008 (UTC)

I had noticed the EL discussion after about the fourth page of text appeared. The focus of the discussion began diffused and quickly scattered. -- SEWilco (talk) 20:43, 25 February 2008 (UTC)

GeoHack renaming

We're moving GeoHack to Stable Toolserver and we are looking for suggestions/consensus(?) for a better name. —Dispenser (talk) 01:57, 9 January 2008 (UTC)

GeoHack is a good name. Let's keep it. -- Karada (talk) 17:23, 14 January 2008 (UTC)

Too fragile!

Can someone tell me what is wrong with this:

{{coord|50|56|40|N|1|22|2|W|display=title|region:GB|type:landmark}}

Before anyone says "use underscores" (a hack that does not appear in a single example anywhere):

{{coord|50|56|40|N|1|22|2|W|display=title_region:GB_type:landmark}}

Doesn't render in the page at all, and does NOT present an error . Excellent, clearly exactly what the user wants. Wait, I know, it should be:

{{coord|50|56|40|N|1|22|2|W|display:title_region:GB_type:landmark}}

Nope. Now it displays, but does not appear in the title, which is where it should be.

I can get my coords to work about 10% of the time "out of the box". This is not good enough. I already have a physics degree, I shouldn't need another to get a template to work!

Maury (talk) 17:18, 14 January 2008 (UTC)

Maury, try this instead:

{{coord|50|56|40|N|1|22|2|W|display=title|region:GB_type:landmark}}

and it should work. The underscore-separated syntax for the final optional parameters (region, type, and source) is a historical accident of the way the template and geographic URL processing code evolved: one day it will be fixed, but not now. -- Karada (talk) 17:21, 14 January 2008 (UTC)

Can you:

1) reduce the exact syntax to a single statement?

2) put this in the template page?

Thanks!

Maury (talk) 17:25, 14 January 2008 (UTC)

Trouble getting it to work

Could someone look at Category:Wikipedia requested photographs in Minnesota and tell me why only a small fraction of the locations show up on the "map of all coordinates"? I can't even find a pattern in the ones that work as opposed to the ones that don't. Thanks.--Appraiser (talk) 22:56, 15 January 2008 (UTC)

That map link uses coordinates from previous database dumps, so the pattern for inclusion is the date when the coordinates were added to the articles and which coordinate template was used. If they were added after the creation of whichever database dump the Wikipedia-World project is currently using, or if they were added using something else than coord or coor *, they probably won't be visible. Ways to make this work better are to contribute on wikitech-l with ideas on how to make the English Wikipedia database dumps not fail most of the time, or maybe to change the toolserver links the coordinate templates create so that the live external links database could be used to find which of the many coordinate links in articles are for the title (or infobox). --Para (talk) 04:31, 16 January 2008 (UTC)

OS grid refs to co-ordinates

I do hope someone can help me. Is there a template which, with the input of OS grid refs, will produce the coord thingy on an article? I ask because I have noticed a lot of articles lacking coord but for which I do have the OS grid refs. Thanks, DuncanHill (talk) 12:48, 17 January 2008 (UTC)

Templates {{Oscoor}} and {{Gbmapping}} can be used to link to map sources from grid refs.

For conversions to degrees latitute and longitude, which you can then put into {{coord}} and friends, use Streetmap [1], and then follow "Click here to convert coordinates" at the bottom of the page once you've got a map -- this will give the right conversions, unlike the routines used by the WP templates, which are slightly wrong, and may give lat/longs about 200m out. Jheald (talk) 13:23, 17 January 2008 (UTC)

So that's a "no" then? DuncanHill (talk) 13:54, 17 January 2008 (UTC)

They don't do simplicity on this page! My bet is it's a "maybe", though I am not expert at translating geo-speak :) Sarah777 (talk) 14:23, 17 January 2008 (UTC)

There is no such word as no! I have written a tool that I use to do the conversion and generate a template that can be places after the grid reference. See here os gb to wiki tool. It is being used by User:Mjroots in his work on watermills in Kent. See page River Teise.

This is not the final solution-

• it does not have the precision I require,
• duplicating a common wikipedia conversion error-
• it does not back convert the gridreference if you tweak the lat/log
• and I am sure in the future, there will be a policy decision that requires a bot to change ::them- but it is fit for purpose, and essential for some old UK reference books.

Please use and enjoy- and talk to me about any improvements needed

So from TQ 7334 6963 51°23′55″N 0°29′32″E ClemRutter (talk) 14:39, 17 January 2008 (UTC)

That's definately a step in the right direction Clem! DuncanHill (talk) 14:43, 17 January 2008 (UTC)

While it might be possible to implement such a complicated conversion using parserfunctions, all coordinates on Wikipedia should be WGS84 first, and other local systems second. I don't see a problem in mentioning local references on pages as long as the globally used one is shown in its usual place as well. User:The Anome has converted OS grid references to WGS84 before as well, keeping the reference in the coordinate template and in article text instead of just replacing it and forgetting the source reference. If his conversion code is indeed correct, then the bot run should just be repeated for all the articles with new references.

ClemRutter, when your tool gives correct results, you should consider making it work in redirect mode to be able to replace User:RHaworth's slightly erroneous tool in the oscoor templates, and possibly install it on the toolserver (since the tool's current host seems to be unresponsive at the moment). --Para (talk) 20:15, 17 January 2008 (UTC)

Gladly. Analysing the error is now high on my todo list. I am open to any suggestions, for improvements or additions- and tips! Accuracy, is a fascinating subject, but the more I research it- the more pitfalls I find. I know where the problem lies with both my code and [[User:RHaworth]- I need to sit down and write it- and then test it against some known reference points. These are difficult to find- for when you bore down- you find that usually they are derivatives of a conversion algorithm (someone elses code) that in itself has not been proven! Il'l start later today!

ClemRutter (talk) 00:03, 18 January 2008 (UTC)

Guys - I have no idea what you are talking about but it sounds damned impressive. Let's do it! Sarah777 (talk) 01:59, 18 January 2008 (UTC)

Thanks Clem, that is a great tool Cosnahang (talk) 10:30, 18 January 2008 (UTC)

ostowiki.hthl tool Things have moved on. I have ditched almost all my code- particularly the work by User:RHaworth as it was only doing a transformation from from the Grid to OSGB36 latitude and longitude- the mention of Helmert transformation to WGS84 was a memo to himself that this was the point it should be inserted. I have taken Paul Dixons code, and patched in a frontend. I have found the Ordnance Survey site and they provide Ordnance Survey Definitive Transformation Tool with OSTN02 so I can compare my accuracy.

• Using my reference point in Barnards Castle- the former tool was 99m/15m out, new tool 0.5m/1.1m out- so the accuracy is now well within the surveying limits of +7m. It is just possible that the new code is derived from the actual OS code so masking the error- but they are the guys that print the maps so I think that is now cracked. In junking so much of the former code, the UI is not as smooth as it was, so that needs to be worked on. It likes running on a 1024x768 screen at the moment.
• But tell me what you want.
• There are a lot of pages that will need redoing
• But a bigger issue is that the GeoHack transformation seems to be following the old level of accuracy, and any of the UK maps derived from the grid code there are inaccurate to the tune of 100 m (I believe- someone needs to test so we know).

So from TQ 7334 6963 51°23′57″N 0°29′26″E and no longer TQ 7334 6963 51°23′55″N 0°29′32″E ClemRutter (talk) 02:15, 21 January 2008 (UTC).

I have put in some more work on my :ostowiki.html tool and added a lot more features, including user defined output tags, a way of adding parameters to the :en: coord tag, and a rudimentary 'freetext' input method. In particular it will now read a location tag from commons and extract the lat/long, which will back convert into a gridref. This then will generate any tag we need. Output formatting has been tweaked. Could people please test it a little (ie try to break it!) and give some feedback.ClemRutter (talk) 12:21, 16 February 2008 (UTC)

Buildings

Should notable buildings (eg., museums, railway stations etc.) have coordinates? DuncanHill (talk) 11:09, 18 January 2008 (UTC)

Yes. But please make sure the lat/longs are right. (eg check the link you get through to WikiMapia) -- wrong coordinates may be worse than no coordinates. Jheald (talk) 11:21, 18 January 2008 (UTC)

As I can't seem to find any clear and understandable instructions about co-ordinates I shall confine myself to adding the locateme request on talk pages, and OS grid refs on articles (which I do understand and can use with a high degree of accuracy). DuncanHill (talk) 20:07, 18 January 2008 (UTC)

Problems

I found some issues on templates and articles involving the coordinates and I listed them here. I wasn't sure how to fix these. : User:Spencer/Coordinates Issues. Spencer^T?C 15:11, 26 January 2008 (UTC)

Japanese map services - Tokyo datum

I was looking at Template:GeoTemplate for Japan, and noticed that there are 6 services where we have no conversion support, but only a warning that the links will be wrong. The error is considerable with landmark scale objects, and so makes them unusable for Japanese locations. Even the Japanese GeoTemplate contains the same services, but they haven't had the list for very long yet. I found an old request from User:? for the conversion with a couple of links to conversion parameters, and I also found a Perl module Location-GeoTool-2, which seems to be able to do the conversion. Anyone fancy implementing it in PHP so that it could be included in GeoHack? People have been working on coordinate system conversions lately here, so maybe this request will catch on this time. --Para (talk) 23:19, 26 January 2008 (UTC)

I was curious to see how well the Perl module works, and put it on the toolserver as a redirector. Looking at a couple of articles of Japanese locations, the services using Tokyo datum are now giving roughly the same location as the WGS84 services. Can people test it around the country and say if it should be kept and/or ported to PHP? --Para (talk) 20:41, 28 January 2008 (UTC)

Clashing templates

Two templates are clashing at the top of Príncipe. Could someone fix please? Carcharoth (talk) 18:42, 27 January 2008 (UTC)

 Done --Para (talk) 18:50, 27 January 2008 (UTC)

Tornado recentism

I joined the flurry of recentism at February 2008 tornado outbreak and added coordinates to the tornado collection. Comments on this usage:

• I don't know if we need to display coordinates within such a list (maybe I should have used <ref>?).
• I had to enter each city and its name manually (I could have used the category membership option but that's not updated dynamically and at least one article is protected so I couldn't add a Tornado-n category).
• I had to include the state in the names because the Google Maps menu doesn't group by state.
• I didn't have coordinates for some cities handy so had to use county coordinates (labeled as such).
• Some entries were in a direction from a city, or between two cities; I simply used the city coordinates (close enough for news report sources).
• Maybe someone will update the coordinates with actual touchdown locations, but we don't support a path so coordinates will be approximate.
  • I see coordinates to one hundredth of a degree are given in the Storm Prediction Center initial report. -- SEWilco (talk) 18:17, 6 February 2008 (UTC)
• -- SEWilco (talk) 06:41, 6 February 2008 (UTC)

City coordinate formats

While looking at various towns I noticed many use a format such as:

Scottsville is located at 36°45?5?N, 86°11?34?W (36.751504, -86.192692)[2].

The first coordinate uses {{coor dms}} formatting, the second is unlinked. I see the linked GeoHack page shows the coordinate in both DMS and decimal formats, so perhaps showing both formats is no longer necessary. Or are both formats considered essential? (I noticed only one format, DMS, is presented in Memphis, Tennessee.) I don't know where the dual format was previously discussed. -- SEWilco (talk) 18:42, 6 February 2008 (UTC)

Coordinates should be entered only once, but is this related to some measurements being shown in two different units? Decimal and dms are in the same system though, so would it really be necessary to work on making the template display it twice, and when should it be displayed twice? Some people are adamant on the choice of coordinate input and/or output format, and I don't see a way to ever find a common format there. That may also depend on the sources where the coordinates are from. Some of Wikipedia's coordinates can now be shown in the other format depending on user css, but that's only for registered users in the know. If MediaWiki and Wikipedia handles coordinates one day and has a setting for it in preferences, it still leaves the anonymous users with inconsistent display. For now I think the unlinked ones can be removed, whichever format they're in. --Para (talk) 22:29, 8 February 2008 (UTC)

Aha. The Scottsville data was created by Rambot, so that is its standard format. I asked Ram-Man. -- SEWilco (talk) 05:23, 9 February 2008

(UTC)

I know this is off topic, but could someone answer this innocent question. What has been tagged? A 6 dec place reference, such as Scottsville gives sub metre accuracy. I zoomed in on the Scottsville example, and Google maps points to some open space between the town and the bypass. If this were a French commune, it would be easy; I would tag the Mairie (Town Hall) and more specifically the centre of the door on the principal entrance, using the WGS84 datum. Has anyone made a decision (policy). Working at the moment on datum conversion and an article where latitude and longitude is important, I am actually using some of the infobox, title and inline tags and many of them are out by many kilometres. I could fix them in passing, were I to know what point of the town to tag. Candidates for consideration: Town Hall, Cathedral (west door, or high altar), town hall, castle, where Eastgate crosses Northgate, Bridge. ClemRutter (talk) 10:00, 18 February 2008 (UTC)

Rambot probably got the coordinates from Census Bureau info. The coordinates are probably the exact location of a survey marker which had some significance at the time it was made, or the geometric center of the city boundaries. This location is near a cemetery and is in a large oddly shaped area, so I suspect this is the site of the original city hall or church (probably now a park or redeveloped along Highway 100). -- SEWilco (talk) 17:33, 18 February 2008 (UTC)

If the coordinates came from the Census Bureau, then the coordinates are calculated to represent the approximate center of a polygon formed by the municipal boundaries. Depending on how irregular the boundaries are, this can produce various distortions. I find coordinates from GNIS are more typically closer to some human-recognizable point, such as the city hall or some other landmark such as the main crossroads. older ? wiser 18:10, 18 February 2008 (UTC)

So- that said- do we manually correct this when we find its someones vegetable plot? Do we leave it? If we correct it- what do we look for town hall, cathedral or a prominent turnip? ClemRutter (talk) 13:17, 20 February 2008 (UTC)

For GNIS official naming: "The Primary coordinate values for communities are taken at the center of the "original" community meaning the city hall, main post office, main intersection, etc. For other areal features, coordinates are taken at the approximate center, and for reservoirs at the dam." [2] There probably is other guidance somewhere in USGS documents. Or just ask the http://geonames.usgs.gov/ database for a coordinate. Ram-bot was driven from Census data, and that organization likes to use polygons. Another way to find coordinates is to see if there is a U.S. National Geodetic Survey benchmark at the location and look up the number in the Survey's records or browse the map at [3] — you might notice there the GO TO coordinates aren't all at benchmarks (I suspect they're GNIS coordinates). -- SEWilco (talk) 16:52, 20 February 2008 (UTC)

Brief project history and geotagging

I'm looking for a brief WPGEO project history. Information about when it started (Feb 2005?) and some basic information about the geotagging process. When was the first article geotagged, etc. Thanks. --Drh08 (talk) 05:50, 18 February 2008 (UTC)

Rambot is well known for creating and updating many city articles, and it inserted geographical coordinates in many articles such as the above mentioned Scottsville edit: (diff). I could extract some other dates from article histories, but maybe we'll get some history from others. The more official standard-following geotagging is much more recent. -- SEWilco (talk) 06:01, 18 February 2008 (UTC)

Adding categories

Resolved

 – Proposal withdrawn Zab (talk) 17:48, 23 February 2008 (UTC)

I am proposing an addition to the Template:coor dms family of templates. A discussion has begun here. Note that I do not want to change functionality, just add additional functionality. I have written the code myself and would modify the documents myself. Also, note that I am aware of Template:coord, but have not yet tested any mod for it.

My idea is to add categories similar to Category:Places near 32°N 144°W or Category:Places near 21°N 0° to any article using Coor templates. The coordinate is rounded off to the whole degree. Values 0 and 180 for either latitude or longitude are categorized without their N/E/S/W component.

This would not conflict with geo-mapping features. In fact it may compliment them because positions would be available via the WP:API, exposing new possibilities to developers out there. Also, the addition would be transparent to most users, useful to most who notice it, and won't bother the rest. It would be a predefined scheme, so it would not violate WP:CAT/WP:OCAT. Finally, most of the work is done, so all that is really needed to make it happen is your approval.

Thank you for listening. Zab (talk) 04:45, 20 February 2008 (UTC)

As he mentions in the template's talk page, the category coding will only work with dms templates, and not with {{coord}} decimal coordinates. -- SEWilco (talk) 04:08, 22 February 2008 (UTC)

Proposal withdrawn per final discussion at here. Zab (talk) 17:48, 23 February 2008 (UTC)

Why must coordinates be on compulsory display?

I'm new to this project so this query may be off base. My question is: Why must the coordinates be compulsorily displayed? My guess is that most people are becoming familiar with the idea of a way point but don't actually read the coordinates or have any interest in what they specifically are. What they are actually interested in is that if they click on the waypoint they get to see a map or satellite picture.

This is particularly an issue if you are displaying way points in a table. Showing coordinates produces a lot of useless clutter to the point of visual pollution, and either reduces the effective table width for other information, or requires each entry to extend over two or three lines. You lose out every which way, with next to no gain.

An example of this can be seen at Coastal fortifications of New Zealand, which has way points in tables. Here I have entered the way points in a non standard way, without coordinates to avoid clutter. Someone has come along and – quite correctly the way things stand – changed them so they show the coordinates. Well he got halfway down the page before stopping. So if you look at the tables in the top half and then the bottom half you can see the comparison. --Geronimo20 (talk) 20:15, 27 February 2008 (UTC)

Thank you for your suggestion regarding Coastal fortifications of New Zealand. When you feel an article needs improvement, please feel free to make those changes. Wikipedia is a wiki, so anyone can edit almost any article by simply following the edit this page link at the top. The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes — they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills. New contributors are always welcome. You don't even need to log in (although there are many reasons why you might want to). Zab (talk) 20:35, 27 February 2008 (UTC)

I used a template for this response that conveyed the wrong tone. I apologize for coming off so bluntly. Zab (talk) 20:57, 27 February 2008 (UTC)

I suspect the main driver for the change someone is making to the page is that your preferred waypoints are implemented as hard coded links to tools.wikimedia.de/~magnus/geo/geohack.php - always a risk at the time that the service is due to move and be renamed. Like you I think blanket provision of templates which regurgitate co-ordinates, as all listed at Wikipedia:Manual of Style (dates_and_numbers)#Geographical coordinates appear to, limits our choices in situations in which a link to a mapserver is desired, and display of coordinates is not. My view is that there are two discussions arising:

• Do we require coords to be displayed in tables such as those in Coastal fortifications of New Zealand?
• Is there a way of using {{coor}} & {{coord}} so as not to display coordinates but merely an anchor for a link to the mapserver, and if not, should there be a template / option to do this? --Tagishsimon (talk) 21:03, 27 February 2008 (UTC)

No if you use {{coord}}. Yes, if you use the deprecated {{coor}}, e.g. {{coor|59_55_N_10_44_E|click here for Oslo}} gives {{Coor|59_55_N_10_44_E|click here for Oslo}} --Dr Greg (talk) 13:21, 28 February 2008 (UTC)

I stopped halfway down because it was getting late and I was doing the conversion manually. My motive was because the article looked like a prime candidate to have the {{GeoGroupTemplate}} on it, which I had only just discovered. The template worked, but gave the points rather bland names. My primary objective in formatting the links was to use {{coord}} so that I could give the points on the map meaningful names. --Scott Davis ^Talk 14:27, 28 February 2008 (UTC)

I find the display of coordinates most useful when printing out an article. It's very useful to be able to print the article and take it with me to another location. Displaying the coordinates as default behavior is also more universal - those who don't understand them can ignore them; those that need them, have them. Some of us still need to refer to paper charts, maps, and atlases! I do understand the visual pollution criticism. I just find, in this case, it's necessary information. Good comment and question nonetheless. -- Quartermaster (talk) 15:58, 28 February 2008 (UTC)

There is one tool which changes the appearance yet still keeps coordinates accessible: Footnotes. Coordinates could be included with other notes wrapped in <ref>...</ref> tags, and would appear at the bottom with other notes. Whether that fits with the rest of the article depends upon the individual article. -- SEWilco (talk) 16:19, 28 February 2008 (UTC)

To go back to your original question- I find non-standard systems totally infuriating. I have learnt to drive the //coord// tag system, and when things act in a different manner, some of the techniques I use are broken. For instance, if I am looking for the camera location of an untagged shot- two clicks and I am in Google earth, and hunting, a third click and I have the street names and I am away. Then consistency, I want your article on the fortifications in NZ, to look like my article (not yet written) on the Fortifications of the Medway Towns, and the article on the one on 17th century European fortification techniques (I have the references for this one!). If if you can wait a few days, I'll have a tool ready to help you do the conversion. —Preceding unsigned comment added by ClemRutter (talk • contribs) 18:32, 28 February 2008 (UTC)

So why not a template which appears, perhaps at the top right of the page, as a small control panel with the option to show/hide the coordinates. If you click "hide" the page redisplays with the coordinates replaced by an appropriate clickable icon. When you add the template you set the show/hide default. --Geronimo20 (talk) 19:11, 28 February 2008 (UTC)

The preference here seems to be to use the standard template, so I've finished the switch. I'm happy with the idea of a control or preference about what to do with whether the coordintes should actually be displayed or only be a hyperlink. I did not find the text "wp" to be a particularly helpful label for the links, as was used on that page before I changed it though. --Scott Davis ^Talk 11:29, 29 February 2008 (UTC)

Wikipedia should be useful offline as well, in print or in environments where the map services don't work or just aren't available, so hiding useful information in links wouldn't go together with that goal. I agree though that coordinates can be very cluttering, especially inline breaking the flow of prose, but sometimes within tables as well. Is it the display location that needs work, or is it just too much information? Then it's a question of importance: if you don't want everyone to be able to use the information, is it really important enough for inclusion? --Para (talk) 00:41, 11 March 2008 (UTC)

I set out my POV clearly. I am addicted to //coord//. When I am working on a topic, I click on the //coord// and zoom in on Google Maps so I can see immediately area. I print out topics with the //coord// before I make a car journey- and photograph any point mentioned. But this topic is interesting:

• I don't think the table is displayed in the optimum way.

Battery	Name	Way point	WWII Ordnance	Range (miles)	Dates	Notes
60	Motutapu Island	36°45′03″S 174°55′09″E	3x6in Mk 21 guns 2xCASLs	13	1936 -1945	Consisted of a battery, camp, gun emplacement, pill boxes and US naval magazines. Its remains are administered by DOC.
61	Bastion Point [Russian scare]	36°50′43″S 174°49′29″E	2x12pdr gun Twin 6pdr guns 3xCASLs	8	1885-
61	Great Barrier Island		6in Mk 7 gun 4in Mk 7gun 4x40mm Bofors	12
61	Manakau		1x4.7in gun	6

I would put the //coord// in with the name.

Battery	Name	WWII Ordnance	Range (miles)	Dates	Notes
60	Motutapu Island 36°45′03″S 174°55′09″E	3x6in Mk 21 guns 2xCASLs	13	1936 -1945	Consisted of a battery, camp, gun emplacement, pill boxes and US naval magazines. Its remains are administered by DOC.
61	Bastion Point 36°50′43″S 174°49′29″E	2x12pdr gun Twin 6pdr guns 3xCASLs	8	1885-	[Russian scare]
61	Great Barrier Island	6in Mk 7 gun 4in Mk 7gun 4x40mm Bofors	12
61	Manakau	1x4.7in gun	6

• It occurs to me that the table is over formatted- and will render differently on different browsers.

• My second point is the use of the word Waypoint. It is not a word I have ever used Waypoint says it is a modern word but this is an article without references. Looking at its etymology: It is a intermediate point on a journey between two destination or Location references. Google reveals it is used by the GPS community- again no reference to origin.ClemRutter (talk) 10:53, 11 March 2008 (UTC)

I think it comes from (sea) navigation, an intermediate point you were aiming for on the way to your final destination, if included as a separate heading in the table, simply "Coordinates" is probably a better name. David Underdown (talk) 12:00, 11 March 2008 (UTC)

Street cred: I spent 4 years in the Navy as a Quartermaster where most of my job was navigation (1983-1987). The term "waypoint" was almost never used. Indeed, we used the term "coordinates" or discussed our "lat lon" which was probably the most common reference for a location. The term waypoint cropped up only in the context of hand held navigation computers (which were new fangled things at that time). You'd input a beginning and ending location, and how many "waypoints" (first time I saw the term) to compute for a great circle track. The computer would give a list of these "waypoints" for laying down on the charts we used for navigation. Since the shortest distance between two points on a globe is not a line, rather, a curve, the waypoints were points on a segmented curve where, when you reached them, you adjusted your course to continue on the optimum track. FYI, we just played with the navigation computer as a toy and never really used it. Easiest way to lay down a great circle track was to use a gnomonic projection chart - on that type of chart you do just draw a straight line between start and end. You then select points along the line, read the lat lon from the gnomonic (polar projection) chart, and transfer them to the more traditional mercator projection charts. Just sharing! Typically we'd adjust our course to stay on the curve about every 12 hours. -- Quartermaster (talk) 12:53, 11 March 2008 (UTC)

Hmm, the suggestion, that the location name and coordinates be displayed in the same column, results in the addition of up to three lines in the display of each battery. This is not so apparant in the snippet chosen since it has only two coordinates anyway. Compared with the way I originally structured the list with the coordinates suppressed, the suggested list is much longer and cluttered with both a dazzle of unsightly coordinates and awkward white space.

But can I reiterate my point since it doesn't seem to have registered here. My point is that most people aren't interested in geographical coordinates; they are interested in the geolinks associated with the coordinates.

Most users just want an easily recognised place they can click on to see a map or satellite picture. The coordinates are displayed there anyway. It doesn't particularly matter when there is just one geolink on a page, but when there is a long list it does matter.

This thread has diverged from the original concern I raised. The discussion now seems to be about how to best display the coordinates, with another thread discussing some remote point of terminology. I feel like my concern is not registering here at all. Scott Davis simply pronounced that there was a consensus for the status quo – the enforced display of coordinates – and proceeded forthwith to convert the rest of the table to display coordinates.

There is an issue of perspective. The article I wrote was about coastal fortifications. When ClemRutter looks at it he seems to see a list of coordinates. That's fair enough if that is his focus and interest, but he shouldn't expect that he can hold hostage articles focused on other things. It's good if the article can display geolinks – but for most users it is unpleasant to be confronted with a clutter of irrelevant coordinates.

The specific coordinates are necessary because they provide the appropriate geolinks, but to insist on displaying them is like insisting that every time we show a link to another web page, we should display the full web address, preferably in numbers. Perhaps in a few years, this techno-insistence on displaying geo-coordinates will be seen as just a primitive stage in their development.

There are other solutions for the occasional user for whom the coordinates themselves are the object of fascination. At the moment the way coordinates are used caters for such occasional users at the expense of the rest.

The solution I suggested was a template which produces a small control panel at the top right of the page with the option to show/hide the coordinates. Click "hide" and the list redisplays with the coordinates replaced by an appropriate clickable icon. When you add the template you set the show/hide default (intended only for lists). What might be the difficulties with this? --Geronimo20 (talk) 22:36, 11 March 2008 (UTC)

But can I reiterate my point since it doesn't seem to have registered here. My point is that most people aren't interested in geographical coordinates; they are interested in the geolinks associated with the coordinates. I want to say this as neutrally as possible: This statement is an unsupported assumption. It may be correct, but until any evidence is presented (a poll?) it, as well as the contrary position, is just an assumption. Until then, I support the more universal, and current, display. It is easier to ignore something that is there, than to see something that is not there. -- Quartermaster (talk)

Where is the downside if you have the option to display the coordinates if you want them? Why support a position that unnecessarily constrains? --Geronimo20 (talk) 23:40, 11 March 2008 (UTC)

The downside is that unregistered users won't see them. And registered users will suddenly have to opt-in to keep the status quo. Without strong arguments this is not acceptable IMO. Registered users do have the choice of hiding the coordinates. Just write a tiny Javascript to rewrite the link text and put it into your monobook.js .--Dschwen 23:49, 11 March 2008 (UTC)

I'd have to see how it worked in practice. If, by a single click, all coordinates could be displayed (and thus, the document when printed would show the lat lon) it wouldn't be that big of a deal. The question would then go back to "what do most people prefer?" The design issue then becomes a choice between:

• A. Display coordinates by default, and make people locate and click link to hide them.
• B. Hide the coordinates by default, and make people locate and click link to display them.

I like to think that the default of displaying the coordinates has an educational purpose, indicating that there is an actual and systematic coordinate system related to physical locations, rather than a magical "click here and you'll go to where you want" approach. Mind you, this is not a "go to the mat" issue for me at all. -- Quartermaster (talk) 23:56, 11 March 2008 (UTC)

Hawthorne, California

Will somebody kindly visit Hawthorne, California and fix the geo tag at the bottom of the page? Sincerely, GeorgeLouis (talk) 03:07, 7 March 2008 (UTC)

Done. -- User:Docu

Some more bad data

Here are some more bad data points, this time encoded as plaintext lat/long coordinates with one or more internal inconsistencies -- please help fix these, so the data miner can capture them correctly on its next pass:

• Óbidos,_Portugal ERROR: bad min/sec value: 39.0 73.0 0.0 N 8.0 63.0 0.0 W -- fixed.
• West_Fairview,_Pennsylvania ERROR: bad min/sec value: 40.0 27.0 25.0 N 76.0 91.0 0.0 W -- fixed
• Huff_Run ERROR: bad min/sec value: 40.0 138.0 34.0 N 81.0 13.0 9.0 W -- bad data removed
• Mafra ERROR: bad min/sec value: 38.0 95.0 0.0 N 9.0 24.0 0.0 W -- fixed
• Hoven,_Denmark ERROR: bad min/sec value: 55.0 85.0 0.0 N 8.0 76.0 0.0 E -- fixed
• JAXPORT_Cruise_Terminal ERROR: bad min/sec value: 30.0 24.0 50.0 N 81.0 34.0 65.0 W -- fixed
• Ladera,_California ERROR: bad min/sec value: 37.0 24.0 360.0 N 122.0 13.0 0.0 W -- fixed.
• Kunkuri ERROR: bad min/sec value: 22.0 -44.0 -35.0 N 83.0 -57.0 -21.0 E -- fixed
• Copiague_Harbor,_New_York ERROR: bad min/sec value: 40.0 66.0 10.0 N 73.0 38.0 49.0 W -- fixed.
• Janitzio ERROR: bad min/sec value: 19.0 57.0 0.0 N 101.0 65.0 0.0 W -- fixed.
• The_Moorings,_New_York ERROR: bad min/sec value: 40.0 71.0 7.0 N 73.0 19.0 93.0 W
• Hope,_Alaska ERROR: bad longitude value: 60.92028 0.0 0.0 N -149.64028 0.0 0.0 W -- minus sign removed.
• 2006_CPL_World_Season ERROR: bad longitude value: 69.0 0.0 0.0 N -28.0 0.0 0.0 E
• Alakanuk,_Alaska ERROR: bad longitude value: 62.68889 0.0 0.0 N -164.61528 0.0 0.0 W -- minus sign removed.
• Karl_Guthe_Jansky ERROR: bad longitude value: 40.365175 0.0 0.0 N -74.163705 0.0 0.0 W -- minus sign removed.
• Akhiok,_Alaska ERROR: bad longitude value: 56.94556 0.0 0.0 N -154.17028 0.0 0.0 W -- minus sign removed.
• Bitis_parviocula ERROR: bad longitude value: 8.0 20.0 0.0 N -35.0 56.0 0.0 E -- minus sign removed.
• Chatto ERROR: bad latitude value: -55.44 0.0 0.0 N 2.36 0.0 0.0 W
• Shavertown,_Pennsylvania ERROR: bad longitude value: 41.306 0.0 0.0 N -75.947 0.0 0.0 W -- fixed.
• Bear_Camp_Road ERROR: bad longitude value: 42.0 39.0 1.25 N -123.0 44.0 54.15 W
• Allakaket,_Alaska ERROR: bad longitude value: 66.56261 0.0 0.0 N -152.64756 0.0 0.0 W -- value in article seems correct (U.S. Geological Survey Geographic Names Information System: Allakaket)
• Portland_Canal ERROR: bad latitude value: -56.0 0.0 0.0 N 130.0 0.0 0.0 W
• G._E._Grumm-Grshimailo ERROR: bad longitude value: 44.0 0.0 0.0 N -90.0 30.0 0.0 E -- just bad formatting, removed hyphen
• Y,_Alaska ERROR: bad longitude value: 62.15427 0.0 0.0 N -149.79892 0.0 0.0 W
• Aleknagik,_Alaska ERROR: bad longitude value: 59.27306 0.0 0.0 N -158.61778 0.0 0.0 W -- minus sign removed.
• Campbell,_Alabama ERROR: bad longitude value: 31.0 55.0 35.01 N -87.0 58.0 50.6 W -- fixed.
• Yellow_Motel ERROR: bad longitude value: 42.0 30.0 24.0 N -86.0 2.0 5.0 W
• Akutan,_Alaska ERROR: bad longitude value: 54.13556 0.0 0.0 N -165.77306 0.0 0.0 W
• Adak,_Alaska ERROR: bad longitude value: 51.8725 0.0 0.0 N -176.62861 0.0 0.0 W
• Gakona,_Alaska ERROR: bad longitude value: 62.30194 0.0 0.0 N -145.30194 0.0 0.0 W -- minus sign removed.
• Akiak,_Alaska ERROR: bad longitude value: 60.91222 0.0 0.0 N -161.21389 0.0 0.0 W -- minus sign removed.
• Navrongo ERROR: bad longitude value: 10.0 53.0 24.0 N -1.0 5.0 24.0 W -- fixed.
• Providence_(comics) ERROR: bad latitude value: 120.0 0.0 0.0 N 165.0 0.0 0.0 W

-- The Anome 23:30, 21 September 2007 (UTC)

Providence_(comics) edit says 120N,165W.[4] Anyone have X-Men #200 handy? (SEWilco 05:14, 22 September 2007 (UTC))

Got it, and confirmed. Source gives location as 120N, 165W. How about defining a label which marks a coordinate as known to be invalid but not erroneous? (SEWilco 00:55, 25 September 2007 (UTC))

Surely typo in source. 20N, 165W fits the description. A parallel in UK locations is a reference 4 furlongs SSW of church which then is 3 or 6 degs out. IMHO Correct it and leave plain text comment to explain.

ClemRutter (talk) 10:22, 31 December 2007 (UTC)

• Blanton Museum of Art ERROR: Incorrect lat/long: Article lists 30.281004, -97.737473 and should be 30.280810, -97.737340 instead (yes, I know that Google Maps & Google Earth shows that to be a parking lot, but their satellite images are old and the WGS84 location in the article is actually the San Antonio Garage (SAG) across the street) -- User:Bradknowles Fri Mar 14 21:45:50 UTC 2008
• University of Texas at Austin ERROR: Non-logical selection of lat/long. Article lists 30.2846, -97.7367, but this is in the middle of some trees next to the Gregory Gym. A more logical location would the same as Main Building of The University of Texas at Austin (30.2861, -97.739321) or maybe Darrell K Royal-Texas Memorial Stadium (30° 17' 01.17" N, 97° 43' 57.06" W) -- User:Bradknowles Fri Mar 14 23:24:43 UTC 2008 —Preceding comment was added at 23:25, 14 March 2008 (UTC)

It is logical if you are a squirrel! I have no statistics to prove it but I believe that about 40% of all articles on things other than a building select a illogical point to label. For towns, I am working on the definition of the centre of the earliest settlement, with that name on that site, but there is an argument to label the mathematical centre of the polygon that bounds which explain why your squirrel was right. In a European city- I then have to ask:which is the centre- the town hall or the high altar of the cathedral- and in my day, the centre of the university was the student union bar rather than the dean's office.ClemRutter (talk) 00:06, 15 March 2008 (UTC)

Geolinks bot replacement

I have prepared regular expressions for replacing the geolinks templates, on Wikipedia talk:WikiProject Geographical coordinates/geolinks replacement. Please review. Especially the templates that have a third parameter need some checking, as the use is very inconsistent. --Para (talk) 02:59, 1 February 2008 (UTC)

Possibly, we might want to convert them directly to de:Template:Coordinate. -- User:Docu

What a wonderful example of the abuse of parserfunctions. It seems about the only advantage of that template is that it parameterizes the arguments sent to geohack. We should be standardize on a single template as to make the parsing hell that is wikitext a bit easier for everyone.

We should when appropriate change to title only and move to the top of the article. The instances when I believe it would be appropriate are:

1. When the article has only no infobox and does not other coordinate templates.
2. When the article contains an infobox but does not contain the string coor, lat[dms] =, lon[dms] =, or long[dms] =
3. The article is a stub

I think this is more useful as coordinates will be treated like the metadata. However, the rules are a little incomplete, on the article Mansfield, Illinois (which has 4 coordinates, btw) a bot add an infobox and removed the title from geolinks. Additionally, there should be an additional bot that converts {{coor dms}} (coor in deg) to {{coord}}. — Dispenser 02:33, 3 February 2008 (UTC)

Conversion of other coordinate templates to a single one was discussed at /Archive 12#Migration to the coord template, and infobox parameter standardisation at /Archive 12#Standardize names for coordinate variables in template namespace. The parameter names got to the list of tags already as well, but Somebody still needs to start the project to actually make Wikipedia content conform to that. --Para (talk) 04:00, 3 February 2008 (UTC)

I agree with the suggested conversion, as its in the line with the single line item people were requesting. As for de:Template:Coordinate, we should probably discuss the template's merits elsewhere. The conversion of {{coor dms}} was rejected earlier. -- User:Docu

The matching and replacement regular expressions seem to be OK. -- SEWilco (talk) 21:00, 5 February 2008 (UTC)

Perhaps we should consider adding more zoom types to geohack? — Dispenser 04:59, 6 February 2008 (UTC)

There's been discussion of that, and probably will be again. For these changes, the only effect with regard to zoom types is whether the bot will keep any unrecognized parameters. Then later editors/bots can use any zoom-related hints to update as the tools change. As with citations, keep all the information and expect Wikipedia's presentation will improve. It is OK for this bot to replace recognized zoom info with new incantations, if it's translating or improving that size info. -- SEWilco (talk) 06:54, 6 February 2008 (UTC)

For zoom types we use in de.wikipedia the parameter dim, which means the diameter of the objekt in meters. Is is important to have a software independent unit. --Kolossos (talk) 13:39, 7 February 2008 (UTC)

Yes a standard zoom definition would be nice, but please start a new section if you want to now discuss modifications to GeoHack. This section is discussing conversion of coordinate incantations to the present version of coord. I was pointing out that this conversion should avoid losing scaling information which may be needed later by scaling improvements. -- SEWilco (talk) 16:01, 7 February 2008 (UTC)

So if the replacement regex is fine, can someone volunteer to run a bot on all the articles using the templates? Until that is done and there are examples, documentation, and the templates still work, we will continue to see reusable data degenerate into non-standard form, such as here. To help the transition in editors' minds, I think after replacement the geolinks templates could be made to output a big fat notice like "Please replace this template with {{coord|...}}" using the correct parameters derived from the used geolinks template, so that people wouldn't have to go to documentation to use the new template, but they could learn from the example. --Para (talk) 15:39, 18 March 2008 (UTC)

{{Locateme}}

I don't believe the {{locateme}} tags are currently of any use whatsoever, since they are not visible in the article itself, and thus fail to stimulate drive-by geotagging.

The major objection to {{locateme}} was that it looked like a warning message, and got in the way of editing. Unfortunately, fixing this by moving the {{locateme}} tags to talk pages also eliminated any usefulness the tags once had.

Instead, I'd like to propose something like a {{geolocation-stub}} template, placed at the bottom of the article and formatted in the same way as other stub notices, saying something like "this article about a location does not have geographic coordinates: please add some". I could then use my bot to add these to use this to tag only those articles which (a) it can recognize as being about geographic features, and (b) are not currently tagged, and (c) cannot be automatically matched to features listed in the GNS database.

Since the majority of new place articles can already be tagged by the bot, this new tag would thus only be added to a much smaller number of articles, where human attention could best be devoted to solving problems which cannot easily be solved by brute-force pattern matching, rather than wasted duplicating work which could be done by a machine.

This would then allow the removal of all the redundant {{locateme}} tags from talk pages.

-- The Anome (talk) 09:59, 19 March 2008 (UTC)

The idea's a good one, but I've moved the template to {{No geolocation}}, since it clearly isn't a stub template and would likely cause confusion with the nqame you suggested. Grutness...wha? 00:38, 20 March 2008 (UTC)

The placement and size of locateme type messages was discussed at length in Template talk:Locate me a while back ... meanwhile I support {{No geolocation}} and The Anome's scheme. It's worth remarking that I do from time to time use the categories populated by locateme to add coords to articles, so "any use whatsoever" is shot down in flames.

If we are to encourage drive-by geotagging, I think we need to work on some basic geotagging help text pitched at newbies. I find the documentation on Wikipedia:WikiProject Geographical coordinates and {{Coord}} discouraging, and I think we lack a basic "how to", one which might wibble on about the use of multimap or your own favoured mapping system as a means of discovering coordinates, and provide succinct advice on the use of one of the templates - coord, for instance. but I don't have the energy right now to launch into writing such a thing, even did I understand fully, or believe in, some of the parameter nuances. --Tagishsimon (talk) 00:53, 20 March 2008 (UTC)

Adding coordinates is such a specialised task that it's unlikely to be done by drive-by readers who are otherwise not interested enough to improve the article and go to the talk page to see what might be up. After them there's the average editors, who might as well take example from other location related articles and notice that the article they're working on isn't as good because it doesn't have coordinates yet. Other editors can find articles needing coordinates even with just simple categorisation without any templates needed, and I think that's enough as a request. Stub notices may be important since in that size an article isn't worth much and invites people to write more, but the addition of a small detail like coordinates isn't going to improve the article a whole lot and is therefore an excessive maintenance request in article space. This type of templates have previously been discussed on Template talk:LocateMe and Template talk:LocateMeText (where the template matches this new one of yours). The only use I can think of for such a request is in articles about locations that only people local to the area could find, but are there really that many of those? --Para (talk) 01:01, 20 March 2008 (UTC)

Concur — it would probably be better suited to a category, so as not to clutter the articlespace with maintenance messages that, frankly, are not crucially important. --Wikiacc (°) 01:19, 20 March 2008 (UTC)

My motivation for this is to guide manual taggers to those articles which cannot be geolocated by automatic processes. I'm currently tagging every article I can match automatically with my bot, but there are still plenty of needy articles which cannot be tagged automatically, either because data is unavailable, or because the article-matching heuristics cannot match the articles and data sources together unambiguously.

I can easily identify these needy articles by traversing the category graph, and apply whatever tags or categories may be appropriate. However, I want to avoid a repeat of the {{Locateme}} fiasco, so I'd like to get a consensus first, before I start to tag thousands of articles for attention.

Reading the comments above, I think categories are probably the least contentious way to go. I'd like to suggest that the categories should be broken down by country and type, leading to categories such as Category:Railway stations in Spain without geodata. This should lead to smaller categories, and attract users who are interested either in those specific types of features, or with specific interest in that country. Smaller categories will also encourage completists (in the example above, Spanish railway enthusiasts) who are interested in sorting out all the entries in a category just for the pleasure of doing so.

The above category would in turn belong to two parent categories, Category:Railway stations without geodata and Category:Locations in Spain without geodata, and finally both of the above would be children of the master category Category:Articles without geodata. This category hierarchy would also serve to attract domain specialists ("I've done Spanish stations, now what about France?").

If no-one has any objections, I can start rolling out a trial run of this out more-or-less immediately, since my bot has nearly all the code to do this already written.

I'd welcome any comments, and in particular any suggestions for improvements. -- The Anome (talk) 13:04, 20 March 2008 (UTC)

Categories would be fine for this purpose, but looking at Wikipedia:Categorization#Maintenance categories and the the subcategories of Category:Articles needing coordinates already being hidden, the categorisation would mostly serve people who already know of their existence, leaving the drive-by geotaggers out. In that sense it would be worse than the current talk page requests. It's a shame that MediaWiki doesn't do category intersection yet, and that every project trying to improve articles in an organised way will have to recreate the existing category structure related to their domain. Category:Wikipedia requested images for example has done this with photo requests from specific locations, and category duplication seems to me like a wasted effort.

While waiting for category intersection, would it not be better to continue tagging talk pages with coordinates requests, and in them provide a link to a toolserver tool-to-be-developed that traverses the category tree with the requested domains and gives an intersection with coordinate requests? Choosing other categories to intersect with could be aided by editor provided categories like with {{Reqphotoin}}, or automatically discovered geographical categories the article is in. With such a limited use tool performance wouldn't be an issue the way it has been for introduction of the feature Wikipedia-wide. This would allow people to easily find requests from a specific area, and advertise the possibility on various talk pages for new editors to notice. --Para (talk) 15:00, 20 March 2008 (UTC)

What is wrong is the hiding of the categories. Yes, there are numerous project-specific maintenance tags that belong on talk pages, but tags and categories intended to be picked up on by casual readers must appear on the article itself, or they are effectively useless. We're here to write an encyclopedia, and if the efforts to keep pages pretty and clean of extraneous tags are preventing progress towards this goal, they are harming the encyclopedia and should cease. Applying Wikipedia:Categorization#Maintenance_categories to this is a bad idea, and should simply be ignored if we are to make any progress on this matter. (See my comments on Wikipedia talk:Categorization.) -- The Anome (talk) 00:37, 21 March 2008 (UTC)

I believe it was I that brought up the original problem on TheAnome's talk page. I agree...having the tags on the talk page is highly annoying. I support the trial run suggested above. I completely agree with TheAnome with the hiding categories in this matter. Spencer^T?C 19:15, 21 March 2008 (UTC)

I very much disagree about the category. There might be some rationale for an unobtrusive tag indicating the lack of coordinates. But I don't see a strong case for displaying the maintenance category. Persons interested in fixing groups of such articles will be able to find the category with a minimal amount of digging. Casual passers-by will not care and the presence of the maintenance category will only clutter the article. older ? wiser 19:36, 21 March 2008 (UTC)

Thanks for all the comments! In the light of your responses, I propose the following:

• a small stub-notice-like tag
• at the bottom of the article
• that links to a user-friendly how-to-geotag help page, as well as to the edit link for the article
• and has two parameters: country and object type, allowing the tagged article to be placed in (hidden) maintenance categories, but also allowing this structure to be refactored as desired if necessary
• and that this should be, like stub notices and other tags that are intended for the general reader an explicit exception to the policy of not putting maintenance tags in articles

So, for example, an article about a Spanish railway station would be tagged with

{{no coordinates|railway station|Spain}}

Does this sound reasonable? -- The Anome (talk) 12:03, 22 March 2008 (UTC)

Seems about right. You're proposing a geolocation stub marker, similar to existing article content stub markers. Links to the hidden maintenance categories should be in the how-to-geotag help page and in this project's page; the former helps contributing readers find more such locations stubs while the latter helps project participants find the same stubs. I think there is an existing how-to page linked on the project page. -- SEWilco (talk) 15:18, 22 March 2008 (UTC)

This seems good. Btw, should I remove some old {{locateme}} tags from articles with coordinates that Anomebot added? I'll start, unless it messes this up. Spencer^T?C 17:49, 23 March 2008 (UTC)

Automatic archiving

While I was adding an archive index, I added 180 day automatic archiving. -- SEWilco (talk) 15:52, 22 March 2008 (UTC)

Geotagging Roads

While following the discussion above- I found Categories of Geographical articles needing coordinates. Many were roads for exampleWatling Street. How do you tag this? So I looked at Roads in UK that had achieved GA status. A500_road has no geotag, and the A1 road (London) is tagged as {{coor title dms|51|34|40|N|0|08|45|W|region:GB_type:landmark}} . So is this the a approved way to do it? A little inspection shows it is a random point close to the road, 5 miles from its origin in the city. So what is the logic here. The tag was placed at the bottom of that article. So what does this show? A1 road is not geotagged. So do we tag the London end, or the country end? Is it a landmark?

ClemRutter (talk) 10:25, 21 March 2008 (UTC)

I think this was discussed earlier. I'll add an archive index; I think the indexer runs in a little over 1.5 hours. Check in the Archive box at the top of this page. I think there is no good solution yet due to no support for linear objects. A mathematical solution is to tag near the midpoint of the road. I'd prefer a template to which a mandatory midpoint must be given, with optional endpoints (which might not be displayed or might be used by GeoHack for scaling); the template's info could be used in the future when someone figures out how to better support linear features. -- SEWilco (talk) 15:26, 22 March 2008 (UTC)

The archived comment "U.S. Roads" pointed at Ridge Route as an example. The description includes various points of interest which are marked with {{coord}} tags. The {{GeoGroupTemplate}} in External Links can show those points on a map. -- SEWilco (talk) 15:48, 24 March 2008 (UTC)

OK, I am following the discussion but all I see is indecision. Though Ridge Route is a FA its geotagging seems to be of start quality. For example there is no cord display=title, so I can't see at a glance which continent it is in. In the discussion page User:Andy Mabbett, suggests using a table of endpoints and waypoints citing Netherton Tunnel branch canal and this doesn't achieve consensus. Looking at that page, it does have a display=title- but of an arbitrary point so we have come fullcircle.

I want to look at a page, be it road, railtrack, canal or river, and see one coord at the top so I can find it on Google Maps. We need to decide whether we are looking at source or outflow, and which goes in the display=title. For a UK road, these points will be defined as all roads lead to London. Canals can be decided as minor flows to major, or high point flows to low point (though I can't see that reversing them would be a major crime). Railways in the UK also have the concept of the up line and the down line. One goes up to London! In Germany the lines seem to be named as the AStadt-bis-ZStadt-Strecke giving a concept of from and to. Andys concept of the table, and even inline end/waypoints can be used to implement this using the display=title,inline clause (sorry I am showing my Cobol). I can't see any value in using a midpoint- is it the mean, median value of the end points of the vector, the polygon? If I were to be bold, I would say that we use the outflow (major)end for the display=title, for two reasons.

• The flow is likely to be greatest at this point. This located, the route can be followed back to its source, which may be in dispute (rivers).
• In a tree structure it is easier to discover the tributaries if one start with the trunk.

There is a problem with roads that are extended. This is solved by looking at the name. Normally, the coordinate moves with the road unless the extended road is refered to by another name, when the original coordinate stays and the extension gets its own references.

Just a few idea.ClemRutter (talk) 23:34, 24 March 2008 (UTC)

Geopedia: coord side effect

A side effect of the geotagging efforts has appeared: Geopedia running on an iPhone shows Wikipedia articles about things near where you are.[5] -- SEWilco (talk) 15:08, 22 March 2008 (UTC)

Wow, that's sweet! Spencer^T?C 11:03, 25 March 2008 (UTC)

List of all pages using Template:Coord

We are in the process of adding a wikipedia layer to a web application that already displays many different other geotagged items, such as photos. While it is easy to find all pages that use the Template:Coord by using the "What links here" we noticed the Robots.txt file won't allow crawling the results page in order to find these pages only. The reason we were planning to build a crawler for this is that the number of geotagged articles keeps growing and we figured out how to use the Quality Assessment (Wikipedia:WikiProject_Council/Assessment_FAQ) to obtain a list of only B-Rated and better.

Through this page we discovered that the Wikipedia-World page provides dumps of this data, so I would like to know if this is the recommended approach for getting a list of all geotagged articles. Jugonzal (talk) 15:34, 24 March 2008 (UTC)

If you want to retrieve a large number of pages programmatically, it's recommended that you use a database dump, available at http://download.wikipedia.org. (Note: Template:Coord is included in several other templates, such as {{Infobox Settlement}}; see "What links here" in template space. It's complicated to extract the coordinates from all of these different templates, so I would just take one of the "Wikipedia-World" files, and parse the WP database dump to get the ratings. -- Eugène van der Pijll (talk) 17:05, 25 March 2008 (UTC)

C(rni Kal Viaduct: discrepancy between WikiMiniAtlas and Geopedia

Why do I get different results when I click the blue globe (at the bottom of the infobox) and when I click "coordinates/GeoHack/Slovenian/Geopedia"? For me the prime method for determining coordinates is by using Geopedia where the objects in Slovenia (like C(rni Kal Viaduct) have been marked already.

Another question: Why does GeoHack not show the main map of Geopedia but shows the Wikipedia - SI layer instead? --Eleassar ^{my talk} 15:51, 25 March 2008 (UTC)

Striken coordinates

Why are the coordinates in the article Poljane Grammar School striken by a straight line under the title? Could someone please fix that? --Eleassar ^{my talk} 12:35, 16 April 2008 (UTC)

See Template talk:Coord. Spencer^T?C 23:00, 16 April 2008 (UTC)

Re:Maps at - maps://ninemsn.com.au

Could someone at Map sources/GeoHack please remove Ninemsn Maps because the page is now a broken link with a 404 (Page not found notice). I can't give an example because the page address is too long. Kathleen.wright5 01:07, 18 April 2008 (UTC)

Is there a way to plot a category on a map?

I discovered the {{GeoGroupTemplate}} as it is used on Cat:Airports in Western Australia. However it doesn't work there as it is designed for articles containing lists of coordinates, not for categories of articles containing a set of coordinates in each article. Is there a way to display a category on a map? --Scott Davis ^Talk 14:27, 28 February 2008 (UTC)

There is a tool being developed to show members of a category. At present it works but needs some synchronization modifications so it will show more current data. One use is so all articles in a photos-wanted category can be mapped. -- SEWilco (talk) 16:22, 28 February 2008 (UTC)

There is a maping tool not for categories but for object-types, see Wikipedia-World/en#Expert_mode the parameter "style". All styles are listed at info.php.

A nice tool that combine categories and geotagging is Catscan. It need a while but that you see all articles which need a geocoord or not. --Kolossos (talk) 15:59, 3 May 2008 (UTC)

Wikipedia on GPS

An interesting suggestion at Wikipedia entries for GPS. How could this be done? -- User:Docu

I have no idea. It looks like a good idea, though. Spencer^T?C 18:23, 3 May 2008 (UTC)

I added some information to WP:GEO#Export_multiple_coordinates, but this doesn't provide the text (or part of the text) of articles.

Wikitude (see above) provides coordinates directly in a POI format (for on GPS at least). The data they use isn't that recent though. -- User:Docu

K?r?khan and Bistam

Would someone help fix the coordinates on the following pages? K?r?khan has two sets of coordinates, one at the upper right and one below the "body" of the article. The coordinates for Bistam are at Talk:Bistam. Thanks. Aramgar (talk) 21:31, 28 April 2008 (UTC)

 Done I have fixed it. Spencer^T?C 21:43, 28 April 2008 (UTC)

Thank you. Is there a reason why K?r?khan needs two sets of coordinates? Is not the set under the the external links heading redundant? Aramgar (talk) 22:38, 28 April 2008 (UTC)

It's generally how it works. For a random example, see Fossil, Oregon. Many article have up to four sets of coordinates: in the title, in text, in external links, and in the infobox. My personal preference is to set a max of three, with at least title coordinates and infobox coordinates. Spencer^T?C 23:10, 28 April 2008 (UTC)

Infobox image on Google Earth layer

I noticed that the Wikipedia article previews on the Google Earth layer never use the photo from an article's infobox. This is annoying, as it means displaying a secondary photo, or in some cases, no photo. Has this ever been suggested to the Google Earth people before? Is there anywhere I can complain? --Padraic 17:43, 1 May 2008 (UTC)

It seems that you mean the Wikipedia-World Layer, so you can talk with Stefan Kühn or with me. The reason is that Stefan Kühn scans the Wikipedia-dump with PEARL and so without any wikimedia parser help. So it is very difficult/impossible to detect an image in a template. I hope this answer is ok for you. Perhaps we could search for "=*.jpeg", "=*.jpg" and "=*.png" but thats would't nice and clean. --Kolossos (talk) 16:36, 3 May 2008 (UTC)

I assume it was for a technical reason like that - I have no technical skills myself, so I can't really help, I just wanted to suggest it. Thanks, and great work on the layer - I'm glad to see all the time I spent adding coords resulted in something useful. --Padraic 20:00, 3 May 2008 (UTC)

Tools

Why are no helpful tools to create coordinate templates on the project page? I mean things like:

• http://www.giswiki.org/hjl_get_CoorE.htm
• Ald-Hjl-Koord-en.kmz Tool for Google Earth
• http://tools.wikimedia.de/~kolossos/geonames/place-search.php
• CatScan in the example with buildings in New York City. It seems there is a lot work to do in NYC, but you can also try your town or area.

I can't understand how people can work without some tools. --Kolossos (talk) 22:09, 3 May 2008 (UTC)

I don't know...I do everything manually (old school). Spencer^T?C 23:16, 3 May 2008 (UTC)

There is a specific page: WP:Obtaining geographic coordinates. -- User:Docu

Ok I didn't find it. I hope I am the only one. --Kolossos (talk) 10:58, 5 May 2008 (UTC)

New Google maps layer

I'm not sure if everyone in the project is aware of this, but Google Maps has just released an update and any user can now chose to add a Wikipedia layer to a map. A lot more people are going to be deriving benefit from the geocoding. - SimonP (talk) 01:15, 14 May 2008 (UTC)

New site: wikitude.org - Latitude, Longitude, ... Wikitude

I've created a website wikitude.org - Latitude, Longitude, ... Wikitude. visualizing the coordinates within Wikipedia articles. You can find points of interest (POI) in your area (address search), view POIs on a map and read the corresponding Wikipedia article. Furthermore POIs can be downloaded for Google Earth and other GPS Navigation system. I would be interested to hear what you think about it. —Preceding unsigned comment added by Joos23 (talk • contribs) 22:44, 6 November 2007 (UTC)

There are some interesting ideas there, but search results is displaying a live Wikipedia page in a frame. Is that kosher? (SEWilco 20:21, 7 November 2007 (UTC))

Joos23's contributions to wikipedia consist entirely of adding external links and promoting wikitude.org and has been marked as WP:Spam and violates Advertising and conflicts of interest. see Wikipedia_talk:WikiProject_Spam#http:.2F.2Fspam.wikitude.org--Hu12 18:00, 10 November 2007 (UTC)

Thank you for your comments. About (SEWilco comment) displaying the Wikipage page in an iframe: I changed this feature such that the default option in the search form "Open Wikipedia articles in new window" is checked. Only if user explicitely uncheck the button, Wikipedia content is shown in an IFrame. Please check it out. If you think this is not ok, I can remove the IFrame altogether. (iframe has been removed) - Nov 07. Joos23 (talk) 09:29, 16 May 2008 (UTC)

removed my comment Joos23 (talk) 09:28, 16 May 2008 (UTC)

I'm still scratching my head but there's nothing in my head at the moment about this. I can't tell whether I'm not understanding something or whether I don't have enough information. (SEWilco 05:01, 12 November 2007 (UTC))

Title coordinate issues

Is there something wrong with the title coordinates? In articles like Lazio, Campania and definitely Gihtsejieg?a, the line under the title is running through them. Is this my browser having problems, or is it a template issue? Spencer^T?C 21:50, 27 March 2008 (UTC)

Seems to now have been fixed, but the Gihtsejieg?a article still cuts it a bit close. Spencer^T?C 23:59, 27 March 2008 (UTC)

I am still getting this problem so it has not been fixed as yet. Keith D (talk) 18:34, 29 March 2008 (UTC)

Funny. It was happening with Palenque, but then I refreshed my browser and it was fixed. This is confusing. Spencer^T?C 19:54, 3 April 2008 (UTC)

At Template talk:Coord I found a problem due to infobox character styles. Infobox fixes will be necessary, probably combined with a CSS change. -- SEWilco (talk) 14:45, 4 April 2008 (UTC)

How do we fix the infobox templates? Reading above suggested link... Spencer^T?C 21:27, 5 April 2008 (UTC)

The reason is that handling of the sitenotice isn't consistent through the MediaWiki & MediaWiki Javascript & site wide Javascript chain Wikipedia uses. When no sitenotice is set, MediaWiki doesn't create an element for it, everything is positioned as we expect, and the coordinates in their top-of-the-page based position look fine. When however there is a sitenotice, an element is created and depending on its height it may or may not make coordinates overlap with other elements. That's part 1 of the problem, that header elements have to be implemented with absolute positioning, and can break when other elements are added. A tentative fix is suggested at bugzilla:12548.

The link to dismiss the sitenotice runs a script which deletes the entire sitenotice element from the current page, and so the first time people click on it everything looks fine again. However, when it has been dismissed, the cookie created to keep it away for good, and another page is loaded, the web of javascripts works differently; it only deletes the contents of the element and not the element itself. Because the element has a top margin of 5 pixels, the empty element still pushes the rest of the page content down by five, making the line overlap with coordinates that would normally be below the line. That's part 2 of the problem, that hiding the sitenotice isn't consistent.

A short term solution could be to first make the hiding always behave the same way, and then maybe brew some javascript to shift all the additional header elements down by the rendered height of the sitenotice element. Wonder where all the code related to the sitenotice is? --Para (talk) 17:30, 9 April 2008 (UTC)

This is still broken. It first became a problem when there was a fund appeal going on and it moved the coordinates to the middle of the page name, because they are located a fixed number of pixels from the top and this wasn't changed while the fund appeal was going on, presumably because registered users get to shut off the fund appeal. I don't know why it was moved recently but it has been brought up twice at Wikipedia:Village pump (technical). Registered users can put a line into their monobook.css file

 #coordinates {
 top:4.5em;
 }

No help for the remaining 99% of Wikipedia users, though. I would recommend not fixing it for oneself so that you can see what the rest of the world sees, and keep complaining until it gets fixed. 199.125.109.104 (talk) 20:10, 11 April 2008 (UTC)

This issue has stabilized now that the anonnotice has been removed. For IPusers the coordinates start with the globe at the horizontal line and are slightly below the line, for registered users the coordinates are slightly above the line unless they hide the sitenotice in which case they are below the line. However, the line does not split the difference. The coordinates could be moved down by exactly 3 pixels to make them an equal distance above the line for registered users and below the line for IP users and registered users who hide the sitenotice. What fraction of an em that is I do not know, but I'm sure that someone can figure it out. 199.125.109.80 (talk) 00:48, 20 May 2008 (UTC)

Best practices, Wikipedia and Google

Some of us over at WikiProject Oregon have noticed the new overlay that places Wikipedia icons on Google maps. (See this conversation.) We have a few questions and are wondering if you can help us determine best practices for geocoding articles.

1. There are two icon sizes on the Google Maps overlay. There are also multiple "levels of importance," as zooming in and out on the map will cause icons to appear or disappear. Ideally, more important or large geographical features (cities, counties) would have large icons and appear at the most distant zoom, while less important local features (buildings, city parks) would have small icons and appear at the closest zoom level. We originally speculated that the levels of importance were determined by the level of specificity (number of significant digits) in the article geotags. But we have since found articles with similar levels of specificity in the Wiki geotags displayed differently by Google. Do you have any suggestion about improving geotags on articles to get the level of significance correct?
2. Do you have any suggestions about how to geotag articles of linear geographical features (roads, rivers)?
3. Do you have any information about when Google cached the article versions that they are displaying? When will the cache be updated? Is it possible to force an update so that more current versions of articles appear?
4. Have you found any official Google documentation on the Wikipedia overlay?

Thanks for any advice. Northwesterner1 (talk) 04:59, 20 May 2008 (UTC)

I've only seen mention of the existence of the layer in a Google blog, with no details provided. There might be a Google Maps forum where you could ask such questions; such a forum might be mentioned in Google Maps help pages. -- SEWilco (talk) 05:19, 20 May 2008 (UTC)

I poked around on the Google forums, but didn't find much. The help pages are curiously devoid of any mention of the layers.... —EncMstr (talk) 05:26, 20 May 2008 (UTC)

That's great news. Multimap started showing Wikipedia data a while ago too. It'll bring more attention to both Wikipedia and this little side project in it, so we should prepare for the repetitive questions and once again, improve our data. Just modifying the "Contact Wikipedia / Report a problem with an article / An article is linked from the wrong place in Google Earth" path won't be enough. The problems we've had to explain to people in the past and probably even more so in the future, are mostly related to visibility. That includes:

• Availability of data in the format documented on Wikipedia. The entry of coordinate data is still inconsistent in Wikipedia and is likely to lead to lots of confusion on why one article with top right coordinates is visible on the map but another that looks just the same to the reader is not. Open issues are #Geolinks bot replacement and infobox parameter standardization. High profile reusers with massive computation capabilities may be able to solve the problem in other ways, but that's a bad excuse not to fix it on our end. It needs to be done.
• Size of the icons reusers display. Whether we have anything to do with it or not doesn't matter, we'll get feedback anyway. What information do we provide for determining the size or importance of an article? Categories are too hard to use with anything automated. Types are not extensive enough. Scales aren't used widely enough and aren't related to anything. Dim is neither supported nor used. Coordinate precision isn't consistent between objects of different size and we haven't agreed on which point the coordinates indicate, so implicit scale from the precision is unusable. That's a whole lot of problems, but I think we can fix them by perhaps adding some more types and slowly starting to use the dim parameter. For that the necessary conversions need to be added to GeoHack, and then the scale parameters either converted and verified or added to articles manually. First, we'll need a table of the various zoom and scale parameters used by map services, and then the corresponding real world distances that fit into those views.
• Better explanation of updates. All reuse is for now, and probably will be for a long to come, dependent on database dumps. It would be good if we could keep a list up to date of available English Wikipedia dumps, side by side with links to some of the latest articles with new coordinates in those dumps. This way people could find the age of the data their favourite reuser is displaying. When such a table exists, will anyone find it from WP:GEO? It's a bit of a mess, but what can be done to improve and help people find the relevant information? In my opinion the markup and instructions for participation are more important than anything that's currently higher up on the page.

Which issue should be tackled first? --Para (talk) 19:02, 20 May 2008 (UTC)

• So long we can provide an geo-dump on de:Wikipedia:WikiProjekt_Georeferenzierung/Wikipedia-World/en, i think it is for reusers not a problem to use our datas. Also on geonames.org the datas are available. But off course the count of templates should be reduce. An international template for all languages would be the best, so we created on german wikipedia our new template de:Template:Coordinate so that we need only one template and use English syntax.
• For converting "dim" into "scale" on geohack I create a formula like dim=42000/((2^scale)*cos(latitude)) this should be tested and integrated into geohack.
• For relevance of articles we should talk with user:henrik, he has for his wikistats a february-dump which we could need in a database on toolserver. So how google works without relevance, I don't like. --Kolossos (talk) 21:15, 25 May 2008 (UTC)

On a side note, de:Template:Coordinate seems to be missing "pagename=" and "title=" when calling geohack.php. -- User:Docu

Lakes needing coordinates

Of 4700 articles about lakes, 3/4 have coordinates. There are some 1200 lakes that are still missing coordinates.

{{Infobox lake}} includes a field for coordinates ("coords ="), e.g.

| coords = {{coor at dms|59|59|N|179|59|W|type:waterbody_region:ZZ}}

If the field is missing, the articles are added to Category:Wikipedia infobox lake articles without coordinates. I'm working on a few articles that have coordinates specified differently.

Lakes of specific countries or regions can be selected with the CatScan tool (see category description). Any help would be appreciated. -- User:Docu

I'd just like to note that some lakes may have coordinates, just not in the infobox. Spencer^T?C 23:31, 20 May 2008 (UTC)

Yes. About 150 articles in the category already use {{coor URL}} in one way or the other. -- User:Docu

Okay, I'm starting to work through it. Spencer^T?C 00:28, 22 May 2008 (UTC)

Thank you for your help. There are now just 7 articles left using {{coor URL}} in another way. -- User:Docu

Satyr

Have you replaced User:SatyrTN's User:SatyrBot? We at WP:CHICAGO are looking for a replacement since he is no longer active. Please respond at my talk page.--TonyTheTiger (t/c/bio/WP:CHICAGO/WP:LOTM) 18:50, 24 May 2008 (UTC)

Can you describe what actions you need? Maybe someone knows a relevant tool but doesn't know what SatyrBot did. -- SEWilco (talk) 05:47, 25 May 2008 (UTC)

Globe

Resolved

 – Appears to have been rectified.Spencer^T?C 19:35, 1 June 2008 (UTC)

What happened to the little globe ( ) that used to be next to the coordinates? It says it should exist according to the documentation at Template:Coord. Example: It's missing in the article Ames, Iowa. Note that the globe is also missing on other coordinates templates, too. Spencer^T?C 20:28, 30 May 2008 (UTC)

I've raised the issue at WP:VPT. There's also a discussion going on at the Help Desk -- ShinmaWa^(talk) 22:28, 30 May 2008 (UTC)

Thanks, I'll look at the discussions. Spencer^T?C 23:46, 30 May 2008 (UTC)

type:waterbody for rivers, glaciers

I fixed a series of rivers that still used "type:waterbody". I'd favor adding "type:glacier" for glaciers and replacing current uses of waterbody for those. -- User:Docu

Given that it seems fairly uncontroversial, I updated type accordingly. -- User:Docu

New types (WP:GEO#type:T)

For schools, colleges, universities, etc., I'd like to create a new "type:edu" replacing "type:landmark" used for such institutions. -- User:Docu

I think we should keep the types as simple as possible, while still covering geographically different types. That's mostly about the size and shape of the objects, where the recent addition of type:river for rivers was great to separate them from all the roundish waterbodies. The purpose of a building however doesn't really need to be told related to the coordinates, as the scale is about the same with other landmarks. Many different types would be useful for reusers though, who could then use different icons based solely on the type, but I don't think we should start replicating categories. --Para (talk) 23:20, 17 June 2008 (UTC)

Is the purpose to determine scale? What is the proper scale for a one-room schoolhouse? What is the proper scale for a university with campuses miles apart? Is the purpose to classify the item? So there should be types for restaurants, corporate headquarters, food franchises, city halls, bullfighting rings, and the last known location of Don Rickles? -- SEWilco (talk) 04:02, 18 June 2008 (UTC)

I find it somewhat convenient to use the type to select specific objects. For scale there is distinct parameter. -- User:Docu

I updated the list accordingly. -- User:Docu

For mountain passes, I'd like to add "type:pass" to replace "type:mountain" (to be used according to current definition) or "type:landmark" (frequently used). -- User:Docu

I updated the list accordingly. -- User:Docu

For railway/train/railroad stations, I'd like to add "type:railwaystation". Comparable to "type:airport", this would replace "type:landmark" currently used. -- User:Docu

Concern

type,description,scale: forest Forests and woodlands  ? river Rivers and canals  ? glacier Glaciers, ice caps  ? edu Schools, colleges, universities  ? pass mountain passes  ?

I notice that the scale parameter is not specified! You are updating "documentation" without updating the underlying "GeoHack" code, See {{GeoTemplate/doc}} "Scaling" and "Type":

Scaling

GeoHack accepts a scale parameter (scale:2000 in the example above) which it uses to provide scaling or zoom values for different mapping services.

name	used by	formula
{scale}	Virtual Globe	supplied in URL via scale or calculated based on type
{mmscale}	Multimap	closest scale value accepted by Multimap (see mapsources.php)
{span}	Google Maps, WikiMapia	scale * 1.0 / 1,000,000
{altitude}	MSN Maps, Fourmilab, Swissinfo	scale * 143 / 1,000,000
{zoom}	MapQuest, Gule Sider	integer(18.0 - log(scale))
{osmzoom}	OpenStreetMap, Live Search Maps	18 - ( round(log($attr['scale'],2) - log(1693,2)) )

GeoHack accepts a type parameter (type:landmark in the example above) from which it will calculate a scale value when none is supplied. The following chart shows the types currently understood by GeoHack, the scale ratio associated with each, plus the additional variables calculated by GeoHack.

{type}	ratio	{scale}	{mmscale}	{span}	{altitude}	{zoom}	{osmzoom}
country	1 : 10,000,000	10000000	10000000	10	1430	1	5
state	1 : 3,000,000	3000000	4000000	3	429	3	7
adm1st	1 : 1,000,000	1000000	1000000	1	143	4	9
adm2nd (default)	1 : 300,000	300000	200000	0.3	42	5	11
city, mountain, isle	1 : 100,000	100000	100000	0.1	14	6	12
airport	1 : 30,000	30000	25000	0.03	4	7	14
landmark	1 : 10,000	10000	10000	0.01	1	8	15

The default values can for each type can be overridden by also supplying a scale. For example, type:airport is assigned a {scale} of 30000, while type:airport_scale:10000 uses the supplied {scale} of 10000.

For detailed implementation see mapsources.php

I have been wondering why the "scale" of several types appeared "broken", someone (User:Docu ?) needs to get "mapsources.php" above updated from:

mapsources.php
'country' => 10000000, # 10 mill
'state' => 3000000, # 3 mill
'adm1st' => 1000000, # 1 mill
'adm2nd' => 300000, # 300 thousand
'city' => 100000, # 100 thousand
'mountain' => 100000, # 100 thousand
'isle' => 100000, # 100 thousand
'airport' => 30000, # 30 thousand
'landmark' => 10000 # 10 thousand
...
'default' = 300000;
...

"Type" was apparently primarily intended as a shorthand way of setting "Scale", I understand its value in specifying what "type" a given set of coordinates are so that scripts can do other things with the information.

I am not sure what is practical, but I see benefit to having:

• pairs of coordinates (start and end of linear features: rail, road, stream, ...
• bounding boxes: at least a maximum and minimum latitude and longitude
• lists of coordinates: at least for "turning points" of a "linear" feature (rail, road, stream, ...)
• extension of a list of coordinates to represent a closed polygon - a.k.a. area border or boundary

Not sure what is practical, but wish that things more complex than a "point" coordinate can be fed to GeoHack. Since Google and some others now support map overlays more complicated than a mark or pushpin (lines, polygons, ...)

Other thought is if there were an "easy" way to create a .SVG from a "structured" list of coordinates, a.k.a. doing a "simple" schematic line map (to show relationships between them - like watersheds, highway intersections, ...) LeheckaG (talk) 17:58, 8 July 2008 (UTC)

Type tags, scales etc

Would it be possible to implement a fuller tag system like the one OSM uses? Sfan00 IMG (talk) 18:39, 20 June 2008 (UTC)

Two tags on one page . . .

In Palms, Los Angeles, California there are two coordinate tags — one at the top in the right-hand corner, and the other at the bottom. Which should be used? Sincerely, GeorgeLouis (talk) 04:38, 28 June 2008 (UTC)

Quick answer. A degree of confusion here. The tag that appears at the top is generated by the coding in External Links at the bottom. But this article lacks an {{infobox}} see Los Angeles to see one in action. When all the details has been added to the infobox (including latitude and longitude) then the line in External Links would be removed as redundant, though appears to be left in the States.

You can get articles where there are many inline tags- for example places along a river. In that case {{Coord|51.17886|-1.82621|display=inline|format=dms}} the parameter display=inline is used, display=title,inline puts that tag both inline and as a title.

ClemRutter (talk) 08:36, 28 June 2008 (UTC)

I simplified the coordinates on Palms, Los Angeles, California, hope it looks better now. -- User:Docu

COORD Template and digital N/S/E/W output

TO try and understand the issue in the "discussion" proceding several sections above this one i.e "Deprecated template ...", perhaps someone can straighten things out for me. The issue, if I understand it, is that given

• "coord" is intended in part to replace the deprecated "coor d"
• "coor d" supports digital N/S/E/W output
• "coord" does not support digital N/S/E/W output

the question is whether this is a Feature or a Dropped Case. By feature I mean "It's supposed to be that way" because, say, some International Geo standards organtization has decided that digital N/S/E/W is bad. That would be reasonable. By dropped case I mean "Hm ... we missed that one, it's on the list of things to do". That's also reasonable.

Have I gotten the crux or this or am I way out of control. :-) Ploversegg (talk) 05:10, 29 December 2008 (UTC)ploversegg

{{Coord}} does support the output of coordinates in digital format. Its output is as designed and agreed by community consensus. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:13, 29 December 2008 (UTC)

That is in contradiction to what the Quick how-to box says.

For decimal coordinates, such as 44.112°N 86.913°W, use one of

{{coord|44.112|N|87.913|W|display=title}}

{{coord|44.112|-87.913|display=title}}

This clearly states that according to the template's specification for decimal coordinates output it is supposed to include the N/S/E/W markers. So where can the development of the claimed "community consensus" be traced? Cush (talk) 12:56, 29 December 2008 (UTC)

Firstly, the wording you quote from that box does not, and is not meant to, imply (much less "clearly state") what you claim it does; and secondly that box was written long after the template was created and widely used. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:08, 29 December 2008 (UTC)

Of course it does state what I say. Moreover, the second sample says that even without |N| and |W| in the page code the N/S/E/W markers are supposed to be rendered in the result. The fact of the matter is that coordinates like 44.112°N 86.913°W cannot be created with the coord template (you may try it in a sandbox). So can you please direct me to the discussion that produced the "community consensus" and can you please direct me to the template's specification? Thanks in advance. Cush (talk) 13:18, 29 December 2008 (UTC)

It states no such thing.

You are clearly not happy with the way {{Coord}} has been designed, even though you did not participate in that process. If you wish to change the way it presents its output, please make a properly-considered proposal to do so, in the appropriate place. Then we can see whether or not there is community consensus for the change you propose. Merely complaining, wrongly, that the template is "broken", or falsely implying that there is no consensus for it, as you are doing, in multiple fora, is wasting your and other peoples' time. Such claims are patently of little interest to the community. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:23, 29 December 2008 (UTC)

Would you now kindly direct me to the discussion that led to the community consensus and the template's specification? Thank you. Cush (talk) 13:41, 29 December 2008 (UTC)

There were dozens of discussions in many different places around May - Aug 2007 in which it was agreed to replace the many varieties of coor with coord. There is no onus upon the community to assist in historical musings. (The choices for {{coord|44.112|N|87.913|W|display=title}} are 44°06′43″N 87°54′47″W or 44.112, -87.913 which seem to cover the usual alternatives. I would agree that the 'quick how-to' leads one to believe, erroneously, that the display 44.112°N 86.913°W is possible.) Occuli (talk) 01:35, 30 December 2008 (UTC)

Who defined the "usual alternatives"? Would you kindly direct me to the ISO or other standard that you folks were using when defining the output? You see, the special thing about geo coordinates is that the order of coordinates differs from that of any other mathematical notation, which is why N/S/E/W is used. 44.112, -87.913 would be interpreted as x-coordinate first and y-coordinate second as vector notation has it. And I fail to understand why dms notation is rendered having N/S/E/W while decimal notation is not. The reasoning should be the same, shouldn't it? Please show me the discussion that led to the specification of output design. Thanks in advance. Cush (talk) 10:47, 30 December 2008 (UTC)

Please note my comment above, time-stamped 13:23, 29 December 2008 (UTC). Until you do as I suggest there, your further questions are beginning to appear disruptive. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:51, 30 December 2008 (UTC)

I revised the "quick how to" yesterday, to address that point. Server lag may mean that you're still seeing the old version. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:54, 30 December 2008 (UTC)

COORD Template and digital N/S/E/W output continued

This was mentioned a couple of times at Template talk:Coord/Archive 1#Display issues and Template talk:Coord/Archive 1#Bug: display N.2FW.2FE.2FS when the template was being written[6], but seems to have been ignored. While the formatting to either decimal or dms format is by design, I think the formatting of the decimal coordinates just happens to be what was easiest to make at the time, and nobody has considered it an issue big enough yet to look into it further. With all those mentions back then, this topic here and at Template talk:Coord#Formatting problems, the community has shown that it wants decimal coordinates formatted in line with dms coordinates. I agree, as it would make coordinate display more consistent. The template is however a major pita to change due to it being clustered over dozens of templates, and internally it might need that third output format added to some of those. The issue now is to find someone who can figure out how. --Para (talk) 12:38, 30 December 2008 (UTC)

Thank you. Haven't talked to you in a while. Is there a way to look at the template's code? Cush (talk) 12:48, 30 December 2008 (UTC)

"View source". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:05, 30 December 2008 (UTC)

Looking at the source of the templates in Category:Coord template would be a good starting point, but I think at least the line of Template:Coord – Template:Coord/input/dec – Template:Coord/link would need modification. --Para (talk) 13:08, 30 December 2008 (UTC)

Oh and while dissecting the template, it would be nice if some documentation could be written of how the various bits and pieces of the whole template work, so that people don't always need to go to the code to understand it. --Para (talk) 13:50, 30 December 2008 (UTC)

I wrote a bit of something on Template:Coord/doc/internals. Discussion continuing at Template talk:Coord#Formatting problems --Para (talk) 20:19, 30 December 2008 (UTC)

Comments from a small handful of users do not mean that the community has spoken. Indeed, the community has consistently shown itself uninterested in the issue, and thus content with the status quo. And that is unlikely to change, until a properly-considered proposal for change is made, in the appropriate place - as I pointed out to Cush yesterday. His reluctance to do that, given the apparent weight of his conviction, is somewhat puzzling. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:05, 30 December 2008 (UTC)

Comments from you do not mean that the community speaks either. I have looked through recent discussions and the issue keeps recurring. So let Para speak for a moment. Cush (talk) 13:11, 30 December 2008 (UTC)

But then I haven't claimed that they do; nor tried to stop Para from speaking. I've merely pointed out the facts of the situation, and advised you on how to attempt to initiate the change you appear to desire. Up to you whether or not you do so, of course, but your apparent reluctance is, as I say, puzzling. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:41, 30 December 2008 (UTC)

Just a word to the wise: there's going to be some unilateral noise when it's noticed that "negative" coordinates will no longer be visible on Wikipedia pages and we'll have to provide them in an other way to programs reading the HTML output. --Para (talk) 13:50, 30 December 2008 (UTC)

ITYM "if" not "when". Until we have a properly-considered proposal for change to comment on, we don't know what the community wants to happen, and what its implications might be. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:56, 30 December 2008 (UTC)

Since when does a bug require community consensus to fix? (It did not function as intended, i.e. replicated the coor * templates) — Dispenser 08:48, 31 December 2008 (UTC)

Thank you. That has been my point all along. But Pigsonthewing is trying to to convince me that this glitch was done on purpose, although he is unable to direct me to the discussion that had the omittance of NSEW as its result. Cush (talk) 10:46, 31 December 2008 (UTC)

I've already responded to that point, more than once, as have other editors. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:14, 31 December 2008 (UTC)

Since when was a personal preference for a display format a bug? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:14, 31 December 2008 (UTC)

"...and the explicit intention to provide the functionality of all of coor *, ..." (Andy, coord template one year on) the functionality of {{coor d}} is to duplicated the visible text output the exact same way it's written. It works correctly for dms, dm, but not d. — Dispenser 16:08, 31 December 2008 (UTC)

That's functionality, not visual presentation; and was written post-implementation, as you point out. You really are scraping barrels. If you wish to change the current implementation, as used on ~a quarter million articles, over the last two years, please make a proposal, invite comment, and obtain consensus. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:55, 31 December 2008 (UTC)

Visual presentation is the functionality of the template. The other functionality being the creation of a hyperlink. Cush (talk) 12:20, 2 January 2009 (UTC)

On the contrary - functions are to offer user choice of DMS, decimal input & output (or both outputs); emit microformat, offer choice of display position. Functions are tasks. Visual presentation, in the form of labelling or use of symbols, is that and no more. Why are you so reluctant to ask for consensus for the changes you desire? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:52, 2 January 2009 (UTC)

Geohack broken

Is it just me, or is the Geohack page broken? When I click on a set of coordinates, I just get a screen full of gibberish, but framed by the GeoHack chrome. It's been like it for a couple of hours; in Firefox and Opera. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:56, 2 January 2009 (UTC)

Same here. And it is browser independent. I'm asking on IRC... --Dschwen 16:55, 2 January 2009 (UTC).

Ok, check [7]. Maintenance is still not finished on one of the database servers (yarrow). That could be causing the error. Then again the tool should definitely fail more gracefully. --Dschwen 17:01, 2 January 2009 (UTC)

See bugzilla:16230. GeoHack workaround for the PHP/MediaWiki/Squid/whatever bug pending. --Para (talk) 17:15, 2 January 2009 (UTC)

The squid servers are now forcing Content-Encoding: gzip on all request for en. I can't fix the problem since my SVN access isn't fixed yet. — Dispenser 17:19, 2 January 2009 (UTC)

It seems to be working OK now, at least for me (using Firefox). -- The Anome (talk) 09:45, 6 January 2009 (UTC)

Easy coord addition button

Anybody here use refTools? It's an easy ref (cite book, cite news, etc.) fill-in button at the top of the edit screen. Could one like this be created for coord? See User:Mr.Z-man/refToolbar.js. Thanks, Spencer^T♦C 01:28, 8 January 2009 (UTC)

I wrote something like this for commons [8] and de.wp [9]. I guess I could adapt it to en.wp as well. It adds a button and a text fieled into which you can paste urls from google-maps and live-maps (pressing the button then adds the coordinate template). The de version is even smarter, it finds boilerplate text from standard stub articles with plain text coordinates, and population numbers mentioned in the text. --Dschwen 05:59, 8 January 2009 (UTC)

Section for Biblical locations?

Hi WP:GEO! I've been going over Category:Israel articles missing geocoordinate data, and noticed that there was a large amount of articles there about Biblical locations. I believe that these should be in a separate category, because not only is the precise location of many of these uncertain, but also it's confusing and counterproductive to lump them with modern locations, because someone who can look up a modern location on a map isn't generally likely to know anything about Biblical locations. -- Ynhockey ^(Talk) 16:18, 8 January 2009 (UTC)

Where would you place such a section? I already have a list of biblical placemarks that I could easily create a new page from. Or do you just want the respective articles to contain title coordinates?
also cf. Cities of the Ancient Near East#the_Levant - Cush (talk) 16:28, 8 January 2009 (UTC)

If the precise location of a biblical place is unknown, remove the {{Coord missing}} template - it should not be re-added (leastways, not by the bot). OTOH, if someone doesn't know anything about a location which does have precise coordinates, those coordinates will help to inform them about that place. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:06, 8 January 2009 (UTC)