Misplaced Pages

This is an old revision of this page, as edited by Docu (talk | contribs) at 18:08, 26 August 2008 (→coord template one year on). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Geographical coordinates

WikiProject Geographical coordinates is of interest to WikiProject Geographical coordinates, which encourages the use of geographical coordinates in Misplaced Pages. 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

Archives

Index 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 Archive 14 Archive 15 Archive 16 Archive 17 Archive 18 Archive 19 Archive 20 Archive 21 Archive 22 Archive 23 Archive 24 Archive 25 Archive 26 Archive 27 Archive 28 Archive 29 Archive 30

Index

This page has archives. Sections older than 100 days may be automatically archived by Lowercase sigmabot III when more than 2 sections are present.

To do

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

I've created a website wikitude.org - Latitude, Longitude, ... Wikitude. visualizing the coordinates within Misplaced Pages articles. You can find points of interest (POI) in your area (address search), view POIs on a map and read the corresponding Misplaced Pages 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 Misplaced Pages page in a frame. Is that kosher? (SEWilco 20:21, 7 November 2007 (UTC))

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

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

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

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

Title coordinate issues

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

Seems to now have been fixed, but the Gihtsejiegŋa article still cuts it a bit close. Spencer 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 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 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 Misplaced Pages 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 Misplaced Pages:Village pump (technical). Registered users can put a line into their monobook.css file

 #coordinates {
 top:4.5em;
 }

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

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

Best practices, Misplaced Pages and Google

Some of us over at WikiProject Oregon have noticed the new overlay that places Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages data a while ago too. It'll bring more attention to both Misplaced Pages 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 Misplaced Pages / 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 Misplaced Pages. The entry of coordinate data is still inconsistent in Misplaced Pages and is likely to lead to lots of confusion on why one article with top right coordinates is visible on the map but another that looks just the same to the reader is not. Open issues are #Geolinks bot replacement and infobox parameter standardization. High profile reusers with massive computation capabilities may be able to solve the problem in other ways, but that's a bad excuse not to fix it on our end. It needs to be done.
• Size of the icons reusers display. Whether we have anything to do with it or not doesn't matter, we'll get feedback anyway. What information do we provide for determining the size or importance of an article? Categories are too hard to use with anything automated. Types are not extensive enough. Scales aren't used widely enough and aren't related to anything. Dim is neither supported nor used. Coordinate precision isn't consistent between objects of different size and we haven't agreed on which point the coordinates indicate, so implicit scale from the precision is unusable. That's a whole lot of problems, but I think we can fix them by perhaps adding some more types and slowly starting to use the dim parameter. For that the necessary conversions need to be added to GeoHack, and then the scale parameters either converted and verified or added to articles manually. First, we'll need a table of the various zoom and scale parameters used by map services, and then the corresponding real world distances that fit into those views.
• Better explanation of updates. All reuse is for now, and probably will be for a long to come, dependent on database dumps. It would be good if we could keep a list up to date of available English Misplaced Pages 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:Misplaced Pages:WikiProjekt_Georeferenzierung/Wikipedia-World/en, i think it is for reusers not a problem to use our datas. Also on geonames.org the datas are available. But off course the count of templates should be reduce. An international template for all languages would be the best, so we created on german wikipedia our new template de:Template:Coordinate so that we need only one template and use English syntax.
• For converting "dim" into "scale" on geohack I create a formula like dim=42000/((2^scale)*cos(latitude)) this should be tested and integrated into geohack.
• For relevance of articles we should talk with user:henrik, he has for his wikistats a february-dump which we could need in a database on toolserver. So how google works without relevance, I don't like. --Kolossos (talk) 21:15, 25 May 2008 (UTC)

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

Lakes needing coordinates

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

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

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

If the field is missing, the articles are added to Category:Misplaced Pages 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 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 00:28, 22 May 2008 (UTC)

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

Satyr

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

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

Globe

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 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 22:28, 30 May 2008 (UTC)

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

type:waterbody for rivers, glaciers

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

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

New types (WP:GEO#type:T)

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

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

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

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

I updated the list accordingly. -- User:Docu

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

I updated the list accordingly. -- User:Docu

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

Concern

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

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

Scaling

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

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)

Type tags, scales etc

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

Two tags on one page . . .

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

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

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

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

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

Maplinks and FritzpollBot

A bot was recently approved (Misplaced Pages: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 Misplaced Pages'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 Misplaced Pages: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)", and also that "Fritzpoll has already agreed that those links are problematic and won't be included, if I understand him correctly". 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" 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."

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 Misplaced Pages 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)

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" . 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 Misplaced Pages's goals as a project of free content? --Para (talk) 09:48, 10 July 2008 (UTC)

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°N 121.42972°E / 31.20083; 121.42972|). However, it is not displayed in the article. Did I do something wrong? Simplifying the manual (Misplaced Pages:Manual_of_Style_(dates_and_numbers)#Geographical_coordinates) could help: tell us where to put what.

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?

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)

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)

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)

Scales for new types

I added sample scales for the types that aren't yet defined in geohack (see WP:GEO#type: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 14:04, 22 July 2008 (UTC)

They are active now. -- User:Docu

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 Misplaced Pages:WikiProject Maps. Spencer 14:03, 22 July 2008 (UTC)

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)

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 11:41, 24 July 2008 (UTC)

Oh, and an example: Cleveland, Ohio...more direct link: Cleveland,_Ohio#Geography. Spencer 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)

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 | 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)

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, Misplaced Pages:Manual of Style (dates and numbers)#Geographical 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 Misplaced Pages 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)

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)

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)

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 11:36, 24 July 2008 (UTC)

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#Resolution 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 accuracy than pixels (other than center versus corner/edge)
• Aerial photography can have better GSD, but usually still in feet ("maybe" inches)
• Professional surveyors can obtain fractional inch or centimeter accuracy; but for most purposes - it just needs to be "close enough" on an image or map

I would say that Decimal should be used when people are cutting and pasting a lot of coordinates from and citing an "official" source which does not have DMS otherwise available.

I am not sure what the differences are between the templates {{Coord}}, {{Location}} and the Commons template "Location".

Since rivers generally have one "mouth" (outflow) and multiple sources/tributaries (inflows); common practice is that the river's mouth (outflow) is the "main"/title coordinate. See my Geobox/Infobox comments and table above.

A stream's primary origin/source is "defined" in a few possible ways:

• The Source (river or stream) article cites a claim of how the National Geographic Society or Smithsonian Institution define an origin or source (without giving a clear reference citation to a verifiable "definition"). The claim is that an origin or source is the most distant point (measured in River Miles) from which water flows. River miles are measured from the mouth following the center of typical water flow upstream.

but then the article cites several examples which contradict portions of the above definition:

• while trying to say that the Nile source is NOT Lake Victoria, they cite the Kagera River as the "largest" river flowing into the lake; it is not clear that Kagera is the "longest" flowing into the lake as well?
• The United States Geological Survey regards the Missouri River as "longer" than the Mississippi River; if you followed Source (river or stream) "definition" above, the "river with the lowest mouth" in a watershed would ALWAYS be the longest (i.e. the Mississippi would be "longer than" the Missouri). It is my understanding that the USGS definition follows the greatest natural/typical flow of water, i.e. at grossly unequal confluences, the river follows the one with the greater flow upstream. So at the Mississippi and Missouri confluence, the "Mississippi" has a greater flow, so the source goes off in that direction rather than the "most distant point" by River Miles in the watershed.

The "common sense" definition is following the greater flow/larger stem upstream from each confluence. Each lesser flow/smaller stem is instead a tributary, rather than the "main stem". Natural erosion can give one clues as to which flow is usually greater when the flows are erratic, i.e. assuming a level landscape and similar geological deposits - the stream with the larger channel or valley by volume (depth x width) has had the greater average flow.

A Geobox or Infobox should use a cited "official" reference source for coordinates whenever possible. When multiple "official" reference sources disagree without an obvious error, Misplaced Pages should not "take sides", and instead the most "reasonable" (possibly an average, or what makes a map look "best") coordinates be posted with a {{Cref}} citation to a {{Cnote}} explanation placed in a "Notes" Section just before the "References" Section with the various coordinates and references cited.

For instance, United States Geological Survey Geographic Names Information System often has several coordinates for a place: "Census", "Civil", "Locale", "Populated Place" ... Use which makes the "most sense" in the context you conveying, for instance "Census" and "Civil" often specify the geographic center within civil or statistical "boundaries" which might not actually be where a city is or where people live (i.e. "Downtown"). "Populated Place" usually is where the USGS estimated the city or people are for mapping purposes. So if you are talking about a "City", then try to use the "Civil" coordinates unless they obviously do not make sense: in water, on a mountain, ... Usually only use "Census" coordinates when you are ONLY talking in the context of a Census statistical area and not trying to talk about it as a "city", or otherwise populated place. LeheckaG (talk) 12:19, 24 July 2008 (UTC)

More

It is fascinating to see how you work, and how differently. Though having used furlongs, feet and inches at school I don't think I have used them 'in anger' since 1970. It is said here in the walking community that we drive in miles but walk in kilometres. On commons, I work to a sub 7m accuracy, ie 4dp at latitude 51 north. Though the tool I have written to help in these Helmert conversions OSTOWIKIcan achieve greater. I use Google maps to place the spot where I took the image. The Ordnance Survey site gives an alternative convertor. The graticule on all UK OSmaps is a 1km square.

Your approach to rivers - they only have one mouth and many source- is one that I think should be policy for infoboxes- though River Teise is an example of bifurcation, this can be handled pragmatically. However WP:RIVERS gives no example on how to geotag a river. It uses the Scheldt as an example, and it is plain that the source is in the Title space. Again this is a bifurcated river. I agree that deciding the longest tributary is not satisfactory, and measuring water flow over the whole year is just not practical if we are using 7m accuracy.

The US has the luxury of a short history- the definition I was given in the past for tagging a European city was- the centre of the earliest known settlement of that name- and to be honest the centre of forum in a Roman fort that has given its name to a later time did seem a little obtuse- if a damn sight better than the tag given to London a few weeks ago , which was in the City of Westminster about 5km away from the City of London. (London now has no geotag!). I am not aware of any official list of UK lat/longs- gridreferences being more popular or post codes.

I do maintain that we need to look at the possibility of integrating {{location}} into our infoboxes and possibly our {{coord}} templates.

Its good to start the dialogue. ClemRutter (talk) 14:10, 24 July 2008 (UTC)

Coor3d

I propose a three-dimensional coordinate template {{Coor3d}} which would either be:

• a derivative/new version of {{Coord}} which accepts an optional elevation parameter (either: positional after latitude and longitude, or named?)
• a redirect to {{Coord}} or vice versa, if {{Coord}} can be modified to accept an optional elevation parameter without affecting other uses?

A key point would be first determining how external programs (Google, et cetera) handle elevation in addition to latitude and longitude LeheckaG (talk) 07:56, 24 July 2008 (UTC)

I'm not aware of any application that commonly uses such data, and so importing it on Misplaced Pages doesn't sound very useful. In many cases across different projects, optional data has been entered in the parameter:value format using the original template. --Para (talk) 10:26, 24 July 2008 (UTC)

As it is, getting coordinates into every article is a challenge. Now adding elevation...Hm, I'm not sure that's exactly feasible. Spencer 11:31, 24 July 2008 (UTC)

I have been filling in the Geobox/Infobox separate elevation fields whenever they exist when I supply the coordinates (sometimes coordinates and elevation are available from the same source, sometimes it requires looking an elevation up separately). In bridges, dams, lakes/reservoirs, rivers/streams, railroads, ... elevation is usually a significant concern and provides clues about other relationships. While 3-D coordinates are in their "infancy" compared to 2-D coordinate uses, they do exist, and providing for them now might get more of them populated. Ignoring elevation is an "Ostrich" approach which (granted) IF 3-D visualization applications (like Google Earth as opposed to Google Maps) become more popular ... Like it would be nice to know where (in 3-D space the highest or deepest point of a feature is ...) My proposal is just that there be a standard way of supplying 3D coordinates (2D Coordinates+Elevation) together when both are known, and that such information be emitted by Wiki in the appropriate Geo Microformat. LeheckaG (talk) 12:37, 24 July 2008 (UTC)

There is a webservice which supplies ground elevation for given coordinates (I have to look up the URL). This might be usefull (we discussed it on commons). But I strongly advise against a new template. Rather use a new parameter in the spirit of heading: on commons, alt: for example. --Dschwen 12:50, 24 July 2008 (UTC)

I am aware of Wiki template coding but not of more intricate details, I have done a few but I am still learning. If {{Coord}} would be modified, my proposal is that:

• an optional numeric elevation parameter (for instance without commas in the U.S, but with a decimal point if tenths are specified), followed by a co-requisite unit abbreviation parameter (either ft for feet or m for meters), be specified positionally after latitude and longitude and before the other optional parameters. For instance, with made-up coordinates and elevation:
• {{Coord|45|30|15|N|90|45|30|W|5000|ft|region:US-WI_type:landmark_scale:10000|name=Hawkins-Ingram}}

If an elevation is not available or known, then both the numeric elevation and co-requisite unit abbreviation parameter would be omitted:

• {{Coord|45|30|15|N|90|45|30|W|region:US-WI_type:landmark_scale:10000|name=Hawkins-Ingram}}

resulting in the present {{Coord}} functionality when the optional elevation is omitted.

An alternative implementation would be to permit a named ft= or m= parameter anywhere after the positional parameters, something like:

• {{Coord|45|30|15|N|90|45|30|W|region:US-WI_type:landmark_scale:10000|ft=5000|name=Hawkins-Ingram}}

I am not sure whether "region:","type:","scale:" are considered positional (my guess) or named parameters?

Because {{Coord}} is highly used, my proposal for implementation would be to copy {{Coord}} to {{Coor3d}} and for editors to perform such modifications there. If/when successfully tested, then either re-direct Coord to Coor3d or copy Coor3d back over Coord.

Before doing any of this, the prerequisite would be to determine how Geo Microformat would/should handle elevation? LeheckaG (talk) 14:37, 24 July 2008 (UTC)

To reiterate: {{Coord|45|30|15|N|90|45|30|W|region:US-WI_type:landmark_scale:10000_alt:5000ft|name=Hawkins-Ingram}}. Altitude won't be needed for the 2D mapservices on the geohack. But having the data ready for extraction might be nice for labeling panoramic images for example. --Dschwen 15:27, 24 July 2008 (UTC)

There are a handful of "3D mapservices" like Google Earth on GeoHack/ToolServer, someone would need to go through each one and determine which are "3D capable" (maybe make a "highlighted section for them"?)

Apparently the Deutsch/German Misplaced Pages already has a "Coordinate" template with an "elevation=" parameter, according to the GeoHack ToolServer page (see "Wiki text markup" table at the bottom) and de:Vorlage:Coordinate. On the English Misplaced Pages, {{Coordinate}} instead redirects to {{Coor title dms}}.

To understand what effect the coordinate templates have, they emit a Geo (microformat). I do not see a big deal with adding an additional optional positional (3rd.) altitude/elevation parameter to class "geo" (the microformat).

There are many practical uses for 3-D coordinates. A few are: locations of geosynchronous satellites; "outer marker" point of an airport, which is a point in the air along an approach path through which planes try to pass in order to land, ...

Labeling images presents the additional "problems" of are the coordinates of the camera/viewer or of the the subject? And in either case, what was the "bearing" and orientation between the camera and the subject i.e. what azimuth/compass direction (and geographic or magnetic?), and ascension (angle off the ground), and similar some distance or zoom clue/hint similar to map scales.

See also Geotagging, LOC record, ICBM address LeheckaG (talk) 16:40, 24 July 2008 (UTC)

In reply to Dschwen's comment about a webservice available to look-up known or estimated surface elevations given coordinates; there are a few posted on the GeoHack/ToolServer page when you click on a set of Wiki coordinates, scroll down the page and you should see Elevation. LeheckaG (talk) 17:14, 24 July 2008 (UTC)

Elevation as stated above will not work. Ignoring the problem of the unit of measurement, you must express the datum. UK heights are express as height above mean sealevel at Newlyn, ODN which is an approximation to the local geoid model while GPS yields the ellipsoid height. A GPS system at sea level at Newlyn I believe is -31m. (can't find reference-differing European Datums explains further.). It is not simply the idiocy of suggesting that everything beneath the 31m contour is beneath the sea- but because we are comparing geoid with ellipsoid you cannot subtract 31 from all spot heights on UK maps to produce a figure, as the number varies according to to location.

If you examine the German template de:Vorlage:Coordinate you see that ISO 3166 codes (for example ISO 3166-2:DE ) are used and one presumes that an average geoid ellipsoid distance can be determined from that. This leads me to conclusion that implementing de:Vorlage:Coordinate is probably a better way forward, provision is even made for OSGB36 datum though that hasn't been implemented. There is also a Dim parameter, useful for giving a measure to items like factories, villages. Some additional provision will need to be added for non SI units of measure, but apart from that all that needs to be done is translate the documentation.ClemRutter (talk) 18:46, 24 July 2008 (UTC)

I point out Geodesy#Heights mentions several heights, and points out: "Satellite positioning receivers typically provide ellipsoidal heights, unless they are fitted with special conversion software based on a model of the geoid." Maybe we should adopt ellipsoidal heights and deal with conversion if we change later. Maybe we should avoid altitude as the label and require names which identify the kind of altitude/height measurement. -- SEWilco (talk) 16:58, 25 July 2008 (UTC)

I was looking for something else and ran across MW:Extension:Gis/geo tag which cites RFC 1876 A Means for Expressing Location Information in the Domain Name System and RFC 2624 update as the basis (standard) for the Wiki geo tag from which the Coor(d) templates later developed. The cited standard does specify Altitude, which the "flat Earth" geo tag implementers did not document when they implemented the geo tag. It is not that an altitude could not be specified within a geo tag pair, but rather that such usage was not documented. LeheckaG (talk) 08:52, 6 August 2008 (UTC)

Avoiding template dilution

(A different template discussion seems to have appeared which is separate from the above 3D discussion. -- SEWilco (talk) 16:26, 25 July 2008 (UTC))

On the English Misplaced Pages, there are (3) articles Special:WhatLinksHere/Template:Coordinate which link to {{Coordinate}} which redirects to {{Coor title dms}}. Per the last post, I propose that de:Vorlage:Coordinate be copied to the English Misplaced Pages {{Coordinate}} replacing the current redirect, and fixing the (3) articles as necessary (whether changing them to point to Coor title dms directly or using Coordinate instead. If there is consensus on this change (replacing Coordinate redirect with the Deutsch/German template), then I can take a stab at translating the corresponding German documentation to English. LeheckaG (talk) 20:08, 24 July 2008 (UTC)

Please do not create new coordinate templates or do major modifications to the existing ones without having a significant number of articles and potentially popular applications for the new features. One of the goals of this project is to keep coordinate templates to a minimum, and we're still not through with the previous template changes, as you noticed in the template section somewhere above. It's not a good idea to constantly change the templates. Creating template redirects that work as if they were the original template is harmful as well, as it makes the format deviate from the one discussed and agreed upon in this project. If such redirecting templates are created for people unfamiliar with the English Misplaced Pages, they should be made to display a warning of being unsupported templates and instruct how to use the correct one instead. The additional information can go to the optional parameters field as the tools that use the data are easier to modify than changing the standard way of coordinate entry. --Para (talk) 20:55, 24 July 2008 (UTC)

I have to agree with Para that the critical factor must be consideration of resources. Dilution is wrong. There is a lot of cross wiki work going on, and a direct cut and paste from :de: to :fr: or :en: would be very labour saving, particularly from and to :commons: and personally from and to :de:. When the latest template changes have been successfully absorbed can be put unification of templates on the agenda- and would hope that de:Vorlage:Coordinate is at the forefront of the debate. ClemRutter (talk) 21:43, 24 July 2008 (UTC)

Based on comments that "Coord" is longer, I updated the table above.

• Coor d, Coor dm and Coor dms actually cost +1, +2 and +3 characters more to invoke.
• Coor at d, Coor at dm, Coor at dms, Coor title d, Coor title dm and Coor title dms "save" -17, -16, -15, -7, -6 and -5 characters.
• Coor d, Coor dm, Coor title d, Coor title dm and Coor title dms save -110, -79, -185, 161- and -148 characters (source/transculsion).
• Coor dms, Coor at d, Coor at dm and Coor at dms cost +87, +159, +200, +425 characters more (source/transclusion).

So the only "Coor d" templates which "save" characters overall are:

• Coor d
• Cood dm
• Coor title d
• Coor title dm
• Coor title dms

Which I am guessing are not used as much? Consolidating from 9 templates down to 1 saves on: cache, documentation, learning curve, maintenance effort, ... LeheckaG (talk) 17:03, 25 July 2008 (UTC)

i.e. All the various usage combinations of the coor (at/title) d/dm/dms templates can be reduced to using the coord template with the display= template paramter; the default is display=inline with the same effect or functionality as coor d, coor dm, coor dms templates. My two minor complaints with the Coor(d) templates are not being able to specify an (optional) elevation, and perhaps some more concise documentation. So a reasonable start would be to have a bot go through all the articles which link to templates coor d, coor dm, or coor dms and update them to use template coord instead. And strongly recommend that that those (3) of the coordinate family templates not be used. LeheckaG (talk) 23:00, 24 July 2008 (UTC)

Agree, coor templates should be deprectated. But it is not true that you are not able to specify an (optional) elevation. See above. --Dschwen 03:30, 25 July 2008 (UTC)

Personally, I prefer the coor * templates. The input format is defined ahead and easily maintainable. It appears that result from various coord inputs isn't easily handled. Questions in regards to the syntax problems of the template remain unanswered (Template_talk:Coord#Please_clarify_syntax).

A recent review of the various variants lead to the development of de:Template:Coordinate. This may be a viable replacement for the various current templates. BTW it offers also an elevation field -- User:Docu

Yes, better template documentation is needed. I added replies to questions asked at Template_talk:Coord#Please_clarify_syntax.

• The easiest way to understand {{Coord}} is to assume that it works like {{Coor dms}},
• Then realize that you can totally omit the seconds or both the seconds and minutes fields (i.e. do not keep "empty" positional parameter fields).
• Then realize that {{Coor title dms}}, {{Coor title dm}} and {{Coor title d}} can be achieved by adding "|display=title" at the end of everything else as a template parameter.
• Similarly, {{Coor at dms}}, {{Coor at dm}} and {{Coor at d}} can be achieved by adding "|display=inline,title" at the end of everything else as a template parameter. LeheckaG (talk) 07:47, 25 July 2008 (UTC)

I have to agree with Docu in prefering the coor * templates. In addition, you can see they use less text than the coord templates to do the same thing. Spencer 16:27, 25 July 2008 (UTC)

Yeah, but if we let personal preference trump community consensus (which in this case happens to be common sense as well) it would be a blow to the project. --Dschwen 17:40, 25 July 2008 (UTC)

I understand completely...I was also adding about the number of characters as one of my reasons for use. Spencer 18:15, 25 July 2008 (UTC)

It would be nice if we could agree that all of the templates mentioned above should be replaced by de:Template:Coordinate. It seems far less confusing than {{coord}}. -- User:Docu

I would be happy if I thought we were working towards de:Template:Coordinate. There appear to be three problems with this: firstly there is a need for a extra parameter for folk who use furlongs, chains feet etc. as it only supports SI units. Can I suggest units=SI/imperial default SI. Secondly, the lat/lons are entered as NS=12.34|EW=56.789 which makes it a pain to cut and paste from commons I suggest that 12.34|56.789 should be retainedand the use of dms is different. Thirdly display=inline,title should be retained. Other than that, one can take a de:Template:Coordinate and paste it into a {{coord}} and it apparently works. However this template only appears to be used about 250 times on de:wiki and never outside a template definition. The only consequence of working towards is that we should try to standardise the syntax of additional optional parameters: alt should be replaced with elevation. Please correct me if I am wildly off track.ClemRutter (talk) 08:01, 26 July 2008 (UTC)

We could easily include a unit field (elevation_unit) for the elevation or add a elevation_ft field.

According to de:Special:MostLinkedTemplates, there are already 70,000 coordinates using de:Template:Coordinate. As most of the compilations are done based on Stefan Kühn/Kolossos' work, the template could easily be supported for coordinates here as well. -- User:Docu

Add to the to do list {{coord}}

Bold assertion. The {{coord}} documentation is a programmer's comment rather than a useful description of the template. All the detail is there but you need to be seriously committed to find it- and have background knowledge gleaned from other templates to interpret it. It is a protected page, so I couldn't do the decent thing- a rewrite. Please can we put that task on the to do list, and ask someone who if further away from the coding to do the task.ClemRutter (talk) 08:11, 26 July 2008 (UTC)

Actually, the documentation is not protected, but it's transcluded on the protected template page from Template:Coord/doc. Anyone can still edit and clarify the documentation. I suggest we organise something to keep all the various pages with instructions for coordinate use in sync and not just the template documentation. Or if it's possible to make the documentation better than it has ever been with any coordinate template, change all those other instructions to link to the template page instead. --Para (talk) 11:36, 30 July 2008 (UTC)

Photos with GPS in the metadata

Question about a number of photos I've recently been uploading. All of them are tagged with GPS from my camera, yet none seem to upload with the coordinates. The metadata seems to be there (the page lists the satellites, altitude, etc) but no specific coordinates. Is there any automatic way to get the coordinates to appear? here's a sample: http://en.wikipedia.org/Image:Chappaquiddick_bridge.jpg If not, are there ways of us entering the data by hand? Arwcheek (talk) 22:44, 25 July 2008 (UTC)

Please refer to commons:Commons:Geocoding (might have to check the archive). I operate a bot that extrats EXIF geodata and inserts the propper geocoding templates. Oh, yeah, and don't upload PD images to en.wp, use commons. --Dschwen 22:50, 25 July 2008 (UTC)

Arwcheek, I believe images uploaded to/via Commons:Upload (instead of directly the English Misplaced Pages) are processed by Commons:User:DschwenBot once or twice a day? Commons:Special:Contributions/DschwenBot indicates it last added Locations on July 15th. See Commons:Bots/Requests for flags/DschwenBot, the source code for what it does is Commons:User:DschwenBot/source. On Commons, it would create something "similar" to: {{Location|41|22|24.0|N|70|27|13.3|W|alt:10_source:exif_heading:?}} (I did not read your image's extended EXIF GPS tags, Misplaced Pages does not display the GPS coordinates, those coordinates are from Chappaquiddick incident) I am not sure if "alt:" is in the same units (feet or meters)? I believe Meters is the preferred unit when a unit is not specified, and "heading:?" is a "hint" that you need to manually replace the '?' question mark with a W:Boxing the compass heading (i.e. 0 to 360 or N,S,E,W NE,SE,SW,NW NNE,ENE,ESE,SSE,SSW,WSW,WNW,NNW NbE,NEbN,NEbE,EbN,EbS,SEbE,SEbS,SbE,SbW,SWbS,SWbW,WbS,WbN,NWbW,NWbN,NbW).

"type:" can be specified, it defaults to "landmark" (on Commons), "scale:" can be specified, it defaults to 5000 (on Commons). mapsources.php has the defined types: country,state,adm1st,adm2nd,city,mountain,isle,airport,landmark and their corresponding default scales (see Misplaced Pages talk:WikiProject Geographical coordinates#Scaling above).

Commons is a site where images or some other "common" files can be shared between the various Wikis. An image uploaded to Commons is retrieved as if it were uploaded directly to the English Misplaced Pages, but can also be retrieved by the other language Wikis and sites as well. The "disadvantage" to Commons is that anything uploaded there needs to be Public Domain or some variation of Creative Commons licensing with few exceptions, i.e. minimal "Copyrighted-Fair Use" content, whereas some "Fair Use" content can be uploaded to the English Misplaced Pages when certain guidelines are followed.

Arwcheek, I believe images uploaded (directly) to the English Misplaced Pages (instead of Commons) are not processed by DschwenBot. So your options are either to move your images from the English Misplaced Pages to Commons, or to manually geocode them: Chappaquiddick incident has {{coor title dms|41|22|24.0|N|70|27|13.3|W|region:US-MA_type:landmark}}, if those coordinates are accurate, then {{Location|41|22|24.0|N|70|27|13.3|W|region:US-MA_type:landmark|display=inline,title}} would be an appropriate Commons geocoding. The Commons:Template:Location works similar to the Misplaced Pages En:Template:Coord which would be {{Coord|41|22|24.0|N|70|27|13.3|W|region:US-MA_type:landmark|display=title}} The Coord and Location templates are a functionality merging of the family of Coor templates (Coor d, Coor dm, Coor dms, Coor at d, Coor at dm, Coor at dms, Coor title d, Coor title dm, and Coor title dms) into one template.

Several "undocumented" and "unimplemented" optional parameters are appearing without the underlying source code (mapsources.php) and templates being updated to properly handle them. In particular: altitude "alt:" or elevation, several new "type:" parameters without "scale:" being properly defaulted or set, a few new "source:" parameters. I agree that these new "features" add value and should be implemented, but some proper process needs to be followed so that all the pieces get updated appropriately and do not break. I would like to see: 3-D coordinates (altitude/elevation), the new types seem reasonable, and I would like to see a standard list of defined sources: besides "GNIS" (like: "EXIF"; GPS with some optional indication of 2D, 3D, differential 2D, differential 3D, military/surveying "L1+L2" high-precision ...; manually plotted with Google Earth, Google maps; ... I do not disagree with the additions, just that an appropriate "process" is needed. LeheckaG (talk) 07:02, 26 July 2008 (UTC)

Does coord scale:N work?

I recently updated template {{Infobox Protected area}} to optionally accept a coords parameter instead of the 8 lat_degrees, lat_minutes, ... long_seconds, long_direction values. (Yes, it still accepts the 8 parameters for backward compatibility. If coords= is used, it trumps the old parameters.)

I was updating the documentation and decided to enhance the examples showing the full power of {{coord}} as many wikiproject members have asked for various aspects of its functionality provided by the infobox template. Part the motivation for the new infobox parameter is avoiding the need for an infobox parameter for every possible display/scale/name/region/world/etc. In adding scale:N, I noticed it has no effect on the generated URL. That is {{coord|45|12|34|N|123|45|56|W|type:landmark_region:US|scale:300000}} gives 45°12′34″N 123°45′56″W / 45.20944°N 123.76556°W / 45.20944; -123.76556 Coordinates: Extra unexpected parameters
while {{coord|45|12|34|N|123|45|56|W|type:landmark_region:US|scale:10000}} gives 45°12′34″N 123°45′56″W / 45.20944°N 123.76556°W / 45.20944; -123.76556 Coordinates: Extra unexpected parameters
. Same URLs, right? Am I doing something wrong? —EncMstr (talk) 06:55, 26 July 2008 (UTC)

Decimal coord and scale?

While writing the last section, I originally used decimal—rather than DMS—format, but got grief from {{coord}} with the addition of a scale parameter. That is {{coord|45.123|-123.123|type:landmark_region:US|scale:300000}} gives Coordinates: Unknown argument format
Removal of the scale parameter gives 45°07′23″N 123°07′23″W / 45.123°N 123.123°W / 45.123; -123.123. Huh? —EncMstr (talk) 06:55, 26 July 2008 (UTC)

Coordinate parameters versus Template parameters

Try: {{|Coord|45|12|34|N|123|45|56|W|region:US-OR_type:mountain_scale:300000|name=South Point (Mount Hebo)}} which produces: 45°12′34″N 123°45′56″W / 45.20944°N 123.76556°W / 45.20944; -123.76556 (South Point (Mount Hebo))

The '|' pipe or vertical bar character you placed before "scale:" ends the "Coordinate" parameters and begins the "Template" parameters. The later "Template" parameters are either: "display=" with "inline" "inline,title" or "title" choices and "format=" either "dec" or "dms".

Would people find it useful if I or someone else wrote up a Extended Backus–Naur Form or Augmented Backus–Naur Form summary of the template syntax? Like:

"{{" "Coord" '|' latitude-degrees ] '|' latitude-direction ] '|' longitude-degrees ] '|' longitude-direction ] "}}"

Where latitude-direction is either 'N' or 'S', longitude-direction is either 'E' or 'W', ...

The above is "unofficial" from my everyday usage of the template, if it would be useful, I can reverse-engineer {{Coord}} (I did not write it, I just use it a lot) and write-up a formal ABNF or EBNF for the template and post it on the documentation?

While not "formally" correct, a "Wiki-simplified" version of the above might look like:

{{Coord | latitude-degrees ] | latitude-direction ] | longitude-degrees ] | longitude-direction ] }}

"Takers", Comments, Preferences: for "Wiki-simplified", EBNF, ABNF, BNF, or some other form? LeheckaG (talk) 07:30, 26 July 2008 (UTC)

The most useful to me is 2 or 3 well-chosen examples. One basic, but useful. One using every feature properly and usefully. And maybe something in between. If that were the focus of the documentation, reading the rest wouldn't be necessary, except for the most esoteric or ambiguous cases. Even then, a little experimentation goes a long way. —EncMstr (talk) 07:36, 26 July 2008 (UTC)

I think I get it! My problem was that I was parsing type:landmark_region:US as one syntactic item—in my mind, a magic cookie saying that the coordinate is a "landmark region" in the US. I now see that the underscore is a delimiter! (I now see that fact in the documentation too!) That—you have to admit—goes against all previous experience. Underscores_are_syntactic_fluff_which_most_readers_regard_much_like_a_space_not_a_delimiter. In most programming contexts, they are allowed as part of identifiers. But I felt I had to delimit scale:. It was simply bad luck that {{coord}} ignores all parameters after number nine.

So the critical documentation issue is:

 {{coord | latitude | longitude | underscore_delimited_qualifiers |
           display=title,inline | name=name_to_use_if_not_the_pagename | format = dms or dec }}

where qualifiers include

type:{country|state|adm1st|adm2nd|city|mountain|isle|waterbody|landmark|forest|river|glacier|edu|pass}

scale:N

region:XX

globe:XXXX (if not earth)

source:xxxx (wickedly complicated)

Assuming I am now on track, that's the emphasis the documentation should have. (It doesn't help that the information is in divided into several places.) —EncMstr (talk) 16:09, 26 July 2008 (UTC)

• The Coordinate parameters (region:, scale:, type:, source:, ... separated by underscores) are "one" template parameter from the Coor and Coord templates point of view, they are passed on "as is" to GeoHack on the ToolServer as part of a URL, which then parses them into individual parameters (using the underscore to delimit them).
• The "name to use if not the pagename" is NOT accurate, if no "name=" is specified, then no "&title=" parameter is generated nor passed to GeoHack.

LeheckaG (talk) 16:56, 26 July 2008 (UTC)

Have a look at the first example at Template:Infobox Protected area#Examples. (Note that "display=title,inline" is shown in the formatted example text for cut-and-paste use, but is omitted in the active wikicode to not mess up the page from all the examples.)

The generated coord URL is http://stable.toolserver.org/geohack/geohack.php?pagename=Template:Infobox_Protected_area&params=37_50_0_N_119_30_0_W_type:landmark_region:US_scale:300000. The pagename parameter shows up on the GeoHack page as the title Template:Infobox Protected area. Compare that with the fourth (and last) example which uses a name parameter. That gives the URL http://stable.toolserver.org/geohack/geohack.php?pagename=Template:Infobox_Protected_area&params=51_56_10_N_112_57_41_W_type:landmark_region:CA_scale:100000&title=Dry+Island+Buffalo+Jump+Provincial+Park. It still has pagename, but added title which appears to override pagename on the GeoHack page. That's what I intended to convey above. The URLs on the GeoHack page incorporate the title for the point name. (Why doesn't it for Google, Yahoo, and a few other maps?) —EncMstr (talk) 17:24, 26 July 2008 (UTC)

Yes, "PAGENAME" and "title=" are two different parameters in the generated URL which Geohack can use. The current GeoHack Template implementation (see: Template:GeoTemplate and Template:GeoTemplate/doc) if a "title=" is not supplied, then uses "PAGENAME" for Title (this occurs on ToolServer in the GeoTemplate, and not on Wiki in the Coor or Coord templates). It is a "bug" in what the GeoHack template/ToolServer then does (sometimes passing it and sometimes not depending on which action/service is chosen). The {{GeoGroupTemplate}} "Map all coordinates" does label each Google Map point with their "name=" parameters. LeheckaG (talk) 17:57, 26 July 2008 (UTC)

I'm having trouble telling right from wrong in your answers. You say that name=name_to_use_if_not_the_pagename is wrong, but you just said that name= overrides pagename in the generated title. What's the distinction? —EncMstr (talk) 18:30, 26 July 2008 (UTC)

I am in the process of reverse engineering the GeoHack/ToolServer GeoTemplate to better answer your post. PAGENAME and title= are (2) distinct parameters in Template:GeoTemplate, the "quick" answer is that while "PAGENAME" might display in the "title" heading in the the top left portion of the page IF a title= parameter is not supplied; if title= is not supplied, the GeoTemplate does NOT actually replace "title=" with PAGENAME. So when a link is clicked on from the ToolServer.Org GeoHack page, it still uses the title= parameter (and NOT the PAGENAME) parameter - but all of that is dependent on the GeoTemplate code ... which I am going through...

The "quick" answer to the comment about (title=name) not being passed on to maps: they are for some (MapQuest, Microsoft Live, ...) and not for others (Google, Yahoo, ...) it is a matter of how GeoTemplate is coded. I will be working on a table indicating which links do and which do not. LeheckaG (talk) 18:44, 26 July 2008 (UTC)

I don't think name= really overrides, but that it is used for different things than the article name. In Arlington National Cemetery there are coordinates for the cemetery. Down in Arlington National Cemetery#External links is a {{GeoGroupTemplate}} which offers this Google Maps display of more coordinates in the article]. The name= parameter is used to label the coordinates, as the article name is not appropriate for all the coordinates. Some tools use the article name if name= is not provided, but the article name is used by some tools despite the name= usage (such as a map being labeled with the article name even if all coordinates have differing name= contents). -- SEWilco (talk) 14:22, 27 July 2008 (UTC)

See the table I posted below, there are only (2) links on ToolServer/GeoHack (GeoTemplate) which actually use the article's PAGENAME:

• "All coordinates"
• OpenStreetMap

which is why if name= is not supplied, then the coordinates do not get labeled with a name on a map.

There are several which do pass on the name= parameter (which is passed on in the URL as title=),

but there are also notable ones like Google and Yahoo for which the parameter is not passed.

GeoTemplate can be updated to "fix" things better, since it is high-use/high-profile, I am not sure what the release control process is? LeheckaG (talk) 15:25, 27 July 2008 (UTC)

The pagename is always provided to GeoHack, and the services that use it may expect to find the source article with it. Some services use a name for the coordinates, possibly displaying it on the map. These are two different purposes. When the coordinates haven't been named explicitly, GeoHack assumes the coordinates are for the object of the article, and since it knows the name of the page, it fills the title with that information. All this is done to get a meaningful name for the coordinates.

The reason some services don't show a name is that they don't support displaying a name at all or they don't support some common characters in Misplaced Pages article names, and GeoHack doesn't yet have functionality for selective character replacement. This was discussed on Template talk:GeoTemplate#Named coordinates. Any fixes should probably be discussed on wiki before dumping suggestions on the developer(s?). --Para (talk) 12:07, 30 July 2008 (UTC)

If you view the Template:GeoTemplate source code, you can see that PAGENAME is only used by the (2) GeoHack selections I documented above, it is never actually copied to "title=", which is what the many of the GeoHack links are set-up to use. Given that many articles either have PAGENAMEs which might not be "best" displayed on a map or they contain more than one set of coordinates, it is probably best to always set "name=" to something which makes sense so that "title=" is always filled in. While some services have no provision for a name, for those which do, either "title=" could be used if they support it, or it can be copied to whatever format/parameter name that service uses. The issue is that it requires research to figure out what each service accepts and uses, which the GeoHack developers may not have had the resources to do. The services which use "PAGENAME" usually backlink to the Misplaced Pages page, and then extract information from that article (from instance Map All Coordinates extracting all article coordinates). LeheckaG (talk) 13:25, 30 July 2008 (UTC)

See Template:GeoTemplate/doc#Miscellaneous and GeoHack source code if you're in doubt: {pagename} is copied to {title} when no title is provided, so most services have no reason to use pagename specifically, unless indeed they support a more complex description with hyperlinks. Researching what all the services support and don't support doesn't need to be left for developers, since we're in an environment with lots of volunteers. Some guidance might be necessary though. --Para (talk) 13:47, 30 July 2008 (UTC)

I do not see {pagename} copied to {title} in Template:GeoTemplate, here are the only (2) {pagename} references which I see:

• This displays {pagename} after {title}, but does NOT copy {pagename} to {title}:

! id="title"                 | Title
| headers="title" colspan="3"| {title} <span  style="display:none{pagename};">
()
</span>

• This passes {pagename} and not {title} to OpenStreetMap via ToolServer:

Check Openstreetmap  of this area

Those are the only (2) references to {pagename} I see on Template:GeoTemplate. If you are aware of the place and source code link where it is copied, then I would like to see it (it may well, but I have not seen it). LeheckaG (talk) 14:37, 30 July 2008 (UTC)

GeoTemplate is not filled by MediaWiki, so there is very little the template itself can do. The tool that fills in the template is called GeoHack, and it's its source code you need to look at. In this case the relevant line is in mapsources.php, where the default value for the title is the pagename. --Para (talk) 21:41, 30 July 2008 (UTC)

I see {{Coord}} transcludes {{Coord/link}} transcludes {{Coor URL}} which loads geohack.php.

I am not sure if this is the "production" version; How does one tell which geohack and mapsources versions are?

https://fisheye.toolserver.org/browse/geohack/www/geohack.php?r=2 has:

13   	 include "geo_param.php" ;
14 	include "mapsources.php" ;
...
50   	 # Read template
51 	$pagename = "Template:GeoTemplate" ;
52 	#$pagename = get_request ( "altpage" , "Template:GeoTemplate" ) ;
53 	$page = @file_get_contents ( "http://{$lang}.wikipedia.org/$pagename" ) ;
...
103   	 # Build the page
104 	$md->thetext = $page ;
105 	$page = $md->build_output () ;

"build_output" calls a class/function in https://fisheye.toolserver.org/browse/geohack/www/mapsources.php?r=3#l287 (revised link from above - which is "production"?) which has:

287   	                 $r_pagename = get_request( 'pagename', '' ) ;
288 	                $r_pagename = str_replace ( '&' , "&" , $r_pagename ) ;
289 	                $r_pagename = str_replace ( '"' , """ , $r_pagename ) ;
290 	                $r_title = get_request( 'title', $r_pagename ) ;
291 	                $r_title = str_replace ( '&' , "&" , $r_title ) ;
292 	                $r_title = str_replace ( '"' , """ , $r_title ) ;

looking at what "get_request" does: http://phpldapadmin.sourceforge.net/function-ref/phpLDAPadmin/_lib---functions.php.html says:

get_request 
void get_request( $attr, , , )
Return the result of a form variable, with optional default
Parameters
   	$attr   	
   	$type   	
   	$die   	
   	$default  

• so geohack reads GeoTemplate, but then mapsources replaces title if it is blank.

If you click on the coordinates to the right of the Globe under the sub-section heading above: Misplaced Pages talk:WikiProject Geographical coordinates#Coordinate parameters versus Template parameters, the URL generated by {{Coord}} and {{Coord/link}} {{Coor URL}} has:

• http://stable.toolserver.org/geohack/geohack.php?pagename=Wikipedia_talk:WikiProject_Geographical_coordinates&params=45_12_34_N_123_45_56_W_region:US-OR_type:mountain_scale:300000&title=South+Point+%28Mount+Hebo%29

If you hover over "All Coordinates" after "Title South Point (Mount Hebo) in the Upper-Left corner, the generated URL is:

• http://maps.google.com/maps?q=http%3A//toolserver.org/~para/cgi-bin/kmlexport?project=en%26article%3DWikipedia_talk:WikiProject_Geographical_coordinates

Similarly for "Map Features" in "Check Openstreetmap Map Features of this area" (about 1/8th to 1/10 of the way down the page):

• http://toolserver.org/~kolossos/osm/osmhack.php?lat=45.209444&lon=-123.765556&name=Wikipedia_talk:WikiProject_Geographical_coordinates

If you hover over the "Map" "Satellite" or "Hybrid" after "MapQuest" under "Global Systems" in the Upper-Left corner, the generated URLs are:

• http://atlas.mapquest.com/maps/map.adp?searchtype=address&formtype=address&latlongtype=degrees&latdeg=45&latmin=12&latsec=34&longdeg=-123&longmin=45&longsec=56&zoom=5&title=South%20Point%20(Mount%20Hebo)
• http://atlas.mapquest.com/maps/map.adp?searchtype=address&formtype=address&latlongtype=degrees&latdeg=45&latmin=12&latsec=34&longdeg=-123&longmin=45&longsec=56&zoom=5&dtype=a&title=South%20Point%20(Mount%20Hebo)
• http://atlas.mapquest.com/maps/map.adp?searchtype=address&formtype=address&latlongtype=degrees&latdeg=45&latmin=12&latsec=34&longdeg=-123&longmin=45&longsec=56&zoom=5&dtype=h&title=South%20Point%20(Mount%20Hebo)

Similarly, if you hover over "Live Search Maps", "Ask.Com", "ACME Mapper", "GeaBios", "GPS Visualizer", ...

If I follow one of those links, I get "South Point (Mount Hebo)" and not "Wikipedia_talk:WikiProject Geographical coordinates" as the label.

I am not sure where the "disconnect" is between mapsources.php and {{GeoTemplate}}

When you click on the original coordinate example on this section Misplaced Pages talk:WikiProject Geographical coordinates#Does coord scale:N work?

http://stable.toolserver.org/geohack/geohack.php?pagename=Wikipedia_talk:WikiProject_Geographical_coordinates&params=45_12_34_N_123_45_56_W_type:landmark_region:US

Yes, since "title" is blank, mapsources.php does replace it with "pagename" in the links when you hover or click on the links.

So the general "issue" would be getting the various GeoTemplate links updated with "title" or whichever name they expect a label, name, title, ... on.

Meta:WikiMiniAtlas MediaWiki:Wikiminiatlas.js works by reading through elements of the article's generated Geo microformat. The "glue" which enables the Wikiminiatlas.js is apparently either in Common.js or Misplaced Pages:Skin, but I have not found the exact links. LeheckaG (talk) 11:11, 31 July 2008 (UTC)

Yes, everything is working as intended: if coordinates have been named, the name is preferred over the name of their container (the article) when labeling the point. The issue as you found has all along been to find which external services don't support certain characters, come up with variables to be used in the links on GeoTemplate to avoid those characters, and implement their substitution in GeoHack. Template talk:GeoTemplate#Named coordinates is the latest I remember about this. --Para (talk) 12:44, 31 July 2008 (UTC)

GeoTemplate

ToolServer / GeoHack

The above is from the source code, I did not actually test each one. LeheckaG (talk) 18:57, 26 July 2008 (UTC)

How Coor(d) templates work

Reverse-engineering {{Coord}}, it looks at/for:

• Template parameter named "display"
• 4th positional parameter is empty for "dec"
• 4th and 8th positional parameters for N E,N W,S E,S W for "dms"
• 3rd and 6th positional parameters for N E,N W,S E,S W for "dm"
• 2nd and 4th positional parameters for N E,N W,S E,S W for "d"
• "format" and "name" are the other (2) named Template parameters (besides "display").

it transcludes Coord/display and Coord/input template families (which transclude Coord/link ...).

There are inconsistencies in the Coor templates:

• Difference(s) between CSS class=geolinks and CSS id=coordinates?
• Only {{Coor d}}, {{Coor dm}}, and {{Coor dms}} accept a "name=" template parameter (which passes on to GeoHack as "&title=name") and
• {{Coor dms}} accepts a "title" template parameter which "triggers" the "class=geolink".

Coord's documentation says is outputs the appropriate Geo Microformats, See {{Coord/link}} (CSS) class= geo-default, geo-nondefault, geo-dms, latitude, longitude, geo-multi-punct, vcard, geo-dec geo, fn org. I do not know what Coor family's CSS "id=coordinates" does compared to {{Coord/link}} Geo Microformats? LeheckaG (talk) 09:22, 26 July 2008 (UTC)

TFD Coord named

I nominated {{Coord named}} for deletion Misplaced Pages:Templates_for_deletion/Log/2008_July_24#Template:Coord_named. It is only a redirect to {{Hcard-geo}} as a result of Hcard-geo being renamed to "Coord named" and then being renamed back again, and it is not used by other Wiki articles or templates Special:WhatLinksHere/Template:Coord_named, for details see discussion under the TFD log I cited. Please Vote as appropriate, either: Delete or Keep. LeheckaG (talk) 10:19, 26 July 2008 (UTC)

I'd have nominated Template:Hcard-geo directly. --User:Docu

Polygon on maps - urgent.

I think Misplaced Pages should seriously consider adding polygon capabilities like WikiMapia. There are many contributions Misplaced Pages is losing to Wikimapia due to Misplaced Pages's very poor support for polygons and overlays. Just a thought.

I am particularly troubled by WikiMapia's very limited licensing. -Regards.

Response

I took another look at Wikimapia, I had previously looked at it briefly. The majority of Wikimapia "polygons" appear to be rectangles derived from Misplaced Pages's type: and scale: parameters. Wikimapia can create more sophisticated polygons based on up to 150 corners or turning points. Wikimapia appears to have nowhere near the quantity of coordinates (articles) which Misplaced Pages has on Google Earth and Google Maps.

Personally, the first (2) steps are to:

• have Misplaced Pages output a 3-D coordinate (i.e. elevation or altitude) and
• then a way of doing simple vectors "pair of coordinates connected by a thin line".

There already is a way (GeoGroupTemplate "Map all coordinates") to do a list of coordinates as individual plotted "pushpins" on Google Maps, so making the jump combining a vector (pair of coordinates + line) and list of coordinates to create a polygon would not be a big jump (AFTER a way of doing a vector is implemented). LeheckaG (talk) 19:34, 26 July 2008 (UTC)

Couple of things. You are right that Wikimapia is lagging behind, but don't expect that to last too long. I'm afraid I can't contribute technically. But I can only urge you to consider Wikimapias dead simple interface and the ease of use that is superior in everyday to Wikimapia in terms of mapping capability. They will catch up quickly.

Look at this link: . Look how easy it is to instantly understand what each neighborhood is, and where it is in relation to all other plot points. To get the same concept in Misplaced Pages via text and singular plot points is simple impossible. Wikimapia has made modifying map points as easy as editing text on Misplaced Pages. This simplicity will soon lead to a a parity in number of waypoints, and eventually, WikiMapia gaining the lead.

Do not underestimate them.

Venture capitalists know this as well. I recall the Russian programmers behind WikiMapia were seeking VC funding not too long ago. I'm pretty sure they already have it now.

Try editing Wikimapia and you will see why.

I think Misplaced Pages should embed an small Google map with a square overlay which can be as quickly and as easily edited as Wikimapia. I think Misplaced Pages is loosing its chance at a massive growth market by not pushing a competitor to Wikimapia no matter how beta or buggy... Just look at the history of web mapping: Google maps pushed a product while MSFT, Yahoo, and even once dominant MapQuest lagged and are now nothing. MapWho? -Regards.

Wikimapia and Misplaced Pages have different funding models, licensing/open source-public domain, and as well as source/verifiability criteria.

• Misplaced Pages is non-commercial, open source, public domain (supported by donations/non-commercial sponsorship) whereas I am not sure what Wikimapia's long-term intentions are?
• Misplaced Pages requires citations and references for information to be generally verifiable. Whereas Wikimapia can be more easily "polluted by bad information".

Wikimapia is working by embedding Google Maps in a frame and just handling the coordinates/rectangles/polygons on their site as an overlay over the content provided by Google Maps. Not likely something Misplaced Pages would do because of several licensing/policy issues, but I cannot speak with authority on that.

Misplaced Pages does not really support embedding "frames", especially not embedding outside (commercial) sites (like Google). Misplaced Pages would more likely use a similar "non-competing"/non-commercial source, like GIS/mapping data and imagery available from free/Public Domain sources: the U.S. federal government or non-commercial sites with philosophies and policies similar to Misplaced Pages's (compared to embedding Google Maps - which is a "commercial" site).

That said, Misplaced Pages uses Cascading Style Sheet (CSS) ids and classes which enables Geoboxes and Infoboxes to work. Geoboxes and Infoboxes can contain one or more images or maps (depending on the particular one), but those are "static" image files uploaded to Wiki "Commons". It is technically possible to overlay such with other content using CSS (which is how the "Location map" or "Pushpin map" works). There might be something more sophisticated, but the available templates I have seen so far overlay a larger map with one or more "marks". LeheckaG (talk) 21:22, 26 July 2008 (UTC)

Point taken. Let me first point out that Wikimapia is far from polluted with information. Its information is easily 2 to 3 times more potent and higher volume than Misplaced Pages. No contest. Misplaced Pages's source requirements are also a sort of null to my point:

My point is that whatever you are doing now, it is obviously insufficient in comparison to Wikimapia. The different licensing is not an excuse or explanation for Misplaced Pages's lag: but the very reason why Misplaced Pages must do better that Wikimapia. All contributions to Wikimapia are explicitly. Explicitly. Licensed away to Wikimapia - likely for commercial use.

"Wikimapia is working by embedding Google Maps in a frame and just handling the coordinates/rectangles/polygons on their site as an overlay over the content provided by Google Maps. Not likely something Misplaced Pages would do because of several licensing/policy issues" This is huge.

Wikimapia has a license or agreement with Google to make money off of Google. I am more than positive that Google with allow Misplaced Pages usage of it's mapping for GFDL & Educational purposes. There is no doubt in my mind. Period. I'll go do the legal foot work myself on this if the devs here are willing to smash something together that resembles what Wikimapia can do, including overcoming whatever technical hurdles in the way. Google uses Misplaced Pages on G Maps and G Earth. There is absolutely no reason short of insanity that they would not extend Misplaced Pages the same courtesy. -Regards —Preceding unsigned comment added by 72.93.213.196 (talk) 21:54, 26 July 2008 (UTC)

Template

I found the following template while looking through articles. {{Geofact-inline}} Does this mean that coordinates need citations? Spencer 15:17, 28 July 2008 (UTC)

I have been using {{Cite gnis}} with "ref" tags whenever I am citing/using coordinates from the United States Geological Survey, it is nice because it provides a "one-click link" to the exact reference source page in contrast to {{GR}} (which I HATE) since it dumps you off at a "search engine site" and results in "exactly where did you find that on Census.Gov or USGS.Gov"? If or when something needs to be "explained", like "manually plotted in Google Earth", or "mid-point between two published coordinates", ... I add a "Notes" section before the "References" section and put a {{Cnote}} there explaining just that (whatever the explanation is and citing references), then I place a {{Cref}} in the article to refer to the {{Cnote}}. LeheckaG (talk) 15:27, 28 July 2008 (UTC)

A "good" reason for doing the citation or reference (even when using GNIS) is because sometimes there may be more than one set of coordinates for a "named feature", mostly to do with "Populated Place"s. In both Alaska and Ohio, I have encountered multiple "feature classes" for the same names:

• "Civil" (for an incorporated municipality - usually the center point of the boundaries)
• "Census" (U.S. Census Bureau's center point of their census tract boundary - which often does not match civil/geographic/political ones)
• "Locale" (either a general or historical area known by that name - sometimes the "Populated Place" moves)
• "Populated Place" (where the U.S.G.S. plots "civilization" on a map - meaning buildings, industry, people, residences, ... usually where the people actually are)

If I am trying to say where a "city" is, I try to use the "Civil" coordinates unless they really do not "make sense" when plotted on a map. For instance, in the "water" or on a "mountain", ... ONLY for a section where I am talking about U.S. Census figures would I usually use a "Census" coordinate. For the majority of other uses, "Populated Place" is where the people (usually) are and makes the most sense. There are counter-examples, when I run across one, then I try to use a Cnote and Cref pair explaining which "published" coordinate and why. In a Geobox or Infobox with a "GNIS" field, that is the "reference citation" unless either a coordinate or altitude/elevation deviates from a published one for some reason. Likewise in a table. But if there is no link or reference, and some explanations are needed, then you should have a reference. Coordinates needs to be reasonably verifiable as to their source, {{Cite gnis}} makes at least the GNIS ones relatively easy to verify. As to coordinate accuracy or number of digits, many are either under or over specified, for larger states Degrees are usually close enough, for many counties minutes are close enough, for 99% of the smaller features seconds are more than enough unless you are documenting a surveying benchmark monument. LeheckaG (talk) 15:47, 28 July 2008 (UTC)

{{Geofact-inline}} was recently created and has no documentation. Ask the creator what its purpose is and that it should be documented. -- SEWilco (talk) 23:29, 28 July 2008 (UTC)

Visualization of Misplaced Pages articles with Google Maps

Sfan00 IMG proposes deleting:

• www.geonames.org (See "discussion) over 800,000 Misplaced Pages articles in 230 languages on Google maps. The placemarks include short descriptions of the displayed items, extracted from the Misplaced Pages articles. Webservices for full text search and reverse geocoding of wikipedia articles.

Citing: (Remove Geonames ambiguous (C) (see - http://wiki.openstreetmap.org/index.php/Geonames - Misplaced Pages needs to review it's relationship with this site)

I reverted the edit so that it can be discussed before changes are made to the WikiProject page. The concerns raised are:

• Traceability/Verifiability of Data
• Copyrights/Licensing (of data and imagery)

Background information:

• GeoNames
• GeoNames - DataSources
• GeoNames - Misplaced Pages
• OpenStreetMap - GeoNames

It is in the last link above that the concerns are raised. I do not see an issue with presenting GeoNames are a "non-authoritative/secondary source" or with offering it as an external link or reference (provided that it is not "used out of that context" as an "authoritative/primary source".)

GeoNames is an important "one-stop" link to locate the authoritative/primary sources, and I agree that appropriate guidance is needed so that contributors do not use it as an authoritative/primary source. LeheckaG (talk) 15:22, 29 July 2008 (UTC)

Sfan00 proposes deleting what from where? You've provided links to external sites; what Misplaced Pages info might be modified? I don't see any need to delete mention of GeoNames, but I also don't see that it is necessarily notable enough to mention. It might have GFDL violations (the http://www.geonames.org/wikipedia.html link suggests there is Misplaced Pages text presented but I didn't find some). The coordinates themselves are not copyrightable, but no sources are provided for individual coordinates so it is hard to judge the reliability of their coordinates. I didn't see GeoNames providing any images other than icons and legends, and nobody has mentioned anyone trying to copy those icons here. The imagery from Google Maps is probably being used following the Google Maps API license, and no specific violation has been mentioned here. So what's the Misplaced Pages issue involving GeoNames? -- SEWilco (talk) 04:14, 1 August 2008 (UTC)

I had noticed that Sfan 00 had deleted GeoNames from Misplaced Pages:WikiProject Geographical coordinates, so I started this discussion and reverted the change:

• 2008-07-29T15:24:32 LeheckaG (Talk | contribs) (31,693 bytes) (Undid revision 228594318 by Sfan00 IMG (talk) Reverted - Added new section to WP discussion page) (undo)
• 2008-07-29T12:57:40 Sfan00 IMG (Talk | contribs) (31,386 bytes) (Remove Geonames ambiguous (C) (see - http://wiki.openstreetmap.org/index.php/Geonames - Misplaced Pages needs to review it's relationship with this site) (undo)

My personal belief is just that some guidance is needed ... i.e. that GeoNames is a secondary source and not an authoritative/primary source. Secondarily whatever copyright/licensing concerns there are, if they are found to have some basis. LeheckaG (talk) 05:11, 1 August 2008 (UTC)

The external comments don't seem very relavant to Misplaced Pages. I don't think coordinates themselves are relevant to copyright issues, being similar to addresses and phone numbers. But the GeoNames pile of unsourced coordinates is a limited benefit to us. Its primary advantage is a timesaver for an editor in finding that a coordinate has been defined, but then one has to do a normal search to find a source (the only help from GeoNames might be the exact name to search for). -- SEWilco (talk) 19:31, 1 August 2008 (UTC)

Geocoding Wikipedians?

What about adding coordinates to your user page so that people can see where you are (e.g. for taking photos and other locality specific tasks), and where other Wikipedians around them are too? It seems like a neat idea, though I'm thinking there might be concerns, e.g. concerns about younger Wikipedians adding their address and pedophiles stalking them, or something like that. I suppose it is also a bit different from geocoding articles and media files. Richard001 (talk) 08:25, 2 August 2008 (UTC)

One can if one chooses to, I suppose one can either give less precise coordinates (i.e. "rounding") of "fudge" them to be a "comfortable" distance away, like giving those of a nearby very public establishment (airport, library, restaurant, bus or train station, store, ...) "nearby". For very rough estimates, one degree is approximately 60 miles (97 km), one minute is 1 mile (1.6 km), and one second is about 100 feet (30 m). For the "real" numbers: one minute of latitude is 1 nautical mile about 6,076.1 feet (1,852.0 m). So you could fudge coordinates so that someone knows about where you are but not exactly.

• To do so, one would put:

{{Coord |latitude_degrees |latitude_minutes |latitude_seconds |latitude_direction |longitude_degrees |longitude_minutes |longitude_seconds |longitude_direction
|region:XX-YY_type:landmark |display=inline,title |format=dms |name=map_marker_label}}

on one's User: page, where:

• I formatted it with the '|' pipe/vertical bar next to the parameter_name which it goes with for readability, actually all of the spaces can be omitted.
• the latitude_ and longitude_ fields would be the appropriate values, seconds can be omitted, or minutes can be omitted along with seconds
• latitude_ or longitude_ 's last field can be a decimal value.
• XX in region specifies an ISO 3166 2-character country code ("US" for United States) and YY an ISO 3166-2 2-character region within (i.e. U.S. state)
• type can be one of the other types above (depending on what makes sense based on the coordinates you supply)
• display defaults to "inline", "title" causes the coordinates to be display in the Wiki title bar (top right corner), inline,title does both
• format can be dec or dms (abbreviations for decimal and degrees_minutes_seconds) and specifies how to display the coordinates
• name supplies a map_marker_label/title for some map services (so that the "pushpin" marker can be labeled)

Mapping Wikipedians? Sounds like a good idea (so long as we a have enough fudge to avoid address location); but the dots created by this could allow the production of some fascinating maps of Wiki activity. Sarah777 (talk) 10:30, 2 August 2008 (UTC)

Note the guideline Misplaced Pages:User categories and the existing Category:Wikipedians by location. I also point out there already are categories by location for requested images and maps which are using categorization and coordinate mapping. -- SEWilco (talk) 23:17, 5 August 2008 (UTC)

I suggest that it would be useful to encourage users to specify approximate coordinate of interest (Misplaced Pages focus might not even be a home or work area), a "Wikipedians by" category name, and a radius of interest around the coordinate. This would allow indication of approximate locations of interest, even if not all the information is being used well yet. Eventually this could help people find requested items in their "zone" or point out to them if a new location category has been created which more closely matches their zone (maybe they used the coordinate for Springfield, NY, and someone has now defined Category "Wikipedians in Springfield, New York"). -- SEWilco (talk) 23:17, 5 August 2008 (UTC)

I think this idea is great. I would allow us to create a World map displaying the concentration of wikipedians similar to this. Eklipse (talk) 15:54, 6 August 2008 (UTC)

Geobox

Most geoboxes include coordinates.

• Is there a way to have them displayed in the upper right corner of the articles as {{coor title d}} or {{coord|display=title}} would do?
• If yes, should this option be used or should would generally still use the normal coordinates templates?

-- User:Docu

With Geoboxes and Infoboxes, it depends whether they will accept a Coor(d) template or whether they have separate lat and long fields and "build" up the coordinates. Where they accept a template, {{Coord}} can be used with the "display=title" or "display=inline,title" template parameter, or the "Coor title" or "Coor at" family of templates to display the coordinates in the article's title bar. There are a few Geoboxes and Infoboxes where they accept coordinates, but there is no way to force them into the title bar (from the separate lat and long fields); when that happens, the options are either to put the coordinates in a "free-form text" field in the Geo/Infobox or to put them elsewhere in the article with the title parameters. If they were to display by default, their needs to be a way to "turn it off" in cases where there are more than one set of coordinates or where they do not want to be displayed for some other reason. LeheckaG (talk) 14:20, 2 August 2008 (UTC)

Infoboxes with "coordinates = {{coord}}" are quite straight forward (e.g. Template:Infobox Airport) and infoboxes providing specific fields for coordinates do use them several times.

Geoboxes using Template:Geobox coor, e.g. Template:Infobox Settlement, don't seem to offer a possibility to put the coordinates to use. Regrettable.

Places using Infobox Settlement have the coordinates displayed four times and specified three or more times, e.g. from Cambridge, Massachusetts (rev. 229231575, August 1, 2008):

1. In the infobox as "Coordinates: 42°22′25″N 71°06′38″W" through Infobox Settlement
2. In article title as "Coordinates: 42°22′25″N 71°06′38″W " through {{Geolinks-US-cityscale|42.373611|-71.110556}}
3. In the external links section as "Cambridge, Massachusetts is at coordinates 42°22′25″N 71°06′38″W" through {{Geolinks-US-cityscale|42.373611|-71.110556}}
4. In the geography section as "Cambridge is located at 42°22′25″N 71°6′38″W / 42.37361°N 71.11056°W / 42.37361; -71.11056.Template:GR" through {{coor dms|42|22|25|N|71|6|38|W|type:city}}

If we adapt Infobox Settlement or the link in the geography section to display the coordinates also in the article title, we could reduce the number of times the coordinates are specified by at least one. -- User:Docu

In both Geobox|Settlement and {{Infobox Settlement}} there appear to be several poorly documented or undocumented coordinate-related fields. Not sure if it would work:

• Geobox several _coordinates_ fields are passed to {{Geobox2 coor}} as positional parameters, if supplied - the 4th or 3rd positional parameter is the "title=" parameter, if one of them contained a named parameter instead? not sure how it would behave, It transcludes {{Coord}}. Likewise,
• Infobox Settlement transcludes {{Geobox coor}} and accepts an undocumented coordinates_type field (the coordinate parameters as opposed to the template parameters), title= is a named parameter, and it transcludes {{Coord}}.

So I am guessing it might be possible to do something non-standard/undocumented with the current template codes:

• Geobox=>Geobox2 coor=>Coord or
• Infobox Settlement=>Geobox coor=>Coord

but might "break" with subsequent template changes unless it is documented. A better way would be to put in a request for a change to the templates, but not sure how many hoops are involved in that process? LeheckaG (talk) 19:00, 3 August 2008 (UTC)

Template:Coordinate

Following the discussion above (WT:GEO#Coor3d), I imported de:Template:Coordinate. I'd be glad if you could help me test it. -- User:Docu

Lakes (2)

Since I posted WT:GEO#Lakes_needing_coordinates above, the number of articles in Category:Misplaced Pages infobox lake articles without coordinates, has remained stable (1047 on August 1, 2008, compared to 1200-150=1050 on May 20).

As the number of articles with {{Infobox lake}} has increased by 300 in the meantime, the number of lakes with coordinates has increased as well. Thank you to all contributors! -- User:Docu

(Subsequent to your post) I updated Goose Lake (Anchorage, Alaska) and Walker Lake (Northwest Arctic, Alaska) from USGS GNIS information (coordinates, elevation, whatever other details they had). Your list is rather huge, I am willing to update Alaska lakes, possibly some British Columbia, Washington state, Yukon, Ohio, Massachusetts, New Hampshire, Connecticut. Is there any way you can break up your huge list into smaller regional pieces (which people might take more of a personal interest in)? LeheckaG (talk) 13:00, 3 August 2008 (UTC)

Personally, I use catscan for this. You may want to try the following links: Alaska (just 5 left), British Columbia (32), Washington (4), Ohio (6), etc. Thank you for your help. -- User:Docu

I did the "5" Alaska ones, including renaming Miles and Walker to disambiguate them from others. "5" because Togiak is really (4) separate lakes: Togiak Lake, Little Togiak Lake, Upper Togiak Lake and West Togiak Lake - I updated them all as different sections on (1) Togiak Lake article page. I also updated the List of lakes of Alaska, Miles Lake and Walker Lake disambiguation pages. I have a few things to work on for other projects and then I will do either the Ohio or Washington state ones. LeheckaG (talk) 18:18, 3 August 2008 (UTC)

I updated the (4) Washington ones: Chopaka Lake, Lake Marcel, Potholes Reservoir, and Beaver Lake (King County, Washington) including disambiguating related articles. LeheckaG (talk) 09:22, 7 August 2008 (UTC)

kmlexport updated to use live category data

I thought how it would be much more rewarding to work through a category if you could see the results of your work growing somewhere. The "map of all coordinates" links on category pages work through dumps, so having to wait months for the visualization doesn't make it a very good incentive. So I modified the kmlexport tool a bit to show live data instead. The old one is still available as kmlexport-old for comparison. Please test with some categories and report any problems here. --Para (talk) 20:38, 3 August 2008 (UTC)

It's great! It works. It displays coordinates added 10 months, coordinates that never had shown up before.

-- User:Docu

Possible bug, see Category:Bays of Alaska, "Map of all coordinates" produces a "Three Saints Bay, Alaska" apparently plotted at Latitude 0N, Longitude 0W. I updated the Three Saints Bay, Alaska article's coordinates from USGS GNIS - (2) sets: Infobox and inline text, and still received the same result. So I removed the 2nd. set of coordinates from the inline text, and still received the same result.

Guessing that it is a "bug" between the {{GeoGroupTemplate}} and {{Infobox nrhp}} code? Where {{GeoGroupTemplate}} is extracting something generated by {{Infobox nrhp}} which "appears" to be coordinates, but are really not? I noticed similar odd behavior on a few other Alaska geographic categories (just guessing that the commonality is Infobox nrhp?).

I tried refreshing the page as well as "resubmitting the toolserver link" on the Google Maps' page (in the past, I have noticed where they do not always update on their own and sometimes take one of those (2) refreshes to actually update), still same results.

Another example (of the Latitude 0 plot) was in one of the Aleutians categories? I will see if I can locate it...going to take some digging. I am fixing some bad Category:Aleutian Islands coordinates: "Toporkov" island coordinates in the Bering Island article which were also "off the map" ... LeheckaG (talk) 12:03, 4 August 2008 (UTC)

Category:Bays of Alaska "Map of all coordinates" did finally update (guessing a replication lag between the English Misplaced Pages and Toolserver? As to the source of the other issue, possibilities: having multiple coordinates, (DM) coordinates (missing seconds), some Geobox/Infobox related issue. I am fixing some more of the "off of the map" coordinates and I will post more observations as I encounter them. LeheckaG (talk) 13:01, 4 August 2008 (UTC)

So far, it appears that they take a while from article coordinates being updated to a Category:, "Map of all coordinates" actually changing (within an hour, maybe a couple versus updating in "minutes" - at least with whatever replication delays are occuring as I have been updating.) So far, there seems to usually be one to three bad ("off the map") article coordinates in each category (at least of the Alaska categories I am going through). LeheckaG (talk) 15:28, 4 August 2008 (UTC)

It seems the mentioned outlier coordinates have been fixed already. Here's some possible reasons for lag, in descending order of likelihood:

1. Google caches the results to the requests it makes from Google Maps for a minute or so, and doesn't tell the client if it's showing cached results. Google also seems to restart the freshness counter of a cached result every time a client makes a request for the same result, ie. a case of a watched pot not boiling.
2. Replication of the English Misplaced Pages database on the toolserver may be lagged at times, though lately it has been only a couple of seconds. See http://toolserver.org/~bryan/stats/replag/ for graphs (en belongs to s1).
3. When Google doesn't get a response from the data source (here the toolserver, which has its apache clogged sometimes) within a couple of seconds and they have a previously cached result for the same URL, Google Maps shows the cached result without any additional messages to the client. If their request times out and they don't have a cached result, the client is shown a "file not found" message.

If in doubt, add some dummy parameters to the URL to make it different, or access the kml directly (show, export). As of writing this, someone's programs are making the toolserver unresponsive and we have a case 3. --Para (talk) 21:17, 4 August 2008 (UTC)

On Category talk:Bays of Alaska someone (else) is debating that {{GeoGroupTemplate}} should not be on a category. Originally, I was (mentally) debating with myself whether or not {{GeoGroupTemplate}} would be useful on a category. Subsequently, I have found it useful on the Alaska-related Categories.

For "list" articles (some/many of which do not contain coordinates), might there be a way to provide a "Map of all coordinates" link which points to a Category to retrieve the coordinates? i.e. Currently, {{GeoGroupTemplate}} relies on FULLPAGENAMEE, NAMESPACE, PAGENAMEE and SERVER to determine its behavior; Could {{GeoGroupTemplate}} be updated accept any named or positional parameters to point it to a different "starting point" (i.e. a Category, or in a "weird case" an alternative article or list to start from)? If so, the "infobox" should probably "echo" from where it is starting. (i.e. before a user clicks on it) LeheckaG (talk) 06:33, 5 August 2008 (UTC)

It would be technically possible to modify the template and allow a starting point that way, yes. GeoGroupTemplate is however an external link template and not just a navigation template of Misplaced Pages articles. Navigation templates in articles are separate from categories even if they share the same content; one doesn't replace the other. The same goes for list articles vs categories. Many article groups don't have navigation templates for the articles in its categories, and many categories don't have their contents in list articles. Should they? If there was an active project to mirror category contents in articles, then perhaps the starting point option could be used and the templates removed from categories, but categories are defined in ways more diverse than most articles have space for.

In GeoGroupTemplate's deletion nomination a year ago I argued that as an external link template for a single external service, it shouldn't be used in articles when the service can be chosen in the map service list among all the other services. I still think so, but back then it didn't have the category functionality yet and so that part wasn't discussed. I don't think anyone disagrees that it's useful, but in the category case I can't see any way to replace its uses in all categories. --Para (talk) 11:25, 5 August 2008 (UTC)

I put in a request for a couple of optional parameters:

• article= (if specified, to replace the default of FULLPAGENAMEE), and
• namespace= (to deal with the "odd" case where article/pagenames are extracted by have the "wrong" namespace

for instance Category:Misplaced Pages request ... which contain "Talk:" pages and the corresponding articles in the normal article namespace actually have the coordinates, See:

• Template talk:GeoGroupTemplate#Requested optional parameters

LeheckaG (talk) 15:13, 6 August 2008 (UTC)

In my enthusiasm for fresh data, I forgot to test what I think was the original use case for mapping categories: the requested photos categories. Sorry about that, it's fixed now. I'll look into adding a namespace parameter later if people are going to start putting coordinates on their user pages. --Para (talk) 18:54, 6 August 2008 (UTC)

I tested it on the requested photos Category which had been pointed out to me and after several refreshes and retries it did work. So how does one now display a map of coordinates when they actually are on a category or namespace of talk pages and not on the corresponding articles? Which is why I recommended a namespace= parameter instead of always stripping off Talk: or other namespace:, so that namespaces can be selected or substituted rather than always stripped off. LeheckaG (talk) 19:29, 6 August 2008 (UTC)

Are there cases where coordinates should be put on category or talk pages instead of or in addition to articles? Browsing through whatlinkshere for the coordinate templates shows that coordinates are scattered in lots of different namespaces, but I can't think of any meaningful use for mapping them. --Para (talk) 23:35, 6 August 2008 (UTC)

Your whatlinks here query of the coordinates templates showing that coordinates are in different namespaces demonstrates why a namespace= parameter would be useful. There may be other ways of achieving similar results, but questions like:

• which Talk pages are discussing coordinates? and how to determine where those coordinates are? (the map tool provides a visual way to do so), wherease -
• In the Category: request ... case the "opposite" is desired where one wants to use a Category first, then switch namespaces on the targets. Providing optional namespace= and article= parameters generalizes the GeoGroupTemplate-KML export tool so that any potential combination of uses foreseen or unforeseen can be accomplished. For instance,
• the discussion above about Users placing geographic coordinates on their User or Talk pages ... then the question how to map them? With either users pages or their talk pages in some category, a namespace= parameter allows a cross-namespace map query to be performed. For instance,
• suppose WikiProject members have a WikiProject template on their User pages and one want to query whether a Wikiproject's members' User talk pages discuss coordinates on the User talk pages and where those coordinates are on a map?

Similarly, an article= parameter allows a more appropriate "target" to be chosen, for instance, the example previously cited - while most articles containing a Geo/Info-box contain coordinates, not all list of ... articles containing them do, whereas a category containing them would. So placing a GeoGroupTemplate on a list of ... article page (where that page does not contain coordinates) and providing for an article= parameter would give a GeoGroupTemplate on a list of ... article page the ability to point to the corresponding Category: to actually retrieve coordinates.

I have not throughly investigated, but I assume GeoGroupTemplate on a Category only processes pages directly on the Category and not Subcategories? I am not sure about the technical feasibility or value of a "depth=" parameter? Whether KML export could do a "tree walk" to a depth of "depth=" ? If so, the primary technical coding decision would be whether to use a depth of -1 or a depth of 0 to mean "do all", or whether to use a depth of 0 or a depth of to mean just do the pages which are directly on the category and not sub-categories. Then the next question would be how many subcategory levels deep to allow? or what is the practical limit to how many subcategories or pages can be queried for coordinates?

I had run across MW:Extension:Gis which apparently was a different attempt to enable Wiki for GIS functionality. LeheckaG (talk) 02:25, 7 August 2008 (UTC)

OOPS! Post I just moved was meant for the section above (about updating coords for User:Docu and WP:Lakes, who requested coord assistance). LeheckaG (talk) 20:09, 7 August 2008 (UTC)

Those cases are a bit far fetched in my opinion and sites like the Keyhole Community seem better suited for random discussion about non-notable locations.

The kmlexport tool doesn't include subcategories because Google Maps would time out long before the tool reaches any depth. One solution would be to have the template link to a page that starts the database query and redirects the client to Google Maps with a cached result when the query is done. It's a much needed feature, and all it needs is someone to implement the framework.

Meanwhile, the GeoGroupTemplate is open for anyone to edit and add parameters to make the template use content outside the page it's transcluded on. I think, though, that it would be misleading to have a link in an article to map the contents of its category, instead of mapping the links in the article itself. The kmlexport tool has a mode to map the pages linked from the given page, see for example a map of Misplaced Pages:Requested pictures/Architecture. --Para (talk) 19:36, 7 August 2008 (UTC)

Could you post a link to look at the source code for the KML export script(s)? I will take a look at GeoGroupTemplate (about updating it to accept and display an article= parameter other than pagename). I will also take a look at the "linksfrom" option. LeheckaG (talk) 20:09, 7 August 2008 (UTC)

I'd rather keep the source for myself for now, until the needs and implementation have stabilised enough to consider cleaning up the code. That however doesn't stop people creating tools to combine the results from multiple queries; the MediaWiki API is available for implementing category recursion. --Para (talk) 21:11, 7 August 2008 (UTC)

My interest is that the interface between GeoGroupTemplate and KML export be appropriately documented, so that there are not undocumented parameters on either side. If there are future or proposed parameters on either side, they should be documented as "unimplemented" so that anyone maintaining either side is aware of what might "break" the interface and which modifications on either side need to be done in synchronization. LeheckaG (talk) 12:32, 8 August 2008 (UTC)

Fastcgi error

On Template talk:Coord#Fastcgi error now in Coord display and Template talk:Infobox nrhp2#Latitude/longitude links aren't working there is discussion about Coord returning:

• "Fastcgi Protocol Error

This server has encountered an internal error which prevents it from fulfilling your request. The most likely cause is a misconfiguration. Please ask the administrator to look for messages in the server's error log."

From the couple cases which I looked at, This is apparently due to Coord being supplied with a "template" parameter (display=title, format=dms, name= ...) without a "coordinates" parameter (region:, type:, scale:, source:, ...) resulting in a "malformed" URL ending in "_". For instance:

• Wollaston Islands (Nunavut)

with

• {{Coord|73|43|00|N|80|55|00|W|display=inline,title}}

generated:

• http://stable.toolserver.org/geohack/geohack.php?pagename=Wollaston_Islands_(Nunavut)&params=73_43_00_N_80_55_00_W_

• I updated the "offending" coordinates to:
• {{Coord|73|43|0|N|80|55|0|W|region:CA-NU_type:island|display=inline,title|name=Wollaston Islands (Nunavut)}}

resulting in: http://stable.toolserver.org/geohack/geohack.php?pagename=Wollaston_Islands_(Nunavut)&params=73_43_0_N_80_55_0_W_region:CA-NU_type:island&title=Wollaston+Islands+%28Nunavut%29 which works.

i.e. add a "coordinates" parameter (region, type, scale, source, ...) whenever adding a "template" parameter (display, format, name, ...) LeheckaG (talk) 07:25, 5 August 2008 (UTC)

Specifically, the problem appears to be with missing the "region:" coordinates parameter. From my limited tests playing with a "malformed" URL, it appears that when a region: parameter is NOT supplied, then the Fastcgi error occurs. But when a region: parameter is supplied (even if empty), then the Fastcgi error does not occur.

LeheckaG (talk) 07:47, 5 August 2008 (UTC)

Recent Toolserver geohack.php (actually mapsources.php) source code changes appear to have nothing to do with the Fastcgi error:

• https://fisheye.toolserver.org/browse/geohack/www

Specifically 2008-07-30 21:34:38 +0000 Author: magnus, Patch by en:user:SQL

• https://fisheye.toolserver.org/browse/geohack/www/mapsources.php?r1=1&r2=3

and 2008-08-03 21:39:23 +0000 Author: magnus, extended list of scales, by en:user:Docu

• https://fisheye.toolserver.org/browse/geohack/www/mapsources.php?r1=3&r2=4

So the "source" of the Fastcgi issue would appear to be something else on ToolServer which changed "recently" and either calls geohack.php or is called by geohack.php LeheckaG (talk) 09:00, 5 August 2008 (UTC)

Previous (geohack/mapsources) changes were more than a couple weeks ago. Does anyone know of the earliest reported instance of Fastcgi Protocol Error?

• ToolServer Blog mentions:

"(But look out for a future post about switchboard, a fast replacement for suphp using FastCGI -- if I ever get around to finishing it.) Posted at 11:44PM Jun 21, 2008 by River in Tech"

I am not sure whether the "glue" between the World Wide Web and ToolServer's .php scripts like geohack.php is?

• TSWiki:Python_WSGI#Flup

or

• https://fisheye.toolserver.org/browse/~raw,r=37448/wikimedia/trunk/switchboard/

So, I am not sure what changed "recently" (also not sure what "recently" means - 2 days, 2 weeks, ...)? LeheckaG (talk) 09:20, 5 August 2008 (UTC)

The toolservers give that FastCGI error for scripts that are running too long, and interrupts them. GeoHack shouldn't run long of course, but as LeheckaG noticed, it was taking its time when a region hadn't been given. That's because the region lookup functionality is running on another server that was unresponsive at the time, and GeoHack was waiting all eternity for it to answer. A bug report has been submitted. --Para (talk) 10:41, 5 August 2008 (UTC)

So the "moral" of the story is to "always" supply a "region:" with an accurate ISO 3166-1 (and 3166-2 region, for instance US-AK for Alaska, or US-OH for Ohio, ...) and some Geobox/Infobox which create a "Coor(d)" should supply the appropriate region (if known) when creating the Coor(d), or at least as much of it as known, for instance I updated Infobox nrhp2 to supply region:US_type:landmark (would be nice if the -XX state was coded/known) since nrhp2 and nrhp are specific to the United States of America. I did not update (yet?) but will check on the Infobox nrhp as well (not sure which other US-specific Geobox/Infobox templates there might be?) LeheckaG (talk) 10:50, 5 August 2008 (UTC)

It's exceptional for the main toolserver to be so busy that it doesn't answer within the 30 second fastcgi timeout, but with the current code always having the region parameter would be a quick workaround, yes. --Para (talk) 11:18, 5 August 2008 (UTC)

Infobox nrhp does supply "region:US_type:landmark", which was why nrhp2 (prior to adding region:US) was more susceptible to the Fastcgi timeout error than nhrp. LeheckaG (talk) 12:14, 5 August 2008 (UTC)

(From my talkpage) Well, when that happens to me, I check with the toolserver administrators. Having taken a look at the error log for the stable toolserver, I'm not seeing any specific problems from this application. Also, in reloading the same URL 10 times, I get one fastcgi error, and, nine successful pageloads. These two things combined, tell me there is not a problem with the application, but, with the underlying server (specifically Fastcgi... Hence the FastCGI Protocol error most likely, and not a blank page or a 500 internal server error, or a PHP error.). I don't think we use switchboard on stable, all projects there use FastCGI (and, I'm fairly sure there's no way around it). I'll see what I can do as far as bugging people, to get the problem resolved soon. SQL 14:34, 5 August 2008 (UTC)

As the creator of Wollaston Islands (Nunavut), I want to say thanks to all involved for your follow-up on this Fastcgi error issue. --Rosiestep (talk) 21:42, 5 August 2008 (UTC)

bad Coor(d)

Maintenance tasks:

• someone? should scan through the Geobox/Infobox templates to see which do and which do not supply region: with a valid ISO 3166-1 (like US) and or -2 (like US-AK for Alaska) code. (Infobox nrhp and nrhp2 both supply US, would be nice if they supplied US-XX where XX is the state code).
• likewise a list (sub- Category: ?) of "bad" coordinates should be created with a bot? populating such "list" with those articles containing coordinates which are not "completely/properly" specified. Perhaps a sub- Category: of "Articles needing coordinates" or "Pages requiring geodata verification"? LeheckaG (talk) 12:14, 5 August 2008 (UTC)

To be included on the Indonesian Misplaced Pages

I just wondering on how to put this feature on Indonesian Misplaced Pages? I am one of the contributor there and now we have article around 84,000 more and one of our target is reaching 100,000 by the end 2008. ThanksNaidNdeso (talk) 22:10, 8 August 2008 (UTC)

Response

I am not sure "which" feature? In general:

• {{Coord}}
• {{GeoGroupTemplate}}
• {{GeoTemplate}}

are the primary templates along with their inclusions/sub-templates, and categories. Additionally, you need the appropriate CSS class=/id= like "coordinates" and "geo*" (* meaning all) from common.css and Misplaced Pages:Skins.

If you post which feature(s) as well as a suggested use on the Indonesian Misplaced Pages, then we can probably provide some guidance as what needs to be copied over.

If we know what exactly you are looking for, we can possibly post a "How To" so that other language Wikipedias have a step-by-step "installation guide". LeheckaG (talk) 10:22, 9 August 2008 (UTC)

I forgot to also mention the MiniAtlas (when you click on a "globe" the pop-up map which appears), it depends on some JavaScript, but I am not sure exactly which files or pages are needed.

So post what you are looking for and then we can post the various details. LeheckaG (talk) 10:25, 9 August 2008 (UTC)

There is a short FAQ on meta:WikiMiniAtlas. Just put

importScriptURL('importScriptURI( 'http://meta.wikimedia.org/search/?title=MediaWiki:Wikiminiatlas.js' 
              + '&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400' );

in your site's MediaWiki:Common.js --Dschwen 14:57, 9 August 2008 (UTC)

Celestial Coordinate clickable template?

Has any thought ever been given to a template that would link a set of celestial coordinates to online sky "charts" (assuming such charts are/will soon be readily available)? This would be similar to how template:coor works. Likewise with selenographic coordinates. — Eoghanacht 21:44, 14 August 2008 (UTC)

For the latter (Moon), there exist:

• {{MoonTemplate}} corresponding to {{GeoTemplate}}; currently the map source is Google,
• Example: http://stable.ts.wikimedia.org/geohack/moonhack.php?params=49_45_24_N_6_38_29_E corresponding to GeoHack
• which links to: http://www.google.com/moon/#lat=49.756667&lon=6.641389&zoom=8

although Talk suggested United States Geological Survey MapAPlanet.Org:

• http://www.mapaplanet.org/explorer-bin/explorer.cgi?map=Moon&layers=moon_clementine_multi&west=55.25&south=32.61&east=60.00&north=34.99&center=57.625&defaultcenter=on&grid=none&stretch=none&projection=SIMP&r=5&g=3&b=1&advoption=NO&info=NO&resolution=303.23&scale=0.1185&imageTopX=-85419.456763&imageTopY=1067441.160253 .

The missing "glue" is an appropriate Geo Microformat:

• http://microformats.org/geo-extension-strawman

and corresponding Misplaced Pages templates (either similar to or modified versions of the Coor(d) templates which emit the Geo microformat (enabling the "clickable link"). The principal thing which is missing is an XML (geo microformat) tag indicating which celestial body the coordinates are on, and then the "glue" - on ToolSever - a modified geohack URL and geohack.php (instead of one for each planet like the moonhack.php, unless separate URLs are a better way to go?) and modified Coor(d) templates which accept an optional parameter to emit the appropriate geo tag.

In addition to the Moon, currently Google also has Mars.

There are several Astronomical coordinate systems, Google Sky uses the most common? Equatorial coordinate system, not sure which Epoch they use B1950, J2000? (longitude=Right Ascension (24 hours=360 degrees) and latitude=declination), for example:

• http://www.google.com/sky/#latitude=32.186073305250304&longitude=-96.82525634765625&zoom=11&Spitzer=0.00&ChandraXO=0.00&Galex=0.00&IRAS=0.00&WMAP=0.00&Cassini=0.00&slide=1&mI=-1&oI=-1

• {{RA}} and {{DEC}} accept and display Right Ascension and Declination, but do not provide clickable links. See also: Category:Astronomy inline templates.

• {{EqCoor}} (or EqCoor-DEC and EqCoor-RA) provides clickable links to WikiSky.Org.

For example:

• {{EqCoor|12|22|54.9|+15|49|21|15|M100}}

produces:

• Template:EqCoor,

which links to:

• http://www.wikisky.org/search/?title=Equatorial_coordinates&astro_params=12+22+54.9++15+49+21+15+M100.

See also Category:Astronomy external link templates. LeheckaG (talk) 07:26, 15 August 2008 (UTC)

There is some work going on at de:Portal_Diskussion:Astronomie/Wikisky&Googlesky, with a Skyhack being developed http://toolserver.org/~kolossos/sky/skyhack.php?ra=11.1925&de=-61.3622222222&size=0.05&name=NGC%203576 . --Dschwen 11:40, 15 August 2008 (UTC)

Default scale for {{coor dms}}?

In the case of coordinates including seconds, it seems to me that a scale of 1:300000 is too broad for such specific coordinates. Would it be possible/reasonable to change the default scale of {{coor dms}} to ~1:10000? Rami R 16:12, 16 August 2008 (UTC)

While 300000 might not be the best default. The issue is that coordinates and scale are independent variables and should be. One can give coordinates accurate down to the seconds - about 100 feet (30 m) for a large lake or reservoir, which is usually cited as the dam containing it or mouth draining it, so in that case, a small scale might not be appropriate. So if a scale is not specified, at least a "type" should be (which sets a default scale for that type). LeheckaG (talk) 20:14, 16 August 2008 (UTC)

Indeed scale and accuracy are supposedly independent, and cases with specific coordinates referencing large objects exist. However, I believe (I haven't actually tested this) that the in the majority of cases, when using specific coordinates one is referencing smallish landmarks. As such I believe that the default scale (when neither the scale or type parameters are given) should be significantly narrower than 1:300000. Rami R 21:38, 16 August 2008 (UTC)

Where to write the coordinates in an article ?

I added coordinates to Meidaimae_Station but I am sure I did it wrong, how am I supposed to do ? I could not find on the wikiproject page. Please tell me so that I do the next articles right. Thanks ! Nicolas1981 (talk) 07:07, 17 August 2008 (UTC)

User Wwoods gave me the answer :-) Just append "|display=title" in the {{coord ... }} tag and then the coordinates automagically appear in the upper right corner ! Cheers Nicolas1981 (talk) 09:05, 17 August 2008 (UTC)

To make life easier on yourself in the long-run, see Misplaced Pages:WikiProject Trains/Article templates#Article text and infoboxes. You probably should use either {{Infobox japan station}} or {{Infobox Station}}; or copy one of those or the Deutsch-German {{Infobox DB station}} or United Kingdom {{Infobox UK station}} template, and customize them as {{Infobox JA station}}.

A Coor(d) template can be placed in the Infobox in either a corresponding Place or Location fields. Coord ... "display=inline,title" ... causes coordinates to display both where the template is placed and the upper-right corner (article title bar). LeheckaG (talk)

Thanks a lot :-) I probably must use {{Infobox japan station}} as I am adding japan stations, and 50 existing one already use it. This infobox contains a lot of information but no coordinates, though... should I be bold enough and add a "coordinates" parameter like seen on {{Infobox DB station}} ? I am quite new in this area of Misplaced Pages, so I prefer to ask... is it legitimate to add the "coordinates" parameter to {{Infobox japan station}} ? Nicolas1981 (talk)

There are (3) possible approaches:

• Use an existing "Place" or "Location" field and put the coordinates are the beginning followed by <br> the-normal-WikiLinked-text-for-the-location

i.e. not sure how Japan is civilly subdivided, but elsewhere (like Canada/US): Address (if known), City, County, Province or State

• Go ahead and add coordinate(s) fields to the Infoxbox. Personally, I like to use {{Location map}} within an Infobox, which requires a separate latitude and longitude. In WikiText, it is easier to "build up", a.k.a. concatenate, rather than parse, a.k.a. split apart; consequently from separate latitude and longitude DMS fields any combination which is needed can be built, including generating a {{Coord}} template. Because Coord accepts additional coordinate (region:, type:, scale:, source:, ...) and template (display, format, name) parameters; there should be a collective coord_parameters field, and fields for each of the others.
• If an Infobox template is protected or you do not feel comfortable updating it, then post on the Talk page for the Infobox template asking about your proposed additions, and see what the response is.

I prefer to use {{Location map}} within Infoboxes because it allows you to create or use one graphic map (.SVG, .PNG, .JPG, ...) for the overall general area and use coordinates to overlay a marker on the map. So it requires less overall effort than generating individual maps for each article, and the Location map gives someone a general idea where a place is located.

LeheckaG (talk) 13:41, 18 August 2008 (UTC)

Thanks LeheckaG for your insight :-) As suggested by your third point, I opened the discussion on Template_talk:Infobox_japan_station. I am hesitating between {{Location map}} and {{Coord}}:

• location map makes it easy to have a cute small map in the infobox, very convenient.
• coord seems to be the standard for locating wikipedia things, which means more third-party parsers and applications will be programmed to understand it. Why use this other way of locating thing, is it legacy ?
• The best would probably be to make the small map builder understand the {{Coord}} format.

By the way, I encountered something that surprised me: how come some articles use both templates ? (To see one, edit Marbletown, New York and check "Pages transcluded"). Nicolas1981 (talk) 08:46, 20 August 2008 (UTC)

The Marbletown article you cited uses {{Infobox Settlement}}, which in turn transcludes {{Geobox coor}}, which in turn transcludes {{Coord}} which in turn transcludes a few "sub"-templates including {{Coord/link}}, which in turn transcludes {{Coor URL}}. This is somewhat "normal" behavior for Wiki templates, where transcluded "sub"-templates each do a piece of the work, and there is "reuse" a.k.a. borrowing/sharing functionality between template libraries/families rather than "re-inventing the wheel". In some cases, it could be re-done cleaner starting "with a blank slate" provided one knows and remembers the past issues and history involved in the development of the predecessors (so that one does not run into the same issues or make similar "mistakes"). In general, on Misplaced Pages, when something works - people generally re-use things as is and do not go tearing older things apart unless they "break" or the available functionality needs to be extended. Recently, I have gotten into the "habit" of verifying template source code against the documentation and trying to ensure that the template documentation is updated before using a template (at least that all parameters are documented along with their default values).

There are some articles which actually do use multiple Coor(d) templates: in the Infobox, in-line in the article text, and often in External links section. These separate coordinates often use different coordinates templates, and sometimes have inaccuracies where several different coordinates are stated for the same geographic feature. In general, coordinates should be "confined" to the appropriate fields in the Infobox(es) or in appropriate tables (when the article details several "related" features), and the article's ONE "primary" latitude,longitude coordinates should display in the article's title bar (in the upper-right corner).LeheckaG (talk) 13:42, 20 August 2008 (UTC)

LeheckaG, thanks a lot for taking the time to explain this in details ! I spent my day yesterday investigating, and will continue analyzing how pages are built, that's very interesting :-) I makes me reevaluate the strategies for writing a wiki geodata extractor. Cheers, Nicolas1981 (talk) 04:11, 21 August 2008 (UTC)

For geodata extraction, your two possibilities are either:

• ("internally", within Wiki) retrieving "raw" unrendered Wiki pages, and looking for the some of the variations of either coordinate templates or other templates like Geo-/Info- boxes, which transclude coordinate templates behind the scenes, and corresponding coordinates fields.
• ("externally", outside of Wiki) retrieving rendered Wiki pages and looking for Geo microformats. Which is what external search services like Google do.

On Wiki, like on ToolServer with PHP code scripts, you have both options available - there are some PHP scripts which can search for the rendered geo microformats, and some which can search the unrendered source pages for specific coordinate templates or coordinate fields.

Because searching text can be taxing on the Wiki database servers, bulk searches are best performed on an exported copy of the database and best performed off-line on another server. If coordinate searches can be more confined in scope, then they can be performed in the Wiki environment (usually on "ToolServer", which is actually more than 1 server, using recently replicated local copies of the Wiki database). LeheckaG (talk) 06:57, 21 August 2008 (UTC)

Here is DBpedia's GeoExtractor, which I was considering improving, it is already quite smart though. It uses what you called "internal" extraction, and additionally it looks for "coord" in each of the templates that would be transcluded during the page build :-) Nicolas1981 (talk) 14:00, 21 August 2008 (UTC)

Polar co-ordinates

See List of research stations in Antarctica, Extreme points of the Antarctic and Extreme points of the Arctic. For obvious reasons, distances are horribly distorted in the polar regions when viewing such areas. Is it possible to link to map services that do a polar projection? Are such services available? (Cross-post from Template talk:GeoGroupTemplate). Carcharoth (talk) 02:50, 18 August 2008 (UTC)

Thanks everyone for your work !

I am a huge DBpedia fan, and coordinates are precious for building impressive software based on Misplaced Pages infoboxes data... so kudos to everyone who makes the effort to contribute coordinates, it is immensely useful :-) Nicolas1981 (talk) 11:59, 18 August 2008 (UTC)

Geolocation search tool

I’ve create a search tool that allows for regular expression searching on the GeoHack links in the external links table. This has the advantages of near real time information and powerful pattern matching. The following are some example queries I have created as a demonstration of the flexibility of the system.

— Dispenser 16:05, 19 August 2008 (UTC)

Can you make the wiki configurable. This would be useful to find heading:? locations on commons. --Dschwen 16:55, 19 August 2008 (UTC)

You can append &site=commons to the end of URL, but it isn't robust yet. Many assumption where made about the English Misplaced Pages as to speed up development. — Dispenser 18:10, 19 August 2008 (UTC)

Good tool. I used to fix a few erroneous coordinates. At some point, I suppose we should fix all the Greek coordinates, they fill up the result pages .. -- User:Docu

My bot fixed most of the Greek coordinates. I added your table to WP:GEO#Coordinates_search_tool with a column to note the last time they were fixed. -- User:Docu

I've been working a tool over the past few day that will parse all external links and dump them in database accessible to everyone on the Toolserver. But during the course of development I found coordinates that geohack would happily accept without throwing errors like python does, some of them that I haven't work in exception are listed in the log's output. And those greek coordinates unsubsting the templates I saw eailier? — Dispenser 21:48, 23 August 2008 (UTC)

So I guess its time for some interesting stats. First off, the most popular globe other than earth is the Moon (424), followed by Mars (70), then our sister planet Venus (14), then by Mercury(13). None of the gas planets are listed nor the moons beside ours. The most popular source for data label is GNS-enwiki (32139), dewiki (5868), gnis (3548), the UScensus1990 (2654), GNIS-enwiki (1432), and again by enwiki-GNS (1423). City (236803) is the most popular type followed by NULL (164795), and rather vague landmark (75239). Popular errors in the region type are adm2 (2665), admin2nd (904), city(348991) (206), country({{{area}}}) (55), city(300) (55), adm3rd (52). — Dispenser 22:40, 23 August 2008 (UTC)

I tried to find type:city\(348991\), but without success. I must have misunderstood your comment or it's already fixed since. -- User:Docu

My mistake, It should have been type: not "region type" and the parenthesis should be escaped. — Dispenser 18:07, 24 August 2008 (UTC)

Thanks. I forgot about escaping .. anyways, looks like the Brazilian coordinates are ok, except for the type and source part. -- User:Docu

75239 landmarks .. -- User:Docu

Similar to wp-world/info.php, would it be possible to compile a list of all types and region codes that are being used? -- User:Docu

500 most used values for type and same for region. — Dispenser 18:07, 24 August 2008 (UTC)

Thanks. BTW in the meantime there are 1500 type:edu -- User:Docu

GEOnet Names Server

I'm trying to sort out just how accurate GEOnet Names Server is. I figure members of ths WikiProject should have some opinions, at least as far as coordinates are concerned. Currently, over at Misplaced Pages talk:Notability (Geographic locations) the conversation has turned into more of a WP:V debate, and I've suggested that using GNS and sources such as FallingRain that take their data from GNS is unwise. I've also opened an AfD on such an article; Misplaced Pages:Articles for deletion/Əngəlan. I'd appreciate any insight you folks might have, even if you reject my AfD nomination I'd feel better about it if it has wider consensus. Phlegm Rooster (talk) 06:00, 20 August 2008 (UTC)

In general, most government-run GNIS/GNS services (USGS GNIS, NGA GEOnet Names, CA BC, ...) are reliable and verifiable provided one understands the accuracy limitations of particular coordinates: degree = about 60 miles (97 km), minute = about 1 mile (1.6 km), second = about 100 feet (30 m). For a more accurate conversion, 1 minute = about 6,076.1 feet (1,852.0 m). In general (some minor clerical errors aside), government-published coordinates are accurate within +/- 2 units prior to any missing fields or zeros. The +/- 2 units (rather than +/- 1/2 unit) comes from (3) possible sources of "error": conversion from different coordinate datums, "rounding" or "truncation", and "deliberate" offset (for "security" reasons). The majority of coordinates are accurate within +/- 1/2 to 1 unit, the ones with the greater +/- 2 unit error margin should be in the minority.

For the (Azeri/Russian) language/(Arabic/Cyrillic) transliteration "issues" with the (Əngəlan, Angalan, Ангалан, Angilan, Ангилан, ...) village article please see my posts on the AfD discussion for the AfD-nominated article which you cited above.

On the other hand, for "Third-party" GIS/GNIS/GNS systems, what is needed is "Traceability", to know which "authoritative" or "official" source they received their information from, which some systems provide and others do not. I suppose "photogrammetric" (spelling?) verification is sufficient to verify coordinates provided by a third party (i.e. opening them up in a aerial/satellite map service and verifying that placemark on the imagery matches the described location), but for "encyclopedic" purposes, a better "authoritative", "official", or "primary" reference source for the coordinates should be cited when available. In general, I recommend MENTIONING third-party GIS/GNIS/GNIS systems for additional information, but I do not NOT recommend CITING them as the "official" reference source; i.e. it can often be the case that one needs to "go through" a third-party system to locate the "clues" necessary to find an "official" source. The third-party source should be mentioned as "informative" while the official source should be cited as authoritative/normative. Personally, I prefer separate "Notes" and "Reference" sections, and a "General references" sub-section under references. "Notes" are used to otherwise clarify information or text in the article, Geo/Info-boxes, or tables. For instance, to describe how (2) or more cited-reference facts "add up" to information in the article, or to otherwise document a "jump" between a cited reference and the article. "References" should be used only for cited i.e. <ref></ref> {{Reflist}} references. Whereas, "General references" can be used with {{Refbegin}}, {{Cite}}, and {{Refend}} to mention those sources generally used to write the article but not specifically cited, or to document useful references which could be used to expand the article in the future - and in doing so those General references would then be cited and moved from "General references" to "References". So a third-party GIS/GNIS/GNS system "reference" could be mentioned in either "Notes" or "General references", but an "authoritative/official" source should be "cited" under References. When possible, a "one-click link" to the exact reference page should be provided; for instance, use {{Cite gnis}} or {{GEOnet2}}, rather than {{GR}}.

For some places, there might not be any "coordinates" published by an "official" source, but rather a narrative description; for such locations, the "official" source for the narrative description should be <ref>{{Cite}}</ref> cited, and then a {{Cnote}} in a "Notes" section and {{Cref}} where the coordinates are used to describe the process employed to translate the description to the coordinates used in an article. For instance: "Google Earth (or Google Maps ...) used to geocode intersection of Route ... and ... Street, then ... manually plotted based on official description: ... from intersection. LeheckaG (talk) 16:50, 20 August 2008 (UTC)

Is it truly reliable(

As to U.S. DoD GEOnet Names (NGA.Mil) database reliability - it is only reliable to the extent of information which they provide directly: "official" Anglicized version(s) of names, country and administrative region (province/state) containing the feature, and coordinates - which are only as accurate as they are willing to publish to the general public +/-2 in the last units.

For the U.S., the "standard" authoritative/official source is the corresponding USGS GNIS (GeoNames.USGS.Gov) database.

For Canada, there apparently is not a national system, but there are several provincial ones, like British Columbia has http://ilmbwww.gov.bc.ca/bcnames/.

I am not sure what Australia or the United Kingdom have? The U.S. DoD GEOnet Names database is supposed to coordinate with official sources in other countries, so I am not sure which official governmental sources they use. For named marine or nautical features it is a bit simpler because international law codifies the official authoritative source as being a country's Coast Guard or Navy equivalent.

I agree that third-party republishers should NOT be cited as an authoritative source, but only as a "informative" source - the difference between a "cited" reference and a general reference. The purpose of a "general" reference is so that people researching a topic can find "clues" as to more sources of information; versus a cited/footnoted reference is an authoritative/official/reliable source where specific data in an article came from.

Any source needs to be "taken with a "grain of salt", errors are possible, so Misplaced Pages contributors should not "blindly" copy "official" government published information without a "common sense" fact-check to verify that what is being included in Misplaced Pages "makes sense". For example, in Alaska the U.S. Census Bureau uses fairly large census geographic areas, and their cited coordinates for a "populated place" can often be "in the water" or "on a mountain" - so "common sense" is required to verify by actually comparing posted coordinates with an area map.

In geographic names databases, generally "street names" are not included among locales or populated places unless they are somehow "noteworthy". They do not necessarily need to be a civil subdivision (municipal corporation/government) but they do need to be a named "populated place" where the surrounding area is generally known by that name.

The names in GEOnet names are "Anglicized" so they often vary from the local name in the local language - so that needs to be taken into account.

There are different classes or types of NGA populated places:

• PPL - Populated Place
• PPLA - 1st-order administrative division seat
• PPLC - political capital
• PPLL - locality
• PPLQ - abandoned
• PPLR - religious
• PPLS - places
• PPLW - destroyed
• PPLX - section

so one needs to consider what kind of "Populated Place" one is referring to. LeheckaG (talk) 13:11, 25 August 2008 (UTC)

E.g. GEOnet gives the Belgian populated place (PPL) of "De Lieve Dochter", for which I can find no evidence at all. The same goes for "De legehaar" or many other Belgian "placenames". E.g. Wittingstraat is a PPL according to GEOnet, but is just a random street in Stekene.

There is no evidence that this street (or many of the other "straat" places in the database) are used to indicate the surrounding area. You can read Misplaced Pages:Articles for deletion/Polfbroekstraat for another street which can be found on GEOnet where the consensus was that it was just a minor street without any justification for an article. I would suggest to not trust GEOnet for any Belgian location, and to check some other countries (preferably with editors from those countries) to check if they used a particularly bad source for Belgium, or that the site is generally unreliable (even though it is government operated). Fram (talk) 13:50, 25 August 2008 (UTC)

The Belgium source for the U.S. DoD NGA GEOnet Names is http://www.ngi.be/; on Misplaced Pages: Belgian National Geographic Institute. In general NGA sources are http://earth-info.nga.mil/gns/html/relatedlinks.htm some of the links are out-of-date, but the source names are generally correct. When one is able to determine the foreign official source (like BE NGI), then when possible, that official foreign source should should be used instead of U.S. DoD NGA GEOnet Names.

In the WikiProject Geographical coordinates at GEOnet Names Server or WikiProject Geographical coordinates at GEOnet Names Server, Polfbroekstraat (Dutch: Polf "pants" Street) case, it is a street/neighborhood of Sint-Lievens-Houtem about 3,000 feet (910 m) West of the NGA published 50°55′00″N 003°52′00″E / 50.91667°N 3.86667°E / 50.91667; 3.86667. NGA "Anglicizes" and republished foreign official sources, so apparently Belgian NGI "coded" Polfbroekstraat as a "Populated Place", which they (Belgian NGI) probably should have either clarified or coded differently. One would need to "go through the history books", it is likely/probable that "Polf broek" formerly was a small community or notable feature of some kind for which the current modern street is named.

In the WikiProject Geographical coordinates at GEOnet Names Server or WikiProject Geographical coordinates at GEOnet Names Server, Wittingstraat (Dutch: Witting Street) case, it is a street/neighborhood about 2,000 feet (610 m) South and West of the NGA published 51°12′0″N 4°0′0″E / 51.20000°N 4.00000°E / 51.20000; 4.00000. In between cities/towns of Stekene, Klein-Sinaai, and Koewacht. Same BE NGI comments apply.

In the WikiProject Geographical coordinates at GEOnet Names Server or WikiProject Geographical coordinates at GEOnet Names Server, De Lieve Dochter (Dutch: "The Dear Daughter") case, is somewhere within 1 mile (1.6 km) of 50°54′00″N 003°29′00″E / 50.90000°N 3.48333°E / 50.90000; 3.48333 near Kruishoutem and Zulte.

Belgian placenames like "Polf Pants" street, "The Dear Daughter" ... are typically named after such and then the spaces are dropped to form a name.

So "common sense" is required, NGA confirms that such a "populated place" existed and publishes its coordinates to whatever accuracy (minutes are about 1 mile (1.6 km). Using the coordinates and looking at a on-line map service (within a few thousand feet or several hundred meters) one can see that it is likely a street/neighborhood name rather than a "town", "village", "city" ... so:

• It is necessary to use common sense.
• NGA only provides "evidence" that a "similar" (possibly miscategorized) feature with a similar name (keep in mind NGA names are "Anglicized") was or is "near" their published coordinates.
• NGA does not provide evidence of what exists there now.

So in the Belgian cases, it helps to restrict Google searches with "site:.Be", and also helps if you translate the names from the foreign language (Belgium names can be a variety - not just Dutch) to English, breaking it apart into the roots like "Polf Broek Straat" so that you have some more insight into what you are looking for. LeheckaG (talk) 16:43, 25 August 2008 (UTC)

Thanks. A "broek" is a swamp in toponyms, and should not be translated as "pants". Not that that changes anything. I agree with your analysis, but I just wonder why NGA is then considered a reliable source to indicate that a village ever existed (like at the AfD mentioned at the beginning of this section). Once we have other (independent) evidence that some place exists, we can use GEOnet to give us the coördinates and so on. But to create and/or keep articles solely on the strength of GEOnet seems dubious. Fram (talk) 18:58, 25 August 2008 (UTC)

Reliable sources for coordinates?

There have been some discussion over at Talk:Camp 1391 of the Camp 1391 article should have coordinates, what coordinates, and if there are reliable sources for the coordinates and so on. Some help would be appreciated. We have a description saying it is "situated in Israel's North District near Pardes Hanna, less than an hour's drive from Tel Aviv and close to Highway 65 between Hadera and Afula.", but exact coordinates would be nice to have. // Liftarn (talk) 21:47, 21 August 2008 (UTC)

Does Israel have something equivalent to the US's Geographic Names Information System? That would be the obvious WP:RS. Otherwise, perhaps there's an impartial mapping service? —EncMstr (talk) 21:55, 21 August 2008 (UTC)

Since it's a black site and it doesn't appear on official maps and it's airbrushed out of aerial photos I don't think it's likley they publish the coordinates just like that. We have some sources the question is how reliable they are. // Liftarn (talk) 11:20, 22 August 2008 (UTC)

UK rail station coordinates

User:The Anome/Railway station coordinates lists geocoordinates for around 1400 UK National Rail station articles that did not have coordinates as of 2008-08-23. The articles are listed by their current Misplaced Pages titles, after best-effort redirect following and disambiguation. See the page itself for source data: whilst I've devoted best efforts to this, the usual disclaimers apply. -- The Anome (talk) 00:45, 24 August 2008 (UTC)

Above ( #New types (WP:GEO#type:T) ), I suggested to create a new type for these. I haven't added it yet to WP:GEO#type:T, but I'd like to go ahead now. What do you think? -- User:Docu

Omitting scale: prefix?

The instructions in the scale:N section states that the Scale: prefix can be omitted. I can not understand how this can be correct. What would an example of this look like? Perhaps what is meant is that this parameter is optional? __meco (talk) 08:53, 24 August 2008 (UTC)

Yes, it should read "parameter" instead of "prefix". -- User:Docu

I changed it accordingly. -- User:Docu

Coordinate parameters (region:, type:, scale: source:) can be omitted, but it is good to understand what occurs when you do, and thus the "value" of including all the known parameters.

• region: is an ISO 3166 code which (can) determine which set of maps are available for some mapping services. It is generally region:XX-YY a 2 character ISO 3166-1 alpha 2 country code followed by 2 to 3 character ISO 3166-2 province, region, or state code. Omitting region: can cause some performance issues potentially resulting in a timeout error message, because ToolServer.Org then does a database lookup to try to resolve blank or empty regions.
• type: was initially intended as a "shortcut" to hint at the appropriate scale:, type: defines relatively reasonable default map scales for most types, scale: overrides the map scale hint provided by type:, it has "unofficially" become a "type" used for data-mining types of coordinates, omitting type: results in the default map scale (usually 1:300000)
• scale: sets the initial map scale when a map is opened and overrides the hint provided by type:, most map services allow zooming in or out from the initial scale, but it is generally good practice for the feature and its general surroundings to be initially visible so that a user does not need to zoom in or out
• source: provides a hint as to where the coordinates came from like source:gnis, the hints are used by "bots" doing data-mining to determine whether to copy or otherwise transform or translate coordinates. For instance, coordinates labeled as source:gnis generally came from one "good" source, like USGS, so they should not be modified nor replicated more than once by "bots". It is possible for coordinates without a stated "good" source to get copied or updated by bots.

So, ALWAYS try to provide a region:, you "should" provide type:; recommended that you provide scale: and source: if known. LeheckaG (talk) 10:27, 24 August 2008 (UTC)

As Meko pointed out, taken literally, the instructions stated that one could write "10000" instead of "scale:10000". This is fixed now. -- User:Docu

No applicable type

When mapping a metro station, the closest types I can find in the list at the type:T section are Landmark or Airport, hardly applicable any of them. Aren't there more types in existence or can't we create more types? __meco (talk) 09:14, 24 August 2008 (UTC)

landmark should be used if there is no other applicable type. The new "railwaystation" (see #UK_rail_station_coordinates might do as well. -- User:Docu

Perhaps when it has been introduced into the template code (or wherever these types are defined). If anyone uses this type currently the map will show with a scale of 1:300.000 which is inappropriate even for very, very large railway stations. __meco (talk) 12:32, 24 August 2008 (UTC)

I added it to WP:GEO#type:T. Support by geohack should follow, hopefully. -- User:Docu

I don't know who/what geohack is, but is this an educated assumption on your part? Or are you just hoping somebody will notice your edit? __meco (talk) 17:43, 24 August 2008 (UTC)

Geohack generates the mapsource page that opens when you click on coordinates. To have it updated, one needs to ask Magnus_Manske. Preferably only once we agree about the name and the scale. --User:Docu

Well, I used 1:50,000 for the several metro station articles to which I have now added map coordinates using the scale: parameter and omitting the type: parameter. __meco (talk) 18:10, 24 August 2008 (UTC)

Is there a type:building? --NE2 19:00, 25 August 2008 (UTC)

More cleanup

A series of pages have links that appear to be substitute old geolinks templates. Special:Linksearch/www.mapquest.com finds a few (2044). If a standard coordinate template is available, these may simply be removed. -- User:Docu

Is it possible to run the query and omit the *_Talk: namespaces? i.e. probably only the :En: main article namespace and possibly the Template: namespace article pages need to be updated. LeheckaG (talk) 16:21, 24 August 2008 (UTC)

Probably not directly on the special page. The feature used to be on the interface, but didn't work. In AWB one can build lists from Special pages and use "Linksearch/www.mapquest.com" as input, then filter by namespace. -- User:Docu

Solution for polyline locations

Has there been any discusion on mapping rivers and autoroutes other than mapping names along these polylines? __meco (talk) 09:56, 25 August 2008 (UTC)

Rivers generally have their "mouth" and "origin" or "source" coordinates in an article's Geobox or Infobox.

I have done a few (rivers) where I included a table of named tributaries including coordinates for the confluences, and included {{GeoGroupTemplate}} so that a (Google/KML) map could be produced with multiple markers.

A "better" solution would be a way of "grabbing" relevant public domain (like from a U.S. government source) background imagery and overlaying a .SVG image which highlights and labels the course and tributaries.

A "schematic" alternative is to use the "BSicon *.svg" and Misplaced Pages:Route diagram templates a.k.a. most but not all of the following:

• BS&WR route map

to produce a "strip" map of a river or route showing confluences, junctions, ... I have proposed that the "strip" maps be "clickable" to go to the corresponding coordinates on a map, but that has not achieved consensus.

LeheckaG (talk) 10:32, 25 August 2008 (UTC)

List of crossings of the Willamette River has one way of doing an approximation, but it is textual, very non-graphic, and misses all the turns. —EncMstr (talk) 15:07, 25 August 2008 (UTC)

coord template one year on

The project page says As of August 2007, there are several different high-level ways of entering coordinates, with no clear consensus on the best way. The most popular techniques are... and lists the various coor * templates, plus coord. {{coord}} was created, over a year ago, with community consensus, the support of Google, and the explicit intention to provide the functionality of all of coor *, which were then to be replaced (bots were lined up to do so). Why has this not been done? Consider a newcomer to Misplaced Pages, and the confusion so many redundant alternatives will present them with. Andy Mabbett | Talk to Andy Mabbett 15:51, 26 August 2008 (UTC)

Perhaps because, one year on, there has been no observable problems with maintaining the status quo. It seems that there is no evidence that the 'confusion' actually exists. Crispness (talk) 16:01, 26 August 2008 (UTC)

I agree with Andy here. Deprecating and eventually removing the old coordinate templates would make this whole bussiness cleaner. There is no benefit to keeping them. If the instructions can be shortened by even one sentence that would already make removal of the old templates beneficial. --Dschwen 16:07, 26 August 2008 (UTC)

Do the older coor * templates emit a geo microformat like coord ? Perhaps if they lack such it might be justification for deprecating the older templates?

Admittedly, I prefer using one coord template to the family of coor * templates (yes, I realize transcluding coord includes a few coord/ sub-templates); mostly using coord with DMS N and DMS W coordinates with the display=inline,title parameter; except for additional related-coordinates in "list" or similar articles where I omit the display= and let it default to display=inline. I try to supply as many coordinates parameters as known (region: type: source:) but often do not take the additional time to set a more appropriate map scale:. I set the name= parameter when there is more than one set of coordinates in a list article.

Where Geo- or Info- boxes use a Location (pushpin) map, I try to use it, and have been trying to get their corresponding templates updated so that they have a way to set the coordinates parameters (usually more of a political than technical challenge).

The use of coordinates in the templates and in geo microformats cite the corresponding IETF RFCs (coordinates in DNS records, and MIME vCARDS) as the basis for their standardization, and the one component which I feel is missing is the optional altitude/elevation parameter specified in those RFCs, there is a geo microformat proposal to reintroduce altitude/elevation, so the (coord) template which emits the geo microformat should accept an optional altitude/elevation parameter (the 'coordinates in DNS' RFC specified 'meters above mean sea level' as the default units, unless an optional units parameter was suffixed). LeheckaG (talk) 16:43, 26 August 2008 (UTC)

Do the older coor * templates emit a geo microformat like coord ?

No: that was one of the reasons why {{coord}} was written. Andy Mabbett | Talk to Andy Mabbett 16:48, 26 August 2008 (UTC)

Somewhat unrelated. I think a single template like coord is a big improvement -- but it would really be nice if it were made easier to use. I mean, the way parameters are just glommed together is very awkward (eg {{coord|43|16|40|N|85|48|37|W|region:US-MI_type:city_scale:30000_source:GNIS|name=Bailey, Michigan}}. Couldn't region, type, scale, source all be made separate parameters instead of the weird concatenation? older ≠ wiser 16:53, 26 August 2008 (UTC)

My educated guess as to the parameter reasoning - is that geohack.php/GeoTemplate has (2) kinds of parameters: those "globbed" together and separated in the URL with underscore "_" characters in place of spaces, and a few "named" parameters which use "&" as a field/parameter separator. While it is possible to modify coord so that it accepts separate named or positional parameters and then either coord or geohack.php/GeoTemplate handles concatenating or rearranging them. The "globbed"-together parameters allows other (new) parameters to be accepted without needing to modify several components (coord, geohack.php GeoTemplate) to accommodate them, instead changes are "localized" to updating either geohack.php or GeoTemplate (depending on the change) without needing to update Coord. LeheckaG (talk) 17:55, 26 August 2008 (UTC)

Considering that we do want to move to an easier solution, given that coord has other drawbacks than the coor * family, I think the solution provided by {{coordinate}} is an interesting one to consider. It was develop based on the experience with {{coor at dms}}, {{coord}} and an other even more complicated template that was used other languages. -- User:Docu

• WikiProject Geographical coordinates pages
• Misplaced Pages pages with to-do lists