Wikipedia talk:WikiProject Geographical coordinates

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

Archives

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

[edit] To do

To-do list for Wikipedia:WikiProject Geographical coordinates:

edit Â· history Â· watch Â· refresh

Fix Category:Articles needing coordinates Use Maybe-Checker: verify and/or add coordinates to articles in categories likely to need coordinates. Fix User:The Anome/Possible manually-generated geodata errors and Category:Pages requiring geodata verification Make better examples, also showing use of decimals and scale. Add an attribute for other planets and the moon and probably also star maps. Extend NASA World Wind support to include layers (by type) and labels. Rewrite the article Geographic_coordinate_system linked from many coordinates. Related articles: latitude, longitude. Convert existing data to templates identify special formats not yet converted, e.g. E12 23 54 N23 34 52

[edit] New site: wikitude.org - Latitude, Longitude, ... Wikitude

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

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

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

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

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

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

[edit] Title coordinate issues

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

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

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

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

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

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

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

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

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

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

 #f3fff2nates {
 top:4.5em;
 }

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

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

[edit] Tools

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

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

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

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

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

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

[edit] New Google maps layer

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

[edit] Best practices, Wikipedia and Google

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

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

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

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

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

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

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

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

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

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

[edit] Lakes needing coordinates

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

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

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

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

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

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

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

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

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

[edit] Satyr

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

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

[edit] Globe

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

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

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

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

[edit] type:waterbody for rivers, glaciers

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

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

[edit] New types (WP:GEO#fff1ff:T)

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

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

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

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

I updated the list accordingly. -- User:Docu

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

I updated the list accordingly. -- User:Docu

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

[edit] Concern

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

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

[edit] Scaling

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

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

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

For detailed implementation see mapsources.php

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

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

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

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

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

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

[edit] Type tags, scales etc

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

[edit] Two tags on one page . . .

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

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

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

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

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

[edit] Maplinks and FritzpollBot

A bot was recently approved (Wikipedia:Bots/Requests_for_approval/FritzpollBot) to create stubs for many locations.

Oddly it appears to insert map links in addition to the coordinates in these stubs, e.g. Ghumay. Given that the article has coordinates, both seem redundant. -- User:Docu

Is this related to WP:GEOBOT somehow? Are stubs normally created with so little information? It's all around confusing to never have heard of such a project before! Hasn't User:The Anomebot2 been importing coordinates from GNS already? Or was it only for existing articles? Both external links the bot has added seem useless to me and not at all in line with WP:EL: The Maplandia site only has a small Google Maps window in the middle of ads and minimal information that's in the article already, why link to it from so many articles if the data comes from GNS anyway? The other link to MSN Encarta atlas has a nice globe, but none of the links lead to anything but the general view, and so having a bot add general links to MSN Encarta seems counterproductive for Wikipedia's goals as an encyclopedia. The operator seems to be on a wikibreak at the moment, but these filler external links need to be dropped for the next run. Has anyone here ever heard of this project? --Para (talk) 00:51, 9 July 2008 (UTC)

Sigh, yeah, why didn't anyone announce such a bot on WikiProject Geographical coordinates? Hard links to map providers are a bad idea(tm), just as we don't link all ISBNs to Amazon but to a page similar to the geohack. This should definitely be rectified before that bot goes into regular operation. --Dschwen 03:38, 9 July 2008 (UTC)

Wow, talk about being late to the train, really!! Look at Wikipedia:Village pump (proposals)/FritzpollBot (don't miss the pulldown), and all the FritzpollBot messages on wikien-l in early June! People are saying exactly the same things as we just did here, like "the external links for the map should go to a more neutral locations (geohack, not maplandia and encarta)"[1], and also that "Fritzpoll has already agreed that those links are problematic and won't be included, if I understand him correctly"[2]. Would be good to get confirmation on that, unless I missed something else somewhere else again? --Para (talk) 15:51, 10 July 2008 (UTC)

Ok, looking a the VP discussion, the concerns mentioned here indeed seem to be covered already: the community thinks the size of the stubs is fine, "Maplandia will not be used in this new proposal"[3] and "The first job of the new WikiProject will be to clean up the existing articles, adjust the source to point at a more precise location, and remove the Encarta links that I know you feel strongly about."[4]

One thing I'm still wondering about is the referencing of coordinates. The Anome has been importing coordinate databases using the source parameter in coordinate templates, and not the usual Wikipedia citation format. I'm not sure which is better, but it would be good to hear some opinions on that here. Anyway, if links are given, they should then be direct (maybe that's what "the source to point at a more precise location" means, though I'd interpret it as more precise coordinates), ie. instead of the general link in the Ghumay article to NGA GeoName Database search interface, link to the Ghūmay record directly. --Para (talk) 11:11, 11 July 2008 (UTC)

[edit] In general

As a related note, User:Zyxw has created Template:HybridMapLink, which is a template that gives an external link randomly out of many services, basically a GeoHack in template form. Any thoughts on that? Should the use of such a template be promoted, should it exist at all, should it be done with a toolserver tool that uses the Map sources list, or should such blind one-click-to-external-services just not be done? --Para (talk) 08:29, 9 July 2008 (UTC)

WTF?!! A randomly selected link?! What got would that do except easing the users conscience with some weird concept of fairness toward the map providers. This should be crushed by elephant. It is useless and we should once and for all discourage the one-click-to-external-service concept. --Dschwen 12:37, 9 July 2008 (UTC)

Alright, if anyone really wants to have a shortcut to GoogleMaps or whatever, I'm working on a configurable QuickLink(tm) feature for the WikiMiniAtlas. Activate it for testing like so. --Dschwen 19:34, 9 July 2008 (UTC)

I was thinking of the architecture for a thing like that, and it occurred to me that why implement GeoHack again in Javascript, when it would be possible to use the existing framework as a redirector with only small changes. This would be similar to the wgs2tky conversion tool that's used on Template:GeoTemplate to introduce new variables that GeoHack doesn't support at the moment. The Javascript part could simply let the user choose a service and link the choices to a yet-to-be-implemented redirector mode in GeoHack. To make the list of choices community editable, they could be on a wiki somewhere as pairs of service id, service url with {parameters} similar to how they're on GeoTemplate now. That list could then be fetched with Javascript so that the redirector requests would be of the type redirector?lat,lon&url=maps.service.domain/?q={latdegdec},{londegdec}, or fetched on server side with the requests like redirector?lat,lon&service=mapservice. This way the Javascript part wouldn't have to understand anything about parameter replacement or complex conversions. How's that? --Para (talk) 11:48, 14 July 2008 (UTC)

That is a good idea. I'd definetely go for redirector?lat,lon&service=mapservice to avoid any exploitability though. This should be easy to implement. --Dschwen 14:39, 14 July 2008 (UTC)

Yes, I agree, but in addition to Zyxw I have seen two other users loudly pushing for a link to "any map" [5][6]. The first one has a good account on the mindset of this supposed group of people. Do they represent a significant number of our readers? A one-click GeoHack in Javascript sounds useful to these editors, but are they just thinking of their own habits, however narrow they may be, and reflecting them on everyone else? I personally don't understand how someone could not get accustomed to a specific service, be it for maps or anything else, but is it just me then? Is awareness of all the available information online what we should aim for, and how could that be done? I just found recently that in Google Earth you can see full screen Street View images outside the US in some places, and it would be great to let people know of that, but where could we advertise all the available services in such a detailed way? Or is that just outside Wikipedia's goals as a project of free content? --Para (talk) 09:48, 10 July 2008 (UTC)

[edit] Confusing for the non-expert user

I tried to add coordinates for Shanghai_Jiao_Tong_University. For a non-expert, this is not an easy task. First of all, the format. There are two formats, coor and coord. Can't you just settle for one? I don't really care about the difference, just tell me the one I should use. I assumed that coord is the newer one and used it. Second, where to put the info? I added it in the info box (coordinates=31°12′3″N 121°25′47″E / 31.20083, 121.42972|). However, it is not displayed in the article. Did I do something wrong? Simplifying the manual (Wikipedia:Manual_of_Style_(dates_and_numbers)#f1fff5phical_coordinates) could help: tell us where to put what.

[edit] Response

Responding to IP address 202.120.34.22 comment posted immediately above:

I went ahead and updated the Shanghai Jiao Tong University article, with:

• coor={{coord|31|12|3|N|121|25|47|E|region:CN_type:edu|display=inline,title|name=Shanghai Jiao Tong University}}|

The issue or problem was that {{Infobox University}} uses "coor=" for the field; and the one which was there was "coordinates=".

In general, {{coord}} is the "preferred" template. I added "region:CN" (assuming "CN" is the ISO-3166 2-character abbreviation for China?

which helps some "map readers" pull up the appropriate map. "display=inline,title" tells it to display them where the {{coord}} template is,

as well as in the Wiki article "title" bar at the top of the page (where Google and other mapping/search services looks for coordinates).

"name=" supplies a label or name which some maps use to label the "pushpin" or mark on the map.

Yes, there are "too many choices", and they should at least give a "best" or "recommended" example at the start for the majority of Wiki contributors.

Not all Infobox templates accept a {{coord}} (or other "Geo") template,

There are those Infoboxes which require separate lat and long degrees, minutes, seconds, and direction fields.

I am not sure if there is any easy way to deal with those? and

There are some which do not have a specific "coordinates" field,

Sometimes coordinates can be placed in a more general text field like "Location" and it might work.

LeheckaG (talk) 17:04, 8 July 2008 (UTC)

I updated SJTU with:

• coor={{coord|31|12|3|N|121|25|47|E|region:CN-31_type:edu|display=inline,title|name=Shanghai Jiao Tong University}}|

which is a more specific "region:" code. ISO_3166-1_alpha-2 confirms the "CN" means China, and leads one to ISO_3166-2,

which in turn leads one to ISO_3166-2:CN and "CN-31" means "Shanghai".

LeheckaG (talk) 17:20, 8 July 2008 (UTC)

Also depending on how accurate your coordinates are, you probably want to set "_scale:" (similar to type:),

probably to 10,000? Since "type:edu" is an "undefined" type in GeoHack - it defaults to 300,000. (unless someone updates GeoHack with default scales for the new types (like "edu") which were "arbitrarily" added... LeheckaG (talk) 06:26, 9 July 2008 (UTC)

LeheckaG, thanks for the answer. I did not realize that the coord template needs to be "registered" in the infobox. Thanks also for the info about "display=inline,title" and "name". This should be added to the manual. I'm still unsure where to put further "coord" templates. Anywhere in the text or in the infobox? If I put the info somewhere in the text, I would avoid the dependency of the infobox, wouldn't I? Does the place mater?

[edit] Response

The "main" coordinates in an article (if there are more than one) should have the "display=inline,title" parameter,

usually any others should have only "inline" (which is the default - so "display=inline" does not need to be specified on the others).

Just make sure that you put "display=inline,title" on only one (the main one).

For instance, many geographic "linear" features actually "branch out";

The "mouth" (main artery, like of a river) is considered to be the "main" coordinate.

The "origin" or "source" are considered secondary coordinates.

In general, the "best" or preferred place(s) for the {{coord}} template are:

• In the Infoxbox, if it has some form of coord((inate)(s)) field; or

• if an Infobox does not have a specific coord/coordinate(s) field, then it can be placed in a "text" field like "Location".

• In a (Wiki-)table of other coordinates, for instance "List of ..." articles or sections.
• Inline within a "Geography" or "Location" sub-section, where an article's geography or location are other wise described.
• Last choice (which many "legacy" articles seem to be) is at or near the bottom of the page (like External links in some U.S. cities).

The goals are to get the main coordinates:

• into the article's title bar (so that the article appears on Google and other maps), and
• on the first or top-most "screen-full", so that they are "consistently" where readers can find them there.

LeheckaG (talk) 05:27, 10 July 2008 (UTC)

[edit] TfD nomination of Template:HybridMapLink

Template:HybridMapLink has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. — NE2 12:54, 9 July 2008 (UTC)

[edit] type:state, adm1st, adm2nd

As the US has states (type:state), US counties should they use "type:adm1st"? -- User:Docu

Yes, It is reasonable to use type:adm1st for U.S. "Counties" or "Boroughs", and type:adm2nd for U.S. "Townships" (whether civil subdivisions or Public Land Survey System ones). Keep in mind the (original) intent appears to be to a "shortcut" to set the scale, so check to make sure that the selected scale (see the tables above) roughly corresponds to what is being viewed. For instance, even though Alaska and Rhode Island are both type:state, they differ in scale by 1:429, so at least one of the should have a more appropriate scale: parameter also specified. The same will go for U.S. counties, where "The Unorganized Borough, Alaska" is several hundred thousand square miles (most of Alaska) versus whatever the smallest U.S. county is either: Kalawao_County,_Hawaii or Arlington_County,_Virginia depending on whether you do not or do count territorial water in their areas. The largest and smallest counties differ in scale by 1:10,000. I understand why you would want to use "type:" for additional types not currently specified in the ToolServer.Org source code implementation to further clarify what kind of coordinate - but someone really needs to update ToolServer.Org for any new types where the default scale of 1:300,000 is not appropriate.

LeheckaG (talk) 16:18, 17 July 2008 (UTC)

Ok, I will add that to the type description. As for the new type, if we agree on the scales to define, it should be easy to add them to the toolserver. -- User:Docu

Also or - "Parishes", Louisiana's version of an Alaskan Borough or U.S. County. Townships (in the PLSS sense above are either 5 or 6 miles by 5 or 6 miles) and are initially numbered "Township number Direction, Range number Direction, alpha Meridian" by the land survey and often later "named". For instance, the Port of Anchorage (Alaska) spans "Townships 13 and 14 North, Ranges 3 and 4 West, Seward Meridian" and the Port of Cleveland (Ohio) spans "Townships 7 and 8 North, Ranges 12 and 13 West, Connecticut Western Reserve Meridian". Alaska (surveying) just goes by the "numbers"; in Ohio most of the (PLSS) Townships were later named, sometimes the later civil subdivision boundaries align with the PLSS surveyed Township boundaries, and other times they do not. LeheckaG (talk) 19:10, 17 July 2008 (UTC)

[edit] Scales for new types

I added sample scales for the types that aren't yet defined in geohack (see WP:GEO#fff1ff:T).

Please feel free to improve them. I hope that eventually they will be added to geohack. -- User:Docu

Thanks Docu. I'll check them out. Spencer^T♦C 14:04, 22 July 2008 (UTC)

They are active now. -- User:Docu

[edit] Request a map to be made?

Is there a place to request a map to be made for a project? I want a clean SVG map of Minneapolis-St. Paul metropolitan area to use for various Infoboxes. Considering Google is copyrighted how are people suppose to implement maps? .:davumaya:. 12:42, 22 July 2008 (UTC)

You might want to see Wikipedia:WikiProject Maps. Spencer^T♦C 14:03, 22 July 2008 (UTC)

[edit] PD sources

As Spencer suggested, WP Maps would be a good place to ask.

What "level of detail" (map features) are you looking for?

In general, U.S. (Federal) Government works are "Public Domain" (there are a few exceptions). For a Minneapolis-St. Paul map, you might be able to find a .GIF, .JPG, .PNG graphic from local or state government. If you find such, and can find what kind of copyright/license might apply, then you are best off uploading it as a .JPG or .PNG graphic to (WikiMedia) Commons. To generate a true .SVG (scalable vector graphic), as opposed to a "SVG" wrapper around a bit-map, you need (point and vector) data from a GIS (Geographic Information System, most are in downloadable in one of the various ESRI "proprietary" formats) and then you need the tools to take that data and create a .SVG out of it. You can find U.S. federal government GIS data from the USGS, US Census Bureau, NOAA, US Army Corps of Engineers, ... lots of federal government agencies which have produced "maps". For a couple Wiki articles, I needed to find out the rough boundaries of a U.S. Census tract (which are downloadable as ESRI files), I was able to extract the corner or turning coordinates out of the file and use some Wiki tools like:

• {{GeoGroupTemplate}} to produce a link to a list of coordinates on a Google map,
• {{Location map+}} and {{Location map~}} to produce a "crude" plot of coordinates on a Wiki article page.

From the .SVG file sizes which I have seen (they should be much smaller), many are either bit-maps encapsulated in a SVG wrapper (which is the "wrong" way) or generated by software which does not do a very good job of "optimizing" them (i.e. lots of unnecessary .SVG file contents/size). The same can be said for CSS (cascading style sheet) files - most should be smaller than they are (if either hand-coded or through better optimization by the programs which write them). LeheckaG (talk) 14:11, 22 July 2008 (UTC)

[edit] Too many coordinates

Take a look at this article. Within the first few inches of the page, the coordinates are given 3 separate times (each time with a separate globe icon to click on). I would say that half of the location articles out there now have at least two sets of coordinates at the beginning of the article - once in the title bar and once in the infobox, then often once again in the body text. Can we institute some kind of guidelines on which of these locations should take precedence? There is no reason to have so much redundant information in our articles. Kaldari (talk) 21:05, 23 July 2008 (UTC)

I concur that most articles should not have coordinates outside of:

• {{Geobox}} or {{Infobox}},
• Title bar,
• Table or list of coordinates relevant to the article

With (2) exceptions, where:

• article discusses relevant nearby or similarly-named features and a list of table does not seem appropriate
• {{Geobox}} or {{Infobox}} "defect", where {{Coord}} additional/optional (|region:US-XX_type:landmark_scale:50000_source:GNIS|display=inline,title|name=) ... parameters cannot be supplied.

I have seen where:

• (For example) WP Cities initially recommended that coordinates be placed under "External links" (not really realizing that the same functionality was in the Title bar and {{Geobox}}/{{Infobox}}); WP Cities has since updated their recommendations.
• Coordinates were placed in-line (text) primarily because of a {{Geobox}}/{{Infobox}} defect, either:

• not "automatically" appearing in the title bar or
• showing up on a {{GeoGroupTemplate}} map with a number instead of a name.

• I have less frequently seen region, scale (or type) parameters be the reason (but they should be set more often than not), i.e. many coordinate links do not provide the region map "hint" (so that an appropriate collection of map links can be supplied), and many coordinates do not have the appropriate scale set (so that the feature is clearly and completely visible - one should not have to zoom in or out to initially see the feature). I am "guilty among others for not setting an appropriate scale.

The technical reason behind Coordinates being both in a {{Geobox}} or {{Infobox}} AND a Title bar is that:

• the Title bar's "audience" is primarily external reader programs and sites which "skim" Wiki articles (for instance how Google places Wiki articles on Google Earth or Google Maps)
• {{Geobox}} or {{Infobox}} primary "audience" is the actual human article readers - for a summary of the "important" details

LeheckaG (talk) 07:56, 24 July 2008 (UTC)

I've seen inline coordinates in the "geography" sections of many articles. I would feel confortable leaving them there...the coordinates template bring up maps and such, so leaving them there feels appropriate to me. Spencer^T♦C 11:41, 24 July 2008 (UTC)

Oh, and an example: Cleveland, Ohio...more direct link: Cleveland,_Ohio#f1fff5phy. Spencer^T♦C 11:42, 24 July 2008 (UTC)

No, I don't buy it for exactly the same reason as we have only a single wikilink to another article, on the first occurrence of the anchor. It would be quite possible in the geog section to provide a verbal description of its location and expect users to pick up coord data from the top of the page or the infobox. --Tagishsimon (talk) 12:01, 24 July 2008 (UTC)

[edit] Geobox/Infobox

As I cited above, some {{Geobox}} and {{Infobox}} templates do not accept a coordinates template, like {{Coord}}, but rather usually accept separate named latitude and longitude degrees fields (both with additional, optional and separate minutes and seconds fields) and directions (N/S and E/W). They build up coordinates rather than parsing them.

I have seen a "rare?" instance where at least one Geobox/Infobox also accepted an optional parameters field where display,name,region,type,scale,source could also be supplied. I ran into the issue of supplying the pipe character as part of the parameter string instead of a separator to the next field, which I got around the issue by instead supplying a ('&') ampersand character which the ToolServer.Org map interface uses for its separator character. I am not sure whether I should have used {{!}} or &#edfbff; instead, but supplying the single ('&') ampersand character worked.

I propose that we start off with a place (Table) to note down which Geobox/Infobox templates "work properly" allowing the flexibility (i.e. which set of coordinates flows through to the Title bar) and the additional/optional parameters, and which do not. Followed by recommendations to the "broken" template authors of similar Geobox/Infobox templates which "work properly" so that they can make the same modifications so that theirs work as well.

For instance, I "experimented" with the new/revised "Geobox 2": {{Geobox}} template to create a couple "Port of ..." articles using "Geobox|Port". {{Geobox}} contains more than one type of feature, and so multiple coordinates can be entered in the same Geobox/Infobox, but then the problem of which gets displayed in the Title bar arises, by default they "All?" do. There is an optional parameter to turn off the "main" coordinates from being displayed in the Title bar, and then it turns out that actually turns them All off from being displayed in the Title bar. So it is "all or none" (when I tried), I ended up turning them All off, and specifying the "main" coordinates elsewhere (which creates the "too many coordinates" situation above).

So if we can note down which Geobox/Infobox "work" and which do "not" in a table, then maybe we can get the "broken" Geoboxes/Infoboxes updated? LeheckaG (talk) 07:56, 24 July 2008 (UTC)

[edit] Geobox/Infobox table

LeheckaG (talk) 09:39, 24 July 2008 (UTC)

Infoboxes commonly exist for objects of similar type, which with coordinates allows the same parameters for all the uses of the infobox. They are also commonly for the article's main object, so associating the coordinates with another name shouldn't be necessary. I don't think these mysterious Geobox templates have been discussed here before and I'm not sure what they're for. If they're the main cause of the problems mentioned, then perhaps a short introduction on their differences with infoboxes would be in order?

Anyway, following User:The Anome/Infobox audit and a discussion about the inconsistencies about a year ago, Wikipedia:Manual of Style (dates and numbers)#f1fff5phical coordinates and the guidance in this project now instructs people to use a common set of templates and infobox parameters, but there hasn't been anything organised yet to make infoboxes conform to that style. The issue isn't just how the templates are rendered in HTML or whether the coordinates eventually end up near the title, but how they are entered in the wikitext that is read by reusers of Wikipedia coordinate data. When they are all entered the same way, standardising the display shouldn't be difficult. --Para (talk) 10:19, 24 July 2008 (UTC)

• "name=" One goes from a Wiki article to a map through ToolServer.Org either by clicking on Coordinates or the {{GeoGroupTemplate}} "Map of all coordinates" which "pushpins" each coordinate in an article. Often the "article name" does not flow through to the map, either the plotted point on a map is unnamed or many numbered (and not named) pushpins are seen. "name=" is useful to provide a clue in either case. Which article or feature was I looking at? Is this a river's mouth or its origin/source?
• I am not sure whether {{Geobox}} or {{Infobox}} came first, but they produce similar functionalities for the reader. Apparently the older Geoboxes were similar to Infoboxes with each "Type" being a separate template - which resulted in a similar "many flavors/styles" of Geoboxes and Infoboxes. {{Geobox}} underwent a transformation at some point creating "Geobox 2" - a documentation/version change, where all the Geobox functionalities (for any feature/type) are provided by one single template. Which makes it easy to create a "new" Geobox for a WikiProject usually without coding or modifying a template. Since there is one Geobox template (which superseded the other separate ones) it has the same look and feel, field names, functionality, ... across "types". In comparison, there are many different Infoboxes, with different field names ("coord=" in one, "coordinates=" in another, ...) different functionalities (one image, two images, no images, map, "automatic map", ...) I am not a total Geobox proponent - I see a few Geobox "defects" and some Infobox advantages, but I am a proponent of the method/standardization which Geobox "2" underwent.
• I have seen where both Geobox and Infobox templates have "problems" (why we should have such a table documenting the various Geobox/Infobox "flavors", and how they handle (or should handle) coordinates/maps. Little annoyances like different field names, formats, functionality, ... should become apparent in flushing then out, they perhaps we can have some guidance like coordinates field should be named ..., and point those out to all the ones which vary from a recommendation/standard. I will take a look at the Infobox Audit cited above.LeheckaG (talk) 13:11, 24 July 2008 (UTC)

[edit] Templates

• Personally, I prefer to see one flexible template with parameters (like Coord) be recommended rather than many other separate templates (Coor, Coor at d, Coor at dm, Coor at dms, Coor title d, Coor title dm, Coor title dms, ...) I am not aware of something which can be done with the other templates which cannot be done by supplying appropriate parameters to Coord. If someone can cite an implementation/technical reason why many separate templates are "better", I would like to know what it is?

LeheckaG (talk) 13:11, 24 July 2008 (UTC)

[edit] Coordinate fields

Field names aside - looking at User:The Anome/Infobox audit which was cited above by another, there are several naming variations.

Structurally, Does the Wiki community have a preference for either?

• "coordinates=" field, containing one of the coordinates family of templates which emits a Geo MicroFormat
• two separate latitude and longitude fields (not sure how coordinates are coded/specified?)
• separate latitude and longitude degrees and direction fields, along with optional minutes and seconds fields (where the GeoBox/Infobox builds the Geo MicroFormat)

My personal preference is for a "coordinates=" field containing separate latitude and longitude degrees,minutes,seconds parameters, BUT I also have a preference for an "automatic map" in an article's Geobox/Infobox. Most of the Wiki automatic "locator" or "pushpin" Geobox/Infobox maps which I have seen so far rely on separate latitude and longitude degree (not sure whether they also look at minutes and seconds) fields (rather than parsing out the latitude and longitude from a Geo MicroFormat). If someone has a way for a Geobox/Infobox locator or pushpin map to accept the Geo MicroFormat output by one of the coordinates family of templates, then I do not see a good reason for separate degree,minutes,seconds fields rather than a "coordinates=" field and any of the Geo MicroFormats templates? Getting rid of all the separate fields would simplify maintenance and field naming.

My preference for an "automatic map" is that it would be burdensome to create individual maps for many articles, whereas a more generalized state or county map with a "pushpin" mark on it is usually sufficient. Generally one larger scale map is easier to create and maintain than many small ones, unless a smaller scale map is beneficial or needed for certain features. For the U.S., there are already Locator maps for each State. A dot plotted on State map gives one a rough idea, but not enough information about the locality. If beneficial such Locator maps can also be created for Boroughs/Counties/Parishes or some more notable (surveyed) Townships. I believe it is more beneficial to dynamically overlay a static background map template based on specified coordinates (see how {{Location map+}} and {{Location map~}} work, rather than to create a whole bunch of "... dot on ..." image files which I have seen. LeheckaG (talk) 14:05, 24 July 2008 (UTC)

[edit] Geobox/Infobox other irritations

If we are looking at broken infoboxes and coord templates could we bear in mind these irritations.

UKgridref are often in UK infoboxes. They can be converted to and from WGS84, but often are separate data- leading to two coords being given (usually for different spots) and would do even the OSGB36/WGS84 conversion had been made correctly.

The confusion between dec and dms. Though I prefer to post as dec- not having 60 fingers- I prefer to read in dms. I would submit that data should be stored as dec, and user preference should determine the output format.

That commons uses a {{location}} template while w:en uses a {{coord}} format, making {{location}} available in infoboxes would speed up tagging enormously, when one is working with photos- for example pulling material across from w:de:.

Linear features: rivers have two coordinates- source and outflow- which goes in the titlebox- what do we do with the other. If someone says source- try tramping some open moorland to verify its accuracy River Kinder illustrates this point.

ClemRutter (talk) 08:35, 24 July 2008 (UTC)

One more irritation: what happened to the observation and fixes that OSGB conversion in GeoHack is sometimes wrong? --Para (talk) 10:22, 24 July 2008 (UTC)

I redirected the {{Location}} template on enwiki to {{coord}}, as it is actually being used in some images and pages. I replaced the ones on pages, but left the ones on images. Spencer^T♦C 11:36, 24 July 2008 (UTC)

[edit] My response

The US has a similar issue with "old map" coordinates being stated in North American Datum 1927 rather than 1983 (NAD83/WGS84) coordinates, requiring a conversion. NAD27 to NAD83 conversion usually involves both calculations and look-up tables, so not sure whether they can be "Wikified" into a template to do the conversion, but National Oceanic and Atmospheric Administration has source code available for the conversion, as well as a web-form application. I am not familiar with the UK conversions and whether there are Wiki templates or what (source code) resources are available.

I realize that Dec. coordinates are "easier" to cut & paste, but I find it "easier" to manually work with dms for both input and output. Realize that a Minute is a Nautical Mile 6,076.1 feet (1,852.0 m) of Latitude (and approximates Longitude as well, Longitude accuracy decreases as you approach the poles). I find it easier to manually estimate how far apart coordinates are or adjust them using DMS.

It is ridiculous to see more than 0.1 seconds or more than 0.0001 degrees! (unless one is citing a surveying benchmark monument).

• quick GPS readings get you to 100 feet (2 decimal places, 60 seconds)
• differential or averaged GPS readings to 10 feet (3 decimal places, 6 seconds)
• Satellite imagery#f1fffftion and data, Ground Sample Distance (GSD) varies from 1 pixel = 30 metres (98 ft) 60 seconds to 0.5 metres (20 in) 1 second, references to imagery should not specify significantly more ac