Wikipedia talk:WikiProject Geographical coordinates/Archive 21

Has there been any discusion on mapping rivers and autoroutes other than mapping names along these polylines? __

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]

The project page says As of August 2007, there are several different high-level ways of entering coordinates, with no clear consensus on the best way. The most popular techniques are... and lists the various coor * templates, plus coord. {{coord}} was created, over a year ago, with community consensus, the support of Google, and the explicit intention to provide the functionality of all of coor *, which were then to be replaced (bots were lined up to do so). Why has this not been done? Consider a newcomer to Wikipedia, and the confusion so many redundant alternatives will present them with. Andy Mabbett | Talk to Andy Mabbett 15:51, 26 August 2008 (UTC)[reply]

Perhaps because, one year on, there has been no observable problems with maintaining the status quo. It seems that there is no evidence that the 'confusion' actually exists.

Crispness (talk) 16:01, 26 August 2008 (UTC)[reply

]

I agree with Andy here. Deprecating and eventually removing the old coordinate templates would make this whole bussiness cleaner. There is no benefit to keeping them. If the instructions can be shortened by even one sentence that would already make removal of the old templates beneficial. --Dschwen 16:07, 26 August 2008 (UTC)[reply]

Do the older coor * templates emit a geo microformat like coord ? Perhaps if they lack such it might be justification for deprecating the older templates?

Admittedly, I prefer using one coord template to the family of coor * templates (yes, I realize transcluding coord includes a few coord/ sub-templates); mostly using coord with DMS N and DMS W coordinates with the display=inline,title parameter; except for additional related-coordinates in "list" or similar articles where I omit the display= and let it default to display=inline. I try to supply as many coordinates parameters as known (region: type: source:) but often do not take the additional time to set a more appropriate map scale:. I set the name= parameter when there is more than one set of coordinates in a list article.

Where Geo- or Info- boxes use a Location (pushpin) map, I try to use it, and have been trying to get their corresponding templates updated so that they have a way to set the coordinates parameters (usually more of a political than technical challenge).

The use of coordinates in the templates and in geo microformats cite the corresponding IETF RFCs (coordinates in DNS records, and MIME vCARDS) as the basis for their standardization, and the one component which I feel is missing is the optional altitude/elevation parameter specified in those RFCs, there is a geo microformat proposal to reintroduce altitude/elevation, so the (coord) template which emits the geo microformat should accept an optional altitude/elevation parameter (the 'coordinates in DNS' RFC specified 'meters above mean sea level' as the default units, unless an optional units parameter was suffixed). LeheckaG (talk) 16:43, 26 August 2008 (UTC)[reply]

Do the older coor * templates emit a geo microformat like coord ?

No: that was one of the reasons why {{coord}} was written. Andy Mabbett | Talk to Andy Mabbett 16:48, 26 August 2008 (UTC)[reply]

Somewhat unrelated. I think a single template like coord is a big improvement -- but it would really be nice if it were made easier to use. I mean, the way parameters are just glommed together is very awkward (eg {{coord|43|16|40|N|85|48|37|W|region:US-MI_type:city_scale:30000_source:GNIS|name=Bailey, Michigan}}. Couldn't region, type, scale, source all be made separate parameters instead of the weird concatenation? older ≠ wiser 16:53, 26 August 2008 (UTC)[reply]

My educated guess as to the parameter reasoning - is that geohack.php/GeoTemplate has (2) kinds of parameters: those "globbed" together and separated in the URL with underscore "_" characters in place of spaces, and a few "named" parameters which use "&" as a field/parameter separator. While it is possible to modify coord so that it accepts separate named or positional parameters and then either coord or geohack.php/GeoTemplate handles concatenating or rearranging them. The "globbed"-together parameters allows other (new) parameters to be accepted without needing to modify several components (coord, geohack.php GeoTemplate) to accommodate them, instead changes are "localized" to updating either geohack.php or GeoTemplate (depending on the change) without needing to update Coord. LeheckaG (talk) 17:55, 26 August 2008 (UTC)[reply]

Considering that we do want to move to an easier solution, given that coord has other drawbacks than the coor * family, I think the solution provided by {{coordinate}} is an interesting one to consider. It was developed based on the experience with {{coor at dms}}, {{coord}} and an other even more complicated template that was used other languages. -- User:Docu

given that coord has other drawbacks than the coor * family, - No. that's not "given". Please explain what drawbacks you think {{coord}} has, and why, if there are any, they could not be remedied? Does the new template output a geo microformat? Does it allow users to control in which format coordinates appear? Andy Mabbett | Talk to Andy Mabbett 18:20, 26 August 2008 (UTC)[reply]

Personally, I am more of a proponent for "minor" updates to Coord (and making sure that Commons:Template:Location remains in synchronization with it). Template Coordinate offers (besides what Coord/Location currently does):

• elevation in m. above sea level
• globe (earth, moon, mars, venus, mercury, ...)
• dimension (in meters) of object's (longest?) linear measurement

de:Vorlage:Coordinate or translated by Google http://translate.google.com/translate?u=http%3A%2F%2Fde.wikipedia.org%2Fwiki%2FVorlage%3ACoordinate&hl=en&ie=UTF8&sl=auto&tl=en

there are a few other features like setting a sortkey (for tables) or alternative names, ...

Personally, elevation is the only "requirement" for my uses.

I can see where globe= benefits non-Earth articles. I have mixed feelings about dimension=, can see where a "reasonable" surface dimension could be used to set a scale:, but I am not sure how many contributors would set a reasonable dimension? LeheckaG (talk) 18:52, 26 August 2008 (UTC)[reply]

IMHO, the main advantage of {{coordinate}} is that it avoids the main drawback of {{coord}}:

that is, as it was expressed above, in {{coord}} parameters are "glommed" or "gobbed" together.

It also nicely splits out the region: and type: that all templates merge into one field. -- User:Docu

Back to the original point: How about deprecating the laundry list of templates to a minimal set? Many members of

Personally, I think we should consider moving on to {{coordinate}}.

BTW we already reduced the number of geolinks templates. Obviously, the ones that remain aren't the ones with the fewest uses. -- User:Docu

You seem to have overlooked these questions: Please explain what drawbacks you think {{coord}} has, and why, if there are any, they could not be remedied? Does the new template output a geo microformat? Does it allow users to control in which format coordinates appear? Andy Mabbett | Talk to Andy Mabbett 19:15, 27 August 2008 (UTC)[reply]

I think one of Coord's main drawbacks is the "glommed" parameters. Coordinate looks cleaner. However if Coordinate lacks support for geo microformat - or other features on a consensus shopping list - then could not microformats be added to it? I entirely endorse EncMstr comments; as one who believes the template design makes working with geo stuff more difficult than it needs to be, I do urge you who know this stuff much better to work towards fewer, better documented templates. (And could we please have an option to take control of scale when we wish to ... landmark, city, lake, just does not cut it for me when these things vary so enormously in size.) --Tagishsimon (talk) 20:33, 27 August 2008 (UTC)[reply]

' ":I think one of Coord's main drawbacks is the "glommed" parameters ' which are the same, are they not, on all of "coor *"? In which case, that shouldn't stop the latter from finally being replaced, while we consider whether to add the other features to {{coordinate}} or fix - if necessary - the "glommed" parameters on {{coord}}. Indeed, I wonder why that was not done, instead of yet another template, {{coordinate}} , being created. Andy Mabbett | Talk to Andy Mabbett 20:48, 27 August 2008 (UTC)[reply]

Eliminating "coor *" whilst we haggle between & about coord & coordinate would be a step forwards, IMO. --Tagishsimon (talk) 20:52, 27 August 2008 (UTC)[reply]

As to "controlling the scale:", when a "scale:" is supplied, it overrides any default scale: supplied by type:

If the {{Coord}} template's major drawback is the concatenated coordinates parameters: (region:_type:_scale:_source:), then it is not that big a deal to add optional named parameter fields region=, type=, scale=, source= and have the {{Coord}} template do the concatenation "behind the scenes". Already concatenated parameters could still be supplied in a positional parameters field after the other positional coordinates (for those who prefer that format). If such optional named parameters are added, then the same changes should be done to the Commons:Template:Location so that they remain "in synchronization".

The current "positional" parameter format would mostly be re-used by Geo- and Info-box templates which build up a Coord template from separate fields, whereas an optional "named" parameter format could be used by contributors who choose to do so. "Normally" a named parameter should take precedence over a positional parameter. LeheckaG (talk) 21:18, 27 August 2008 (UTC)[reply]

Scale: thanks. Would I then be right in thinking that the parameters I've just added in this edit to the coord documentation are correct? Am I right in thinking that we are better off putting pertinent documentation on the template page than in the middle of the project page? (Okay. It occurs to me as I;ve been doing this that if there is a set of parameters common to the coor * and coord templates, we would be well to maintain them in one place, but could we not at least transclude them into the relevant template pages?). Apologies - I seem to have digressed: could we keep pursuing the reduction of templates issue. --Tagishsimon (talk) 21:28, 27 August 2008 (UTC)[reply]

I fail to see what the advantage of having named parameters is. The scale parameter for example is never used in the template logic. It may be used in the GeoHack which would have no problems parsing the concatenated parameters, and it is used by the WikiMiniAtlas, which also has no problems parsing the concatenated parameters. IMO this is a non-issue and should not be held against {{Coord}}. --Dschwen 03:20, 31 August 2008 (UTC)[reply]

It seems that there is still active resistance to changing from coor * to coord; though quite what the specific objection to the change is; or why it is though that the change should have been "discussed", is not stated. The reversion cited leaves pages about Swiss Towns without Geo microformats and prevents users from electing to see the coordinates in their preferred format. Andy Mabbett | Talk to Andy Mabbett 21:38, 30 August 2008 (UTC)[reply]

Three doesn't seem to have been an answer to this. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 10:59, 6 September 2008 (UTC)[reply]

The problem with the "glommed" or "gobbed" parameters isn't just limited to scale/region/type, but the coordinates themselves. Latitude and longitude in degrees/minutes/seconds. Coordinate has the advantage of separating latitude and longitude and labeling them fairly intuitively. -- User:Docu

{{coord}} allows users to enter coordinates as separate D M S values; or as decimal values, with Northings and Eastings, or as +/- decimal values. Does {{coordinate}} do that? Andy Mabbett | Talk to Andy Mabbett 23:45, 27 August 2008 (UTC)[reply]

Summing up

So; are there any reasons why {{coord}} cannot now replace the coor * family? Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 21:11, 3 September 2008 (UTC)[reply]

None? Is there anyone other than Docu (talk · contribs) who doesn't agree that we should do so, then? Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 23:25, 5 September 2008 (UTC)[reply]

I take it that we have consensus, with just one dissenting voice. I'll shortly request a bot to complete the conversion of corr * to {[coord}}. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 10:44, 8 September 2008 (UTC)[reply]

Pigsonthewing, I think you overlooked the subsequent sections and the unsubstantiated claims in your "2nd summary". This being said, I don't mind if you convert them to {{coordinate}}. -- User:Docu

My name, as I have repeatedly told you, is Andy Mabbett. I have taken full account of all the discussion on this page, including the parts where other editors have noted that {{coordinate}}, which apparently lacks the required functionality and cannot be used in sufficient quantity on a single page, is irrelevant to this issue. You say I have made unsubstantiated claims. I have invited you more than once, if there are any specific points which you disagree with, or do not understand, to say so; and you have failed to raise one. In fact, you have yet to present a single cogent argument as to why the change from coor * to {{coord}} should not go ahead. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 11:54, 8 September 2008 (UTC)[reply]

There are way too many templates in action both here and commons. For an end user, its certainly frustrating to figure out which one to use if one uploads images on both places. I suggest one template be adhered to, with support for elevation and heading parameters. This be used on all wikipedias. =Nichalp «Talk»= 14:40, 8 September 2008 (UTC)[reply]

Replacing all of coor * with {{coord}} will change a choice of ten templates into one; and can be done now. None of them currently support elevation or heading, though that could be added to {{coord}} (if deemed appropriate by consensus), but please don't conflate separate issues, in order that we can finally move forward on the overdue deprecation of nine redundant templates. Thank you. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 14:50, 8 September 2008 (UTC)[reply]

{{coordinate}} supports elevation, and commons:template:location supports "heading" (suited to images). Ultimately, all the templates point to the geohack site, so the faster we get rid of old templates, the better. =Nichalp «Talk»= 15:39, 8 September 2008 (UTC)[reply]

So you'd be in favour, in the short term, of replacing coor * with {{coord}}? Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 16:03, 8 September 2008 (UTC)[reply]

All of them support elevation and heading, those values are just jammed into the generic property section which also holds type and region. I made a remark above that this approach seems to be sufficient for now. So for the coord vs. coor* question it seems to be irrelevant. Also I don't quite see why we should go for the largely unproven coordinate template if we have coord. coord seems clearly superior to the whole coor* family. I don't quite see the advantages of coordinate yet. Coord has been tested and used for a year now. What is keeping us from finally getting rid of the coor* family? --Dschwen 16:09, 8 September 2008 (UTC), P.S.: Andy, your new signature is a bit on the long side. --Dschwen 16:10, 8 September 2008 (UTC)[reply]

I did not know altitude was supported. Where can I read more about all supported generic properties? =Nichalp «Talk»= 16:51, 8 September 2008 (UTC)[reply]

Thank you for clarifying the elevation/ heading issue. As to "What is keeping us from finally getting rid of the coor* family?": so far as I can see, nothing, apart from Docu (talk · contribs), and I honestly can't make out the substance of his objection. There are many tens, if not now hundreds, of thousands of instances of {{coord}}; as you say, it is now proven to work. My sig is already discussed on my talk page; please feel free to comment there). Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 16:24, 8 September 2008 (UTC)[reply]

The main disadvantage of {{coord}} compared to both {{coordinate}} and {{coor title dms}}, e.g. is that the template and its user can't know if the value they enter are valid ones (e.g. {{coord|12|92|59|N|12|5156|56|E|type:landmark}} is accepted. With the coor d/dm/dms templates such checks were always easily possible and regularly performed. They are now even built in. In {{coordinate}}, e.g. {{coordinate|NS=12/92/59/N|EW=12/55156/56/E|text=/|type=landmark}} emits an error.

IMHO coordinate, even if it hasn't been used yet in this Wikipedia, the template itself has been sufficiently tested if it's already used 75,000 times. Even if we decide to hold a move to {{coordinate}} for now and want to see how occasional use develops, a conversion of thousands of template first to {{coord}} and then to {{coordinate}} should be avoided.

That being said, I think we can build several of the advantages of some of templates into the others. If one prefers prefixes (at/title)+(d/dm/dms), suffixes (display=inline/display=inline,title) or named parameters, finally shouldn't matter that much. -- User:Docu

The parameter checking is nice, but not a strong enough reason to prefer it. It can't distinguish wrong values, only those which are preposterous. That is, is {{coordinate|NS=1/2/3|EW=15/16/17}} correct? Clearly it could be correct. But such user handholding is misplaced, IMHO. —EncMstr (talk) 19:20, 8 September 2008 (UTC)[reply]

Even if that's the main difference, it's still fairly minor - of the may thousands of instances of coor *, only a handful or so show up as having such errors; and a bot can and has previously been used to check for "illegal" values. You've only recently added such validity-checking to coor *, couldn't you just have easily contributed it to {tl|coord}}}? {{coordinate}}, as has already been pointed out more than once, cannot be used sufficient times on a single page and apparently offers users no choice of display format. Anyway, the consensus here is clealry that coor * should be converted to {{tl|coord}], and soon. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:22, 8 September 2008 (UTC)[reply]

Obviously, once they are fixed, they don't show up anymore. Besides, apparently the consensus has it that offering users the choice of display format is being depreciated. -- User:Docu

"apparently the consensus has it that offering users the choice of display format is being depreciated" - your evidence for that remarkable - frankly, unbelievable - assertion is what, exactly? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:47, 8 September 2008 (UTC)[reply]

Wikipedia:MOSNUM#Date_autoformatting. BTW can you do something about the impossible values entered as coordinates in {{coord

}}? -- User:Docu

These templates output coordinates, not dates. Which "impossible values entered as coordinates in {{coord}}"? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:05, 8 September 2008 (UTC)[reply]

Obviously it's for dates, not coordinates, but IMHO personal preferences for dates are much stronger than for coordinates. Thus if don't let people choose their preferred date format, there isn't much use to do this for coordinates.

BTW, please excuse that I asked you to contribute.

http://en.wikipedia.org/w/index.php?title=Prospekt_Pobedy_(Kazan_Metro)&action=history

Eventually someone else will do it for you, no? -- User:Docu

Thank you for clarifying that the issue of user preferences for coordinates being deprecated is your "humble opinion" only. So far as I am aware, that does not equate to Wikipedia policy. Your latter comment appears, once again, to be more concerned with irrelevant point-scoring than making a material contribution to the present debate. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:33, 8 September 2008 (UTC)[reply]

Finally your getting funny. Cheers. -- User:Docu

Conclusion

Please find below a summary table of some elements of the three variants:

If you like me to add anything to the table, please comment below. -- User:Docu

1. Coordinate is a more verbose template, requiring 20-50% more typing than the others.
2. coor* template set hasn't been recommended for a long time, and new users trying to follow the guidelines are steered to coord.
3. 'supports "name=" and 'not supported by mediawiki' appear for all entries, so should be removed from the table.
4. coord display=inline,title replaces an additional use of a template such as geolinks...
5. What about support for elevation, source, region, globe?
6. Geotag microformat?
7. Extensibility to support non-point areas?

—EncMstr (talk) 09:05, 4 September 2008 (UTC)[reply]

Good points: I added (1) to the table. (2) seems difficult to assess. I added "frequently advocated" which might cover this (3) In the past, support for "name=" was sometimes brought up, which is why I included it. The absence of direct support by mediawiki is worth mentioning (IMHO). (4) any template should be able to replace geolinks. (5) elevation is supported by one, the other points seem to be covered already. I did add globe though. (6) is frequently mentioned, but no one seems to bother checking or fixing it. (7) interesting topic, may need to be added (an opportunity for any of the above?). BTW coordinate can suppress display of the coordinates. -- User:Docu

You mention the overhead of {{coords}} in the table, but you could make it clear that it means that there is a low limit on the number of times it can be used on a page. For lists of places such as List of cities, towns and villages in North Brabant, I need to be able to use a template a few thousand times, so the coor * family cannot be removed entirely. -- Eugène van der Pijll (talk) 13:26, 4 September 2008 (UTC)[reply]

List of cities, towns and villages in North Brabant is clearly in need of subdivision, as have been other such pages (by first letter would be a start). Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 15:24, 4 September 2008 (UTC)[reply]

Now done - with no more than 309 entries on a page. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 12:19, 6 September 2008 (UTC)[reply]

I added the point above. Note that WikiMiniAtlas already slows loading of that page with {{coor dms}}. -- User:Docu

Saying of {{coord}} "Despite being created a long time ago to supersede others, didn't do so" is a somewhat cyclical argument! {{coord}} could as easily be described as being "well known". You've also omitted that {{coord}} emits a geo microformat; and your comment that "no one seems to bother checking or fixing it" seems to be both unsupported and irrelevant. Indeed, the microformat is a major strength of {{coord}}. {{coordinate}} is not "Frequently used" here. Suppressing the display of coordinates is a bad thing. I don't see that any of the issues you raise are significant enough to prevent {{coord}} from replacing corr * ({{coordinate}} seems to be a red herring in that debate). Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 15:24, 4 September 2008 (UTC)[reply]

P.S. Where's the validation in {{coor title d|551.997|N|0.742|W|region:GB_type:landmark}}? Or in {{coor d|551.997|N|0.742|W|region:GB_type:landmark}} ? Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 15:30, 4 September 2008 (UTC)[reply]

P.P.S. With regard to the claim that coor * had "support for microformat available in some of test version (abandoned due to lack of interest)"; on further examination it seems to apply onlty to {{coo d}}; and that Docu (talk · contribs) removed the microformat markup in this edit, which was marked "minor" and had an edit summary of "rv", 22 minutes after it was added. I can find no trace of attempts to add the microformat to {{coor dm}}, {{tl|coor dms}} or the other six coor * templates. My earlier comments on the matter, pointing out that {{coord}} should be used instead, were struck out by Docu, on the same day. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 14:39, 8 September 2008 (UTC)[reply]

Although you (Docu (talk · contribs)) seem to have edited this page about five times since I wrote the above; you have yet to include the issues I raised in your table. Should I do so? It also needs to indicate that {{coordinate}}, unlike {{coord}}, is not (so far as we know) recognised by Google. Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 19:07, 5 September 2008 (UTC)[reply]

Pigsonthewing, would you suggest additions based on a comparison of the templates? (e.g. I tested (A) it works, I tested (B) it didn't work, I tested the suggested update for (C) it does work). Obviously, I can't make much of it if you don't try any of the other templates. -- User:Docu

My name, as you know, and as written above your post, is Andy Mabbett. I have already said what additions, changes and removals need to made made to the table, in my first post under this sub-heading. If there are any specific points which you disagree with, or do not understand, please say so. Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 20:22, 5 September 2008 (UTC)[reply]

Pigsonthewing, I think you have take a good approach by building an own summary table. To make sure, please double-check any claims you make. Are they based on the way you think it is or are they based on templates you checked?

Besides, to some extent, keep in mind what EncMstr wrote "[..] appear for all entries, so should be removed from the table". -- User:Docu

My name, as you know, and as written above your post, is Andy Mabbett. If there are any specific points which you disagree with, or do not understand, please say so (I'm repeating that text, as you appear to have overlooked it, previously). I will refute your allegation or adjust my claim accordingly; I will not ignore your comments as you did mine. Incidentally, I am unclear as to why you reverted the title of this section from "Summary", to "Conclusion", which it clearly is not. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 13:09, 6 September 2008 (UTC)[reply]

Pigsonthewing, can you provide references for your claims in regards to Google, export and microformats? -- User:Docu

My name, as you know, and as written above your post, is Andy Mabbett. If there are any specific points which you disagree with, or do not understand, please say so. If you do no understand this reply, which includes words now repeated for the third time, please say so. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 13:17, 6 September 2008 (UTC)[reply]

Pigsonthewing/Andy Mabbett, with "your claims" in meant the elements you added to your table. If there is a specific part of my question you don't understand, please write so. -- User:Docu

Apart from your concluding remark, and your inability to use my name properly, I can't understand anything in the above comment. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 13:25, 6 September 2008 (UTC)[reply]

This is a talk page. Everyone's being courteous and respecting Docu's request that Docu only adds things to the table. But Docu seems to me not to be extending that same courtesy to AndyM. That does not seem a tenable situation. We are here to evaluate how to move forwards with templates, not to engage in a pissing match. It would be helpful if some good faith could be injected into proceedings. --Tagishsimon (talk) 14:19, 8 September 2008 (UTC)[reply]

I looked into the points raised by User:Pigsonthewing and asked him for supporting references or tests he may have made, but apparently his still doesn't bother discussing how he arrived at the conclusion that no template but {{coord}} is supported by everybody else. Personally, I don't mind if he builds a comparable table. -- User:Docu

I have invited you three times (this being the fourth): If there are any specific points which you disagree with, or do not understand, please say so. The conclusion which you now say I have drawn is you invention; I have said no such thing. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:41, 8 September 2008 (UTC)[reply]

your table lists under opportunities for {{coord}} "# mash-ups using microformats # Export to KML, GPS etc. "# User can use mapping tools not on Geo-Hack"". Why is this listed only under coord, why not under the others? The table lists "# preferred by Google Maps/ Google Earth" under {{coord}}. On which basis did you list this there? For {{coord}}, the table lists "# emits Geo microformat", but at least now you concede that this is supported to some extent by the other templates. -- User:Docu

KML/ GPS export is a feature of the Geo microformat emitted by {{coord}}. At the time of writing, it appeared that none of the other templates emitted that microformat. It has since seemed that coordinate does, albeit undocumented, and in a broken way. The statement about Google is based on correspondence with their staff responsible for the matter, their public statement and statements by the Wikipedia editors responsible for liaising with them. I can't be held responsible for not knowing features of template which you have introduced and advocate, but have failed to discuss or document. Why did you not include the issues I raised, at your request, after I did so? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:41, 8 September 2008 (UTC)[reply]

As you are the specialist about microformat, it's preferable that you write about it, but I fail to understand why you didn't notice that coordinate does emit a microformat.

Can you forward us the correspondence with Google's staff? The odd thing about the google FAQ is that it's there for quite some time, even before {{coord}} was much used. Besides, it doesn't help us much about how to deal with all coordinates specified in infoboxes etc. -- User:Docu

Oddly, your request that I wrote about a feature of a template I didn't know excised, in a template I didn't know existed, seems to have escaped my attention. No, I can't forward private correspondence to you; but since I've also provide you with the URL of a public statement, which you'd clearly already seen, I shan't worry about that too much, If asking for such is the level of your case against converting to {{coord}}, then I think you may well have run out of anything meaningful to say on the matter. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:00, 8 September 2008 (UTC)[reply]

Postscript: Lest your "fail to understand" comment lead anyone think that I have been negligent in attempting to gain a full view of the situation, people should note that I explicitly asked you, on 26 August, and again on 27 August, whether coordinate emitted a microformat, You did not answer that, nor any of the other questions I asked you - not for the first time - in the same post. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:47, 10 September 2008 (UTC)[reply]

Maximum usage

The 105 kilobyte page List of cities, towns and villages in North Brabant uses {{coor dms}} 1184 times to earn the statistics:

Preprocessor node count: 82884/1000000
Post-expand include size: 625203/2048000 bytes
Template argument size: 60384/2048000 bytes
Expensive parser function count: 0/500

Replacing with {{

coord

. The stats are:

Preprocessor node count: 210758/1000000
Post-expand include size: 2048000/2048000 bytes
Template argument size: 774892/2048000 bytes
Expensive parser function count: 0/500

For {{coordinate}}, I created user:EncMstr/test1/coordinate, but encountered several problems: I was never able to save the page with all the entries enabled—a timeout error occurred somewhere within Wikipedia. Also, {{coordinate}} assumes the equivalent of "display=title" and I was unable to find a way to make it inline only, so the top-right coordinate title place is heavily overwritten. At 251 entries active (the rest commented out):

Preprocessor node count: 312988/1000000
Post-expand include size: 1208351/2048000 bytes
Template argument size: 451976/2048000 bytes
Expensive parser function count: 0/500

These suggest the limit for the number of uses of {{coor dms}} on one page is (2048000/625203) * 1184 = 3880; for {{coordinate}}, 2048000/1208351 * 251 = 425 uses. {{Coord}} has a limit of 689 uses. —EncMstr (talk) 18:23, 4 September 2008 (UTC)[reply]

Interesting figures, thank you. As I've noted above; List of cities, towns and villages in North Brabant is clearly in need of subdivision. Indeed, I can't see why any article with ~700 or more instances wouldn't need to be split. Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 18:42, 4 September 2008 (UTC)[reply]

I wonder why this edit includes the figure for coord (given as 680, but actually 689 per EncMstr) but not the lower figure of 425 for {{coordinate}}? It also includes the PoV wording that 15-20 are "many" but 5-10 are just "several". Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 19:16, 5 September 2008 (UTC)[reply]

Speaking of PoV, it seems we're not now even to suggest to editors the possibility of using {{coord}}. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 22:40, 5 September 2008 (UTC)[reply]

Further reversion

Why was this set of references to coord reverted? The only edit summary was "v undiscussed change" Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 10:59, 6 September 2008 (UTC)[reply]

Why did you go through the page to change these? -- User:Docu

Why do you reply to a question with a question, rather than an answer? Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 13:13, 6 September 2008 (UTC)[reply]

Can you explain why you want to change it? Your edit was reverted because you didn't provide sufficient explanation. -- User:Docu

I have now done so. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 13:31, 6 September 2008 (UTC)[reply]

Changes to such pages should reflect a consensus rather than an opinion of yours. Please avoid doing them unless we agree. -- User:Docu

My edit summary includes facts, not opinions. There appears to be emerging consensus, as there was before, that coor * templates are redundant to, and should be replaced by {{

WP:OWN, your personal agreement would not seem to be a requirement. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 14:12, 6 September 2008 (UTC)[reply

]

Another instance of coord has been reverted. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 18:52, 6 September 2008 (UTC)[reply]

and another Note that the claim "per talk page" is bogus; no reason for the revert having been given on this, the talk page in question. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 19:37, 6 September 2008 (UTC)[reply]

Summary 2

Since Docu (talk · contribs) has failed to include points I raised, in his table, here's a revised version, with more neutral wording and a more compete set of facts:

Note:

• {{coor at dms|41|12|21|N|086|25|08|W|region:US-IN_type:waterbody_source:gnis}} = 78 characters
• {{coord|41|12|21|N|086|25|08|W|region:US-IN_type:waterbody_source:gnis|display=title}} = 93 characters
• variable parameter configuration: "The "globbed"-together parameters allows other (new) parameters to be accepted without needing to modify several components (coord, geohack.php GeoTemplate) to accommodate them, instead changes are "localized" to updating either geohack.php or GeoTemplate (depending on the change) without needing to update Coord." ^[1]

An end in sight?

We now have support for conversion to {{coord}} from, I understand, me, Dschwen, LeheckaG , EncMstr, Tagishsimon & Nichalp; with opposition only from Docu. Unless there are any other voices or arguments against, I propose to mark the nine coor * templates as deprecated in favour of {{coord}}, and request a bot to commence conversion, in not less than 24 hours from now. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:51, 8 September 2008 (UTC)[reply]

 Done at Wikipedia:Bot requests/Archive 22#Deprecated coordinates templates. I'll now start adjusting documentation, accordingly. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:54, 9 September 2008 (UTC)[reply]

Docu (talk · contribs) is reverting related changes as "undiscussed". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:18, 9 September 2008 (UTC)[reply]

Since resolved. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:35, 17 September 2008 (UTC)[reply]

Work to replace the deprecated templates has started, thanks to The Anome and his faithful The Anomebot2. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:38, 19 September 2008 (UTC)[reply]

I'm being very conservative at the moment: the bot is only updating those geotags it added itself, and even then only if the tags are still character-for-character the same as when it added them to the article. However, this should still amount to several tens of thousands of articles. -- The Anome (talk) 13:14, 19 September 2008 (UTC)[reply]

Understood, and thank you again for your work, but please note that there is consensus to deprecate, and replace all instances of, the old templates, as indicated above. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:55, 19 September 2008 (UTC)[reply]

Yes, and I'm going to do those eventually, but I'm picking the low-hanging, low-risk, fruit first. Given the free-form, unvalidated, ad hoc syntax of wikitext, dealing with even simple textual changes with a bot requires lots of testing and error checking, because there are so many corner cases to deal with, and a bot can do a lot of damage if you don't test extensively first. If you want it done faster, have you considered writing and debugging your own bot, applying for bot permission yourself, and supervising your bot as it runs? -- The Anome (talk) 15:17, 19 September 2008 (UTC)[reply]

I didn't mean to express any impatience; just to set the record straight for other readers - as I've said, I'm very grateful for your work on this. Even if the bot does it all ;-)

I'd be very happy to run a bot, but sadly my coding skills are (or were) in now-archaic languages. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:00, 19 September 2008 (UTC)[reply]

Anome, when you are talking about your bot being conservative, what cases are there that you want to be careful about? Maybe we can compile a list of potentially problematic (or even ambiguous?) cases. --Dschwen 16:05, 19 September 2008 (UTC)[reply]

That's right: broken and ambiguous templates, particularly ones that have been modified by users who don't know how the template system works. For example, template instances with missing or extra positional or keyword parameters, or ones with embedded templates within them... Even some of my own earlier bot-generated tags had errors, caused by propagating errors in the original data used to create them. -- The Anome (talk) 16:22, 19 September 2008 (UTC)[reply]

One of the searches at

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

Which are the

"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

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

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

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

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. __

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

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

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

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

]

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

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

]

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

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

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]

What remarkably low figure are you referring to? The roughly 1800 instances of broken templates? Geez, that's not the template's fault, no need to go around censoring other peoples' posts. --Dschwen 19:47, 16 September 2008 (UTC)[reply]

I haven't censored anyone's post. I fixed a link, and changed a misleading heading. Please stop making false accusations. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:09, 16 September 2008 (UTC)[reply]

I cannot, since I haven't even started. I just made a perfectly correct observation. What's misleading is your claim of just having fixed a link, since you broke it in the first place, by the very same suppression of other peoples' dissenting opinions. --Dschwen 22:20, 16 September 2008 (UTC)[reply]

Cease making false accusations. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:30, 16 September 2008 (UTC)[reply]

Another case of edit summary bullying [5]. Neither did you refute anything, nor did I lie. Same old, same old. --Dschwen 22:33, 16 September 2008 (UTC)[reply]

I'm sorry that you felt bullied. Given your apparent vulnerability, and inability to tell fact from fiction (I'll assume good faith and accept that it may not have been a deliberate lie), I'll leave it at that. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:01, 16 September 2008 (UTC)[reply]