Wikipedia talk:WikiProject Geographical coordinates/Archive 15

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

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

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

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.

Coordinates distance approximations:
Decimal	Distance	Seconds	Distance
0.1	608 feet (185 m)	60	101.27 feet (30.87 m)
0.01	61 feet (19 m)	1	20.25 inches (51.4 cm)
0.001	6 feet (1.8 m)	0.1	2.03 inches (5.2 cm)
0.0001	7.3 inches (19 cm)	0.01	.2 inches (0.51 cm)

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

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

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

I'm not aware of any application that commonly uses such data, and so importing it on Wikipedia 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)[reply]

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

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

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

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

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

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 Wikipedia 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 Wikipedia, {{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.

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

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

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

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

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

On the English Wikipedia, 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 Wikipedia {{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)[reply]

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

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


Name	Redirects	vs. Coord	Bytes	Usage	Recommendation
{{Coor d}}		+1	360	{{coor d\|DD\|N/S\|DD\|E/W\|region:_type:\|name=}}	{{coord\|dd\|N/S\|dd\|E/W\|coordinate parameters\|template parameters}}
{{Coor dm}}		+2	391	{{coor dm\|DD\|MM\|N/S\|DD\|MM\|E/W\|}}	{{coord\|dd\|mm\|N/S\|dd\|mm\|E/W\|coordinate parameters\|template parameters}}
{{Coor dms}}		+3	557	{{coor dms\|DD\|MM\|SS\|N/S\|DD\|MM\|SS\|E/W\|}}	{{coord\|dd\|mm\|ss\|N/S\|dd\|mm\|ss\|E/W\|coordinate parameters\|template parameters}}
{{Coor at d}}		-17	629	{{coor at d\|deg\|NS\|deg\|EW\|optional}}	{{coord\|dd\|N/S\|dd\|E/W\|coordinate parameters\|display=inline,title}}
{{Coor at dm}}		-16	670	{{coor at dm\|deg\|min\|NS\|deg\|min\|EW\|optional}}	{{coord\|dd\|mm\|N/S\|dd\|mm\|E/W\|coordinate parameters\|display=inline,title}}
{{Coor at dms}}		-15	895	{{coor at dms\|deg\|min\|sec\|NS\|deg\|min\|sec\|EW\|optional}}	{{coord\|dd\|mm\|ss\|N/S\|dd\|mm\|ss\|E/W\|coordinate parameters\|display=inline,title}}
{{Coor title d}}		-7	285	{{coor title d\|deg\|NS\|deg\|EW\|optional}}	{{coord\|dd\|N/S\|dd\|E/W\|coordinate parameters\|display=title}}
{{Coor title dm}}		-6	309	{{coor title dm\|deg\|min\|NS\|deg\|min\|EW\|optional}}	{{coord\|dd\|mm\|N/S\|dd\|mm\|E/W\|coordinate parameters\|display=title}}
{{Coor title dms}}	{{CoorHeader}}	-5	322	{{coor title dms\|deg\|min\|sec\|NS\|deg\|min\|sec\|EW\|optional}}	{{coord\|dd\|mm\|ss\|N/S\|dd\|mm\|ss\|E/W\|coordinate parameters\|display=title}}
{{Coord}}		0	470	{{coord\|dd\|mm\|ss\|N/S\|dd\|mm\|ss\|E/W\|coordinate parameters\|template parameters}}

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

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

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

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

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^T♦^C 16:27, 25 July 2008 (UTC)[reply]

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

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

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

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