Wikipedia talk:WikiProject Geographical coordinates

From Wikipedia, the free encyclopedia

You have new messages (last change).
To-do list for Wikipedia:WikiProject Geographical coordinates: edit · history · watch · refresh
  • Make mechanism that provides a NASA World Wind layer that provides clickable reverse links into Wikipedia. -- Egil 10:39, 4 Mar 2005 (UTC)
  • Add more (optional) parameters, such as: scale, type, region
  • Make sure the bug wrt. templates as arguments to templates gets fixed, see bugzilla:662 (Not required any longer)
  • Update the documentation on the Meta:Gis extension.
  • Make sure the now external script for "Map sources" can be replaced by an internal mechanism by having the gis extension enabled for Wikipedia.
  • Make sure the gis extension is enabled for Wikipedia, so that the coor template can be replaced by geo markup. (Done by robots).
  • Implement database storage and management of the discovered points in geo extension, and interfaces to make use of this data.
  • Change syntax {{{aa}}} into {aa}, since it conflicts with future development on templates.
  • Fix the E/W bug when entering negative degrees.
  • Support NASA World Wind.
  • Extend NASA World Wind support to include layers (by type) and labels.
  • Support Swiss coordinates.
  • Make better examples, also showing use of decimals and scale.
  • Convert existing data to Template:coor
    • dms: Mountains, data already in templates, rambot
    • dm: mostly done
    • d: tba
    • identify special formats not yet converted, e.g. E12 23 54 N23 34 52
  • Add an attribute for other planets and the moon and probably also star maps.
  • There is a bug in the calculation of {osgb36ref}. The numerical part is correct, but the letters reference the next 100 km square north of the correct one. Eg. Heathrow ends up at y=176570 x=506839, which is correct, but ref=TL0683976570 should be TQ…. Or Catterick has NZ and should be SE. Strangely this one: Middlesboro has NZ which is correct. See OSGB bug below.
  • Candidates for the <geo> tag if/when the gis extensions is enabled for Wikipedia: Template:Infobox british hills Template:infobox Kommune

--Scott Davis Talk 13:33, 7 August 2006 (UTC)

Contents

[edit] Format for display

Restating things I mentioned on the Manual of Style talk page, and more

[edit] Conversion

Q: I was given the following coordinates ( X: 1.019.760, Y: 1.041.109 ) and have no idea how to convert them to Grades, minutes and seconds. Does any body know?

[edit] spacing issues

One of your stated goals is more uniformity in the representation—but we need to decide what that uniform representation should be. For example, should there be any spaces at all within the numbers? Both ways are used. NIST, in explaining that this is an exception to the rule that there is a space between a number and its symbol, closes up all the spaces its example "α = 32°22′8″" http://physics.nist.gov/Pubs/SP811/sec07.html

  • This rule has the advantage of being nonbreaking on the primes—though as I have seen with temperatures, the degree sign is not nonbreaking. If you do use spaces, it should be nonbreaking spaces between the degrees and minutes and between minutes and seconds.

I prefer the closed-up representation, with spaces between the number and the directional indicators and between latitude and longitude:

  • 12°02′36″ S 177°01′42″ W

Gene Nygaard 12:04, 14 Feb 2005 (UTC)

I begun using no spaces, but found that at least on my screen the symbol and the next digit came so close that they were touching. Not pretty. I switched to &nbsp; which looks better on my screen, FWIW. The ideal thing would be a non-breaking half-space. Is there such an animal? The break point is between the latitude and the longitude, which I think is as it should be. -- Egil 12:14, 14 Feb 2005 (UTC)

PS: My only idea would be to use a small nbsp, as in the 2nd example below:

  1. 12° 32′ 06″ S 177° 01′ 22″ W
  2. 12° 32′ 06″ S 177° 01′ 22″ W
  3. 12°32′06″ S 177°01′22″ W

Did I mention that #3 looks awful with my font. Probably did. -- Egil 13:16, 14 Feb 2005 (UTC)

FYI I've placed a screen shot of how the above section looks in my Firefox here. -- Egil 19:07, 14 Feb 2005 (UTC)

Sorry, but I prefer the unspaced version, too, particularly if the implementation is going to be an underlinked click-through rather than the [n] external link mark: unspaced would be a lot less obtrusive on the page. Thus: 12°02'36" S 177°01'42" W -- maybe using apostrophes and quotation marks instead of proper sloping primes would help your display issues, or is suggesting that heretical?
I've just checked my Chicago Manual of Style, which seems to prefer the unspaced version and, incidentally, includes a comma after the N/S (so: 12°02'36" S, 177°01'42" W) -- something I always put in in coordinates I type manually. Or is that a layman vs. specialist thing? –Hajor 02:53, 15 Feb 2005 (UTC)
The apostrophe and quotation mark suggestion sounds quite reasonable to me, even though I have several times in the past changed them to primes (in conjunction with other editing, not just for the sake of doing so). Gene Nygaard 07:49, 15 Feb 2005 (UTC)

If you see here you'll notice on my screen for #3 the degree and ticks touch the next digit. That I think is outright ugly. Anyway, this is no hurry, and does not need to be decided now, since this policy issue on formatting can be easily enforced in Template:coor dms et al at any point. My suggestion is leaving it as #2 for a while, and try to reach an agreement when we have more experience. -- Egil 09:21, 15 Feb 2005 (UTC)

The above shows how the coordinates of North Cape, Norway and Knivskjellodden are rendered on my screen, magnified 4X, when there are no blanks. Note how the prime is glued to the digits 2 and 6, and is also too close to the 5 (the combination with the 4 looks OK here, but not so good in 1X). I can assure that this is as bad as it looks in 1X also, bordering to the unreadable (as well as being ugly). Note also how the degree sign is closer to the following digit, which also looks unbalanced. For other digits then shown here, the degree sign touches the following digit. -- Egil 16:39, 15 Feb 2005 (UTC)

So show us how the same numbers look, blown up the same way, using Hajor's suggestion (75°10'21" N 25°47'54" E). Then, for comparison purposes, show us how much uglier the extra spaces (using the prime and double prime) look when they are blown up the same way as well. Gene Nygaard 20:45, 15 Feb 2005 (UTC)

Done (I have changed the example to make it more worst case). Hajor's suggestion renders exactly like #3. Note how the symbols touch the next character. This is unacceptable. I believe #2 to be the best variation so far, leaving sufficient air around the symbols, while not as wide as the space used between words. (Ideally, that space could have been a pixel narrower) -- Egil 08:04, 16 Feb 2005 (UTC)

But if you make your actual display font larger, rather than these blown-up pictures of a small font, even if it is only half the size of these picture displays
  1. the primes and the apostrophes and quotation marks are distinguished (and primes look better)
  2. the symbols do not run into the characters, either way
There are lots of other uglinesses associated with the use of small, sans serif fonts as well; I'm not sure if we need to avoid all of them (e.g., ν v for nu and vee, Illinois). Gene Nygaard 13:46, 16 Feb 2005 (UTC)

I notice the issue of spaces and widths thereof is also discussed on Wikipedia_talk:Manual_of_Style_(dates_and_numbers)#20m_or_20_m.2C_etc.

That particular discussion isn't really relevant to the discussion at hand; the rules are separate for these which are actually one number with its first and second sexagesimal fractions. Gene Nygaard 20:45, 15 Feb 2005 (UTC)
It is relevant, because it discusses various ways of achieving narrow, unpaddable spaces. (And yes, I was thought to write 20m, not 20 m. But I've learned to accept the space, as long as it is unpaddable.) -- Egil 06:46, 16 Feb 2005 (UTC)
Yes, that is relevant. I have never worried much about the fact that Wikipedia allows a justified paragraphs option, and don't know for sure how it works. I've never even thought about a non-breaking space as also a "non-padding space". Most good justification algorithms include some spacing within the "words" as well as between words, don't they? But that usually doesn't get to be as extreme as the inter-word spacing can.
One thing that discussion does show is that the options are all work-arounds. Gene Nygaard 13:46, 16 Feb 2005 (UTC)
(Sorry if this has already been concluded) There are a few different spaces available. All shown between a prime and a zero:
  1. ′0 - no space at all (yes the prime is there)
  2. ′ 0 - an ordinary space
  3. ′ 0 - a non-breaking space
  4. ′ 0 - en space U+2002 = #8194
  5. ′ 0 - em space U+2003 = #8195
  6. ′ 0 - thin space U+2009 = #8201
For me, ordinary or non-breaking space are the same, and the narrowest of the spaces, and look better than no space or any other size. --ScottDavis 04:54, 19 Mar 2005 (UTC)

In case anyone cares, below is what it looks like on my Mac, in Safari. As you can see, there's no problem making out all the glyphs. But I dislike the format without any spaces, because it looks like a long random alphanumeric string—you have to stop and think to parse it out.

With even a bit of space, it intuitively reads as words "twelve degrees, thirty-two minutes, six seconds, south...". I would also prefer to have the comma between latitude & longitude. —Michael Z. 2005-03-29 22:37 Z

Image:Four-x-mac.png


[edit] March 21 revision of Template:Coor dms

Template:Coor dms now includes a &nbsp; between the numbers. In infoboxes and, e.g. on Shorewood-Tower_Hills-Harbert, Michigan this can take up a lot of space. Further, it appears that the &nbsp; isn't rendered if the template is part of a wiki-| table (It works with wiki-<td> tables). To save space, I'd be in favor of returning to the previous format. -- User:Docu

[edit] padding with zeros

You, in your examples, padded zeros in your entry for the minutes and seconds. But that is not a feature of the template, at least not yet. You also did not pad a second zero in the longitude degrees. Gene Nygaard 12:04, 14 Feb 2005 (UTC)

As it is now, padding of zeros is accepted (there was a bug which is now gone), and the padding will appear just as in the template arguments. With todays template mechanism, I think there is no other way. -- Egil 12:16, 14 Feb 2005 (UTC)

[edit] links page

Forget about the format of the coordinates, let's talk about the link. I clicked on the coordinates at the Winnipeg, Manitoba article, and it took me to a confusing page that gave me a list of unessecary options including finding the location in Norway, United States, and the United Kingdom, despite the fact that Winnipeg is in none of those countries. This page should only have links to global maps... or better: clicking on the coordinates always takes you to the same maps site. --Munchkinguy 23:17, 22 Mar 2005 (UTC)

As the coordinate at Manitoba already has "region:CA" set, you may have the link call a subpage http://kvaleberg.com/wiki/index.php/Wiki:Map_sources/CA which would only give links relevant to Canada. There is already a similar subpage "US" at http://kvaleberg.com/wiki/index.php/Wiki:Map_sources/US -- User:Docu
The US subpage works, but the Canada subpage doesn't. It has links to maps of Norway and Switzerland. I will try to edit this template. --Munchkinguy 15:44, 23 Mar 2005 (UTC)

[edit] Error checking on entry

Is there any way the template can do some error checking of range of numbers, as well as convert them from text to numbers to aid in making consistent padding of the numbers?

I'd like to see something like the "Did not parse" errors in TEX entry. Gene Nygaard 12:04, 14 Feb 2005 (UTC)

No error checking yet, this should of course be implemented at some stage. -- Egil 12:21, 14 Feb 2005 (UTC)
Done. -- Egil 16:52, 15 Feb 2005 (UTC)

[edit] Error in off-Wikipedia map sources page

You have your minutes and seconds symbols reversed. Gene Nygaard 12:04, 14 Feb 2005 (UTC)

The source text for this is in fact on Wikipedia, so anyone can edit on Wikipedia:Map sources. What is off Wikipedia is the script. -- Egil 12:20, 14 Feb 2005 (UTC)
Comment: In the next PHP off-site implementation now being used, the page is off-site, but still editable. Follow the map sources link. -- Egil 16:48, 15 Feb 2005 (UTC)

[edit] Format for markup entry

The current quarter hemisphere thing was simply a hack out of necessity in the inital implementation (with no script, just doing Mapquest). This is no longer required, so we can design a better template. I do believe that the formatting for the article itself should be done via the template alone, though.

Perhaps the following syntax is more suitable:

   {{coor dms|48|46|36.48|N|121|48|51.84|W|}}

Which becomes: 48°46′36.48″N, 121°48′51.84″W

With the current template mechanism, the dms is needed, because there is no conditional mechanism in the templates.

I have allowed for yet another argument, which is an optional map scale. This will of course not appear in the article, but is a useful parameter for many map resources (so that the initial map view shows the entiry country, island or whatever).

Comments invited. -- Egil 13:03, 14 Feb 2005 (UTC)

I think this entry method is preferable, and it'll make converting existing lat&long entries in the articles somewhat easier. I say go for it! (before it's too late and we go too far down the road with the other format.) Scaling, too, will be a great boost to the functionality: either here, or on the linked-to gateway page. Oh -- and please add the missing comma after "N", too, or am I the only one obsessing about that? –Hajor 01:15, 18 Feb 2005 (UTC)
If one wants to add a comma after the N, this should be done in the representation as implemented in the templates, Template:coor dms for instance. That said, use of a comma is not very common. -- Egil 08:41, 18 Feb 2005 (UTC)
{{coor dms|48|46|36.48|N|121|48|51.84|W|}}
why not {{coor dms|484636.48N|1214851.84W|}}
or {{coor dms|N484636.48|W1214851.84|}}
this way everybody can take the precision he wants e.g.
        {{coor dms|N48|W121}}
adding more numbers, making it more precise, leading Zeros in this concept are partialy necessary then.
BTW, you know: http://geo.sourceforge.net/Atlas/ ? best regards and good luck with the project Tobias Conradi 22:05, 8 Mar 2005 (UTC)

[edit] Chinasaur's suggestions

Great to see someone finally scripting this! I really look forward to seeing this incorporated into MW. One thing I wonder is how you envision this working in conjunction with the templates I have been working on (geolinks-US-streetscale etc.). I can imagine your stuff replacing the old system entirely. On the otherhand, geolinks may be a good way to provide more selective "suggested links" that are a little less promiscuous than the link page you are providing. Something to think about.

For the time being, let's try to coordinate (no pun intended). The geolinks templates have been added to RamMan's automatic city updates, so I assume they are pretty well accepted. If/when we ultimately switch over to your style templates we can hopefully get the city bot to help with that too.

There is no reson why these things cannot coexist. I added a small link to other maps in the georef streetscale template to show one way. -- Egil 08:41, 18 Feb 2005 (UTC)

[edit] Dealing with scale

I was just going to suggest a scale argument but I see you're working on it. Implementing this is going to be tricky though. Perhaps you would consider the model we have used for geolinks: "cityscale", "buildingscale", etc. The named scales is (I hope) an easier way for editors to remember what size they really want. The tricky part of course is translating this into the right "zoom" arguments for any particular web page; as you know they mostly use their own specific formats (i.e. zoom=5 on mapquest means something totally different from s=5 on terraserver). One thing that I think would work would be to use a "cityscale" style argument to your script as a string for another template name.

I'm not sure if I can explain this clearly off the cuff, but here goes: imagine I pass in "city" as the final argument to one of your templates. This then becomes the value for {{{scale}}} on your special page. You then link to mapquest using (psuedocode):

mapquest.com/?lat={{{lat}}}&lon={{{lon}}}&zoom={{mqscale-{{{scale}}}}}

and to terraserver using (psuedocode):

terraserver.com/?lat={{{lat}}}&lon={{{lon}}}&zoom={{tsscale-{{{scale}}}}}

I believe this should work and result in the template {{mqscale-city}} and {{tsscale-city}} being loaded in as the scale arguments. My mind gets kind of boggled trying to remember MW's rules for loading templates but for an off-the-cuff trial see User:Chinasaur/Sandbox. Here I've used PAGENAME as a standin for your special variables since I believe they behave in similar ways. As you can see, the code correctly requests a template whose name depends on the value of PAGENAME. This approach will cause a proliferation of templates for all the different scales (city, county, building, street, hood, or whatever you decide on) and for all the different webpages, but I think that's okay, and this way it's transparent to editors and easily tweakable.

The intention was to base everything on a scale, and make the script supply scale factors as required for different URLs. (One thought: It should probably be allowed to enter 1e6 in addition to 1000000) Currently, the following is available:
{{{scale}}} which is the scale as a decimal number
{{{altitude}}} which is the altitude equivalent that MSN uses (143 for 1:1000000)
{{{zoom}}} which is the equivalent zoom factor for Mapquest
{{{span}}} suitable for Google and US Census (needs calibration)
I'm sure there are other quirky ways of defining scale, but hopefully they can be accomodated. Multimap uses a scale, but it has to be from a fixed list of about 10 different ones. A mechanism for that needs to be implemented.
So hopefully the countryscale/cityscale/buildingscale concept can be implemented in form of supplying a default scale? -- Egil 08:41, 18 Feb 2005 (UTC)
A lot of my suggestions were from the mindset of trying not to hard-code things. Your approach of using a single scale in the template and then having that generate a bunch of different scale parameters for different web sites is a natural solution. But what do you do if an editor wants to add a new map page with a new scale parameter? I went through all these template gymnastics with the idea that we wanted a system that is open to multiple editors; it's clearly undesireable to require a system patch to add new variables of these types. You don't want people to have to come to you anytime they want to change things... --Chinasaur 08:04, 4 Mar 2005 (UTC)
Hardcoded parameters for various map sources is defintely something I would want to avoid. If Wikipedia maprkup gets expression evaluation that could fix a lot of things, otherwise I can always make various configurable scaling parameters in the Map sources. In due course. -- Egil 21:04, 5 Mar 2005 (UTC)

[edit] Country filtering

My only other suggestion for now is that you could use the script to filter what country is being looked up. Since so many resources only work for US locations, it would be nice if the script first determined if the coordinates were US, then forwards you to an appropriate page within your demo server. For non-US locations, the script forwards you to a similar site without the US links. I'm not sure how the loading between the editable links page and the special page with the variable substitutions works, but I'm guessing that it would be possible to set this up so that all the US links are in a separate template that is just called from the US specific special page. This way it is transparent to editors who want to add US specific links. In fact, this way you could avoid creating more than one special page by having the script initialize the argument {{{country-specific-template-name}}} to the special page according to its parsing of the coordinates and then have the universal special page call that template ({{{{{country-specific-template-name}}}}}). This is assuming that the double substitution discussed above does indeed work. If this mechanism worked, you could use it to generate country specific links for as many countries as you have time to delineate coordinate rules for.

Anyway, as you can see, I'm full of enthusiasm for your work and also full of (hopefully useful) suggestions. I feel like this format is not the easiest way to bounce ideas off each other. If you're open to the idea, maybe we should get in touch by email or phone. Let me know on my talk page if this is cool and we'll work something out. Also I can help out with coding if (AND ONLY IF!) I get a little more time in the next few months. I'm a reasonable php hacker (I assume this is all php?). Nice work! --Chinasaur 00:32, 18 Feb 2005 (UTC)

P.S., you might be interested in my stillborn wikibook Wikibooks:GET--Chinasaur

Cool. You can probably find some material from the current Map sources already. Some sites, like MSN, are in fact helpful enough to supply information about their format. -- Egil 08:41, 18 Feb 2005 (UTC)

P.P.S., what about a variable for labeling markers where appropriate (e.g. for the tigermaps US census sites). You probably don't want to add more baggage to the editor end of the templates. What about adding PAGENAME into the templates though? After parsing with the script (to take off disambiguation in parens, etc.), this would probably work well for a {{{mlabel}}} variable!--Chinasaur

Interesting thougths. My idea was to include some mechanism for filtering based on pure location (range of lat/longitude, range of UTM zone or similar), so that for a location within the US, none of the resources unique to Europe et al would appear. It should also be possible to pipe other type of parameters through the map mechanism too. Of course, the implementation of such a mechansim should not be done purely for the map sources, it should be Wikipedia-wide for conditional inclusion of text — a mechanism sorely needed for the templates also.
An alternative, and simpler, mechanism would be to allow the map source mechanism to specify the name of the map page. So instead of using the default Wikipedia:Map_sources, you could always have Wikipedia:US_Map_sources etc.
Talking of altenatives, it would of couse be an alternative to implement the entire coordinate transformation based on a template instead of a Special page. In practical code development, the nice thing about the Special page is that it is very isolated from anything else. -- Egil 08:41, 18 Feb 2005 (UTC)

[edit] NASA Worldwind

Any chance of having automatic generation of NASA Worldwind links?

(They are of the form: worldwind://goto/world=Earth&lat=52.61664&lon=-1.39980&view=0.00739 )

It's now open source (they have their own wiki here).

Plus it seems reasonable to support it, since its landmark links currently link to Wikipedia. --cfp 21:41, 28 Feb 2005 (UTC)

I tried to add to the kvaleberg.com wiki, but didn't have a great deal of success. Wikipedia only seems to recognise links which start "http://". e.g. Find this location doesn't work. Below is what I added. If you can tell me a better way of doing it, I'd appreciate it:
=== Requiring special software ===

*[worldwind://goto/world=Earth&lat={{{latdegdec}}}&lon={{{londegdec}}}&view={{{span}}} Find this location] with [http://worldwind.arc.nasa.gov/ NASA World Wind].

Perhaps this is just a bad idea. --cfp 22:24, 28 Feb 2005 (UTC)
What about using a redirector PHP script? I just tested that HTTP redirect to worldwind:// URI works in Firefox. The code itself is simple:
<?

header("302 Redirect"); header("Location: worldwind://goto/world=Earth&lat=$LAT&lon=$LON&view=0.008"); ?> NASA WorldWind redirect. Requires <a href="http://worldwind.arc.nasa.gov/">WorldWind</a>

The disadvantage is that it stays open. But it could be opened in a new window and contain javascript to close itself immediately.
Could be rewritten to automatically parse several possible input formats: N/S E/W notation vs signed coordinates, decimal vs deg-min-sec, etc.
Similar code that produces a snippet of XML instead, and serves it as "Content-type: application/keyhole", can be used for output of KML files for Google Earth. What output will be produced could even be configurable by the user, or both links could be provided.--Shaddack 23:51, 17 July 2005 (UTC)


[edit] Brilliant...

Seems like a really brilliant idea if you ask me, just needs some thought and consideration when implementing. I'm sure there are ways around the http: thing, for those who have Worldwind installed locally. For those who have not, do you know if there are any public servers where this can be accessed? -- Egil 08:16, 1 Mar 2005 (UTC)

Worldwind itself connects to public servers to get its data, i.e. Landstat7, USGS, MODIS, SVS, WMS, Blue Marble. Its unique feature is combining all of them in a pretty (3D) format. You can zoom from seeing an entire globe, to seeing individual houses (at least in the US, everywhere else the resolution's a bit worse). I don't think there are any public servers running the software itself. It would require a server with 3D graphics abilities doing the equivalent of generating screenshots with the program. The code is open source, so perhaps it's doable, but I think it would be a major undertaking. (And not one for the Wikimedia developers really.) Should we ask a dev/committee member about enabling worldwind:// links? --cfp 17:33, 1 Mar 2005 (UTC)
No need. I have now enabled worldwind: on the demo Wiki, so that the above thing should work. I've placed it at the end of the page, so you can try it out, now. I will include the support for worldwind: in the patch that I will provide for the Wiki software. -- Egil 18:29, 1 Mar 2005 (UTC)
Yup works fine. Thanks, my two internet addictions are now united! To give an indication of whether scale's working, the Heathrow link leads to Heathrow's main runway being about one screen across. The top Oslo link goes south east as far as Arjangs Commun and north west as far as Buskerud Fylke. The bottom Oslo link leads to Sandvika being about 25% in from the right, and Ekeberg being about the same amount in from the left. --cfp 18:42, 1 Mar 2005 (UTC)
check out [1] on how to add new URL types, like [2]. NevilleDNZ 03:12, 7 Jun 2005 (UTC)

[edit] From World Wind to Wikipedia

I am working on incorporating a World Wind layer that provides clickable reverse links into Wikipedia. It seems to work real nice so far, but I need to spend more time on the automation process that extracts the coordinates from Wikipedia. -- Egil 10:37, 4 Mar 2005 (UTC)

Good idea. Best of luck. --cfp 20:15, 4 Mar 2005 (UTC)
There is a demo Wikipedia layer for NASA World Wind available via http://wiki.worldwindcentral.com/Wikipedia if anyone are interested. Any feedback would be appreciated! -- Egil 09:46, 5 Mar 2005 (UTC)

[edit] Swiss grid?

Swiss maps generally use the Swiss coordinate system. It would be nice if there was a way to use them as output or possibly as input. On the other hand, sites such as http://www.swissinfo-geo.org and http://map.search.ch don't appear to support direct links with coordinates. -- User:Docu

Do you have further information about these coordinates? Seems like some sort of transverse Mercator; swissinfo gives coordinates Easting 600500 Northing 199500 for Bern, located at 46°57′N 7°25′E. The UTM for this location is Northing 5200824 Easting 379514 Zone 32T. For the map.search.ch one I couldn't find any. If you can please find more information, ideally also on how to navigate directly, I would be happy to implement.-- Egil 08:25, 1 Mar 2005 (UTC)
PS: I found some info on http://www.geocities.com/CapeCanaveral/1224/prj/ch/ch1903.html about CH1903 which seems to be what is being used (centered around an observatory in Bern, no less!). I have to investigate what Oblique Mercator is, but if you can find how to make direct links, I'll supply the coordinates. :-) Egil 08:54, 1 Mar 2005 (UTC)
There is an article from Swisstopo at [3] in German and French (see PDF), and one in German Wikipedia. The old observatory's coordinates can be found at Bern#Geography. Converters are at [4], [5], [6], though you already implemented it. Great!
At first glance I thought TeleAtlas/Endoxon at http://map.search.ch did include coordinates in the displayed source, but they appear to be available only offline ([7]). Linking doesn't apppear possible at http://www.swissgeo.ch either. -- User:Docu
There is now a draft at Swiss coordinate system, it could probably use a re-write by a specialist editor. -- User:Docu
Looks excellent if you ask me (not that I am an expert). I tried to look at the possibility of direct linking the Swiss maps, but it seems they use some sort of 5 minute sessions for the URLs designed to make it impossible. -- Egil 19:03, 13 Mar 2005 (UTC)
Thanks. For now, a possible way I came up with to link to a local map is to add [http://map.search.ch/{{PAGENAME}}] to {{switzerland-geo-stub}}, which can give unspectacular links like Bern. To search by coordinates, I suppose one would need to simulate a GPS input for local software. -- User:Docu
(Finally) The following URL should work:
http://gis.swissinfo.org/swissinfo-geo/neapoljs_ENGLISH.htm?Resolution=small&KOORDX= {ch1903northing}&KOORDY={ch1903easting}&markx={ch1903northing}&marky={ch1903easting}&ZOOM=5
The optional "marky" part creates a green marker. Thank you for making this possible. -- User:Docu
This is now in the map sources. I also made a page region:CH which lists this entry first. (You mixed nothing and easting, otherwise it was ok). -- Egil 17:34, 23 Mar 2005 (UTC)
Thanks, even a special page! Now I only need to find a way to import the coordinates (and possibly more) from de:Template:Places in Switzerland). -- User:Docu

[edit] Swiss grid as input

I'm referring on user Docu's first comment. Because all small scale maps of Switzerland are in CH1903 datum, we'd like to use them as input for the geo tag, see german proposal. For OSGB36 I saw conversion is implemented. Is this also the case for CH1903? We would be very glad not having to convert the coordinates to WGS84 manually anymore. Thanks in advance --Ikiwaner 12:00, 18 August 2005 (UTC)

I did at one point implement input in a few coordinate systems other than WGS84, but I then decided against it. For a number of reasons: one being lack of time (which is really sufficient), one other being that it would complicate systems extracting georef meta-data from the Wikipedia articles (like measuring great cicle distances), and it complicated support of a georef database. It is bad enough to support the various formats for output. Converting input data to WGS84 should be quite easy, and it needs to be done only once for each point. I do believe there are various Swiss online maps that support online conversion to WGS84. -- Egil 16:23, 22 August 2005 (UTC)
I see that it takes quite some time to implement such functions and makes db-queries more complicated. Converting coordinates is not easy at all especially for non mathematicians. At the moment there is an error of about 150m in northing and 80m in easting in your conversion, and we don't know whether this is systematic or just a trunctation error. There are NO exact maps with WGS84 in Switzerland. How sould the average user be able to do a correct and accurate conversion? Slightly disappointed --Ikiwaner 19:04, 23 August 2005 (UTC)
It would seems that the Swiss map services are lacking the feature of providing WGS84 coordinates. But look at http://www.tandt.be/wis/ for help. Wrt. the error in CH1903, yes I am aware of it, but I simply haven't had time to investigate. Every country seems to have had their own coordinate system, and they are different in many subtle respects. The source code is available, see meta:Gis, so I would appreciate if you could investigate. -- Egil 06:19, 24 August 2005 (UTC)

[edit] Plowboylifestyle's Stuff

[edit] Search Mechanisms, Finding Articles based on Geography

Egil, is it possible that eventually, the template:coor could be modified to access an a mediawiki extension instead of just formating the coordinate and making it a link to a special page? It seems like this might be problematic (see m:Talk:Write your own MediaWiki extension) --Plowboylifestyle 05:41, 11 Mar 2005 (UTC)

Good point. Not expanding the template arguments within the extensions seems to me like a mis-feature that should be attended to. -- Egil 06:47, 11 Mar 2005 (UTC)
Apparently this is not a misfeature, I found out it has to work this way, since wikimarkup stops inside of <tags>. If it didn't then template syntax would for example be confused with TeX, syntax.
Yes in addition I'm not sure that MediaWiki supports "edit-side" extensions which make things things difficult. I'm going to go out on a limb and suggest that templates might not be the best way to implement geographic coordinates, if you want to eventually move from just a standardization of format to something more powerful. Here is my reasoning: As far as I can tell template processing occurs on the "display-side" (meaning rendering side) of the media wiki. In other words when you edit a page with a template, the original unexpanded template text is added to the text in the database. The template is not expanded until the page is rendered to html. This means if you would like to do anything useful on the edit-side, like cataloging geographical coordinates as they are entered into the database, you have to first expand the template text. So in musing on this subject I realized that templates add an additional barrier. Using a mediawiki extension for geographic coordinates (i.e. <geo> coor|48_46_36.48_N_121_48_51.84_W|Special:Mapsources/48_46_36.48_N_121_48_51.84_W </geo> would simplify things later on, though implementing it now would mean convincing mediawiki developers to add an extension to the existing site. I hope this makes sense. --Plowboylifestyle 05:49, 12 Mar 2005 (UTC)
You are raising very important issues. The subject of geographical coordinates has become more inclusive then first anticipated, and building and maintaining the reverse database is the remaining one big issue that must be solved first. (Currently I am just doing a simple scan with a Perl script to generate points. This certainly has to happen internally, and kept in the SQL database.) I am working with Magnus Manske so see what we can come up with.
One very real advantage of using templates at this stage is that it is easy having a robot go through and modify current usage if a change is necessary. Plus, it allows is to get experience and learn now. Waiting for a change in the official Wikimedia software before getting a change to build enough data to get the experience on how it ought to have been sounds like a non-starter. -- Egil 18:42, 13 Mar 2005 (UTC)
Perhaps the solution is to move a bunch of articles about a specific area, like a city, to your server. Then implement the extensions however you want and show it to other developers. They are often very resistent as their priorities are not on new functionality but on bugs, performance and security, at least for the next realease of Mediawiki. There is a new hook in 1.4 called the 'ArticleSave' hook that would allow an extension to be called when a page is saved. (Unfortunately templates complicate its use.) it makes it possible to parse for coordinates and put them into a database, on-save. Unfortunately if you use templates its complicated because they are only expanded on render. --Plowboylifestyle 21:01, 13 Mar 2005 (UTC)

Does ArticleSave give you the article in the before and after forms? ( I believe that is needed, because you should also be allowed to remove coordinates from articles). Wrt storage in a database and orgainization in a database, I don't think that should be a problem.

Templates needs to be considered whataver the solution, because one of the major applications of coordinates in articles will be via infoboxes. This must be supported. I will investigate the extension mechanism also. Some of the requirements are:

  1. It must be possible to supply it as an argument to an infobox style template.
  2. It must produce standard markup when used stand-alone, including link-through to the special map sources page.
  3. It must also be possible to hide the actual markup of the coordinates, and have either nothing appear, of a link to the map sources with a different text. This may perhaps be handled via a template.

Switching to extensions would imply converting existing coor templates (quite managable via a robot), but also converting existing coordinates in the US articles to this template. This conversion needs to happen after the extension has been installed in the English Wikipedia, of course. -- Egil 09:03, 14 Mar 2005 (UTC)

I agree we need to use both, but this seems extremely problematic. I talked to a few developers about this on #mediawiki and got some fairly condescending responses. Its sort of a chicken in the egg thing, you cannot pass template parameters to an extension but you can't make effective templates without using extensions. I've started a proposal on my meta userpage about how to use extensions to manage geocoordinates. I'm still trying to decide how I feel about templates, the mediawiki is not really designed to use them for anything beyond standard messages. Read here. --Plowboylifestyle 12:07, 14 Mar 2005 (UTC)

I've played with your extension idea, and I think I've got some quite promising results. It seems like there is a concept there that will also work very well together with infobox templates and such - it will in fact work significantly better than the current approach due to the current limitations wrt. templates as arguments for templates. The only real disadvantage I can see right now is that one cannot control the resulting appearance from within Wiki - although some would claim that is an advantage ;-).
I will see what I can do about the storage bit. If you have more info on the ArticleSave hook, that would be appreciated. For the database solution (including sorting out the neighbourhoods) I do believe I have a concept, but I just din't have the time to write more now (non-Wikipedia things needs to be done also). -- Egil 13:42, 14 Mar 2005 (UTC)
I have now implemented the ArticleSave hook, and it most certainly seems to be exactly what is needed. I have not implemented the actual SQL storage yet, but all required information is certainly available. I will also soon rewrite the special page into an extension page, so that all of this is via extensions. -- Egil 18:19, 14 Mar 2005 (UTC)
Using templates shouldn't be a problem unless the template needs to send individual parameters to the extension so if you are sending an extension to a template it should work but doesn't. See {{catmore <math>\sum_{x=2}^{6} x^{2} = 2^{2}</math>}} == {{catmore \sum_{x=2}^{6} x^{2} = 2^{2}}} that is the real barrier no? --Plowboylifestyle 20:15, 14 Mar 2005 (UTC)

[edit] Map Markup/Projecting Geographic Points onto Images

PHP includes a image manipulation library called GD. I'm pretty sure that PHP includes this library by default and the code is very straightforward, I'm guessing wikipedia servers already have the capability and maybe already use it for math rendering(does anyone know how math is rendered to PNG?) I'm guessing that projecting points onto a image of a map could be done in a couple hundred lines of code.

The process works like this:

  1. The rendering script encounters a map tag, the tag includes:
    1. A references to a Wikipedia image (the image of course depicts a map.)
    2. A set of geo-point to pixel relations that define the map space.
    3. A set of projected geo-points to text relations (the text can include any wikimarkup).
  2. The script calculates the pixel equivalents of the projected geo-points and stores a list of pixel to text relations (clipped to the map, error text should be generated if a point is not on the map.)
  3. The script generates an image where numbers are overlayed at the correct points on the map.
  4. The script generates a text key, showing the text corresponding to each numbered point.

Ideally there will also need to be some kind of caching routines so that the image only needs to be rendered the first time it is accessed after the map tag has been altered otherwise we can default to the last rendered image and save cycles. (I don't know how to do this yet.)

My assumption is that by defining three or more points on the map surface to define the map space, I can approximate the projection well enough for most maps, and this is an easy way for an editor to define a map image. Options for more detailed information about the projection will eventually be added to the map tag.

Later a special search page will essentially generate a map tag and perhaps find an appropriate map image. --Plowboylifestyle 03:36, 11 Mar 2005 (UTC)

[edit] Limitations and extensions

(adapted)

  • The map services which are not available for the location concerned are also listed (but where each is available is indicated)
  • While for worldwide map services the largest available scale often depends on the country (MSN World Atlas being a notable exception), this is not taken into account when converting the scale parameter: the result may be a map link that does not directly produce a map, and also there is no indication what the largest scale is that is available for the location.

For providing an overview of the map services which are available for the location, with for each an overview of available zoom levels, for various sets of countries a template can be made, e.g. Template:Mapeu for Europe and Template:Maplr for countries like e.g. Morocco; alternatively there is a separate template for each scale, e.g. Template:Geolinks-US-streetscale.

For presenting these sets of links there are two possibilities:

  • they are put in the article; this is suitable in cases where the map links are important enough to have direct links to all maps on the page itself, even though this requires more space. The links could be in a separate map section. If the set of links is written in a compact form, as done in Template:Mapeuc, a list of locations (e.g. a list of cities in a country) could have a set of links for each location.
  • for each location a separate map sources page is made, and in the article a link to this page is provided; this is more suitable if in a text the set of links is provided for several locations, and all these links, even in compact form, would disturb the lay-out of the text; unfortunately, when linking to a template instead of embedding it, transfer of parameters is not possible, therefore the page can not be made on the fly; an example is Template:Leiden maps; it could also be put in the main namespace.

In both cases the general template is called (in the article or in the separate page, respectively), and possibly comments on the maps are added.

Alternatively "subst" is used, e.g. with {{subst:mapeu|52.16|4.49|Leiden}}; this allows comments within the template content. However, it may be wise not to apply subst to templates that call external URLs directly, in order not to have to change many links when the format of the URLs change. A version of mapeu etc. could be used where each map link is a template call.

In the case of a separate page, a link to the article is added if that is not in the template using a parameter

A page can then use {{Leiden maps}}, but also just a link [[Template:Leiden maps|Leiden maps]] giving Leiden maps; in the case that the main namespace is used, these are {{:Leiden maps}} and [[Leiden maps]], respectively.

Patrick, Mar 2005

A remark to the above: Using subst: IMHO very much defeats many of the good things about using templates. Using subst: for anything connected to the Template:coor is a definitive no-no. (There will be crucial changes to those templates in the future). -- Egil 09:19, 8 Mar 2005 (UTC)
I suppose you mean that you do not recommend using subst:coor, and that you mean there will be internal changes in coor without changing the name or parameters? Applying subst to a template using coor does not give more problems with changes in coor than using coor directly, as recommended.--Patrick 14:17, 8 Mar 2005 (UTC)
The plan is that all changes are supposed to be internal. When the map sources special page is moved to within Wikipedia, the coor template will change. But there will also soon be need for additional data, like for instance a category. If you have a general template for cities, it is very easy to add this just in that one template. But if the template is substituted, it is not, and your cities will end up as uncategorized.
Note that adding or deleting a category tag in a template does not add or delete the listings on the category page of pages that use the template, until some edit is made in the page that uses the template. Thus, if you plan to add a category tag, do it as soon as possible.--Patrick 15:52, 8 Mar 2005 (UTC)
Ah. Not a WIkipedia category, but a geograpical coordinate category (city/mountain/country/etc). Which is something else. Seems like there is a good reason to use another term, so as to avoid confusion. -- Egil 22:25, 8 Mar 2005 (UTC)
Ah, I see.--Patrick 23:05, 8 Mar 2005 (UTC)


[edit] Reformatting existing coordinates

Shall we start with the conversion of existing coordinates? After adding several manually, I gave it a try with D6 at some of the geography articles (Atlantic Ocean, Geography of Angola, of Australia, of Egypt, of Equatorial Guinea, of Eritrea etc). The format for all should probably be Template:Coor dm rather than Template:Coor d (easy to change). Ideally the conversion might also include a scale. The default might not be ideal. -- User:Docu

Good idea. I believe though, that the current concept may need to be developed a bit more before doing this on a massive scale (to the degree we are talking about massive scale here).
With the wider application of the coordinates in mind (like incorporation in Wikimaps, NASA World Wind, and future concepts for finding neighboring articles) I feel (others may of course have different opinions) that the current concept needs to be developed in two areas:
  1. Making sure every point is properly classified by type (e.g. city, landmark, airport, etc).
  2. Making sure there is a good mechanism for maintaining the reverse linkage database.
For #1, experience has shown this is crucial. I think the suggested concept is workable (the type: parameter), and I am now right now trying it out for Wikimaps and for World Wind. One extra immediate advantage, that will be implemented in a couple of days, is that one may assign different default scales to different types, so that one in most cases need not bother setting a scale specifically (I put in come suggestions in the table, comments invited.)
For #2 further study is required.
As long as we are not talking of a massive number of points, and you are happy to follow-up if further changes are required, there shouldn't be a problem. Geography of should have type:country, for instance. -- Egil 08:03, 14 Mar 2005 (UTC)
Well, speaking of massive changes, I don't intend to go through the Rambot entries (they might not even need it), but I think it's worth trying to get the other coordinates in a standard form, which makes later changes (adding types, e.g.) and uses (#2) easier for everyone. The ones in the geography articles are probably some of the easier ones (for people like me learning about regexp).
BTW I had started with the "type:country" addition at Finland, but it didn't do too much (for now). As it's already an advantage to have them in the form you suggest, I will do all of those articles. -- User:Docu
You'll see the real advantage when the usage is reversed. I will do this for NASA World Wind very soon (so you can disable/enable by type, for instance show only countries), but it will become even more useful in Wikimaps. I'll implement the default scale based on type real soon (please update the desired scale factors in the table to sensible values), which will hopefully also be beneficial. The default scale can of course always be overridden by an explicit scale. -- Egil 13:23, 14 Mar 2005 (UTC)


[edit] Brazilian towns, Australian National Parks

There are about 300 stubs (e.g. in Category:São Paulo state) with coordinates in the form:

Its latitude is 20.18/20°10'56" S and the longitude is 49.35/49°21'05" W.

I'd like to change them to:

Its coordinates are 20°10′56″S, 49°21′05″W.

Samples: Orindiúva, Limeira, Barretos, Orlândia, Piracicaba

The coordinates in the Portuguese language versions of the articles (were they probably came from) are in the format DMS. Before changing all of them, I'd like to have your opinion about this. -- User:Docu

FWIW, my personal opinion is that dms is better for human consumption. But perhaps I'm only old fashioned? Specifying both forms defintely should be unnecessary. (SI seem to believe dms is acceptable, I think. And coordinates in radians has really not become high fashion yet.) Anyway, if you add region:BR then they will lead you to a page with the Brazil map shown first. -- Egil 18:20, 17 Mar 2005 (UTC)
OK, I will add region:BR and keep only the original DMS form. Which type shall I add to the National Parks of Australia? (There are about 500 with articles, some with a "fact sheet" (Barool National Park e.g.), others with an infobox (Organ Pipes National Park). "type:landmark_region:AU" ?-- User:Docu
The region is AU (there is not a specific AU page yet, so you will default to the main page. Which is fine. An AU page is easily made at any time, using BR or something as a starting point). The purpose of type was first and foremost meant to differentiate different symbols that would appear on a map. We could perhaps distinguish cultural landmark from natural landmark, but I'm personally totally happy with just landmark. -- Egil 07:13, 18 Mar 2005 (UTC)
As the Australian ones didn't seem problematic, I already converted them. I'm currently running the bot reformatting the coordinates in the Brazilian towns. My sample wasn't that representative and the changes need show all the more the advantage of a template! -- User:Docu

[edit] Rambot entries

Most of the Rambot articles already have Template:Mapit-US-cityscale or Template:Geolinks-US-cityscale etc, I excluded all those from the selections of articles to be processed. There might be several hundered articles that don't have them yet, mostly Townships and unincorporated communities, but also Lexington, Kentucky. I converted some of the US articles that don't include links like "[[Geographic references|1]]" or Template:GR (most rambot entries have them).

Should the remaining rambot entries be converted as well? How shall we convert the rambot format?

The default conversion would be, e.g. at Lexington, Kentucky:

Lexington-Fayette is located at 38°1'47" North, 84°29'41" West (38.029632, -84.494642)1.

to:

Lexington-Fayette is located at 38°1′47″N, 84°29′41″W (38.029632, -84.494642)1.

If we drop the decimal notation as for Brazil, it would be:

Lexington-Fayette is located at 38°1′47″N, 84°29′41″W 1.

Obviously, I would add "region:US".

Not all entries do include the decimal format though.

How shall we proceed? Personally I wouldn't do the conversion myself for the articles that already include one of the templates linked to Template:Coor, but would be willing to do it for the remaining ones (500?). I will leave a note to Ram-Man as well. -- User:Docu

Yes, better synchronize with Ram-Man. It is rumored there are about 30.000 of these articles. Since there already is a pointer in form of the mapit-etc templates, there is no hurry. Perhaps best to wait untill the mechanism as entirely within Wikipedia (which probably means switching from the coor-family templates to a Geo tag). -- Egil 16:11, 18 Mar 2005 (UTC)
Well it's just the 500 or so entries that don't have the map-it etc. templates (moved articles?, coordinates not even added by rambot?), but I obviously favor a format consistent with the remaining 30000.
Even if we switch to <geo> tags later, unless it includes a very tolerant parser, it's a definite advantage to have as many of the current variations formatted into the templates. Either way, it could be sufficient to add the <geo> to Template:Coor. -- User:Docu
Right. Another thing is that when the coordinates for the cities is used for markup in maps (which can happen sooner than you think), then due to the sheer amount of points, we really need not only the type specified, but also the size of the city (e.g. type:city(108,541). Otherwise, an overview map of the entire USA will end up as a big blob of red ink. It is nice to have some more innocent amounts of data to experiment with (like Brazil or Norway), before committing to changes for all the 30000. -- Egil 16:35, 18 Mar 2005 (UTC)
I'm a bit hesitant to duplicate the population data to the link as well. It would be easy to add it where it's already part of a template, e.g. Norway or Poland (if you get the formatting of the coordinates right). BTW Lombardy has an infobox with the population data, but the infobox is not in a template. For Brazil it might be a bit hard to get the data out of Pumpie's articles, it took me quite some time to get the coordinates right.
Once a new download version is available, I could easily add a series of types to coordinates, e.g. "type:landmark" to many masts. Maybe the categories on the articles could help determine the type as well. -- User:Docu
I just stopped by on request and I have not read into this discussion that much, but can someone give me some examples of some articles that have the coordinates but are not using the "Mapit" stuff? It is possible that I missed it, but it is also possible that I was not the one that added those coordinates. In any case, is this new format intended to replace the mapit template? -- RM 16:53, Mar 21, 2005 (UTC)
It's mainly to provide formatted coordinates on the articles, similar to the Lexington sample above. The mapit stuff does that also, so no use to change the formatting of the coordinates yet, especially since the coor template isn't necessarily the definite solution.
Other cases without a mapit/geolinks template: [Removed, see page history] .
From those, all seem to have coordinates added by others, with the exception of maybe Montezuma, Colorado. Anyways, this suggest that D6 should convert the coordinates in cases where there is no mapit template (and it hasn't been done yet). We'd just need to agree on a format, e.g.
Lexington-Fayette is located at 38°1′47″N, 84°29′41″W 1.
You could later use those coordinates to add the missing mapit templates ;-)
-- User:Docu
Since most of them appear to have been added by someone else, I think that I don't have any objection to someone else trying to perform the update. So go for it, once the format is decided on. -- RM 14:22, Mar 22, 2005 (UTC)
Can we agree on the version above w/o the decimal notation? (I would only convert those that don't have a mapit template) for now. -- User:Docu
As these few entries didn't include the geolinks-us-cit/mapit template don't appear to matter (approx. 200 compared to 30k), I converted them and removed the selection from my previous post (see page history). --- User:Docu

[edit] Formatting variations not yet converted

After converting dms and dm, I plan on converting coordinates for template:coor d. Once in a while I come across formats the regex didn't convert in it's present form, e.g. at Varna Airport. Only one of the five "official formats" appears to need conversion [8].

If there are formats of coordinates in articles I haven't converted yet, please post them here. A few exceptions are listed at #Articles with coordinates, but not linked to Template:Coor.

I don't want to define the conversion too broad, to avoid too many conversion of things that are not coordinates. I do review the conversion log generated by D6 to reverse such changes. -- User:Docu

[edit] Suggestion: Add Coordinate Display Format into User Preferences

(Topics: delegate data format, display format, and default display format)

Recently I got a first hand experience of the benefits of using the "Local coordinate system" for New Zealand while hiking in the mountains there. Basically I preciously stubbornly used Latitude/Longitude. NZ maps include Lat/Long, but the maps are gird marked for NZDG49. This is the same problem as expressed by swiss friend with CH1903.

The etrex handheld GPS unit I carried display both Lat/Long and NZDG (and about 20 others). NZDG was by far the easiest to find on the local map.keep the coor dms/md/d system currently in place. But allow a used to specify what their preferred "output format" coordinate system is in their preferences. This could well be dms, dm or just d.ddddddd.

But then ALSO allow the whole system to be extended by delegation. NevilleDNZ 04:13, 14 May 2005 (UTC)

I see there are two issues that need here to be delegated to each country/user, as follows:

[edit] The Geo Data input format

  • how the data is Input, eg which is the local/natural coordinate system
    • These two coordinates are actually the same location:
      • NZ 1949 std {{coor NZGD49|38|56|11.292|S|175|23|4.38|E|}}
      • Global std {{coor WGA84|38|56|4.9507|S|175|23|5.0315|E|}}
      • note: NZ is different because of a 200m difference in the original estimate of the earths center of mass. Currently NZ now uses the NZGD2000 standard that matches WGA84.

NevilleDNZ 04:13, 14 May 2005 (UTC)

[edit] The Geo Data display format

How these coordinates are displayed.

  • Do the user prefer Latitude/Longitude in WGA, or in the "local" tandard.
    • Are there are even choices of local formating standards...
    • eg. 25S10130.00 60E26941.00 for 40.96S 173.00E
    • I believe this makes for a 1km x 1km grid in NZ (I need to check this)
  • It could be in GDS84 d,dm,dms
  • It could be in as per the users preferences.
  • If could default to the standard of the country of the input method.
  • possibility: NZ 1949 std {{coor NZGD49|38|56|11.292|S|175|23|4.38|E|region:nz_type:school_display:WGA84}}

Here is a URL from the NZGS discussing that pros/cons of the WGA84 system. (Source) BTW: There are many!!! Here are just some stems: AGD66 AGD84 ATF ATS77 CH1903 CH1903+ CSG67 DHDN ED50 ELD79 ETRS89 FD58 GDA94 GGRS87 HD72 ID74 IGM95 IGN53 IGN56 IGN72 IGN72 IGN72 IRENET95 ISN93 JAD69 JGD2000 KKJ KOC KUDAMS LKS92 MGI MOP78 NAD27 NAD83 NAD NEA74 NGN NGO NTF NZGD2000 NZGD49 etc etc So it important that the adding of these grid references systems are delegated.

Another important reason to make the other reference systems available is simply put, if they are available then people can use them, if they are not, that data will be entered in an unknown system which will default to WGA84.

It seems complicated, but the simple "coord dms" would still always work as the default.

NevilleDNZ 04:13, 14 May 2005 (UTC)

I found the web page for GDAL, this software is from FSF and seems to contain all the conversions necessary for the different coordinate systems.

NevilleDNZ 04:39, 14 May 2005 (UTC)

[edit] One small suggestion for conversions

Can we add to the TownX Map Sources Wiki page the different "nowiki" versions of the "coor" e.g.

  • DMS {{coor dms|38|56|4.9507|S|175|23|5.0315|E|region:nz}}
  • DM {{coor dm|38|56.?????|S|175|23.?????|E|region:nz}}
  • D {{coor d|38.93647|S|175.38455|E|region:nz}}
  • NZGD49 {{coor NZGD49|38|56|11.292|S|175|23|4.38|E|region:default_display:dms}} possible?
  • CH1903 {{coor CH1903|?|?|?|region:ch_display:dms}} ?

That way we can cut and paste the "dms" version into our pages, without using a calculator to convert from Degrees to DMS.

NevilleDNZ 05:54, 14 May 2005 (UTC)

[edit] Latest status

The Map sources now has an entry Find nearby locations on GeoURL, which will present a list of Internet pages with geographic information (based on HTML meta tags). (The new Geo extension will ensure that the Wikipedia articles containing coordinates will get a geo.position meta tag that should make it possible for Wikipedia articles to appear on this list also.)

The type and region attributes are now implemented. The type will set an appropriate default scale (plus of course the advantages for future use. The region is a mechanism that enables selection of targetted map resources (e.g. region:US). -- Egil 18:12, 15 Mar 2005 (UTC)

I have now implemented the database mechanism that keeps track of the articles with geographic references in realtime, and that has the ability to come up with a list of neighboring articles, with distance and direction stated. It is also possible for anyone to obtain a list of coordinates and articles for other uses, and there will be hooks for Wikimaps. I will do some more in-house debugging, and tune a couple of implementation details. After that, I will try to create a critical mass of articles with geographic locations on the test server, so that this scheme can be tested in a more realistic manner. -- Egil 07:36, 18 Mar 2005 (UTC)

[edit] Area vs point

Many objects are not represented very well by points. Jan_Mayen may - because it is a lonely island - be identified by 71° N 8° W, but might be better defined by a Dublin Core Box from 7.9253 - 9.1711 W and 70.7914 - 71.1802 N. (But I have to admit that the bounding box of Norway - including Svalbard, Jan_Mayen and Bouvet_Island - would be rather useless.)

Agreed, but one has to start somewhere, right? This has to be an extension for further study. Would a square box do, or is a generic polygon required? (A square box certainly makes things very much easier wrt representation in the database). Anyway, going to polygons is soon bordering into general maps, for which there is a project already. -- Egil 17:11, 17 Mar 2005 (UTC)
With regards to the Dublin core box, it that a format that is suitable as inclusion as ordinary HTTP meta data? -- Egil 17:50, 22 Mar 2005 (UTC)

[edit] Why doesn't it display?

' and " display on my browser. Whatever you are using does not. All I get is square boxes for minute and second. I don't see how making the coordinates unreadable on a least a subset of popular browsers is supposed to be an improvement. It certainly faills the user-friendly test if I am going to need to download new fonts just to read locations. Rmhermen 01:39, Mar 19, 2005 (UTC)

The characters being used in the template seem to be unicode 8242 and 8243 - prime and double prime, which are probably the "right" symbols to use. What operating system and browser do you use? I haven't had a problem on Windows XP with Firefox or IE, or Linux with Firefox. --ScottDavis 03:49, 19 Mar 2005 (UTC)
I agree with Rmhermen, ' and " are fine, there is no need to use &prime; &Prime; giving ′ ″--Patrick 16:36, 19 Mar 2005 (UTC)
But typewriter quotes are simply a poor substitute for primes. Let's figure out why Rmhermen's browser isn't displaying them before settling for a compromise. —Michael Z. 2005-03-19 23:04 Z

[edit] Is it time yet?

Hi. I signed up when I found this project because it looks like good ideas. I propose to try to find and add coordinates for towns and other items in Australia, particularly South Australia. It looks like I should lay them out as 34°15′0″S, 138°30′0″E or 34.25° S 138.5° E. Is this a good thing to do yet? Is there anything else I should put in these template calls (eg scale, type)? What should the last parameter be for suburbs of a city? What about for landmarks within the city centre? --ScottDavis 04:19, 19 Mar 2005 (UTC)

It would be very nice if you could include the type attribute. It should give you a reasonable default scale, so you don't have to worry about that. But the real benefit should be when the Wikimaps gets to happen. Landmarks anywhere should just have exact coordinates and type:landmark, we'll leave it to the map engine to manage. Cities should really have the population specified. Suburbs is a very good question, I believe we don't have a type for that. I'll try to look at what others are doing (GIS etc). -- Egil 11:43, 20 Mar 2005 (UTC)

I've done a few towns in South Australia with region:AU-SA and no type. I've done at least one landmark (Victoria Square, Adelaide) with the region and type:landmark. Is type:city appropriate even for country towns? "City" has a legal meaning in Australia, and most towns don't qualify. Some gazetteers use "populated place" as a non-judgemental term. I'd prefer type:town or type:pp, and add the population if/when known. I'll try to add type:city (or type:town or an alternative if you accept it) to them tomorrow. According to suburb, what I mean by suburb is what Americans would call a neighbourhood. --ScottDavis 13:16, 20 Mar 2005 (UTC).

The term city was used simply because it was used in some US GIS resource. It is certainly meant to mean anything that should be marked on a map, from village to metropolis. By adding the population in parenthesis, the future map engine should be able to handle it according to size. If you think it is important, we can always have city and town as synonym attributes. -- Egil 10:11, 22 Mar 2005 (UTC)

The source I've been using (Geoscience Australia) uses the feature code LOCB - Locality (bounded), Town, Village, Populated place, Local government town, Town site (no population) for towns like Tanunda, and URBN - Urban area, City for Adelaide. Suburbs of Adelaide such as Elizabeth have feature code SUB - Suburb. Either the definition of type:city should be modified to say "City or town...", or a new type:town could be introduced. I don't mind which. --ScottDavis 23:19, 22 Mar 2005 (UTC)

[edit] Wow

In case anyone hasn't mentioned it: fantastic work! The work of the project adds a whole new dimensions of capabilities to Wikipedia. The implementation is excellent and easy to use. Well done. —Michael Z. 2005-03-19 15:15 Z

[edit] Mumbai

I tried to get Mumbai into the d cordinate but I get an out of range error. Mumbai has a co-ordinate of 18.96N , 72.82E. See template:Mumbai infobox. I gave up after trying different permutations. How does the syntax work? Nichalp 19:12, Mar 20, 2005 (UTC)

I fixed it, check out Wikipedia:Manual of Style (dates and numbers)#Geographical coordinates for the decimal notation. -- User:Docu
Thanks for the link. I'll use the Mos for all my articles now. Nichalp 19:19, Mar 21, 2005 (UTC)

[edit] Very good idea!

My deep respect to the man, who generated it! Maybe somewhen in the future something similar applied to the sky (for objects with relatively constant location, like stars, there) will appear here, although I doubt, if at the present we can find for this such a good "locator" as e.g. MapQuest. Cmapm 23:27, 20 Mar 2005 (UTC)

[edit] Gis extension

The <geo> tag, the map source mechanism, the database, the neighborhood article mechanism as well as a source mechanism for Wikimap and others are now all available as part of the meta:Gis extension. If you would want to have this feature available for Wikipedia, you need to press your Wikipedia admin to have this extension enabled. -- Egil 10:30, 25 Mar 2005 (UTC)

Is there a way yet to include "<geo>{{{LONG}}} {{{LAT}}} type:city({{{population}}})</geo>" in templates? -- User:Docu
who is our wikipedian admin ? can we press them ? I'd love to see Geo meta data --neilp 23:40, 2005 Apr 19 (UTC)

[edit] More missing types

As noted above, there isn't really a type defined for towns/villages/suburbs, although city is intended to be able to do the job.

There are also no available types for non-administrative parts of countries or landforms other than isle. Missing types I can think of include

  • river
  • peninsula/cape/headland
  • inlet/bay/harbour/bight/gulf/fjord
  • region/area
  • port
  • lake
  • archipelago

--ScottDavis 14:03, 27 Mar 2005 (UTC)

This is a geographical classification. Using legalistic distinctions between whatever might be officially designated by some particular name such as a "town" or a "plantation" or a "village" or a "city" in any particular jurisdiction (the discussion above to which you refer here dealt with Australian legalese, IIRC) would be just plain idiotic. Rough distinctions based on how much area they cover would make sense here, and population might be used for a rough estimate of that distinction. But having having some "cities" with 8 people and some "towns" with 800,000 people would be of no help whatsoever in choosing an appropriate scale at which to map these features.
Your grouping of what you see as missing is a good idea; would we need one name for each grouping? But as far as the purpose of including it at all in this template goes, I though that the only reason for it was to help start with an appropriate map scale.
So what's really "missing"? If these aren't something that you are normally going to "see" in any case, they aren't really anything "missing". So unless you have some other use for these in mind, I don't see the relevance. I haven't followed all this discussion about this either, so maybe there already is something along those lines, but I haven't noticed it if there is. Gene Nygaard 17:14, 27 Mar 2005 (UTC)

Quoting from the project page,

 Sets the type of this location, which will be used for the reverse mapping of the
 points. Will also set the default map scale.

The type is intended to be used for more than just setting scale. Ideally for many area features, the article should specify a box, not just a point.

I noticed the problem last night when I wanted to add template:coor with coordinates to Yorke Peninsula. Other problem examples for which there isn't yet an appropriate type include Murray River, Spencer Gulf, Great Australian Bight, Encounter Bay, Wrattonbully, Port Lincoln, Lake Alexandrina, Malay Archipelago. Most of these don't yet have coordinates entered. --ScottDavis 23:44, 27 Mar 2005 (UTC)

I agree that there should be a very small list of very generally-applicable types. To do anything else will require constantly adding more and more specific types.

So I am confused as to why there are both "state" and "adm1st" types; I think that states are first-level administrative subdivisions in the USA and some other countries, and a state is also a country. —Michael Z. 2005-03-29 22:44 Z

[edit] More thoughts about the type

The main use of the type is for the coming Wikimaps. This is under development. There needs to a type for towns/cities so they can be added and filtered appropriately. Other items that will be marked with a symbol on a map, like airports, mountains and landmarks are also required. For things that are generally shown as areas on a map, like major lakes, peninsulas, fjords, bays and islands, from the map drawing point of view, it suffices to give a central point and a name. On the map, only the name will appear, and it is assumed that the map itself will show the relevant feature. The coming geo tag has support for a bounding box, time will show how how useful this is.

The adm1st in the US was meant to be the county level. Perhaps that is confusing? In smaller countries, the county is the 1st level below country. In the US, the county is the 1st level below state. The adm2nd was meant to be at the municipality level. That would often be interchangeable with city.

town and village can be made a synonym for city if that is meaningful. In the maps, the distinction and filtering will be done by population anyway, so city/town/village will be exactly the same.

Perhaps it makes sense also to expand the "geographic area" category to include lake, isle, fjord, bay, peninsula and a few others. For the map drawing point of view they are treated the same, but when the neighborhood articles are listed, it is probably nice to see the difference? -- Egil 23:28, 29 Mar 2005 (UTC)

So is this the way it works?:
  • state = province, région, oblast, canton (Switzerland)
  • adm1st = county (Ontario or USA), rural municipality (Manitoba), département, raion
  • adm2nd = arrondisement
  • ? = canton (France)
  • ? = communauté
  • ? = comune
That is not intuitive (I assumed state was used for U.S. states and adm1 for Canadian provinces. I know, if I had thought about it...). Since there are three levels of administrative subdivisions, why not start numbering them from 1, and use generic names?:
  • sub1 = state, province, région, oblast, canton (Switzerland)
  • sub2 = county (Ontario or USA), rural municipality (Manitoba), département, raion
  • sub3 = arrondisement
  • sub4 = canton (France)
  • sub5 = communaté
  • sub6 = comune
  • sub7 = etc.
—Michael Z. 2005-03-30 02:54 Z
I'm game to try using the bounding box for area features like many I mentioned above. Having a few distinct types might be helpful for understanding. It would better allow for future clever wikimaps to render the names differently (water features labeled in dark blue, land features in black, manmade features in red for example).
I also thought state was equivalent to adm1st. I don't recall what systems I've used that I might have picked that idea from, but it never occurred to me that adm1st was a division of a state.
I like the idea of city, town, and village being equivalent, but with different default populations if not specified. For example default city has pop 50,000, default town 5000, default village 500. I don't know if I've picked good scale numbers (one order of magnitude). Maybe 100, 10,000, 1,000,000 at two orders of magnitude.
--ScottDavis 14:12, 30 Mar 2005 (UTC)

[edit] Categories

There is currently a debate at Categories for deletion#category:Articles with OSGB36 coordinates. -- User:Docu

[edit] Spacing after primes

The current form, "11° 22′ 33″ N" looks just awful, with those biiig spaces after the primes. How about using plain old apostrophes and double-quotes, "11° 22' 33" N", or doing it math-style, "11^\circ \, 22' \, 33'' N"? —wwoods 08:47, 16 Apr 2005 (UTC)

It looks fine on my Mac. Please don't change the correct characters to typewriter quotation marks because of the poor quality of font display on a particular system. And for goodness' sake don't change text to an image file! —Michael Z. 2005-04-16 16:51 Z
"11^\circ 22' 33'' N" looks kind of funky. And the PNG image I get is 522 bytes and will be cached by the server. HTH HAND --Phil | Talk 16:03, Apr 19, 2005 (UTC)

[edit] Help needed to find latitude/longitude of some UK towns

Hi, I am in the process of adding a map showing the location of every town in a subcategory of Category:Towns_in_England (and intend to then move on to Scottish/Welsh towns). I've had trouble finding the coordinates of some towns. Please could you take a look at User:Lupin/coords and help me to fill in the blanks? Many thanks. Lupin 14:48, 19 Apr 2005 (UTC)

[edit] OSGB bug

Image:OS grid key Britain.gif

This picture may help in fixing the {osgb36ref} bug. On the project page you invite us to help. This looks like a bug that I might be able to fix without detailed knowledge of php script. But where is the source code? -- RHaworth 00:46, 2005 Apr 27 (UTC)

It's at [9]. Probably in the transversemercator.php file. Egil would know where exactly. -- User:Docu
I reckon that in transversemercator.php, function LatLon2OSGB36() if you replace two occurrences of round with floor, you will fix this bug. -- RHaworth 08:21, 2005 Apr 27 (UTC)
Implemented. Thanks. -- Egil 05:14, 28 Apr 2005 (UTC)
It is I who am thanking you. -- RHaworth 08:36, 2005 Apr 28 (UTC)

[edit] OSGB36 as input

Whilst people navigating the coast of Great Britain may use latitude and longitude, inland these co-ordinates are almost never used because we have the excellent British national grid reference system. index.php should be amended to accept grid references as an alternative input parameter. Or a separate php should be written. It needs to accept both the all-numeric and the 'two letters plus even number of digits' formats.

If this was done, the following articles and hundreds more could use the php instantly. special:whatlinkshere/Template:Gbmapping, special:whatlinkshere/Template:Gbmappingsmall, special:whatlinkshere/Template:Gbmaprim.

And so they don't feel left out, you would also need to accept Irish grid refs.

-- RHaworth 01:20, 2005 Apr 27 (UTC)

Input in UTM was implemented once, but I later sort of decided against it because it made parsing of Wikitext to extract coordinates more complex and ugly since every parser would have to include routines for detecting and converting transverse mercator. So I removed and, and for the existing cases were UTM was used, I converted to lat/lon.
OSGB36 adds the extra subtility that it is not referrenced to WGS84, which makes yet another exception. So my thought was that it was much cleaner to have input as pure WGS84 lat/lon, and convert to other systems as required for the various map sources. One other thing: wouldn't you need to convert to degrees WGS84 for use with a GPS navigator, anyway? -- Egil 05:38, 28 Apr 2005 (UTC)


I agree that parsing the input parameters of index.php is complicated enough as it is. My idea was to create a separate php which would only accept OSGB and OSNI co-ordinates. It would convert them to lat/lon and call index.php.

I had the use of GPS for a few months then I had to give it back. In the two years since I have not felt the lack of GPS at all. But others like it, that is why we need the separate php.

I don't know whether you have noticed another horrible potential complexity - look at:

UK railway stations

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

They contain 2000 map links using postcodes! I think all the GB mapping services accept post codes but I consider it a perversion. The postcode to co-ordinates database is licenced from Royal Mail but I do not think Wikipedia needs to bother about it. My solution here would be to add just one extra input option to index.php - a pass-through facility. The postcode would be made available, unchanged for use in any link that is capable of using it. This would achieve the object of giving the Wiki user a choice of map / aerial photo sources.

-- RHaworth 09:24, 2005 Apr 28 (UTC)

[edit] OSGB36 now available

Template:oscoor is now up and working for GB at least. (I hope to add Ireland shortly.)

I apologise for writing it in Javascript, but:

  • I can manage Javascript with only a few references to the manual. Doing it in php would involve a steep learning curve for me.
  • It would relieve the always hard pressed Wiki servers from doing lots of maths.
  • There is the disadvantage that it breaks the browser back button - but so do some of the map sources we link to.

At the bottom of Map sources/GB is a circular link to help test the arithmetic - this example is about the worst that it gets - over most of the country it is acurate to a metre. To examine the code, just call it with invalid coordinates. -- RHaworth 06:22, 2005 May 5 (UTC)

[edit] Worldwind alt, dir, tilt parameters +++

I can see this map location is evolving, and has to deal with interfacing with many different kinds of geo-databases.

I added the following to the kiwi page kakahi.

The worldwind URL on this page is not supported... eg Composite Satellite/Radar Image of Kakahi with Mountains: Ruahehu, Tongarero and Ngarahoe in background Hence I will have no reason or temptation to upload the (derived) equvalent WorldWind screen shot.

OK... it would be "nice to have" the information for alt, dir and tilt in wiki. As a "coor" it would be available to other applications also, rather then just worldwind.

Also the current "coor" stub {{coor d|38.93647|S|175.38455|E|region:nz_type:city}} allows a contributor to add the country and administrative unit, but the TownName/Topic name is missing. Hence the name of the "coor" will be derived from the page name. Hence only one coor per page is useful.

And if I was to get really excited, then maybe it would be useful to add Date/time so information about photos can be tagged with location and time photo was taken. This would be useful for automatic generation of timelines for a location or country.

NevilleDNZ 08:14, 12 May 2005 (UTC)

FYI: DNS/bind also stores Lat/Long location information, DNS#Types_of_DNS_records

Here is a query example using the linux dig command:

$ dig 3ttechnology.com LOC
Returns:
3ttechnology.com.       600     IN      LOC     2 10 0.000 S 104 30 0.000 E 10.00m 1000m 10m 10m
This includes altitude, and an estimate of the size/precision of the location that is refered to.

Details: from RFC 1035

3 Master File Format

The LOC record is expressed in a master file in the following format: 
   <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
                               {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
                               [vp["m"]]]] )
 (The parentheses are used for multi-line data as specified in [RFC 1035] section 5.1.) 
where: d1:     [0 .. 90]            (degrees latitude)
       d2:     [0 .. 180]           (degrees longitude)
       m1, m2: [0 .. 59]            (minutes latitude/longitude)
       s1, s2: [0 .. 59.999]        (seconds latitude/longitude)
       alt:    [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
       siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)

I mention this in the hope it might be useful. (I am feeling guilty at being a spectator AND with the knowledge that the best solution is sometimes not so easy to conclude on.)

NevilleDNZ 08:53, 12 May 2005 (UTC)


[edit] WikiProject_Geographical_coordinates/Templates_used

The lists how many times different templates use Coor templates (on May 16). -- User:Docu

[edit] Google maps

I think we should remove Google maps from the Global section of kvaleberg.com Map Sources. In truth, Google does North America well (actually superbly) in both satellite images and line art maps, it also has the UK at barely passable level. The rest of the world barely exist except in very low resolution satellite maps at a scale which shouldnt't really qualify for anything useful. Until it is expanded well beyond beta, Google maps should be treated as US only. -- Solipsist 20:17, 23 May 2005 (UTC)

Done. I've also tried to clean up Great Britain. The concept is that the default map scale should be specified in the Wikipedia map reference, not that the user should worry about it when selecting a map from the list. Scaling up and down should best be done at the original map service. -- Egil 03:30, 24 May 2005 (UTC)
Meanwhile I do not know any place on earth that is not offered in an acceptabe resolution by Google Earth.
The national pages on Kvaleberg should be run with an interface to Google Earth generally. -- Simplicius 11:13, 16 November 2005 (UTC)

[edit] Google Earth with 2600 coordinates from german Wikipedia

Hi, I transfer 2600 coordinates from the german Wikipedia in a XML-file for the software Google Earth [10]. At this website you can see the results and download the pointdata. I test also NASA World Wind, but this software can handle max. 200 points. With more points it stop the work. I hope with my work we can better handle the coordinates in the german Wikipedia. The user can see how bad or good the point is. I use the types to groupe the points. It was usefull to create a new type:waterbodies for lakes, channels and waterfalls. -- Stefan Kühn 2 July 2005 00:14 (UTC)

Now I have complete the dataset with 5300 Points from the englisch Wikipedia. Download. In Google Earth load this klm-file with Menu File/Open. -- Stefan Kühn 16:59, 16 July 2005 (UTC)

Will it be possible, eventually, to create co-ordinate entries in wiki articles (using something like the coor template) that generate a link to Google Earth? For those users with Google Earth installed, it would be mighty nice to have a button in the wiki article that "takes you there". Technically, this seems to imply creating a kmz file on the fly, but I may be wrong... Urhixidur 16:15, 2005 August 11 (UTC)

[edit] Unlinking coor

Egil had carefully arranged that Template:coor would be the only place where the URL of his Mapsources script would be held. Netoholic started to copy this URL into other templates to reduce the number of levels of nesting. Would a few people please visit Template talk:coor#Discussion and confirm that I was right to tell him to stop it. -- RHaworth 16:56, 2005 July 12 (UTC)

[edit] re: Tool for the determination of coordinates and markup-building

There is a version for the english and german Wikipedia available.

Nice page... Can we somehow get a "coor dm" button here? (1 minute of latitude is always exactly one Nautical Mile, a useful unit of measure, (also: 0°1.0000'S = 1.0000NM = 2 x 1013 yd = 2 x 0.926 km) )
I added support for "coor dm" and "coor dms". HeinzJ 11:27, 14 July 2005 (UTC)
I get a message "Click into the map above to get the coordinates.", but there is no map.--Patrick 14:43, 14 July 2005 (UTC)
if you did download the page to your computer, you should read the text of the htm-file. HeinzJ 06:54, 15 July 2005 (UTC)

[edit] How do we convert a bounding box of 2 coordinates into a map?

Over in Wikipedia:WikiProject Mountains, we are considering expanding our infobox to cover mountain ranges. The natural location data for ranges would be a bounding box of lat/long, rather than a single point (perhaps with a scale).

Is there any way to modify the coor template & web site to accept a bounding box? The bounding box can be converted back to a center location and scale. I would just hate to have Wikipedia editors do this conversion manually.

Discussion about this is starting at Wikipedia Talk:WikiProject Mountains#Include mountain ranges?

-- hike395 07:19, July 22, 2005 (UTC)

[edit] Which geographical coordinate can be chosen when there are different ones?

Which geographical coordinate can be chosen when there are different ones? For example, for Drygalski Island, there are several different geographical coordinates (see Talk:Drygalski Island and Talk:Geographic coordinates (obtaining)). Are there guidelines or hints which one to choose? Which geographical coordinate is the most correct one? -- Citylover 12:34, 16 September 2005 (UTC)

They are not very different, it is just that there is one that is represented as decimal degrees, one as degrees and minutes. For an island with a certain size, as long as they point to a location reasonably in the middle of the island, there is really no preference for one over the other. Personally I may prefer the degree and minutes, but probably we should have sort of Wiki-decision on which one to use. The only fixed limitation is a referrence to WGS84, but for a reasonably large island it would not make much difference any way. -- Egil 16:02, 16 September 2005 (UTC)

[edit] templates and infoboxes

I noticed that Template:Airport infobox does not provide a link from the coordinates of the airport. This wikiproject says that infobox coordinates should be defined in terms of Template:coor and suggests Template:Infobox Dutch municipality 3 as an example. Unfortunately, that example does not use Template:coor any more. Is this a job for someone who understands the intricacies of Template:coor, and perhaps D6 bot if needed to format the calls to the airport infobox? I'm happy to help if required. --Scott Davis Talk 08:37, 18 September 2005 (UTC)

Template:Infobox Swiss town may show how it works. Basically, you'd need to add something like
{{coor dms|{{{latd}}}|{{{latm}}}|{{{lats}}}|{{{latNS}}} |{{{lond}}}|{{{lonm}}}|{{{lons}}}|{{{lonEW}}}|type:airport}}
to the template and, e.g. on London Heathrow Airport, replace
coordinates=51° 28' 39" N
0° 27' 41" W|
with
latd=51|latm=28|latd=39|latNS=N|
lond=0|lonm=27|lons=41|lonEW=W|
I might try to use D6 next week to do the conversion on the different airport articles, if it's ok with the editors of Template:Airport infobox. -- User:Docu
Docu, if you're still willing to make that change and automate the migration then that would be great - yes please. Thanks/Wangi 16:24, 17 October 2005 (UTC)
What is current status of this migration ? --TAG 13:36, 29 June 2006 (UTC)

[edit] Japanese map services - Tokyo datum

Hallo,

I am a Japanese user. I'm very interested in this project.

We have 2 reference frames in Japan. One is international one, Japanese Geodetic Datum2000, almost equal to ITRF and WGS84. Onother one is Tokyo Datum (Tokyo 97), old one. The both differences of latitude and longitude are about 8-15 seconds. Because some map services for Japan including Google map use Tokyo Datum, I'd like to get Tokyo Datum from the project. Could you arrange the project?

The data to convert are:

--? 13:00, 5 October 2005 (UTC)

[edit] Coordinates at the top of the article

[edit] German

Has anyone noticed the rather nice placement of coordinates on the German Wiki, using the template de:Vorlage:Geokoordinate, for example on de:Sony-Center. -- Solipsist 15:29, 23 Apr 2005 (UTC)

Very elegant solution, indeed. I have noticed that perhaps having coordinates as part of running text is not always appropriate — this concept really solves all of that. -- Egil 05:43, 28 Apr 2005 (UTC)

The Germans have been changing theirs a bit, and have replaced "Geokoordinate" with "Koordinate Artikel" that uses: span id="coordinates" class="coordinates" style="white-space:nowrap;" William Allen Simpson 02:15, 4 December 2005 (UTC)

[edit] Portuguese

The Portuguese Wikipedia has implemented a wonderful solution I would like to see emulated here in the English Wikipedia, where coordinate info is placed at the top/right of articles. See for yourself here. It seems fairly easy to implement, but we probably need an admin or a developer to get it work. What does everyone think? Isn't it a great idea? —Cantus…☎ 04:27, 9 October 2005 (UTC)

It's nice, though I don't quite like the way coordinates are specified: it adds the coordinates twice: "{{geocoordenadas|39_21_00_N_09_24_00_W|39º 21' N 09º 24' O}}". In cases where the coordinates are in a template/infobox, it might be easy to add/replace them with this way of displaying them. BTW: Oddly the coordinates aren't available in the print version (it works here though). -- User:Docu
The Germans did the same. I moved that talk entry down here, so that they can be talked about together.

The Portugese uses: div id="coordinates" class="noprint" p class="coordinates" William Allen Simpson 02:15, 4 December 2005 (UTC)

[edit] Dutch wikipedia

At the Dutch WP, we have implemented the same options, although we allow them both, and have different templates. 2 templates are implemented in nl:Ei_van_Kortrijk :

  • You can see coords at the top, which should be implemented as much as possible when the coords are relevant for the entire article, since they are in a unobtrusive location. (implementation is not optimal yet however, coords are specified twice)
  • In the external links section, there's another link... this template allow to link to kvaleberg sources as an external link : this may be usefull to draw a little more attention to the link if a map is relevant in the external links section, and you may want some text instead of purely the coords
  • Of course, we also have the normal templates like the ones used here, these allow to actually adds the coords visually and link the them within the text or an infobox

--LimoWreck 09:59, 3 March 2006 (UTC)

[edit] Implementation

It does mean going through and fixing the text by hand (since it would not longer be embedded in the article). I'd prefer the top placement to be the method used here, too, but don't see the need for the second "display" copy of the coordinates.

Also, their standard solution was to put the template at the end footer of the article, rather than the top (although it displays at the top). For other templates here, there is a hint on standard placement. Placement of the template at the start of the article would be best.

--William Allen Simpson 11:10, 3 December 2005 (UTC)
--William Allen Simpson 09:57, 22 January 2006 (UTC)
  • What should we call the top template? {{geo title d}}, {{geo title dm}}, {{geo title dms}}? {{title d}}, {{title dm}}, {{title dms}}?
-William Allen Simpson 10:03, 22 January 2006 (UTC)

Actually, they have variants that are text-inline as well, such as de:Template:Koordinate Text Artikel, so that placing coordinates in the text automagically puts them in the header as well.

As for implementation, it would be easy to add the code to the existing {{coor d}}, {{coor dm}}, and {{coor dms}} templates. A separate family (perhaps called {{coord header d}} and so on?) could be made that don't have an inline portion and only put it in the header. I have a working example at {{coorHeader}} that doesn't require any changes to the site-wide stylesheets. — Saxifrage ✎ 11:35, 20 March 2006 (UTC)

First of all, thanks for the example template! I had no idea that one could use absolute in such a way.
Still, given that 3 (and counting) different sites use "id=coordinates" it shouldn't be too hard to add that to en: .css. I'm going to post a help query at the village pump....
I like the Dutch solution best. (I just moved it above.) When you want it in the title, use the title version. When you want it in the text, use the inline version (our existing {{coor}}, {{coor d}}, etc.) When you want both, use both.
--William Allen Simpson 12:52, 20 March 2006 (UTC)
I'm partial to the German solution, but it would depend on what exactly developed as a standard: the German solution would be appropriate if we want coordinates to always appear at the top; the Dutch solution would be if we only wanted to encourage this usage. I just occurred to me though, that a big advantage to the Dutch way is that we could build consensus for adoption on a per-article basis and let it grow from there. — Saxifrage ✎ 19:44, 20 March 2006 (UTC)
If by "German solution" you mean changing the current (inline) templates to put the coordinates at the top: that would cause serious problems at e.g. List of settlements in Utrecht, and other pages with multiple instances of these templates. -- Eugene van der Pijll 22:41, 20 March 2006 (UTC)
Thank you, that's an extremely good argument for making them separate! I'm convinced. — Saxifrage ✎ 02:01, 21 March 2006 (UTC)
For the purpose of extrating coordinates to use them in Google Earth or WikiMiniAtlas this list is rather unfortunate. The coordinates should rather be put into the appropriate articles, otherwise we'll end up with a ton of markers on the map just pointing to the listpage. Then using the coord_title templates should be pushed, it is a really nice feature in the german (and portugese and dutch) wikipedia and I don't quite understand the controversy around it in en:wp.--Dschwen 10:47, 20 May 2006 (UTC)
Also, a note on implementation. The other languages use duplicated parameters to allow passing NSEW to kvaleberg, while displaying the initials of their own language. Can they/we use {{qif}} to compare strings and substitute the correct parameters? As Docu (talk • contribs) above, I'd prefer to keep a single set of coordinates. I'm not sure this is an issue here, but might be a thought to help coordinate among the *pedia.
--William Allen Simpson 13:09, 20 March 2006 (UTC)
This should be doable using {{switch}}. — Saxifrage ✎ 19:44, 20 March 2006 (UTC)

It turns out (unsuprisingly—I should have expected it) that the template as-is breaks when pages are viewed with skins other than Monobook, such as the significantly-popular Classic. [11] This means that moving to this style of coordinates template does require Developer support, in that we need to get the CSS out of the template and into Mediawiki:Monobook.css so that it plays nice with the other skins. Until such a thing happens, {{CoorHeader}} should be considered an experimental template. — Saxifrage ✎ 03:44, 21 March 2006 (UTC)

[edit] Consensus

This seems to have moved to implementation but I think I may have missed the discussion on whether it was a good idea. I would have voiced opposition at that time had I known. I think that for some articles, forcing the coords to display at the top of the article is not appropriate. Many articles I've had a hand in use {{Coor title d}} embedded inside {{Geolinks-US-streetscale}}. There doesn't seem to be a clear process for not usiing that nesting where it's not appropriate and I don't want to fork either one. So how should I proceed? Just lump it and consider it a done deal? ++Lar: t/c 14:12, 13 April 2006 (UTC)

The existence of the coor title family of templates is well supported. Including it in other templates enjoys less support. I personally don't think the blanket usage that happens by including it in various infoboxes and geographical templates is advisable and I've voiced opposition to this. Ideally, to my mind, it would be an independent template that could be added to pages that obviously benefit from it, and could be left off pages that really don't need it. The template family needs more exposure to determine the opinion of the wider community, and unfortunately this Project page is very sleepy. — Saxifrage ✎ 20:21, 13 April 2006 (UTC)

[edit] Non readable text

I find articles hard to read when they have geographical coordinates in with the text. I think the co-ordinates should be in a info box on the right side of an article when possible but when this is not possible to put it in a box i think there needs to be a better solution. From a readability POV I can not understand coordinates and must skip over them disrupting the flow of the page. Could we have another template where the coordinates are replaced with a clickable superscripted small globe icon or something similar? --Clawed 11:23, 16 October 2005 (UTC)

For towns or similar, I tend to put the coordinates in parentheses just after the name of the town. It's fairly natural to skip over parenthetical text if it does not interest you. I consider it important that the coordinates are visible on the page for printing, screen-reading software etc, not just hidden in a link to another page such as the one with all the links to maps. Most of the time I don't read the coordinates and only use them as a link, but not always. --Scott Davis Talk 12:50, 16 October 2005 (UTC)

[edit] New Data from Wikipedia for Google Earth

Hi, I have create a new dataset with coordinates from Wikipedia for Google Earth. From the english Wikipedia I use 27894 coordinates and from the german Wikipedia I use 14852 coordinates. In the german Wikipedia we use very often "region" and "type" in the coordinates. In combination with the categorys I can create a very good file for Google Earth. In the english Wikipedia I have found not so much entries of "region" and "type" an so the structure of the file is not so good. Attention pleace! The folder "City" is very very big. Download the file on this website. Sorry the Website is today only in german available. Click on "27894 Punkte von en.wikipedia.org" and have fun. -- Stefan Kühn 19:20, 16 October 2005 (UTC)

I've noticed that website some time before. It's very nice! One little suggestion from me would be: can it be mentioned somewhere, how frequently is it updated. Anyway, it's the great work, thanks a lot! Cmapm 01:58, 17 October 2005 (UTC)
Hi Cmapm, when I update my dataset then I write this here. I have not the time do make every week a update. My little script need one night to extract titel, coordinat and category of all articels. After this process I start an other programm to sort the data and create the kml. This need two hours. I need the most time to update my programm to the new templates. In the german wikipedia we have today a very stable template and not so many different templates, like in the english wikipedia. -- Stefan Kühn 07:14, 17 October 2005 (UTC)

Hi, again! A new file is available Download. 33420 Points!!! :-) -- Stefan Kühn 19:12, 19 November 2005 (UTC)

Hi, again! The next new is available Download. 33801 Points -- Stefan Kühn 20:38, 18 December 2005 (UTC)
Hi, again! The new dataset is available Download. 38547 Points -- Stefan Kühn 17:22, 5 March 2006 (UTC)
Hi, again! The new dataset is available Download. 48874 Points. Include a new structure! -- Stefan Kühn 18:42, 23 July 2006 (UTC)
Stefan, there seems to be a problem with this dataset for pages that used {{Geolinks-AUS-suburbscale}} - the longitude gets the wrong sign. Look around 33 degrees south. There's a gap at 150 degrees east, and a cluster of places at 150 degrees west that should fill it. Also one around 35 south, 135 east/west. These places ended up tagged as landmarks, where most should be populated places, but that may be outside your control. The location is definitely a problem with your data collation though. --Scott Davis Talk 13:33, 7 August 2006 (UTC)

[edit] ISO6709

Many kinds of latitude and longitude representation has already been described on WEB. Though uniform description based on ISO_8601 done for time. It might be desirable that the method of describing geographic coordinates of wiki spreads to other approachs of www. The specification that refers to other standard specifications might be more desirable than the description method of the original decision to achieve it. ISO_6709 might be a candidate when we analogize making W3CDTF referring to ISO_8601. ISO6709 is being revised now. The new revision will be able to add Coordinate Reference Systems (WGS84 etc.).

[edit] Lunar craters

Hi. I'm implementing the {{coor d}} template for the series of lunar crater articles using the type globe:Moon. (C.f. {{Lunar crater data}}.) The link works fine, but it doesn't appear to retain the decimal information. Also, the Lunar and Planetary Institute link doesn't always find matching crater pages for the coordinates, even though there are pages found under the name. I'm not sure whether this is an issue with the L&PI lookup or with the coordinates being transmitted.

Here's a couple of examples:

Is there anything that can be done to address this lookup problem? Thank you. — RJH 19:05, 14 December 2005 (UTC)

[edit] I've submitted a bug at bugzilla

For longitude range check for planets/moons rather than the Earth. But it seems nobody cares/fixes it.

Bugzilla entry here

— Yaohua2000 19:08, 15 December 2005 (UTC)

  • Thanks. — RJH 23:39, 15 December 2005 (UTC)
    • Don't just thanks, I hope someone could fix it... — Yaohua2000 01:22, 16 December 2005 (UTC)
      • Well, alas, I'm not sure what I can do about that. Is there code somewhere that can be examined? — RJH 22:08, 20 January 2006 (UTC)
        • If you are the coder, please modify the longitude range check to -360° to +360°. — Yaohua2000 05:19, 25 January 2006 (UTC)
  • If anybody is interested in getting this fixed, could you to go in via your bugzilla account and vote on this bug? I added mine it. If it gets enough votes maybe somebody will notice... Thanks. — RJH 23:00, 27 February 2006 (UTC)

[edit] dynamical Datas from Wikipedia for Google Earth

Hey, for people with not so fast computers I have a database on Meta:Toolserver to show only the 80 most important entities in the field of vision:

http://tools.wikimedia.de/~kolossos/georef/Wikipedia-dyn-data.kmz

I work together with de:Benutzer:Stefan Kühn.

An other little tool for searching a place is here: http://tools.wikimedia.de/~kolossos/ajax/place-search.php .

de:kolossos 20:07, 19 December 2005 (UTC)

Now, the program has also surroundings search.80.185.52.113 13:29, 5 January 2006 (UTC)
Do you use coordinates in templates such as template:infobox Swiss town? There should be many more points available for Switzerland. -- User:Docu
I believe yes. I take the coordinates from Stefan Kühn. The english Version should be 1 Month old. de:Benutzer:kolossos13:31, 11 January 2006 (UTC)
Wald, Berne has coordinates since June 2005, but doesn't appear on the map. The few pages that do appear are those with coordinates directly in Template:Coor dm. To make it easier to identify them, I created a category for the templates: Category:Coordinates templates. Great tool BTW ! -- User:Docu
Hi, I use only the standard templates "Coor ...", "Mapit..." and "geolinks..."! Important is, that this is part of the articel-dump. The template:infobox Swiss town create the Template:Coor dm at runtime. When I use the Dump, I only search the text "Coor ...", "Mapit..." and "geolinks..." and don´t parse the "template:infobox XY country". If someone can create the query online, then we can use also the "template:infobox...". But the problem is that you have a infobox per land or more. I think the better way is to make a standard of three types of coordinates (like in the german wikipedia) and to use this types. Next time I will test the using of infobox. -- Stefan Kühn 13:02, 12 January 2006 (UTC)
Ok, I'm looking forward to the new version. BTW the coordinates in the English municpality articles for Switzerland come from the German or French langugage wikipedias, although there they are just text (wasted?) and not formatted. -- User:Docu



To help your work, there is the Cat Scan-Tool, where you can scan whole categories with sub-categories and looking for templates. de:kolossos12:07, 22 December 2005 (UTC)

Now we have also a own surrounding map. Please test it. de:Benutzer:kolossos13:31, 11 January 2006 (UTC)

[edit] Wrong coordinates

Everyone else here wants to talk about high tech, but has anyone else noticed how many coordinates are simply miscopied? I keep finding areas like Greek towns (excluding the beginning of the alphabet, which I have fixed), where about 30% of the longitude/latitudes are wrong. It's usually wrong by one or more degrees (I seldom need to change the minutes and seconds), or by confusing N/S/E/W or longitude with latitude, or often the article has two sets of coordinates that disagree. I think the problem occurs most places throughout Eastern and Southern Europe. Art LaPella 19:14, 2 January 2006 (UTC)

There was a similar problem with articles about Italian cities. I fixed a few coordinates someone had pumped from the German wikipedia. Once the coordinates feature gets activate on Wikipedia (if ever), it may be easier to check them. -- User:Docu

[edit] Simple How to for noobs and non-programmers

I just finished creating a simple "how to" article for people who simply want the basics on adding georeferenced link templates to wikipedia articles. It is called Wikipedia:Coordinate-referenced map templates. Feel free to change the name of it or edit it to death, but I didn't see any other place where a noob could get basic instruction on the different template options that are out there. Please message use the discussion page on this article if you have any major beefs with the article MPS 05:14, 25 January 2006 (UTC)

[edit] Geographic naming

Would it make sense to add geographic names to the template, or is intended to key only to the Wikipedia article title? If, say, a city article has co-ordinates for several prominent buildings in it, how can the co-ordinates be harvested and linked to the correct entities.

Furthermore, lots of places have multiple names (historical, native, multiple local languages, multiple alphabets, transliteration, English, etc.). The Wikipedia:Persondata project is creating a metadata format which allows alternate names and other data to be entered in a metadata block for biographical articles. It may be natural to extend coor in this direction for other geo-related metadata.

Any thoughts? —Michael Z. 2006-02-08 00:31 Z

[edit] Please sign the petition for PUBLIC GEODATA

http://petition.publicgeodata.org/ --Historiograf 23:31, 17 February 2006 (UTC)

[edit] Converting among coordinate systems?

Hi everyone - I have to confess that I am a novice to this field, so please forgive me if my questions are basic or confusing. I'm trying to incorporate coordinates of summits in the article List of Norwegian peaks over 2000 meters into the table, and I've found a source that has all these coordinates listed. Here's the problem: the source lists it in either EUREF89 or ED50 (the webmaster isn't sure which, I asked him), which takes the format 463550 East and 6833850 North for a mountain called Galdhøpiggen, when the longitude and latitude for the same mountain is 61°38′11″N, 8°18′45″E. Apparently, the former is in meters. I have no idea how to convert from one to the other, but would like to. Any suggestions? --Leifern 19:54, 23 February 2006 (UTC)

The difference between EUREF89 and ED50 is not large. See ED50: the differences between the two coordinate systems are not more than a few hundred meters at most. The meter values you mention seem to be UTM values. You can do conversions at http://www.ngs.noaa.gov/cgi-bin/utm_getgp.prl (for example; unfortunately no EUREF/ETRS89 or ED50, as it's an American site). Apart from easting and northing, you also need the UTM zone of the location; see e.g. the map on the UTM article. Locations in Norway are in zone 32 to 36. Eugene van der Pijll 20:28, 23 February 2006 (UTC)

[edit] Coords on top as extra option ? (again)

In the millionth article Jordanhill_railway_station, it seems people can't agree if the coords should be added or not :

  • removing the coords is just throwing away VERY usefull information and very usefull links
  • adding the coords in the normal text paragraphs however doesn't look that good and is a bit over the top:

Maybe people should really reconsider adding templates for adding coords at the top of the articles , like the german/dutch/portugese wiki's ? See:

Wikipedia_talk:WikiProject_Geographical_coordinates#Coordinates_at_the_top_of_the_article

--LimoWreck 10:02, 3 March 2006 (UTC)

LimoWreck - my apologies: I hadn't seen your comments here before I moved the coordinates back to Notes and references again. Anyway, I actually agree with you: having them in the normal text just looks wrong. Thanks for pointing out the German and Portuguese Wikipedias' practise. Those certainly are elegant non-intrusive solutions. Perhaps we should have a straw poll to resolve this. --A bit iffy 10:58, 3 March 2006 (UTC)
I've been promoting this idea for general use at en.wikipedia for the last week, so I would definitely support this. Developer support is necessary to get the required code into Monobook.css, but broad support at the Millionth Article might be enough to make it happen! — Saxifrage ✎ 19:54, 23 March 2006 (UTC)
I forgot to mention that the CSS has been added to a couple of the style sheets this past week, so {{coor title d}}, {{coor title dm}}, and {{coor title dms}} are up and running. {{CoorHeader}} is deprecated.
--William Allen Simpson 04:58, 5 April 2006 (UTC)

[edit] Hartley Bay, British Columbia

Could someone check my coordinate conversion on that page? And what is the 6000 about in the teemplate? Rmhermen 19:12, 22 March 2006 (UTC)

[edit] Wikipedia:Version 1.0 Editorial Team cooperation

Hello. I'm a member of the Version 1.0 Editorial Team, which is looking to identify quality articles in Wikipedia for future publication on CD or paper. We recently began assessing articles using these criteria, and we are are asking for your help. As you are most aware of the issues surrounding your focus area, we are wondering if you could provide us with a list of the articles that fall within the scope of your WikiProject, and that are either featured, A-class, B-class, or Good articles, with no POV or copyright problems. Do you have any recommendations? If you do, please post your suggestions at the listing of all active Places WikiProjects, and if you have any questions, ask me in the Work Via WikiProjects talk page or directly in my talk page. Thanks a lot! Titoxd(?!? - help us) 18:24, 23 March 2006 (UTC)

[edit] Longitude Latitude

I'm new to this whole thing, and i was finding Long Lat co-ordinates for Pilanesberg National Park, some one else was helping me, and i found that depending on where you looked, the co-ordinates were different, I eventually settled with the one on google earth, was this the right thing to do? Philc 0780 13:31, 30 March 2006 (UTC)

[edit] Help needed

Please help me to arrange coors in the upper right angle of Livadia Palace, the way the do in de:Liwadija Palast. Thanks, --Ghirla -трёп- 10:26, 4 May 2006 (UTC)

The equivalent here to Koordinate Artikel is {{coor title dms}}.
--William Allen Simpson 12:21, 4 May 2006 (UTC)

[edit] multiple coords within an article?

Hi all, I'm new to this. The article Carnac stones deals with a lot of disparate objects for which the precise locations are, however, known [12]. Is there a way I can tag each of these objects? Or can I only tag the general location of the Carnac stones, accurate to say 20kms? Stevage 13:34, 11 May 2006 (UTC)

There is only room for one coordinate in the header; use the {{Coor title dm}} template (I think degrees+minutes works best for the size of the given region, perhaps even rounded to the nearest tens of minutes). {{Coor dms}} inserts a coordinate in the text; you can use as many as you want on a page, so this would be appropriate for the individual features. -- Eugene van der Pijll 21:35, 11 May 2006 (UTC)
Since you've got decimal degrees,
{{coor d|47.617800|N|3.065|W|type:landmark}} would save you converting. That produces 47.617800° N 3.065° W. If there are going to be a lot of links on a page, it'd probably look better if you could mask it somehow. Neither an internal nor external link seems to work, but you can put it into a footnote:[1]
—wwoods 00:38, 12 May 2006 (UTC)
Well, I've tried incorporating some directly into the headings. Do you think it looks too intrusive? Carnac stones. Stevage 08:55, 12 May 2006 (UTC)
No, but I suggest cutting the 00s from the latitudes. Since they all end that way, I don't think the source is really claiming the positions are accurate to 10 cm, it's just some quirk of their system.
—wwoods 17:33, 12 May 2006 (UTC)
  1. ^ 47.617800° N 3.065° W

[edit] WikiMiniAtlas Javascript plugin

WikiMiniAtlas in action
Enlarge
WikiMiniAtlas in action

I'd like you to point you to a little javascript extension for your monobook.js file. It displays draggable and zoomable maps in geocoded articles (with a little marker at the article coordinates). Check the instalation instructions and give it a test drive :-)

The next step will be AJAX powered insertion of clickable Wikilinks. Check out a live demo (with german wikilinks) here! --Dschwen 18:35, 19 May 2006 (UTC)

A neat idea. But why does it load so slowly? Rmhermen 21:31, 19 May 2006 (UTC)
Maybe because it is served from my crappy office desktop? If this gets more response it'll have to be hosted on a better connection, ideally on the wikimedia servers. Btw on the german WP the AJAX links are already fully working. If I get to it tomorrow i'll update the version in en:wp. --Dschwen 23:25, 19 May 2006 (UTC)
The new version is available. The map now has clickable links to geocoded articles with little markers at their geographical positions. More links appear gradually when you zoom in. The priority with which they appear is determined by the article length they refer to. --Dschwen 10:12, 20 May 2006 (UTC)

[edit] Categorization of location

I have just created Wikipedia:Categorization of location, proposing a hierarchy of location-based categories. Once widely employed, these will allow the reader to quickly find articles about locations that are near that described by the article they're currently reading. All feedback welcome, as always. AxelBoldt 03:05, 28 May 2006 (UTC)

Why doesn't use: http://tools.wikimedia.de/~kolossos/georef/umkreis.php?submit=%2B&lon=-0.13333299999999&lat=51.5&rang=9.8765432098767&map=1 or http://tools.wikimedia.de/~kolossos/ajax/place-search.php ? --de:Benutzer:Kolossos 12:10, 4 July 2006 (UTC)

[edit] Precision

Is there anything which can be done about the faux-precise locations of cities? It appears that some of the publically available sources people use for coordinates are precise to tenths of seconds of arc, which is somewhere on the order of 3m (10 ft). Unless the data is showing the City Hall (at that precision, perhaps the Mayor's private bathroom in City Hall?), or the geographic center of the municipal boundaries of the city, it seems that one minute of arc precision is all that is necessary to locate even most small villages. Perhaps tens of seconds would be required in locations where villages are small and closely spaced. Many cities are tens of minutes across in at least one dimension. Argyriou 20:22, 21 June 2006 (UTC)

Some of that could be accomplished with a bot. The bot could access the pages at, say, Special:Whatlinkshere/Template:Coor dms, and round off the coordinate values if the parameter "type:city" is present. But rounding off to the nearest minute might be too coarse in certain cases, for example if the coordinates point to the city hall or the city center. --Opie 22:30, 21 June 2006 (UTC)
Or maybe a change could be made to the template itself, so that any pair of coordinates followed by the parameter "type:city" would automatically be rounded off. --Opie 22:34, 21 June 2006 (UTC)

[edit] Why metadata content?

I know that coordinates are extremly useful for any geographical article and this is what makes Wikipedia unique. But could you give me a rationale about why it's included as a metadata content? Why could it be included in the main text, in the lead or in an infobox? Metadata content is hard to find for the new reader, and conflicts with some other content in the same area like the little FA star or the top announcement (like the current one: Early registration for Wikimania 2006 is open until July 9. Scholarships are available; applications are due by June 28.). Thank you. CG 08:05, 25 June 2006 (UTC)

What CG didn't say is that the coor title series of templates are being discussed at Wikipedia:Templates for deletion#Template:Coor_title. --Scott Davis Talk 00:47, 28 June 2006 (UTC)
I posted the message before the discussion started. It was William Allen Simpson who indicated that these coordinates were part of this project. CG 17:38, 28 June 2006 (UTC)
It makes the data easier to extract and harness for other cool projects like (*cough*shameless plug*cough*) User:Dschwen/WikiMiniAtlas. And it follows the idea of the semantic web. --Dschwen 20:53, 28 June 2006 (UTC)

[edit] Celestial Navigation

Wouldn't it be nice to do a similar thing for space? One could parse the information of the Starbox template and generate script files for Celestia...--Joris Gillis 11:33, 30 June 2006 (UTC)

Here's the implementation of external resource page for celestial equatorial coordinates (M100 galaxy):
12h 22m 54.9s +15° 49′ 21″ {{EqCoor|12|22|54.9|+15|49|21|15|M100}}
Right ascension: 12h 22m 54.9s {{EqCoor-RA|12|22|54.9|+15|49|21|15|M100}}
Declination: +15° 49′ 21″ {{EqCoor-Dec|12|22|54.9|+15|49|21|15|M100}}
— friendlystar 16:22, 26 November 2006 (UTC)

[edit] Covering an area

Hello,

I've just recently become interested in geographic coordinates, and the work you guys are doing is certainly very impressive. :)

I was just wondering how people generally handle the problem of areas such as countries and rivers, well even oceans too, most things. Representing them by a precise dot certainly seems wrong, even if the map is way "zoomed out" (so it's a very huge dot)...I read a bit here about using a "bounding box" but that still doesn't seem very precise. Is this really the best method that we've come up with to describe areas? Are there alternative (if uncommon) methods out there? I'm curious. --pfctdayelise (translate?) 06:23, 21 July 2006 (UTC)

For this purpose, generally use {{coor d}} or Coordinates: {{{1}}}° {{{2}}} {{{3}}}° {{{4}}} with no decimal near the centre of the area. The text will give an idea of the area or boundaries. --Scott Davis Talk 07:15, 21 July 2006 (UTC)

[edit] New location point dataset

The following is the result of taking Wikipedia's category links and the NIMA GNS data, and rubbing vigorously. With a number of quite cautious validation checks applied to both datasets, this gives an unambigious location for 12660 out of a possible 28628 (44%) articles about non-US cities, towns and villages.

The results are sorted by country, then place, and binned into four files. They have also been compared to the data in Koordinaten_en_CSV.txt, and labelled by whether they are new coordinates (NEW), or duplicate coordinates already in articles (dup), and, if so, whether they are exact duplicates, or if not, roughly how many km out they are. (The distance calculation uses several approximations, so treat it only as an order-of-magnitude figure).

  • User:The Anome/Geodata 1: countries A-F
  • User:The Anome/Geodata 2: countries G-I
  • User:The Anome/Geodata 3: countries J-M
  • User:The Anome/Geodata 4: countries N-Z

-- The Anome 17:34, 6 August 2006 (UTC) (revised 12:53, 7 August 2006 (UTC), to take into account requests below)

I would be interested in a list with cities/towns/villages where our coordinates differ form the GNS ones by more than, say, 10km; sorted by country, if possible. I'm working on Dutch villages mainly, and such a list would be a good help to correct coordinates. (If its wikipedia that is wrong. The GNS database does contain errors.) Eugène van der Pijll 19:02, 6 August 2006 (UTC)
Yes, GNS is not the cleanest dataset I've ever seen. Eugène, can you point me at a single resource where I can get the existing coordinate/article data in an easy-to-process machine-readable format? If you can, I'd be happy to crunch the numbers. -- The Anome 20:53, 6 August 2006 (UTC)
http://earth-info.nga.mil/gns/html/cntry_files.html has the data per country and in one single 190Mb zip-file. Eugène van der Pijll 22:27, 6 August 2006 (UTC)
Rereading your message, I think you meant the wikipedia data... You may find these files useful; they were announced on here. I haven't looked at them tough. -- Eugène van der Pijll 22:32, 6 August 2006 (UTC)
Thanks! That looks exactly like what I was looking for. I'll take a look... interim result: it seems that of the locations I found, 2959 are for articles with coordinates in en: already, so 9701 of the data points appear to be genuinely new. I'll post the deltas for the 2959 duplicates tomorrow. -- The Anome 02:01, 7 August 2006 (UTC)
OK, here's a dataset showing the differences: User:The Anome/Geodata differences en:GNS; and here is a dataset showing only items for which the difference is greater than 10km: User:The Anome/Geodata differences en:GNS gt. 10km. -- The Anome 11:01, 7 August 2006 (UTC)

Looking at some of the more massive outliers in the error reports above suggests that there are significant errors in Koordinaten_en_CSV.txt: for example, on the Birdwood, South Australia page, Koordinaten_en_CSV.txt has

Birdwood, South Australia -34,819 -138,965 landmark

my GNS-sourced data gives

The article and Google maps both agree with my data. The other dramatic outliers in Australia also seem to be the same problem. -- The Anome 11:33, 7 August 2006 (UTC)

I'm checking the A's now. There are at least some cases where we are right and GNS (presumably) wrong; e.g. Arnia. Eugène van der Pijll 12:09, 7 August 2006 (UTC)
It looks like there was a problem with the collation of data from pages that used {{Geolinks-AUS-suburbscale}}, which Birdwood does. There are two large concentrations of places in the eastern Pacific that should be near Sydney and Adelaide, as well as a few other places from that template. --Scott Davis Talk 13:33, 7 August 2006 (UTC)
I've done some further spotchecking of points with large reported discrepancies (> 100km) against the existing data, (see User:The Anome/Geodata - outliers gt. 100 km) using MultiMap, Google and Yahoo! Maps. The five randomly-chosen points I've looked at so far all suggest that the GNS data is correct to within a couple of km or less from the marked map feature. This is better than I expected: but you're right, Arnia is way off. -- The Anome 14:56, 7 August 2006 (UTC)
The discrepancy in Arnia because of mistakes in matching the GNS data to wikipedia articles. There is more than one Arnia in the GNS database, and you've chosen the wrong one. The same for Ako, Hyogo. Eugène van der Pijll 15:13, 7 August 2006 (UTC)
Gah! I thought I had that cracked: the heuristic I used was that the page had to be the only one of that name in the country (as found by following the category tree upwards), and that there was only one record of that name in that country in the GNS, after various other heuristics had been employed to deal with naming conventions, etc. I can have a go at tracking it down, but not until I've got some more free time. I haven't yet used the subnational region category data, which will require another level of heuristics to tie CC1 ADM1 to Wikipedia subnational regions, but I'll also give that a go next time. -- The Anome 16:47, 7 August 2006 (UTC)
Hi, at the moment I am 600 km away from my computer. Tomorow I am back and cheak this problem. In the last month I change my program. I write the complete source code new. Now I have a perl script. 99 % of error I have found, but not all. At friday I upload an new Koordinaten_en_CSV.txt, because I forget the minus in the south hemisphere. I write a new part of my script which test the both coordinates from EN and DE. The Result is interessting. Only 800 coordinates have more then 2000m difference in EN and DE. In the next week I will present a new intenational CSV-dataset. They include the coordinate with the articlename in eigth important languages. So everybody can produce a KML for spanish or russia wikipedia. If you find more errors or you have question, please write my. I will try my best to fix it. ;-) -- Stefan Kühn 21:12, 7 August 2006 (UTC)
That's good news, Stefan. The more we all work together, the better the results will be. Please let me know when your new, improved dataset is ready, and I'll re-run my program. In the meantime, I'll work on finding and fixing my remaining false disambiguation bugs. -- The Anome 21:31, 7 August 2006 (UTC)
I've found my bug: I was only counting standard (N) and canonical (C) names; the correct Arnia was listed as a variant (V) name, and got missed out, creating the false appearance of a unique name.-- The Anome 21:40, 7 August 2006 (UTC)
And I've found and fixed another bug: this one affected the formatting of templates places with missing-leading-zero degree, or degree-and-minute, values. I've regenerated the listings above accordingly. -- The Anome 01:12, 9 August 2006 (UTC)

Ok, I fix the error in my new script. I wrote "W" for "E", when I extract the "Mapit-AU". I hope I can upload the correct CSV-Data at Monday. The "Templeate:Mapit-AU" is very special, because the frist inside is "long=" and then "lat=". In "Templeate:Mapit-US" first "lat=" and than "long=". Ths is also the reason for some wrong using of this templeate. For example: One Tree Hill, South Australia, Uleybury, South Australia, Canberra railway station, Brampton Island, Queensland, Denistone railway station, Sydney, West Ryde railway station, Sydney, Willoughby, New South Wales. For the future we should change this order, first lat secound long! -- Stefan Kühn 08:53, 13 August 2006 (UTC)

I have upload the new version of KML and CSV. -- Stefan Kühn 08:54, 14 August 2006 (UTC)
Thanks, Stefan. I've regenerated my data using the new versions of your files and the latest en: Wikipedia dump, and User:The Anomebot2 is busily pushing the results into the database. -- The Anome 22:27, 23 August 2006 (UTC)
Done! See Special:Contributions/The_Anomebot2 -- The Anome 22:26, 24 August 2006 (UTC)

[edit] New tag type option

I've added a new option for the type tag on geotags, since lakes do not fit any of the existing tag types: type:lake, with the obvious meaning. -- The Anome 20:37, 26 August 2006 (UTC)

Hi, at the german wikipedia we use "waterbody", so we can also tag bays, fjords, lakes, glaciers ... Please use also "waterbody". -- Stefan Kühn 16:29, 17 September 2006 (UTC)
I'll do that: I've got 327 article to correct, which I will do when I have time. -- The Anome 02:21, 28 September 2006 (UTC)
Done. -- The Anome 17:02, 6 October 2006 (UTC)

[edit] Progress so far

A walk of the category tree suggests that perhaps 140,000 of the current 1.37 million articles on Wikipedia are about places of some sort. Of these, about 48000 are listed in Stefan Kühn's list of geotagged articles, and the Anomebot has so far marked an additional 16000 or so articles with geodata taken from either the GNS or Stefan's listing of coordinates in the de: Wikipedia, making a total of 64000 tagged articles: so just under half of all place articles are now tagged. The actual situation is probably better than this, because a large number of British place articles are currently tagged with OSGB36 coordinates, which Stefan's tool does not yet pick up. -- The Anome 14:25, 9 September 2006 (UTC)

[edit] Template to request coords?

Is there a template people can put on the talk page of an article to request that coordinates be included in the article? Similar to {{reqphoto}} or {{reqdiagram}}. Tnikkel 03:26, 13 September 2006 (UTC)

The German wikipedia has the template {{Lagewunsch}} under Vorlage:Lagewunsch. I wonder if it could be adapted for the English one. --Carboxen 05:40, 13 November 2006 (UTC)

[edit] Village pump discussion

Please participate at Wikipedia:Village_pump_(technical)#Activating_the_mapsource_extension_on_Wikipedia. -- User:Docu

[edit] Update from kvaleberg.com to Template:Coor URL

To simplify updates, I added the new url to that template, rather than to each template using a kvaleberg direct link. A few links still need fixing, try: Special:Linksearch Kvaleberg.com (629 currently, update is a bit delayed). -- User:Docu

It's down to 109 now. Most if not all of them are incorrect uses of the coordinate links or links in test templates/Talk- or other (non article) namespaces.
At least the ones in article namespace should be fixed. A few Serbian infoboxes still need fixing. Some of them include the country's coordinates rather than the city's, or the link points to the coordinates for the country rather than the city, even when displaying other coordinates.
BTW: To fix some of the infoboxes, I made Template:Coor at dms and Template:Coor at dm. It displays the coordinates in the infobox and in the article text (e.g. at Westpac Stadium). -- User:Docu

[edit] Map script problems: bug report

There seems to be something wrong with the new map source page that is now being linked from geotags: for example, if you go to the URL

http://tools.wikimedia.de/~magnus/geo/geohack.php?params=51_25_N_0_12_W_region:GB_type:adm1st

the page is convinced that the location is

51° 25′ 0″ N 0° 12′ 0″ E

rather than the correct

51° 25′ 0″ N 0° 12′ 0″ W

However, the URL http://tools.wikimedia.de/~magnus/geo/geohack.php?params=51_25_N_1_12_W

produces the correct result.

This seems to be a general problem with the degree parsing or rounding code around zero degrees: for example, the URL

http://tools.wikimedia.de/~magnus/geo/geohack.php?params=0_31_S_0_31_W

resolves to

0° 31′ 0″ N 0° 31′ 0″ E

-- The Anome 11:17, 3 October 2006 (UTC)


See also User_talk:Magnus_Manske/GeoTemplate. -- User:Docu

[edit] Wikimapia ?

Hi there,

A newbie question: when I follow a "coordinate" link and get to a page such as [13], I see there a number of links to various useful map servers. But there is none to Wikimapia ([14], with appropriate parameters). Is it possible to add such links? I think such a link would be quite useful, because t would allow a Wikipedia reader, when he reads an article about a city or another place, to get to a page that not only allows him to view a detailed annotated map, but also to participate in a "peer-reviewed" collaborative annotation process, very much in the spirit of Wikipedia itself. ( Vmenkov 17:59, 19 October 2006 (UTC) )

  • There is now a template for linkage to Wikimapia (Template:Wikimapia); however, its format and usage have not been reviewed by this WikiProject, which I think would be useful; this template was recently subject to decimation with the edit comment 'Wikimapia is not a Wikimedia project'(sic). Wikimapia now supports back-linkage to Wikipedia in the form of a simple dedicated input field in the site-editing dialog. An ongoing discussion regarding x-linking Wikipedia and Wikimapia appears at User talk:Alexandre Koriakine, and it might be useful to re-direct this discussion to a sub-page of this WikiProject. --User:Ceyockey (talk to me) 12:56, 21 October 2006 (UTC)
Looks like a duplicate of the geolinks templates (see Category:Coordinates templates). Please replace them with one of those. -- User:Docu

[edit] Project directory

Hello. The WikiProject Council has recently updated the Wikipedia:WikiProject Council/Directory. This new directory includes a variety of categories and subcategories which will, with luck, potentially draw new members to the projects who are interested in those specific subjects. Please review the directory and make any changes to the entries for your project that you see fit. There is also a directory of portals, at User:B2T2/Portal, listing all the existing portals. Feel free to add any of them to the portals or comments section of your entries in the directory. The three columns regarding assessment, peer review, and collaboration are included in the directory for both the use of the projects themselves and for that of others. Having such departments will allow a project to more quickly and easily identify its most important articles and its articles in greatest need of improvement. If you have not already done so, please consider whether your project would benefit from having departments which deal in these matters. It is my hope that all the changes to the directory can be finished by the first of next month. Please feel free to make any changes you see fit to the entries for your project before then. If you should have any questions regarding this matter, please do not hesitate to contact me. Thank you. B2T2 14:46, 25 October 2006 (UTC)

[edit] Announcement: Wikipedia-World

Please, take a look at de:Wikipedia:WikiProjekt_Georeferenzierung/Wikipedia-World/en, it's a project of Stefan Kühn and me. Its in the beta-phase and not ready. We have collected 143.000 coordinates from different Wikipidias worldwide. I'm waiting for your comments and ideas. Perhaps we find on this way somebody who whats to intensive supporting us with programming. For integration of other languages we need a central list of Geotags like the interwikilinks in Category:Coordinates_templates in many languages. de:Benutzer:Kolossos

[edit] Google's Wikipedia Layer in Google Earth

Google have added a wikipedia layer to Google Earth. Official Google Blog: Opening my eyes to a whole new world --Grand Edgemaster Talk 13:18, 10 December 2006 (UTC)

[edit] Machine readability of Wikipedia's geocoding

As mentioned above, Google earth is now offering Wikipedia data. It's a fantastic thing, but it's nowhere near as fantastic as it could be or should be right now because of an important problem: Wikipedias geocoding is only minimally machine readable.

The human readers of Wikipedia consider an article geocoded whenever there is something in the text that looks like coordinates. But, for many reasons, it would be both difficult and unwise for a machine to read our geocoding by taking the HTML rendered text and scanning it for numbers that look like coordinates.

Fortunately, we have standards for geocoding in Wikipedia. ... but we don't really, not from a machine readability perspective. There are many dozens of templates including infoboxes and subject area specialty templates which can be placed in an article to add coordinates which ultimately have the same visual effect as the basic {{coor title d}} template. It is unreasonable to expect third parties to continually update their software to support this ever widening collection of templates.

As a result Google earth isn't managing to grab all the articles which we have geocoded. In order to fix this and to make our data maximally useful for others, we must establish a standard machine readable interface for geocoding. The standard must be simple, support extraction via nothing more powerful than regular expressions (hopefully POSIX re rather than PCRE), not require template traversal (since doing that right will pretty much require that they implement full mediawiki wikitext parsing as well as have a complete and current copy of all templates).

I propose the following:

  1. {{coor title d(m)(s) ... }} and {{coor at d(m)(s) ... }} be declared the standard for basic coordinate insertion.
    ...and perhaps we should remove {{coor title d(m)(s) ... }} and instead add a optional titleonly argument to the other, like {{coor title d|1.0|N|1.0|W||titleonly=1}}. Thoughts?
  2. For all other coordinates inserted via templates (such as infoboxes), we should set the coordinates via a set of standard argument names which are reserved for that use. I propose we use lat_degrees, lat_minutes, lat_seconds, lat_direction, long_degrees, long_minutes, long_seconds, long_direction. All infoboxes and other templates which take coordinates would be required to use these arguments. Any use of these argument names in a template would be taken to be a specification of the coords for the page the template is used on. Any template which uses these argument names for any non-geocoding purpose would be taken out and shot.
    There are many other sets of these in use today. Perhaps the most notable alternative is latd, latm, lats, latns,longd. I do not believe these are sufficiently unique argument names.
  3. Funny business like building up the location using tranclusion, such as {{coor title d|{{expandto81}}|N|{{expandto43}}|W}} would be declared unsupported.
    It would be easy enough to run a bot to catch weird/broken uses of the standard templates.

I *think* these two cases would solve our current uses. Templates such as {{Geolinks-US-cityscale}} could be switched to the second mode of operation, by switching it to using named arguments. Google currently supports a superset of what I've proposed above, but I believe the proposed would fit our needs.

I really need comments on this, because I'm sure I've overlooked some stuff. Once we reach a consensus I'll begin coding a bot which will convert all the cases I can find into whatever standard we decide on. --Gmaxwell 20:43, 11 December 2006 (UTC)

Retrieved from "http://en.wikipedia.org../../../w/i/k/Wikipedia_talk%7EWikiProject_Geographical_coordinates_0907.html"