Wikipedia talk:WikiProject Geographical coordinates

From Wikipedia, the free encyclopedia

Geographical coordinates WikiProject Geographical coordinates is of interest to WikiProject Geographical coordinates, which encourages the use of geographical coordinates in Wikipedia. If you would like to participate, visit the project page.


Archive
Archives
Archive 1 Archive 2 Archive 3
Archive 4 Archive 5 Archive 6
Archive 7 Archive 8 Archive 9
Archive 10 Archive 11 Archive 12
Archive 13
Index


Contents

[edit] To do

To-do list for Wikipedia:WikiProject Geographical coordinates: edit · history · watch · refresh
  • Use Maybe-Checker: verify and/or add coordinates to articles in categories likely to need coordinates.
  • Make better examples, also showing use of decimals and scale.
  • Add an attribute for other planets and the moon and probably also star maps.
  • Extend NASA World Wind support to include layers (by type) and labels.
  • Convert existing data to templates
    • identify special formats not yet converted, e.g. E12 23 54 N23 34 52

[edit] 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 (USGS GNIS: 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.[1] 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)

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)

[edit] 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))

[edit] 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)

[edit] 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 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 / -36.75083, 174.91917 (Motutapu Island) 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. [1]
61 Bastion Point
[Russian scare]		 36°50′43″S 174°49′29″E / -36.84528, 174.82472 (Bastion Point) 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 / -36.75083, 174.91917 (Motutapu Island)

 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. [2]
61 Bastion Point

36°50′43″S 174°49′29″E / -36.84528, 174.82472 (Bastion Point)

 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)

[edit] 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)

[edit] 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

[edit] {{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. SpencerT♦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. SpencerT♦C 17:49, 23 March 2008 (UTC)

[edit] 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)

[edit] 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.[2] -- SEWilco (talk) 15:08, 22 March 2008 (UTC)

Wow, that's sweet! SpencerT♦C 11:03, 25 March 2008 (UTC)

[edit] Automatic archiving

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

[edit] 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)

[edit] Č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 Č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)

[edit] 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? SpencerT♦C 21:50, 27 March 2008 (UTC)

Seems to now have been fixed, but the Gihtsejiegŋa article still cuts it a bit close. SpencerT♦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. SpencerT♦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... SpencerT♦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)

[edit] 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. SpencerT♦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

[edit] 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. SpencerT♦C 23:00, 16 April 2008 (UTC)

[edit] 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)

[edit] 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)

Y Done I have fixed it. SpencerT♦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. SpencerT♦C 23:10, 28 April 2008 (UTC)

[edit] 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)

[edit] Tools

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

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). SpencerT♦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)

[edit] 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)

[edit] 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

[edit] 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. SpencerT♦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. SpencerT♦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

[edit] 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)

[edit] Globe

Resolved. Appears to have been rectified.SpencerT♦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. SpencerT♦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. SpencerT♦C 23:46, 30 May 2008 (UTC)


[edit] 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