Template talk:Infobox Protected area
From Wikipedia, the free encyclopedia
[edit] Text of row descriptions
What do you think of Established: rather than Date Established:? Right now it is the longest item on the left side. In a few tests (see Gloria Dei (Old Swedes') Church National Historic Site) because it is long (and depending on the input to the right) it often breaks into two lines (at least on my interface), yet the date is probably always a single line, making the table slightly taller. Elimiating "Date" would keep it a single line in all instances. — Eoghanacht talk 17:07, 31 October 2005 (UTC)
[edit] Map with grid
To help with getting the dot in the right place, an enlarged map with a grid of pixel "coordinates" (eg. x:0-187, y:0-288) would be a good reference. - Diceman 11:14, 1 November 2005 (UTC)
- I built a template utility which is hopefully general enough to be usable with any locator map, but fairly simple to use. Feedback is welcome. Thanks, —Papayoung ☯ 21:40, 2 November 2005 (UTC)
[edit] Proposal to change Template:Infobox protected area
Hi. I was wondering what others think about my idea to change Template:Infobox protected area to looking something like this:
- The template below is a test. Do not use it in articles. It uses deprecated Wikipedia:hiddenStructure CSS hack.
Crater Lake National Park | |
IUCN Category II (National Park) | |
Location: | Oregon, USA |
Nearest City: | Eugene, Oregon |
Coordinates: | |
Area: | 183,224 acres (741.48 km²) |
Established: | May 22, 1902 |
Visitation: | 451,322 (in 2003) |
Governing Body: | National Park Service |
I think this sort of makes a compromise between the templates that are used on all the national parks pages (such as Yosemite) and I think it looks better than what we have right now:
Crater Lake National Park | |
---|---|
IUCN Category II (National Park) | |
Location | Oregon, USA |
Nearest city | Eugene, Oregon |
Coordinates | |
Area | 183,224 acres (741.48 km²) |
Established | May 22, 1902 |
Visitors | 451,322 (in 2003) |
Governing body | National Park Service |
Just wondering what others think. --Hottentot
- Although I would personally like a bolder header than the one now, the proposed one is too bold -- however, if there is a wikipedia-wide standard for the format of an infobox header, I vote we should go with that (and I think the current one does). I am against the extra horizontal spaced between the fields because it makes the box that much taller, and makes placing more images in the article problematic (you have to move them to the left, and the text gets squeezed between the box and the picture). As for input, units are up to the user's discretion, but I would not show an example with both hectares and km² (why does the metric system bother with hectares if no one likes using them?) — Eoghanacht talk 14:49, 7 November 2005 (UTC)
-
- I object to these changes, because they all move in the direction of making the Infobox bigger and visually stronger. I believe that an article's text should be its most important content, and that Infoboxes are often not only unnecessary but that they actually distract and confuse. In the current template design we have eliminated as many extra lines and borders as possible and reduced the font sizes, so that it complements rather than competes with the article body text. And this is already a compromise; I would go even further, myself, but the members of this WikiProject have a lot of time and effort invested in their work, and I respect that. —Papayoung ☯ 18:16, 8 November 2005 (UTC)
-
- I previously preferred the 280px width for infoboxes but the map doesn't look as good and the 288px width is fine. I think anything more than what has been done recently makes the infobox too dominant. I like what we have now...I think is a huge improvement over what was standard just a month ago.--MONGO 02:39, 9 November 2005 (UTC)
-
-
- User Eoghanacht said
- I would not show an example with both hectares and km² (why does the metric system bother with hectares if no one likes using them?).
- The answer is that the metric system does not bother with hectares. The hectare is a legacy unit used in some domains, just like quintal and dunam. The official status of the hectare is "use is not encouraged" (that phrase can be seen at: http://www.bipm.org/en/si/si_brochure/chapter4/4-1.html). A basic principle of the system is coherence i.e. the parts fit together (despite the popular misconception, base 10 is not a basic principle). Thus length, area and volume are made coherent by the use of the single unit metre, the single set of prefixes, single set of symbols, and the use of powers. That is why km² is in the system but hectare etc. are not. Hope that helps. Bobblewik 11:39, 9 November 2005 (UTC)
- Thanks for the note. And I thought the Imperial system had problems. I guess the liter is out too then. I presume the use of "741 km²" is okay rather than "7.41×108 m²"? But seriously, I have been using hectares only because that is what is used in the IUCN database. — Eoghanacht talk 14:08, 9 November 2005 (UTC)
- User Eoghanacht said
-
-
-
-
-
- Correct, the liter is out too, as you say. But it is regarded as a more acceptable non-SI unit. It is therefore listed in table 6 instead of table 8 (see both tables in the link I gave before). Your presumption is correct too, the formats 741 km² and 7.41×108 m² are both valid, you are not forced to use the latter. Bobblewik 18:46, 9 November 2005 (UTC)
-
-
-
-
-
-
-
-
- If you see Hectare, it is used in mainly agrigulture (I imagine in spoken laguage it's easier to say "hectare" than "square kilometres"). Km² is an easier unit to imagine for people not familiar with Hectares. For reference's sake Acre is still in use in the real-state industry although only for large properties, "squares" (which I assume means square metres) for regular sized allotments. Litre is in no way being phased out. - Diceman 14:41, 10 November 2005 (UTC)
-
-
-
-
FYI, I changed the sample boxes to eliminate the hectare. — Eoghanacht talk 15:21, 10 November 2005 (UTC)
- Please feel free to use hectares. Removing any mention of hectares despite opposition is another quixotic quest of Bobblewik - who was recently temp-banned for mass changing to remove date linking despite having no consensus. Hectares are widely used in protected areas description even by international bodies. Since the early days of this project it has used hectares and sq. miles in the box and sq. km and sq. miles in the text. I will continue to revert Bobblewik's changes - as I have informed him. However, I work in many areas of Wikipedia - instead of spending all my time constabntly fiddling with units and always fall behind on this. Rmhermen 17:08, 11 February 2006 (UTC)
[edit] Text wrapping problem with embedded coor template
On some of my articles, when the lat/long gets too long, it wraps to another line (at least as I see it on my IE browser). What bothers me is that this happens even when there seems to be plenty of white space between the right and left sides of the infobox. For example: Scotts Bluff National Monument, on my screen, puts the "W" on a new line, even though there is a gap of about 25% of the infobox width to spare. I wonder if this has anything to do with the little "arrow pointing out of a box" symbol that the system uses to denote an external link? I attempted to fix the problem by adding a nonbreaking space ( ) immediately after the coor template, but no dice. Does anyone else see this problem? And, if so, can anyone think of a solution? — Eoghanacht talk 14:09, 10 November 2005 (UTC)
[edit] Additional fields
Could I put in a request for a plain old "coordinates" field that can make use of eg. {{coor dms|35|00|47|S|138|39|21|E|}} as the majority of the Australian pages have this template on them, and for an "official site" field. - Diceman 15:55, 10 November 2005 (UTC)
- My programming skills are not very good, but when I attempted to embed the coor template into another template, it did not work. I presume this is why Papayoung set it up the way he did. As for the official site field, I have no big objection to it, and considered proposing it in last month's round of discussions. However, I decided not to because I figured there would usually be other links (so it would not eliminate the need for a "External links" section in the article) and Wikipedia users are already conditioned to look at the bottom for websites anyway. If others think it is important to add it, then does anyone know what the standard wiki-infobox format is for website links? — Eoghanacht talk 16:07, 10 November 2005 (UTC)
- All that is needed is an empty field really, I put the above template into the "location" field for comparison's sake and it displayed with no problems. The name might need to be "co-ordinates" to avoid a clash.- Diceman 17:42, 10 November 2005 (UTC)
- One other thought: although it may be easier to cut-n-paste the coor template when migrating existing tables over to the infobox, I think it would be easier to input in the current format for brand-spanking-new articles. Also, I have migrated a few of these, and it is very easy to move the data from the coor template into the infobox fields. Out of curiousity, how many articles are involved in terms of your interest areas? I checked, and there are about 30-40 already using the new template. — Eoghanacht talk 18:40, 10 November 2005 (UTC)
- We're talking 536 articles although I have not personally checked all of the WA, NSW and QLD parks to see if every last one uses the template (I'm 95% sure they do). I'm only inclined to do the SA, Vic, Tas and NT parks (90 articles) and will have to recruit people from the other states to work on their parks. There might not be many new articles as G from B basically added an "information sheet" for almost every national park in Australia, many of them that only 4WD/camping enthusiasts will have heard of (which is why most of them are stubs). - Diceman 14:01, 11 November 2005 (UTC)
-
-
- You know what they say, if you want a job done, do it yourself. - Diceman 15:16, 14 November 2005 (UTC)
-
Could I put in a request for a "Contact" field that could contain phone numbers, email address, postal address etc, for the governing body? Tongariro National Park has got this (I think useful) information in an info box, and it would be good if the Tongariro National Park article could use this template without discarding information. If there are no objections before the new year I'll do it myself. Alastairgbrown 02:47, 16 December 2005 (UTC)
- It seems to me that posting and keeping the contact information up to date is the job of the webmaster of the protected area's official website -- I think it would be a maintenance problem in the infobox. I am slightly against having the website address in the infobox, mostly because the link to the official website should always be prominent at the top of the "External links" section, and it would be repetative in the infobox. (Although much of the other info in the box tends also repeated in the article, it is usually stuff that is in the body of the text somewhere.) If others think a weblink at the bottom of the infobox is important, I won't lose any sleep over it. — Eoghanacht talk 14:27, 16 December 2005 (UTC)
[edit] Multiple locations for the same protected area
Currently, the template only allows location information to be entered for one set of geographic coordinates/descriptions. While this is sufficient for most protected areas, there are some areas where it's necessary to enter in two (or more) sets of coordinates/descriptions. For example, the Nebraska National Forest is comprised of two districts that are over 150 miles apart from each other. It'd be nice to be able to create two dots, two sets of coordinates, and list the closest city for each. –Swid 21:07, 22 November 2005 (UTC)
- The simple fix is to create a one-off place-specific location map, and not use the locator dot function at all (just leave those numbers blank). I am going to have to do this for Blue Ridge Parkway when I eventually update to the new format -- adding a red swerving line to the new U.S. location map in order to show the location of the road. — Eoghanacht talk 21:47, 22 November 2005 (UTC)
[edit] Off-Wiki Database
For the purposes of comparison, I've created an off-wiki database ([1]) that contains template data for all en:wikipedia articles that describe a IUCN Protected Area. The reasons for doing this are:
- It can be used to compare values of attributes. Sorting on area tells me that Tassili n'Ajjer is the largest land-based IUCN Protected Area.
- It can be used to compare values of attributes, within a group. Grouping on Governing Body, sorting on Established and opening Department of Conservation will tell me that the oldest National Park in New Zealand is Tongariro National Park.
- It can be used to tell me which articles might benefit from having this template added.
- It can tell me inconsistencies is usage, for example Grouping on Governing Body tells me that the (U.S.) National Park Service is referenced to in two different ways - National Park Service and U.S. National Park Service. There are similar inconsistencies in the Bureau of Land Management, and U.S. Forest Service.
What I would like to know from interested wikipedians is:
- Is this useful?
- Is this database too bot-like, and in violation of the hand-crafted nature of wikipedia?
- If it is useful, would databases for for other templates be useful as well?
Alastairgbrown 09:15, 17 February 2006 (UTC)
[edit] Appropriateness for urban monuments?
I have to say, though this is a helpful template generally, it doesn't make so much sense for these giant national maps to illustrate a monument that happens to be in the center of a major city.--Pharos 03:55, 15 June 2006 (UTC)
- The map tells you very quickly: A) it is a place, B) what country it is in (and by inference who is proctecting the area), and C) roughly where in the country it is located. The lat/long provides a link to aerial photos and maps showing location (depending on the map) within a hundred feet or so.
- Which makes a lot of sense if you want to identify some tract of land out in the wilderness. But IMO it's really overkill to have a national map and the precise latitude and longitude for Grant's Tomb, which is just a building on the island of Manhattan.--Pharos 09:36, 16 June 2006 (UTC)
[edit] Usefulness for State Parks
Would this template be useful for a state park. I had some guy whining about the template I made for the Indiana State Parks displacing some beloved pic of his. (For the template I made for the Indiana State Parks, see Ouabache State Park. The top right template, not the one on the bottom.)--Bedford 04:32, 6 September 2006 (UTC)
- I started using this Template for North Carolina State Parks Zanter 17:32, 7 February 2007 (UTC)
[edit] The map..
I really want to love this template... It's attractive, it's informative... but it looks absolutely foolish on articles which are illustrated. I've seen this problem 'solved' in a number of ways, all of which are weak. For examples see Lincoln Memorial and Statue of Liberty... or the default impact on Wolf_Trap_National_Park_for_the_Performing_Arts.
The map is informative. But it's not so informative that it should offset a picture provided on an article. Even with the rearrangement we see on my first two examples it still causes the into of the article to become picture heavy and cluttered overall. I'm not sure how best to solve this. .. I am getting tempted to start moving the box to the bottom of the article, to the right of the external links section on articles which are illustrated and above stub length, but I'm sure that would offend all the folks here who have worked so hard on it.
Thoughts? --Gmaxwell 23:27, 17 September 2006 (UTC)
- Nothing should be written in stone on wiki for sure. There are several problems, however with this proposal. Firstly, many articles that this template is transcluded to simply have no decent images available that depict the site. This may not be true for National parks and other areas of high interest, for which there are plenty of free use images available, but for forests, wildernesses, national wildlife refuges and other areas of lesser interest, there simply are not any images available. Secondly, we have several maps that can be used in this infobox besides the U.S. There is one also for Canada (Banff National Park), India and South Africa. I personally had hoped that others would develop maps for other countries as well, but this has yet to happen. Thirdly, for places that are very specific, argument as to what image best describes the park or unit have happened in the past, so the map eliminated that issue. For the Statue of Liberty, or Fort McHenry as examples, any image of the specific item that is protected will do. But for places like Yellowstone National Park, what is best...is it the geysers, the canyon, a waterfall, even a bison perhaps. Fourth, people around the world have little understanding of geography. Heck, many of those in the U.S. have no idea which state is which without the state being labelled, but at least the map allows some introduction as to where the park or site is. The infobox also has the basic overview of information such as the coordinates, etc, which for shorter articles makes it easy to get a quick take of where, how big and when. Lastly, for the sake of the project itself, it's best to keep things uniform, which in my opinion, provides a standard of expectation whenever someone comes along and reads about a protected area. I usually try to have one decent image either right under or slightly to the left and down on each article anyway...I suppose depending on the browser setting, this may be crowded on some pages, but when I view it (1024X768) I see introduction, the infobox at right and an image at left and below, before I need to scroll down to read more text.--MONGO 04:34, 18 September 2006 (UTC)
- I've looked at the practice elsewhere on Wikipedia. My impression is that the editors think that the infobox data should be given prominence regardless of appearance. In no case (that I found) did the editors put the infobox to the right of the external links section. For example, see Hayward, California and Seattle, Washington. The Hayward layout does not appeal to me at all. The Seattle layout is even more cluttered than the example cited above. Ponderosa Pine, provides an example of both a picture and map in the taxobox. More common, in plant articles, is a picture with no map. Eventually, one might expect that most articles will have both a picture and map in the taxobox. Perhaps that will happen eventually for protected areas, but I agree that suitable pictures do not exist for many protected areas currently. Best wishes, Walter Siegmund (talk) 17:38, 18 September 2006 (UTC)
- I've done quite a bit of work adding the infobox to U.S. National Park System articles and have had the same thought as Gmaxwell on several occasions. On one hand, the infobox contains some very valuable information and I think it would be nice to have all protected area articles have the infobox at the top of the article for the sake of uniformity. However, in the articles where there are several nice pictures present, such as in the aforementioned Wolf Trap National Park for the Performing Arts, it does seem like it would be more visually impressive to have one of those photos at the top of the page. I've done a little experimenting with having a photo take the place of the locator map, see War in the Pacific National Historical Park for example, and while the result looks quite nice, as MONGO said, the map really helps place the park in a geographical context. I wonder if there is anyway if the infobox could be altered to allow two images to be placed within the infobox. Then the locator map could be placed adjacent to a picture (where available) of the area in question. What are everyone's thoughts on this idea? Part of me thinks this might be worth trying while another part thinks that having two images in the box would just look stupid. --Nebular110 06:47, 19 September 2006 (UTC)
- My biggest concern over having both the loc map and an image would be for further crowding. I guess I'm just one of those that likes to see the quick links right there as one begins the article and I like it on all articles since it helps to standardize them.--MONGO 11:39, 21 September 2006 (UTC)
- Please see Ponderosa Pine for an idea of how placing both an image and a map in the infobox would look. I think the result is a rather big block, but it wouldn't be so bad with the protected areas map and a landscape image. Walter Siegmund (talk) 15:26, 21 September 2006 (UTC)
- Yes, that is a rather big block although the locator map in question here is not nearly as large as either of those images. However, I am concerned about how this would look on some of the stub articles where there are only a few lines of text, probably not real good. When used in the longer, more developed articles, it seems like it would look nice. --Nebular110 16:25, 21 September 2006 (UTC)
- I've done quite a bit of work adding the infobox to U.S. National Park System articles and have had the same thought as Gmaxwell on several occasions. On one hand, the infobox contains some very valuable information and I think it would be nice to have all protected area articles have the infobox at the top of the article for the sake of uniformity. However, in the articles where there are several nice pictures present, such as in the aforementioned Wolf Trap National Park for the Performing Arts, it does seem like it would be more visually impressive to have one of those photos at the top of the page. I've done a little experimenting with having a photo take the place of the locator map, see War in the Pacific National Historical Park for example, and while the result looks quite nice, as MONGO said, the map really helps place the park in a geographical context. I wonder if there is anyway if the infobox could be altered to allow two images to be placed within the infobox. Then the locator map could be placed adjacent to a picture (where available) of the area in question. What are everyone's thoughts on this idea? Part of me thinks this might be worth trying while another part thinks that having two images in the box would just look stupid. --Nebular110 06:47, 19 September 2006 (UTC)
- I've looked at the practice elsewhere on Wikipedia. My impression is that the editors think that the infobox data should be given prominence regardless of appearance. In no case (that I found) did the editors put the infobox to the right of the external links section. For example, see Hayward, California and Seattle, Washington. The Hayward layout does not appeal to me at all. The Seattle layout is even more cluttered than the example cited above. Ponderosa Pine, provides an example of both a picture and map in the taxobox. More common, in plant articles, is a picture with no map. Eventually, one might expect that most articles will have both a picture and map in the taxobox. Perhaps that will happen eventually for protected areas, but I agree that suitable pictures do not exist for many protected areas currently. Best wishes, Walter Siegmund (talk) 17:38, 18 September 2006 (UTC)
[edit] Scale Factor
There needs to be a way to pass the map scale to the coor function. Not all parks are the size of Algonquin. The parameter needs to be optional and if not specified the current 1:300,000 should be used to keep from altering present usage. --J Clear 00:48, 2 November 2006 (UTC)
[edit] Problem seeing images in infoboxes
I know this isn't quite the kind of message one usually posts on a talk page but I asked this at the Help Desk almost a week ago and never received any answers. I am experiencing a bit of a problem with the locator maps in the Protected area infobox. Whenever I view a page that contains the infobox in Mozilla Firefox (v 2.0 and my primary browser), the locator map does not appear, instead there is just a thick gray line. I know the maps are still there, the red locator dot still appears (over the text of the infobox) and I can view the maps just fine when I access the page using Internet Explorer. I've never had this problem before, it surfaced about ten days ago. Does anyone have any insights on what might be the cause of this issue? Thanks, --Nebular110 17:11, 12 December 2006 (UTC)
- I had a problem seeing galleries until I did a complete system recovery a week ago. You might want to try at the Wikipedia:Village pump (technical) and see if anyone there can assist you.--MONGO 06:00, 16 December 2006 (UTC)
- I've been having problems with infobox for a couple of days on all the machines I have used. I have been using Firefox 2 and the infobox doesn't show up on the right side, but shows up just before the main text. It works fine in IE - is this something that's being worked on? Thanks
[edit] Change "Nearest city" to "Nearest community"?
Protected areas can be close to towns, villages OR cities. I propose that the word "city" should be changed to "community". Alan Liefting 04:09, 16 December 2006 (UTC)
- Let's leave it at city...the nearest point doesn't have to be a city per se, and in many articles, even small hamlets are used as a reference point. There was argument on one protected area page in which two cities almost equidistant from the resource were disputed as to which one should be cited as the nearest and I think there they decided to abandon the city idea and use the closest town. Community is not very descriptive I think...but none of this is either here or there and I'm not dead set on City as the best word to use.--MONGO 05:57, 16 December 2006 (UTC)
[edit] Locator dot is invisible
For some reason I can't see the locator dot on the map (although when I mouse over the location it does point to Image:Locator_Dot.svg). I have tried Firefox and IE, and both have this problem. --Schzmo 02:37, 6 April 2007 (UTC)
- Just checked several articles, and I have no problems...maybe a rendering issue...try clearing out your cookies.--MONGO 07:01, 6 April 2007 (UTC)
- Yes, seems to be working now...thank you. --Schzmo 22:45, 7 April 2007 (UTC)
[edit] This template should have a photo at the top
Hi folks, I think that this template would be vastly improved by including a photo at the top, above the map. This would mean adding optional fields for "photo" and "photo_caption". These would be located between the current "iucn_category" and "image" fields, so that the photo would appear above the map.
The reason is simple: the map is very bland, not pretty at all, and that is the very first thing that any reader's eye is drawn to. It would be so much nicer if, e.g., the Yosemite or Mount Rainier National Park articles began with a scenic photo instead of that map. Many editors have resorted to cramming a scenic photo into the upper left corner of various national park articles to overcome the current template's limitations, but that is not a good solution because it fouls up the lead paragraph, and may violate WP:MOS too.
I think this change will be a major improvement, and it would certainly cause no harm since the optional photo / photo_caption fields would not be displayed if absent. What do others think about this idea? --Seattle Skier (talk) 06:08, 3 May 2007 (UTC)
- That's fine. Probably above the map.--MONGO 06:52, 3 May 2007 (UTC)
- Just be careful...I have no idea how to edit this template...it is transcluded to over 2,000 articles.--MONGO 06:54, 3 May 2007 (UTC)
-
- OK. I'll edit a copy of the template in my userspace or the template sandbox to make sure it's working and bug free before editing the real thing. I've done lots of template editing including some with complicated parser functions, and I haven't broken anything yet, so I think it should be OK. --Seattle Skier (talk) 08:19, 7 May 2007 (UTC)
- Try several different options...and put them no include here if you don't mind...maybe image at top, map at bottom or one on top the other?--MONGO 14:11, 7 May 2007 (UTC)
- I'll second the idea -- a lot of the wilderness areas really need photos in the infobox. If I can make a suggestion: put the locator map first, then the metadata, then the photo. Otherwise, you'll have 2 figures next to each other, and it may look odd. Thanks! hike395 05:09, 8 May 2007 (UTC)
- Or... you can put the photo on top, then the metadata, then the locator map. This is the way {{Geobox Mountain Range}} does it. I don't know if editors will freak out if the locator map suddenly jumps down to the bottom on all 2000+ pages. Personally, I would prefer this, but I can imagine objections. hike395 05:11, 8 May 2007 (UTC)
- Try several different options...and put them no include here if you don't mind...maybe image at top, map at bottom or one on top the other?--MONGO 14:11, 7 May 2007 (UTC)
- OK. I'll edit a copy of the template in my userspace or the template sandbox to make sure it's working and bug free before editing the real thing. I've done lots of template editing including some with complicated parser functions, and I haven't broken anything yet, so I think it should be OK. --Seattle Skier (talk) 08:19, 7 May 2007 (UTC)
I think the only problem from having a loaded infobox will be the need to create space between the area where the infobox and introduction is and the first section after that if the introduction wording is too short, otherwise we'll run into cramping since a lot of articles have a picture in the very first section after the intro/infobox section..see Yellowstone National Park, where an extra picture will work out fine.--MONGO 05:24, 8 May 2007 (UTC)
- Here's a compromise ideea: replace "|float_caption = {{{name}}}" with "|float_caption = {{{PAGENAME}}}", and then an image could be added in the name field (otherwise it screws up the locator dot caption). It would not interfere with previous implementations. --Qyd 20:33, 20 July 2007 (UTC) (Correction: the pog is screwed only when an image contained in the name field contains a wikilink in the caption, otherwise, it works as it is now --Qyd 18:43, 21 July 2007 (UTC))
[edit] Parameter added to accomodate World Heritage Sites
I think adding the parameter to all parks, etc. that have been designated World Heritage Sites is a decent idea...as far as I am concerned, ths is the best way to eliminate the addition of the template that is currently on a number of articles that details just this issue. So I updated the template and the useage section so it should be easy to copy and paste this info into the appropriate articles. The pararmeter to copy and paste is below..add it right after Governing body or it won't work right. Maybe further refinements are possible as well.
|world_heritage_site =
Thanks.--MONGO 04:19, 24 May 2007 (UTC)
I already added the new parameter manually to the Yosemite National Park article.--MONGO 04:23, 24 May 2007 (UTC)
[edit] Additional optional fields; sea area and land area
Is it possible to add two more optional fields, land area and sea area? This is known data at least for a number of Norwegian national parks, see for example Forlandet National Park (which I would like to change into using this template). --Berland 16:00, 14 September 2007 (UTC)
[edit] Request to automatically place the dot
Locator maps have the capability to place the dot automatically based on longitude/latitude. If somebody has gone to all the trouble to enter the coordinates in the format, it would be nice if it carried through rather than having to also manually enter the X and Y. That all said, i like standardizing the protected area. Americasroof (talk) 02:53, 22 November 2007 (UTC)
[edit] display=inline,title in coord template
In order to ensure Google Earth is able to pick up the articles' coordinates, display=inline,title should be used, see Template:Coord, compared to display=inline which is used for now in the template. Would anyone object to this? --Berland (talk) 21:27, 11 December 2007 (UTC)
-
- That causes duplicate coordinate displays— one in the box and one at the top right of the article. See Arches National Park for an example. --— Gadget850 (Ed) talk - 12:28, 5 February 2008 (UTC)
-
-
-
- Yes, having the coordinates duplicated within three inches is redundant. Some articles already had coordinates in the External links section as well— that now shows two sets of coordinates superimposed in the title. Ah, cleanup... --— Gadget850 (Ed) talk - 16:47, 5 February 2008 (UTC)
-
-
- I changed back to inline only before reding the discussion, I appologise for that. The reason was not redundancy, but collision of cordinates in the title area, there are many pages that use a separate coord statement or coor title (ex: Lois Hole Centennial Provincial Park, it also collides with geolinks templates. --Qyd (talk) 17:30, 5 February 2008 (UTC)
- I absolutely think those articles with the separate coord statement in addition to the infobox must be fixed. Redundancy in source code must be avoided, redundancy in display is not that important (I prefer Google Earth inclusion over avoiding display redundancy). --Berland (talk) 21:49, 5 February 2008 (UTC)
-
-
- Why doesn't inline work with Google Earth? --— Gadget850 (Ed) talk - 22:01, 5 February 2008 (UTC)
- And the answers are at Template talk:Coord and About the Google Earth Geographic Web Layer. --— Gadget850 (Ed) talk - 22:12, 5 February 2008 (UTC)
- Why doesn't inline work with Google Earth? --— Gadget850 (Ed) talk - 22:01, 5 February 2008 (UTC)
-
I would still prefer this template to use display=title,inline, but Qyd reverted my change, so I am reluctant to reverting Qyd myself. Is there any consensus here? --Berland (talk) 11:12, 16 February 2008 (UTC)
- I wouldn't mind to have the template render inline and title, but in that case, all pages that have dual coord statements woudld have to be cleaned up before implementing the change. Can a smart robot be set up for the task? --Qyd (talk) 13:58, 16 February 2008 (UTC)
- A compromise (and easy) solution would be to have a parameter that adds the title display (by using for example title=yes), by replacing
-->|display=inline|}}
with
-->|display=inline{{#ifeq:{{{title|}}}|yes|,title|}}|}}
or with
-->|display=inline{{#ifeq:{{{title|}}}|no||,title}}|}}
The editors would than be able to control the rendering. Alternately (second example), the switch could be used to inhibit the title display in particular cases (useful if consensus is built towards enabling the title display by default). --Qyd (talk) 14:24, 16 February 2008 (UTC)
[edit] Need the name parameter in coord
I recently added the name={{{name}}} parameter to the coord template and had it reverted. Out of curiousity, if you're just going to revert every change, then why not protect the page?
Anyhow, the reason is that the name provided there will escape the spaces properly. For example, if you go to Mount Rushmore right now and select the coordinate you'll see that Title shows Mount_Rushmore. If you then try to use a mapping service that uses the name (like MapQuest... when it's working, and Live Maps), the underscore breaks things. With the fix in there, the title will show Mount Rushmore, and everything will work fine. I guess I'll check back and see if people feel better about the change after this explanation. Heptazane (talk) 00:04, 8 March 2008 (UTC)
-
- That is because the name field in the example includes the image. When the name field is reused in the coordinates, so is the image. The top image should be a separate parameter. --— Gadget850 (Ed) talk - 23:05, 13 March 2008 (UTC)
- the "name" part is not necessary. the geo microformat is wrapped in a vcard class (the top class of the infobox), which already defines the name ("fn" class definition of the "name" element), and that is inherited automatically by the geo microformat contained in coord. Furthermore, if adding a name to coord, fn would be defined twice, which is prohibited by the microformat, and would create an error (fn is required and mus be unique, "MUST be present exactly once"). Yes, an image added to the "name" field would break that name (as parsed through the microformat), but only if that image contains a caption, otherwise it's fine. --Qyd (talk) 23:47, 13 March 2008 (UTC)
- Did some more testing, turns out you Heptazane is right, the name is not present when you click the coordinates link that takes you to the geo-hack age (unless it's defined again in the coord template). It is, however, present in the geo microformat generated by the page as a whole. Question remains if a duplicate fn definitions breaks the entire microformat (according to the standard, it would, but it might work still if the statements are identical (both times "fn" is defined by the same parameter, the "name" field).--Qyd (talk) 00:18, 14 March 2008 (UTC)
- Okay, so it's incorrect to have the photo in the name, and the name is required as I've been saying, so are you guys satisfied, or if I make the change again will it just get reverted? Heptazane (talk) 23:21, 14 March 2008 (UTC)
- You are unaware of that your change causes problems on the numerous pages that use the template with image and map. If you think is incorrect the present way of including two images in the infobox, then you would propose an alternative way to solve this issue and fix it before making any another change. Jespinos (talk) 15:42, 15 March 2008 (UTC)
- Okay, so it's incorrect to have the photo in the name, and the name is required as I've been saying, so are you guys satisfied, or if I make the change again will it just get reverted? Heptazane (talk) 23:21, 14 March 2008 (UTC)
- Did some more testing, turns out you Heptazane is right, the name is not present when you click the coordinates link that takes you to the geo-hack age (unless it's defined again in the coord template). It is, however, present in the geo microformat generated by the page as a whole. Question remains if a duplicate fn definitions breaks the entire microformat (according to the standard, it would, but it might work still if the statements are identical (both times "fn" is defined by the same parameter, the "name" field).--Qyd (talk) 00:18, 14 March 2008 (UTC)
-
-
-
- I did some more testing, and found no evidence of errors in the microformat if the name is defined in the coord statement. Images in the name field, however, break the template if name is defined in coord. If another picture field is defined and implemented (allowing for both map and picture), the change could be made, otherwise, I would not go ahead with it. --Qyd (talk) 16:02, 15 March 2008 (UTC)
- I propose that images not be put in the name field because then it isn't really a "name" field, it's a "name+image" field. Not having it means that all protected areas with a space in the name will cause a poor experience when using the coordinates. My vote is for fixing the name field. Heptazane (talk) 22:21, 15 March 2008 (UTC)
- I did some more testing, and found no evidence of errors in the microformat if the name is defined in the coord statement. Images in the name field, however, break the template if name is defined in coord. If another picture field is defined and implemented (allowing for both map and picture), the change could be made, otherwise, I would not go ahead with it. --Qyd (talk) 16:02, 15 March 2008 (UTC)
-
-
[edit] Sandbox
I created the sandbox and testcases pages. Please use these to test changes and gain consensus before making live changes. --— Gadget850 (Ed) talk - 02:30, 8 March 2008 (UTC)
- Links?--MONGO 17:24, 11 March 2008 (UTC)
-
- At the top of the documentation section. This is one of the neat things about using the {{Documentation}} system— as soon as you create the sandbox and testcases subpages, it automatically adds the links to the doc page. --— Gadget850 (Ed) talk - 17:30, 11 March 2008 (UTC)
- Gotcha...thanks.--MONGO 09:00, 13 March 2008 (UTC)
- At the top of the documentation section. This is one of the neat things about using the {{Documentation}} system— as soon as you create the sandbox and testcases subpages, it automatically adds the links to the doc page. --— Gadget850 (Ed) talk - 17:30, 11 March 2008 (UTC)
[edit] Modifying zoom level for coord
Can someone who is savvy please add a field for modifying the zoom level of the co-ordinates? This is done with "type:____" in the coord template. I think this would be useful to the varying sizes of parks; for example, look at the difference between the title and inline coords I used at Westmeath Provincial Park. --Padraic 18:23, 1 May 2008 (UTC)
[edit] Change
Sorry if i mess up the page history, but I made some changes that incorporate the world heritage template. Hopefully, it can solve the problem. —Chris! ct 21:24, 3 May 2008 (UTC)