![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 5 | Archive 6 | Archive 7 | Archive 8 | Archive 9 | Archive 10 | → | Archive 14 |
I just noticed that Paulatuk Airport has as part of the coordinates "_elevation:5". Does it do anything? I looked but couldn't find any listing for it. Enter CambridgeBayWeather, waits for audience applause, not a sausage 11:19, 27 June 2009 (UTC)
dim:
for the general dimension/diameter in meters (now supported by GeoHack)elevation:
(also alt:
for the height presumably above mean sea level, intended as as a coord3dheading:
the general direction of the object or direction of a picture.After we get the undefined parm issues settled, I'd like to make three improvements to the error handling in {{ coord}}:
-- Stepheng3 ( talk) 11:54, 15 October 2009 (UTC)
Well, that was exciting. I seem to have hit a gusher of errors of the form {{Coord|latd|longd|source=geograph.co.uk|region:GB_type:landmark|display=title}}. Until the pressure subsides, I'm going to put off the final edit to {{ Coord/input/ERROR}} to address improvement #2. -- Stepheng3 ( talk) 21:10, 16 October 2009 (UTC)
According to
Template:Coord/doc, {{
Coord}} is supposed to display a blue globe (
) for each set of coordinates. This is broken in many skins, but it usually works with Chick, Monobook, Simple, or Vector. The fact that it doesn't always work, even with these skins, is demonstrated below.
OK, it makes sense to hide the blue globe for off-Earth coordinates. (There probably won't be a WikiMiniAtlas of the Moon any time soon.) However, the fact the the blue globe is hidden for all subsequent coordinates (in my browsers, at least) has got to be a bug. I've seen this both with IE8 and Opera 9.64 and with all four of the skins that usually display the blue globe. Does anyone know what's going on here? -- Stepheng3 ( talk) 03:24, 19 October 2009 (UTC)
* [http://stable.toolserver.org/geohack/geohack.php?pagename=User:Redrose64/Sandbox¶ms=1_N_2_E_ 1°N 2°E ] * [http://stable.toolserver.org/geohack/geohack.php?pagename=User:Redrose64/Sandbox¶ms=3_N_4_E_globe:moon 3°N 4°E ] * [http://stable.toolserver.org/geohack/geohack.php?pagename=User:Redrose64/Sandbox¶ms=1_N_2_E_ 1°N 2°E ]
Is there a reason why Ganymede
is not documented as a legal value for the globe: parameter? Despite being capitalized differently from the other values, it gets a lot of use and doesn't seem to be breaking anything. --
Stepheng3 (
talk)
23:30, 16 October 2009 (UTC)
globe:
. There maybe other parsers which aren't so tolerant of the casing, we need to decide (or I'll decide) if we should be capitalizing the planet names since they are proper names or leave them all lowercase for easier typing. The ghel parser support 36 globes in our solar system (planets+some moons). The supported planets in GeoHack only limited by subpages people have created (
list) and the willingness of to documenting the coordinate system and finding services. —
Dispenser
06:22, 19 October 2009 (UTC)I documented the three additional globes that GeoHack supports and, in the process, learned more than I wanted to know about how longitude is defined for other worlds. Suffice to say that the IAU has coordinates systems set up for 51 natural satellites.
Since the case-sensitivity question is unresolved, I left it undocumented for now. -- Stepheng3 ( talk) 09:55, 22 October 2009 (UTC)
ENUM( 'Mercury', 'Venus', 'Earth', 'Moon', 'Mars', 'Phobos', 'Deimos', 'Ceres', 'Ganymede', 'Callisto', 'Io', 'Europa', 'Mimas', 'Enceladus', 'Tethys', 'Dione', 'Rhea', 'Titan', 'Hyperion', 'Iapetus', 'Phoebe', 'Miranda', 'Ariel', 'Umbriel', 'Titania', 'Oberon', 'Triton', 'Pluto')
. Hopefully, I wont be needing to add more in the near future. —
Dispenser
22:35, 24 October 2009 (UTC)The rendering of text labels on the map that pops up when you click on the blue globe is pretty buggy. Text is often illegible either because of clipping, overlapping or lack of colour contrast with the background. Guess everyone already knows this, right? —Preceding unsigned comment added by 86.138.41.250 ( talk) 01:54, 24 October 2009 (UTC)
{{
coord}}
Is there a general way to give a reference for a display=title coordinate? For an inline coordinate, it seems straightforward: {{coord|...|display=inline,title}}<ref>...</ref>
I see no way to translate that for display=title. The "source" parameter doesn't seem to do nearly as much as a <ref> can. Am I just being anal retentive? Gregbaker ( talk) 05:31, 8 July 2009 (UTC)
Example: [1] 51°51′51″N 31°21′11″E / 51.86417°N 31.35306°E
{{
coord}}
, use <ref> after the tag (e.g. {{coord|...|display=inline,title}}<ref>...</ref>)For reasons relating to EU database copyrights limiting what can be used as a source is a very bad idea. Generaly it's not a good idea to encourage people to draw large numbers of coordiates from a single source.© Geni 13:13, 17 October 2009 (UTC)
{{coord|67.5|22.5|note=<ref>_Encylopedia Galactica_, page 14:322</ref>|display=title}}
I've added a notes=
parameter to the sandbox version of the template. If someone with administrative powers would copy {{
Coord/sandbox}} to {{
Coord}}, I'll take care of updating the template documentation. --
Stepheng3 (
talk)
17:45, 5 November 2009 (UTC)
I've been working on the Infobox Country template on the India page, and I noticed that the coordinates of New Delhi in the Infobox have a little weird symbol combination that looks like this...
‡)28°34'N 77°12'E
I've checked a few other articles that use Infobox country, and they appear okay. So far, I see this little " ‡) " symbol only in the India article and across all nine skins in my IE7. Anybody else see this? and what do you suppose is causing it? I can't find anything in the code for this template nor the Infobox template that might cause this, and the box on the page itself appears to be free of this symbol. If it's coming from outside, then why is it only affecting one particular article's Infobox?
—
.`^) Paine Ellsworth
diss`cuss (^`.
11:17, 27 October 2009 (UTC)
<sup>‡</sup>)
(out). I found it. It was on the "area_km2=3,287,240<sup>‡</sup>" code line in the box on the India page. There is no close paren, however if the <sup>‡</sup>" is removed, the weirdological symbol vanishes, including the close paren. To me, this appears to be a high-falutin' vandalism, but I'm not experienced enough to know for certain.
Last month I added a check to {{ Coord}} such that articles which use "source=" (instead of "source:") would get a bold red error message and a maintenance category. After this turned up a large number of nonstandard template uses, the check was removed. In order to start standardizing these uses, I'd like to add a slightly different check, which would invoke the maintenance category but not display a message. Are there any concerns or objections to adding this check? My next step will be to standardize existing uses of {{ Coord}} (in articles), and when that's done, I'd like to re-enable the error message. -- Stepheng3 ( talk) 19:37, 11 November 2009 (UTC)
Whereas in IE Opera and other browsers the template appears directly under the page title line, in Firefox it stays at a steady distance under the top tabs' line. In the case of long titles, it superimposes on the title letters. Any cure for this? Hoverfish Talk 17:15, 15 November 2009 (UTC)
Hmm. Yes, in the last half an hour Safari (for windows), IE8, Chrome, Opera have also changed as you say and only Flock has it still the old way. Could it be that the Meta-techs are moving things around? Hoverfish Talk 18:18, 15 November 2009 (UTC)
I have Firefox 3.5.5 and Monobook BTW... Oh, and Flock just jumped with the other browsers. Hoverfish Talk 18:28, 15 November 2009 (UTC)
I've been noticing how coordinates in dm and dms formats can be very difficult to read--at least with my browser/skin combination (Monobook/Opera 10.01). This is especially a problem in the title position, due to the small font used. An extreme example is dm-format title coordinates in the northern and/or eastern hemispheres, where the stroke (′) after the minutes of latitude disappears completely into the N, and/or the stroke after the minutes of longitude disappears completely into the E. When the stroke appears immediately before an S or W, it merges with the letter and easy to miss unless you know what to look for. Even the normal font used in inline coordinates has problems with ′W. There are similar problems in dms format with the ′ merging into certain digits and the second stroke of the double stoke (″) merging with a following glyph.
Are others experiencing these problems? If so, I see a various possible solutions: (1) increase the font size (2) switch to a different font family (3) add a space after each stroke and double stroke Each of these solutions might be applied to all coordinates or only to title coordinates. -- Stepheng3 ( talk) 06:03, 20 November 2009 (UTC)
that could be used? --
Redrose64 (
talk)
10:52, 20 November 2009 (UTC)
 
) or narrow no-break space ( 
). In my browser, however, these don't look different from an
.Currently the javascript for the WikiMiniAtlas is loaded on every page view, no matter if a page has coordinates or not. I intend to make it so it only loads when needed. See discussion at MediaWiki talk:Common.js#WikiMiniAtlas.
-- David Göthberg ( talk) 17:26, 15 January 2010 (UTC)
Not sure if this is related to the discussion above but if you go to List of airports in Ontario and scroll down eventually the globe icon vanishes. If you open the page in another tab then you get the same effect but not always on the same line. The same can be seen at the article linked above, List of bridges on the National Register of Historic Places in Pennsylvania. I also noticed that if you click on the globe icon in the airport list you get a grey box with blue links for places around the world but in the bridges you get the grey box and the links are restricted to the US. Enter CambridgeBayWeather, waits for audience applause, not a sausage 22:40, 25 January 2010 (UTC)
For some few weeks at least now, most of the topographical maps have stopped working for Hawaiian islands (except Oahu and Kauai at low resolutions). For example, try 20°48′N 156°20′W / 20.800°N 156.333°W and select any of the topo sites. It used to work. This might not be anything with this template, but perhaps someone here might know if this is a feature or a bug, who to contact, etc. Thanks for any suggestions. W Nowicki ( talk) 23:58, 30 January 2010 (UTC)
It has come to my attention that there are some list articles such as this one that employ numerous calls to this template. These articles are suffering from long (over 20 seconds) load times and high CPU loads on some medium powered machines, leading to concern that they might be inaccessible on older machines. This template was identified as the culprit, and further testing by myself has revealed the real culprit to be the implementation of the javascript WikiMiniAtlas with each call to this template. I slogged through the code on this template and its subtemplates and it appears that the WikiMiniAtlas feature is hard-coded into the template and there is no way to disable it. If there is a way to disable it, that should be made more clear in the documentation so that these kinds of lists can do away with the WikiMiniAtlas feature and eliminate the long load times; if not, can an optional parameter be added to optionally disable this feature? Sher eth 16:31, 29 December 2009 (UTC)
<!-- Served by srv146 in 17.527 secs. --> <!-- NewPP limit report Preprocessor node count: 112588/1000000 Post-expand include size: 737005/2048000 bytes Template argument size: 271536/2048000 bytes Expensive parser function count: 0/500 -->
|WMA=no
that would insert something like style="nowma"
to the link, and then instruct WMA to skip these ones?
Sher
eth
20:33, 29 December 2009 (UTC)This is almost certainly Internet Explorer's horrible string performance, the page loads in about 14 seconds with a bunch of other scripts in Firefox on a decade old machine. — Dispenser 15:16, 1 January 2010 (UTC)
var wma_settings = { onlyTitle: true }
". I can use that to make a small template or an option in {{coord}}, that when placed on a page adds a special id. And I can add code in
MediaWiki:Common.js that triggers on that id and then adds "onlyTitle: true
". Thus making WikiMiniAtlas only work on the title on that page. But it would be better if Dschwen supplied us with a method to disable it for just some coordinates on a page.In case anybody thinks this is a minor problem, or one caused by old machines or bad browsers: Can anybody open up List of bridges on the National Register of Historic Places in Pennsylvania in less than 15 seconds?
What editors would like to do is click on the Bing or Google maps link and see them plotted on a map, or maybe click one set of coordinates and see it on google maps. We'd also like to be able to add a photo in less than 30 seconds. I don't think anybody wants to click on one of the little blue globes and get that funky little map that comes up. Can't those maps just be deleted, thrown away, stamped underfoot, and gotten rid of? Smallbones ( talk) 03:04, 19 January 2010 (UTC)
Nevertheless, I think there is a real need for a lightweight version of Template:Coord for large tables or multiple tables such as found in Mountain peaks of North America. Yours aye, Buaidh ( talk) 03:14, 7 March 2010 (UTC)
<!-- Served by srv203 in 49.154 secs. -->
. Firefox 3.0.18, Windows XP, Monobook. --
Redrose64 (
talk)
16:28, 7 March 2010 (UTC)Started a discussion at Wikipedia talk:WikiProject Geographical coordinates#Add full ISO 6709 support to Template:Coord. Coordinates from tz database come in a ISO 6709 format, but this, nor any other ISO 6709 format is supported. TimeCurrency ( talk) 02:56, 11 March 2010 (UTC)
Lately I've spent a lot of time normalizing type: parameters. I suspect one of the reasons why people use undefined typecodes like type:hamlet
and type:place
is that the documentation (at
Wikipedia:WikiProject Geographical coordinates/type:) doesn't provide as much clarity and guidance as it might, particularly concerning type:landmark
, which seems to be the catch-all.
I plan to edit the documentation to address issues I see. However, I'm bringing up my plans for discussion here in case they prove controversial.
type:city
, the lower limit is unclear. I propose including "hamlets, suburbs, subdivisions, neighborhoods, other human settlements including unincorporated and/or abandoned ones". Otherwise these might get lumped with type:landmark
.type:airport
, include "airbases".type:mountain
, include "hills, submerged reefs, seamounts".type:waterbody
, include "waterfalls".type:river
, include "arroyos, brooks, streams including intermittent ones".type:event
, include "earthquakes, festivals, shipwrecks".type:railwaystation
, include "(railway) maintenance areas".type:landmark
from "buildings of special interest" to "buildings that are neither schools nor railway stations".type:landmark
, enumerate miscellaneous artificial structures including "antennas, bridges, castles, cemeteries, dams, factories, intersections, lighthouses, mines, museums, monuments, power plants, ranches, roads, rocket launch sites, shopping malls, stadiums, theatres"type:landmark
, enumerate miscellaneous natural features including "caves, geologic faults, headlands, valleys".In a few cases I'm unsure which type: applies best...
A. Should craters and calderas be coded as type:landmark
or type:mountain
?
B. Should individual trees be coded as type:landmark
or type:forest
?
C. Should archeological sites be coded as type:landmark
even if they were once cities? I'm tempted to say "yes".
D. I'm unsure how to code fourth-level administrative divisions, such as civil parishes of England. I'm tempted to lump them with "adm3rd" or "city".
E. How should we code non-administrative regions:
biomes, extraterrestrial
regios, and informal regions such as the
Rust Belt? I tend to use type:landmark
and override the default scale using a dim: parameter.
Looking forward to any feedback or suggestions. -- Stepheng3 ( talk) 20:46, 17 January 2010 (UTC)
Regarding issue (D), I've decided to recode English civil parishes as type:city
.--
Stepheng3 (
talk)
19:54, 26 February 2010 (UTC)
type:settlement
instead of type:city
(while still recognising the latter for backwards compatibility) would be less ambiguous, and mirror the use of that word in {{
Infobox Settlement}}.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits
23:01, 19 February 2010 (UTC)
type:settlement
, so I'd like to proceed with this. I'll talk to
User:Dispenser about getting this synonym added to GeoHacks, and then proceed with documenting the change. --
Stepheng3 (
talk)
16:40, 8 March 2010 (UTC)type:city
(with or without population) for villages,
Census-designated places, and so forth.type:settlement(pop)
from the beginning. Perhaps (after a transitional period) we could make type:settlement(pop)
the standard and eliminate type:city(pop)
completely. Would you support that plan, Dschwen? --
Stepheng3 (
talk)
06:52, 9 March 2010 (UTC)
Hi, As far as I understand, Template:coord is the accepted way of adding coordinates to Wikipedia. I have however just discovered Template:Oscoor, which appears to do a parallel job, and seems to be unable to integrate with Template:GeoGroupTemplate (see List of Hewitts and Nuttalls in England), and may not have microformats, nor allow geo-indexing by search engines (e.g. google).
Any suggestions on what can be done to unify Template:Oscoor with Template:coord? -- Ozhiker ( talk) 14:48, 23 February 2010 (UTC)
{{
coord}}
is for use when you have a latitude and longitude on a globe. {{
oscoor}}
is for when you have a British or Irish National Grid Reference on a map (transverse Mercator projection). Further, {{
oscoor}}
should not be used alone, but should be called via any of several wrappers such as {{
gbmapping}}
. --
Redrose64 (
talk)
16:17, 23 February 2010 (UTC){{
coord}}
template via some coordinate conversion so that external systems know about them, so there is one place for microformat code, and one place linking to the GeoHack page.{{
Oscoor}}
or other UTM templates seem to be completely missing from Mashups. :-( --
Ozhiker (
talk)
19:32, 23 February 2010 (UTC)Many mountains are located on international borders. So region codes for two countries are appropriate. For example a mountain on the US Canadian border should use US and CA. Is there a meaningful syntax for this case. I have noticed that some editors have used region:US/CA but this is not a documented syntax. – droll [chat] 22:05, 9 March 2010 (UTC)
+ de:Vorlage:Coordinate, et:Mall:Coordinate best regards 80.142.251.43 ( talk) —Preceding undated comment added 14:08, 16 March 2010 (UTC).
It has been proposed at
Template talk:Infobox mountain that the template use the coord | notes =
parameter to display a link in the title line to a bottom note. This would be for ever page that uses the template. I don't like the idea and I'm wondering if those who watch this template have any thoughts. –
droll
[chat]
07:36, 17 March 2010 (UTC)
I think it's time to get rid of type:state
, which is currently used in only about 250 coordinates. The documentation says it's for specifying coordinates of a "Former country or administrative unit of country, undefined level", but I think it would be better to tag these as type:country
, type:adm1st
, and so on, so as to provide better scale hints to GeoHack. If there's no objection, I'll retag these coordinates and update the template documentation. --
Stepheng3 (
talk)
05:53, 20 April 2010 (UTC)
I stumbled into this yesterday. I think this is a great feature and plan to use it. If I put text after the scale parameter, it will show up before and part the coord image e.g.
{{coord|48.19464|N|3.01776|W|scale:5000 Guerlédan Dam}} yields Guerlédan Dam 48°11′41″N 3°01′04″W / 48.19464°N 3.01776°W
However, if you try to use the name parameter, it gets messed up: e.g.
{{coord|48.19464|N|3.01776|W|name=testname|scale:5000 Guerlédan Dam}} yields Guerlédan Dam&title=testname 48°11′41″N 3°01′04″W / 48.19464°N 3.01776°W
It is way beyond my paygrade to know if this is a feature or a bug. GloverEpp ( talk) 12:41, 29 April 2010 (UTC)
Do we really need the globe? There are a lot of infoboxes that use {{coord}} as a nested template and I at least find it quite disturbing to see the globe interrupt the table structure of the final box output. And when one uses display=title, these boxes will leave the Coordinates field blank but still show the parameter name. De728631 ( talk) 17:51, 31 March 2010 (UTC)
|display=inline,title
". Probably whoever entered them forgot; I've done it.I am visiting this page as a casual reader of the article Mary_Celeste. In section 3 (Discovery of the Mary Celeste), the "coord" template inserts this unpleasant hieroglyph in the middle of the text. It breaks ease of reading, so much that I left the article to complain here. I am not interested in template design, this is only the testimony of somebody _reading_ an article, but I strongly feed something should be done ; inserting a blue small disc in the middle of a sentence is a real disgrace. French Tourist ( talk) 16:41, 2 May 2010 (UTC)
I tried copying this code to this page, but it seems to always give an unrecognized character error there. Would someone here be able to troubleshoot that? -- 209.34.235.6 ( talk) 19:25, 6 May 2010 (UTC)
I had this goofy idea in my head, but I still thought that I would run it by some people here. There have been requests made at various times to add geographic coordinates to the junction lists at the bottom of articles on highways. M6 motorway does this by using footnotes; Montana Highway 16 by including a column of them with {{ coord}} in it for each junction it its very non-standard list. What I'm picturing is something similar to {{ coord}}, but without the full display of the linked coordinates. Maybe it would display just the globe icon. It could be inserted into the distance or exit number column of a list in an article like U.S. Route 41 in Michigan. The data would be there and accessible, but streamlined for display purposes. Thoughts? Imzadi 1979 → 00:53, 10 May 2010 (UTC)
The coord function seems to have gone haywire. For example, the coordinates here Lot_(river) were working yesterday. GloverEpp ( talk) 12:56, 13 May 2010 (UTC)
I have a question about the regions, can we use regions:Kosovo for kosovo? e.g : template : coord|42.2068|N|20.7374|E|region:Kosovo
thanks, mike James Michael DuPont 13:36, 23 May 2010 (UTC)
Is there something similar like mountains for other landscapes like deserts, peninsula or larger regions? -- Tobias_dahinden 13:07, 2 June 2010 (UTC) —Preceding unsigned comment added by 130.75.51.124 ( talk)
After seeing this, it got me thinking that we could potentially set up some sort of a check for some of the more basic errors in specifying the region, source, type, ... passed to the coord template. One very basic check is to look for < and [ in the field using say {{ str find}}. This could be one of the checks that throws an error exception. This wouldn't find all such errors, but doing that may create too much server load. Here is some code that finds wikilinks and html tags in a field:
{{#ifexpr: {{str find|{{{region-iso|}}}|[}} < 0 | Good | Bad}}
and
{{#ifexpr: {{str find|{{{region-iso|}}}|<}} < 0 | Good | Bad }}
This test could go in {{ Coord/link}} or upstream in the top level template with the other error exceptions. It would be really nice if we could check the validity of the region field, but I am afraid that would take far more work. Comments? Plastikspork ―Œ(talk) 15:19, 15 April 2010 (UTC)
region-iso=
is not a {{
Coord}} parameter, so that check would have to be performed at a higher level template (in this case {{
Infobox mountain}}). Unless you know how to parse the coordinate parameters, that is, in which case I'd like to see a prototype.
{{{region-iso}}}
was just a dummy value to give an idea of what I was talking about. Basically, I believe that none of the unnamed parameters in this template should contain wikilinks, flag templates, or html code.
Plastikspork
―Œ(talk)
18:36, 15 April 2010 (UTC)
{{#ifexpr: {{str find|{{{1|}}}{{{2|}}}{{{3|}}}{{{4|}}}{{{5|}}}{{{6|}}}{{{7|}}}{{{8|}}}{{{9|}}}{{{10|}}}|[}} < 0 | Good | Bad}} {{#ifexpr: {{str find|{{{1|}}}{{{2|}}}{{{3|}}}{{{4|}}}{{{5|}}}{{{6|}}}{{{7|}}}{{{8|}}}{{{9|}}}{{{10|}}}|<}} < 0 | Good | Bad}}
display=
parameter.--
Stepheng3 (
talk)
16:48, 15 April 2010 (UTC)
display=
, I've added namespace support for to my
redlink prefix index tool to identify all cases. —
Dispenser
04:33, 16 April 2010 (UTC)
{{#ifexpr:((0{{{2|-1}}}+1) and not (0{{{6|-1}}}+1)) or (not (0{{{2|-1}}}+1) and (0{{{6|-1}}}+1)) != 0|Empty warning}}Of course with every additional step it takes longer and longer to render a page w:List of craters on Mars: A-L has 534 points and takes 47 seconds to render. On geosearch.py its going to optional once I write tools to handle the errors that have surfaced regarding geohack URL missing this template. — Dispenser 07:05, 16 April 2010 (UTC)
{{#if:{{{1|}}}||Empty warning}}do the trick? -- Stepheng3 ( talk) 08:06, 16 April 2010 (UTC)
Yes, I figured that this might be a bit expensive. This {{#ifeq:{{padleft:|1|{{{foo|}}}}}|<|Bad|Good}} and this {{#ifeq:{{padleft:|1|{{{foo|}}}}}|[|Bad|Good}} aren't as expensive, and catch some cases, but probably would be better to just to other individual templates that call this one. For example, this works for the region example:
{{#ifeq:{{padleft:|1|{{flag|Egypt}}}}|<|Bad|Good}}
and
{{#ifeq:{{padleft:|1|[[Egypt]]}}|[|Bad|Good}}
By the way, I am aware of the problem with the Mars Craters page. I had to split it after running into the problem of exceeding the total number of templates on a page limit. I think it could be split again due to the size. Although, it is a good test case for illustrating a point. Plastikspork ―Œ(talk) 17:06, 16 April 2010 (UTC)
<!-- Served by srv207 in 43.015 secs. -->
. There's also inital caching delay. I ran the tests a few times and it seems the one without the check is about 2 seconds faster (40.366 vs 42.386) but this is rather negligible across 500 especially when comparing to {{
coor d}} which can renders 2000+ coordinates in 20 seconds. —
Dispenser
04:34, 19 April 2010 (UTC)
Getting back to the original problem. Since these users don't look at the HTML output, big red error messages are going to do nothing. So we need a way of detecting these broken URLs. Instead of use the expensive parser functions, I propose that we append &
to the end of the coordinate URLs and use geosearch.py with [^&]$
. —
Dispenser
04:34, 19 April 2010 (UTC)
(space) (newline) [ ] < > "
characters, as soon as it encounters one of those characters it will treat the rest as the title (gets tricky with '' and '''). If we have a known marker at the end the URL, it wont be included if the mentioned truncation happens. We then can then search for URLs missing this marker indicating something was lost. There's also the {{urlencode:}} function (can now produce underscores) but hasn't been thoroughly debugged yet, it may double escape input and escapes everything that isn't 0-9A-Za-z:._
. —
Dispenser
19:06, 30 April 2010 (UTC)
{{
editprotected}}
{{
editprotected}}
Done. Plastikspork ―Œ(talk) 21:11, 9 May 2010 (UTC)
It's the change from
|1={{{1|}}}|2={{{2|}}}|3={{{3|}}}|4={{{4|}}}|5={{{5|}}}|6={{{6|}}}|7={{{7|}}}|8={{{8|}}}|9={{{9|}}}|10={{{10|}}}|
to
|{{{1|}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|{{{5|}}}|{{{6|}}}|{{{7|}}}|{{{8|}}}|{{{9|}}}|{{{10|}}}|
In the |1={{{1|}}}|
form, any leading or trailing spaces are stripped from parameter 1 before it's passed on; but in the |{{{1|}}}|
form they're not. This is significant when you start substituting the actual values used into the subtemplates, and you find that {{
Geobox2 coor}}
inserts a space prior to the latitude degrees before sending this into {{
coord}}
. You can check this by using the subtemplate {{
coord/input/dms}}
directly. The code
*{{Coord/input/dms|1= 51|2=02|3=21|4=N|5=116|6=26|7=33|8=W|9=type:river_region:|10=|format=|name=}} *{{Coord/input/dms| 51|02|21|N|116|26|33|W|type:river_region:||format=|name=}} *{{Coord/input/dms|51|02|21|N|116|26|33|W|type:river_region:||format=|name=}}
produces this
{{
Coord/input/dms|51|02|21|N|116|26|33|W|type:river_region:}}
{{
Coord/input/dms|51|02|21|N|116|26|33|W|type:river_region:}}
It's just that one space that causes the problem. The bug therefore lies within {{
Geobox2 coor}}
. --
Redrose64 (
talk)
16:57, 7 June 2010 (UTC)
{{
editprotected}}
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 5 | Archive 6 | Archive 7 | Archive 8 | Archive 9 | Archive 10 | → | Archive 14 |
I just noticed that Paulatuk Airport has as part of the coordinates "_elevation:5". Does it do anything? I looked but couldn't find any listing for it. Enter CambridgeBayWeather, waits for audience applause, not a sausage 11:19, 27 June 2009 (UTC)
dim:
for the general dimension/diameter in meters (now supported by GeoHack)elevation:
(also alt:
for the height presumably above mean sea level, intended as as a coord3dheading:
the general direction of the object or direction of a picture.After we get the undefined parm issues settled, I'd like to make three improvements to the error handling in {{ coord}}:
-- Stepheng3 ( talk) 11:54, 15 October 2009 (UTC)
Well, that was exciting. I seem to have hit a gusher of errors of the form {{Coord|latd|longd|source=geograph.co.uk|region:GB_type:landmark|display=title}}. Until the pressure subsides, I'm going to put off the final edit to {{ Coord/input/ERROR}} to address improvement #2. -- Stepheng3 ( talk) 21:10, 16 October 2009 (UTC)
According to
Template:Coord/doc, {{
Coord}} is supposed to display a blue globe (
) for each set of coordinates. This is broken in many skins, but it usually works with Chick, Monobook, Simple, or Vector. The fact that it doesn't always work, even with these skins, is demonstrated below.
OK, it makes sense to hide the blue globe for off-Earth coordinates. (There probably won't be a WikiMiniAtlas of the Moon any time soon.) However, the fact the the blue globe is hidden for all subsequent coordinates (in my browsers, at least) has got to be a bug. I've seen this both with IE8 and Opera 9.64 and with all four of the skins that usually display the blue globe. Does anyone know what's going on here? -- Stepheng3 ( talk) 03:24, 19 October 2009 (UTC)
* [http://stable.toolserver.org/geohack/geohack.php?pagename=User:Redrose64/Sandbox¶ms=1_N_2_E_ 1°N 2°E ] * [http://stable.toolserver.org/geohack/geohack.php?pagename=User:Redrose64/Sandbox¶ms=3_N_4_E_globe:moon 3°N 4°E ] * [http://stable.toolserver.org/geohack/geohack.php?pagename=User:Redrose64/Sandbox¶ms=1_N_2_E_ 1°N 2°E ]
Is there a reason why Ganymede
is not documented as a legal value for the globe: parameter? Despite being capitalized differently from the other values, it gets a lot of use and doesn't seem to be breaking anything. --
Stepheng3 (
talk)
23:30, 16 October 2009 (UTC)
globe:
. There maybe other parsers which aren't so tolerant of the casing, we need to decide (or I'll decide) if we should be capitalizing the planet names since they are proper names or leave them all lowercase for easier typing. The ghel parser support 36 globes in our solar system (planets+some moons). The supported planets in GeoHack only limited by subpages people have created (
list) and the willingness of to documenting the coordinate system and finding services. —
Dispenser
06:22, 19 October 2009 (UTC)I documented the three additional globes that GeoHack supports and, in the process, learned more than I wanted to know about how longitude is defined for other worlds. Suffice to say that the IAU has coordinates systems set up for 51 natural satellites.
Since the case-sensitivity question is unresolved, I left it undocumented for now. -- Stepheng3 ( talk) 09:55, 22 October 2009 (UTC)
ENUM( 'Mercury', 'Venus', 'Earth', 'Moon', 'Mars', 'Phobos', 'Deimos', 'Ceres', 'Ganymede', 'Callisto', 'Io', 'Europa', 'Mimas', 'Enceladus', 'Tethys', 'Dione', 'Rhea', 'Titan', 'Hyperion', 'Iapetus', 'Phoebe', 'Miranda', 'Ariel', 'Umbriel', 'Titania', 'Oberon', 'Triton', 'Pluto')
. Hopefully, I wont be needing to add more in the near future. —
Dispenser
22:35, 24 October 2009 (UTC)The rendering of text labels on the map that pops up when you click on the blue globe is pretty buggy. Text is often illegible either because of clipping, overlapping or lack of colour contrast with the background. Guess everyone already knows this, right? —Preceding unsigned comment added by 86.138.41.250 ( talk) 01:54, 24 October 2009 (UTC)
{{
coord}}
Is there a general way to give a reference for a display=title coordinate? For an inline coordinate, it seems straightforward: {{coord|...|display=inline,title}}<ref>...</ref>
I see no way to translate that for display=title. The "source" parameter doesn't seem to do nearly as much as a <ref> can. Am I just being anal retentive? Gregbaker ( talk) 05:31, 8 July 2009 (UTC)
Example: [1] 51°51′51″N 31°21′11″E / 51.86417°N 31.35306°E
{{
coord}}
, use <ref> after the tag (e.g. {{coord|...|display=inline,title}}<ref>...</ref>)For reasons relating to EU database copyrights limiting what can be used as a source is a very bad idea. Generaly it's not a good idea to encourage people to draw large numbers of coordiates from a single source.© Geni 13:13, 17 October 2009 (UTC)
{{coord|67.5|22.5|note=<ref>_Encylopedia Galactica_, page 14:322</ref>|display=title}}
I've added a notes=
parameter to the sandbox version of the template. If someone with administrative powers would copy {{
Coord/sandbox}} to {{
Coord}}, I'll take care of updating the template documentation. --
Stepheng3 (
talk)
17:45, 5 November 2009 (UTC)
I've been working on the Infobox Country template on the India page, and I noticed that the coordinates of New Delhi in the Infobox have a little weird symbol combination that looks like this...
‡)28°34'N 77°12'E
I've checked a few other articles that use Infobox country, and they appear okay. So far, I see this little " ‡) " symbol only in the India article and across all nine skins in my IE7. Anybody else see this? and what do you suppose is causing it? I can't find anything in the code for this template nor the Infobox template that might cause this, and the box on the page itself appears to be free of this symbol. If it's coming from outside, then why is it only affecting one particular article's Infobox?
—
.`^) Paine Ellsworth
diss`cuss (^`.
11:17, 27 October 2009 (UTC)
<sup>‡</sup>)
(out). I found it. It was on the "area_km2=3,287,240<sup>‡</sup>" code line in the box on the India page. There is no close paren, however if the <sup>‡</sup>" is removed, the weirdological symbol vanishes, including the close paren. To me, this appears to be a high-falutin' vandalism, but I'm not experienced enough to know for certain.
Last month I added a check to {{ Coord}} such that articles which use "source=" (instead of "source:") would get a bold red error message and a maintenance category. After this turned up a large number of nonstandard template uses, the check was removed. In order to start standardizing these uses, I'd like to add a slightly different check, which would invoke the maintenance category but not display a message. Are there any concerns or objections to adding this check? My next step will be to standardize existing uses of {{ Coord}} (in articles), and when that's done, I'd like to re-enable the error message. -- Stepheng3 ( talk) 19:37, 11 November 2009 (UTC)
Whereas in IE Opera and other browsers the template appears directly under the page title line, in Firefox it stays at a steady distance under the top tabs' line. In the case of long titles, it superimposes on the title letters. Any cure for this? Hoverfish Talk 17:15, 15 November 2009 (UTC)
Hmm. Yes, in the last half an hour Safari (for windows), IE8, Chrome, Opera have also changed as you say and only Flock has it still the old way. Could it be that the Meta-techs are moving things around? Hoverfish Talk 18:18, 15 November 2009 (UTC)
I have Firefox 3.5.5 and Monobook BTW... Oh, and Flock just jumped with the other browsers. Hoverfish Talk 18:28, 15 November 2009 (UTC)
I've been noticing how coordinates in dm and dms formats can be very difficult to read--at least with my browser/skin combination (Monobook/Opera 10.01). This is especially a problem in the title position, due to the small font used. An extreme example is dm-format title coordinates in the northern and/or eastern hemispheres, where the stroke (′) after the minutes of latitude disappears completely into the N, and/or the stroke after the minutes of longitude disappears completely into the E. When the stroke appears immediately before an S or W, it merges with the letter and easy to miss unless you know what to look for. Even the normal font used in inline coordinates has problems with ′W. There are similar problems in dms format with the ′ merging into certain digits and the second stroke of the double stoke (″) merging with a following glyph.
Are others experiencing these problems? If so, I see a various possible solutions: (1) increase the font size (2) switch to a different font family (3) add a space after each stroke and double stroke Each of these solutions might be applied to all coordinates or only to title coordinates. -- Stepheng3 ( talk) 06:03, 20 November 2009 (UTC)
that could be used? --
Redrose64 (
talk)
10:52, 20 November 2009 (UTC)
 
) or narrow no-break space ( 
). In my browser, however, these don't look different from an
.Currently the javascript for the WikiMiniAtlas is loaded on every page view, no matter if a page has coordinates or not. I intend to make it so it only loads when needed. See discussion at MediaWiki talk:Common.js#WikiMiniAtlas.
-- David Göthberg ( talk) 17:26, 15 January 2010 (UTC)
Not sure if this is related to the discussion above but if you go to List of airports in Ontario and scroll down eventually the globe icon vanishes. If you open the page in another tab then you get the same effect but not always on the same line. The same can be seen at the article linked above, List of bridges on the National Register of Historic Places in Pennsylvania. I also noticed that if you click on the globe icon in the airport list you get a grey box with blue links for places around the world but in the bridges you get the grey box and the links are restricted to the US. Enter CambridgeBayWeather, waits for audience applause, not a sausage 22:40, 25 January 2010 (UTC)
For some few weeks at least now, most of the topographical maps have stopped working for Hawaiian islands (except Oahu and Kauai at low resolutions). For example, try 20°48′N 156°20′W / 20.800°N 156.333°W and select any of the topo sites. It used to work. This might not be anything with this template, but perhaps someone here might know if this is a feature or a bug, who to contact, etc. Thanks for any suggestions. W Nowicki ( talk) 23:58, 30 January 2010 (UTC)
It has come to my attention that there are some list articles such as this one that employ numerous calls to this template. These articles are suffering from long (over 20 seconds) load times and high CPU loads on some medium powered machines, leading to concern that they might be inaccessible on older machines. This template was identified as the culprit, and further testing by myself has revealed the real culprit to be the implementation of the javascript WikiMiniAtlas with each call to this template. I slogged through the code on this template and its subtemplates and it appears that the WikiMiniAtlas feature is hard-coded into the template and there is no way to disable it. If there is a way to disable it, that should be made more clear in the documentation so that these kinds of lists can do away with the WikiMiniAtlas feature and eliminate the long load times; if not, can an optional parameter be added to optionally disable this feature? Sher eth 16:31, 29 December 2009 (UTC)
<!-- Served by srv146 in 17.527 secs. --> <!-- NewPP limit report Preprocessor node count: 112588/1000000 Post-expand include size: 737005/2048000 bytes Template argument size: 271536/2048000 bytes Expensive parser function count: 0/500 -->
|WMA=no
that would insert something like style="nowma"
to the link, and then instruct WMA to skip these ones?
Sher
eth
20:33, 29 December 2009 (UTC)This is almost certainly Internet Explorer's horrible string performance, the page loads in about 14 seconds with a bunch of other scripts in Firefox on a decade old machine. — Dispenser 15:16, 1 January 2010 (UTC)
var wma_settings = { onlyTitle: true }
". I can use that to make a small template or an option in {{coord}}, that when placed on a page adds a special id. And I can add code in
MediaWiki:Common.js that triggers on that id and then adds "onlyTitle: true
". Thus making WikiMiniAtlas only work on the title on that page. But it would be better if Dschwen supplied us with a method to disable it for just some coordinates on a page.In case anybody thinks this is a minor problem, or one caused by old machines or bad browsers: Can anybody open up List of bridges on the National Register of Historic Places in Pennsylvania in less than 15 seconds?
What editors would like to do is click on the Bing or Google maps link and see them plotted on a map, or maybe click one set of coordinates and see it on google maps. We'd also like to be able to add a photo in less than 30 seconds. I don't think anybody wants to click on one of the little blue globes and get that funky little map that comes up. Can't those maps just be deleted, thrown away, stamped underfoot, and gotten rid of? Smallbones ( talk) 03:04, 19 January 2010 (UTC)
Nevertheless, I think there is a real need for a lightweight version of Template:Coord for large tables or multiple tables such as found in Mountain peaks of North America. Yours aye, Buaidh ( talk) 03:14, 7 March 2010 (UTC)
<!-- Served by srv203 in 49.154 secs. -->
. Firefox 3.0.18, Windows XP, Monobook. --
Redrose64 (
talk)
16:28, 7 March 2010 (UTC)Started a discussion at Wikipedia talk:WikiProject Geographical coordinates#Add full ISO 6709 support to Template:Coord. Coordinates from tz database come in a ISO 6709 format, but this, nor any other ISO 6709 format is supported. TimeCurrency ( talk) 02:56, 11 March 2010 (UTC)
Lately I've spent a lot of time normalizing type: parameters. I suspect one of the reasons why people use undefined typecodes like type:hamlet
and type:place
is that the documentation (at
Wikipedia:WikiProject Geographical coordinates/type:) doesn't provide as much clarity and guidance as it might, particularly concerning type:landmark
, which seems to be the catch-all.
I plan to edit the documentation to address issues I see. However, I'm bringing up my plans for discussion here in case they prove controversial.
type:city
, the lower limit is unclear. I propose including "hamlets, suburbs, subdivisions, neighborhoods, other human settlements including unincorporated and/or abandoned ones". Otherwise these might get lumped with type:landmark
.type:airport
, include "airbases".type:mountain
, include "hills, submerged reefs, seamounts".type:waterbody
, include "waterfalls".type:river
, include "arroyos, brooks, streams including intermittent ones".type:event
, include "earthquakes, festivals, shipwrecks".type:railwaystation
, include "(railway) maintenance areas".type:landmark
from "buildings of special interest" to "buildings that are neither schools nor railway stations".type:landmark
, enumerate miscellaneous artificial structures including "antennas, bridges, castles, cemeteries, dams, factories, intersections, lighthouses, mines, museums, monuments, power plants, ranches, roads, rocket launch sites, shopping malls, stadiums, theatres"type:landmark
, enumerate miscellaneous natural features including "caves, geologic faults, headlands, valleys".In a few cases I'm unsure which type: applies best...
A. Should craters and calderas be coded as type:landmark
or type:mountain
?
B. Should individual trees be coded as type:landmark
or type:forest
?
C. Should archeological sites be coded as type:landmark
even if they were once cities? I'm tempted to say "yes".
D. I'm unsure how to code fourth-level administrative divisions, such as civil parishes of England. I'm tempted to lump them with "adm3rd" or "city".
E. How should we code non-administrative regions:
biomes, extraterrestrial
regios, and informal regions such as the
Rust Belt? I tend to use type:landmark
and override the default scale using a dim: parameter.
Looking forward to any feedback or suggestions. -- Stepheng3 ( talk) 20:46, 17 January 2010 (UTC)
Regarding issue (D), I've decided to recode English civil parishes as type:city
.--
Stepheng3 (
talk)
19:54, 26 February 2010 (UTC)
type:settlement
instead of type:city
(while still recognising the latter for backwards compatibility) would be less ambiguous, and mirror the use of that word in {{
Infobox Settlement}}.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits
23:01, 19 February 2010 (UTC)
type:settlement
, so I'd like to proceed with this. I'll talk to
User:Dispenser about getting this synonym added to GeoHacks, and then proceed with documenting the change. --
Stepheng3 (
talk)
16:40, 8 March 2010 (UTC)type:city
(with or without population) for villages,
Census-designated places, and so forth.type:settlement(pop)
from the beginning. Perhaps (after a transitional period) we could make type:settlement(pop)
the standard and eliminate type:city(pop)
completely. Would you support that plan, Dschwen? --
Stepheng3 (
talk)
06:52, 9 March 2010 (UTC)
Hi, As far as I understand, Template:coord is the accepted way of adding coordinates to Wikipedia. I have however just discovered Template:Oscoor, which appears to do a parallel job, and seems to be unable to integrate with Template:GeoGroupTemplate (see List of Hewitts and Nuttalls in England), and may not have microformats, nor allow geo-indexing by search engines (e.g. google).
Any suggestions on what can be done to unify Template:Oscoor with Template:coord? -- Ozhiker ( talk) 14:48, 23 February 2010 (UTC)
{{
coord}}
is for use when you have a latitude and longitude on a globe. {{
oscoor}}
is for when you have a British or Irish National Grid Reference on a map (transverse Mercator projection). Further, {{
oscoor}}
should not be used alone, but should be called via any of several wrappers such as {{
gbmapping}}
. --
Redrose64 (
talk)
16:17, 23 February 2010 (UTC){{
coord}}
template via some coordinate conversion so that external systems know about them, so there is one place for microformat code, and one place linking to the GeoHack page.{{
Oscoor}}
or other UTM templates seem to be completely missing from Mashups. :-( --
Ozhiker (
talk)
19:32, 23 February 2010 (UTC)Many mountains are located on international borders. So region codes for two countries are appropriate. For example a mountain on the US Canadian border should use US and CA. Is there a meaningful syntax for this case. I have noticed that some editors have used region:US/CA but this is not a documented syntax. – droll [chat] 22:05, 9 March 2010 (UTC)
+ de:Vorlage:Coordinate, et:Mall:Coordinate best regards 80.142.251.43 ( talk) —Preceding undated comment added 14:08, 16 March 2010 (UTC).
It has been proposed at
Template talk:Infobox mountain that the template use the coord | notes =
parameter to display a link in the title line to a bottom note. This would be for ever page that uses the template. I don't like the idea and I'm wondering if those who watch this template have any thoughts. –
droll
[chat]
07:36, 17 March 2010 (UTC)
I think it's time to get rid of type:state
, which is currently used in only about 250 coordinates. The documentation says it's for specifying coordinates of a "Former country or administrative unit of country, undefined level", but I think it would be better to tag these as type:country
, type:adm1st
, and so on, so as to provide better scale hints to GeoHack. If there's no objection, I'll retag these coordinates and update the template documentation. --
Stepheng3 (
talk)
05:53, 20 April 2010 (UTC)
I stumbled into this yesterday. I think this is a great feature and plan to use it. If I put text after the scale parameter, it will show up before and part the coord image e.g.
{{coord|48.19464|N|3.01776|W|scale:5000 Guerlédan Dam}} yields Guerlédan Dam 48°11′41″N 3°01′04″W / 48.19464°N 3.01776°W
However, if you try to use the name parameter, it gets messed up: e.g.
{{coord|48.19464|N|3.01776|W|name=testname|scale:5000 Guerlédan Dam}} yields Guerlédan Dam&title=testname 48°11′41″N 3°01′04″W / 48.19464°N 3.01776°W
It is way beyond my paygrade to know if this is a feature or a bug. GloverEpp ( talk) 12:41, 29 April 2010 (UTC)
Do we really need the globe? There are a lot of infoboxes that use {{coord}} as a nested template and I at least find it quite disturbing to see the globe interrupt the table structure of the final box output. And when one uses display=title, these boxes will leave the Coordinates field blank but still show the parameter name. De728631 ( talk) 17:51, 31 March 2010 (UTC)
|display=inline,title
". Probably whoever entered them forgot; I've done it.I am visiting this page as a casual reader of the article Mary_Celeste. In section 3 (Discovery of the Mary Celeste), the "coord" template inserts this unpleasant hieroglyph in the middle of the text. It breaks ease of reading, so much that I left the article to complain here. I am not interested in template design, this is only the testimony of somebody _reading_ an article, but I strongly feed something should be done ; inserting a blue small disc in the middle of a sentence is a real disgrace. French Tourist ( talk) 16:41, 2 May 2010 (UTC)
I tried copying this code to this page, but it seems to always give an unrecognized character error there. Would someone here be able to troubleshoot that? -- 209.34.235.6 ( talk) 19:25, 6 May 2010 (UTC)
I had this goofy idea in my head, but I still thought that I would run it by some people here. There have been requests made at various times to add geographic coordinates to the junction lists at the bottom of articles on highways. M6 motorway does this by using footnotes; Montana Highway 16 by including a column of them with {{ coord}} in it for each junction it its very non-standard list. What I'm picturing is something similar to {{ coord}}, but without the full display of the linked coordinates. Maybe it would display just the globe icon. It could be inserted into the distance or exit number column of a list in an article like U.S. Route 41 in Michigan. The data would be there and accessible, but streamlined for display purposes. Thoughts? Imzadi 1979 → 00:53, 10 May 2010 (UTC)
The coord function seems to have gone haywire. For example, the coordinates here Lot_(river) were working yesterday. GloverEpp ( talk) 12:56, 13 May 2010 (UTC)
I have a question about the regions, can we use regions:Kosovo for kosovo? e.g : template : coord|42.2068|N|20.7374|E|region:Kosovo
thanks, mike James Michael DuPont 13:36, 23 May 2010 (UTC)
Is there something similar like mountains for other landscapes like deserts, peninsula or larger regions? -- Tobias_dahinden 13:07, 2 June 2010 (UTC) —Preceding unsigned comment added by 130.75.51.124 ( talk)
After seeing this, it got me thinking that we could potentially set up some sort of a check for some of the more basic errors in specifying the region, source, type, ... passed to the coord template. One very basic check is to look for < and [ in the field using say {{ str find}}. This could be one of the checks that throws an error exception. This wouldn't find all such errors, but doing that may create too much server load. Here is some code that finds wikilinks and html tags in a field:
{{#ifexpr: {{str find|{{{region-iso|}}}|[}} < 0 | Good | Bad}}
and
{{#ifexpr: {{str find|{{{region-iso|}}}|<}} < 0 | Good | Bad }}
This test could go in {{ Coord/link}} or upstream in the top level template with the other error exceptions. It would be really nice if we could check the validity of the region field, but I am afraid that would take far more work. Comments? Plastikspork ―Œ(talk) 15:19, 15 April 2010 (UTC)
region-iso=
is not a {{
Coord}} parameter, so that check would have to be performed at a higher level template (in this case {{
Infobox mountain}}). Unless you know how to parse the coordinate parameters, that is, in which case I'd like to see a prototype.
{{{region-iso}}}
was just a dummy value to give an idea of what I was talking about. Basically, I believe that none of the unnamed parameters in this template should contain wikilinks, flag templates, or html code.
Plastikspork
―Œ(talk)
18:36, 15 April 2010 (UTC)
{{#ifexpr: {{str find|{{{1|}}}{{{2|}}}{{{3|}}}{{{4|}}}{{{5|}}}{{{6|}}}{{{7|}}}{{{8|}}}{{{9|}}}{{{10|}}}|[}} < 0 | Good | Bad}} {{#ifexpr: {{str find|{{{1|}}}{{{2|}}}{{{3|}}}{{{4|}}}{{{5|}}}{{{6|}}}{{{7|}}}{{{8|}}}{{{9|}}}{{{10|}}}|<}} < 0 | Good | Bad}}
display=
parameter.--
Stepheng3 (
talk)
16:48, 15 April 2010 (UTC)
display=
, I've added namespace support for to my
redlink prefix index tool to identify all cases. —
Dispenser
04:33, 16 April 2010 (UTC)
{{#ifexpr:((0{{{2|-1}}}+1) and not (0{{{6|-1}}}+1)) or (not (0{{{2|-1}}}+1) and (0{{{6|-1}}}+1)) != 0|Empty warning}}Of course with every additional step it takes longer and longer to render a page w:List of craters on Mars: A-L has 534 points and takes 47 seconds to render. On geosearch.py its going to optional once I write tools to handle the errors that have surfaced regarding geohack URL missing this template. — Dispenser 07:05, 16 April 2010 (UTC)
{{#if:{{{1|}}}||Empty warning}}do the trick? -- Stepheng3 ( talk) 08:06, 16 April 2010 (UTC)
Yes, I figured that this might be a bit expensive. This {{#ifeq:{{padleft:|1|{{{foo|}}}}}|<|Bad|Good}} and this {{#ifeq:{{padleft:|1|{{{foo|}}}}}|[|Bad|Good}} aren't as expensive, and catch some cases, but probably would be better to just to other individual templates that call this one. For example, this works for the region example:
{{#ifeq:{{padleft:|1|{{flag|Egypt}}}}|<|Bad|Good}}
and
{{#ifeq:{{padleft:|1|[[Egypt]]}}|[|Bad|Good}}
By the way, I am aware of the problem with the Mars Craters page. I had to split it after running into the problem of exceeding the total number of templates on a page limit. I think it could be split again due to the size. Although, it is a good test case for illustrating a point. Plastikspork ―Œ(talk) 17:06, 16 April 2010 (UTC)
<!-- Served by srv207 in 43.015 secs. -->
. There's also inital caching delay. I ran the tests a few times and it seems the one without the check is about 2 seconds faster (40.366 vs 42.386) but this is rather negligible across 500 especially when comparing to {{
coor d}} which can renders 2000+ coordinates in 20 seconds. —
Dispenser
04:34, 19 April 2010 (UTC)
Getting back to the original problem. Since these users don't look at the HTML output, big red error messages are going to do nothing. So we need a way of detecting these broken URLs. Instead of use the expensive parser functions, I propose that we append &
to the end of the coordinate URLs and use geosearch.py with [^&]$
. —
Dispenser
04:34, 19 April 2010 (UTC)
(space) (newline) [ ] < > "
characters, as soon as it encounters one of those characters it will treat the rest as the title (gets tricky with '' and '''). If we have a known marker at the end the URL, it wont be included if the mentioned truncation happens. We then can then search for URLs missing this marker indicating something was lost. There's also the {{urlencode:}} function (can now produce underscores) but hasn't been thoroughly debugged yet, it may double escape input and escapes everything that isn't 0-9A-Za-z:._
. —
Dispenser
19:06, 30 April 2010 (UTC)
{{
editprotected}}
{{
editprotected}}
Done. Plastikspork ―Œ(talk) 21:11, 9 May 2010 (UTC)
It's the change from
|1={{{1|}}}|2={{{2|}}}|3={{{3|}}}|4={{{4|}}}|5={{{5|}}}|6={{{6|}}}|7={{{7|}}}|8={{{8|}}}|9={{{9|}}}|10={{{10|}}}|
to
|{{{1|}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|{{{5|}}}|{{{6|}}}|{{{7|}}}|{{{8|}}}|{{{9|}}}|{{{10|}}}|
In the |1={{{1|}}}|
form, any leading or trailing spaces are stripped from parameter 1 before it's passed on; but in the |{{{1|}}}|
form they're not. This is significant when you start substituting the actual values used into the subtemplates, and you find that {{
Geobox2 coor}}
inserts a space prior to the latitude degrees before sending this into {{
coord}}
. You can check this by using the subtemplate {{
coord/input/dms}}
directly. The code
*{{Coord/input/dms|1= 51|2=02|3=21|4=N|5=116|6=26|7=33|8=W|9=type:river_region:|10=|format=|name=}} *{{Coord/input/dms| 51|02|21|N|116|26|33|W|type:river_region:||format=|name=}} *{{Coord/input/dms|51|02|21|N|116|26|33|W|type:river_region:||format=|name=}}
produces this
{{
Coord/input/dms|51|02|21|N|116|26|33|W|type:river_region:}}
{{
Coord/input/dms|51|02|21|N|116|26|33|W|type:river_region:}}
It's just that one space that causes the problem. The bug therefore lies within {{
Geobox2 coor}}
. --
Redrose64 (
talk)
16:57, 7 June 2010 (UTC)
{{
editprotected}}