Geographical coordinates

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

Archives

Index Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 Archive 14 Archive 15 Archive 16 Archive 17 Archive 18 Archive 19 Archive 20 Archive 21 Archive 22 Archive 23 Archive 24 Archive 25 Archive 26 Archive 27 Archive 28 Archive 29 Archive 30

Index

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

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

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

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

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

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

• BS&WR route map

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

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

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

Could you give some examples of your table[s] of named tributaries including coordinates for the confluences, please? I'm working one something similar, and would like to compare styles. Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:55, 10 September 2008 (UTC)[reply]

One of the searches at WP:GEO#Coordinates_search_tool brought up a series of odd region codes:

• "region:Northern_Cyprus".
• "region:OuterSpaceTreaty"

Which are the WP:GEO#region:R codes to use? Others, such as "Europe", "Asia", "Netherlands" should be fairly easy to fix. -- User:Docu

"region:Northern Cyprus" should be region:CY (per ISO 3166-1),

more specifically region:CY-nn (per ISO 3166-2:CY and Districts of Cyprus) where CY-nn is either:

• CY-01 Kyrenia
• CY-02 Nicosia
• CY-03 Famagusta
• CY-04 Larnaca
• CY-05 Limassol
• CY-06 Paphos

"Northern" to me would mean either Famagusta or Kyrenia in the "Turkish" Northern part; but some view "Cyprus" as meaning either only the "Turkish" North or the "Greek" Southern part. So "Northern Cyprus" might only exclude Limassol in the Southern part depending on the context. LeheckaG (talk) 11:14, 27 August 2008 (UTC)[reply]

The "region:OuterSpaceTreaty" coordinates represent geo-stationary satellites with a "type:satellite". http://toolserver.org/~dispenser/cgi-bin/geosearch.py?regexp=region%3AOuterSpaceTreaty

Again "Altitude or Elevation" would be a good optional parameter to have.

The (2) options are either:

• ISO 3166-1 alpha-2 defines "ZZ" as "International Waters" not otherwise assigned?
• use the XX-YY code for the corresponding surface feature underneath the satellite shadow.

LeheckaG (talk) 11:42, 27 August 2008 (UTC)[reply]

In the meantime, I fixed all but the CY and OuterSpace ones. ISO 3166-2:CY seems a bit odd, but possibly the only solution.

ISO 3166-1 alpha-2 lists "XZ" not "ZZ". Apparently it's UN/LOCODE that uses it that way. For oceans, we could use this. Together with type:satellite, I suppose we could use this for satellites above.

I'd favor adding type:satellite and region:XZ to the definitions on WP:GEO. -- User:Docu

An important problem with {{coordinate}} is on its documentation page: Currently not implemented. Until it becomes a real template, I don't think it reasonable to interfere with discussions about using {{coord}}. —EncMstr (talk) 21:47, 27 August 2008 (UTC)[reply]

Pardon me? Úlfljótsvatn Scout Center. --Dschwen 22:35, 27 August 2008 (UTC)[reply]

Once more, documentation is Achilles' heel. We're not telepathic and we just don't want to have to research usage by using "What links here". Do you not think? --Tagishsimon (talk) 22:55, 27 August 2008 (UTC)[reply]

The template as such works. It's already used at least 75,000 times elsewhere.

As in en.wikipedia.org, we already have three other systems, we should avoid starting to use this one, until we are sure we want it.

Before my edit of today [1], it was made to work only outside of article namespace. -- User:Docu

Those 75,000+ times must be on another wiki. There are 45 references on English; 17 are transclusion articles—the rest are links (non-transclusion), mostly from documentation. Is the English template:Coordinate identical to those used heavily elsewhere? Where is it being heavily used? —EncMstr (talk) 01:25, 6 September 2008 (UTC)[reply]

It's on de:Special:MostLinkedTemplates. I came across it more or less by chance. It's replacing there the equivalent of {{coor}}, a template we never used much here (no relation to coord/coor title d).

I copied their version without much change. It appears to have been made to be ported. There are one or two minor features I removed, e.g. one that forces editors to add a "name=" each time it's used inline. You should see my changes documented in the edit history. -- User:Docu

I've been experimenting with coordinate, but identified some missing parts. {{coordinate|NS=45.3734512|EW=-121.6956316|type=mountain|region=US-OR|source=gnis|elevation=3429|text=DEC|article = DEC}} gives 45°22′24″N 121°41′44″W / 45.3734512°N 121.6956316°W / 45.3734512; -121.6956316. Also, if a preview is scrutinized, {{Coordinate to DEC}} is redlinked. It appears to display a coordinate as decimal degrees (not DMS). Another missing template is {{Info ISO-3166-2}}. I don't know what it's for but it seems associated with article=DEC .

I also traced how {{coordinate|type=mountain|elevation=X}} works. If type isn't "mountain" it seems to ignore elevation. But with a mountain type, it outputs _type:mountain(X). So if elevation is desired in {{coord}}, perhaps that's all that needs to be added to coord. But since I don't understand how that is translated, maybe geohack(?) should parse an elevation:X parameter and provide it for the geotemplate? I've been adding _elevation:XXX to coord's glommed parameters on a few articles anticipating this will be added. —EncMstr (talk) 04:12, 10 September 2008 (UTC)[reply]

In the meantime I imported {{Coordinate to DEC}} which is why the above sample displays correctly (Template_talk:Coordinate/Samples_1). Template:Info ISO-3166-2 is called by Template:CoordinateRR DEFAULT, but could probably be removed. Template:CoordinateRR DEFAULT varies the way coordinates are displayed based on a region code. Ideally it should enable OSGB36 for GB if that was implemented. -- User:Docu

You may want to look into my comment at Template_talk:GeoTemplate#Edit_article_link. -- User:Docu

See Template_talk:Coor_title_dm#More_precision_needed. Silsand is an example of an affected article. Carcharoth (talk) 14:46, 31 August 2008 (UTC)[reply]

I've changed Silsand to use {{coord}}, with display=title, which has fixed the problem. Once again, rather then expending energy fixing a redundant template, conversion to coord would be the sensible approach. Andy Mabbett | Talk to Andy Mabbett 14:55, 31 August 2008 (UTC)[reply]

Thank-you. I'm not really aware of what the different co-ord templates mean, just that there are a lot of them! It would be easier if there were less templates, I agree. I have just read Wikipedia_talk:WikiProject_Geographical_coordinates#coord_template_one_year_on, and it looks interesting if difficult for outsiders to get a handle on what is going on. If I got more involved in co-ord templates, I might have a stronger opinion, but for now I'm just trying to spot errors and point out some things. A recent development I'm rather excited about is generating polar maps. See Template_talk:GeoGroupTemplate#Polar_co-ordinates. Carcharoth (talk) 15:20, 31 August 2008 (UTC)[reply]

[outdent] To summarise; {{coord}} is intended to replace nine other templates:

• {{coor title d}}
• {{coor title dm}}
• {{coor title dms}}
• {{coor d}}
• {{coor dm}}
• {{coor dms}}
• {{coor at d}}
• {{ coor at dm}}
• {{ coor at dms}}

As well as introducing additional functionality, that change is intended to reduce the very confusion to which you refer. Yes, the Polar mapping work does look promising. Andy Mabbett | Talk to Andy Mabbett 15:31, 31 August 2008 (UTC)[reply]

[/outdent]

If you want to add seconds to {{coor title dm}}, you'd need to switch to {{{coor title dms}}. -- User:Docu

Ah, I should have realised what d(egrees), m(inutes), and s(econds) stood for! :-) Carcharoth (talk) 16:35, 31 August 2008 (UTC)[reply]

Not a problem with {{coord}}, which accepts and understands "D-M-S", "D-M" or "D" values, including decimal versions of the latter. Andy Mabbett | Talk to Andy Mabbett 16:57, 31 August 2008 (UTC)[reply]

Looking at Wikipedia:GEO#type:T, I was wondering how the various scales for different features were worked out. To my mind the one for railway station is too small a scale (zoomed out too far), but that may be just me. Talltim (talk) 16:58, 31 August 2008 (UTC)[reply]

The scale for type:railwaystation hasn't been activated yet (geohack currently uses the default 1:300,000 instead of 1:10,000). I hope Magnus will have time to update it soon though. --- User:Docu

type:railwaystation now works. -- User:Docu

Docu, I notice you've changed scales on some articles where I added coordinates with an appropriate scale. For example, at 120th meridian west, the CA-NV border map was scaled to provide a view of parts of the two states, with the map about 100 miles across. You changed it so it focuses on a tiny part of Lake Tahoe which is featureless blue. Is there an explanation for this? --JWB (talk) 20:07, 31 August 2008 (UTC)[reply]

The list includes a series of geographic features. I just set the type: according to these features, rather than a random one. If you like to provide a specific scale, please use scale: rather than type:. BTW adm2st isn't a valid type, it showed up one the #Geolocation_search_tool. -- User:Docu

adm2st must be a typo for adm2nd. But adm1st and adm2nd are widely used and documented. Canadian provinces and US states are first-level administrative divisions, hence adm1st. Santa Rosa Island and Santa Barbara County are county-sized, hence the scale for a second-level administrative division. I could have used a numeric scale initially but the documentation at Template:Coord/doc and elsewhere seemed to suggest the use of these codes. If they are not recommended, why are they documented as such? --JWB (talk) 23:40, 31 August 2008 (UTC)[reply]

On 120th_meridian_west, the feature listed is called "British Columbia / Alberta border" rather than "British Columbia" or "Alberta". If the feature was "Alberta" "type:admin1st" would be appropriate. As there is no specific type for borders, I used "type:landmark".

The idea is to use "type:" to describe the feature and let this scale the maps, rather than decide on the scale and then select a corresponding type. If one wants to select just the scale, "scale:" is appropriate. -- User:Docu

I have found that using both scale: and type: is appropriate. There can be many situations where a different scale than the default for a defined type is more suitable, but there should be no reason to omit the type because of the manual scale setting. Type, I'm sure, aids in classifying the object for various purposes and applications which are only beginning to emerge.

I find for _type:railwaystation that it matters greatly whether the object is a downtown metro station or a railway station in the mountains, and I have offset the scale accordingly. __meco (talk) 09:25, 1 September 2008 (UTC)[reply]

The border is not a single point, it is a line about as long as the provinces / states themselves, so the scale for the provinces / states is also appropriate for showing the border. In general, scale for a border should default to the scale for the territorial units that border. --JWB (talk) 23:45, 3 September 2008 (UTC)[reply]

When coordinates are provided for similar features, specific types for such features would probably be useful. (e.g. type:road, type:border). BTW in one wiki, the coordinates automatically categorize articles by longitude, e.g. eo:Kategorio:120°_U. -- User:Docu

I sometimes use google earth, and sometimes my GPS device to mark the coordinates. What should I use in the "source" parameter? WGS84 or GNIS? =Nichalp «Talk»= 10:27, 4 September 2008 (UTC)[reply]

The source parameter is mainly used by bots. In general, if you check several sources, there is no need to add it.

If the coordinates are sourced from GNIS, one would use source:gnis.

All coordinates for Earth should use the WGS84 datum only (see WP:GEO#Geodetic_system). Your GPS most likely uses that. Coordinates with a globe:G parameter wouldn't use this though.

BTW the geohack extension currently doesn't use the source parameter. -- User:Docu

Thanks Docu. So, can I add source:WGS84 to geotag my images for future compatibility? Does it make sense to do so, or leaving it blank should suffice? Regards, =Nichalp «Talk»= 14:18, 5 September 2008 (UTC)[reply]

As the map datum for all conversions in the geohack extension needs to be WGS84, coordinates in other formats are not compatible and shouldn't be used (e.g. the quote on Cape Howe [2]). Unless at commons, there is a different policy for images, I'd just drop the source parameter in your case. -- User:Docu

Commons recommends adding them. Since I upload my photos there, I guess I will use it. Regards, =Nichalp «Talk»= 16:47, 5 September 2008 (UTC)[reply]

I didn't find anything on Commons:Geocoding. Looking at tools:~dispenser/cgi-bin/geosearch.py [3], it appears that "source:exif" is popular.

Re-reading WP:GEO#Geodetic_system, I thought it might mention that only coordinates entered in templates like {{oscoor}} would use a different datum. -- User:Docu

Commons:Geocoding#Geodetic_system says this: "All coordinates should be referenced to the en:WGS84 datum, the one supported by GPS systems and Google Maps." =Nichalp «Talk»= 07:28, 6 September 2008 (UTC)[reply]

Great Britain has it's own British national grid reference system; it's legitimate for articles about places in GB to use that, instead of or (better) in addition to WGS84 coordinates. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 11:22, 6 September 2008 (UTC)[reply]

It looks like commons requires you to use WGS84 as well, but you don't need to specify it in the source: parameter. -- User:Docu

I've been checking various San Francisco landmarks against the Wikipedia links that pop up on Google Earth. I've noticed that there are some spots, for example the Condor Club, that have coordinates listed in the article, but do not have a Wikipedia link show up on Google Earth. Is there some way that Wikipedia article need to be coded so that they link to Google Earth? Or is there some kind of Google Earth database one needs to submit these articles to? Iamcuriousblue (talk) 15:36, 4 September 2008 (UTC)[reply]

Use {{coord}}, with "display=title" or "display=inline,title" . Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 15:42, 4 September 2008 (UTC)[reply]

They seem to use a copy of the database instead of the live site, so it can be months between when coordinates are added to an article and when they finally show up on Google Earth (and Google Maps) in an eventual update. *Dan T.* (talk) 22:04, 13 September 2008 (UTC)[reply]

Please check WT:WikiProject_Western_Australia about the coordinates in List of homesteads in Western Australia. Maybe we can just convert to some other template and the problem will fix itself. ;-) -- User:Docu

Yes. Any bot converting coor * to {{coord}} could fix such problems as part of the same process. Or perhaps instead of adding checks for such problems to multiple archaic templates, you could work towards adding them to {{coord}}. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 22:44, 5 September 2008 (UTC)[reply]

Thank you for helping us fixing that. With whatever template you prefer. -- User:Docu

The choice of coordinates template should not be a matter of personal preference; almost all editors commenting agree we should standardise on one. {{coord}} is clearly better than coor *, despite the demonstrable bias in, and incompleteness of, the summary of attributes you have provided. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 23:04, 5 September 2008 (UTC)[reply]

You are free to disagree. In regards to [4], I even concede that it's not obvious why the coordinates on Ploshchad Tukaya (Kazan Metro) are still wrong, but by converting to {{coord}}, you are hiding the problem. -- User:Docu

Is their anyway too hide the blue globe which appears when using {{coord}} Gnevin (talk) 21:28, 5 September 2008 (UTC)[reply]

Meta:WikiMiniAtlas explains what to add to your monobook.js file (enabled: false or onlyTitle: true). Possibly it works. -- User:Docu

Possibly?! Of course it works!!! ;-) --Dschwen 22:36, 5 September 2008 (UTC)[reply]

It does .. just noticed that I still had the script in there from prior to when it was activated. -- User:Docu

I don't want to edit my monobook, I mean hide it as a stylistic choice for a project or infobox Gnevin (talk) 00:12, 6 September 2008 (UTC)[reply]

46°29′37.8″N 8°5′51.5″E / 46.493833°N 8.097639°E / 46.493833; 8.097639 -- User:Docu

No, a stylistic choice should not trump the functional behaviour and make the interface behave inconsistently. --Dschwen 02:47, 6 September 2008 (UTC)[reply]

How would hiding the globe effect the functional behaviour? No Docu, the other way with the coordinates showing but no globe Gnevin (talk) 14:21, 6 September 2008 (UTC)[reply]

Do I really have to spell that out? It would affect the functionality by removing the possibility to show the location on the WMA. --Dschwen 21:58, 7 September 2008 (UTC)[reply]

To some extent the two types duplicate each other. Most of the articles currently using type:state are those about states of the US.

Contrary to what we concluded earlier (#type:state,_adm1st,_adm2nd), US counties don't use type:adm1st but type:adm2nd (The Anome added most if not all of them, I changed 4 or 5 that did use type:adm1st to match that).

To simplify things, I'd do away with "type:state" and use "type:adm1st" for any of those listed on Table_of_administrative_country_subdivisions_by_country#Table, including US states. -- User:Docu

Absolutely. A U.S. state is a first-order division of the larger United States of America, so counties, as the next level down, must be a second-order division. -- The Anome (talk) 19:59, 13 September 2008 (UTC)[reply]

If there is a better place for this, let me know. Has anybody gotten anything like this to work? http://www.ogleearth.com/2006/11/fortiusones_geo.html (geoiq seems to be down now) It'd be cool if we could mashup wikipedia data in a heatmap like format using something like DBpedia, http://wiki.dbpedia.org/UseCases#h19-4 etc. So, if you've gotten this to work, please let us know. Thanks. --Rajah (talk) 01:16, 7 September 2008 (UTC)[reply]

Apparently http://www.geoiq.com/ is still down. There are various tools that generate markers for selections of wikipedia to google, but they don't generate heatmaps. -- User:Docu

Hi all,

I have written a Perl script, Nichalp's upload script, that you can use to batch upload your photographs to Wikimedia Commons. The script has a lot of functions including:

1. adding infoboxes, categories, and geoboxes;
2. embedding your name, caption, and GPS data as Exif data;
3. autorotation of images to correct the orientation;
4. renaming images on-the-fly; and
5. rigorous checking to ensure that categories, licences and descriptions are added.

Do have a go at testing it. Regards, =Nichalp «Talk»= 06:56, 8 September 2008 (UTC)[reply]

See Template talk:Coord#Coord needs repair (on 1844 pages). -- User:Docu

What a remarkably low figure, give the number of instances of the template. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:34, 15 September 2008 (UTC)[reply]

I investigated and cleaned up a few of these article. Many I chose had existing UTM coordinates converted by Elkman using, according to the edit summary, UTM to degree/minute/second conversion script. The only class of error was 123|5|60. Elkman is also associated with the same type of unnormalized value in List of Registered Historic Places in Orange County, California in this edit by Doncram summarized as add Elkman-table-generator generated table for all OC NRHPs as of January 2007. a few edits to names to wikilink to existing articles.

Another class of errors are represented by List of airports in the Netherlands: 123|10|88. It's hard to imagine that was caused by any computational error. Perhaps a decimal number interpreted as faux dms. I've asked the editor who added it how he got it. —EncMstr (talk) 16:42, 16 September 2008 (UTC)[reply]

Hi!

MOS requires a unicode minus (U-2212) to represent a minus or subtraction operator for display. But if a template tries to evaluate that expression, parser functions #expr and #ifexpr break (bugzilla 15349). This new commit fixes that. It should be live in English wp in about a week, I don't know about others.

Didn't know if you guys were interested. Enjoy. Saintrain (talk) 00:19, 16 September 2008 (UTC)[reply]

Thanks for letting me know.

While I can see the advantage from a typographic viewpoint, most software is still Unicode-unaware, and using Unicode minus signs will break all sorts of tools that only understand HYPHEN-MINUS when parsing numbers, including dump-parser code used for geodata maintenance. If we're not careful, we will end up propagating bad data through the system, regexes and number-parsing routines in most external tools will fail and negative numbers will be either ignored, or worse, turn into positive numbers.

Have the Kolossus team and Google's representatives been told about this? -- The Anome (talk) 08:40, 16 September 2008 (UTC)[reply]

Update: see User:The Anome/Unicode coord test for a test case; currently the top two test cases are completely broken because the changes above have not yet been applied. It'll be interesting to see what happens as the software evolves.

However, the following test case does work, but currently breaks the Geohack page on the toolserver:

Here's a direct URL for the geohack page, using HYPHEN-MINUS in the usual way -- note that the minus sign turns 1° N into 1° S:

http://stable.toolserver.org/geohack/geohack.php?params=-1_N_1_E_

Here's the same thing using MINUS SIGN, which would happen if data was entered into a template using this convention -- the toolserver page ignores the minus sign:

http://stable.toolserver.org/geohack/geohack.php?params=−1_N_1_E_

I think a lot more testing is needed throughout the entire geodata ecosystem before we consider going live with this. I know all my current tools will break -- the fixes are trivial, but I will need to apply them to all of the tools, and then re-test them all. As the current single largest producer of Wikipedia geodata, I certainly won't be outputting templates with MINUS SIGNs embedded until I'm confident all significant downstream consumers can parse it correctly.

Perhaps the creation of "ASCII-number" and "Unicode-number" parser functions that perform the obvious textual transformations their names imply might help this transition? -- The Anome (talk) 10:00, 16 September 2008 (UTC)[reply]

I think the geohack, wikiminiatlas etc are brilliant and would be very disappointed were any of them to break. I think the distinction between minus and hyphen is silly "what colour would you paint the wheel" nattering. I am not advocating nor encouraging a switch to minus.

But if someone else does follow the MOS and use a minus, at least parts of the chain won't break anymore. I thought that knowing that #expr won't choke on a minus anymore would make things easier. One less thing to worry about. Sorry. Saintrain (talk) 15:33, 16 September 2008 (UTC)[reply]

WikiMiniAtlas should now be prepared for a possible introduction of MINUS SIGN. --Dschwen 15:46, 16 September 2008 (UTC)[reply]

I've tried to put the following co-ords with the nice globe thingy at the top left hand side of Larmer Tree Gardens, but Captain Cockup is at home today. I've tried following the instructions in the MOS but to no avail. Could anyone help out please? Co-ords are 50 deg, 57 mins, 06.82 secs N; 2 deg, 04 mins 59.86 secs W. Thanks. Roisterdoister (talk) 14:22, 16 September 2008 (UTC)[reply]

Oh, I meant to ask - can we link to Google Earth images? Is that allowed? Roisterdoister (talk) 14:24, 16 September 2008 (UTC)[reply]

I've added a coord for the place - best that you check it by clicking on the link at the top. The Mapserver provides a link to Google earth, so "no" is the short answer to your question, for the reason that a link is already provided ... we do not single out single map sources on the article page.

Any analysis of which part didn't work for you would be handy: we know that the documentation is not the best, and knowing where it went wrong for you would help us improve matters. Maybe. --Tagishsimon (talk) 14:53, 16 September 2008 (UTC)[reply]

Thank-you, that was quick! I've checked and it's perfect. Didn't realise about the Mapserver thing linking to Goggle Earth, dur. My failed attempt is here: [5]. I probably did something really stupid ... Roisterdoister (talk) 15:01, 16 September 2008 (UTC)[reply]

You used coor title dm and then supplied it with second parameters, which would probably have worked with coor title dms (note the last s). But we're playing coord games and deprecating coor * nowadays in any event. Glad it's all sorted out. --Tagishsimon (talk) 16:18, 16 September 2008 (UTC)[reply]