Geographical coordinates

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

Archives

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

Conversion: For issues to be considered in upgrading other coordinates templates to this one, please see /conversion.

Following a lenghty discussion on WT:GEO, it appears that one of the features from other templates that could improve others, was the introduction of named parameters for parameters such as type, region, scale.
This would result in using "type=landmark|region=GB|scale=5000" instead of "type:landmark_region:GB_scale:5000".

Using pipes (|) instead of underscores (_) has also the advantage of being closer to the way people use parameters in wikipedia. Probably already now, {{coord}} is frequently used this way. If we want to identify the pages, adding this sample code to {{coord}} would categorize all these pages into a maintenance category Category:coord template needing repair.

All articles that would end up in the category currently need repair as information on region/type/scale is present in the article, but not passed on to geohack. Check, e.g. this version of Carreño.

If we decide to use named parameters, the named parameters can be used within the template to check input. {{coord}} would need to be modified slightly to pass them on to geohack (see fix). -- User:Docu

Similar to checks in {{coor at dms}} and {{coordinate}}, I'd like to add checks to verify if the there aren't any excessive number of input fields. Sample:

• For Template:Coord/input/d,
• the input should be {{coord|12|N|12|W|region:XY_type:landmark}}
• not {{coord|12|N|12|W|region:XY|type:landmark}} which renders as {{coord|12|N|12|W|region:XY|type:landmark}}

The subpage includes additions to make to each template. Any article with an excessive number of input fields would be categorized in Category:coord template needing repair. -- User:Docu

Sometimes input is made in the degree/minutes/seconds format instead of decimal format, e.g. {{coord|12|67|85}} instead of {{coord|12.6785}}

To be able to identify and fix these uses of {{coord}}, I'd suggest to make an addition similar to the ones used on {{coor at dms}} or {{coordinate}}. (sample fix}}

This would categorize all articles with minutes/seconds equal to or exceeding 60 seconds in Category:coord template needing repair. -- User:Docu

Not every case of 60-seconds/60-minutes is faux-decimal. I would suspect that almost all case of values of exactly 60 are the result of poor round-off code.

Although I agree that seconds or minutes values > 60 probably indicate the entry of decimal values in faux-dms format, values of exactly 60 are more likely to be the result of careless rounding-off of floating-point values in badly-written numerical-processing code. For example, 1° 24' 00" might end up being represented 1° 23' 60" after conversion to floating-point followed by conversion back to DMS.

It's easily done; I've done it myself, and I've seen similar values output from Google Maps, who should know better. For example, see this: http://maps.google.com/maps?ll=6.8,-1.083333&spn=0.1,0.1&q=6.8,-1.083333 , which displays as +6° 47' 60.00", -1° 4' 60.00 within Google's interface. -- The Anome (talk) 08:59, 16 September 2008 (UTC)[reply]

We could modify the template to categorize only articles with minutes/seconds > 60. Note that geohack converts 1°60' to 2°. -- User:Docu

Unresolved

 – Conversions to dms with some of the secondary templates may still need repair.

(separated from previous section with new header by Docu).

Better to fix the bug in template:Coord/dec2dms/dms, I fixed it on fr a few month ago. Adapt it from fr: to en: ? - phe 17:55, 11 September 2008 (UTC)[reply]

Reading your post, I'm wasn't sure what the nature of the bugs was, but it appears to be related to :

the output generated with "format=dms" when the input is in decimal format.

I generated a series of tests at template:coord/dec2dms/dms/testcases and it looks like values in minutes don't round correctly. With fr:Template:Coord the same tests give a better result. -- User:Docu

Yes, I misread the above section, I was thinking about the 60″ with {{coord|2.4333|-73.9667|format=dms}} --> 2°25′60″N 73°58′00″W. Quite possible the same rounding problem exist with other template [1], I didn't fix them on fr: phe 08:24, 12 September 2008 (UTC)[reply]

I updated template:Coord/dec2dms/dms with the fr:template:Coord/dec2dms/dms. The testcases are working now correctly. As I'm not sure when/how the other templates are called. I leave the others for now. -- User:Docu

According to Template:Coord/doc, {{coord}} is to be used only for Earth. Thus we could add the above limits for degrees latitude and longitude. Most coor d/dm/dms templates already check for latitude >90°.

Code would be similar as the one for minutes/seconds. I will adapt it and add it here. Articles would also be categorized in Category:Coord template needing repair. -- User:Docu

WP:Geo has a "to do" item of "Add an attribute for other planets and the moon"; and Coord has a "globe" parameter. There is also a proposal to add a corresponding "body" and a "schema" property to the Geo microformat and to the vCard specification.

What effect will the proposed changes have on the maximum number of instances of Coord which can be used on one page?

Isn't checking for such errors best done by a bot? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:20, 16 September 2008 (UTC)[reply]

How would such a bot work? -- User:Docu (signature added per [2]: Docu (talk · contribs))

By applying the same rules of logic as currently encoded into the template; but in the manner used by SmackBot and similar bots. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:26, 18 September 2008 (UTC)[reply]

That a bit too much summarized for me: How would it identify Latitude >90° and longitude >180° ? How would the bot fix them? -- User:Docu

I think the former would be achieved by comparing the existing value with a value of 90/ 180 respectively and seeing which was bigger; but where did I say it would fix them? How would your proposal fix them? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:43, 18 September 2008 (UTC)[reply]

So the bot would just read all pages and output a list? Then re-read them later? If we build in a check, incorrect uses will be identified directly, no use to do so later. -- User:Docu

Output a list, or add a category. Bot checks, and repairs, seem to work well for many other templates. Please will you now address the other points I raised in my first post in this section? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:55, 18 September 2008 (UTC)[reply]

Maybe you should try to implement your proposal. If it improves things, it is fine with me. -- User:Docu

I repeat: Please will you now address the other points I raised in my first post in this section?. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:06, 18 September 2008 (UTC)[reply]

Did you make any progress with your bot proposal? -- User:Docu

The bot wouldn't have to read all pages, the coordinates are stored in the externallinks table in the db. Extracting those is a matter of minutes. --Dschwen 23:05, 1 October 2008 (UTC)[reply]

An apparently undocumented feature of this template is that, if the name parameter is set, an hCard microformat is emitted. This causes problems in several ways:

• It can conflict with the use of the template inside other templates/ tables, such as infoboxes, which are themselves designed to emit an hCard. In such cases, redundant, and incomplete, second hCards are often generated.
• It precludes the use of additional hCard fields such as address properties, dates, etc.
• The name is hidden by CSS in the output HTML. Some microformat parsers, including the most popular, Operator, by default, ignore hidden content.
• Even where the coordinates relate to a person (such as those of a burial place) an HTML class of "org" is included; this flags the coordinates as belonging not to a person, but to an organisation or venue.

I propose that this be resolved by removing the mark-up <span class="vcard"> and <span class="fn org"> from the child-template {{Coord/link}}; along with their two paired closing tags. These classes are used only by the microformat; and are not styled in any Wikipedia skin. The name parameter would remain, still hidden, for use by other services. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:51, 18 September 2008 (UTC)[reply]

Removing the spans would break the structure by taking away the markup for the name. To retain the microformat functionality, used by a tool in {{GeoGroupTemplate}} for example, the associated HTML would then have to be written to articles directly, obfuscating the wikitext and making articles harder to edit. These issues were discussed thoroughly before, please see Archive 4#Moving microformat markup from articles to coord. --Para (talk) 22:05, 18 September 2008 (UTC)[reply]

What do you mean by "break the structure by taking away the mark-up for the name"? {{GeoGroupTemplate}} doesn't require an hCard "fn"; but will use the proper, parent hCard name where one is provided. Nothing in the earlier discussion resolves the points I list above. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:09, 18 September 2008 (UTC)[reply]

Most coordinates on Wikipedia with a name parameter do not have surrounding classes or names in prose and removing the elements would therefore break compatibility with the microformat tools in the majority of cases. The widely supported modification a year ago did exactly the opposite of your proposal by clearing articles of markup that doesn't belong on article level. All issues except perhaps for the last one were discussed, resulting for example to the mention of infoboxes in the documentation of the template. On the last point: people don't have fixed coordinates; coordinates for a burial site are for the location of the grave. Inclusion of such detailed information in Wikipedia is questionable anyway. --Para (talk) 22:58, 18 September 2008 (UTC)[reply]

Unless you can cite evidence of such a case, I think your claim that "removing the elements would therefore break compatibility with the microformat tools in the majority of cases" is false; removing the classes from Coord would still leave it rendering a Geo microformat (which is what it was created to so in the first place), and the relevant tools are made to work with that. The changes of a year ago did a deal of damage; for instance here; where "label" (unformatted address) and "note" properties were removed from the hCard microformat; perhaps you could tell us how they can be replaced? The issues may have been discussed, but the problems were not resolved. Coordinates for the graves of dead people are labelled with the name of; and are part of the hCard of; the dead person, not of the grave, just as are the hCard's date of birth property, and such hCards do not use "fn org". The vCard specification, on which hCard is based, has a coordinates property explicitly for the coordinates of an individual. As an aside, it is odd to see you arguing so vociferously for the retention of a microformat, when you argue elsewhere, at the same time, that microformats should not be used on Wikipedia. There is already consensus for the inclusion of such information. As O have already said to you elsewhere today: If you wish to pursue a case against the use of microformats per se, then please do so in the appropriate forum; not here. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:30, 18 September 2008 (UTC)[reply]

Simple: just look at the HTML with Special:ExpandTemplates for example. If the spans are removed, the structure will end up broken and the information without markup. The last available database dump from July 2008 contains 88500 direct uses of coord|...|name=. Significant issues with their use have not been reported. --Para (talk) 18:30, 19 September 2008 (UTC)[reply]

It's not "simple" at all. Merely asserting that "...the structure will end up broken" tells us nothing more than did your previous unqualified assertion. How will it be broken? Will it be invalid? Not render correctly? What? Likewise, what information will be "without markup", and why will that matter? What do those spans do, other than carrying the HTML class names used only by the microformat?

I have reported significant issues with the use of the name parameter in Coord, above and predicted them - correctly - elsewhere, previously. For example,. you use of it on List of Gaudí Buildings means that the first table entry says, nonsensically, to readers with CSS disabled or unavailable that the coordinates of Bellesguard's Tower are "41°24′34″N 2°07′37″E / 41.40944, 2.12694 (Bellesguard's Tower)"; it does not degrade gracefully, as is good practice.

Despite this, I have not asked here for the name parameter to be removed, only for the hCard classes and their containing spans. If the spans are important, for some reason that escapes me, then just the classes can be removed, or renamed, leaving the (empty) spans in situ. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:43, 19 September 2008 (UTC)[reply]

I'm sorry, I should have been more clear, we can't expect everyone to be aware of what microformats are. When this template is used with the name parameter, the HTML ends up with span elements and some very specific class names, linking the coordinates to a descriptive name. Some tools in turn recognise these class names and can use the information as labels on a map. If either the encapsulating elements or the class names are removed, the given names will no longer be associated with the coordinates in the microformat, and the tools that used the microformat cannot find the information, as the only thing they look for are the elements with those very specific class names. I've understood microformats are quite popular indeed with coordinates, and many Wikipedia articles with inline coordinates link directly to a tool that depends on the markup this template creates with the name parameter. It would be a shame to make the descriptive information unavailable to the users of those tools, or to have to start writing the HTML this template creates into article wikitext instead. I hope this helps. --Para (talk) 00:35, 20 September 2008 (UTC)[reply]

So, to be clear, you're referring to the use of those spans/ classes in an hCard microformat only, and for no other purpose? If so, my earlier points apply: the use of a hidden name property in this way, in a microformat is broken, and causes the problems already identified. The spans/ classes should be removed as requested, in order that an hCard "fn" or "fn org" property can be applied to visible data, in a valid and appropriate manner. Your reference to direct links to "a tool that depends on the markup this template creates" seems to be a red herring, as that tool (GeoHack) does not use the spans/ classes to which this request applies. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:38, 20 September 2008 (UTC)[reply]

As far as I know, the additional HTML is there for microformat purposes only and is used by many microformat readers, including the Suda tool. They might even be the reason our users have used the parameter tens of thousands of times. The hiddenness of information visible though not directly adjacent to coordinates has been discussed already among your other concerns. The rest of this discussion can be found from the talk archives of this and another template. Please refer to them to find why your concerns aren't met with actions. The best part was perhaps "I've still seen no citation for any *prohibition* of hidden data in microformats"[3]. By adding the new parameter with its microformat functionality to this template after an RfC, the community agreed. Give it a rest, please. --Para (talk) 23:36, 20 September 2008 (UTC)[reply]

Nothing in what you write addresses the problems I have listed. The "Suda tool" and every other microformat reader will work equally well with Geo microformats with no name parameter; or where the name's class is applied to visible data as part of a more widely-scoped hCard microformat. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:43, 20 September 2008 (UTC)[reply]

There is an issue with broadcast stations in North America: both the FCC (U.S.) and CRTC (Canada) still use NAD27. Displaying these as NAD83/WGS84 causes errors in pinpointing the position of many stations. This is obvious when looking at aerial images of the antenna site, and the marker doesn't even touch the building or tower. It would be nice to have a parameter like "datum=NAD27" to indicate that a conversion should be done.  –radiojon (talk) 22:12, 26 September 2008 (UTC)[reply]

For the links on Template:GeoTemplate to work, the input needs to use the WGS84 datum. There are a few templates at Category:Coordinates conversion templates to convert coordinates to this datum. As {{coord}} doesn't convert, coordinates with another datum shouldn't use it. -- User:Docu

Geohack outputs of coordinates with some other coordinates systems (see Template:GeoTemplate/doc#Position, [4]). If it's helpful to provide coordinates with NAD27 datum for links to websites, you may want write code to enable geohack to provide this. -- User:Docu

Industry Canada recently converted all of its coordinates to the NAD83 datum. --  Denelson83  10:01, 4 November 2008 (UTC)[reply]