Jump to content

Wikipedia talk:WikiProject Geographical coordinates: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Why must coordinates be on compulsory display?
Line 1,390: Line 1,390:


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. --[[User:Geronimo20|Geronimo20]] ([[User talk:Geronimo20|talk]]) 20:15, 27 February 2008 (UTC)
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. --[[User:Geronimo20|Geronimo20]] ([[User talk:Geronimo20|talk]]) 20:15, 27 February 2008 (UTC)
:{{sofixit|Coastal fortifications of New Zealand}} [[User:ZabMilenko|Zab]] ([[User talk:ZabMilenko|talk]]) 20:35, 27 February 2008 (UTC)

Revision as of 20:35, 27 February 2008

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

To do

News from Wikipedia-World

Thanks to all helpers! Now we are supporting over 200.000 articles in Wikipedia-World.

New is the support of thumbnails-previews in Google Earth, see Link or Screenshot. Unfortunally we can't use images from english Wikipedia, the reason is the "fairuse" licences of some pictures. An other new feature is the possibility to show only articles without a photo (Link), so you have a chance to plan your next photo-safari in your surrounding area. --Greetings from Germany and sorry for my bad english. de:Benutzer:Kolossos --12:31, 31 May 2007 (UTC)

Good job! For a more accurate photo safari, free geocoded images from Commons are also available (as opposed to images used in geocoded articles), on Commons:WikiMiniAtlas or the Commons Google Earth layer, but the amount isn't even close to Wikipedia-World yet. You can help on Wikipedia by using the Maybe-Checker, or on Commons by geocoding any good image. --Para 19:08, 31 May 2007 (UTC)[reply]


Possible manual geodata errors

See User:The Anome/Possible manually-generated geodata errors for a subset of entries from User:The Anome/Geodata error triage that have been flagged as errors by the KML user community (via the Google Earth Data Problems Compendium page), but have never (as far as my records show) been edited by the Anomebot.

Some of these will already have been fixed, but they should all be checked by hand just in case.

In the meantime, I have been working on further triaging and fixing of the entries in User:The Anome/Possible bot-generated geodata errors, of which I have currently fixed about 80%. -- The Anome 10:39, 4 August 2007 (UTC)[reply]


New template: {{geodata-check}}

A new template, {{geodata-check}}, now provides a way of marking pages as having possibly erroneous geodata. Its only effect is to add pages to Category:Pages requiring geodata verification, and to provide a place for putting hint information in its "was" and "suggest" parameters -- it does not make any visible change to the page content.

The intent of this tag is to call for manual supervision. Bot edits should only be made to fix pages listed with this tag if they are very low risk edits, with some form of verification available from an independent data source. I've now tagged all the pages reported as dubious by the Google Earth users' group that I have not personally fixed, either with bot edits, or manually.

Most/many of these are now fixed, but this is a trial run for this mechanism: please remove the tag from pages which can be verified as already correct or have already been fixed, or correct the coordinates if they are incorrect.

This tag is intended to be bot-friendly, and will be integrated into the Anomebot system soon. -- The Anome 09:18, 13 August 2007 (UTC)[reply]

It would be good to have a reason or source for the doubt mentioned in the template, with a date of the comparison included. When the bot has a suggestion already, it would also be good if it compared that against the current coordinates. Cairns Central for example was tagged with this template suggesting a fix of coordinates that had been done two months earlier already. --Para 14:21, 27 August 2007 (UTC)[reply]

New template: {{geodata-request}}

The experimental template {{geodata-request}} is intended to be used to flag pages that should have geodata, but are not yet tagged with any of the coordinates templates. Unlike the now-deprecated {{LocateMe}} tag, it is intended to be placed in the article body: it does make any visible change to the article, other than adding it to a category. This tag is intended to be bot-friendly, and will be integrated into the Anomebot system soon. -- The Anome 10:22, 13 August 2007 (UTC)[reply]

Since when was LocateMe, or other templates in that family, deprecated? Andy Mabbett | Talk to Andy Mabbett 11:09, 13 August 2007 (UTC)[reply]
The idea behind this tag is to be discreet, and not to bother regular readers with large banners or boxes in the article. People didn't like {{LocateMe}} being stuck in the article for this reason, so {{LocateMe}} got chopped out of a large number of articles, and put on the talk page instead. In my opinion, putting maintenance tags on talk pages adds an extra level of complexity which I'd rather avoid unless strictly necessary. If we want to put a page in a category, we should put the page into the category. It's easier for bots, and easier for people. -- The Anome 11:12, 13 August 2007 (UTC)[reply]
Agreed. Categories should be on articles not talk pages. Having an additional locateme banner on the talk page itself wouldn't be bad, however. --Gmaxwell 20:30, 13 August 2007 (UTC)[reply]
There's no reason (other than the dogged insistence of one editor) not to have a discrete template like {{LocateMeText}} on articles; it's no different, to, say, {{ISBN}} or {{listdev}}. Andy Mabbett | Talk to Andy Mabbett 20:38, 13 August 2007 (UTC)[reply]
The obvious difference is that {{ISBN}} and {[tl|Expand list}} are referring to visible things which are already in the article. They're asking for improvements to article text. Asking for the addition of something which is not in the text is somewhat different, but for a location-oriented article there is an implied location in the article. This difference should be emphasized in the usage instructions. For non-location-oriented articles the requests for additions should be in the Talk page. (SEWilco 21:24, 13 August 2007 (UTC))[reply]
The above phrasing "it does make any visible change to the article, other than" seems contradictory. Does it need correction? (SEWilco 20:33, 13 August 2007 (UTC))[reply]


Question about which coordinates system to use

I was wondering which coordinates system between Template:Geolinks-US-streetscale (and the related ones) and Template:Coord (or any others) is the best one to use for tagging stuff? I had been tagging a few things, but I noticed that some stuff is tagged one way and some is tagged the other. (among other ways) Thanks. (Cardsplayer4life 17:08, 18 August 2007 (UTC))[reply]

Initially, articles had neither coordinates on one of the top corners nor links to the WikiMiniAtlas. Then the geolink-templates were the easiest way to get to a map. Coordinates could only be added somewhere in the article.
After the {{coor title dm|a1|a2|N/S|b1|b2|E/W|type:landmark_region:US}} was introduced, it was added to the some articles through existing geolink templates.
To add new coordinates, I'd suggest using {{coor title dm|a1|a2|N/S|b1|b2|E/W|type:landmark_region:US}} or one of the similar templates. -- User:Docu
How is that different from {{coord|12|34|N/S|45|33|E/W|type:landmark_region:US|display=title}}? (SEWilco 18:06, 27 August 2007 (UTC))[reply]
It uses 6 characters and 7 templates less. -- User:Docu
Definitely. It also makes my head hurt less. (SEWilco 04:37, 28 August 2007 (UTC))[reply]

Agreed, the coor title or coord templates are better. The geolinks templates add too much clutter to the "External links" section, their title display format is non-adjustable and IMO not very user friendly, and most importantly, I don't think you are really geocoding an article when using geolinks. Don't think Google Earth recognizes these tags as geocoding anyway. --GregU 05:22, 28 August 2007 (UTC)[reply]

In defense of geolinks --- Originally, when Egil made the first version of the geohack server, it used the region parameter and the type parameter to limit which maps to show. When Egil's server died, and the geohack moved over to toolserver, that feature was lost. That's when I became a big fan of geolinks --- geolinks shows a small number of links that are useful to a reader, instead of forcing them to wade through a large list of map for countries that are not relevant. Sadly, since then, the habit of using the region and type parameters has been lost.
I strongly encourage people to use both {{coord}} and geolinks until 1) geohack parses the region and type parameter to remove irrelevant maps, and 2) someone runs a bot over uses of {{coord}} and inserts relevant region and type parameters (this may be difficult). hike395 05:33, 28 August 2007 (UTC)[reply]
But you can't use both, as both try to display coordinates in the title area. It might be nice if you could use geolinks in a way that only displays inline, so that use of geolinks does not prevent you from geocoding the article with coor(d). --GregU 13:15, 28 August 2007 (UTC)[reply]
What we do in the Mountains wikiproject is use {{coord}} without the display=title parameter in the infobox, to let geolinks display in the title area. If you think this is a bad idea, you could propose a change to {{geolinks-start}} to accept an optional "notitle" parameter, but you would have to touch all of the geolinks templates to call it (and take their own "notitle" parameter. hike395 14:23, 28 August 2007 (UTC)[reply]
Yeah, the problem with that is without the display=title, you are no longer effectively geotagging the article. See [1]. The notitle may be a good idea... --GregU 15:51, 28 August 2007 (UTC)[reply]
It means that at present Google Earth might not know about all the available information, but the article may contain geotags. Wikipedia can use the coordinates in List of Registered Historic Places in Kings County, New York in several ways, including by Wikipedians going to the locations and getting material for articles. Google might not be recognizing the redlinked locations because there are no geotagged articles, but Wikipedia readers (I think we also include map-oriented users as "readers") and editors can use the coordinates. (SEWilco 19:19, 28 August 2007 (UTC))[reply]
Seems to me that Google should parse {{geolinks-start}} in addition to {{coord}} with display=title. The earth.google.com link seems to think that coord is the only form of geotagging, which is not true. hike395 04:10, 29 August 2007 (UTC)[reply]
Google must have been mislead somehow, as {{coord}} is neither the main nor the only template for coordinates. In the past, it appears that the FAQ read the Google is parsing them, but practically didn't do so. Possibly this has changed now. -- User:Docu

Coord RfC

There is a request for comment at Template_talk:Coord#Request for Comment to annotate coordinates on Wikipedia for use as a title in map services and microformat readers. As it's related to this wikiproject, opinions would be appreciated. --Para 10:52, 19 August 2007 (UTC)[reply]

The RfC has concluded and "|name=" has been added to {{coord}}. (SEWilco 15:33, 4 September 2007 (UTC))[reply]

Template:French commune

The users of the {{French commune}} template are enthusiatically adding geodata to articles on French communes. Unfortunately, they're doing it in a way that does not use the geodata templates, and stops my bot from adding its own coordinates. I had a go at fixing this from within the template, but couldn't get it to work. Can someone else have a go at fixing this, please? -- The Anome 15:03, 9 September 2007 (UTC)[reply]


The template uses coordinates mainly through one of the following sets of fields:
  1. "lat_long" appears to hold the usual coordinates templates (mainly {{coor dms}}). I fixed a few exceptions.
  2. "latitude", "longitude": in the French version this is a decimal value that renders as a link. In July, [2] the fields mixed DMS format, decimal and combined versions in the same field. To make things work, there are about 1200 articles with fields in text form such as 43° 42' 14" N or 45° 15" N (45.27) that could be converted to the "45.27" format.
  3. "lon-deg", "lon-min", "lon-sec", "lon", "lat-deg", "lat-min", "lat-sec", "lat". This is used in the German wikipedia to generate coordinates. I removed two occurrences present in the July dump.
-- User:Docu

Version 1 should now use {{coor dms}}/{{coor dm}}/{{coor d}} and display a second set of coordinates in the top corner of the page if it's defined. I removed instances of {{coor at dms}} and {{coord}} to avoid conflicts, a few may still exist with geolinks templates. --- User:Docu

Wikipedia use of coord

I found another use within Wikipedia for the geographical coordinate tools. In pages such as Wikipedia:Requested pictures, adding geographical coordinates makes it easier to see if requested items are near you. In the Talk page there someone has inquired about mapping members of a "need" Category, but that's beyond the ability of the present tool. (SEWilco 17:35, 17 September 2007 (UTC))[reply]

Good idea, I extended the tool. It uses the database to find category contents and the rarely updated dumps to find the coordinates of the articles. Now what people have to decide is how to put the link on category pages, or if it's sufficient to just mention the tool somewhere and have people copy and paste category names to it. GeoHack has the link already, but most category pages don't have coordinates and putting a dummy one on them wouldn't make much sense. This is the first time I think using a template like {{GeoGroupTemplate}} would actually be justified. --Para 23:56, 17 September 2007 (UTC)[reply]

Progress on standardization and other goals?

As I'm relatively new to this project, I'd like to know the progress on this project's goals. It doesn't really seem like {{coord}} is the completely accepted template. My idea would be to show the most used links when you click the coordinates. There would be a little box pops up below them and shows links to them. You wouldn't have to leave the page. There would be a link to show all the links on a different page. Also, when will there be an option in your preferences to select between the decimal and dms form of showing coordinates? Psychless 23:50, 18 September 2007 (UTC)[reply]

What do you mean by "most used"? Coordinates for which people use map tools? Some map tools show all the coordinates on a page so the individual coordinates are never clicked on. And for what encyclopedia use is it helpful to know which locations are clicked on? (SEWilco 05:22, 19 September 2007 (UTC))[reply]
You misunderstood me. When I said "the most used links", I meant the links that are generated by the Geolinks templates. Psychless 22:57, 19 September 2007 (UTC)[reply]
What meaning of "used" are you using? (SEWilco 04:39, 20 September 2007 (UTC))[reply]
Are you asking for information to appear in encyclopedia pages about "used" links, or were you asking about how many times each template is being used? (SEWilco 16:31, 20 September 2007 (UTC))[reply]
Let me rephrase my idea. Clicking the coordinates takes you to the geohack page which has links to many websites that will give you a map, satellite image, etc. of the place you were reading about. If you use one of the Geolinks templates it gives you links to Google Maps, Map Quest, etc. Most people use those websites for maps and satellite images. With my proposal, the links generated by the geolink template would be in the box. There would be a link that would take you to the geohack server that shows the full list of links. That way, it would be easier to find the link you want without wading through 100 links. It also eliminates the necessity of using {{coord}} or equivalent and geolinks. You would just need to use coord. Psychless 22:04, 20 September 2007 (UTC)[reply]
I wrote such a script on Commons once, to add the links to the coordinates box used there: commons:MediaWiki:Geolinks-US-hoodscale.js (for example from this to this). It's opt-in though, but since the WikiMiniAtlas already hooks on coordinate links, we could generalise that and make the Javascript do more. It could for example fetch a heavily cached and pre-parsed version of Template:GeoTemplate. --Para 19:04, 23 September 2007 (UTC)[reply]

See also commons:User:Dschwen/coordinates.js which makes finding the coords to use quite easy, paste a google maps URL in, and it sticks a template into the curenntly being edited article. Requires a change to your monobook as currently written but may be useful to thought start things. ++Lar: t/c 20:39, 23 September 2007 (UTC)[reply]

Currently used templates

Here is a list of the (approximate) current usage of geodata templates, and some recommendations for standarization. (I've already removed a number of other templates which either had very low usage levels, or were caused by typos.)

Template Number of matches Suggested action
{{coor}} 327 upgrade to {{coord}} now
{{coor URL}} 8 upgrade to {{coord}} ASAP, then delete template upgrade direct use in articles to {{coord}}, no action with template use
{{coor at d}} 346 nothing as yet
{{coor at dm}} 885 nothing as yet
{{coor at dms}} 1275 nothing as yet
{{coor city}} 1 in only 1 article: fixed
{{coor d}} 9152 nothing as yet
{{coor d Antarctic}} 32 used in only 3 articles; upgrade to {{coord}} ASAP, then delete template
{{coor dm}} 18718 nothing as yet
{{coor dm Antarctic}} 12 used in only 2 articles; upgrade to {{coord}} ASAP, then delete template
{{coor dms}} 58874 nothing as yet
{{coor title}} 1 in only 1 article: fixed
{{coor title d}} 8999 nothing as yet
{{coor title dm}} 39046 nothing as yet
{{coor title dms}} 25701 nothing as yet
{{coorHeader}} 2281 upgrade to {{coord}} now
{{coord}} 33820 none
{{coordinates}} 10 no actual geodata uses remain: delete template redirect now

-- The Anome 15:25, 20 September 2007 (UTC)[reply]

I changed the above from list format to a sortable table. (SEWilco 16:07, 20 September 2007 (UTC))[reply]
The suggested actions sound like good ideas. Replace those little-used variants. (SEWilco 00:25, 23 September 2007 (UTC))[reply]
How updated is this? S♦s♦e♦b♦a♦l♦l♦o♦s (Talk to Me) 20:08, 1 December 2007 (UTC)[reply]

More discussion moved further down to #Geolinks:_redirect_or_not?

Some more bad data

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

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

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

Providence_(comics) edit says 120N,165W.[3] Anyone have X-Men #200 handy? (SEWilco 05:14, 22 September 2007 (UTC))[reply]
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))[reply]
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)[reply]

Data mining infoboxes

As of the most recent article data dump, Wikipedia had 166420 articles containing geodata tags and/or infoboxes with embedded coordinates (infoboxes without parsable coordinates don't count; figures for geotags may differ from those given above because the counting basis is different) Of these 166420:

  • 124200 (74.6%) have just a geotag or geotags
  • 19921 (12.0%) have just an infobox with embedded coordinates
  • 22299 (13.4%) have both a geotag and an infobox

Thus, combining these:

  • 146499 (88%) overall have at least one geotag
  • 42220 (25.4%) overall have at least an infobox

(Last two figures do not sum to 100% because they include the 13.4% overlap from the earlier figures)

Although I believe the Kolossus project takes infoboxes into account, I believe that infoboxes without geotags are not parsed by third-party reusers such as Google. If we were to datamine all the parsable infoboxes in articles that do not yet have a geotag, and convert them to use geotags, we could increase the total number of easily source-code-parsable geotagged articles by 19921, from 146499 to 166420, an increase of 13.5% over the current count.

The effect to external reusers would actually be more noticeable than this, because we should be able in almost all cases to take infobox coordinates as representing the one, true, location of the subject of the article, allowing them to be tagged as "display=title,inline".

However: this is not at easy as it might at first seem, because there are many non-standard infobox formats with different parameters, some with nasty features such as implicit East/West or North/South directions, which will cause simple-minded bot scans to generate bogus coordinates, and many of these templates are themselves misused, and contain garbage or non-standard data.

Getting all of these cases right, with appropriate sanity checking and cross-checking, is going to need to be a lengthy, measured, process; shortcuts will potentially generate large amounts of bad data, which would be counterproductive.

First step: finding all the currently used infobox templates with provisions for coordinates, and categorizing them. Does anyone have a list?

-- The Anome 22:24, 22 September 2007 (UTC)[reply]

I think I saw discussion of assorted infoboxes recently, probably in Template talk:coord. (SEWilco 04:25, 24 September 2007 (UTC))[reply]
By standardizing infobox fields to the suggested names (lat_d, lat_m, lat_s, lat_NS, long_d, long_m, long_s, long_EW) extraction would be made easier. It may mean adding lat_NS, long_EW if this was implied before. -- User:Docu
I did a quick list once based on the parent category and template names, but the participation in looking them through was discouraging. --Para 16:30, 26 September 2007 (UTC)[reply]
As the above names were defined not that long ago, it's likely that we will need to update quite templates to standardize the names.
If there is another set that is used more often, I'd go for that.
-- User:Docu
Also, I've noticed that the Google Earth layer ignores images embedded in infoboxes, instead displaying later images in the article. Fixing this would be a nice aesthetic improvement. --Padraic 00:38, 24 October 2007 (UTC)[reply]

Wikipedia London Placemarkers on Google Earth

Whilst I haven't done a very thorough search, it seems that in my part of North London, the only places showing up with placemark links to Wikipedia on Google Earth are those where a co-ordinates template has been manually added. The co-ordinates info seems to be generated through the infobox, but it seems to be done in a way that the Google Earth scrape doesn't recognise. (To see why I think what I think, compare Crouch End with, say Muswell Hill or Harringay). All railway & tube stops seem fine, although their coordinates also seem to be generated through one of the templates. I tried adding the Coordinates template manually, but it seems to overwrite most of the infobox and make it disappear. Anybody know more about this and how to fix it? hjuk 21:53, 25 September 2007 (UTC)[reply]

For anyone who's interested, I think the answer may at Template talk:Infobox UK place/Archive 4#Google Earth compatibility: geotags are invisible hjuk 11:34, 26 September 2007 (UTC)[reply]

To standardize the infobox, I'd convert it to use "lat_d" and "long_d". -- User:Docu

Tibetan places on the wiki map

Hi I've recently been adding the Tibetan towns and villages to wikipedia complete with coordinates. However the titles of the new villages I have been adding aren't showing on the wiki mini atlas in the globe. If you look at Tibet on the map only the larger places like Lhasa, Dhingri, Shigatse, Golmud etc are showing when it ought to show the titles of smaller places like Alamdo, Azog, Baicang etc and tens of others i have been adding when you zoom in. PLease can you help me because I am trying to draw up a detailed map of Tibet as I add these articles but they are just not registering as places on the map ♦ Sir Blofeld ♦ "Talk"? 09:38, 26 September 2007 (UTC)[reply]

On Alamdo, the longitude designation "E" is missing from the coordinate. I see it is being specified in the template parameter, so someone needs to look at the template. (SEWilco 15:53, 26 September 2007 (UTC))[reply]
I fixed Lhasa and Alamdo by including {{coor title dm}} and {{coor at dms}}. However, I think we should update {{Geobox Settlement}} to display the coordinates on the top corner of articles. This would avoid adding the coordinates once more. -- User:Docu

Free maps tool for article maps?

Not long ago someone pointed out that some of the maps being generated by Wikipedia-linked mapping tools could be usable in Wikipedia articles. Issues have arisen in Template talk:Infobox UK place where a map with a red dot marking a location would be helpful. That template is using existing tools, but are there better tools? Does the not-supported-in-en:Wikipedia <geo> extension have this ability? Are there existing free map tools which could be used to create locator maps? Generating maps on demand might have problems; might a tool/bot be able to create maps into Commons (in a reserved namespace perhaps?) which could be used in articles? (SEWilco 16:20, 3 October 2007 (UTC))[reply]

Does the toolserver already have a map generator with country outlines, whose maps could be placed under a Commons-compatible license? That would be sufficient for some locator maps. (SEWilco 19:12, 8 October 2007 (UTC))[reply]
Note that "Red dot" location maps are already available for many countries at {{location map}}. These can also be called via {{infobox settlement}} and its derivatives. Jheald (talk) 15:22, 24 November 2007 (UTC)[reply]

UserBox

I think that WP:GEO should have a UserBox. I have no clue how to make one, so if someone else could it would be wonderful. --Nick4404 02:41, 6 October 2007 (UTC)[reply]

Formatting problem

Currently, coordinates displayed using the {{coord}} template are being displayed as "52°28′59″N 1°53′37″W": they should surely be displayed as "52° 28′ 59″ N 1° 53′ 37″ W" instead, with spaces between the degrees, minutes, and seconds groups and the compass direction. -- Karada 10:35, 6 October 2007 (UTC)[reply]

That's a style issue. I see {{coord}} points out [[Wikipedia:Manual of Style (dates and numbers)#Geographical coordinates]] but that merely says to use a template, without explaining why this format was chosen for the template's display. I think this is a case where the relatively narrow text windows of most browsers places a greater priority on using a narrower format, thus the symbols between numbers are being used as visual separators in place of the more grammatically correct spaces. People who actually made those decisions would have to state the actual reasons (there might be discussion in the old Talk pages here but more likely in MOS, coord, or coor). The reasons for the current design should be mentioned in the MOS. (SEWilco 05:07, 7 October 2007 (UTC))[reply]
In the archives of this talk page, there are lenghty discussions about various formats. -- User:Docu

Infobox audit

I've now written some auditing tools for templates, and have been running them on the most recent en: dump. The first result of this process is User:The Anome/Infobox audit, which tries to spot plausible uses of geodata-related parameters in Wikipedia templates, other than those using the standard coordinate templates.

Clearly there is a lot of standardization work to be done. -- The Anome 22:54, 10 October 2007 (UTC)[reply]

Geobox mention?

Should the {{Geobox}} family be mentioned on the project page? I haven't found where they are all described. And the template Talk page mentions a box conversion tool which may be of interest. (SEWilco 21:40, 16 October 2007 (UTC))[reply]

Google Earth

How come the link at the top is no longer one of a satellite image provided by Google Earth like it used to be? Wikipediarules2221 20:48, 18 October 2007 (UTC)[reply]

At the top of what page? (SEWilco 21:09, 18 October 2007 (UTC))[reply]

Geobox question in VP

A {{Geobox}} question appeared in Village Pump: [4] (SEWilco 17:07, 25 October 2007 (UTC))[reply]

Bug report: WikiMiniAtlas/infobox interaction

Here's an interesting bug. Go to Shillong, and take a look at the locator dot on the map in the infobox. Now pop up the WikiMiniAtlas from the title line globe -- even though the WikiMiniAtlas now covers the infobox, the infobox's locator dot remains visible over the WikiMiniAtlas, complete with a popup-on-hover title of "Location of Shillong". This is confusing, and might well lead some readers to mistake the (completely arbitrary) location of the locator dot on the WikiMiniAtlas map for the actual location of Shillong. In the case of Shillong, this is particularly misleading, because the label link for the Shillong article does not appear on the WikiMiniAtlas as the default zoom, and the infobox locator dot is more salient than the translucent red splodge used as default locator by the WikiMiniAtlas.

This can also be seen in other suitably-aligned instances of {{Infobox Indian Jurisdiction}}: for example, see Babina and Jaipur. (Browser info: Firefox 2.0.0.8 running on Debian Etch.)

I don't know if this is specific to {{Infobox Indian Jurisdiction}}, or a symptom of a more widespread bug with locator maps in general: the templates used within that infobox are so intricately nested that I'll have to leave this to someone more expert with debugging WP templates. -- The Anome 09:50, 26 October 2007 (UTC)[reply]

Probably someone just cranked up the z-index of the infobox-locator-point unreasonably high (z-index inflation!). That should be corrected in th elocatormap/infobox source. The WikiMiniAtlas uses a z-index of 10 or 20 I think, and there is no reason for a locator point to have a z-index above let's say three. --Dschwen 14:04, 26 October 2007 (UTC)[reply]
Oh geez, that was exactly it. The infobox used a z-index of 200! I set it to 2 (and 3 for the dot) and it still works fine. Plus the WMA related bug is gone. --Dschwen 14:13, 26 October 2007 (UTC)[reply]

Template:Geolocation abandoned

I think Template:Geolocation was unused and is now orphaned and abandoned. Should it be nominated for deletion? (SEWilco 15:39, 26 October 2007 (UTC))[reply]

I've nominated it for deletion. -- The Anome 11:58, 27 October 2007 (UTC)[reply]

WPcoord

I created Template:WPcoord, rephrase it as appropriate. I avoided WPgeo due to similarity to the Geology project. (SEWilco 15:52, 26 October 2007 (UTC))[reply]

Coordinates for Group, Linear and Area items

Is there any way of tagging an article with coodinates for groups, linear objects or area objects? E.g:

Perhaps these could be investigated for future inclusion? --Ozhiker 19:36, 26 October 2007 (UTC)[reply]

This was discussed on the german project, on [[:commons:commons:Geocoding], and on Template:coord before. I'm all for it.... --Dschwen 15:20, 27 October 2007 (UTC)[reply]

Coord loc on VP

Someone notes in VP [5] that title coords have moved to a bad place. The reference to Jimbo implies that the reader has the normal fundraising banner visible and a browser window which is 800 pixels wide (a common width). Even without the fundraising banner, the present location above the line puts the coordinates in conflict with article titles. The location below the line was better due to the shorter and smaller text ("From Wikipedia,...") on the left side of the page. I think this same issue is in a template Talk archive, I'm sure I've seen it before. (SEWilco 14:33, 1 November 2007 (UTC))[reply]

Oh, I see. The CSS is using absolute positioning of the coordinates. So when the fundraising banner is present, what is on the left depends upon whether the banner is large or small. When the fundraising banner vanishes the header will get smaller and the coordinates will again be below the header horizontal line. (SEWilco 20:12, 1 November 2007 (UTC))[reply]

Geotagging software for Linux?

Anybody know the easiest way to geotag photos in Linux (preferably drag and drop on a map instead of manually adding coords). In Windows, I love Picasa+Google Earth, but the Linux version of Picasa doesn't seem to have this feature. --Padraic 16:07, 5 November 2007 (UTC)[reply]

There is a Wikipedia tool for Google Earth which shows the current location. Maybe there is a similar tool which shows a text balloon with whatever text has to be pasted in a photo tool...or provides a geotagging URL for Picasa. (SEWilco 06:12, 8 November 2007 (UTC))[reply]
Or I can write a similar tool, if there is some sort of URL or text which the server could emit which would be useful in geotagging. I'm not familiar with the Picasa interface, but I think I saw some sort of Picasa web service so can geotagging be done through their web service? (SEWilco 04:57, 12 November 2007 (UTC))[reply]
I just noticed that there is an addon for digiKam.[6] [7] (SEWilco (talk) 20:33, 23 November 2007 (UTC))[reply]
Thanks for the tip - I will have to try out the digiKam addon. Too bad I can't get Google Earth working in Ubuntu anymore! --Padraic 21:51, 23 November 2007 (UTC)[reply]
I think Linux GE needs OpenGL and there is no version for 64-bit Linux. (SEWilco (talk) 16:39, 29 November 2007 (UTC))[reply]

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

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

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.

About being marked as Spam (Hu12): I was not aware of this strict external link policy. I fully comply to this policy and agree that this is the best way to avoid Wikipedia to become a link farm. Since this was the first time that I was editing Wikipedia and I started this discussion before I added a few (as I thought useful) links, I ask for rehab and to be removed from the spam list. Spamming is really not my intention.

Since my (study) project (wikitude.org) is actually a visualization of Wikipedia articles with Google Maps I request being listed in "Visualization of Wikipedia articles with Google Maps". Joos23 22:29, 10 November 2007 (UTC)[reply]

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

Template lacks

Gentlemen, you lack the following templates:

The user sees 24°N 120°E / 24°N 120°E / 24; 120 and when they click, it's just as if they clicked 24°10′54″N 120°51′58″E / 24.18170479°N 120.86603958°E / 24.18170479; 120.86603958. I.e., a way to set display precision.

The user sees GREAT LOCATION and when they click, it's just as if they clicked 24°10′54″N 120°51′58″E / 24.18170479°N 120.86603958°E / 24.18170479; 120.86603958. I.e., a way to set display title.

Jidanni 01:32, 10 November 2007 (UTC)[reply]

For precision see WP:GEO#Precision. Otherwise, shouldn't all coordinates be shown as such? If not, which type of coordinate use needs a more compact presentation? What would be the rule or guideline for the formatting, so that it's not up to single editors? What about printed articles; would the coordinate information just be excluded? If it's that insignificant, should it really be included at all? See also Wikipedia talk:WikiProject Geographical coordinates/archive012#Inline coordinate display and the linked previous discussions. --Para 15:39, 10 November 2007 (UTC)[reply]

Geolinks: redirect or not?

What about all the Geolinks templates? There are many articles that have coordinates in Geolinks format only. I don't know if there's a way around the people who want to keep the links to map services in the articles, so how about just duplicating the data to a known format? Many of the Geolinks articles already have another coordinate template. --Para 18:42, 23 September 2007 (UTC)[reply]
According to Category:Geolinks templates the main page for that group is Wikipedia:Coordinate-referenced map templates. You might rais issues in that Talk page (and tickle past participants). I see that Template talk:Geolinks-start directs people here. (SEWilco 03:08, 24 September 2007 (UTC))[reply]
Personally, I'd favor merging the geolinks templates with one of the other templates above (preferably {{coor title d}}). -- User:Docu
Good idea. This seems the active place for discussion but we're not hearing comments. Maybe one or two of the lesser-used geolinks should be converted, with the summary directing comments here. (SEWilco 05:47, 26 September 2007 (UTC))[reply]
My opinion: it is a good thing if Geolinks calls {{coord}} with display=title, in order to geotag articles, but please don't delete the Geolinks themselves. hike395 06:12, 26 September 2007 (UTC)[reply]
Are you aware that the map links displayed by Geolinks are redundant and minimalist, as clicking on any {{coord}}inate provides a wider selection of mapping tools? Some of those tools are better for certain tasks than are the Geolinks list. (SEWilco 15:29, 26 September 2007 (UTC))[reply]
The minimalist solution may be appropriate for some subject matters, but, in general, I think the mapsource list is indeed preferable.
Compared to earlier version, just adding {{coord}} doesn't do that much, it just adds a lot of overhead. Earlier versions of the geolinks templates already displayed coordinates in the top (left) corner. -- User:docu
By "adding coord" do you mean "adding coord to articles" or "adding coord to template Geolinks"? (SEWilco 17:08, 27 September 2007 (UTC))[reply]
"adding coord to template Geolinks" hike395 mentioned. -- User:Docu
Indeed, I believe that the minimal obvious list of maps provided by Geolinks is a service to our users. Geolinks shows the most common links that people want: I often want to click directly on topozone for USian articles, rather than having to scroll down thru 2 pages of not-terribly-relevant links on geohack. Again, if geohack parses type and region and filters the list, then I would be much happier and Geolinks can go away at that point (as far as I am concerned). Thanks for listening! hike395 02:48, 28 September 2007 (UTC)[reply]
The problem with the minimalist solution is that it's likely to supply the link everyone wants (e.g. Google Maps) and the one you'd want (e.g. Wikimapia), but not everyone else prefers.
As Google Maps is easily accessible on Template:GeoTemplate, there isn't much of a reason to include it on geolinks as well. For the later one, it might just be worth to improve the organization of Template:GeoTemplate. For a quick map, we still have WikiMiniAtlas. -- User:Docu

At Template:Geolinks-US-cityscale/Test, I made a version to update Template:Geolinks-US-cityscale, what do you think of it? Try replacing, e.g. {{Geolinks-US-cityscale|42.027335|-93.631586}} with {{Geolinks-US-cityscale/Test|42.027335|-93.631586}} to test.-- User:Docu

Are the Geolinks no longer supposed to show up in "External links" sections? If so, this should be discussed--the change is going to leave hundreds of empty external links sections and will need cleanup. I'd prefer the links show up. (example: Abert Rim) Katr67 17:03, 10 October 2007 (UTC)[reply]
As I understand it, from its inception, coor title d, used on Abert Rim, was designed to "place the coordinates in the upper-right of the article, just below the horizontal rule running under the article's title" - that from the first version of the template. In the case of Abert Rim, seems to me that the external links heading relates to the commons|Abert Rim template, which places a right justified link box. So I'm not convinced that any change has been made which removes inline coordinates (but others may know better). I note that templates such as coord have parameters facilitating the placement of the coordinates inline at the point of the template. --Tagishsimon (talk) 17:18, 10 October 2007 (UTC)[reply]
Ooops! Sorry, bad example, I do mean the Geolinks templates. I'll find a better example. Abert Rim's external links section is empty for some other reason... Katr67 17:40, 10 October 2007 (UTC)[reply]
I think Abert Rim's External Links is not empty, but the only thing in it is a Commons template. That template is usually placed in External Links. (SEWilco 17:46, 10 October 2007 (UTC))[reply]
Yes, I see that now. I tend not to "see" the commons template for some reason. It would be nice to have an option to move it left if the section is otherwise empty. Katr67 17:48, 10 October 2007 (UTC)[reply]
Here's one I wrote recently: Bull Run, Oregon. I use Geolinks templates all the time, and I like having the minimalist links at the bottom. I think it helps our readers, as hike365 said above. I think this a major change and it may need to be discussed in a larger venue, it there's an appropriate place for it. Katr67 17:44, 10 October 2007 (UTC)[reply]
It's one of the stated goals of this WikiProject to do away with external links to maps ("4. Should be able to have a uniform, extensible way of accessing all types of map resources, avoiding having direct external links to maps in articles")
If the few empty section headers are perceived as a problem, I could go through removing them.
BTW, replacing {{commonscat}} with {{commonscat-inline}} shifts the commons link to the left. -- User:Docu

Thanks for the help with the commonscat. So this change is a done deal? I can't say that I like it, but I sense there's no use fighting it. I still think this should be discussed outside this project, but oh well. There will be more than a few empty headers but if this is indeed irrevocable, then please do take on the cleanup. I'll probably stop using the template, BTW, and let the bots handle coord duties. It was nice while it lasted. Thanks again. Katr67 18:54, 10 October 2007 (UTC)[reply]

I see that we have this decision to do away with the links. Could we please temporarily have a reversion to the with-links form, at least for a few days, until the empty section headers are removed? Many thousands of US place articles (enough that would take Docu many days to do, working 24-7) have an external links section with nothing except the mapit template; as someone who watches place articles for vandalism, it's highly confusing because it looks as if someone vandalised the external links. I definitely would appreciate it if someone wrote a bot to go around and remove all of those now-empty sections. Nyttend 00:53, 11 October 2007 (UTC)[reply]
I strongly object to removing the links. It may be a stated goal of this project, but other WikiProjects are expecting these links: see, e.g., Wikipedia:WikiProject_Cities/Guideline, where these links are recommended.
This is a large enough change to Wikipedia where it requires more community input: I do not believe that we have achieved consensus --- both Katr67 and I object, and not that many people have been informed. hike395 02:20, 11 October 2007 (UTC)[reply]
Let me get this right. A WikiProject can make goals that everyone else has to abide by. Could you point me to some WikiPolicy where it says that, I can't seem to find it under WP:CONSENSUS? If you get the sarcasm, well then here is some more reson why that arguement is tossed and the reversion needs to happen until there is consensus:
Consensus decisions in specific cases are not expected to override consensus on a wider scale very quickly - for instance, a local debate on a Wikiproject does not override the larger consensus behind a policy or guideline. The project cannot decide that for "their" articles, said policy does not apply.
That comes from an actual WikiPolicy, WP:CONSENSUS. You see, otherwise another wikiproject can decide something else, and then another something else, and so on until you have twenty different rules for say a biography about a killer from Chicago, Illinois who went to Columbia University and was a botanist. That's six projects making rules for one article, and that's not how it works. Being bold is one ting, but even WP:BB has a caveat to be less bold when dealing with templates, since they can affect many articles. Aboutmovies 03:29, 11 October 2007 (UTC)[reply]
If everyone agrees that we should have them, obviously we should keep them. -- User:Docu
I think we should attempt to come to a consensus: let's have a wide discussion about this. I don't think we should wait for "everyone" to agree --- please please please revert until we reach consensus. It's the WP way. hike395 17:20, 11 October 2007 (UTC)[reply]
I agree. Personally, I find it much easier to click directly on a Google Maps link, rather than going first to yet another page, which loads slowly for me here in North America, and is sometimes down. More discussion, please! -- Ken g6 21:54, 12 October 2007 (UTC)[reply]

The way coordinates are handled is very different now from when the geolinks/mapit template was first created. The map source page is now on the toolserver (it used to be on kvaleberg). In addition, there is a link to WikiMiniatlas on every coordinate. This is much more than we had when we first added the coordinates with geolinks. -- User:Docu

Several WP probably have standards which were written based upon the technology which was then available, just as Census 1990 might have been defined as a standard source before Census 2000. We should point out the coordinate-embedded map tech to the other WikiProjects. These last two paragraphs should also be split off to a new topic at the bottom of this page so it can be linked to for discussions. (SEWilco 15:10, 11 October 2007 (UTC))[reply]
I'll repeat what I've said before. When Egil's original geohack page was made, I was one of the first to argue to ditch the geolinks. But, Egil's page was more functional than the current geohacks page on the tools server. It paid attention to the "region" and "type" parameters, to filter down the list of links to relevant ones and to set the scale of the maps. This functionality is gone.
Right now, you have to wade through pages of irrelevant links to find a relevant map. This is very user unfriendly. Take my own browsing behavior as an example: I love to look at topo maps for geographical locations in the US. If I click thru to the geohacks page, I have to scroll down past pages of links. If I use geolinks, I can immediately go to the topo maps for USian spots, and the scale is set correctly.
My proposed compromise is: if geohacks is modified to do the right thing with "region" and "type" (i.e., if region is given, then show the country-specific maps first, then the worldwide maps), then we can redirect geolinks to point to geohacks.
Thanks for your attention. hike395 17:28, 11 October 2007 (UTC)[reply]
P.S. I would also suggest the geolinks never be a true redirect, in order to avoid the empty external links problem. I would recommend keeping it at one line, that says something like
*[http://tools.wikimedia.de/whatever Maps and photos] of {{PAGENAME}} at Wikimedia Tools server
But, you can eventually get rid of the direct links to maps. hike395 17:38, 11 October 2007 (UTC)[reply]
Seeing what others have said since my previous comment, I'll note this: I strongly oppose the removal of these links in the first place, and request their restoration. Nyttend 18:01, 11 October 2007 (UTC)[reply]
Hike395, I'm not sure if I understand you in relation to "Geolinks-US-cityscale". Prior to conversion, this included "Maps from WikiMapia, Google Maps, Live Search Maps, Yahoo! Maps, or MapQuest Topographic maps from TopoZone or TerraServer-USA"". These are easily accessible on the top of Template:GeoTemplate. Why would you need additional support for regions? -- User:Docu
Docu: Topozone is not easily accessible, it's four pages down, or an additional click. And it's even worse for Switzerland: I was working on Swiss mountain pages for a while, and was looking at a Swiss topo map server a lot: the Swiss topo map link is 9 pages down for me. It seems bad enough to make readers click thru once to the Geotemplate (I can sort of live with that), but twice? Just to avoid implementing regions? Again, it seems reader-unfriendly to me. hike395 18:04, 12 October 2007 (UTC)[reply]
The geolinks templates have needed replacing for some time, as part of the general standardization of geodata. I'm prepared to make all the necessary edits using my geodata bot when you've improved the map interface sufficiently: just let me know on my talk page when you're ready. -- The Anome 19:26, 11 October 2007 (UTC)[reply]
Type is still taken into account; it affects the scale, which is passed on in one form or another to most of the services listed in GeoTemplate. For the region I just hacked together a proof of concept, by adding section ids to GeoTemplate and a bit of Javascript to GeoHack to shuffle a section to the top based on the region. See for example London or Paris. It will be possible later to guesstimate the region automatically from the coordinates, but that's to be implemented later. Does this solve the concerns with using the more extensive list? --Para 21:05, 11 October 2007 (UTC)[reply]
I far as I'm concerned, I would be (mostly) happy with this sort of region-sensitive Geohack. Can we implement this for real before crushing geolinks? hike395 18:04, 12 October 2007 (UTC)[reply]
It is now implemented for all coordinate links server-side. Some areas may need the region parameter added to coordinate entry. --Para 21:21, 12 October 2007 (UTC)[reply]
See User:The Anome/Geolinks audit for some quick stats on the number of direct uses of each template (NB: does not count indirect uses via other templates). -- The Anome 21:18, 11 October 2007 (UTC)[reply]
Counting all pages that use it, Geolinks-US-cityscale is used on 27,000 pages. I just did some major work on US place articles and noticed at thousands of articles (more like tens of thousands) with empty External links sections now that the Geolinks-US-cityscale template was modified. I'd like to see it contain at least one line with a link to a map so as not to break thousands of articles all at once. --CapitalR 04:42, 13 October 2007 (UTC)[reply]

Is anything happening with this? I'd like to see a single line in the external links section myself. Meanwhile, they sit there being empty. Can we decide so this can either be reverted or cleaned up? Katr67 22:12, 16 October 2007 (UTC)[reply]

There doesn't seem to be much (any?) objection to the template having only a single line: you could put a {{editprotected}} at Template talk:Geolinks-US-cityscale asking a passing admin to change it back to a single line. hike395 03:47, 17 October 2007 (UTC)[reply]
Docu interrupted that process last time. Do we have consensus with the "no links whatsoever" people? Katr67 14:17, 17 October 2007 (UTC)[reply]
Below I tried to summarize the above. (SEWilco 15:42, 17 October 2007 (UTC))[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The Geolinks and {{mapit}} templates display in articles links to a few mapping services, placed in the "External links" section (the preceding are referred to as "Geolinks" below). The recent {{coord}} templates show geographic coordinates in article text and/or on the top of an article, with links to a page with many mapping services. Using both in an article may be redundant.

  • Map service links shown by Geolinks are redundant and fewer than those available by clicking on coord's coordinates.
    • Some people prefer the Geolinks in-article links to map services.
      • Geolinks might not show the map services which a user prefers.
    • Some people prefer to reduce clutter in articles and have all mapping services on a separate page.
    • Having all mapping services on a single page makes finding a service difficult.
      • The page with all mapping services now displays at the top the links for a region when one is specified with a "region" option or found automatically based upon coordinates.
  • {{Geobox}} and other infoboxes are emitting coord-style coordinates which are linked to the page of map services. In this discussion those are discussed as if coord is being used, and alteration of Geolinks is relevant to those pages which have Geolinks.
    • Some infoboxes added coordinate usage after Geolinks already existed on pages which used the infobox, and article editors may not have been aware of the two tools.

Policies and Guidelines

There is a preference for Wikipedia to not be a link directory; it is recognized that sometimes it is useful to have a link to a directory such as DMOZ. That discourages the in-article links which Geolinks emits. The large list shown by coord is a specialized link directory, although a location-oriented service which is also not in the Article space.

It's one of the stated goals of this WikiProject to do away with external links to maps ("4. Should be able to have a uniform, extensible way of accessing all types of map resources, avoiding having direct external links to maps in articles")

Proposals

Interim proposal: Change Geolinks to emit a single line. This has been proposed as an immediate change, while the rest of this discussion proceeds.

  • Comment - addressing the concerns this is redundant: It would be little work to change the template so it shows something (even revert to the old version if it's too much work to render a single line?) and then change it again to the final version. Meanwhile, we don't know how long this process will take, and the external links sections sit there looking empty and vandalized. Why can't we just act on this while the discussion continues? This has already gone on for a week... Katr67 13:50, 18 October 2007 (UTC)[reply]
  • Support - CapitalR 21:51, 17 October 2007 (UTC)[reply]
  • Oppose - Why change it twice unless it also says there's a discussion of whether to eliminate this? dm 22:38, 17 October 2007 (UTC)[reply]
    • Comment - because the current state has left hundreds or thousands of articles with empty EL sections, and has been in discussion limbo for weeks now. Can we agree to this, at least? hike395 18:42, 21 October 2007 (UTC)[reply]
  • Oppose - If we are to replace it anyway, there isn't much use for such a intermediate solution. -- User:Docu
  • Support: The interim solution is a good compromise, while we get more input. I share Katr67's and dm's concern that there is not enough community input. hike395 10:17, 18 October 2007 (UTC)[reply]
  • Oppose -- mostly because there little point to changing twice. older ≠ wiser 12:51, 21 October 2007 (UTC)[reply]
  • Oppose - this is a really bad way of making a change (re getting more opinions - all you will get is heat - it's a method of making changes which happens too often on Wikipedia and convinces ordinary users that we're not actually interested in what they think). Orderinchaos 22:05, 23 October 2007 (UTC)[reply]
  • Strong Oppose - what a stupid suggestion. This template (and the Mapit equivalent) is really useful and does not need to be changed in any way. JRG 05:59, 24 October 2007 (UTC)[reply]
  • Support - a discussion may ensue, but it will avoid the appearance of a WP:CABAL. Walter Siegmund (talk) 03:06, 30 October 2007 (UTC)[reply]
  • Support one-line-visible fix — Invisible Mapits (which are redirected to Geolinks, remember) are causing layout breakage (empty External links) that even editors fairly familiar with Wikipedia (like me) were not told about. I'm a regular editor and yet I just discovered this accidental-blanking-looking thing just today. Templates and layout that work as expected are far more important than the desire to mass-remove information that does no harm; and apparently, whoever did this "fix" didn't get it right the first time, so let's keep it functioning like it was designed until it's actually decided for good. Add a link in small type about ongoing proposals if you want to see a discussion. --Closeapple 01:57, 5 November 2007 (UTC)[reply]

Proposed: Replace Geolinks with coord using display=title, so coordinates show on top of the page with link to map services.

Replace uses of Geolinks with a text and coord

Proposed: Replace Geolinks with a line such as *Maps and photos of {{PAGENAME}} at {{coord|...|display=inline,title}}

Discussion of the phrasing is below in section #CLICK ON COORDINATES.
  • Support - Reduces number of coordinate templates used while preserving a map service link in the external links preferred by some people. --Para 17:57, 17 October 2007 (UTC)[reply]
  • Support - Although prefer preceding replacement with coord. (SEWilco 19:10, 17 October 2007 (UTC))[reply]
  • Support - Though I don't relish getting used to scrolling through the list to find what I usually use, it's better than not having anything in the external links section at all. Will also be more useful to casual Wikipedia users. Comment - should say "aerial photos". Katr67 22:17, 17 October 2007 (UTC)[reply]
  • 'Neutral - If you did this, I'd prefer to make this somehow user configurable, the very long list of mapping services is questionable dm 22:38, 17 October 2007 (UTC)[reply]
  • Oppose This just readds redundancy. -- User:Docu
    • Partial Support It's an improvement to the (current) previous versions of the geolinks templates. 5 Dec 2007 -- User:Docu
  • Support - Comment: why replace (i.e., force a subst) Geolinks, rather than have Geolinks emit this? This seems like the best idea: I prefer this to the proposal which keeps geolinks without using {{coord}}. hike395 10:17, 18 October 2007 (UTC)[reply]
  • Support (although 'geolink' is a nice name similar to 'geobookmark') --Geonick 22:59, 20 October 2007 (UTC)[reply]
  • Oppose, although this is perhaps the least objectionable of the proposals that replace geolinks with coord. older ≠ wiser 12:55, 21 October 2007 (UTC)[reply]
  • Oppose The coord page (especially for countries such as Australia which are WAY down the list) is very hard to navigate, and the links which result are unconfigurable - it'll result ultimately in a major reduction in usability for users, and is also inflexible as the size of maps emitted by the toolserver is at the wrong scale for what we use. I'm not against streamlining/improvement of Geolinks-style templates, but this just strikes me as a faulty application of policy to support a minority's point of view which results in an imposition on the majority, who are contributing users and broadly speaking are getting sick of bureaucracy creep on Wikipedia. Orderinchaos 22:13, 23 October 2007 (UTC)[reply]
    • Question have you clicked on coordinates lately? If you use it from Australian pages, Australia is all the way on top. -- User:Docu
    • Comment The scale used with the links on the GeoHack page is configurable; unlike with Geolinks, it is not given by choosing among coordinate templates of different scale and location, but by using the single coordinate template that can be used anywhere on Wikipedia and giving it the type and/or scale of the object the coordinates are representing. Normally, only type is needed as it's reflected to many scale parameters used by various services, but in exceptional cases a specific scale can also be given. I think this and the dynamic section placement Docu pointed out solve both of the concerns mentioned. --Para 22:40, 2 November 2007 (UTC)[reply]
  • Strong Oppose. JRG 06:01, 24 October 2007 (UTC)[reply]
  • Support per Katr67 and Hike395. Walter Siegmund (talk) 03:11, 30 October 2007 (UTC)[reply]
  • Support per Para. --Dschwen 03:16, 3 November 2007 (UTC)[reply]
  • Strong Oppose. S♦s♦e♦b♦a♦l♦l♦o♦s (Talk to Me) 20:11, 1 December 2007 (UTC)[reply]

Proposed: Replace for US locations, replace Geolinks with {{gnis}} and {{coor title d}}.

Proposed: Have Geolinks emit a single line such as *[http://tools.wikimedia.de/whatever Maps and photos] of {{PAGENAME}} at Wikimedia Tools server as the new display format of Geolinks.

Both Geolinks and top-of-page coord

Proposed: Make Geolinks use coord with display=title, but continue to display in-page Geolinks links to a few map services.

  • Oppose - More clutter than needed in articles. (SEWilco 18:02, 17 October 2007 (UTC))[reply]
  • Support - More useful than going through the long list of every mapping service dm 22:38, 17 October 2007 (UTC)[reply]
  • Oppose - In general, this just adds clutter. In a few cases, a link to map specific to an article may be suitable, but in general, map links shouldn't be made through Template:GeoTemplate. -- User:Docu
  • Oppose - now that region is a useful parameter, I can live with the geohack list. hike395 10:20, 18 October 2007 (UTC)[reply]
  • Support, for the simple reason that the current toolserver pages are quite confusing at present. However, some of the geolinks templates could be trimmed down to be less verbose. If the toolserver pages settle down to a workably user-friendly structure, then perhaps the geolinks templates would be unnecessary -- but until then, no. older ≠ wiser 13:02, 21 October 2007 (UTC)[reply]
  • Oppose - Links in articles to general information services can never satisfy all the readers. This is why book sources, which all ISBNs link to, have been centralised on a single page instead of listing the "most popular" services in all articles about books. Map services are no different. Coord provides the link to the centralised list, making additional service links redundant. If the current list is confusing, report what the problem is and propose a list change. --Para 15:17, 21 October 2007 (UTC)[reply]
  • Support Isn't this the status quo? Agree with older-wiser on all counts. Orderinchaos 22:08, 23 October 2007 (UTC)[reply]
  • Neutral - I don't think there is nothing wrong with the current list, but if this is the status quo then I'm happy to support this. JRG 06:03, 24 October 2007 (UTC)[reply]
  • Support - One-click access to the maps I use, rather than having to scroll down to the appropriate section of the general map-links page. —wwoods 14:48, 24 October 2007 (UTC)[reply]

Side effect: If Geolinks no longer emits visible text in an article, a bot should be requested to move it out of the "External links" section and the section headline of an empty section should be deleted.

Discussion

I tried to summarize the issues above. I suggest cautious editing of items above Proposals. Voting-type feedback in Proposals with comments; readers remember that meanings might change a little if the preceding summary is edited, and try to avoid simply referring to a previous person's comment in case they need to change their comment. (SEWilco 15:42, 17 October 2007 (UTC))[reply]

We should invite discussion in affected WikiProjects. I'll invite ones which I find. (SEWilco 15:54, 17 October 2007 (UTC))[reply]

  • Comment How do the two single line proposals differ? Can we merge the two? Katr67 17:52, 17 October 2007 (UTC)[reply]
    • The Interim proposal is for an immediate change (I'll alter the wording). The second one-line proposal is for it to become the new format for Geolinks. An immediate change seemed to be suggested in previous discussions. (SEWilco 17:57, 17 October 2007 (UTC))[reply]
    • I don't see much difference between "Geolinks with a text and coord" "Geolinks single line" because the latter seems like an ambiguous proposal from the discussion where the exact format of the single line was not particularly important. Isn't the concept behind the two point-at-detailed-list suggestions the same? (SEWilco 18:07, 17 October 2007 (UTC))[reply]
      • The single line proposal in its current form isn't to replace the geolinks templates, but their contents. That helps only with external link clutter but not with template standardization. The other proposal of replacing with coord and text is for replacing all the uses of the geolinks template with a readable coord text. Currently many articles have an "invisible" display=title at the end, but if people prefer to see a link at the end, the "text and coord" proposal would do that. --Para 18:25, 17 October 2007 (UTC)[reply]

Deadlock

There seems to be a deadlock in the discussion of the proposals: if I can make a caricature, most of the people in this WikiProject want to change geolinks, while most of the people outside the WikiProject don't want to change.

How can this be resolved? The current state (doing nothing) isn't a consensus, but an artifact of the protected state of the template, and that most of us are not admins. Is there some compromise that can be reached? hike395 20:03, 27 October 2007 (UTC)[reply]

Whatever the answer is, please do something so that people like me don't waste 30 minutes trying to figure out what to do about empty External Links bullets like the one I found in Centralia, Pennsylvania. Jordan Brown 16:19, 28 October 2007 (UTC)[reply]
Agreed. This has dragged on for too long. Since there isn't consensus, I suggest reverting the template to its previous version until this is resolved. This may need to be brought up to the whole wiki community to break the deadlock. Katr67 16:34, 28 October 2007 (UTC)[reply]
If we follow the commonly used WP:BRD pattern, we should revert to the previous state, and then continue discussion. hike395 17:59, 28 October 2007 (UTC)[reply]
This probably shouldn't have been set up as a poll with set choices, it discourages discussion and shows yet again, why Wikipedia is not a democracy. IvoShandor 17:18, 6 November 2007 (UTC)[reply]
This was actually set up to try to untangle the many issues in the preceding discussion. (SEWilco 17:21, 6 November 2007 (UTC))[reply]

Deadlock broken

There is 7-4 support for #Replace uses of Geolinks with a text and coord (and recent changes to GeoHack might affect a Neutral and Oppose). I'll soon create a request for that change; if you have comments on the currently poor phrasing please discuss at #CLICK ON COORDINATES below. (SEWilco 20:13, 7 November 2007 (UTC))[reply]

Question: do you mean to replace all instances of Geolinks with text + coord (using a bot), or make Geolinks emit text + coord ? It wasn't clear to me which we were discussing: I prefer the latter. hike395 03:52, 8 November 2007 (UTC)[reply]
I suggest discussing that along with the phrasing at #CLICK ON COORDINATES. Because output formats is the reason templates were created, I was going to initially request changing the geolinks templates to emit the same message. This also reduces difficulties if further changes are needed. Then geolinks can be merged or replaced with text. (SEWilco 06:06, 8 November 2007 (UTC))[reply]
Changing the Geolinks templates to emit something different was proposed at #Geolinks single line and #Geolinks temporary single line. The proposal SEWilco mentioned would "replace uses of Geolinks with a text and coord" using a bot. The phrasing is to be discussed. --Para 10:35, 8 November 2007 (UTC)[reply]
I claim that the polling, above, confused three issues: the phrasing of the line, whether {{coord}} should be called or not, and whether there should be a geolinks template. I supported #Replace uses of Geolinks with a text and coord because I liked the phrasing and the calling of {{coord}}. I don't see why we have to get rid of geolinks if it simply calls coord: it's a convenience template.
In fact, I would claim that getting rid of geolinks entirely is bad for this project: without a standard template that calls coord, editors may start to drift away from the usage that you want to proscribe. It's much better to enforce uniformity through a template, rather than through guidelines. hike395 05:53, 10 November 2007 (UTC)[reply]
Yes, the several topics were entangled and split because that's what the result seemed to be of the discussion. How about starting a new topic only about retaining Geolinks with a one-line phrase? There is time for that discussion because I'll be starting with that change and not initiating Geolinks replacement&deletion until after a reasonable delay. Please comment on the one-line phrasing in #CLICK ON COORDINATES and start a separate section on whether Geolinks should be kept. (SEWilco 06:04, 10 November 2007 (UTC))[reply]
Comment: I'm not sure if having several different options is helping here, especially if you're asserting there's consensus. It's confusing and somewhat arbitrary. Perhaps you need to make it a straight poll on whether we should have geolinks, geohack, or both. Plus, 11 people sounds like a really weak population. On a tangent, I've been using the geohack page quite a bit to make sure I understand the opposite point of view. I find the lack of "scale" to be quite annoying. When using geolinks while editing articles, I've been able to pick the appropriate scale for the feature being pinpointed. I'm not sure if there's something I'm missing, but I dont see this feature in geohacks. Why are we trying to kill geolinks again? dm 05:56, 8 November 2007 (UTC)[reply]
The consensus is leaning toward replacing Geolinks with a GeoHack-using message. Yes, we haven't gotten many participants but that seems to be those who care of those who found the discussion during mention in a VP, several Projects, and several Templates. There will be time for further reaction between changing of Geolinks and their replacement. I thought I saw a scale option in coord, but I think it's now automatic based on the coordinate precision (number of digits after decimal point). (SEWilco 06:06, 8 November 2007 (UTC))[reply]
My point is that I can equally argue that 7-1 oppose #Replace Geolinks with a title coord or that we are 4-4 #Both Geolinks and top-of-page coord. I do not believe the deadlock has been broken and I suspect that the various choices have with good intentions, put us in a spot where no good decision can be made. dm 13:31, 8 November 2007 (UTC)[reply]
Yes, people who commented did oppose some options more than others. I haven't compared user names between options, but of these options there is one where there are more supporting comments than opposing. (SEWilco 15:03, 8 November 2007 (UTC))[reply]
There seems to be a common misunderstanding that scale wouldn't be supported with GeoHack. GeoHack supports scale: click on any coordinates on Wikipedia, and you'll see the scale at the top of the page, used by services that support a scale. Most coordinates on Wikipedia however do not set a scale explicitly, which might be the source of the misconception, but this doesn't mean that no scale is given at all. Most coordinates use an implied scale, that is, they set the type of the object (see Wikipedia:WikiProject Geographical coordinates#type:T and Template:GeoTemplate/doc#Scaling), which implies its size and thus the scale needed to show it on a map. --Para 10:35, 8 November 2007 (UTC)[reply]
Great, thanks for the info. Just for clarity, can someone pls confirm the proposed update to the geolinks template will automatically translate the various scales to the geohacks version so that all of those thousands of edits out there will not have been in vain? Thanks dm 13:31, 8 November 2007 (UTC)[reply]
I will be translating the Geolinks parameters in my change requests. The scale parameter will be supported. (SEWilco 15:03, 8 November 2007 (UTC))[reply]
Thanks, that would certainly help. Do we have an example that you could point to of how this would look? dm 04:30, 10 November 2007 (UTC)[reply]
There are several examples below in the section #CLICK ON COORDINATES, where I am getting no feedback on the phrasing. (SEWilco 05:58, 10 November 2007 (UTC))[reply]

Removing empty headers for the template that was already changed seems to have a lot of support as well.

We should probably not take in account "votes" of people that clearly haven't used the mapsource page recently, such as stating "The coord page (especially for countries such as Australia which are WAY down the list) is very hard to navigate". -- User:Docu

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Disenfranchising users because they disagree with you or to try to generate an artificial consensus in favour of your proposal does not conform with any standard of consensus building or good faith. I am rather disturbed at the above comment. I know this has been archived, but I was very busy with work and then on holiday for just over a month so didn't see the end of this discussion. Orderinchaos 12:33, 27 December 2007 (UTC)[reply]
I ignored that qualification comment when studying the results of the discussion because in context the criticized comment was not relevant to the results. -- SEWilco (talk) 15:42, 27 December 2007 (UTC)[reply]
I recognised that, but I was addressing the fact the comment was made to begin with, and the attitude it betrayed on the part of the user concerned. Orderinchaos 18:34, 27 December 2007 (UTC)[reply]

CLICK ON COORDINATES

The above proposed one-liner "*Maps and photos of {{PAGENAME}} at {{coord|...|display=inline,title}}" is text which looks awkward in a printed page and doesn't tell the reader CLICK ON THE COORDINATES FOR MAPS. "Maps and photos of Washington Monument at (some numbers)"? Suggestions for phrasing? (SEWilco 15:46, 22 October 2007 (UTC))[reply]

  • Comment I think you are not getting any feed back on this because it is confusing. Can you set up some "live" examples so we can better see what these will look like? Katr67 03:05, 13 November 2007 (UTC)[reply]

I'll rephrase: The grammar on the proposed phrasing (number 1 below) does not seem quite right. Is there better phrasing? The text is bolded for this example but would not be bolded in articles. (SEWilco 03:50, 13 November 2007 (UTC))[reply]

  1. * Maps and photos of Baltimore, Maryland at 39°17′11″N 76°36′54″W. (click for maps)
  2. * Find Baltimore, Maryland at coordinates 39°17′11″N 76°36′54″W. (click for maps)
  3. * Baltimore, Maryland is at coordinates 39°17′11″N 76°36′54″W. (click for maps)
  4. * Maps and aerial photos for 39°17′11″N 76°36′54″W' is the current phrasing used in Template:Geolinks-start. I think the noprint (click for maps) should be added.

For most coordinates templates, the standard span (mouse over) title already reads "Maps, aerial photos, and other data for this location" (see talk). Stating where someone should click is contrary to the concept of wiki (and HTML). In your sample, the following formating should be sufficient:

  1. * Maps and aerial photos for 39°17′11″N 76°36′54″W / 39.28639°N 76.61500°W / 39.28639; -76.61500

at least, IMHO. -- User:Docu

For that matter, if we ignore the implied meaning of the hyperlinks we end up with phrases which are not grammatically correct: Maps and photos of Baltimore, Maryland at 39°17′11″N 76°36′54″W. What makes sense is the simple statement of fact: Baltimore, Maryland is at coordinates 39°17′11″N 76°36′54″W. Maybe mention of maps or photos should be wrapped in noprint so it doesn't show up in printed copies; why mention that maps exist of Baltimore? (SEWilco 17:14, 13 November 2007 (UTC))[reply]
I like the simple statement of fact: can we proceed with substituting it? This template has been broken for months. (I think substitution with a bot is not a great idea, but it's much better than inaction and deadlock on the status quo). hike395 (talk) 05:16, 29 November 2007 (UTC)[reply]
The changes are under way. (SEWilco (talk) 02:07, 30 November 2007 (UTC))[reply]
checkY - change made, please take a look & see if this is working as you wanted. SkierRMH (talk) 06:30, 30 November 2007 (UTC)[reply]
I, for one, don't like that particular statement. It's not too bad in itself, but it's very similar to a statement frequently present in the Geography section, roughly, "{{PAGENAME}} is located at {{coor dms...}} (lat, long)". Example. That looks redundant, which is almost as bad as being empty. Even worse, some people had been putting the blank template at the end of the Geography section, which puts the redundant statements right next to each other. Since this template is/was usually in the External Links section, a single link might be better. Would it be possible to make the statement simply "*[(geohack URL) Maps of {{PAGENAME}}]", no coord template, with the whole statement a link to GeoHack? -- Ken g6 04:59, 3 December 2007 (UTC)[reply]

Accuracy of Google vs Yahoo vs Topozone vs MapQuest

I'm new at this, but when I plot coordinates, I find that each vendor points to a slightly different place. For example, I tried to aim the coordinates for Ramona High School (Ramona, California) to a large circular building in the center of the school complex. See 33°01′36.9″N 116°52′08.8″W / 33.026917°N 116.869111°W / 33.026917; -116.869111. I centered it in Google's satellite view, but off center in the others. Does anybody have any knowledge of which mapping source is the most accurate for the US? Thanks, Project Coordinates (talk) 01:46, 17 November 2007 (UTC)[reply]

I tend to use Google Earth first myself, which is the same as Google Maps, and I cross-check with Yahoo and Live Search. I'm not sure if one is consistently more accurate than another. Since they vary you probably shouldn't try to be so precise. I'd just use 33°01′38″N 116°52′09″W / 33.02722°N 116.86917°W / 33.02722; -116.86917 for this school since that is the usual precision for something of this size.
Having said that, there is one way you can get an idea of which source is the most accurate, if there is an airport nearby. The exact coordinates for airport runways are available at AirNav.com (for US airports) or at World Aero Data (for elsewhere in the world). Looking up the Ramona Airport in AirNav and testing those coordinates, it appears that the Google imagery here is about 10 ft too far SE, Yahoo is about 55 ft too far ESE, and Live Search is 12 ft too far west. So in this case at least, Yahoo is the one that is the most off, and Google is a good choice to go with. --GregU (talk) 14:16, 25 November 2007 (UTC)[reply]
Thanks! I'm going to change my username now, btw. I don't like it anymore. Project Coordinates (talk) 02:27, 17 December 2007 (UTC)[reply]

Coord/GeoHack scale

It looks like GeoHack isn't passing type/scale scaling information to the Google Earth exporting tool. GE keeps presenting a view from the default altitude. (SEWilco (talk) 18:49, 19 November 2007 (UTC))[reply]

There are two Google Earth links on that page. The first one is from de:User:Kolossos and doesn't support the scale parameter, so it always uses the tool's default altitude. He has commented before that scale makes no sense when used with a varying amount of pixels, and that the German Wikipedia currently has a mix of scale parameters and dim parameters (where dim is the dimension or diameter of the object in metres). This confusion is probably why the tool doesn't support any scale at all. The second tool a few rows below is mine, and estimates an altitude from the GeoHack scale, while also returning KML links to other resources. The additional links could be a reason enough for people to keep using the first tool instead. --Para (talk) 01:30, 20 November 2007 (UTC)[reply]
I'll compare the two URLs when I get past "Unable to connect to the server at tools.wikimedia.de." (SEWilco (talk) 05:22, 20 November 2007 (UTC))[reply]
There is a scheduled network downtime announced for tuesday morning on the ts mailinglist. This is probably it. --Dschwen 13:23, 20 November 2007 (UTC)[reply]
You're right, the first Google Earth link doesn't know about scaling. (SEWilco (talk) 16:11, 23 November 2007 (UTC))[reply]

Can someone help me?

Hi. I'm not sure if that's the right place to ask for help but if anyone here can do the thing with making parts of maps clickable? (like in the first map of the article US State) I'd like the map in the article Constantine Province clickable, with the articles (shown in the section "Adminsitrative divisions") clickable as in the map. Thanks in advance!--escondites 15:30, 23 November 2007 (UTC)[reply]

UK co-ordinate conversions faulty?

I'm not sure if this is the right place to raise this (if not, then please forward this appropriately, someone), but GeoHack's co-ordinate conversions seem to be a little bit off.

For locations in London, maps called via UK National Grid co-ordinates (eg Streetmap, GeoGraph) seem to locate places a couple of hundred metres west and north of where they get indicated on eg Google Maps using degrees, minutes and seconds.

This is somewhat disconcerting when trying to add location co-ordinates. Can we find out where the mismatch is occurring? Jheald (talk) 16:00, 24 November 2007 (UTC)[reply]

For example, for Big Ben, without decimals we have 51°30′02″N 00°07′28″W / 51.50056°N 0.12444°W / 51.50056; -0.12444, which WikiMapia places just to the East of the clock tower. Geohack converts this as TQ 30168 79678; but Streetmap, GeoGraph etc show that as the intersection of Bridge Street and Parliament Square, about 200m to the West, and 50m to the North.
Putting N51:30:02 W00:07:28 into Streetmap's own converter [8] gives TQ 30281 79624, which matches the WikiMapia position. This looks like a bug in Geohack. Jheald (talk) 09:04, 25 November 2007 (UTC)[reply]
I wonder if this is a datum issue, where one system is using the WGS84 datum to perform conversions, and the other is using OSGB36? Lat/long coordinates in Wikipedia should use WGS84 throughout. -- The Anome (talk) 09:11, 25 November 2007 (UTC)[reply]
Both pages say that they're using WGS84 for lat/long. But perhaps GeoHack is actually converting as if from OSGB36? Jheald (talk) 09:57, 25 November 2007 (UTC)[reply]
That does indeed look possible. GeoHack's grid conversion is mapping 51°28′38″N 0°00′00″E / 51.47722°N 0.00000°E / 51.47722; 0.00000 squarely to the centre of the Royal Greenwich Observatory building, when according to Prime Meridian WGS 0° should point to a rubbish basket about 102.5 to the East of the brass strip. The OSGB36 meridian is actually 6m to the west of the brass strip; and according to OSGB36 the transformation most commonly used (eg by Streetfinder?) can add another 7m error. That compares pretty closely with the 113m difference found between the two Eastings for Big Ben. Jheald (talk) 11:24, 25 November 2007 (UTC)[reply]
Just for completeness: GeoHack is translating that lat/long to TQ 38875 77313. The Ordnance Survey "gold standard" converter [9] says TQ 38987 77259. And Streetmap's converter says TQ 38989 77258. Jheald (talk) 11:48, 25 November 2007 (UTC)[reply]
I have been working to produce my own tool to convert Grid to WGS84 see OS to Wiki Templates (WGS84) Toolfor a Beta version. It was to put inlines into a page en:River Bourne. The maths is complete- I am tweaking the UI. Indeed I have a discrepancy but have not analysed it- gut feeling suggests it could be 113m too. As I used Roger Haworth's Javascript code for the clever bits- could it be that there has been a typo introduced into that or Fishers c code? ClemRutter (talk) 18:19, 25 November 2007 (UTC)[reply]
Note that the 113m is correct for London, but the discrepancy varies with longitude (as one would expect for an WGS84-OSGB36 difference). So for a point near Lands End, 50°4′7″N 5°42′58″W / 50.06861°N 5.71611°W / 50.06861; -5.71611 translates to SW 34114 25409 according to GeoHack, SW 34177 25338 according to StreetMap, and SW 34182 25340 according to the Ordnance Survey -- i.e. an East-West error of only 63m. -- Jheald (talk) 19:05, 25 November 2007 (UTC)[reply]
I've had a quick look at the Fisher convert.c code, and I think you're right: it looks like it converts from the Grid coordinates to OSGB36 using the Airy 1830 ellipsoid . But there's no way it converts to WGS84 -- there's nothing in there to define the WGS84 ellipsoid. Jheald (talk) 19:56, 25 November 2007 (UTC)[reply]
The file that will need to be fixed is geo/transmercator.php [10]. As surmised, it has a routine to convert from OSGB36 lat/long -> OSGB grid coordinates; but no routine to convert from WGS84 lat/long to OSGB36 lat/long. Somebody should also verify whether there is a similar problem for the Swiss co-ordinate system, which uses the CH1903 ellipsoid.

Bug filed on JIRA: [11]. Jheald (talk) 14:56, 29 November 2007 (UTC)[reply]

There's GPL'd PHP code that can be spliced in to do the conversion here [12] (also Java and Javascript translations). Other implementations, but in Javascript, can be found here [13] and, with explanation, here [14].
Template {{oscoor}} has a similar issue - it's converting to OSGB36 lat/longs, not WGS84 ones (see here). This code may have been used to convert a number of UK national grid references to lat/longs -- if so, they are all going to be slightly wrong. Jheald (talk) 14:06, 26 November 2007 (UTC) However, conversions done automatically by The Anomebot2 are apparently correct. Jheald (talk) 14:23, 26 November 2007 (UTC)[reply]
Thanks for that! I rather hoped that was the case. -- The Anome (talk) 18:40, 28 November 2007 (UTC)[reply]
For what it's worth, I raised this issue with RHaworth, whose external site performs the (faulty) gridref-to-latlong conversions, back in March, but he hasn't done anything about it yet. See User talk:RHaworth/Archive to 2007 April#OSGB36 and WGS84. I use http://www.nearby.org.uk/ whenever I need to do a manual conversion in either direction; I don't rely on Wikipedia's own conversions. --Dr Greg (talk) 18:07, 26 November 2007 (UTC)[reply]
I have posted a copy of the conversion code I used to do the earlier National Grid --> lat/long conversions, at User:The Anome/lat-long.py, which I hope performs a reasonable conversion from both OSGB and Ordnance Survey Ireland grid refs to WGS 84 lat/long. It's in Python, and was (mostly) auto-converted from some GPL'd code written in PHP, by a variety of earlier authors: see the original comments within the source file for its origin, and the original authors. I've done a few bits of manual cleanup to the overall program flow, but the maths is pretty much verbatim.
If anyone wants to use it, could they please spot-check a few locations, just to check that it works OK? -- The Anome (talk) 18:59, 28 November 2007 (UTC)[reply]
I've just checked Colchester Castle, which was one of your conversions, and your numbers exactly match Streetmap's conversion [15].
BTW. There's another wrinkle in {{oscoor}} -- it's adding 50m to the Easting and the Northing of a 6-figure gridref when it passes the data on to GeoHack (ie it's assuming the Gridref is indicating a 100m x 100m square to its north and east, and giving the centre of that, as if somebody has got the gridref by doing a floor rather than a round . I am not sure that is correct -- I don't think as a rule people do go to the south and west when they give map references; so I don't think {{oscoor}} should be adding those extra 50m. Streetmap doesn't, when it's doing conversions. Jheald (talk) 14:49, 29 November 2007 (UTC)[reply]
Thats not a bug- its a feature!. Wikipedia convention is to tag or reference or mark the centre of a map not the left bottom corner. The code I have been examining tags the centre of the TQ 675 123 square, not the left hand corner! So we have TQ 6755 1235! I havent had time to examine Anome s Python code other to see it is very clear and well written and should be very easy to convert into Javascript and retrofit into my code and RHaworth code. Give me a couple of days. —Preceding unsigned comment added by ClemRutter (talk • contribs) 15:23, 29 November 2007 (UTC)[reply]
ClemRutter (talk) 15:37, 29 November 2007 (UTC)[reply]
I think that's wrong. If WP has a grid reference, the map should show where that grid reference is. We don't know whether the grid reference cited was meant to indicate the gridline intersection to the bottom left of an object on the map (which is what you're assuming). It could equally well have been chosen to indicate the nearest gridline intersection. We should just convert the number. Jheald (talk) 15:42, 29 November 2007 (UTC)[reply]
Note also that there are three versions of code already in Javascript linked to above for the datum change, [16], [17], [18] (documentation). Wouldn't it be easier to start with one of those? Jheald (talk) 16:06, 29 November 2007 (UTC)[reply]
Many questions.I am trying to locate the errors, and to do it I have written a bit a code to do a fixed job. In doing so I now am suspicious of every piece of code- including my own. It is a design decision that every programmer must make as to what OSGB36 point the four, six, or eight figure refs refer to. Each is valid, it is a POV as to which one to choose, whether you floor it, round it or average it. In my tool, designed to provide a inline reference to go alongside a 6fig GridRef transcribed from 1950s reprints of 1930s reference book that had references in the form '5 furlongs NNE of the church'. When the original reference was calculated that way, it seems reasonable to use the 'average'. Personally I prefer 'floor'. There is no definitive 'number'. We are left with two approaches to these numbers.
  1. Identify the error, and patch a correction.
  2. Identify size of the error (in each case) and post process a further filter, to pull the erroneous WGS back to actual by a simple transformation using an array of constants fixed to each letter square!
ClemRutter 13:21, 30 November 2007 (UTC)[reply]
Request for control points to use as test data
Does anyone have the precise grid references, and WGS84 coordinates of a set of control points to act as testdata for the various calculations floating around. All the texts are clear that latitude and longitude can only be expressed within a margin of error, and change with height and time, so the best we can achieve is to define accuracy of each method with reference to a control point. This will apply to our method of data collection, and chosen method of data display. ClemRutter (talk) 11:26, 17 December 2007 (UTC)[reply]
I suggest we use the StreetMap conversions as our target. They are well defined mathematically, easy to check against, and correspond to within ~7 metres with the (distorted) historical grid defined by the 1938-1966 surveying. Jheald (talk) 12:09, 17 December 2007 (UTC)[reply]

Geolinks/mapit changes

The Geolinks and mapit changes discussed above are being made. (SEWilco (talk) 02:49, 30 November 2007 (UTC))[reply]

Issues:

All uses are now converted to the "statement of fact" format. Most articles had the OSGB reference in the infobox already, but some stubs had it hidden inside a map service link without being shown, so I added {{oscoor}} to those. --Para (talk) 12:27, 30 November 2007 (UTC)[reply]
Seems to be an external equivalent of GeoHack, with the added feature to see a service list for nearby landmarks as well. It's already listed in GeoTemplate and doesn't need to be advertised in articles, so we can remove it from articles that have coordinates already, or replace it with coord when there's no other coordinates. --Para 03:49, 1 December 2007 (UTC)[reply]
Orphaned. --Para (talk) 21:03, 5 December 2007 (UTC)[reply]
This will be easy to convert to use coord directly, when a bot replaces all the uses as noted below. --Para 03:49, 1 December 2007 (UTC)[reply]
The linked service is listed in GeoTemplate (#4 in the US section!), but GeoHack doesn't support the format of the scale parameter. Their documentation says that they need the wid parameter to be the width of the map coverage in degrees, so we'll have to add such a scale-derived parameter to GeoHack for this service to work correctly. What would be an appropriate estimate? --Para 03:49, 1 December 2007 (UTC)[reply]
  • {{Geolinks-US-river}} - Special template that takes two named coordinates: the beginning and end of a river. Some of the articles have an infobox with the same information. Should probably be converted to two external links of the statement of fact style, with (mouth/source) at the end. --Para 05:36, 1 December 2007 (UTC)[reply]
Done. The articles using this template pass linked article names within parentheses, so the bot run will have to take that into account to use the plain names as a coord parameter. --Para (talk) 03:50, 15 December 2007 (UTC)[reply]

Several requests are awaiting administrator action. When the changes are done someone might want to check which templates can be merged, as many of the templates which specify a region might no longer be needed due to automatic region detection. (SEWilco (talk) 04:35, 30 November 2007 (UTC))[reply]

The modifications have now been done. People who haven't in the last two months seen any of the notifications of the planned change will now have a chance to comment. If we continue to have consensus and can go by #Replace uses of Geolinks with a text and coord, a bot can substitute the uses of all the coordinate templates in External links sections to the "statement of fact" format with coord. Then Wikipedia's coordinates will be easily available for Google Earth and the like. --Para 03:49, 1 December 2007 (UTC)[reply]
As I stated above, I don't like the current setup because the current statement is very similar to a statement in the Geography section of most cities/towns/villages/etc. One way to fix this is to change the statement. Another way would be for the bot replacement to merge the two statements. I've done this for Peetz, Colorado (diff) as a first example. My questions are:
  1. Does the community like this?
  2. Is it at least acceptable enough for me to keep doing it manually?
-- Ken g6 (talk) 04:28, 8 December 2007 (UTC)[reply]
It adds a bit of inconsistency. At the moment there's three places in location related articles where the coordinates can be found with some certainty: title area, infobox, external links, in that order. Some articles may have them hidden somewhere in the text, but without reading a few sentences around them you won't even know if they're for the whole article or for some small detail related to it. How many articles out of all location related ones have a Geography section, is its placement predictable, and does it contain something else than the data from the infobox in a list like manner? Also, the duplication of coordinates in different formats isn't really necessary. The Coord template creates some hidden blocks with coordinates in the other format, which readers can control with css rules. Now, I'm not against moving coordinates out from external links, but I don't think the Geography section is much better. --Para (talk) 23:48, 8 December 2007 (UTC)[reply]
The last step of the requested conversion, substitution of the templates, so the coord template will be recognized by search engines, will begin after the start of the calendar year. -- SEWilco (talk) 15:19, 20 December 2007 (UTC)[reply]
  • Some old geolinks template seems to have been subst'd all over, and will be more difficult to replace. Articles where it has been used should be easy to find though, as it links to a rarely used hostname. See links to virtualearth.msn.com for a list: there are currently 664 articles with the substed template. --Para (talk) 00:06, 21 January 2008 (UTC)[reply]

{{Geolinks-UK-buildingscale}} is producing the error:

Coordinates: ERROR in Coordinates: Missing latitude
Invalid arguments have been passed to the {{#coordinates:}} function invocation. Please see Template:Coord for usage. Arguments supplied as: <snip>

Would someone who knows please fix it. thanks --Tagishsimon (talk) 11:45, 30 November 2007 (UTC)[reply]

 Done --Para (talk) 11:54, 30 November 2007 (UTC)[reply]
Thanks --Tagishsimon (talk) 11:56, 30 November 2007 (UTC)[reply]

ifexist limit issues

Several geo templates are mentioned as broken in the first subsection of Wikipedia:Village_pump_(technical)#.23ifexist_limit -- SEWilco 06:33, 3 December 2007 (UTC)[reply]

{{coord}} was mentioned only because its documentation pages use {{Template example row}}, which in turn does up to 10 ifexists per call. I've converted some of the pages to plain wikitext, but either way the limit doesn't change the template's functionality, only the documentation pages. --Para (talk) 20:07, 5 December 2007 (UTC)[reply]

There's currently a huge number of direct map service links on Wikipedia because that's the format easiest for people to add. They are used in prose as linked place names, numbered external links, external links named after the service, and in the references and external links sections. This kind of linking is hardly ever justifiable, as similar information is often available from many other services, and most services don't allow the user to request data from a specific date. If the contents of the link may change at any time, the only reason to continue linking to that service is if the section is about that particular service, like maybe in Satellite map images with missing or unclear data. All other direct map service links should be converted to coordinates, but it can not be done with a bot as the usage is so diverse.

I have put together a simple tool that gives a random set of such links from the database: maplinks-report. Would be good if people could convert a few every now and then; there are thousands. With some obscure links this may introduce unwanted sets of numbers in prose, which will perhaps also revive the inline coordinate display discussion. --Para (talk) 04:20, 15 December 2007 (UTC)[reply]

I have taken a look at several of the maplink reports. But how do you suggest that one can start. All seem to need the co-ords added to the infobox- but that is missing too. Often the article is one of a massive group, and they all need doing. Or are you suggesting that the link, usually in External Links, should just be converted to standard format, if so which? But couldn't that be done automatically? I've never written a bot so wouldn't know how to start?

ClemRutter (talk) 10:40, 17 December 2007 (UTC)[reply]

Based on the links I've converted so far, the use is so varying that they can't all be converted with a bot. You could however write a bot to convert a single subset. Articles with a map service link and no coordinates would probably be easiest, when the link is found in the external links section and the coordinates in the possibly many links match. In that case the link can just be converted to title coordinates, and someone can later move them to an infobox if necessary. Most bots run with the pywikipediabot framework, but AWB could be a big help already. Data can be found from Special:Linksearch or my maplinks-report tool. --Para (talk) 21:37, 27 December 2007 (UTC)[reply]

I have finally found a place to comment on the changes that have been done to a template I have been looking after for two or three years now: {{geolinks-cityscale}}. This was originally developed (by myself) to insert links to Google Maps and its equivalents. Less than thirty people seem to have had a discussion above and reached a 7:4 vote. Changes have therefore been made. I didn't have a vote. If I had, I just needed to find 5 friends to change this vote the other way. This is not democracy...

There is a reason to use geolinks-cityscale. If people want a quick link to maps of an area, they click a link. Map nerds can instead access geohack and have hundreds of options. The "compromise" reached is that the convenience of "one-click" mapping has been removed and the user has to look at a confusing list of hundreds of links. I have been busy for years adding this template to pages, dilegently finding co-ordinates to find that this month it has been completely undone. Not everybody is interested in maps. Most users of the Wikipedia want information.

So what is the problem that this change has fixed?

  • One click mapping has become two click mapping
  • A simple list has become a myriad of options.

I think people who are overwhelmingly interested in maps (or perhaps "order") have put themselves in control. If it ain't broke, why fix it?

I have reverted cityscale. It breaks my heart to see all my good work undone. --Scotthatton (talk) 14:14, 20 December 2007 (UTC)[reply]

There is a quick link to a map. Click on the globe icon next to the coordinates. There are practical needs for a time limit on voting; if you don't show up to vote during Election Day your vote cannot be processed. -- SEWilco (talk) 15:01, 20 December 2007 (UTC)[reply]
Isn't the Wikipedia supposed to be democratic? How can so few self-appointed people decide on changes that affect so many? I can't think of another walk in life where this would be so. --Scotthatton (talk) 15:04, 20 December 2007 (UTC)[reply]
Someone had to decide, and the current decision is not my favorite either (as you can see from my above proposals). You're insisting that your one voice should override what several have decided. What is your definition of a democracy? We also can't hear those who don't speak during the long discussion period. The reasons given for the decisions are above. -- SEWilco (talk) 15:13, 20 December 2007 (UTC)[reply]
I am not saying my voice is more important. Of course I don't agree with it but that's life. I am very distressed that people started to implement changes. If there was no concensus, why isn't the status quo the default condition? In my company, everybody affected by a change is brought into a discussion. Nobody could have put more work into this than I and I feel it's been destroyed for no real reason. --Scotthatton (talk) 15:24, 20 December 2007 (UTC)[reply]
The coordinate information is what is being preserved, it is being placed in a different wrapper. We've all spent many hours tending various coordinate items (a few weeks ago I checked a set of government coordinates and sent corrections to that government agency as a side effect of adding them to Wikipedia). -- SEWilco (talk) 15:37, 20 December 2007 (UTC)[reply]
I'm sorry if my remarks have seemed directed against people in particular. They are not. I still cannot see what problem has been fixed by making these changes to cityscale and I feel disenfranchised. It's been an abstract discussion which cityscale has ended up being part of because it used coord. Nevertheless, as a result, an extra step has been added for a normal Wikipedia user who cares not for how useful it will be for Google Earth coordinate systems etc. I like maps as well but most people just want convenience. This is a backwards step. If I made any further revert back people can now say "Look - here it is being discussed and you missed the bus". So what my opinion is now counts for nothing. Absolutely and completely nothing. That is very depressing. --Scotthatton (talk) 16:21, 20 December 2007 (UTC)[reply]
The GeoHack mess is similar to the ISBN problem: given a book/location identifier, how does one help users with many needs to find a useful resource? There will be continuing discussions about improving the tools in various ways, as all this is being developed. The globe icon's map isn't my favorite presentation either, but Wikipedia's map support is still evolving. A User Preference for map presentation would be nice (someone let me know if there's a Bugzilla to vote for), but maybe that is in the Mediawiki gis extension which has not been installed here in en.wikipedia. Indeed, I suspect it is most likely the geo software will be added after these location templates settle into similar and stable conditions. My favorite recent improvement to the map interfaces was to have the proper region's services pop to the top of the GeoHack page, although I haven't been using it much due to always hunting down the Google Earth options. Not that that interface is the best yet either. -- SEWilco (talk) 16:56, 20 December 2007 (UTC)[reply]

Scott, I share your frustration, but you have heard the expression Wikipedia is not a Democracy? Katr67 (talk) 18:33, 20 December 2007 (UTC)[reply]

You should look at the "vote" more as a list of points for or against the proposals instead of counting people. The selection of map services is very much a reader choice, and though the people who have maintained the geolinks templates have done a good job, the editor chosen short list of links can never serve the entire world. Except with very specialized services, map links in articles are not information about the articles' topics, whereas coordinates are. Perhaps we should work on making this clear on Wikipedia:External links and maybe guide people who add direct map links without using any templates at all? Anyway, to get the selection more to the direction of the reader, on Commons there was a request for configurable map links, so I wrote Google Maps Love.js to add a Google icon next to the globe icon. Something similar could be made here to add a set of links to External links or popups. --Para (talk) 20:00, 20 December 2007 (UTC)[reply]

The selection of map services is indeed very much a reader choice. Just a long as a link is made to Geohack, coordinates for use by KML files etc. people should not be forced along a particular path. We might decide that the Netherlands deserves "one-click" map links different from Alabama. Geohack has its place but not as the first choice for all users. Indeed more discussion needs to be done but first of all, I want the old cityscale back. And the freedom to put it back. Katr67's link is very interesting. And thanks Para for the javascript ideas. --Scotthatton (talk) 23:10, 20 December 2007 (UTC)[reply]
Most readers who want to know where a place is really don't care which g'dam map they see (WP:OR). What they want when they click on a link that says "map here" - is a MAP! Until there is a single non-commercial map we can link to then let each editor decide for themselves. And if you change one of my location links to a link to a page of gobbledeegook don't get too surprised if you are reverted. Sarah777 (talk) 20:49, 15 January 2008 (UTC)[reply]
You're in luck: All Wikipedia pages with coordinates already link to a single non-commercial map, the WikiMiniAtlas. Try clicking on the globe icon next to any coordinates to open the map. Unfortunately we can't have instructive messages in articles to point readers towards map services, as they would belong to the user interface and are not information about the topic of the article. For the case when a user is not happy with our maps and wants to use external ones, what should we do to make the list of available services more usable? --Para (talk) 04:42, 16 January 2008 (UTC)[reply]

Note: A similar discussion is at Template talk:Mapit-AUS-suburbscale#Moving forward. -- SEWilco (talk) 15:50, 28 December 2007 (UTC)[reply]

This proposal notes the following:-

  • Following a discussion in October and November, Geolinks and the templates such as geolinks-cityscale using it, were changed to emit a single line
  • Geolinks now outputs the latitude and longitude of a place in the top right of an article and also at the position of the template in the article
  • Geolinks outputs a format usable by third party software such as Google Earth

This proposal recognises the following:-

  • The Wikipedia's aim is to be an easy-to-use source of information to its readers
  • Geohack in its current form is of interest to people who wish to see multiple map sources
  • The recent change to Geolinks means that users uninterested in mapping options are two clicks away from seeing links to maps, may wish to easily find a map of a place, are generally not aware that clicking a coordinate brings them to a page of mapping options and lastly may not require so many mapping options
  • The discussion in October/November came to a inconclusive decision which made changes to the status quo
  • Discussions here are made by people who have a keen interest in mapping and may be not representative of general users.

This proposal suggests the following:-

  • Until Geohack matures into a easier-to-use, maybe inline version (discussions have been progressing at Geohack [citation needed] on this subject), no changes should have been made which force its use.
  • A solution needs to be found which offers links to mapping on the article page.

This proposal concludes the following:-

  • There are multiple needs. Users who want easy links to maps and users who want further mapping options.
  • Recent changes to geolinks serve the second community but not the first
  • Geolinks-cityscale served both communities before the recent changes
  • Geolinks-cityscale should have direct mapping links restored while not affecting the links to Geohack nor compromising third party uses such as that by KML/Google Earth
  • Geolinks-cityscale has been well-looked after since its inception and has no known issues with missing data

Interim proposal: The geolinks-cityscale template has the direct mapping links it had before the November change restored until Geohack or an equivalent product matures further.

  • Support - As the (biased) originator of geolinks-cityscale, recent changes have lessened the usefulness of the Wikipedia. I am only proposing this change for cityscale. Hence if links are restored to this alone, a useful comparison can be made down the line to other templates still emitting a single line. --Scotthatton (talk) 12:25, 24 December 2007 (UTC)[reply]
  • Oppose - The above is incorrect. Single-click map is available by clicking on the globe icon. That is the major issue specified above (and no link to a progressing Geohack discussion is provided). -- SEWilco (talk) 18:07, 26 December 2007 (UTC)[reply]
  • Support - Previous consensus-building process was flawed (it did not in fact come to a consensus, and 11 users is not a basis on which to enact such a wide-reaching change) and failed to recognise wider user/community needs, focussing on narrow development/standardisation goals. We now have users running off and doing their own thing as a direct result of the imposition of the last one, which cannot be a good thing. This is what happens when Wikipedia's processes for doing things cooperatively are abandoned in favour of totalitarian if mechanically efficient solutions. Nobody was ever able to highlight any problems with the existing system, and through careful management, linkspam was avoided. Orderinchaos 18:30, 27 December 2007 (UTC)[reply]
  • Support. Paraphrasing what I said at Template talk:Mapit-AUS-suburbscale, what we do here should be done for the convenience of readers, ahead of the preferences of User:s or developers - if I was a first-time reader, which of the following would best *inform me* where I can find map information?
or
  • Maps and aerial photos
  • Oppose. Clutter. Why should we sponsor certain map services and not others? What about Mapquest, Yahoo, Map24, etc.? Furthermore putting a verbose list of geocoding links in the article gives it too much space. It's usefull yes, but keep it in proportion please. --Dschwen 12:36, 28 December 2007 (UTC)[reply]
  • Oppose - Wikipedia offers information, and for external map service links to be information about the topic of the article, the chosen links would have to reflect the quality of the services' imagery for that location. The assumption that a single editor chosen set of map services could ever serve all cities around the world is however severely flawed: some areas are better covered by some services than others, but those services don't always have better coverage than the others, so linking to the selected services isn't information about the topics of the articles at all, but linkspam. If we had a structure in place to allow users to evaluate the quality of each map service per article or even just on city scale, and then be able to link to the top services on the dynamic list from each article, then those links could perhaps be offered in articles. But since we don't, and such a quality indicator would depend on quite a few factors anyway, making it close to impossible to implement, the only solution is to list them all and the place for that is obviously outside article space. Therefore no solution needs to be found to offer redundant mapping links in articles directly. Also an objection to the conclusions of the proposal: the coordinate template the articles will soon use directly is currently the only recognised uniform way to enter coordinates in Wikipedia. The geolinks templates are not and cannot be made uniform, so they do not serve the alleged second community of people who are not content with links chosen by a handful of editors, but want to see the whole of Wikipedia coordinate information in other services such as the WikiMiniAtlas, Google Earth, or any other service not included in the geolinks list. Coordinate template standardisation serves the entire Wikipedia community, making coordinate entry the same no matter what region the location is in or what its scale is.
    Since the people opposing the #Replace uses of Geolinks with a text and coord proposal either had no reasoning or weren't up to date with the recent page navigation developments on the map sources page, the change has been implemented partially, pending a bot subst run. The dislike of Wikimedia's own mapping service or change from one to two mouse clicks for the rest is hardly reason enough not to go on with the change. --Para (talk) 21:43, 28 December 2007 (UTC)[reply]
    As a slightly vision impaired person, I do find geohack unreasonably difficult to use - just way too much distraction. So it's not just an issue of "one or two mouse clicks", it's an issue of usability - and that's even with the changes that were made recently to it. Orderinchaos 04:12, 29 December 2007 (UTC)[reply]
    Okay, that point hasn't been made before, let's work on improving the usability. A few months ago there wasn't input from many people at Template talk:GeoTemplate#Redesign.3F, but perhaps now we can look at it again: what can be done to have the page less distracting, while keeping all the services? My proposals at the time were a list with icons or the same in columns. (If people do have ideas on improving the GeoTemplate, let's discuss it at its own topic somewhere, rather than related to this proposal.) --Para (talk) 14:18, 29 December 2007 (UTC)[reply]
  • Support - Exceedingly glad I found this discussion - I was wondering where the links had gone. I want to find links to maps easily. Why are people so opposed to Google Maps? It's by far the best way to find where a location is. If it's the best external site to Wikipedia, why remove links to it? Or is it a prejudice against "comercial" sites. If so, the Wikipedia is full of links to external sites. --Faylawnsett (talk) 12:37, 30 December 2007 (UTC)[reply]

Note: User registered on Wikipedia 23h before posting the comment.

On what criteria would that be the best map service all the 300,000 Wikipedia articles with coordinates should link to? What about the other services listed in the geolinks templates, are they also the best? Is that criteria generalisable to the needs of all or even most of our readers? We need to be consistent on our linking to map services, and so far there's been no reason for Wikipedia to promote one commercial service over the others. --Para (talk) 14:32, 30 December 2007 (UTC)[reply]
As an editor, I am trying very hard to understand this debate, I a feel I have a duty to put forward an opinion. I use Google Maps with a passion- but for UK editing I choose Magic maps because of their superior scale, representation of watercourses, mapping detail and overlays such as SSSI's. I don't want to lose that. Can someone give me a list of example page where these templates are used. Are we talking about Geolink-UK-Cityscale or what? Where can I see the source code- as I cannot find one? How has work been lost, if the link goes to geohack?
Slightly off focus, but I do find the map that the globe icon points to particularly useless- does a solution turn around sacrificing that direct link? I wish I could be of more assistance.ClemRutter (talk) 18:56, 30 December 2007 (UTC)[reply]
In a nutshell, some people liked geolinks ability to put a select few maps inline on the article page. Some people regionalized these templates for better selections in a given area. Others liked it because you could select the scale down to a building as part of the Geolink. On the opposing point of view, there's the thought that rather than make arbitrary choices about which maps are featured, make everyone go to the giant list of all mapping services. Improvements were made to that page to allow for scaling and a form of regionalization, though perhaps not as much as could be hoped for. There's a lot of red herrings and partial solutions offered, but I suspect no one will be happy here. One specific concern is that only 10-15 people have been active in this discussion. dm (talk) 19:22, 30 December 2007 (UTC)[reply]
As documented in Wikipedia:WikiProject Geographical coordinates#Parameters, you can add |region:GB to make the British options appear at the top of the Geohack list. {{Geolinks-UK-cityscale}} is using that, and without it an automatic process tries to do the same. -- SEWilco (talk) 05:04, 31 December 2007 (UTC)[reply]
  • Support. "300,000 articles" - these are custom templates for different countries and purposes, so that the most appropriate services can be chosen for each country. And each country's editors can come to consensus amongst themselves rather than having to deal with the central and macro-heavy Template:GeoTemplate. If the changes were just for the default template I'd agree with them, but preventing specialised templates from promoting particular appropriate services is too limiting. It's not like the Geolinks service isn't still available, it's still in the standard top-right location for all coordinates. TRS-80 (talk) 19:55, 30 December 2007 (UTC)[reply]
What do you mean "still in the standard top-right location"? The numerical coordinates were not being displayed by Geolinks in the top-right corner of articles until the change was done. And your comment about each country suggests more documentation needs to be added to the GeoTemplate's presentation of the most specific data first (I don't remember whether it presents the relevant country or region). -- SEWilco (talk) 04:48, 31 December 2007 (UTC)[reply]
Please note that this is not correct. Co-ordinates have always been displayed on the top right by the template underneath - indeed before I wrote cityscale originally. --Scotthatton (talk) 13:31, 2 January 2008 (UTC)[reply]
Ah, there it is: Wikipedia:WikiProject Geographical coordinates#Parameters says to try the two-letter country abbreviation in the region specification. -- SEWilco (talk) 05:04, 31 December 2007 (UTC)[reply]
Orderinchaos's comment on #Both_Geolinks_and_top-of-page_coord says that's how things were, and it's my recollection too, old versions of Mapit-AUS-suburbscale included {{coord}} as {{coord|{{{lat}}}|{{{long}}}|type:landmark_region:AU|display=title|format=dms}}. Country selection isn't good enough, different services are appropriate for differently-sized and located regions - coverage of towns in rural Australia differs a lot between mapping services. To re-iterate - I support the change to the global template, but leave the country-specific ones alone, as they are better maintained and more appropriate for their regions. TRS-80 (talk) 09:51, 31 December 2007 (UTC)[reply]
I'm willing to accept that the top-right coordinates were present in some Geolinks code; I edited so many templates that I might be remembering what a different template was doing. -- SEWilco (talk) 17:44, 2 January 2008 (UTC)[reply]
I can think of many many examples where country selection is not enough. You'd want an Ordnance Survey map to give justice to a remote area like northern Scotland. You'd want Streetmap to link to street maps of London. Both are in the UK. The solution does not lie in scaling as streetmap does not supply street-level mapping of Edinburgh. You'd need a London version alongside a UK generic to provide maximum service. --Scotthatton (talk) 14:37, 2 January 2008 (UTC)[reply]
No geolinks templates exist for areas more detailed than country level though, so this is all hypothetical. If that kind of detail was wanted and we had the service coverage information required for such a feature, it could easily be added to GeoHack, as the more detailed region information is already available (see with Edinburgh for example) and filtering services out of the list would be a simple comparison of scale values. This could all be done with geolinks too of course, but requiring edits to the related articles, and with highly subjective results because of the editor chosen services. Anyway, it would not be a good decision to not provide links to services that don't have very detailed data of a location, as we can't know what kind of detail the user wants to see, and some users may be accustomed to using a specific service (which may not, again, match with what the geolinks editor chose). --Para (talk) 22:23, 3 January 2008 (UTC)[reply]
It's not hypothetical, see directly below at #Geolinks_coverage where there's a listing of the various country templates at various scales - building, street, city etc. TRS-80 (talk) 02:46, 6 January 2008 (UTC)[reply]
Scotthatton was talking about lists of services on a sub-country level, to see a different selection of services depending on the location of the region within the country. Currently neither GeoHack nor the geolinks templates support this. What you seem to be talking about is one of:
  • geolinks templates imply a scale of the object with their name. This translates to the scale parameter in all the coordinate templates, and is relayed to map services through GeoHack.
  • geolinks templates for small scale objects do not link to services that are appropriate for the region and are included in their larger scale counterparts, but don't have small scale data. This practice is incorrect, as it assumes that readers expect to see the object with that small scale only, and not just its general location.
  • geolinks templates for large scale objects do not link to services that are included in their smaller scale counterparts, because ...? Absent any criteria for inclusion, I'm guessing this is because the large scale template editors like the services they chose, and the small scale template editors don't like them.
We can give hints in some way on how one service might be better than another, but we should not leave services out because of personal preference. --Para (talk) 17:20, 7 January 2008 (UTC)[reply]
"preventing specialised templates from promoting particular appropriate services is too limiting" ?? It's not for Wikipedia to promote external services! --Para (talk) 17:20, 7 January 2008 (UTC)[reply]

In theory it's a nice idea that there would be a maintained geolinks template for all scales of all the world's regions, but in practice it's unmanageable. I looked at all the Geolinks templates from before the change, and here's the results:

Geolinks coverage
Continent Region Template scale Google Maps Live Wiki
mapia 		Yahoo Maps Map
Quest 		Topo
Zone 		Global
Guide 		Multi
map 		Street Directory Bonzle Terra
Server 		MSN Maps Map
tech 		Virtual Earth Virtual
Globe
trotting 		US Census
Geolinks-buildingscale landmark x x x x x x x
Geolinks-cityscale city x x x x x x x
Oceania Geolinks-AU-streetscale landmark x x x
Mapit-AUS-suburbscale landmark x x x x x
Geolinks-NZ-streetscale landmark x x x
Asia Geolinks-Asia-cityscale landmark x x x
Geolinks-IN-landmarks landmark
Geolinks-IN-streetscale landmark x x x
Europe Geolinks-Europe-buildingscale landmark x x x x x
Geolinks-Europe-cityscale city x x x x x x x x
Geolinks-Europe-mountain mountain x x x x x
British Isles Geolinks-UK-buildingscale landmark x x x x
Geolinks-UK-streetscale landmark x x x
Geolinks-Ireland-streetscale landmark x x
Geolinks-UK-cityscale city x x x x x x x x
Geolinks-UK-mountain mountain x
North America Canada Geolinks-Canada-streetscale landmark x x x x
Geolinks-Canada-cityscale city x x x x
Geolinks-Canada-region city x x x
Geolinks-Canada-townscale city x x x x
Geolinks-CanadaMore-cityscale city x x x x x x x x x
United States Geolinks-US-buildingscale landmark x x x x x x x
Geolinks-US-hoodscale landmark x x x x x x x
Geolinks-US-photo landmark x x x x
Geolinks-US-river landmark x x x x x
Geolinks-US-streetscale landmark x x x x x x x
Geolinks-US-trails landmark x x x x x
Geolinks-US-cityscale city x x x x x
Geolinks-US-countyscale city x x x x x x
Geolinks-US-mountain mountain x x x x x
Geolinks-US-colorphoto N/A x
Geolinks-US-surrounds N/A x

What the table doesn't show is all the areas not covered by the geolinks templates. There is no consistency, not in the selection of map services within a region, not in the selection of map services within articles of a certain scale, and not in inclusion of services local to an area, except in very few cases. Most of the included services are global, and their imagery can change at any time without any notice. The problem isn't that Wikipedia wouldn't have articles from the regions missing in geolinks templates (see map of coordinate coverage), but that there is nobody to maintain the templates. People supporting reversion here are mostly interested of the area they're taking care of themselves, ignoring all the remaining ones. Many of the regions the geolinks templates propose are also too big to really include the best services available for some of the areas listed in GeoTemplate. When a random reader comes to Wikipedia and wants to find the location of an article or a better view of the area, we should provide a predictable link to better map services, and Geolinks cannot do that. --Para (talk) 16:23, 31 December 2007 (UTC)[reply]

Maybe this is the crux of the entire discussion in different topics scattered throughout this article. I am the originator and maintainer of cityscale and have indeed maintained it throughout its existence. I have fixed mistakes, improved co-ordinates, disposed of linkspam etc. for a long time now. From discussions I see that the Australian maintainers have been doing the same job. Other templates have not had this care and attention. All geolinks templates are not equal. There is a strong case for getting rid of some - the Europe ones are too wide in their remit.
As for "When a random reader comes to Wikipedia and wants to find the location of an article or a better view of the area, we should provide a predictable link to better map services" I can 100% agree. But it should be on the article page. I trust the Australian maintainers to find great "predictable" Australia-wide sources plus the biggies like Google Maps etc. I don't know Australia and so trust Australians to know their best providers. In the UK I'd want to see Ordnance Survey; in the Netherlands lokatienet. these are great local services. You can with Geohack bring mapping to the top. The problem is that's it's still one click too many away... --Scotthatton (talk) 14:01, 2 January 2008 (UTC)[reply]
All articles with coordinates related to the whole article should be treated equal, to provide readers consistent and predictable map links. "Predictable" here could mean that a global map service found in one location related article should then be found in all location related articles, and a regional one in all articles in or somehow connected to that region. Any partial deletion of geolinks isn't progress at all. If some people want geolinks in articles, but there are no editors to create and maintain templates for all the world's regions in a consistent way, then that's an impossible scenario and we'll have to use the central list used by Wikipedias in many languages and other Wikimedia projects. Then map links (as coordinate links) can be truly predictable, to always show the same global services and applicable local ones. We can later work on getting the services listed in an order following some yet-to-be-defined criteria. --Para (talk) 22:32, 3 January 2008 (UTC)[reply]
As long as the attributes can be linked in the title and the user has the option of going to the blindingly confusing geohack page (on which I can't even find Wikimapia any more - I think I managed to once - but most times I have to enter the link directly and enter coordinates manually - how is this an improvement?!), or using our somewhat easier to use links, isn't that good for Wikipedia overall? I don't really mind what happens in areas which didn't have coverage or didn't significantly use the templates - for those an international template can be used. However, for regions (or past use of templates) where there is a strong group of readers and editors and where consensus is not unhappy with what they previously had and clearly does not want the new version, then telling them "we know what's best for you and you're getting it whether you like it or not even though we can't even get an international consensus amongst other regions' editors" smacks of arrogance and elitism, and is not and should not be how Wikipedia works. Orderinchaos 20:29, 5 January 2008 (UTC)[reply]
No, it's not good for Wikipedia to have two separate ways for reaching map sites, when one of those isn't guaranteed to exist in all location related articles, may not be up to date, is based on personal preferences of a handful of editors, and links directly to those arbitrarily chosen advertising supported services. If there are any problems with the GeoHack interface, please report the specific problems somewhere so that they can be fixed. The motives of the main geolinks contributors are highly questionable when they are not interested of mapping links Wikipedia wide, but only for their particular region. Since the links in the geolinks templates don't add anything the coordinate templates don't already have, they are nothing but convenience links as interface elements that should be uniform throughout Wikipedia. There have been cases on Wikipedia before when strong groups of readers and editors were unhappy with fundamental Wikipedia policies, wanted to see them changed, and felt offended when their efforts were turned down, calling it arrogance or elitism. Links to map services are not information. --Para (talk) 04:05, 8 January 2008 (UTC)[reply]
Orderinchaos is mainly concerned with an Australia-wide template. I am mainly focused upon a worldwide template. Though we are both on the other side of the debate from Para, we are coming from two different angles. Much as I enjoy being told what I think and why I am thinking it, I have come to the end of this debate. Para does not agree with me and I don't agree with Para. This is understood now. --Scotthatton (talk) 14:31, 8 January 2008 (UTC)[reply]

Problem with format of coordinates templates on page

I don't know if this has been raised before, if so I couldn't find it, apologies. The templates Template:Coord, Template:Coor_title_dm, [[Template:Coor_title_dms, Template:Coor at d, Template:Coor at dm and Template:Coor at dms all place the link at the top right of pages and it overlaps the XX,XXX have donated link/s. I suspect at at higher screen res than mine (1024x768) its OK but going lower only makes the problem worse. I'm not sure if fixing this is in the scope of this project or whether it needs to go higher, but it certainly needs fixing. Talltim (talk) 17:51, 30 December 2007 (UTC)[reply]

It was mentioned when the fundraising advertising appeared. You're still seeing that behavior because no good solution has been found. -- SEWilco (talk) 16:31, 31 December 2007 (UTC)[reply]
Which browser version do you use? (If you're not sure - click Help -> About in the top bar of your browser) Orderinchaos 20:32, 5 January 2008 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

Here is a suggested compromise.

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

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

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

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

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

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

Seems a reasonable compromise suggestion to me. Orderinchaos 03:12, 8 January 2008 (UTC)[reply]
None of the discussions on this page have been votes and they should not be counted as such. You really need to read through all the arguments. And so far I can't agree that the "viewpoint two" side has had any basis, as there hasn't been any reasonable argument for keeping geolinks, except maybe the one about GeoHack supposedly being difficult to use, which unfortunately hasn't been detailed further. To move forward, how about following well explained opinions of people entirely unaffiliated with articles of any single region, geolinks templates or other coordinate projects, such as this comment from User:Wikidemo: "for the sake of consistency and fairness, where we have essentially the same need on 300,000 articles we shouldn't be linking to external web services on an ad-hoc basis. Best to have a standardized, predictable way of doing it so that all the users know what to expect and we're not in the position of favoring one advertising-supported commercial service over another." Any others? --Para (talk) 04:24, 8 January 2008 (UTC)[reply]
Para - I acknowledge the arguments on both sides of the debate. Are you happy with the compromise proposal? --Scotthatton (talk) 09:25, 8 January 2008 (UTC)[reply]
No I am not happy with it, and can't see how anyone could be, other than the people who have been maintaining the soon-to-be-deleted templates. It would leave about 3,200 articles of the total 300,000 location related ones with redundant links just because of opinions that come down to WP:USEFUL and WP:ILIKEIT. It seems to me that the people supporting geolinks are ignoring all the issues mentioned in the above discussions, are not elaborating on what is wrong with the alternative, and are trying to act on the basis of WP:OWNERSHIP. One possible compromise for keeping the two geolinks templates for now could be to add a supported coordinate template to those 3,200 articles with a bot, and leave it for other editors (none of us) in the normal editing process to remove the redundant geolinks templates from the articles. --Para (talk) 12:45, 8 January 2008 (UTC)[reply]
"other than the people who have been maintaining the soon-to-be-deleted templates". Soon-to-be-deleted? Now I think I need to know more. Please explain. --Scotthatton (talk) 14:35, 8 January 2008 (UTC)[reply]
Since the geolinks templates (except perhaps two of them then?) no longer serve any purpose, and as the second stage of the changes will be substing the templates to text and coord in articles, the unused geolinks templates should then naturally be deleted. For those remaining two templates the community will no doubt later do the right thing and get rid of such redundant external links, eventually leading to the deletion of the two templates as well. In a project with relatively few interested contributors, "soon" can be a longer time than it might normally be on Wikipedia. --Para (talk) 15:44, 8 January 2008 (UTC)[reply]
I am finding all this a bit arrogant, dismissive of others views and presumptive but perhaps that's me. --Scotthatton (talk) 15:52, 8 January 2008 (UTC)[reply]
It's you and others who missed the many mentions of this long-running discussion. This discussion (spread across this Talk page) has tried to be inclusive, which is why there was a suggestion to perform an interim change so as to help alert interested people. And if we were indeed being dismissive, I'd have already begun the substitution process which I stated I was delaying until after the holidays. I'm waiting for a decision, although someone else might decide there has been a decision. -- SEWilco (talk) 17:10, 8 January 2008 (UTC)[reply]
Some of us didn't notice these above discussions until too late for which we will never be forgiven. Who is the mysterious "somebody else"? --Scotthatton (talk) 21:32, 8 January 2008 (UTC)[reply]
I think I said that you didn't notice the discussions, but that was stated as a fact and not a sin. No specific "somebody else" is intended, it's simply that my lack of action does not affect the decision of others. -- SEWilco (talk) 22:36, 8 January 2008 (UTC)[reply]

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

If I was treating this with contempt then I'd have continued the updating process. Instead I'm reading the contributions. -- SEWilco (talk) 22:36, 8 January 2008 (UTC)[reply]
Please note that any further work on these templates needs concensus or at least agreement. At the moment there is no mandate or agreement to do absolutely anything at all, whether trashing the templates or reverting. --Scotthatton (talk) 19:50, 10 January 2008 (UTC)[reply]
What's your (and others') opinion on the compromise I proposed above at 12:45? That would leave it to individual article editors to decide what to do with geolinks. --Para (talk) 15:52, 11 January 2008 (UTC)[reply]
In the absense of any other ideas, that would be a way forward. We seem to have few other people interested in anyh of these issues right now. --Scotthatton (talk) 17:05, 12 January 2008 (UTC)[reply]
I'm starting to think that dispute resolution is necessary, as certain editors are acting completely contrary to the spirit of Wikipedia and have already made up their mind what they're going to do regardless of what anyone else says. Orderinchaos 13:34, 20 January 2008 (UTC)[reply]
It would be good to hear your opinion on the compromise proposals as well. Also, seeing as you were the only one opposing the move to GeoHack with an actual reason, what do you think of the usability of the page now that it's more organised and much of the distracting text is gone? --Para (talk) 00:22, 21 January 2008 (UTC)[reply]
I don't even understand the compromise proposal - if someone can explain it to me, I can offer an opinion on it. Meanwhile, between 100 and 200 instances of Mapit-AUS have been converted amateurly to manual links to mapping services by other users who think the changes are errors - so the evidence is that users clearly want the links at the bottom and not from some less-than-obvious page less-than-obviously linked. Orderinchaos 12:54, 22 January 2008 (UTC)[reply]
The proposal was that Template:Mapit-AUS-suburbscale and Template:Geolinks-cityscale would be reverted to their external linking state, changed to display inline coordinates or none at all, and {{coord}} added to all the articles using the templates. The other geolinks templates would be subst'd in articles to use {{coord}} directly and without the external links. Individual article editors could then choose whether the remaining geolinks uses are necessary in articles or not. I am however not thinking so highly of this proposal anymore...
Wikipedia is written for the readers, and this whole issue being based on principles, we don't need to give way to the ignorance of editors who have been working on Wikipedia for a long time and are used to seeing external map links in articles. They do many things that are against Wikipedia guidelines, such as add direct links to Amazon for more information about a book in a book article, instead of or in addition to ISBNs (see for example A City In Winter, A Corner of the Universe, A Dance with Dragons, A Dancing Bear, A Forest Apart, A Funnier Approach, A History of Christianity (Paul Johnson), A History of God, A History of Knowledge, A History of π, A More Perfect Constitution, A Quiver Full of Arrows, A Random Walk Down Wall Street, A Rebel Life: Murder by the Rich, A Slight Trick of the Mind, A Swift Pure Cry, A Theory of Fun for Game Design, etc). They can simply be instructed on how these references to external services are given on Wikipedia and reverted, if they don't read the article the way an unbiased reader would, by seeing that the set of numbers are coordinates, that links on Wikipedia give more information about the linked topic, and that the tooltip confirms all this. Could you point people to the conversion evidence, so that an orientation project could be started for the old timers and also for the newcomers who don't know how to insert coordinates yet?
Also, again, how is the linked page less than obvious, and how can it be improved? You mentioned that the page may be difficult to use for visually impaired people, but there have been changes since your observation. Is this still the case, and why? --Para (talk) 15:10, 22 January 2008 (UTC)[reply]
The big blocking point surrounding this project is that there are no editors making bold moves. The stuff in the sandbox stagnated for half a year with little change. We need to standardize on appearance so that readers (who vastly outnumber editors) can expect the same interface on each article. And the standardization should extend to the markup level so people don't have to support the 3 or 4 coordinate schemes when parsing pages. I think geolinks should be removed from the external links section moved to the title with {{coord}} and tread like any other meta-data information. And I'm sure that this viewpoint is disliked but it'll ultimately be better for Wikipedia, just like the Ambox was. — Dispenser 00:23, 23 January 2008 (UTC)[reply]
I agree that it's for the readers, but from there we seem to take opposite views. I'd argue that it's not at all obvious to readers that if they click on some numbers that it's going to take them somewhere. The new version of GeoHack is certainly a big improvement, I might add - cutting all the text was a great move, I was actually able to find Wikimapia on the first screen (probably the link I use most consistently along with the street-directory one for Australia). If we could find a compromise which tells readers what they'll find if they click on the link, and at least where desired, renders as dms (as the present geolinks for Australia does), we might just have this one sorted out. Orderinchaos 13:54, 24 January 2008 (UTC)[reply]
The instructive and non-printable "(click for maps)" text after the coordinates, mentioned at #CLICK ON COORDINATES, would suit there just fine, wouldn't it? I don't think it's necessary, but wouldn't oppose if such a thing was added to Template:Geolinks-start and all the geolinks uses then substituted in articles to coord level using all the parameters the current templates call it with. --Para (talk) 20:40, 25 January 2008 (UTC)[reply]

References for geographical features

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

A similar discussion on map links generally, excluding reference use, is now at Wikipedia talk:External links#Issues with inclusion or exclusion of map service links. --Para (talk) 17:07, 2 February 2008 (UTC)[reply]
Really strange how many emotional responses you get, just for cleaning up the map link mess. I wonder if you cleaned out someone's link farm. -- User:Docu
Indeed. It may be a personal issue with argumentation styles or just a downside of the difficult process of improving the deeply rooted status quo in a consensus driven environment. I have been somewhat busy lately and unable to keep on pushing the project goals on various pages – could someone else step in please? --Para (talk) 17:52, 25 February 2008 (UTC)[reply]
"Various pages"? Where have the discussions scattered to now? -- SEWilco (talk) 17:57, 25 February 2008 (UTC)[reply]
The latest is on Wikipedia talk:External links#Edit warring again on external links to map services, but other similar discussions and possible disputes related to other guidelines can sprout anywhere. WikiProjects generally seem to be shunned by the rest of the community when something is questioned, so even though we do a lot of work on projects for coordinating and organising articles, we'd need to better spread those ideas and knowledge on related pages, and watch for any developments. Would it be useful to have a list of Wikipedia project pages where geographical coordinates are mentioned, so that geo-participants could keep an eye on them and help other well-intentioned editors from going astray? Or should we wait for something like mw:Extension:Labeled Section Transclusion? --Para (talk) 19:25, 25 February 2008 (UTC)[reply]
I saw that WP:BRIDGES has a list of articles about types of bridges, and some article talk pages have this project's template on them. But stuff like WP:EL perhaps would belong in a "Related topics" list. -- SEWilco (talk) 20:00, 25 February 2008 (UTC)[reply]
I had noticed the EL discussion after about the fourth page of text appeared. The focus of the discussion began diffused and quickly scattered. -- SEWilco (talk) 20:43, 25 February 2008 (UTC)[reply]

GeoHack renaming

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

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

Too fragile!

Can someone tell me what is wrong with this:

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

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

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

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

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

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

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

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

Maury, try this instead:
{{coord|50|56|40|N|1|22|2|W|display=title|region:GB_type:landmark}}
and it should work. The underscore-separated syntax for the final optional parameters (region, type, and source) is a historical accident of the way the template and geographic URL processing code evolved: one day it will be fixed, but not now. -- Karada (talk) 17:21, 14 January 2008 (UTC)[reply]
Can you:
1) reduce the exact syntax to a single statement?
2) put this in the template page?
Thanks!
Maury (talk) 17:25, 14 January 2008 (UTC)[reply]

Trouble getting it to work

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

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

OS grid refs to co-ordinates

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

Templates {{Oscoor}} and {{Gbmapping}} can be used to link to map sources from grid refs.
For conversions to degrees latitute and longitude, which you can then put into {{coord}} and friends, use Streetmap [19], and then follow "Click here to convert coordinates" at the bottom of the page once you've got a map -- this will give the right conversions, unlike the routines used by the WP templates, which are slightly wrong, and may give lat/longs about 200m out. Jheald (talk) 13:23, 17 January 2008 (UTC)[reply]
So that's a "no" then? DuncanHill (talk) 13:54, 17 January 2008 (UTC)[reply]
They don't do simplicity on this page! My bet is it's a "maybe", though I am not expert at translating geo-speak :) Sarah777 (talk) 14:23, 17 January 2008 (UTC)[reply]
There is no such word as no! I have written a tool that I use to do the conversion and generate a template that can be places after the grid reference. See here os gb to wiki tool. It is being used by User:Mjroots in his work on watermills in Kent. See page River Teise.
This is not the final solution-
  • it does not have the precision I require,
  • duplicating a common wikipedia conversion error-
  • it does not back convert the gridreference if you tweak the lat/log
  • and I am sure in the future, there will be a policy decision that requires a bot to change ::them- but it is fit for purpose, and essential for some old UK reference books.
Please use and enjoy- and talk to me about any improvements needed
So from TQ 7334 6963 51°23′55″N 0°29′32″E / 51.398729°N 0.492200°E / 51.398729; 0.492200 ClemRutter (talk) 14:39, 17 January 2008 (UTC)[reply]
That's definately a step in the right direction Clem! DuncanHill (talk) 14:43, 17 January 2008 (UTC)[reply]
While it might be possible to implement such a complicated conversion using parserfunctions, all coordinates on Wikipedia should be WGS84 first, and other local systems second. I don't see a problem in mentioning local references on pages as long as the globally used one is shown in its usual place as well. User:The Anome has converted OS grid references to WGS84 before as well, keeping the reference in the coordinate template and in article text instead of just replacing it and forgetting the source reference. If his conversion code is indeed correct, then the bot run should just be repeated for all the articles with new references.
ClemRutter, when your tool gives correct results, you should consider making it work in redirect mode to be able to replace User:RHaworth's slightly erroneous tool in the oscoor templates, and possibly install it on the toolserver (since the tool's current host seems to be unresponsive at the moment). --Para (talk) 20:15, 17 January 2008 (UTC)[reply]
Gladly. Analysing the error is now high on my todo list. I am open to any suggestions, for improvements or additions- and tips! Accuracy, is a fascinating subject, but the more I research it- the more pitfalls I find. I know where the problem lies with both my code and [[User:RHaworth]- I need to sit down and write it- and then test it against some known reference points. These are difficult to find- for when you bore down- you find that usually they are derivatives of a conversion algorithm (someone elses code) that in itself has not been proven! Iĺl start later today!
ClemRutter (talk) 00:03, 18 January 2008 (UTC)[reply]
Guys - I have no idea what you are talking about but it sounds damned impressive. Let's do it! Sarah777 (talk) 01:59, 18 January 2008 (UTC)[reply]
Thanks Clem, that is a great tool Cosnahang (talk) 10:30, 18 January 2008 (UTC)[reply]
ostowiki.hthl tool Things have moved on. I have ditched almost all my code- particularly the work by User:RHaworth as it was only doing a transformation from from the Grid to OSGB36 latitude and longitude- the mention of Helmert transformation to WGS84 was a memo to himself that this was the point it should be inserted. I have taken Paul Dixons code, and patched in a frontend. I have found the Ordnance Survey site and they provide Ordnance Survey Definitive Transformation Tool with OSTN02 so I can compare my accuracy.
  • Using my reference point in Barnards Castle- the former tool was 99m/15m out, new tool 0.5m/1.1m out- so the accuracy is now well within the surveying limits of +7m. It is just possible that the new code is derived from the actual OS code so masking the error- but they are the guys that print the maps so I think that is now cracked. In junking so much of the former code, the UI is not as smooth as it was, so that needs to be worked on. It likes running on a 1024x768 screen at the moment.
  • But tell me what you want.
  • There are a lot of pages that will need redoing
  • But a bigger issue is that the GeoHack transformation seems to be following the old level of accuracy, and any of the UK maps derived from the grid code there are inaccurate to the tune of 100 m (I believe- someone needs to test so we know).
So from TQ 7334 6963 51°23′57″N 0°29′26″E / 51.399218°N 0.490456°E / 51.399218; 0.490456 and no longer TQ 7334 6963 51°23′55″N 0°29′32″E / 51.398729°N 0.492200°E / 51.398729; 0.492200 ClemRutter (talk) 02:15, 21 January 2008 (UTC).[reply]

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

Buildings

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

Yes. But please make sure the lat/longs are right. (eg check the link you get through to WikiMapia) -- wrong coordinates may be worse than no coordinates. Jheald (talk) 11:21, 18 January 2008 (UTC)[reply]
As I can't seem to find any clear and understandable instructions about co-ordinates I shall confine myself to adding the locateme request on talk pages, and OS grid refs on articles (which I do understand and can use with a high degree of accuracy). DuncanHill (talk) 20:07, 18 January 2008 (UTC)[reply]

Problems

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

Japanese map services - Tokyo datum

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

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

Clashing templates

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

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

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

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)[reply]
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)[reply]
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)[reply]
Perhaps we should consider adding more zoom types to geohack? — Dispenser 04:59, 6 February 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

Tornado recentism

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

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

City coordinate formats

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

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

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

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

(UTC)

I know this is off topic, but could someone answer this innocent question. What has been tagged? A 6 dec place reference, such as Scottsville gives sub metre accuracy. I zoomed in on the Scottsville example, and Google maps points to some open space between the town and the bypass. If this were a French commune, it would be easy; I would tag the Mairie (Town Hall) and more specifically the centre of the door on the principal entrance, using the WGS84 datum. Has anyone made a decision (policy). Working at the moment on datum conversion and an article where latitude and longitude is important, I am actually using some of the infobox, title and inline tags and many of them are out by many kilometres. I could fix them in passing, were I to know what point of the town to tag. Candidates for consideration: Town Hall, Cathedral (west door, or high altar), town hall, castle, where Eastgate crosses Northgate, Bridge. ClemRutter (talk) 10:00, 18 February 2008 (UTC)[reply]
Rambot probably got the coordinates from Census Bureau info. The coordinates are probably the exact location of a survey marker which had some significance at the time it was made, or the geometric center of the city boundaries. This location is near a cemetery and is in a large oddly shaped area, so I suspect this is the site of the original city hall or church (probably now a park or redeveloped along Highway 100). -- SEWilco (talk) 17:33, 18 February 2008 (UTC)[reply]
If the coordinates came from the Census Bureau, then the coordinates are calculated to represent the approximate center of a polygon formed by the municipal boundaries. Depending on how irregular the boundaries are, this can produce various distortions. I find coordinates from GNIS are more typically closer to some human-recognizable point, such as the city hall or some other landmark such as the main crossroads. older ≠ wiser 18:10, 18 February 2008 (UTC)[reply]
So- that said- do we manually correct this when we find its someones vegetable plot? Do we leave it? If we correct it- what do we look for town hall, cathedral or a prominent turnip? ClemRutter (talk) 13:17, 20 February 2008 (UTC)[reply]
For GNIS official naming: "The Primary coordinate values for communities are taken at the center of the "original" community meaning the city hall, main post office, main intersection, etc. For other areal features, coordinates are taken at the approximate center, and for reservoirs at the dam." [20] There probably is other guidance somewhere in USGS documents. Or just ask the http://geonames.usgs.gov/ database for a coordinate. Ram-bot was driven from Census data, and that organization likes to use polygons. Another way to find coordinates is to see if there is a U.S. National Geodetic Survey benchmark at the location and look up the number in the Survey's records or browse the map at [21] — you might notice there the GO TO coordinates aren't all at benchmarks (I suspect they're GNIS coordinates). -- SEWilco (talk) 16:52, 20 February 2008 (UTC)[reply]

Brief project history and geotagging

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

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

Adding categories

Resolved
 – Proposal withdrawn Zab (talk) 17:48, 23 February 2008 (UTC)[reply]

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

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

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

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

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

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

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

Thanks for your suggestion for Coastal fortifications of New Zealand. When you believe an article needs improvement, please feel free to change it. You can edit almost any article on Wikipedia by just following the Edit link at the top of the page. We encourage you to be bold in updating pages, because wikis like ours develop faster when everybody edits. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. You can always preview your edits before you publish them or test them out in the sandbox. If you need additional help, check out our getting started page or ask the friendly folks at the Teahouse. Zab (talk) 20:35, 27 February 2008 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Geographical_coordinates&oldid=194491252"