Wikipedia talk:WikiProject Geographical coordinates/Archive 2

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. [worldwind://goto/world=Earth&lat=&lon=&view= 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 ===

with NASA World Wind.
 * [worldwind://goto/world=Earth&lat=&lon=&view= Find this location]
 * 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:
 * &lt;?

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

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 on how to add new URL types, like [worldwind://goto/...]. NevilleDNZ 03:12, 7 Jun 2005 (UTC)

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)

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.95°N, 7.41667°W. 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 in German and French (see PDF), and one in German Wikipedia. The old observatory's coordinates can be found at Bern. Converters are at, , , 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 . 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 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

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 Gis, so I would appreciate if you could investigate. -- Egil 06:19, 24 August 2005 (UTC)

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 . 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. coor|48_46_36.48_N_121_48_51.84_W|Special:Mapsources/48_46_36.48_N_121_48_51.84_W 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 ==  that is the real barrier no? --Plowboylifestyle 20:15, 14 Mar 2005 (UTC)

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:
 * 2) A references to a Wikipedia image (the image of course depicts a map.)
 * 3) A set of geo-point to pixel relations that define the map space.
 * 4) A set of projected geo-points to text relations (the text can include any wikimarkup).
 * 5) 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.)
 * 6) The script generates an image where numbers are overlayed at the correct points on the map.
 * 7) 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)