Wikipedia talk:WikiProject Geographical coordinates

504165 transclusions

The template transclusion counter found 504165 transclusions of {{Coord}} just now! Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:47, 8 September 2009 (UTC)

Very good. Basis for a signpost story, I think. --Tagishsimon (talk) 00:18, 9 September 2009 (UTC)

Indeed. Good call. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:20, 9 September 2009 (UTC)

←And just now, 14 days later, 511927 transclusions - that's ~500 added each day! Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:57, 22 September 2009 (UTC)

Now 534456, an increase of 22529 in just over a month since 22 September. -- The Anome (talk) 14:46, 26 November 2009 (UTC)

That would be a two month period thus 11k per month, non? Today we are at 541697, which is another 7k from 26t Nov. --Tagishsimon (talk) 01:56, 21 December 2009 (UTC)

558347, just now; an additional 16650. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:29, 28 February 2010 (UTC)

Please note that more transclusions is not necessarily better. Many articles geocode the same location three or more or more times, creating a maintenance headache. To reduce the number of {{Coord}} transclusions, I merge templates using the display=inline,title option whenever I see the opportunity. --Stepheng3 (talk) 03:09, 27 March 2010 (UTC)

Not getting captured by Google

I've been trying for a while to get Google Maps/Earth to pick up the coordinates for Mont Clare, Pennsylvania. I've tried a few things without success (although if the slightly different coords in sv:Mont Clare, Pennsylvania were impacting, I just fixed those). Anyone have any suggestions? Thanks. --J Clear 00:19, 6 December 2009 (UTC)

It is a feature that Google has an idea where it is located.[1] The difference from the article's location is about 2,000 feet (610 m). The coord in the article is fine as far as I know, and I would expect a W icon to show up for the city in a few months. Google says it updates every one to three months, but my observation is that it is often quite a bit longer. —EncMstr (talk) 01:14, 6 December 2009 (UTC)

I set the article coords at the oldest part of town, near the former post office, where the population is denser, rather than the GNIS coords (what Google appears to be using) which are more in the area center, or perhaps just at a more major intersection. Maybe I'm "fighting city hall". Should be interesting to add secondary coordinates in the article and see what shows up. --J Clear (talk) 01:44, 3 January 2010 (UTC)

Geocodes of items in articles

Is there a way to put geocodes on specific landmarks mentioned in articles rather than the whole article? E.g. I think geocodes on the various Spite houses would be useful. --Dwchin (talk) 06:39, 19 December 2009 (UTC)

Yes, of course. Use the name= parameter with an inline {{Coord}}. For instance: {{Coord|40|46|36|N|73|57|26|W|region:US-NY_type:landmark|name=Richardson Spite House}} gives 40°46′36″N 73°57′26″W. --Stepheng3 (talk) 06:45, 19 December 2009 (UTC)

Discussion at Template:Coord

I have started a discussion at Template_talk:Coord#WikiMiniAtlas_override.3F that may be of interest to this project. Shereth 16:32, 29 December 2009 (UTC)

Yes, this problem is very important at at Wikipedia_talk:WikiProject_National_Register_of_Historic_Places, see Wikipedia_talk:WikiProject_National_Register_of_Historic_Places/Archive_34#Loading_speed_of_our_longer_lists. The problem is with lists of 200-300 places, which take 15-20 seconds to load and can be nearly impossible to edit. Any help would be greatly appreciated. Smallbones (talk) 15:30, 18 January 2010 (UTC)

Yes, We could define an id alla disable-wma, that WMA will getElementId and when present not run WMA on those pages. It could be added with a {{disable wma}} or something. And then additionally add a 10second execution timeout in the script. I'll look at making such suggestions later today. That might be a solution for the NRHP issues. —TheDJ (talk • contribs) 21:57, 18 January 2010 (UTC)

'impossible' to edit effect, is mostly caused by an edit requiring the page to be parsed again. Some of those pages take well over 30 seconds to parse with the complexity of the coord template. That is separate from the javascript parsing delay. —TheDJ (talk • contribs) 21:59, 18 January 2010 (UTC)

Shorter GeoHack URLs

GeoHack URLs are rather long. So I propose the following shortening scheme: drop pagename= as it can be gotten from the referer, make the language= and params= part of the request path using a rewrite rule. The effect is illustrated below:

http://toolserver.org/~geohack/geohack.php?language=en&pagename=PAGENAMEE&params=45_N_123_W_&title=NAME
http://toolserver.org/~geohack/en/45_N_123_W_?title=NAME

This is part of GeoHack's move off the stable server, no changes are mandatory when this happens. Other schemes under consideration are /~geohack/en/PAGENAMEE?params= and /~geohack/wikipedia/en/PARAMS. I am interested in hearing the thoughts from Toolserver users and others who parse the external links table. I will post the rewrite regular expression if we have finalized a scheme. — Dispenser 23:24, 2 January 2010 (UTC)

With this proposed change, what would happen to the region:, type:, scale: and zoom: fields? -- The Anome (talk) 13:24, 3 January 2010 (UTC)

They would continue to be used along the coordinate, so it would look like /~geohack/en/45_N_123_W_type:city_region:US?title=NAME. — Dispenser 14:26, 4 January 2010 (UTC)

OK, I can handle that. -- The Anome (talk) 13:53, 5 January 2010 (UTC)

first, i can handle it to. But why a second parameter for title?/~geohack/en/45_N_123_W_type:city_region:US_title=NAME. Visi-on (talk) 21:57, 11 January 2010 (UTC)

organize the attributes of coordinates. A coordinate describe

1. a place with
   1. an elevation
   2. a population
   3. a name / title
   4. a type (landmark, city ... )
   5. a region (up to 4 ISO-Codes → Four Corners)
   6. a dimension
2. the center of an area with
   1. an elevation (avg, max and min)
   2. an area
   3. a population
   4. a name / title
   5. a type (landscape, state, country, adm1st, adm2nd, adm3rd ...)
   6. a region (up to 4 ISO-Codes)
   7. a dimension

example: Berlin: /~geohack/de/52.5N_13.35W_area:891.82_pop:3431700_ele:45_maxele:115_minele:34_region=DE-BE_type=city/adm1st_name:Berlin

Visi-on (talk) 12:08, 12 January 2010 (UTC)

dimension added Visi-on (talk) 11:22, 15 January 2010 (UTC)

The biggest problem with the proposal is if we did name/title that way it would be limited to one word as the underscore/space would indicate a new param. This field also has the same title restrictions as in MediaWiki, in fact doing what I purpose requires some trickery in the regex with regards to question mark character. Also, usage of = (Equal sign) since this character cannot be easily typed into enwiki's templates.

oh this is true ...

• but: /~geohack/de/52.5N_13.35W&a=891.82&p=3431700&e=45_34_115&r=DE-BE&t=city/adm1st&id=Berlin&d=20000 will work well and
• with signed decimals: /~geohack/de/52.5_13.35&a=891.82&p=3431700&e=45_34_115&r=DE-BE&t=city/adm1st&id=Berlin&d=20000 even better

and you can left the old interface as is for compatibility reasons. Visi-on (talk) 14:27, 16 February 2010 (UTC)

Your welcomed to come up with whatever scheme for additional information you'd like to include in the URL. On region I know that there's at least one instance on the dewiki where 10+ were being used (broken my db) and it also the sort of stuff that should be sorted out by a computer. — Dispenser 06:39, 24 January 2010 (UTC)

The idea in the dewiki is that the first four region-iso codes must be interpeted because of the existence of places like Four Corner. The problem of rivers (lakes) touching a lot of regions is known. Visi-on (talk) 14:27, 16 February 2010 (UTC)

Google

Is anyone in touch with Google (or any of the other search engines) about this, just in case they are parsing these URLs for this information? -- The Anome (talk) 14:41, 6 January 2010 (UTC)

I can drop Google a line if you let me have more detail; better still, put some documentation on a page which I can point them to. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:22, 28 February 2010 (UTC)

Asymmetry

After reading the discussion of dim vs. scale I was off measuring my village to change its {{coord}} when I noticed a potential issue. How should asymmetric objects be handled? For example, New York City. Clearly lower Manhattan is the place to leave the coordinate, but most of the city is to the North and East of that. I'd think that using dim exclusively would tend to show too much of New Jersey and miss parts of NYC entirely. While scale could be adjusted to show the whole city, but still include too much New Jersey (I'm sure there's joke opportunity here...). And I think many populated places along a body of water would naturally have this problem (e.g Philadelphia, San Francisco), but not all (e.g. London). What's really missing here is that we'd like to center the displayed map somewhere other than the cultural center listed as the primary coordinates. OK, what's really missing is bounding box polygons, but perhaps a secondary coordinate would be much simpler for the interim.

Upon further reflection if the various mapping sites don't support the concept, then it's probably moot to add a second coordinate. However it might be useful to allow both scale and dim to be set, with dim recording the actual dimension and pass scale to the mapping service to get the whole asymmetric object on screen.

Another example are concave objects, such as the canal park along a big river bend that wraps around half my village. The "center" there isn't even in the object. (Always amusing when the GPS plotter puts the "City Park" tag near my condo a km away.)

Guess I'll leave the village dim-less for now. --J Clear (talk) 15:15, 4 January 2010 (UTC)

Taking a tape-measure to your village is probably overkill.

I believe that the sole purpose of dim: is to set the viewport (i.e. scale) for maps of the geocoded object or region. As such, it needn't be precise. I doesn't even need to indicate the actual size of the subject.

While in many cases dim: approximates the largest diameter, in others it is much larger. For instance, if the coded latitude/longitude is not centrally located (i.e. the mouth of a river, the capital of a nation, etc.) then the dim: ought to be about twice the distance to the furthest point. And if the subject is small (i.e., a building) or isolated, then the viewport should include nearby features to provide context. --Stepheng3 (talk) 17:37, 4 January 2010 (UTC)

I used a km long virtual tape measure. However I was less concerned about the dimension than what, if anything, can be done for asymmetric regions. --J Clear (talk) 03:06, 7 January 2010 (UTC)

My tape measure comment was tongue-in-cheek. In all seriousness, the coordinate specified needn't be the center. And if you set the dim large enough to encompass the entire region (when the viewport is centered on the coordinate) you've probably done right by the end-user. I think it's probably better to show too a bit too much than to cut off part of the region. --Stepheng3 (talk) 04:55, 7 January 2010 (UTC)

More region code analysis

I've now built my own regioncheck-like tool, using binned versions of the GNS and GNIS datasets as a reference for country coverage. Here are some stats, based on the most recent (and already well out of date) dump:

There are 868536 geolinks in the en: Wikipedia, of which there are:

• ~283732 geolinks without any region: field, and
• ~584810 with a parseable region: field, (these two don't quite add to the total above because of edge cases in parsing) of which there are:

• 1110 with a region: tag, but no region coded
• 2360 with uppercase region codes that are in ISO 3166, but look suspicious
• 527 with uppercase region: codes that are not currently part of ISO 3166 (some of which I've broken down by code -- many of these are simple systematic errors)
• 261 with lowercase region: codes that look accurate
• 3 with lowercase regions codes that don't (all already fixed)

and all the others are most probably right, suggesting a lowerbound on the error rate for the region: tags that existed as of the time of the dump of around 0.7% -- and perhaps 50% of these remaining errors look as if they may be capable of being resolved automatically.

You can see some reports generated from this data on these pages.

I see that (mostly) User:Stepheng3 and (also) a number of other editors have fixed a lot of these already! I've just begun to realize just how valuable this work is in terms of generating information about political geography. -- The Anome (talk) 03:37, 6 January 2010 (UTC)

Geotags with uppercase region parameter, region=others seems to find problems with valid ISO 3166-1 alpha-2 codes, such as Guam - GU and the Northern Mariana Islands - MP. What's with that? --Tagishsimon (talk) 23:32, 6 January 2010 (UTC)

I'm planning to re-code these as US-GU, and US-MP respectively: I'm currently working on adding these and the other US-xx sub-codes to the analyzer. -- The Anome (talk) 15:20, 7 January 2010 (UTC)

Region code for Kosovo?

Since Kosovo does not have an ISO 3166 code at the moment, what region: code should we use for places in Kosovo? See User:The Anome/Geotags with uppercase region parameter, region=CS for a breakdown of some of the cases in question. -- The Anome (talk) 14:21, 6 January 2010 (UTC)

It's POV to suggest that Kosovo is not part of Serbia ... but on the other hand it's also POV to suggest that it is part of Serbia. So you've unearthed a thorny issue. I honestly don't know what's best, but as the United Nations (and presumably ISO) still consider Kosovo to be Serbian, then I would suggest using the code for Serbia. This will not please everyone of course. Bazonka (talk) 19:34, 6 January 2010 (UTC)

When a new country is attempting to form, I try to err on the conservative side -- i.e. which country the territory belonged to a couple years ago, since it's likely that other mapping services are (at least) that far out of date. The functionality provided by the region code is minimal; if you're seriously worried about NPOV, you can safely omit (or delete) the region code. --Stepheng3 (talk) 23:06, 6 January 2010 (UTC)

I'm going to go with code RS-KM, which is the valid ISO 3166 subregional code for RS that exactly matches the claimed territory, and will make it easy to re-code if/when Kosovo gets its own code. -- The Anome (talk) 15:14, 7 January 2010 (UTC)

Need help/advise...

The article Bethsaida has a link to et-Tell. The problem is that from the descriptions of the two sites they are two widely different locations, and this seems to be born out by the geo-coordinates given. I would edit-out the link myself except I'd like my conclusions double checked by experts (well... more expert than myself, anyway). Thank you, Shir-El too 09:24, 15 January 2010 (UTC) P.S. See comments on the discussion page too. Cheers!

I've weighed in at Talk:Bethsaida. There's a lot more wrong in the article than merely the link; I suggest a solution (probably involving a rewrite) is called for. The link is the least of the problems. --Tagishsimon (talk) 03:17, 26 January 2010 (UTC)

What am I missing?

I've been doing a few corrections from Category:Talk_pages_requiring_geodata_verification and I keep running into talk pages where someone has gone to the trouble to note the error and put the correct coords on the talk page, but hasn't gone on to correct the article page and remove the {{geodata-check}} template. I'm not objecting, just confused and wondering if there's something that I don't know about or don't understand. I'm consequently concerned that I'm somehow goofing up by making the corrections I'm making. Could someone provide enlightenment? Best regards, TRANSPORTERMAN (TALK) 16:32, 2 February 2010 (UTC)

A lot of users don't know how {{coord}} works and how to change the geographical coordinates of an article, so they make the request or respond to another user's request. I don't see anything wrong with taking their coordinates and using them in the article if you think they're correct. --Mysdaao ^talk 18:36, 2 February 2010 (UTC)

That's right, there are people who are worried that they might do something wrong (mutters stuff about computers on TV). This gives them a way of still contributing. Although, I'd check to make sure the coordinates weren't overly precise and they usually pull them from Google Maps which is known to sometimes have some errors in its imagery. Also, on inspection of Template:Geodata-check/report editintro, I fixed the v-d-e that overlaid the [show] link making it impossible to click to read the rest of the instructions. — Dispenser 03:13, 4 February 2010 (UTC)

Thanks, I was just afraid I was sticking my nose into something I didn't entirely understand. Now if I can just remember to insert edit summaries... Regards, TRANSPORTERMAN (TALK) 03:27, 4 February 2010 (UTC)

{{coord missing}} now accepts Indian state names as arguments

Support for Indian states has now been added to the {{coord missing}} system.

You can now use either "India" or the name of an Indian state as a parameter for the {{coord missing}} tag. This will automatically add it to one of the sub-categories of Category:India articles missing geocoordinate data, and will also work seamlessly with all the other geolocation management tools. For example, to add an article to Category:Delhi articles missing geocoordinate data, just put {{coord missing|Delhi}} at the end of the article.

As part of this process, the existing, but incompatible, Category:Indian location articles needing coordinates tree has been emptied of articles by converting all of them to use the new tag support, and should now be considered deprecated in favor of the new use of state names as parameters to {{coord missing}}.

A bot is currently working on automatically recategorizing around 12,000 articles currently tagged as {{coord missing|India}} into their respective Indian state subcategories.

Note that these new categories are hidden categories. To view hidden categories, one needs to activate them in Special:Preferences. Under "Misc", there is "Show hidden categories". -- The Anome (talk) 15:12, 7 February 2010 (UTC)

Para's tool and geocoding progress

First, I'd like to say thanks to Para for all their help on geocoding, and make it clear that the following is not intended as a criticism of either them or their excellent work.

Unfortunately, the coord missing tool is now way out of sync with the current state of missing coordinates. Currently, it reports 182,737 articles with {{coord missing}}, whereas the category itself reports only 172,416 articles in Category:All articles needing coordinates. Most articles where coord missing has been removed after geocoordinates have been provided are being missed by the tool; for example, I've recently geocoded over 800 Japanese railway stations, none of which seem to have shown up on the tool's lists, and I'm sure the same is true of many of other people's edits.

This gives a discouraging impression that geocoding activities have slowed down significantly. In my bot runs, I see quite the reverse -- more than half of all geocodable articles are already geocoded before my bot can get to them, which is a huge improvement on how things were even a year ago.

At the same time, we are nearing saturation on the tagging of geographical articles without coordinates (except for a few feature types I have deliberately held back on), so I believe that the backlog indicated by the category count is pretty close to the true state of affairs.

I've dropped a note on Para's talk page asking for assistance. -- The Anome (talk) 16:22, 24 February 2010 (UTC)

Something seems to have happened on 2009-12-04, as the db has 172642 removals marked for that date, yet the viewer doesn't show the date at all. The query that feeds the database doesn't handle more than one addition and one removal of the template in any single article, so something like this would probably break the counts from there on. There can be some slow drift as well; I'm not sure if page moves or deletions are handled properly. Upside is that I've still got the hourly query results of all coordmissing pageids since the tool was created, so if anyone wants to make a multi-maintainer tool out of this, or to recreate the db and viewer, it shouldn't be too difficult. I'll try to have a closer look at some point as well, or maybe just reimport everything. --Para (talk) 23:21, 24 February 2010 (UTC)

Kenilworth railway station

Wonder if someone can take a look at Kenilworth railway station article, an IP has identified a problem with the label displayed on Google maps. The coordinates on the article appear to be correct showing a location in Warwickshire yet when looking directly at Google maps the station is shown as being in Suffolk, at 52.34191°N 1.572232°E / 52.34191; 1.572232. Has anyone any idea what is going on here? Keith D (talk) 22:56, 7 March 2010 (UTC)

Many of the labels on Google maps are misplaced or otherwise inaccurate. It's Google's problem, not ours. In this case, they seem to have put the label at an east longitude when it should be at the corresponding west longitude. Deor (talk) 23:16, 7 March 2010 (UTC)

(edit conflict) Ah, you're referring to the link from Google Maps rather than the link to Google Maps.

The article was corrected when the missing minus sign was added to the longitude parameter on 17 January 2010 and the GeoHack links all seem fine now, but it looks like Google hasn't updated its cache. Maybe they don't check for changes of sign alone, or maybe they are just slow to update.

I've updated the coords to move them slightly closer to what seems to be the former (and proposed) site of the station, and rounded to 4 decimal degrees so as not to be overly precise. Not sure whether this will help Google Maps to notice that their link needs updating, but it can do no harm!

— Richardguk (talk) 23:51, 7 March 2010 (UTC)

As Deor noted, google have an east-west transposition problem with some of our coords. It's their problem, and leaves very many UK locations sitting in the North Sea. There's further discussion here. It's been broken for quite a long time and shows no sign of being fixed. It is a problem of google's making, and we have no apparent means of fixing it. And, really, it's a bit crap. --Tagishsimon (talk) 00:29, 8 March 2010 (UTC)

Thanks for the pointers to what the problem is. Keith D (talk) 01:55, 8 March 2010 (UTC)

Can't see any examples of Google getting it wrong except where a Wikipedia article itself has (within the past few months) either also been wrong (minus sign incorrect) or has unconventially used negative degrees east (when the template should be called either with signed global degrees: -180 to 180, or with non-negative degrees east or west: 0 to 180 E/W). — Richardguk (talk) 02:59, 8 March 2010 (UTC)

Tz database - geolink the list of 400 lat-long pairs in ISO 6709 format

The tz database is the most common resource for information of time offset from UTC. It contains zone identifiers, ISO 3166-1 alpha-2 country codes and coordinates.

#...
# Latitude and longitude of the zone's principal location
#     in ISO 6709 sign-degrees-minutes-seconds format,
#     either +-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS

Data stored: Template:Tz/coordinates

Is there a way to turn these coordinates into links to the geohack site?

Example of a page that might use such a link: Asia/Novokuznetsk. TimeCurrency (talk) 21:30, 10 March 2010 (UTC)

I can do this using my bot. I've downloaded the file (which is in the public domain). A quick sampling of articles at random from the list suggests that most of these already redirect to articles with geocodes, but it can't hurt to check that none have been missed out. I'll have a go at some point in the near future. -- The Anome (talk) 00:19, 11 March 2010 (UTC)

I wanted that templates can handle ISO 6709 "+-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS". The current redirects to existing articles do not help here. Maybe Template:Tz/latitude and Template:Tz/longitude in a format that geohack can handle need to be created. But this is duplicating the data in Template:Tz/coordinates, which I better like to avoid for better maintenance. The tz data is updated quite often, so the process to do the update here should be very simple. TimeCurrency (talk) 01:26, 11 March 2010 (UTC)

See my comment below.--Stepheng3 (talk) 19:39, 11 March 2010 (UTC)

Germany railway stations without geocodes

I've now managed to get the number of German railway station articles without geocodes to below 50; see User:The Anome/German railway stations still missing coordinates for the list of those remaining. Would anyone be interested in helping to code some of the last few remaining stations? -- The Anome (talk) 00:40, 11 March 2010 (UTC)

Done. Fischbek station and München Hirschgarten station are too new to show up on the Google Maps satellite views; but Bing shows the former under construction, and the information in the article was sufficient to pinpoint the latter more or less exactly. Deor (talk) 15:01, 11 March 2010 (UTC)

Add full ISO 6709 support to Template:Coord

Template:coord should have full ISO 6709 support.

Currently accepted per project page are

D|MM|SS.S|NS|D|MM|SS.S|EW   {{coord|57|18|22.5|N|4|27|32.7|W|display=title}}
D.DDD|NS|D.DDD|EW           {{coord|44.112|N|87.913|W|display=title}}
-D.DDD|-D.DDD               {{coord|44.112|-87.913|display=title}}

where "-" means - has to be written, but + can be ommited
NS North/South, EW East/West

ISO 6709 defines

±DD.DDDD±DDD.DDDD
±DDMM.MMM±DDDMM.MMM
±DDMMSS.SS±DDDMMSS.SS

TimeCurrency (talk) 02:48, 11 March 2010 (UTC)

Also supported is:

D|MM.M|NS|D|MM.M|EW   {{coord|51|12.5|N|4|27.3|E|display=title}}

Have you thought about how to implement this? As far as I know, Wikimedia templates don't support parsing strings in this fashion, which is why {{Coord}} uses the stile ("|") to separate parameters. --Stepheng3 (talk) 19:36, 11 March 2010 (UTC)

I converted the data with some regex and added it to the new template:tz/coord. The data is now stored close to the coord format, e.g. "05/19/N/004/02/W" But neither "|" nor {{!}} were accepted. It would be good if geohack could accept data as one string. -D.DDD|-D.DDD is two strings, but for DDMM only the selfmade pipe splitting is accepted. Standards are there to make life easier. If GeoHack would follow ISO 6709 editing would be much easier. I have no idea what technology is available in mediawiki to help. Is there any string splitter that at least could process strings similiar to "05/19/N/004/02/W"? TimeCurrency (talk) 01:49, 12 March 2010 (UTC)

GeoHack is independent of {{Coord}}, so you can generate GeoHack links without using {{Coord}}. GeoHack uses underscores ("_") between parameters. GeoHack is written in a real programming language, so it's capable of parsing strings.

I admit I don't understand what you're hoping to accomplish here. Perhaps what you want from {{Coord}} is a new output format (alternative to format=dms or dec) rather than a new input format?--Stepheng3 (talk) 17:50, 12 March 2010 (UTC)

Bottom link proposal for Template:Infobox mountains

It has been proposed by Stepheng3 that {{Infobox mountain}} use the {{coord}}'s {{{notes}}} parameter to display a link in the title line to a bottom note. See an example here. This discussion is at Template talk:Infobox mountain. It is proposed that this style be adopted by all templates which include coordinates. –droll [chat] 10:19, 17 March 2010 (UTC)

Precision and precedence

In this edit, I reduced the precision of coordinates for a 13Km-diameter feature from 7 to 6 decimal places (on reflection, I realise that I could have reduced further). I was reverted, and it has since been claimed that, since the 7-dp coordinates are from a cited source, that has precedence over the Wikipedia guidelines on coordinates precision, which require rounding to fewer decimal places. What do others think? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:59, 17 March 2010 (UTC)

As a matter of principle, I would hope that our guidelines take precedence. However, this particular example does not seem like a high priority for the WikiProject, given that we have plenty of coordinates with 16 dp precision to work on. --Stepheng3 (talk) 17:12, 17 March 2010 (UTC)

The change was reverted due to WP:V. Policy takes priority over any guidelines. The number was changed from one directly supported by a reference to one which was not. In a comment Mr Mabbett left on my talk page, he says he doesn't like USGS numbers because of their level of precision. But that is not a Wikipedia editor's decision to make. The coordinate precision recommendations apply to making one's own coordinates from a map or GPS. If the number is supported by a source, especially a widely accepted one like USGS GNIS as it was in this case, using the source's numbers will keep it verifiable for other editors. If the numbers don't match, you'll waste people's time going forward as they check whether the change was vandalism or good faith. Ikluft (talk) 17:23, 17 March 2010 (UTC)

Rounded coordinates can still be verified from the original source via a routine calculation.

In the case of GNIS coordinates, there's also a partial workaround because everywhere GNIS gives decimal-degree coordinates (to about 1 cm precision), it also provides them in dms format, rounded to something like 30 metres precision. We can choose the more appropriate precision without resorting even to routine calculations. --Stepheng3 (talk) 17:42, 17 March 2010 (UTC)

Please don't misquote me; I said no such thing. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:05, 17 March 2010 (UTC)

OK, fair enough. No misrepresentation was intended. But the quote was "inanities of the GNIS" so displeasure with them was understood to be a factor. Ikluft (talk) 18:55, 17 March 2010 (UTC)

Yes; I thought the GNIS were being inane, because I believed your explanation (I paraphrase) that they were providing a single set of 7dp coordinates for a 13Km-diameter feature. But that's not the case, is it? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:50, 17 March 2010 (UTC)

Per Stepheng3, rounded coordinates can still be verified from the original source via a routine calculation. We do not want inappropriate 7dp coords, and policy should not be misused to force us to have them. Nor should we have to be dragged through a policy versus guideline hedge before being allowed to do the patently obviously right thing. --Tagishsimon (talk) 19:55, 17 March 2010 (UTC)

I have some vague ideas on this subject. It might be that, in the future, high precision becomes the expected norm. How those values are displayed is another question. Decimal degrees with nine decimal places should not be displayed, IMHO. I generally use DMS format it overcome this. There is, I think, a valid question about the coordinates of large areas. I suppose agencies like GNIS have some algorithm they use to centralize the coordinates. I don't know much about it. Defining the location of a city or state might not require high precision. I do think we have some duty to our sources. I know others disagree. If GNIS gives seven decimal places then I think there is no crime in reflecting that in stored data. How that data is formatted for display is, I think, the important issue. I would support a DM format option for decimal degree data. I also would like to see a format option for displaying DDMMSS.sss that rounded to seconds. The point is that information storage and display are not the same. This was alluded to in the discussion above. –droll [chat] 22:58, 17 March 2010 (UTC)

GNIS gives degrees, minutes and seconds. For most things, more than four decimal places is overkill. I've been planning for some time to do a bot run to reduce these kinds of excessively precise coordinates. I would suggest that five decimal places (of degrees) or one decimal place (of seconds of arc) is the absolute maximum we should expect to support for any article. Now we have an up-to-date dump, I'm willing to do a bot run to round off these figures, if desired. -- The Anome (talk) 23:16, 17 March 2010 (UTC)

Did you read my comment above? Also Geohack converts all input to six decimal places. What is your rational for only four place precision. On what kind of articles are you proposing to revise or is the revision to be indiscriminate? –droll [chat] 23:52, 17 March 2010 (UTC)

Doesn't appropriate precision depend on the object? I usually round off the POV of an urban photo (in Commons) to thousandths of a minute. Another decimal or even two more would be appropriate for a life-sized statue, if available, while even unsubdivided degrees are arguably overkill for a continent or especially an ocean. Jim.henderson (talk) 00:52, 18 March 2010 (UTC)

Appropriate precision does depend on the subject. The guideline that kicked off this discussion (Wikipedia:WikiProject_Geographical_coordinates#Precision) suggests "one tenth the size of the object, unless there is a clear reason for additional precision". The question under discussion is what to do when a source provides (what we consider to be) excessive precision. --01:24, 18 March 2010 (UTC)

Oops! Yes, I should read the links, not just the text here. On the question at hand, about faithfulness to source or to Wikiprinciple of precision, I offer no advice. Jim.henderson (talk) 04:41, 20 March 2010 (UTC)

So: would someone like to fix the coordinates on Victoria Island structure (lest I be accused of edit-warring); noting the additional discussion on its talk page, about the fact that the cited source doesn't support the coordinates as used? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:33, 19 March 2010 (UTC)

Usability of GeoTemplate

Comments on the usability of {{GeoTemplate}} (the page listing mapping services found by clicking on coordinates in articles) are invited, at Template talk:GeoTemplate#Usability redux. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:33, 17 March 2010 (UTC)

GeoGroupTemplate problem?

{{GeoGroupTemplate}} has stopped working for me (by which I mean that I get the error message "File not found at http://toolserver.org/~para...." when I try to access a multiple-location Google map, and the error message "This content is not available. It may have been deleted by the author" when I try it with Bing). The problem seems to have started sometime between 18:15 and 23:30 UTC yesterday, 23 March, as it was working for me at the former time. Is this a problem with my computer or a failure of some sort on the toolserver end? Deor (talk) 13:23, 24 March 2010 (UTC)

Never mind; it's working again. Must have been a transient glitch. Deor (talk) 16:10, 24 March 2010 (UTC)

The links fail quite often, in fact. I'd been assuming that the failures were due to load or lag on the toolserver in question, but I have no proof. --Stepheng3 (talk) 17:25, 24 March 2010 (UTC)

Google is impatient with requests that take the tool longer to process. When Google gives up waiting, they cache the result of that request as failed. If the user is impatient as well and keeps on refreshing the failed page, Google seems to cache it even more persistently. A watched kettle etc... Bing behaves similarly with quick timeouts, though I haven't noticed this caching problem with them. This was briefly mentioned at Template talk:GeoGroupTemplate#Long-list-warning option needed too. So I have now changed the template so that it will first have the content parsed, and then ask Google just to fetch it. That option of the tool hasn't seen much use[2], so there will probably be bugs with some obscure option used on some page. --Para (talk) 20:24, 24 March 2010 (UTC)

When it wasn't working for me, I tried using it from a variety of articles, some containing only two or three geocoded locations. That's why I was concerned (along with the fact that similar glitches in the past turned out to be a sign that my computer was infected with a virus). Deor (talk) 13:58, 26 March 2010 (UTC)

Use by iPhone apps

Our geotagging is being used to find "nearby" articles, by several iPhone apps, according to the Signpost article "New commercial Wikipedia iPhone app reviewed". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:16, 24 March 2010 (UTC)

Almost all of these services use http://geonames.net btw. —TheDJ (talk • contribs) 23:37, 24 March 2010 (UTC)

And how do they get from there to Wikipedia articles? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:55, 24 March 2010 (UTC)

Geonames' explanation —EncMstr (talk) 06:35, 25 March 2010 (UTC)

Google Street View links

I have two questions: are links to Google Street View locations appropriate external links to Wikipedia articles? (examples: [3], [4]) And if they are, should we expect the links to become outdated? I don't know if GSV links can be construed as a search result, as GSV is a subset of Google Maps/Google Earth. But there is a user who has a goal of including these links to articles about New York City Subway stations. Tinlinkin (talk) 01:39, 26 March 2010 (UTC)

As I mentioned in the linked Project talk page, I think yes they count as EL, and yes they are good links. However, after a bit more thought, it seems to me a template such as Template:Gsvlink is the better way to implement these ELs. If the Google interface changes, this will allow a central way of handling the change rather than scurry around to find and kill or repair a multitude of broken links. If other map sites such as Bing Maps develop similar views, a template may allow a quick way to take advantage.

They are still just links, and when the linkage changes, all the articles need to be edited. If you search for GSV links from before 2008 for example, none of them seem to work. It would be better to have a template that takes the values of the url parameters and then constructs a link from those, so that any changes at the service's end would be easy to fix with a single template edit. --Para (talk) 21:54, 27 March 2010 (UTC)

I don't think they're appropriate, when we're not linking to other services that provide geotagged images, and when Google Street View coverage is too big and complex to mirror in our articles of landmarks. Or is it? Could there be a project for adding some tags to articles if their object is visible on GSV, and similarly for all the other street view services?

Seeing as people are adding them anyway, I think we should reformat them and make the added information as reusable as possible. The links, even with the Gsvlink template, are currently just raw links and the information can't be used with anything else but Google Street View. As they however are parametric, we could instead have editors provide a camera location and direction, as sort of a "best viewed from" location (most likely converted from a link given by GSV). The French Wikipedia has fr:Template:Google Street View that constructs links from that information. This way we could have a template or a GeoHack-like more complex application link to GSV and possibly other services, as mentioned at Wikipedia:WikiProject Council/Proposals/Street View#There can be more than one.

Alternatively, editors could just provide the coordinates of the object, if it's not already in the article. Google and probably others can then show images of that location, like at Wikipedia talk:WikiProject Geographical coordinates/Archive 25#Linking to panoramic views (or [5] with the first example here). --Para (talk) 21:54, 27 March 2010 (UTC)