Template talk:GeoTemplate

Subpages

• /doc - Documentation on the keywords
• /sandbox - Sandbox for test edits and design work
• /lang - Language bar hack
• /guideline - Guidelines for link inclusion

Test coordinates

Without region codes New York City 40.71°N -74.00°E Australia 35°18′S 149°08′E Chile 33°26′S 70°40′W Anadyr, Russia 64°44′N 177°30′E Córdoba, Spain: 37.883333°N 4.766667°W / 37.883333; -4.766667 (Córdoba, Spain) Hamilton, New Zealand: 37.783333°S 175.283333°E / -37.783333; 175.283333 (Hamilton, New Zealand) Other globes Venus: Venera 8 10.70°S 335.25°E / -10.70; 335.25 (Venera 8)

With region codes US: White House 38.89767°N -77.03655°E GB-LND: London,Trafalgar Square 51°30′28″N 0°07′41″W JP-13: Tokyo 35°41′N 139°46′E RU: Moscow 55°45′8″N 37°37′56″E AU-ACT: Canberra 35°S 149°E FI-LS: Akaa 61°10′N 23°52′E CH-VS: Zwischbergen 46°10′N 8°7′E NZ: Auckland 36°51′S 174°47′E

After you change this template it might be a good idea to purge the squid cache

Localized NSEW

Is there a way to get localized equivalents to {latNS} and {lonEW}? It would be nice to display the coordinates at the top of the page using the letters for North/South/East/West in the local languange. E.g. {latEWlocalized|O|W} would insert O or W instead of E or W. --C960657 (talk) 11:42, 10 August 2008 (UTC)

Here is a patch that adds the requested feature. Just replace the last line of map_sources::build_output() in mapsource.php with the following:

       // Allow localized versions of NSEW, e.g. {lonEW|O|W}
       preg_match_all('/{(latNS|lonEW)\|([^|}]*)\|([^|}]*)}/u', $bstext, $tags, PREG_SET_ORDER);
       foreach ($tags as $tag) {
           if (!in_array($tag[0], $search)) {
               $search[] = $tag[0];
               if ($tag[1] == 'latNS') {
                   $replace[] = $lat['NS'] == 'N' ? $tag[2] : $tag[3];
               } elseif ($tag[1] == 'lonEW') {
                   $replace[] = $lon['EW'] == 'E' ? $tag[2] : $tag[3];
               }
           }
       }

       // Allow localized decimal point and thousand separated, e.g {londegdec|,} or {scale|,�|.}
       preg_match_all('/({\w*(?:dec|int|abs|scale))\|([^|}*])(\|[^|}]*)?}/', $bstext, $tags, PREG_SET_ORDER);
       foreach ($tags as $tag) {
           $i = array_search($tag[1] . '}', $search);
           if ($i !== false) {
               $search[]  = $tag[0];
               $decimals = strlen(substr(strrchr($replace[$i], '.'), 1));
               $replace[] = number_format($replace[$i], $decimals, $tag[2], isset($tag[3]) ? substr($tag[3], 1) : );
           }
       }

       return str_replace( $search, array_map('htmlspecialchars', $replace), $bstext );

--C960657 (talk) 18:36, 16 August 2008 (UTC)

seldom seen roadhouse

{{editsemiprotected}} Geographic co-ordinates have been "rounded" to nearest degree. I would like to put in the accurate co-ordinates. Wombatburrow (talk) 06:36, 11 August 2008 (UTC)

seldom seen roadhouse - response

If you identify which "seldom seen roadhouse" i.e. which Wiki article, the corresponding coordinates can probably be updated. In general, Wiki allows coordinates to be specified in Degrees (about 60 Nautical Miles), Minutes (1 Nautical Mile), and Seconds (1/60 th. of a Nautical Mile). A Nautical Mile is approximately 6,076.1 feet (1,852.0 m) so for most "map" uses Seconds are "close enough" (about 100 feet (30 m)) - similar to GPS "quick fix" (non-differential, non-L2 military/surveying) accuracies. If one is trying to document a "surveying monument" (or a GeoCache) then accuracies of 1/100th. (0.01) of Second might be appropriate. LeheckaG (talk) 07:22, 11 August 2008 (UTC)

Presuming you are referring to Seldom Seen Roadhouse 37°7′S 148°15′E? If you describe where it is on either a satellite image, road map, or terrain map, then I can Geocode it if you do not already have more accurate coordinates (i.e. what should the Latitude and Longitude seconds be?)

Google Maps satellite imagery can zoom in to an about 1 inch (2.5 cm) = 2,000 feet (610 m) scale, showing a hilly or mountainous area with apparently the Gelantipy road going primarily North-South, and Seldom Seen Road going off to the West. Where is it relative to the intersection of either those (2) or another feature (river, road, ...) intersection? LeheckaG (talk) 18:51, 11 August 2008 (UTC)

Venice-Iraq editsemiprotected

The coordinates of this page do not lead to Venice, but to the site of a massacre in Iraq.

Unsigned by: 128.195.110.107 (→{{editsemiprotected}}: new section)

Venice-Iraq editsemiprotected response

Which Wiki article page and what were the respective coordinates? LeheckaG (talk) 03:14, 12 August 2008 (UTC)

I spot-checked:

• Venice (45°26′N 12°19′E)
• Venice, Los Angeles, California (33.99083, -118.45917)
• Venice, Florida (27°5′55″N 82°26′20″W)

Iraq (for instance Baghdad 33°20′N, 44°26′E) has similar Latitudes to (Los Angeles) California, so guessing a Venice/Los Angeles/California article has an incorrect Longitude? LeheckaG (talk) 03:45, 12 August 2008 (UTC)

How about adding a 'download GPX' link to GeoHack? Tedder (talk) 00:56, 23 August 2008 (UTC)

Geoportail... page non existing

Hello to all! Maybe this have been discussed but can't find when. When a French coordinated article is opened it gives the option to see maps and aerial views on Geoportail... but unfortunately it seems that the system has moved and it's not possible to see the page, only a "Page non existing" message. I've been looking how to solve it but it seems very difficult to me. But fortunately there are some pages that explain how to solve the problem using an script to change the coordinates from the normal system to the one used in the geoportail. As the code is open-source ([1]) it can be used and referenced when we want. Does anyone know how to solve this? -Theklan (talk) 19:22, 24 August 2008 (UTC)

Is there a way to link to a map of a specific location rather than embedding their maps here? -- User:Docu

Little Wymondley Co-ordinates

The co-ordinates given for Little Wymondley, Hertfordshire, UK are incorrect. The OS reference TL226257 should be TL215275. —Preceding unsigned comment added by PinGreenScout (talk • contribs) 07:24, 29 August 2008 (UTC)

Edit article link

To edit the article where the coordinates are located, I added a new link to the template [2]. In addition, I provide a link to the articles talk page. This adds a line below the title bar as follows to the page (sample from coordinates linked by New York City [3]):

Title	New York City (All coordinates)
Article:	New_York_City [ | ]

The comment link doesn't work if the coordinates are on a page that is not in article namespace. I modified {{Geodata-check}} to have it display a notice for article's talk page.

Possibly the best place to discuss incorrect coordinates is not the article's talk page, but either here or WT:GEO? -- User:Docu

The revised version is an improvement as it focused on the main features, but it may suggest to "report inaccuracies" rather than fix them directly. -- User:Docu

HTML markup samples replaced with XHTML

Dispenser (talk · contribs) recently replaced the HTML samples in this template with XHTML; I reverted, and he did so again. I find his reasons for doing so unconvincing, and intend to replace the HTML unless there are good reasons not to; since neither should be promoted above the other, and HTML was used first. Andy Mabbett | Talk to Andy Mabbett 19:33, 1 September 2008 (UTC)

XHTML is HTML with a stricter structure. If Alice writes an XHTML page and forget to add slashes to the HTML (using it as we present it) it FAILS validation. Conversely if Bob writes an HTML 4.0 Strict page and uses the XHTML it will continue to PASS validation. Thus XHTML is better for both. Continuing to ignore the arguments I present and claiming that first use trumps all is counter-productive. — Dispenser 00:53, 3 September 2008 (UTC)

Since no such claim was made, your latter point is redundant, if not misleading. None of your arugments (sic) have been ignored. Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions

Please stop reverting to XHTML. There appears to be no support for the change. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 14:45, 8 September 2008 (UTC)

You have not addressed any of my arguments directly, and providing arguments all of which are in the form of Bob simply likes B. Perhaps, if I had called it "adding attributes to HTML for compatibility with other standards" and claimed it only looks like XML you might agree with the changes. Finally about support there are only two people in this debate it looks like I have to resolve to wp:third opinion. — Dispenser 16:03, 8 September 2008 (UTC)

I'm sorry that you have not understood that I have addressed the issues you;ve raised. Your "Bob simply likes B" is simply an invention; as is your XML comment. I indicated my intention to revert your (undiscussed) changes here, on this busy page, and no-one else objected. On Wikipedia, silence=consent. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 16:16, 8 September 2008 (UTC)

If we can use a new sample for both HTML and XHMTL, there isn't really a point in keeping the current HTML version. -- User:Docu

Do you have any evidence (as opposed to theoretical debate) that people write and publish valid HTML 4.01 with closing slashes? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:21, 9 September 2008 (UTC)

The reasoning made by dispenser doesn't bring forward this point. -- User:Docu

It is more and more beneficial to use XHTML rather than older forms of HTML. Given that "This HTML markup is provided for use in other websites" it would seem to be an improvement to include the closing slashes required for validation, rather than only giving instructions to "add closing slashes for XHTML if appropriate." Generally closing slashes do not cause problems for older browsers, so there would seem to be no harm in including them. I came here after seeing the listing on WP:3, however, I can't offer a real 3rd opinion because I'm not sure I understand the issue. Maybe you could give a concise summary here of the pros and cons of XHTML in this context. There are obvious advantages to XHTML, but maybe there are disadvantages I'm unaware of that could be stated clearly here. Mesopelagicity (talk) 07:03, 10 September 2008 (UTC)

For whom is XHTML more beneficial? If you mean for publisher or readers on the wider web, that's a PoV, and proselytising it on this template is not in accordance with Wikipedia's policy of neutrality. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:32, 10 September 2008 (UTC)

This isn't about proselytizing anything. One might just as well call any attempt to improve an article "proselytizing" on the basis that whether or not something is an improvement depends on one's point of view. Yes, it is my belief that XHTML is generally more beneficial for both publishers and readers. (According to w3.org, "The XHTML family is the next step in the evolution of the Internet." [[4]].) However, the reason to use XHTML in this article would not be to convince people to share this belief. The reason would be to make the article more practically useful to its readers, since they could copy and paste the code into another web page, regardless of whether that page were HTML 4 or XHTML. The policy of neutrality would imply that if this article were discussing the pros and cons of XHTML versus HTML 4, that discussion should be neutral, but that's not what the article is doing, and in any case giving preference to HTML 4 would not be neutral either. If you're opposed to the use of XHTML in this article, you need to give a convincing reason for that opposition. It's useless to argue that "HTML was used first"; Wikipedia articles are meant to be improved. The bottom of the page clearly states, "If you don't want your writing to be edited mercilessly ..., do not submit it." Mesopelagicity (talk) 17:28, 10 September 2008 (UTC)

Where have I objected to my writing being edited? Please don't put up straw men. My point is that there is no clear advantage to our readers in displaying XHTML over 4.01 (or vice versa, for that matter) and as such we should stay with what we have; by analogy with en_Gb vs. en_US, AD vs. CE and similar precedents. Claims that "closing slashes are valid in HTML 4.01" are meaningless; what matters is whether our readers use closing slashes in HTML 4.01, or not (the requested evidence has not, as yet, been forthcoming). My experience is that HTML 4.01 authors do not; and though I use both 4.01 and XHTML; and will have to remove the closing slashes from for 4.01, according to the house standards where I do so; and I know I'm not alone in that. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:43, 10 September 2008 (UTC)

I apologize for my incorrect speculation that you might have objected to your writing being edited. I was trying to understand the significance of the argument that "HTML was used first", and I had no intention of putting up a straw man. Thank you for the clarification. Also thanks for raising the issue of house standards for HTML 4.01, which is the first argument against closing slashes I've seen that appears to have any merit. Nevertheless, the fact incorrect belief that "closing slashes are valid in HTML 4.01" is far from meaningless. It supports would support the argument that closing slashes are valid for both HTML 4 and XHTML and therefore code with closing slashes is more generally useful. A house standard against closing slashes seems unfortunate since it obstructs writing code that is compatible with both HTML 4 and XHTML. I would expect such a house standard to change with the times, and I suspect there must already be some house standards that dictate the opposite -- using closing slashes whenever such usage provides interoperability between XHTML and HTML 4. I don't have evidence for that suspicion, though. Nevertheless, providing compatibility with both XHTML and HTML 4 seems to me a higher priority than providing compatibility with a particular house standard, so my opinion now is that it is better to use closing slashes in this article. Mesopelagicity (talk) 19:09, 10 September 2008 (UTC) (struck-out mistakes Mesopelagicity (talk) 01:18, 16 September 2008 (UTC))

No; you did. I'll take that as "no", then. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:32, 10 September 2008 (UTC)

Wikipedia:Third opinion: Put in the /s. They don't hurt strict HTML compliance, and do aid XHTML compliance. "We should stay with what we have" isn't a convincing argument where there is a reason to change, it's only convincing when the two alternatives are equivalent. Since with one alternative we meet two standards, and with the other, only one, they're not equivalent. The "house standards" not to do so don't seem to be documented anywhere, so could well be extrapolating from a limited subset. --GRuban (talk) 15:14, 11 September 2008 (UTC)

I decided to check this out; and it seems that [validation link redacted - see below] closing slashes in HTML 4.01 are invalid]. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:44, 15 September 2008 (UTC)

You're right and I was wrong. What an inconvenient truth! I'd be in favor of giving priority to XHTML over HTML 4, but the idea of supporting both with the same code seems to be hopeless. Mesopelagicity (talk) 01:18, 16 September 2008 (UTC)

Thank you. Since I and others favour HTML 4,.01 over XHTML (and I admit that that's as much a matter of religion as science!); the only way to resolve this fairly would seem to be, as I said above (and as did GRuban, inadvertently!), to take the precedence of en-GB vs, en-US, or "AD" vs "CE", and stick with what was used first. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 01:24, 16 September 2008 (UTC)

Thank you Andy, well checked. --GRuban (talk) 18:33, 17 September 2008 (UTC)

Y'welcome. I'm going to fix the page, soon, so anyone reading this in future will have to take our words for it, or conduct their own test. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:17, 17 September 2008 (UTC)

geo.region

I have just removed, for the second time, the addition of a "geo.region" mark-up sample. The GEO metadata header comprises two parts: two-letter country code and one-, two- or three-letter regional code (ISO 3166-2), separated by a hyphen [5]. The regional code is optional only if the country identified in the first part has no defined region codes. As I explained in my first edit summary, the code for a suburb of Birmingham, such as Perry Barr, should be "GB-BIR". The mark-up I have removed included the country-code "GB", but not the hyphen and region-code; presumably because region-codes in coordinate templates are less precise. Andy Mabbett | Talk to Andy Mabbett 20:05, 1 September 2008 (UTC)

It's not that important if we add geo.region or not. An easy way to fix it would be to complete the region-code on Perry Barr. BTW why do you mention "Dublin Core"? -- User:Docu

Indeed it's not important; but if we do so, we should do it properly. Fixing Perry Barr (if it is broken - are coordinates links supplied to always use available 2+3 format location codes?) would resolve the issue in respect of that one article, but no other. Dublin core was included in the subject header in error. Andy Mabbett | Talk to Andy Mabbett 15:10, 2 September 2008 (UTC)

Nearest latitude & longitude articles

For a longitude value of, say, 1° 54, this service links to the "1° W" article, where the "2° W" article would be more relevant. Is it possible to add logic to solve this issue, or offer both? Likewise for the nearest latitude. I thought I had the answer in latdeground & londeground but they don't work for negative values, so I've reverted myself. For example, San Paulo is at 23.5433°S 46.633°W / -23.5433; -46.633. Existing parameters give:

• latdegabs: 23,
• latdegint: -23
• latdeground: -24
• londegabs: 46
• londegint: -46
• londeground: -47

but there appears to be no parameters for the required, positive-integer values of "24" or "47". Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 16:09, 8 September 2008 (UTC)

Another sunrise and sunset calculation brought to you by Earthtools

http://www.earthtools.org/sun/{latdegdec}/{londegdec}/{{CURRENTDAY}}/{{CURRENTMONTH}}/99/0

Examples for New York:
http://www.earthtools.org/sun/40.71417/-74.00639/18/12/-5/0 fixed timezone
http://www.earthtools.org/sun/40.71417/-74.00639/18/12/99/0 auto timezone

Text on page could be something like:

• www.earthtools.org Get today's sunrise and sunset information for this location (result is XML-formatted, automatically calculate timezone, no DST)

Thomas Lerman - 17:43, 9 September 2008 (UTC)

Markup samples

As markup samples are not meant to be used in this wikipedia, but elsewhere. There isn't really a point in removing samples from the template, e.g. {{coor d}} or {{coordinate}}. As there is no consensus for such a change, it should be reverted. -- User:Docu —Preceding unsigned comment added by Docu (talk • contribs) 11:25, 10 September 2008 (UTC)

Where else are such samples - deprecated by consensus for WP-EN - likely to be used? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:27, 10 September 2008 (UTC)

In any non-EN WP. -- User:Docu —Preceding unsigned comment added by Docu (talk • contribs) 11:33, 10 September 2008 (UTC)

Then they should be in a separate section, lower down the page, and clearly marked as not for use on WP-EN (until such time as other WPs deprecate them). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:37, 10 September 2008 (UTC)

Now done. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:43, 10 September 2008 (UTC)

Even {{coord}} isn't for use in WP-EN as the source:enwiki hasn't much use here. -- User:Docu —Preceding unsigned comment added by Docu (talk • contribs) 11:39, 10 September 2008 (UTC)

I can't parse that. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:43, 10 September 2008 (UTC)

source:enwiki would indicate in the WP of another language that the coordinates were copied from here. The Anome imports coordinate to WP-EN and indicates their source, e.g. source:eswiki. -- User:Docu —Preceding unsigned comment added by Docu (talk • contribs) 19:38, 10 September 2008 (UTC)

google maps location label

I found a way to label the point in Google Maps; I adjusted the first three URLs accordingly. I tested it every way I could think of using two dozen kinds of coordinates, FireFox, Sea Monkey, and Internet Exploder. I didn't see anything go wrong, so I'm inclined to leave the change unreverted. If you do see something wayward, please let me know. —EncMstr (talk) 06:44, 14 September 2008 (UTC)

This had stopped the scale/type parameter from working. All links from articles to Google Maps ended up at the same scale and far too close in for details to be seen. In some cases the sat image was not visible at all. CambridgeBayWeather Have a gorilla 07:39, 16 September 2008 (UTC)

See Image:CYCB 1 cropped.JPG which shows the problem. The image is too close for the entire airport to be seen and the label says it's "Cambridge Municipal Airport" but is Cambridge Bay Airport. Image:CYCB 2 cropped.JPG shows how it should normally look. I have a couple of other screenshots if required. CambridgeBayWeather Have a gorilla 08:16, 16 September 2008 (UTC)

PlanetEye URL structure update required

PlanetEye has updated the structure of their URLs and as a result need to be updated from: http://www.planeteye.com/Map.aspx#lat={latdegdec}&lng={londegdec}&z={osmzoom}&mediaLens=media to http://www.planeteye.com/Map.aspx?lat={latdegdec}&lng={londegdec}&z={osmzoom}&mediaLens=media (change # -> ?). The old URL will still work, but it will fail to point users to the requested coordinates. Please note that PlanetEye is listed at the top of the template and should be added to the "Photography" section near the end of the template. —Preceding unsigned comment added by Planeteye (talk • contribs) 12:53, 19 September 2008 (UTC)

I've made the change, but don't have Flash on this machine; please will someone check the results? Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:00, 19 September 2008 (UTC)

The first link (under Global Systems) works fine now. However, the same change is required for the link under "Other systems with wiki aspects". If applicable, I believe it should also be added to the "Photography" section at the bottom. Thanks! Planeteye (talk) 11:30, 21 September 2008 (UTC)

Latitude / Longitude links

The Wikipedia articles on individual latitudes / longitudes aren't at titles "Latitude 60 degrees N" ("Longitude 20 degrees E" etc.) as linked, but instead at 60th parallel north (20th meridian east, etc.) --dab (𒁳) 11:24, 2 October 2008 (UTC)

There are redirects at Category talk:Lines of latitude and Category talk:Lines of longitude that link to those articles. As geohack can't do ordinals yet, at some point we have to use redirects. The question is if which of the below you prefer:

1. "{londegabs}_meridian_{lonEW}" => 101 meridian W
2. "{londegabs}nd_meridian_{lonEW}" 101nd meridian W
3. "Longitude_{londegabs}_degrees_{lonEW}" => Longitude 101 degrees W
4. etc.

BTW, I just created the missing redirect from Latitude 60 degrees N. -- User:Docu

Local landmarks?

Is there anyway to locate local landmarks near a landmark on GeoHack?

For example, what are the local landmarks already on GeoHack near Odessa Philharmonic Theater? Thank you. Odessaukrain (talk) 13:43, 17 October 2008 (UTC)

Currently the best (only?) way would be to open a Google Maps view, and enable (via the "more" tab) their Wikipedia layer: thus. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:15, 17 October 2008 (UTC)

In the second section of the GeoHack page is Systems with Wikipedia data. For example, choosing a 20 km radius of the last entry gives this. Note that has a "map" button for graphic display, though crude, it's evolving. If you have Google Earth, there are a few other good options in the section as well. —EncMstr (talk) 15:37, 17 October 2008 (UTC)

In addition to Google services, Multimap and Geonames have Wikipedia placemarks as well. Geonames also shows a list sorted by distance, like the toolserver list EncMstr mentioned.

It would be great if we could somehow get this information on the page so that people wouldn't need first hand experience of each service to know what they're like. There could maybe be tags for each service that people could then choose from to see the services with that tag at the top of the list or a separate frame. That would probably require Javascript, but this type of dynamic functionality has been requested before as well, so that people could have their preferred services first. --Para (talk) 16:43, 17 October 2008 (UTC)

Wow you guys rock, this page is much more active than most of the other pages. I got three responses in 12 hours. Incredible! thank you! Odessaukrain (talk) 07:37, 18 October 2008 (UTC)

**Later** Para, how do you access Multimap and Geonames placemarks? And the Geonames list sorted by distance? thank you. Odessaukrain (talk) 08:03, 18 October 2008 (UTC)

Well, if you click on the GeoHack link, on the left side there's links to both of those services. The Multimap service has a checkbox on the left side for turning on the Wikipedia placemarks, similar to Google. Multimap seems to require a close zoom before it shows anything, though. The Geonames link leads you to a map view that has the list underneath. Both of those services rely on Wikipedia database dumps which don't come out very often, so the data may be a bit old, but looking at a live map of the Odessa category, there aren't that many Odessa related articles with coordinates. Looks like you'll need to go through some categories with help from Wikipedia:Coordinates! --Para (talk) 12:39, 18 October 2008 (UTC)

Thank you! This page is by far the easiest to use for what I want to do right now. Para, interesting that your user name is in the Google box and the web address. thanks again Para. Odessaukrain (talk) 17:08, 18 October 2008 (UTC)

Glad to hear that, as the tool that enables the functionality is indeed mine. I can't take much credit for leading people to it, though, since this talk page is the only place where you could have found the live map link of the category tree. Linking to it is a bit of a puzzle, discussed at Template talk:GeoGroupTemplate#Request for recursive grab of category tree to specified depth. Maybe others will have ideas to solve the problem mentioned there? --Para (talk) 13:59, 19 October 2008 (UTC)

Streetmap link

The link from this template using www.streetmap.co.uk appears to come out in the wrong place. It just came to notice after I made this edit. Using Google Earth I got 53.740639 -0.338164 (53° 44' 26.30"N -0° 20' 17.39"W) which is in the middle of the ship. A test on the page got me this Map sources/GeoHack listing. In turn I got this from Google Maps but it made the Streetmaps link is right off. But if you go to the Streetmap site directly then this is what you get, which looks fairly close. The other links on the template look to be in the right place, so is there any way to fix the Streetmap link? Thanks. CambridgeBayWeather Have a gorilla 23:06, 17 October 2008 (UTC)

There was a mention of problems with the conversion at Wikipedia talk:WikiProject Geographical coordinates/Archive 12#UK co-ordinate conversions faulty.3F, but it seems that nothing came of it despite all the noise. That's unfortunate to say the least. Luckily StreetMap handles the WGS84 coordinates used on Wikipedia as well, and I just changed the links to use those instead. That's problem solved with StreetMap, but there are still other services that use the OSGB grid references... --Para (talk) 00:13, 18 October 2008 (UTC)

Thanks for the quick response on that. CambridgeBayWeather Have a gorilla 00:40, 18 October 2008 (UTC)

Problems with kmlexport

Link problems

I don't know how this can be solved: The link you gave above, which was the "live map of the Odessa category":

http://toolserver.org/~para/cgi-bin/kmlexport?article=Category:Odessa&redir=google&l=0

Links too a different Google maps address every time, such as these:

http://maps.google.com/maps?q=http://toolserver.org/~para/kmlexport-temp/23e8fa27a50d25cfb2762b98e5d62ccf.kmz

http://maps.google.com/maps?q=http://toolserver.org/~para/kmlexport-temp/51bc4be4ebeb6a56c561be56d1aef065.kmz

http://maps.google.com/maps?q=http://toolserver.org/~para/kmlexport-temp/fecd41b9b4c43051f4cef69fc0eb06bc.kmz

The maps.google.com link I added to this page yesterday:

http://maps.google.com/maps?q=http://toolserver.org/~para/kmlexport-temp/cf7c2d806a126ab22f4bef3ad80eb06e.kmz

No longer works, do these links expire after a certain period of time? So if someone likes your link, they cannot save the page address on google maps and return to it. Odessaukrain (talk) 14:37, 19 October 2008 (UTC)

Yes, they expire after a while, and I was hoping the "temp" and odd file name would have given that out. Maybe I will have to make the caching internal to the tool at some point, instead of distributing temporary urls. Perhaps everything about this tool should be discussed on Template talk:GeoGroupTemplate, since links from categories never lead to the GeoTemplate? --Para (talk) 15:34, 19 October 2008 (UTC)

Categories listed?

If you notice here: http://toolserver.org/~para/cgi-bin/kmlexport?article=Category:Odessa&redir=google&l=0

and

Category:People from Odessa

are listed on the map, which both link to bad locations...

how can we fix this? Odessaukrain (talk) 14:37, 19 October 2008 (UTC)

That request makes Google Maps show all the articles from Category:Odessa and its subcategories that have coordinates. There are lots of articles in the category, and some of them may have incorrect or inappropriate coordinates.

The "link to bad locations" probably means what Google Maps shows when you click on a folder name (category): "We are sorry, but we don't have imagery at this zoom level for this region. Try zooming out for a broader look." The problem there is that when there are no placemarks in a folder, or just one placemark, or many placemarks in a small area, Google Maps zooms to the maximum zoom available in the interface, even when they do not have imagery detailed enough. This is a Google Maps problem that we can't really do anything about, except maybe by not showing empty categories in the list? I'm not sure about that fix, since sometimes it may be useful to know that a geographically related category has certain subcategories with no articles with coordinates, but in many cases it can indeed be useless information. --Para (talk) 15:34, 19 October 2008 (UTC)

Not all locations listed

The link: http://toolserver.org/~para/cgi-bin/kmlexport?article=Category:Odessa&redir=google&l=0

Does not list all locations, including the Seventh-Kilometer Market and Odessa International Airport Odessaukrain (talk) 14:57, 19 October 2008 (UTC)

That's a categorisation problem: those articles aren't in any of the subcategories of Odessa. You can fix it by adding them to Category:Buildings and structures in Odessa, Ukraine for example. --Para (talk) 15:34, 19 October 2008 (UTC)

thanks, I will do that, I appreciate your response. Odessaukrain (talk) 13:28, 20 October 2008 (UTC)

Template:Coord Floating over the top line:How?

Can anyone explain how the Template:Coord is able to float over the top line? thanks Odessaukrain (talk) 14:13, 20 October 2008 (UTC)

It's done using the CSS position:absolute: which is found for those using the MonoBook skin on lines 137-162 in MediaWiki:Monobook.css — Dispenser 14:22, 20 October 2008 (UTC)

Thank you so much sir/ma'am, you are wonderful. What a quick response too. Odessaukrain (talk) 14:28, 20 October 2008 (UTC)

*later* Great starting at:

/* For positioning icons at top-right, used in Templates

"Spoken Article" and "Featured Article" */

And concluding at:

text-transform: none;

white-space: nowrap;

} [line 163]

Odessaukrain (talk) 14:39, 20 October 2008 (UTC)

Generally, this should make it should float below the the top line, but what makes it float on the top line (e.g. at Lakehurst_Mall) ? -- User:Docu

Infoboxes are specified with a small font-size (90%) and the positioning is specified in ems which is affected by font-size. This is done so that when a user scales the font size of the page all the interface elements scale accordingly. This could be corrected by using the inverse font-size (111%) around the outside the coordinate. Or adding a class to correct the positioning when present in an infobox. — Dispenser 16:57, 20 October 2008 (UTC)

Is there a way to correct it in Template:Coord/display/inline,title ? My attempts at Template:Coord/display/inline,title-sandbox weren't exactly successful. -- User:Docu

This version looks ok at Template talk:Coord (top corner) and Talk:Lakehurst Mall (with same infobox as Lakehurst Mall). -- User:Docu

On that infobox specifically you would need to set the size to ~95%. If all the infoboxes used 90% as the base font size then you could do the following:

/* Add to Monobook.css */
.infobox #coordinates {
    font-size: 94.35%; <!-- .85 * 1/.90 -->
}

However, they come in all sorts of font-sizes so the possiblity best solution is to hard code a pixel value instead or increase the offset. — Dispenser 07:23, 21 October 2008 (UTC)

The font-size:small tag in [6] seems more reliable. Shall we try this? Compared to the current version, it's an improvement. -- User:Docu

position

Who chose the ranking of the different service-providers? btw. please add openstreetmap, non-javascript version also, thanks.