Template talk:Geobox

From Wikipedia, the free encyclopedia

Geobox is of interest to WikiProject Geographical coordinates, which encourages the use of geographical coordinates in Wikipedia. If you would like to participate, visit the project page.

[edit] Issues

[edit] Geobox hidden errors

There are an uneven number of "{" (12527) vs "}" (12531). The template is exceedingly complex with few comments, making it quite difficult to figure out what is going on. However, I believe it is resulting in a possible open {{#if: statement somewhere in the middle. Aflin (talk) 01:42, 10 May 2008 (UTC)

[edit] Geobox font size

The Geobox template sets the font size for the table as 90% of the global font size, it's a setting used in most other Infoboxes. The problem is that every browser displays a different final font size.

• Opera up to 9.23: 10px; (it displays all Wikipedia UI, navigation etc., in this font size)
• Firefox, Safari & Opera 9.5 alpha: 11px;
• IE (probably all versions) ignores this setting completely: 12px; (also on the Wikipedia UI)

And the question is, should any of these be hard-coded? Setting e.g. font-size: 11px; so that the Geoboxes look the same in every browser? If so, which font size?

I've only viewed Wikipedia articles through IE. It uses the font size of 90% (which I would guess is 90% of 12px, but I couldn't find the 12px hard-coded anywhere). On IE, the geobox text displays slightly larger than the county navbox text, and slightly smaller than the article text. If you wanted to hard-code a font size for the geobox, I think 11px is a reasonable option. I think the relative sizes of the body text, geobox text, and navbox text are good for now and I would try to keep those relative sizes the same. If you make a change, let me know and I'll comment. Skeetidot 23:25, 23 September 2007 (UTC)

Yeah, it calculates 90% of the font of the nearest higher object whose part it is. I don't think Wikipedia's css sets any default font size so it probably takes the one from the browser's settings, which is in most cases 12px. And 90% of 12px is 10.8px, which gives rounded 11px. I only the the Geobox should get displayed in the same way in all browsers. – Caroig (talk) 18:10, 24 September 2007 (UTC)

The font size got smaller again! It's still readable, but definitely smaller than it used to be. Was this intentional? Skeetidot 03:52, 14 October 2007 (UTC)

[edit] Coordinates globe

The display of coordinates is handled by a template which is not a part of the Geoboxes and the globe icon is inserted after the page has loaded by Javascript. I don't like this very much. The line with coordinates is too long, looks odd when the font is smaller (I've put the coordinates below elevation in this series to at least somehow fix the broken layout). And my mainly objection is it put two clickable obejcts on a single entry.

The coordinates link to the Geohack page, which lists many mapping reosurces. There's a newly proposed redesign of the Geohack page, which displays the WikiMiniAtlas at the top (click View using the proposed redesign on any Geohack page) which seems better. The proposal here is to handle the coordinates display by an own sub-template which wouldn't produce the globe icons and which would link the coordinates, for the time being, to the proposed Geohack.

For me, at least as of September 23, the globe icon is not clickable. All it does is offset the alignment of the coordinates. In Geobox 1.0 (which a lot of articles are still using), the coordinates end up being displayed on a separate line entirely (see Point State Park, and I know there are many other examples). If you could modify the geobox code to not have to rely on the Geohack code, that would definitely be beneficial. Skeetidot 23:30, 23 September 2007 (UTC)

The fact it was breaking the coordinates in the most unexpected places (in my browser often after the minus sign when the longitude was a negative number) was the main reason why I put the coordinates in a no-wrap property so they get displayed on a single line now. I'd leave the "globed" coordinates version in the article title though.

As of it not being displayed in your browser, there have recently been some issues with caching images from the Commons, probably solved by now. Clearing your browser's cache might help. – Caroig (talk) 18:03, 24 September 2007 (UTC)

[edit] Blank template style

In Geoboxes 2 the blank templates list all parameters without any whitespace and list multiple fields on a single line to save space. However, some users prefer the longer old style with whitespace. Which one should be preferred. The semi-automated conversion tool also produces the style without whitespace.

I prefer having the whitespace. When I add a geobox, the first thing I do is break all fields onto separate lines and add the necessary whitespace so that all the equals signs are at the same position. I find it easier to read the information if it all starts at the same position (like a table). Skeetidot 23:36, 23 September 2007 (UTC)

Support. I also align the equal signs. --Berland 14:24, 24 September 2007 (UTC)

Fine, the only reason why I removed the whitespaces was there were more fields in this version, thus giving even more lengthy code and I wanted to reduce it somehow. So I removed the whitespaces and put some fields on a single line. Should we also split them again, e.g. having lat_d, lat_m, lat_s, lat_NS on separate lines or on one line line only? How about the additional fields. If someone adds say country_flag, area_unit etc. should these be placed after the base field or on a separate line as well? I agree the table-like formatting is easier to read. I'll adjust the semi-automated tool too after we decide on this (it can reparse even a page which is in the Geobox 2 style).

{{Geobox Settlement
name               = Prague
country            = Czech Republic
…
population_density = auto

{{Geobox|Settlement
name = Prague
country = Czech Republic
…
population_density = auto

[edit] Commons

I've also added the commons field which creates a link to the appropriate category at Wikipedia Commons. See an example at Uluru. There's a template which does that as well but it's usually somewhere at the bottom of the page so most readers do not find it. So why not having a link from the Geobox too? Optional of course. I'm just not sure about the link's location. As of now, it's at the bottom of the Geobox, below the website field. I thought of placing it immediately after the image caption, in brackets. So at the sample page it would read: Uluṟu at sunset (more images at commons).

[edit] Page layout broken by map1_locator field

Could an expert in all this template/css magic look into why the bottom of this page contained a lot of excess empty space until I removed these fields? (In case your browser doesn't have the problem, mine is a Firefox 2.0.0.8.) Thanks, KissL 14:46, 5 November 2007 (UTC)

[edit] Etymology

The etymology value is not displaying in Sangre de Cristo Range. Perhaps the use of a language template in the field is causing a problem? RedWolf (talk) 16:57, 7 December 2007 (UTC)

[edit] References in Geobox

It seems that it is impossible to put references in many parts of a Geobox. Using Template:Infobox Mountain I am able to add references for the height of the mountain within the Infobox (see Mount Ossa). I think Geobox should allow something similar, but its use of templates for height, position, etc causes errors if references are included. --Ozhiker (talk) 13:21, 19 March 2008 (UTC)

References can be added to any field with a second parameter with the suffix "_label" "_note". For example, you mention height, so to provide a height value and a reference, you'd use the following code.

height = 700
height_label height_note = <ref>{{cite|...}}</ref>

Hope that helps. VerruckteDan (talk) 23:03, 19 March 2008 (UTC)

That doesn't seem to work for the elevation parameter of the Mountain Geobox (see example on right which has no reference link):

--Ozhiker (talk) 12:03, 20 March 2008 (UTC)

My mistake, first off I told you the wrong code. You actually use the suffix "_note". However, there still seems to be an issue with it working properly. I'll have to take a more detailed look through the code and see if I can find the problem. Just be warned, I'm not an expert at template coding, so I can't guarantee that I will be able to track down and or fix the issue, but I'll try my best. VerruckteDan (talk) 22:14, 23 March 2008 (UTC)

[edit] Initial Comments

Cool, new geoboxes! My initial thought is that the text is significantly smaller. Any chance you could increase the font size? Also, the map of the state in the US stopped working. Otherwise, it's great to see updates, and nice to know that you took my flag idea into consideration. If you'd like, I can begin incorporating the geoboxes onto the municipalities I've been working on. – Skeetidot 01:18, 3 September 2007 (UTC)

Thanks for such a quick post. The sooner and the more the new Geoboxes are used the quicker we can eliminate any bugs or glitches. – Caroig (talk) 04:31, 3 September 2007 (UTC)

Smaller font: The smaller font is intentional. I've been always getting the smaller font as my primary browser is Opera. This is an attempt to unify the look across all browsers. The think is, most infoboxes that use the same CSS class (infobox geography) define the font-size as 90%. In IE, Firefox and Safari this is somehow ignored, only Opera adjusts the font accordingly. I personally prefer the smaller font, everything fits better in the box. But of course we can put back the larger font back if requested, I'd just wait for more reactions. – Caroig (talk) 04:31, 3 September 2007 (UTC)

I checked the code on the Template:Geobox page and the infobox geography class specifies the font to be 7.5 pt (pretty small). It's smaller than any other infoboxes I've seen. It sounds like Opera displays things differently than the standard browsers (IE, Firefox, and Safari), and I'd recommend looking at the geoboxes on those to see how the two versions compare. Users shouldn't see the info suddenly become smaller, but we can see what other people say.

I wanted the Geoboxes to look the same way across all browsers and as I was used to how they get displayed in Opera (I'd always worked with that font size) I hard-coded (though I understand setting absolute, not relative, font-sizes is not a good practice, but I didn't see other way how to achieve the same font size in every browser) the font size to be 7.5pt which equals 10px font height in most browsers. The trouble seems to be in rounding. Most templates using the css class "infobox geography" and define font-size: 90% which should cause smaller font in the box. Opera seems to be rounding the font size for points (pt) while other browsers for pixels (px), thus giving a bit different results. I do not which is standard compliant though Opera is generally the most standard-compliant browser, while especially Firefox tries to render some feature rather IE-like to make the switch to FF easier for users. Anyway, personally I prefer the smaller font but I prefer smaller fonts generally ;-) I've returned the old setting with font-size: 90%. Setting absolute font-size is not a good practice indeed. – Caroig (talk) 08:01, 3 September 2007 (UTC)

US map not working: I'm not quite sure what you mean by "map of the state in the US stopped working". Could you please point me to a page where this occurs? There's a test page for city: Template talk:Geobox/City which displays everything as the old template does.

For Allegheny County, Pennsylvania, I'd made maps showing each municipality in the county. There were originally black and white maps (see Pine Township for an example) that I've been replacing with color maps as I've been adding the geoboxes (see Aspinwall, Pennsylvania - Braddock Hills, Pennsylvania for these. If you try to convert any of these pages from Geobox 1.0 to Geobox 2.0, the map of PA in relation to the US does not display in the geobox.

Fixed. – Caroig (talk) 08:01, 3 September 2007 (UTC)

Error messages: Another bug I noticed with the Geobox 2.0 version on Template talk:Geobox/City is the error message that comes up at the bottom of the geobox, "Renamed field: replace area_water_percentage with area_water_share, auto doesn't work on this field". I was able to fix that by changing the field area_water_percentage to area_water_share, but I wanted to let you know that anyone wanting to update their geoboxes will need to make this additional change. What was the reasoning behind changing the field name? Could you keep it the same to avoid having to make that update?

The reason was to unify the field names across Geoboxes, while some used _share other had _percentage, I opted for share as it is shorter. There are actually more such changes on some rather rarely used fields, we shouldn't have two or three names for the same parameter. I could add support for both fields (_share other had _percentage) which would act as aliases if you wish so. – Caroig (talk) 08:01, 3 September 2007 (UTC)

Update. I've removed all but one of those error messages. Both new and old field names are now accepted. The remaining field is one which has been completely removed (and probably never used). – Caroig (talk) 21:39, 3 September 2007 (UTC)

Title bar: Finally, when I tried to convert Aspinwall, Pennsylvania's geobox to version 2.0, the dark gray background for the title bar no longer displayed in dark gray.

There was some misunderstanding about the template calls in the Geobox 1.0 series. There was a master settlement template {{Geobox Settlement}} with various aliases such as {{Geobox City}}, {{Geobox Borough}}. I didn't create those aliases but I haven't objected to them either as they did no harm but they were rather obsolete as the category field was set as well. However, the idea was to put the category/type of the settlement to the category field, usually linked to e.g. List of borroughs in Pennsylvania. The first (unnamed) parameter in Geobox 2. only sets the Geobox color, the category should be in category field. The name field should contain just a short name of the location, the long, official name has its separate field official_name. While the the old style can still be used (the Borough parameter wasn't in the list of parameters setting the gray color, it's been added now) I'd suggest calling the new Geobox as {{Geobox|Settlement and setting the appropriate category. While the old geoboxes printed the category only when set, the new ones display it always and if category is not set it uses the first parameter with which the template is called. – Caroig (talk) 08:01, 3 September 2007 (UTC)

I don't mean to sound nitpicky... just trying to help make the new geoboxes as good as possible! – Skeetidot 06:09, 3 September 2007 (UTC)

Not at all, I'm real greatful for any feedback. As of conversion of old Geoboxes into new, this can be better done using AWB, in which such issues as changed field names might be done automatically. – Caroig (talk) 08:01, 3 September 2007 (UTC)

• I have a problem with this new box... I often improve articles in my language WP by adding an infobox and other texts. With the new box it is simply impossible to distinguish by using "what links here" rivers from towns on the first sight but you get a real big mess of articles. Do you have a work-around? CatScan's a bad alternative since sometimes it doesn't work. :( --213.155.231.26 11:34, 2 October 2007 (UTC)

This idea is dealt with further on this talk page. Please, see the discussion or comment there. – Caroig (talk) 20:45, 2 October 2007 (UTC)

[edit] Duplicate display of coordinates in title

Hi, Caroig. Thanks for updating the geobox. This comment applies to both Geobox1 and Geobox2. Take a look at Duck Mountain Provincial Park (Manitoba), which calls Geobox2. Notice the upper right of the article: there are two overlapping "coordinate" links. This is because both Geobox2 and {{Geolinks-Canada-streetscale}} call {{coord}} with display=title ... This is also true of Geobox1.

Would it be possible to add an argument ("notitle") which turns off display=title in the call to {{coord}} within Geobox2? (If you are updating Geobox in any event). Thanks! hike395 17:49, 3 September 2007 (UTC)

What about making a "no-title" version of {{Geolinks-Canada-streetscale}}. The Geolinks-US templates each have a "no-title version, Category:Coordinates templates. VerruckteDan 18:03, 3 September 2007 (UTC)

Good idea! Implemented. There's now an extra argument coordinates_no_title, if it is assigned any value it switches off generating the coordinates in the title by the Geobox. I first named the field as coordinates_title_off but switched to coordinates_no_title so we have similiar field name as Geolinks-US (easier for editors). I've updated the sample article accordingly. – Caroig (talk) 18:09, 3 September 2007 (UTC)

FYI, the Geoboxes accept decimal coordinates as well. You can simply put the decimal numbers to just lat_d and long_d and leave the other coordinates-related fields empty. By adding coordinates_format = dms you can force the Geobox to display the coordinates in the D°M'S" format (if you don't add this field the template will display the coordinates in the format in which they are entered, i.e. as decimals). It's just easier for you, you don't have to manually convert the decimal coodinates for the Geobox. – Caroig (talk) 18:16, 3 September 2007 (UTC)

[edit] Official Name

Caroig, thanks for making the updates to the new geoboxes! I updated the Allegheny County municipality articles (Aleppo - Braddock Hills) to use Geobox 2.0, and even one for Mount Davis (Pennsylvania), to learn about other fields in the new geobox.

You mentioned earlier using the official name in the official_name field and just a shortened name in the title. I have an official name in each municipality geobox I've done so far, but it looks repetitive. Do other people think the official name should stay? I don't mind getting rid of them (especially on the township articles, see Aleppo), but I want to ensure consistency with the settlement geoboxes that will follow. Any thoughts?

Skeetidot 04:52, 4 September 2007 (UTC)

I think the official long name should neither be made the headword of an article nor be the heading of a Geobox. All countries are under their short names on Wikipedia (United Kingdom not the United Kingdom of Great Britain and Northern Ireland), many settlements in Spanish speaking countries have sometimes very lengthy official names which are rarely used (La Nueva Guatemala de la Asunción aka Guatemala City) etc.

The heading of Geoboxes is designed to contain the most common name of the location plus category, a general group to which it belongs. The latter should, for less common categories, link to an appropriate article (not City or Town, but Borough, Township, Parish, any local categories of protected areas etc.). It's indeed useless to repeat the category in the name and have it again bellow in 'category. I see that some mountains have Mount in their names but most don't as well as most other objects the Geoboxes are used for. In Geoboxes 1.0 there was no such field as official_name, it was added for the version 2.0. When creating the first geoboxes it didn't occur to me some users would want to put the official long name in the heading, I even corrected some pages that were used that way but later there were too many so I let it be.

The main reason for splitting the actual name and category is lingustic, foreign users which might not always be able to tell the difference between the general noun in the name (such as Parish or Borough) and the proper name. We've been splitting the name and category for Protected Areas, Regions, Rivers so it would only be consistent to stick to this with any settlements. – Caroig (talk) 19:44, 4 September 2007 (UTC)

I see how splitting the name and category would be useful for areas outside the US! When I initially created the geoboxes for Allegheny County, I just went with standards I'd seen in other American municipalities.

Given the repetition between name/category and official name, would you recommend keeping official name on all of the articles (example: Aleppo)? Also, you mentioned adding a link to borough, parish, etc. I checked for Pennsylvania boroughs and towns have an article, List_of_towns_and_boroughs_in_Pennsylvania, but cities and townships only have categories, Category:Cities_in_Pennsylvania and Category:Townships_in_Pennsylvania. Do you think the category field should link to articles/categories like these?

Oh, just as an FYI, that United Kingdom article displays the official long name (United Kingdom of Great Britain and Northern Ireland) in the first line of the infobox. I still agree that the shortened name looks better, though.

Skeetidot 14:32, 5 September 2007 (UTC)

It's indeed United Kingdom of Great Britain and Northern Ireland. I somehow assumed the Infobox would use that given the short name is used within infoboxes for the country, but I hadn't checked. But it does look strange; the infoboxes, in my view, and I belive that's according to the guidelines should provide a brief overview for quick orientation in the topic not be full of prose.

My idea is to link the category when the term is less common, if it is city, town it of course doesn't need to link to any definitions, but with categories such as borough … I had only a vague idea what it means exactly when I saw it first in the Geoboxes. – Caroig (talk) 21:28, 5 September 2007 (UTC)

And as of keeping the official name in, I guess it should be in only if it has any informative value, if it is often refered to under the long name (such as NYC). If all townships (or whatever) in a state/county are officially named Township SOMETHING I don't think it needs to be in the Geobox. But these are my ideas, I don't think any rules should be set for this issue. – Caroig (talk) 21:37, 5 September 2007 (UTC)

• Skeetidot, please note that since you have switched Mount Davis (Pennsylvania) to use this new Geobox rather than {{Infobox Mountain}}, changes to the article will no longer be actively monitored by the Mountains WikiProject once the mountains watch list is re-generated. This is a current issue with the new Geobox (noted in another section). RedWolf 07:09, 24 September 2007 (UTC)

[edit] More custom labels fewer animals

11-Sep-2007: I recommend reducing the groups of specific labels and using more large groups of totally custom labels as free fields. The structure might become, perhaps 7 custom-groups, with 15 custom-entries in each group, such as listing major lakes (up to 15) finally noting "umpteen hundred smaller lakes" etc. Another use might be, when infoboxing islands, to list shoreline features, such as white sand, black sand, pebble beach, clamshell, with east reef, or "Ship Killer" sub-ridge at northwest. In each case, the custom-groups would be variable (such as "Major lakes" or "Shoreline features"), rather than having so many predefined groups for plants, animals (etc.) that would never be used when the focus is shoreline reefs, harbor depth, and mooring, etc. Does that make sense? -Wikid77 00:24, 11 September 2007 (UTC)

I'm not sure what exactly you mean. Do you suggest ditching all specific fields names from all the Geobox (including e.g. country, area, website etc.) in favor of some generic field names or does your suggestion concern only the section with biome, animal, plant etc.?

If you indeed have the first in mind then I simply don't understand what it would be good for. And as of geology, biome, plant, animal, these are not to be used for every feature of course, but when geoboxing a protected area biome, plant and animal might be used to list the reason for protection, if you're writing about a mountain range then geology, period (Jurassic, Tertiary etc.) are useful. The advantage of the named field is that everyone immediately sees what to fill them with. If you feel you might need some extra feature which could be used for more features we could add it. There's a landmark field which doesn't have any strict type assigned, it can anything of some importance for the topic and it's displayed name can be redefined using landmark_type. And you can redefine other categories as well if the item has something in common with an existing one. If writing about a coral reef, the field animal can well be used to list coral species, they're animals after all, and you can set animal_type = Corals. Nonetheless, if you find an item which doesn't logically fit into any category and it's something that can be used in more Geobox types, there's no problem add it. Most of the fields in the Geobox got into it this way. On the other hand I think only such items which are important for a category in general should be put in Geoboxes not just anything.

All this comes at a price, sure, and that is the template size. Unfortunatelly, the template syntax isn't a programming or scripting language, it has very limited capabilities. I read tour post at Talk:Omø where you criticize that. If I knew of a way how to make the template more effective and less memory consuming … but I don't. So either we have a template which does most of the work for you (conversions, wikilink lookup, location dot placement) and is pretty simple to fill in for someone with no knowledge of the templates (you don't need to explain anyone what to put in country, state, range, area, length, population, website etc.) while offering a lot of extra formatting features (setting rounding precision, redefining diplayed text etc.) and displaying the data in a unified style or a fully customizable, small, very general template where anyone can put any data in whatever format they like. (I don't like what happened with most pages that use {{Infobox Country or territory}}, they're full of chaotically oraganized data, indexes, sources, footnotes …). I'm still looking for ways how to make the code better and faster, so if you have any ideas, they're welcome. – Caroig (talk) 20:01, 11 September 2007 (UTC)

[edit] US Flag

The US flag in Geobox 2.0 is not displaying for me. However, clicking on the area where the flag should be does bring up its image page, where it does display correctly. Is anyone else experiencing this as well?

Skeetidot 22:14, 15 September 2007 (UTC)

Must have been just my PC, it's displaying now. The coordinates globe is not, but that's not a function of the geobox.

Skeetidot 22:44, 15 September 2007 (UTC)

I've just arrived home from a nice trek. I get no globe icon either. It's Wikipedia related, this happens when one of the servers that stores cached images is down. – Caroig (talk) 21:06, 16 September 2007 (UTC)

[edit] Geobox|River State/Province option?

Would it be possible to add province to be used instead of state (for canadian rivers) ? Lotheric 12:49, 21 September 2007 (UTC)

If you use the parameter "state_type = Province" prior to "state = Ontario", the title on the left column will change. VerruckteDan 13:24, 21 September 2007 (UTC)

Thanks, it worked! Lotheric 15:35, 1 October 2007 (UTC)

[edit] Generating lists based on specific type

I was considering generating a list of mountain ranges based on pages that use the {{Geobox Mountain Range}} as is done for {{Infobox Mountain}} to generate Wikipedia:WikiProject Mountains/List of mountains (simply by using "What links here"). The mountains list is used for monitoring changes to mountains for peer review and vandalism. Now with the range specific infobox going away, I would no longer be able to generate such a list in this fashion. RedWolf 16:41, 23 September 2007 (UTC)

I second this --- this is a very useful feature for a WikiProject! hike395 01:55, 24 September 2007 (UTC)

We might add a [[Category:TYPE]] call to the template which would place the article into an appropriate category. This way the list would be always be most actual. Using What links here probably generates a lot of "false" occurencies where the template is just mentioned but not actually used. Would this solution be OK? – Caroig (talk) 13:27, 24 September 2007 (UTC)

• Yea, that also occurred to me after I wrote my original comment. The thing is, we already have an existing category system of mountain ranges, but this have been subdivided according to geographic region in the various subcats. I'll agree that using "What links here" has its problems and does require manual editing afterwards. The {{mountain}} template puts the talk pages into a category so Geobox could do something similar. However, I'm not sure I would like seeing the categories list of an article showing a "maintenance" category as its only use would be for the generation of the watch list. RedWolf 06:51, 26 September 2007 (UTC)

I can think of two ways how to deal with this. Either, as I suggested, we can have the template generate an appropriate category. Given the "popularity" of various maintenance tags that some editors put into many pages (this article needs …, there are no references …) at the very top I don't think a category would be something to object to. They always get displayed at the bottom of the page, among other categories, the categories being a Wikipedia feature used mainly by editors to better organize their work. A big advantage is there would be no false links, it doesn't put any extra load on the servers as the categories are a built-in feature. There also exist many helpfull extensions to adjust the category page looks, such as e.g. {{CategoryTOC}}. In my view, this is the neatest solution.

I can think of a workaround which would enable using "What links here" as well. Instead of generating an appropriate category link the template could call an appropriate template say {{Geobox2 Mountain Range}} or {{Geobox2 Settlement}}, based on the first parameter. These templates would be empty thus they wouldn't make the code any longer. Because these calls would be generated only when the template were used in a page, not just referred to, they wouldn't cause any false links. Anyway, although these templates would be empty, they would exist which means "what links here" could be used for them. I haven't tested this but I don't see any reason why this shouldn't work. It could also be used together with the automatically generated categories. But this solution doesn't seem that neat, it's rather a workaround.

I would prefer the first option, the categories, but neither the second option is that bad, so if that's requested, we can add it to Geobox 2. – Caroig (talk) 20:43, 2 October 2007 (UTC)

[edit] Units of Area

Last week, I converted two PA state park articles (Point State Park and Allegheny Islands State Park) from Geobox 1 to Geobox 2, but they were reverted back to Geobox 1 because Geobox 2 was unable to represent area in acres. I wanted to share this comment I received here with other geobox users to see if someone could fix this:

I reverted Point State Park as the new Geobox said the area type was acres, but gave the area as 36 square miles (and the corresponding square kilometers). I tried a couple of things to fix it, but since the old Geobox worked here and the new one does not, I reverted to the old one. Thanks for switching and feel free to switch back once the problem is fixed, but "acres 36 mi2" makes no sense. Ruhrfisch _><>°^° 01:37, 16 September 2007 (UTC)

I switched Allegheny Islands State Park same thoughts as Ruhrfisch. Dincher 01:44, 16 September 2007 (UTC)

I've tried to switch those two artcicles to Geobox 2 (simply by replacing {{Geobox Protected Area with {{Geobox|Protected Area) and there were no problems. The acres are not default area unit for protected areas, these are square kilmetres/miles, only Geoboxes for buildings use m, ft, sqm, sqft etc. as base units. Both Point State Park and Allegheny Islands State Park declare area_unit=acre and it does what it is supposed to do. – Caroig (talk) 13:16, 24 September 2007 (UTC)

Addendum. I've checked the history and it seems you've used the "semi-automated tool" which is far from perfect, I wrote the script in an hour or so. Anyway, it should work OK now, at least as of unit type change, there was an error in the code which caused the unit types were ignored and not written in the new box. – Caroig (talk) 17:51, 24 September 2007 (UTC)

[edit] Geobox settlement

This is a terrific template, but I would like to suggest a minor improvement. It would be somewhat nicer to have a space between "timezone" and "uts_offset" (the same for DST). Something like "CET (UTC+1)" instead of "CET(UTC+1)". Since I do not have enough experience to make these changes, can anyone help me with it? Otherwise, thank you for excellent work! Tankred 01:42, 24 September 2007 (UTC)

Fixed, of course it should have looked like you suggested. – Caroig (talk) 04:32, 24 September 2007 (UTC)

Thank you for your prompt reaction. Tankred 04:38, 24 September 2007 (UTC)

[edit] Website url

If I add website url in form of http://www.kutnahora.info/?l=en then it s not displayed. If I add it as http://www.kutnahora.info/ then it is displayed ok, but it points to the Czech version of site. Look at Kutna Hora geobox. Thanks. --mikeshk 08:28, 26 September 2007 (UTC)

I have had the same problem with inclusion of the English version of kosice.sk (http://kosice.sk/languages.asp?id=1). Tankred 12:20, 26 September 2007 (UTC)

The problem is caused by the equal sign character in the url, the template understands it as a separator between the parameter name and parameter value, this relates to templates in general, not just Geoboxes. It can be easily fixed by replacing the equal sign character with &#61; (the simicolon included) which is the HTML representation of the equal sign. I've fixed both articles; as of Košice, it could be just the plain url, without the square brackets and the shorthand url but it looks nicer this way and saves space, but it doesn't have to be this way, 'course. – Caroig (talk) 13:34, 26 September 2007 (UTC)

[edit] Native name spacing

There should be a space between the name and native name. See Kunlun Mountains for an example. Also, I really question the value of "Range" being placed under the name. RedWolf 03:26, 28 September 2007 (UTC)

The spacing is fixed, thanks for pointing it out. In Geoboxes 2 we always have a "category" word below the actual name. Most mountain ranges (I daresay) do not have the word Mountains in their name so it helps the reader quickly orientate what the Geobox is describing. – Caroig (talk) 19:31, 1 October 2007 (UTC)

Well, I do question the need for adding range when "Range" is part of the official name. RedWolf (talk) 17:00, 7 December 2007 (UTC)

[edit] News as of 2007-10-07

Geobox news: 2007-10-07

Irregular newsletter on the lastest news, changes and bugfixes for the Geobox template

Let me inform you in this way about the recent cahnges to the Geobox 2 template code. Please add your comments or ideas.

• Many bugfixes, especially for river-related fields (source, mouth …). Some fields that existed in the Geobox River template were not displyed at all. Also fixed situation when if the line with coordinates was too long and there was a note, the line got split in two (for all browsers). This was causing the label field (- coordinates) being split in two parts in IE (which ignored the &nbsp; character between the hyphen and the word). Thanks to Ruhrfisch for pointing these bugs out.

• Also for rivers: if the locator_map option is on, the coordinates are taken from the mouth section.

• Change in display of World Heritage Sites, the section header gets the Geobox header background color, see e.g. Stužica.

• Further code size reduction for some fields (flag, symbol).

• New fields flag_border, symbol_border which if assigned any value turn on display of a border around the flag or symbol. This is usefull when the flag/symbol is a borderless (useally SVG) image whose light color merges with the Geobox background. Thanks to Mikeshk for the idea. See e.g. Poděbrady.

• And I also dared to change the icon that symbolizes the Geoboxes. I've just stumbled on this clipper ship which I made many years ago for a website, it's bit more original than the globe. – Caroig (talk) 13:07, 7 October 2007 (UTC)

• Addendum: there's a new field statistics which gets printed between the commons and website fields at the bottom of the box, it can contain a direct to link a statistical site so that the data can be easily updated. – Caroig (talk) 16:20, 7 October 2007 (UTC)

[edit] Geobox bridge

The following text is an answer to a request by User:Skeetidot, as it concerns a general geobox issue (use of Geobox 2 for bridge) I post my reply here.

• User:Skeetidot/GeoboxBridge2 - proposal
• User:Caroig/Sandbox/Bridge - proposal with my comments

Please, let me first write some explanatory text why I suggest certain fields to be formatted/used in a certain way. These aren't any hard-set rules, it's just what I'd like the geoboxes to be. And of course, add any comments, ideas, even critical ones are welcome.

The fields are organized in a database-like structure and so should be the values entered, one field should contain just single, unformatted value, i.e. without any html code, line breaks, but also the actual field value and any sort of commentary should be split into their separate fields. Why is that? Given the template field structure any geobox can serve as an excellent, easily parseable source of data for any sort of Wikipedia or non-Wikipedia project. If the fields are hapazardly named, the values entered with a lot of formatting it's much more difficult to parse the data in any way, for any purpose. An idea of implementation is a translation to any national Wikipedia. If you know in advance what sort of and how formatted data a field can contain this task is very easy to implement. However if the field contains a lot of text data and the actual value, say length, is hidden somewhere in it any automated parsing is rather impossible. As of your suggestion this concerns the Crosses and Carries fields.

The names of the fields (the text displayed on the left) shouldn't change within a series of geoboxes on one topic. So types universal for bridges, or at least US bridge should be same bridge from bridge. This concerns e.g. the length1 field, while it's OK when it sets length1_type = navigational (a field which can be used for most bridges), the information it relates to the middle span should preferrably be in the note (as it can be the middle span, or the third span or the leftmost span …).

Also when "retyping" the fields the data should be entered to a field somehow related to the data so that it would make sense even without its _type. This concerns the Crossses data, it best fits into the river field. The new type text should be as short as possible (possible moving longer text into the appropriate _label which displays an info on hover) because the label text is prevented from being split into two lines.

And finally comments on some of the fields (the fields marked with an asterisks might be "retyped" by the geobox code because I believe the suggested label is fit for any sort of bridge anywhere in the world):

• municipality - there exist this field so why not use it instead of retyping the district, also if there are more municipalities they should be split into indexed fields
• * parent - any bridge is usually a part of some road or something so it can be considered its parent, again multiple parents (with index) can be used as for the twin bridges in your previous example, the Carries label's OK, can be Road or Rail track if needed. Any additional data, such as it's only for pedestrians, trucks up to 5 tons should be put into the _note field (fields if there are multiple communications)
• river - the best for the Crosses data, if the bridge doesn't stretch over a river the landmark field can be used (?) or we can add a special field for this
• length - I guess there's no need for the label to read Length (total), the default Length seems OK. The first dimension of any time always relates to a total figure, well, it should.
• * clearance - Again, retyping to just Clearance seems enough if the default Height isn't satisfactory, I have no problem talking about a bridge's height but I'm not an engineer.
• style, author - the suggested labels are OK yet I don't think they will be used generally in that form for any bridge, historical bridges here, in Central Europe, might know just their designer
• * established - Build and opened labels seem fit. I'd prefer keeping both years in the established field which should be used for any established/settled/opened/reopened data while the data fields are to be used for any other dates: burned down/abandoned etc.

Hope I haven't forgotten anything. I've added support for {{Geobox|bridge. There wa some sort of support for bells but this was created only during the development. The bells now use the template call as {{Geobox|monument with the appropriate bell type in the category field. I will only add full support for those features which are going to be used frequently and for whcih there will be some further changes in the geobox code, such as the "retyped" fields. When you use {{Geobox|building, {{Geobox|monument and newly {{Geobox|bridge the default units for the length, width and area are set to meters/feet or square meters/square feet respectively. – Caroig (talk) 19:37, 8 October 2007 (UTC)

Caroig, that looks great, thanks! The only thing I noticed is with the traffic carried. The Blue Belt carries vehicles. Pedestrians and cyclists can use the sidewalk, but vehicular traffic is the main function of the bridge. I can see people wanting to add the name of the road, number of lanes, etc. Skeetidot 16:40, 10 October 2007 (UTC)

I think that VerruckteDan did a good job of displaying traffic that the bridge carries. See his example at sandbox7. Skeetidot 16:40, 10 October 2007 (UTC)

I've updated my example: User:Caroig/Sandbox/Bridge. There's now a brand new field: road, with up to four indexed additional road fields. The data in the example is not meant seriously, it's just some sample text. Can it be this way? In this place or after the river? I suppose there would usually be just one road running on the bridge, so we probably don't need to have the empty Carries line. Should the label read Carries by default or should the field istelf be named that way? And what about the fields marked by an asterisk in my previous post? Would that make sense if the geobox code changed the labels by default in the suggested way? And please, if you disagree with something I suggest, do say so, my word is not sacred at all ;-) What you think about my suggestions to some of the fields used for bridges in my first post: clearance or height by default, river used for Crosses etc.? – Caroig (talk) 19:25, 12 October 2007 (UTC)

Caroig, thanks for the updates! I made some updates on your sandbox page as well, User:Caroig/Sandbox/Bridge (hopefully, that's OK, but I can put them on my sandbox if it's an issue). Here are my thoughts by section:

Features Crossed

I'd say that the feature crossed (i.e. river) should go first. Though the bridge's main crossing is the Monongahela River, if you look at the code, you'll notice it also crosses some railroads (and roads I didn't include) that the geobox doesn't yet account for.

There's also the landmark field which could be "retyped" to Crosses. Or do you think a new field (crosses) would help? I'd prefer using one of the existing fields. – Caroig (talk) 07:43, 14 October 2007 (UTC)

Traffic Carried

Your label of "Road" is fine. Maybe the Carries field was intended to indicate whether the bridge carried vehicles, rail lines, pedestrians, etc., but I agree it's not needed. The main feature carried (in this case, road) should be first. Then, I listed the additional traffic the bridge carries below (HOV, sidewalks, etc.). My intention is that the type of traffic would go on the left and the name of the feature would go on the right... looks a little silly though, since HOV lanes and sidewalks aren't named. Notes fields can also be filled out here to indicate the number of lanes of each type of traffic. Ideally, the "2 lanes" for HOV would be italicized, but I didn't know what to put in the name field (this is just made up data, but I wanted to put it there as proof of concept).

I do not see how I would fill in the data myself, perhaps when the Geobox is used for more bridges some sort of formatting for this field will prove as the preferrable one. – Caroig (talk) 07:43, 14 October 2007 (UTC)

Features

I added a field here to list the number of spans that the bridge has. I couldn't find an appropriate field here, and wanted it to go above the design and material, so I used the geology field. You could add a new field here, since it's probably not best to put completely different information in the geology field.

And I've added a number field in the "Dimensions" section, though it's among other units it doesn't have any unit assigned, it can be just a plain number of anything, e.g. spans for bridges. – Caroig (talk) 07:43, 14 October 2007 (UTC)

Clearance

I personally don't understand what vertical clearance is, especially since this bridge is a deck truss and therefore doesn't have an obvious height restriction, but I'm not an engineer either. It doesn't make the most sense to me, but I didn't know of a good way to change it, either. VerruckteDan, any thoughts?

Asterisk Fields

• municipality - Makes sense to me!
• parent - I would use the term Carries or Traffic Type instead of Parent. The main type of traffic carried (in this case, road) should be first, with additional types (such as sidewalks) below.
• river - Interchanging river and crosses is fine. If the bridge primarily crosses a river, though, I want that to be the first feature listed. Roads or any other landmarks crossed should go below, and wouldn't need separate headings.
• length - True. Makes sense to me!
• clearance - Clearance and height are different. A bridge might be very high, but have height limitations for driving across it. Look at arch bridges (example: Fort Pitt Bridge). The height would be the height at the top of the arch. The clearance is much less, limited by horizontal elements of the arch, signs, etc. I'm not sure I understand your question, but I think we need spaces for height, clearance above, and clearance below (navigational clearance).
• style, author - Style is intended for the bridge design. A lot of historic European bridges would have the style, stone arch or just arch with stone as the material. Author would be used for the bridge designer. In the US, historic bridges were designed by bridge companies and more recent bridges were built by government agencies (with the help of engineering firms). I assume for European bridges, people would list the architect or engineer.

OK, so we probably don't need to have the code change the default label as it seems it will vary depending on where the bridge is located.

• established - Established makes sense to me... since I've used it in {{Geobox|Settlement as well

Other than that, I just did some capitalization (I think it looks cleaner if everything in the left column is capitalized, such as Main span, Navigational, etc.) and added a little more info to show it could fit in the geobox. I think the template is just about ready to implement on real sites (not just sandboxes)! I just placed a comment on WikiProject Bridges to get more expert opinions. Let me know if you make any changes!

Skeetidot 03:50, 14 October 2007 (UTC)

As of capitalization, the Geobox prints capitalized bold labels but the "sub" fields are printed in lower case and normal font weight. I didn't have any clear reason to make it that way. So if you prefer it this way, that's fine. The "sub" fields are "retyped" in most situations anyway. If there's a consensus this should be the default Geobox design, I'll change the code appropriately. – Caroig (talk) 07:43, 14 October 2007 (UTC)

And yes, I've finally decided to change the font size so that the Geobox gets displayed in the same way across all browsers. I've had this smaller size in the code since the beginning, only IE from reasons to me unknown, decided to ignore that. Most other Infoboxes that make use of the "infobox geography" css and set the font size to be somewhat smaller suffer from this IE bug as well. – Caroig (talk) 07:49, 14 October 2007 (UTC)

And finally, You might want to read the section bellow because the Geoboxer might probably be adapted to convert from any existing Infobox as well. – Caroig (talk) 14:43, 14 October 2007 (UTC)

Caroig, I haven't had a chance to work on the geoboxes this week, but I wanted to direct your attention to the comments we've been receiving on WikiProject Bridges. They requested that we incorporate information for NRHP (National Register of Historic Places) data, since many of the bridges that would be receving geoboxes are on the NRHP. The samples provided are the Bedell Covered Bridge and the Cornish-Windsor Covered Bridge. Skeetidot 18:53, 18 October 2007 (UTC)

I'm afraid I'll so no here. While I realize that these fields can be used for other Geoboxes, on other subjects (buildings, monuments), not just bridges, they're still US specific. The Geobox has already fields for these purposes. It's exactly what the five code fields should be used for, for covering nation-specific codes of any sort. And there are also the five free' fields. – Caroig (talk) 20:37, 18 October 2007 (UTC)

I think that's fine. We can use the code fields for that sort of nation-specific information. Skeetidot 23:20, 21 October 2007 (UTC)

[edit] Template use audit

I've now written some auditing tools for templates, and have been running them on the most recent en: dump. The first result of this process is User:The Anome/Infobox audit, which tries to spot plausible uses of geodata-related parameters in Wikipedia templates, other than those using the standard coordinate templates.

Clearly there is a lot of standardization work to be done -- but I see you are working on it already. Can I help you in any way? -- The Anome 22:54, 10 October 2007 (UTC)

Well, actually we're not working on any standardization in the scope of the whole Wikipedia. The Geobox project started about a year ago beacause I was not satisfied with the chaotically named parameters of most existing templates and the fact each and every one used a completely different layout. So I created {{Geobox River}}. I found the code was easily adaptable for other geographic features and so {{Geobox Settlement}}, {{Geobox Mountain Range}}, {{Geobox Protected Area}}, {{Geobox Mountain}}, {{Geobox Region}} were born. And requests for other Geoboxes were coming.

If you look at those templates you'll find out their code and most of their fields are the same and the template differ from each other by a few extra fields in each (and the heading color). So after some time a decided to create a master Geobox (aka Geobox 2) which could serve them all. The initial code copied from the old Geoboxes (aka Geobox 1) wasn't very effective but after two upgrades (aka 2.1 and the current 2.2) we got a code which was much more effective than any of the Geobox 1 templates, reducing the pre-expand size 4 to 5 times and thus we get much faster code execution. The Geobox 2 template is fully backward compatible with the old Geoboxes, if you replace {{Geobox River with {{Geobox|River in any existing page all fields will get displayed, only some'll get rearranged beacuase the fields in the old geoboxes weren't always ordered in the same way. So for your audit you might put all Geoboxes, in both versions, into one category because they're basically identical. We'll be converting everything to the new version.

But back to your question. Replacing all Wikipedia Infoboxes with Geoboxes has never been my target. I'm just going to edit the places I can provide photographs for, which I visited. Nonetheless, I believe they're very universal (they were designed to be) and can proably be used for any sort of geografic data. And if anyone wishes to implement the Geoboxes for their country or for any sort of a geographc feature, I'll be glad to assist, if I find the time of course.

The main feature of the Geoboxes isn't that they all look the same but that the fields are named in a unified style. Most field names consist of one word (image, river, area) while all additional data (image size, number of significant digits, field label) are derived form their name by suffixes (image_size = 128, river_type = Creek, area_round = 2). All data is to be entered in raw, unformatted way and thus it can be easily parsed for any purpose. While the design might be radically changed, the field names should be durable.

There exist a php tool that can clean-up existing geoboxes, update fields or even convert from other infoboxes (currently the tool supports only clean-up on geoboxes on settlements, converts from Infobox Slovak Town and adds some missing data for settlements in the Czech Republic and Slovakia, which is the region where I live …). I'm working on the tool's upgrade/cleanup so that it could be easily extended with support for any infobox should anyone request it. The tool runs on my personal server but if anyone's interested I'll provide the source code. I'm no programmer, so it's no miracle but it can do its work. It would be great if anyone can trasform the code to C# for the AWB, it shouldn't be difficult as the script just fetches an article and performs some formatting and clean-up on it, mostly thru regular expressions.

You might want to read all the posts on this page, there are couple of issues such as some sort of categorizing or creating "What links here" page for each and every geobox category. Any insights you might have are welcome.

So far, there exist Geoboxes for the following geographic features:

• settlements (example: Necpaly, Prague)
• mountain ranges (Greater Fatra)
• protected areas (Greater Fatra National Park, Stužica)
• mountains (Tlstá)
• valleys (Blatnica Valley)
• rivers (Váh, Amazon)
• regions (Pilsen Region)
• buildings (Blatnica Castle)
• bridges (User:Caroig/Sandbox/Bridge) - under construction, which means we're just deciding which geobox fields to use, the code support the bridges without the need for any upgrades
• bells (Liberty Bell) - a highly special topic yet the Geobox can be used with no need to change the template code – Caroig (talk) 20:21, 12 October 2007 (UTC)

Thanks for your comments. Yes, I am interested in infobox standardization as part of my larger work on geographic metadata. So far, I've worked largely on geodata tagging and categorization. However, my tagging work is now beginning to collide with previous infobox data, and the chaotic formatting of the various kinds of geographic infoboxes made it impossible to reconcile the two.

Rather than compete with or duplicate the data already in infoboxes, I started looking at standardizing them, only to discover that you were already doing exactly what I was considering doing -- creating a single uniform format for geoboxes, with standardized parameters.

If this can be done, I hope it will stop other people from adding new ad-hoc infoboxes (which they typically do by finding another infobox template and hacking it), and have them standardize on the new geobox format, with great advantages not only for the visual appearance of Wikipedia, but also for its use as a machine-readable metadata source (which is still my principal objective).

I have some tools which can extract template data from wikitext, and I've been running them on dumps to find possible candidate templates. I've now completed my first pass of identifying possible candidates for standardization, and I can now start extracting parameter lists from each of the templates identified in the first pass.

To complete the process, I would need firstly to identify mappings from the old parameters to geobox parameters, possibly creating new geobox data fields if necessary, and then to run bot passes which convert from the old infobox style to the new geobox format.

However, if other people are working on the same or similar projects, I don't want to clash with their work, particularly if they already have tools built for this process. I would be very interested in providing useful data for this project: lists of pages, parameter lists from templates, cleaned-up paramter values, etc., for other people to use, since I have done much of this work already. -- The Anome 10:00, 14 October 2007 (UTC)

[edit] Parts

I took note that if there is filled eg. 30 parts then only 16 are shown. Is it a bug or a feature? Look at Klatovy for example. Thank you. --mikeshk 13:01, 11 October 2007 (UTC)

That would be a weird feature. Sure it's a bug/omission on my part. Fixed. – Caroig (talk) 13:29, 11 October 2007 (UTC)

[edit] Geobox Slovakia & Czechia

I was asked some time ago by User:mikeshk to add a fucntionality to the Geoboxer tool which would put a blank geobox with some pre-filled fields to articles which have no Infobox/Geobox at all. I've just realized there are no Czech Slovak settlements without an Infobox/Geobox. How come? We have our sister projects on the Czech and Slovak wiki. Given most existing articles have at least a link to the corresponding article on the national wiki we have an easily accessible source for the data for the Geobox.

And you can actually help here. I'm working on an upgrade of the Geoboxer tool in terms of the general code (it's very chaotic but at least now I what it should be able to do). And then we might start adding special code for various boxes to convert from. It would help me a lot if anyone prepares the conversion list for those Infoboxes from the national wikis.

The Geoboxer is written in PHP, I do not now if you're php-savvy but you can help either way. The conversion works in two steps.

First step - fields (parameter) conversion. This works in two phases.

'a': For each infobox to convert from there's a variable named $map which is an array, whose keys are the field names in the source infobox and the values are the field names in the target geobox. Thus for the Czech wiki's Infobox české obce a města the variable can look like this:

 $map = array (
   'název' => 'name',
   'status' => 'category',
   'popisek.foto' => 'image_caption'
   'výměra' => 'area'
   … );

'b' : Some fields obtained in the first phase need some further changes. E.g. the field 'category' will now contain the Czech word obec but we need it to be Village. So we'll have to to change this. All the geobox data are stored in a variable named $data which is an array too, the keys being the field names the values being the actual values of course. So in php we'll do this:

 $czech = array ('obec', 'město');
 $english = array ('Village', 'Town');
 $data['category'] = str_replace ($czech, $english, strtolower ($data['category'));

Of course this can be achieved in other ways, e.g using the switch keyword. Personally I prefer using regular expressions which enable the code to be pretty short. But that really isn't important. Any way to achieve the desired result is OK. The czech figures will use commas instead of decimal points so we'll simply swap them:

 $data['area'] = str_replace (',', '.', $data['area']);

But it would help me even if you just describe the necessary changes, like the commas must be changed to decimal points for the area field. It helps checking this in more than one page as users might have edited every page in a different way so it's good to now all versions. You might want to use the following subpages: User:Caroig/Geobox/Czechia and User:Caroig/Geobox/Slovakia to post the conversion rules. (As this is a highly special topic, related to just these two countries, I guess it's OK if you use Czech or Slovak languages should you find it easier that way).

Second step - field updates for particular countries/areas, which do not depend on the source geobox (they're applied during every conversion, no matter where the data comes from). E.g. it can check whether the country_flag = 1 field is set (it seems there's a consensus to use flags for these tow countries). This has already been implemented. As well as checking the region field looks like this: [[Žilina Region|Žilina]], if not it formats the field accordingly. Here you can simply sum up ideas on a standard field display.

It would really help a lot if anyone tried to at least prepare the necessary conversion patterns. The sooner we have the conversion patterns the sooner you can add Geoboxes to each and every settlement. – Caroig (talk) 21:32, 12 October 2007 (UTC)

[edit] News as of 2007-10-14

Geobox news: 2007-10-14

Irregular newsletter on the lastest news, changes and bugfixes for the Geobox template

After a week there's a new installment of Geobox news. There are some minor upgrades and one BIG surprise.

• The Geoboxes will probably be used for some bridges, see Bridge Sandbox. {{Geobox | Bridge call supported
• New fields:

• statistics - for a direct link to statistical data (see e.g. Necpaly)
• road - introduced with Geobox for bridges for roads/railroads
• number - introduced for bridges as well, it gets displayed among units but doesn't have any unit assigned, it's just a plain number of anything (it will be used, e.g., for the number of bridge spans)

• All Geoboxes create a category in the form Category:Type, Country[, State] to enable easy maintenace of Geoboxes for a given feature. I'm not sure if this is the best solution but we need some sort of organization. Please express your views.

Simply ingenious! Thank you.--mikeshk 13:48, 15 October 2007 (UTC)

I couldn't agree more, I just found the page, awesome.--Kranar drogin 03:55, 20 October 2007 (UTC)

• The same font size across all browsers. IE, from reasons unknown, ignores font size of 90% which is used for most geography related infoboxes (with the same issue, IE ignores it). However, setting the font size to 89% does the trick. Must be some Microsft(TM) formula which hasn't entered maths textbooks yet. IE users will now see the font being somewhat smaller which has been the design since the beginning. The solution comes from the discussion at {{Infobox City}}.

And what's the big surprise? Brand new Geoboxer, version 3.0. A tool for automated conversions of Geoboxes from various other Infoboxes. It has two major functions: conversion and cleanup.

• The Geoboxer can convert (so far) from just one Infobox, {{Infobox Slovak town}}. It analyzes its fields and converts them to appropriate Geobox fields. The doesn't just rename the fields, it e.g. splits the coordinates data which are withing a coor template and puts them to corresponding Geobox fields.
• It can convert all old Geoboxes to the new format. It fixes a few fields which have been renamed (yet Geobox 2 still understands the old field names should you just rename the template call). It rearranges all fields to correspond to the order in which they get diplayed (it doesn't need to be so, it just look better). The output is in the old whitespaced format which is much easier to edit. For each feature it prints some basic set of fields which are most likely to be used, even if they are empty. This can also be used to start new Geoboxes in articles, type in just the template call with the type (e.g. {{Geobox|River|}} - NB the pipe after River), run the tool and you'll get a blank template with many river related fields. Nontheless, if the Geobox contains some fields which are not considered default for a given feature, they are kept and printed provided they are nonempty.
• And the best comes now. Well, just for Slovak users. Not only can the tool convert from the old Infobox, it can place brand new Geoboxes to any Slovak settlement without any box of any kind provided there exists a corresponding page on the Slovak Wikipedia. Similiraly it will look there for some missing data if the tool is run on an already Geoboxed article. The tool also standardizes many fields (the phone numbers will get displayed as +421-area_code, auto calculation for population density will be added, link to statistics page (a direct link to the page with the data on the settlement, not just general link to the statistcis page), flag display will be turned on (this applies for any Geoboxes that will have country == Slovakia), the locator map will be added and if exists, the locator map within a region as well. Some of these fixes work for the Czech republic too (e.g. turning on the flag for everything within the country).
• The tool also performs some general fixes for every Geobox such as short disply of websites (without http://).

The tool's far from perfect and it can save a lot of tedious work. Should you encounter any issue, don't hesitate to report it although I'm going to slow down a bit on the Geobox development (it's fairly matured, isn't it) and focus on working on articles, mainly on around my beloved Greater Fatra range.

And how can you use the tool. The easiest way for Opera Browser users is to create a button (follow this link. The others will need to put the following code into your monobook.js. If you're already using the Geoboxer you don't need the first snippet, there's just another text on the tab, othewise it's the same code.

//add Geoboxer link 
addOnloadHook(function(){
  var editTab = document.getElementById("ca-edit");
  if (!editTab) return;
  addPortletLink("p-cactions", 'http://wikipedia.paloch.net/Geobox2.php?page='+location.href,
  "geoboxer", "ca-geobox", "Geoboxer","", editTab.nextSibling);
});

And another tab when you want to add a brand new Slovak settlement Geobox.

//add Geoboxer for Slovak settlements
addOnloadHook(function(){
  var editTab = document.getElementById("ca-geobox");
  if (!editTab) return;
  addPortletLink("p-cactions", 'http://wikipedia.paloch.net/Geobox2.php?page='+location.href+'&source=sk_obec',
  "geoboxer.sk", "ca-geobox_sk", "Geoboxer for Slovak settlements","", editTab.nextSibling);
});

Hope it serves well. – Caroig (talk) 23:16, 14 October 2007 (UTC)

Kudos on all the work... however, I think that the categorization feature needs to go away, as it creates unnecessary noise. See for example Larrys Creek. Basically this seems to just be a category for tracking template use -- and as such, provides no real information to the article reader. If a sorting device like this is really needed, perhaps hidden links or wrapper templates would be more suitable? -- Visviva 01:49, 16 October 2007 (UTC)

Actualy that's what the categories are to be used for. Given what the Geoboxes try to be, a unified database-like easily machine-parseable data abou any geographical subject, they might deserve their own category. Whether it takes this form or just simple categories based on the Geobox type (just Geobox Settlement, Geobox Bridge, Geobox Mountain) is another question but usually there's a wikiproject focused on a state or a country and this simply helps the editors see for which articles in a given category of their area these standard data have been supplied. You can then easily apply any changes on it using e.g. AWB. I thought about creating some invisible links but these would have to be placed somewhere and having the target in the main namespace isn't very clean. Such lists should be created in another namespace. I wouldn't object to having them in my userpages but I don't think it would be good to have this tool connected with one user's space. And still, this would only enable listing the articles with Geoboxes using "What links here" which gives unsorted and unorganized lists which have to be manually edited for any purpose. The categories feature enables to list them alphabetically and, if the list is too long, split it to multiple pages. If you look at the categories attached to e.g. Prague there's a lot of those of maintenance nature. I don't think it's against any wiki rules having a category that tells usere the article contains standardized easily parseable geodata. Anyway, after a request, the feature can be manually switched off for a given article by adding the geobox_category_off = 1 field– Caroig (talk) 19:54, 16 October 2007 (UTC)

• We have had this discussion previously on this page about whether to auto-categorize pages when they use these templates. At this point, I just don't feel that this is the best approach. If there was an option to populate categories but not actually show the category on the article itself, then I think it would work (although this might cause confusion to the uninformed). While your argument has merit in that there are other maintenance type categories out there, they are intended as a temporary measure to assist editors with wikifying articles, disambiguation, expanding stubs, etc. and eventually (hopefully) they would be removed. While it is not against wiki rules, I think aesthetically, it leaves a bad taste. At this point, I think geobox_category_off should be the default until we get this worked out. Other than that, kudos on all your geobox work. RedWolf 03:57, 17 October 2007 (UTC)

The problem is I don't see a better solution here. Some sort of auto-categorization is highly desirable. Since we're not breaking any rules it's just about personal preferences and I like this solutiton more and more and so do other editors (while some disagree as well). I am open to any proposals and if the mojority turns this solution down, I'll remove it. I had been thinking about it for quite some time and is there a better way to see whether an idea is good or not than to try it out? – Caroig (talk) 17:18, 17 October 2007 (UTC)

"statistis - for a direct link to statistical data" -- Should that be statistics? (SEWilco 15:21, 26 October 2007 (UTC))

Surely, fixed, thanks. – Caroig (talk) 16:33, 26 October 2007 (UTC)

[edit] Headers

There seems to me to be something inconsistent in the way Geobox headers are organized (I'm not sure if the problem is with the definitions of the fields or just the way they're displayed). We have the following fields: name, native_name, other_name, category, and (outside the header) official_name. This would seem fine. But problems arise when the normal name contains the category (as in the example you - Caroig - pointed me to in our previous discussion, Plunketts Creek (Loyalsock Creek). You say that in this case, the category should be removed from the name (so name=Plunketts, category=Creek). Thus we get the display format Plunketts Creek. From this, both readers and parsers are supposed to conclude that the primary name in use is actually Plunketts Creek.

But I don't understand how they can, given that in many other cases the primary name is just the content of the name field. Take your other example, Bratislava. Here name=Bratislava, category=City. But the standard name is not "Bratislava City", just "Bratislava". How is the reader or parser supposed to know whether or not to affix the category? It doesn't just depend on the category, since there exist cities whose names end with 'City' and there are probably creeks whose names don't end with 'Creek'. And in some cases the category would be affixed before rather than after the name (as with Lake XXX). Again, how do we know?

Of course, we can look at the article text or just the title, so in practice it isn't a huge problem (though it might be for an automatic parser), but this seems to be contrary to the infobox philosophy. There can't be many facts about something much more essential than its name, so an infobox ought to present at least this piece of information with total clarity.

Another thing is that the situation becomes even more confusing (for the human reader) when the native_name or other_name fields are filled in. Then the name becomes separated from the category, making it even less intuitive that the category is to be read as part of the name. Say the creek has the other name Cooks Brook. You would have Plunketts (Cooks Brook) Creek on display. This can't be right surely?--Kotniski 10:15, 19 October 2007 (UTC)

I see your point. While it's quite clear from the point of view of an administative division, which always has an official name, it's not that easy in case of other locations such as rivers, ranges, mountains etc. There was some discussion on this topic e.g. at the Amazon River, though it rather concerned the name of the article. And countless similar debates. Then there are many Spanish or Latin American Settlements which have quite a long official name, though rarely used, such as La Nueva Guatemala de la Asunción for the Guatemala City which is Ciudad de Guatemala. What should go to the header?

The Geobox doesn't address how to name artciles but only how to display the data in its database-like format (which is clearly something different from the text as it would appear in the article body). It seemed the best compromise to emphasize just the proper name, which is the core piece of information, so that even a user with limited knowledge of English could see, what's just some sort of category word (Parish, Township or Gmina) and what the proper name. For avoiding any potential confusion, there's the official_name which should contain the official full version of the name. The parser can't get confused as it expects the title to be formatted this way. Most databases will have Gmina XXXX stored (indexed) by the XXXX part of the name, not Gmina.

I don't think this solution is perfect but if it is used consistently, it shouldn't create any confusion. The main target is to somehow set apart the proper part of the name form the generic word. Any ideas how to address this differently? – Caroig (talk) 21:00, 22 October 2007 (UTC)

I think the Geobox header layout generally works better than most of the other Infoboxes I've seen, so I wouldn't wany to change it more than necessary. I think the only issue is to decide in which cases it's permissible/advisable for the name to contain the category (or a synonym of it). So let's look at some cases:

• Settlements: in the vast majority of cases there's no problem. In a case like New York City, the name could be just New York and the category City, since New York is the normal name. But in other cases, like Oklahoma City or things like New Town/New Village, I think it's clear that City/Town/Village must be both part of the name and the category, since the remainder of the name would be misleading or meaningless on its own.
• Rivers: the present solution works perfectly for the vast majority of rivers, since "River" isn't an essential part of the name, and putting it underneath in the category field avoids the River X/X River issue. But again there will probably be exceptions (Yellow River?) And where the naming word is not River but e.g. Creek or Stream, it seems more natural in most cases to include it in the name (possibly using just River as the category rather than repeating e.g. Creek).
• Mountains, other physical landforms: probably a similar situation as for rivers. Usually the category would not be part of the name, but in particular cases (e.g. Table Mountain, Black Sea) it probably has to be.
• Administrative regions (these are the ones of my immediate concern). Obviously something like Texas or Kent gives no problem. With US counties I would tend to include County in the name field (e.g. Springfield County), analogously to Oklahoma City. I agree that in a database of counties it would appear as just Springfield, but a) our first concern is to make the situation clear to human readers (who might not have vast experience looking at Geoboxes), and b) it's easier for a parser to subtract a word when it needs to than to add one (how would it know County is part of the name with Springfield but not with Kent?). The same arguments apply to Polish counties and gminas, with the added factor that I would like to include an other_name or native_name field (putting these underneath in official_name is misleading), and that's not really possible with the present setup (it would be like my hypothetical example above with the Brook/Creek). Another point is that in databases "gmina/commune" or "powiat/county" likely would be included in the name, because of the possible clash of names between Xxx and Gmina Xxx or Xxx County. --Kotniski 08:54, 23 October 2007 (UTC)

I agree with most of your points. We simply can't have the header reading just Everest for Mt. Everest and many other cases. As it was designed the native_name was meant to be used in cases when the proper name itself in the native language was different from the English one (Praha/Prague), similarly the other_name is designed to contain other frequent versions of the proper name, such as the various names of the Amazon along its course (Tambo, Ene, Solimoes …).

The elegancy of the always-split solution is it doesn't need the parser to be set up to treat each and every country differently. But obviously there will always be some situations when the category word will have to be a part of the name, e.g. Mt. Everest. The database can be organized this way as well, though the databse structure I had in mind was that it the primary index would be on two fields: name + category, thus XXX + Town will always be different from XXX + County (as well as from a potential XXX + City County), XXX + Gmina.

I don't think there doesn't need to be anything more in the header then Gmina XXXX given the articles are always named this way and the Gminas are always referred to this way in most articles so I think adding either Commune or Municipality in whatever form in the header is rather confusing as these are not used anyplace else (my major objection to your first treatment of the Gmina ggeobox was rather that the header was cluttered with data). I still prefer having just XXX as the name field and Gmina in the category field as, in my view, the XXX is what's matters more here, though given there will always be some Geoboxes where the category will in one way or the other get repeated so I probably can't object to the name being set to Gmina XXX and the category to [[Gmina]] again. But probably nothing more, to keep the header as simple as possible. – Caroig (talk) 20:52, 23 October 2007 (UTC)

[edit] Auto categories

There have been several complaints about the auto-category feature of the Geoboxes. From reasons unknown, they were first placed rightfuly at Template talk:Geobox#News as of 2007-10-14 stating some users didn't like this feature (while some did). Another complaint was posted at a personal talk page: User talk:Caroig#Suggestion suggesting the feature was breaking some rules which were not given. The topic was then shifted to Wikipedia:Village pump (policy)#Question where, unfortunatelly, some false statements and allegations were made. The feature was finaly put to Categories for Deletion: Wikipedia:Categories for discussion/Log/2007 October 25#Geobox categories.

Here's a summary of why this feature has been added: it doesn't serve to trace the template's usage but to indicate that the page contains easily readable and machine-parseable geographical data. It can well be put into just one large category but the idea was to help users working on a particular area easily organize their work but also to help readers to browse thru a set of articles on a given topic with consistently presented data. It was never stated that this feature is a must, if the whole concept is wrong it can easily be removed, but there should first be a discussion, it's a good Wikipedia practice.

Besides several completely unrelated allegations there are several good points in one of the pages and I'd like to raise several questions.

• Most importantly. Is the major objection that the category name contains the word Geobox? From the arguments provided it seems the name's indeed incorrect from several reasons.
• Or is bad the system that a template creates multiple auto-categories based on the data it contains and not just one category?
• If the created auto-category goes e.g. Articles on Slovak Settlements that contain consistently formatted machine-parseable geographical data would that bee OK? This not an actual proposal of the name, it's just a name from which the majority of English speakers would most easily recognize what it is about. The actual name would have to be agreed on (and it would have to be shorter, of course).
• If creating any sort of auto-categories is a bad idea (and/or breaking some rules), is there any other suggestion how to help organize the various Geoboxes?

I'd appreciate anyone who uses or likes to Geoboxes to give their 2c here and possible read the posts at the other pages, especially at Wikipedia:Village pump (policy)#Question which left me gape with mouth open wide. – Caroig (talk) 22:50, 25 October 2007 (UTC)

This has to be one of the most ridiculous things I have seen brought up on the Village Pump. Nominated without debate other than one sided without contacting the creator. Then to make accusations without knowing anything like WP:OWNis ridiculous. I don't think some people know all the rules around here that well, and then just throw them out at will when they find something they don't like. Keep them is what I say.--Kranar drogin 23:07, 25 October 2007 (UTC)

{{GeoGroupTemplate}} does emit Category:Lists of coordinates for several reasons, but notice that {{coord}} does not label which articles contain coordinates. At the moment anyone wanting to find Geobox articles can use Whatlinkshere and other categories could be added later if they are needed. Adding state,city categories following existing naming is fine with me if it's properly documented. (SEWilco 15:18, 26 October 2007 (UTC))

It's seems the name chosen for the auto-categories is indeed a wrong one as it contains the word Geobox. That could easily be changed after we've decided what the new name should be. One question still remains though and that is if the template can generate more detailed categories based on the feature it describes (e.g. Settlements in Slovakia with parseable geographical data - in fact it would be something shorter)? Similarly to what other templates do, namely those maintenance tags as e.g. in Prague. There are actually four maintenance categories: All articles with unsourced statements | Articles with unsourced statements since September 2007 | Articles with unsourced statements since March 2007 | Articles needing additional references from August 2006 and no one seems to object to this. One category is placed here by the template (and other maintenance tags often placed at the very top of many articles do the same) that displays the This article needs additional citations for verification text, where the other come from I do not know. – Caroig (talk) 15:32, 26 October 2007 (UTC)

"parseable geographical data" are metadata comparable to the metadata generated on people article pages with the {{Persondata}} template (see wikipedia:persondata), if I finally start to understand this correctly. If that is the case: not eligible for categorisation, afaik (I mean as far as I can assess the usual reaction to proposals for using categories for such things). That's also my personal view: not eligible for categorisation. --Francis Schonken 16:42, 26 October 2007 (UTC)

Yeah, they're comparable. Yet the Geobox doesn't just add a further block of data to the page but uses this metadata to generate a geographic Infobox as well. We'll definitely find a better name to this auto category, whether it should be generated or not will depend on the outcome of this discussion. We might also think of a way which would allow users to switch on this feature temporarily for a set of objects within a given area while they're working on it. I've just figured out how to do it technically. – Caroig (talk) 16:55, 26 October 2007 (UTC)

The categorisation should be in the "switch" then: default: off; only visible when the geodata are switched on by the individual user's choice (by css or whatever). If technically not possible (or: until implemented): no categorisations of this kind in main namespace, at least: that's my opinion. --Francis Schonken 17:08, 26 October 2007 (UTC)

Agree with Francis. By standard categorizing we will achieve nothing and just fill articles which use Geobox with this waste. If this scheme, as David pointed out, is made with purpose of generating some list of articles to help editors, it should be done more professionally, in nice and clean way, as e.g. Persondata are. Creation of hundreds of badly named categories is the worst way to go and it is only a matter of time when they will be deleted. Probably other users will nominate 'em in the future. I work with WP:CFD for over two years, so you can bet on it. - Darwinek 18:04, 26 October 2007 (UTC)

Settlement categories are mentioned in Wikipedia:Naming conventions (categories)#State-based_topics. (SEWilco 17:26, 26 October 2007 (UTC))

OK, let me just figure out system which would satisfy both sides. I see the problem in generating too many "red" categories by default and having the word Geobox in the category name. However for some users it's useful to have a category (rather than just a Whatlinkshere page which doesn't allow you to sort the articles in any way) for the area they're working on. As e.g. Czech or Slovak settlements. I prefer not to switch off the functionality before the new system is ready so that we don't break the ongoing projects whatever they might be. – Caroig (talk) 18:33, 26 October 2007 (UTC)

If people are converting from an infobox to Geobox, can't they use infobox>Whatlinkshere to find something not converted? (SEWilco 18:45, 26 October 2007 (UTC))

I think the editors I know usualy add Geoboxes to where there have been no Infoboxes before. The problem with Whatlinkshere is it generates an unordered list. Or are there any additional parameters to the whatlinkshere call that can make the list be generated is some (alphabetically) ordered form? – Caroig (talk) 18:50, 26 October 2007 (UTC)

Nope, I am converting almost all our projects from infobox to geobox. But, 80% of our articles don't have an infobox at all, they are blank (for now). I no longer see the use of infobox, but that is just me. To get back on track, I don't like using whatlinkshere at all. As I am working through the articles, I like to be able to click on a category down at the bottom, and I can monitor what everyone in the project is adding the geobox too. Just for Illinois, and don't have to worry about the other states or nations.--Kranar drogin 22:00, 26 October 2007 (UTC)

Well, if you do, then I might set up the Geoboxer tool to ease your work (it's a tool that can convert the old Geoboxe to new ones, other Infoboxes to Geoboxes or even fetch data from other language Wikipedias and set up new Geoboxes). Just if you would send me the corresponding Infobox > Geobox fields and possible what other fixes the tool should make. The Geoboxer can also be set up to apply various fixes based on the object type or the state it lies in, e.g. the tool can add the calibrated map and turn on USA and Illinois flag display to any Illinois Geobox it is invoked in. As I wrote in my previous post, I don't think the auto-categorization should be removed until we figure out a way how to satisfy both sides. If anyone's using it it has right to exist. There will be a way how to tell the template to keep the auto-categorization should anyone wish it e.g. for all Geoboxes on Illionois. By default, this feature will be off. The category name should be without the geobox word, any idea? The template might (as it does now) create the category names automaticaly or it might enable you to choose what the auto-category name for Illinois Settlemnt, Illionois River etc. should be. What sounds better? – Caroig (talk) 22:24, 26 October 2007 (UTC)

If the existing city categories are not being used for conversion, Geobox could emit the same categories which are already in use for those cities and states. (SEWilco 00:55, 27 October 2007 (UTC))

That would be fine by me too. --Francis Schonken 01:04, 27 October 2007 (UTC)

Geoboxer tool? Please run it through Wikipedia:Bots/Requests for approval, if you haven't done so yet. --Francis Schonken 22:37, 26 October 2007 (UTC)

That's enough. It is described on the appropriate Geobox page what the tool is, what it does and how it operates. It has nothing to do with a bot. – Caroig (talk) 22:47, 26 October 2007 (UTC)

The semi-automated tool described in Template:Geobox/legend#Geobox 1.0 > Geobox 2.0 conversion apparently does more than is in the description there:

• it (...) can convert (...) Infoboxes to Geoboxes (not in the tool description)
• it currently adds categories irrespective whether these categories exist or not (not in the tool description) - this is the issue being discussed here. As long as that is an issue under discussion it's simple courtesy not to deploy a semi-automated tool that increases speed with which a disputed feature is introduced in main namespace.

on both accounts: please get approval to run such (semi-)bot. — or, put otherwise, why can't I find a "caution" section, warning about possibly controversial aspects when running the semi-automated tool, in the tool description, like for instance Cyde's "Ref converter" (a tool with a similar modus operandi) has (User:Cyde/Ref converter#Caution)? --Francis Schonken 00:09, 27 October 2007 (UTC)

From the description of the Geoboxer tool, it looked to me like a script which individual users run to manipulate their own edits and not a single user's bot. (SEWilco 00:55, 27 October 2007 (UTC))

Yes, like Cyde's "Ref converter" (see my comments above on "caution" section). --Another script is WikEd. 01:02, 27 October 2007 (UTC)

Exactly as SEWilco says, it's just a script that helps the editor manipulate their own edits. The tool doesn't add any cotegories, that's what the Geobox template does. Some low-speed user assistance programs (e.g. Auto Wiki Browser in normal operation mode) are not considered "bots". I urge Francis Schonken to always carefully read about a problem before he or she makes any further allegations. The ones made at Wikipedia:Village pump (policy)#Question were just over the top, false and rude. – Caroig (talk) 06:44, 27 October 2007 (UTC)

[edit] Request for Comments

This template is a versatile infobox which can be used for describing any geographical feature in a unified style with a lot of automation (automated locator dot placement, metric/imperial unit conversions …), see examples for a mountain range, a mountain, a valley, a river, a protected area, a settlement, a castle ruin, a bridge, a bell, it's being considered for [[User:Kranar drogin/Geobox race track|. The parameters/fields are named and the the values entered in such a way the data is easily parseble by any tool.

As there is just one template that can serve all these features, users requested a means that would help them organize their work. Thus I added automated category generation: every Geobox contained code that added [[Category:Geobox TYPE, COUNTRY or STATE]], i.e. a template called as {{Geobox | Settlement | … country = Slovakia … }} put the page into [[Category:Geobox Settlement, Slovakia]].

Some users appreciated this feature, some didn't like it, but their objections were of the "I don't think it's nice …" nature. User:Darwinek, one of them, placed a mere suggestion on my talk page: I think these categories shouldn't show up and another user wrote I am sure there is something in WP:MOS/WP:CAT. Just vague personal point of views. Unfortunately, instead of explaining his view, this user simply removed the piece of code responsible for category generation, which I reverted as no rationale was given for the deletion.

Following this, he moved to the Wikipedia:Village pump (policy)#Question (and possibly elswhere) where he made some absolutely false statements, repeatedly decribing the template as "User:Caroig's Geobox" which led to allegations I claimed ownership of this template (I created it and do most changes to it), other sentences that had never been written anywhere were attributed to me and there were many other accusations that had nothing to do with the topic being discussed. We were said to be unwilling to coopearte, while no-one of the Geobox editors/users knew this discussion was taking place, those who were objecting were unable to state clearly what they saw as the problem and only started to discuss the issue after I had requested it countless times. There it was finally made clear what the major objection was and was the word Geobox in the category title. It was accepted and I wrote I wanted to work on a solution that would satisfy all users. My major objection here is very unfair behavior of some editors and their unwillingness to discuss the issue.

In the meantime the categories were put to Categories for discussion page where most users were supporting keeping the categories, some expressed their objection to just blind application of policies and guidelines and some wanted to delete them based on their strict interpretation. After a few days the discussion, obviusly still running, but without any conclusion, was closed and the categories deleted, the major rationale being the categories were "breaching policies and guidelines". What I object is the discussion was closed and conclusion made by a single user's personal decision, while there were clearly expressed reasons why this categorization was helpful to both readers and editors. It was stated that if there are four technical categories like "Articles missing references since October 2007" it was acceptable (not because of common sense, but beacuse there was a notice about these categories in a wiki guideline, which also contained sentence these categories should "… not necessarily be deleted as they serve their purpose here on Wikipedia …" which might well be appplied on Geobox categories). I believe if I carefully read all guidelines and policies I would find enough references saying the Geobox categories are acceptable, given they help, they are actively used by editors who add valuable, encyclopaedic data to Wikipedia. I still prefer to apply just common sense here. Even the words "breach of policies and guidelines" suggest these categories were some terrible crime while the only thing they did was adding one more, for many users useful, category which is just an aid for both readers and creators.

I seek help and advice. Should I complain someplace about those users' approach? Is Wikipedia driven by strict interpreation of guidelines and policies and WP:IGNORE and WP:SENSE don't apply any more? I would like to somehow recreate these categories, taking into account all objections and suggestions. Yet I fear the same users will delete them immediately beacuse of WP:XX, WP:YY and WP:ZZ while the merit of the thing won't be discussed at all. Possibly, if the categories hadn't been deleted before any consesus could have been reached there might have already been a solution. I prefer to find a peaceful resolution, without any furher complaints or the need to seek arbitration, so that everyone can peacufully do what they believe helps Wikipedia best. – Caroig (talk) 22:14, 6 November 2007 (UTC)

I'm not familiar with this Geobox, but it sounds like a good idea. Spamming Geobox categories, maybe not so good. That just sounds messy. Can you use the "What Links Here" feature to track the Geoboxes? Instead of categories, can those who primarily benefit from the Geobox use their watchlists, or sections of their userpages? Can I be Frank? ^{(Talk to me!)} 02:49, 9 November 2007 (UTC)

I think using the word "Geobox" being in the categories seemed to many people like irrelevant advertising. If the purpose of that word was to force the categories in a separate namespace to avoid collisions, a neutral phrase such as "Articles about" could have worked (but that would split such entries from existing categories and would only be accepted if there was a known need such as a planned transition). Another problem is that there are naming exceptions which may require manually created categories, such as using "Article Name" for state,city category but that fails for Chicago. Someone could examine the existing relevant categories and see if it is desired that those be automatically added, but discussion probably should take place within the existing relevant conventions. Wikipedia:Naming conventions (categories) is about all categories, but geoboxes straddle conventions such as Wikipedia:Naming conventions (places) and Wikipedia:Naming conventions (settlements). (SEWilco 16:20, 9 November 2007 (UTC))

All the objections were OK, just they could have been stated clearly at the beginning (by those who objected to them). Your comments, SEWilco's were real helpful. The naming scheme was bad because:

• The names of those auto categories were not very helpful to uninvolved reader
• The scheme created too many "red-linked" categories which had to be set-up manually
• The names didn't follow the recommended category naming guidilines

The Geobox existed long time without any categories whatsoever as for a long time there were various templates (Geobox Mounatin Range, Geobox Settlement, Geobox River) which could be watched by using "What Links Here". With the current Geobox version where there's just one single template which handles all geography related features, this can't be used to track the sub-types any more. Besides, users don't find this features particularly useful.

I've been thinking about how to tackle the issue taking into account all objections and suggestions. My proposal is this:

• Unless country/state/type specific category is defined (see the second point) all articlesusing the Geobox template will be placed into a category which would, under the dismissed naming scheme, correspond to Geobox Settlement, Geobox River etc. I'm not sure how to name these, any suggestions are welcome, some of mine:

• Rivers with Geobox - probably not, the Geobox name should probably not appear in the category name, but it was one of suggestions in the previous debates
• Rivers with geodata - neither this is good, geodata has no clear meaning though we might want to start a Wikiproject focused on standardizing Infobox template field names

• Prior to setting the above category the template would test existence of a country/state/type specific categorization template (under a standardized name such as Template:Geobox category/Settlement/Illinois or Template:Geobox category/Illinois), if it existed, the default category wouldn't be set, the appropriate template would be called and it would handle setting the category. I might explain this on Slovakia: the settlements there either have a Geobox or don't have any Infobox and usually put into the Category:Cities and towns in Slovakia. While the process is running, the Template:Geobox category/Settlement/Slovakia would put all settlements into say Category:Settlements in Slovakia with geodata or divide them according to the category field to more specific Category:Cities in Slovakia with geodata, Category:Villages in Slovakia with geodata etc. After the process is over and all settlements in Slovakia have a Geobox, we would change the Template:Geobox category/Settlement/Slovakia to create just Category:Cities in Slovakia etc. which bwould be listed under some higher Geobox categories?
• Would something like this be acceptable? – Caroig (talk) 18:39, 10 November 2007 (UTC)

[edit] News as of 2007-11-11

Geobox news: 2007-11-11

Irregular newsletter on the lastest news, changes and bugfixes for the Geobox template

There's only one change to announce and it is categorization again, hope there will be decent discussion this time. I've tried to address the major problems the first auto-categorization scheme was causing. In the new version, unless further specified, all pages are automatically put to TYPEs articles with geodata, there's just a limited list of these and they were (hopefully) all set up manually so there should be no more red linked categories. Users can set up a different categorization scheme for their project in two ways.

• If they add their country or state to appropriate Template:Geobox category/type template (NB the lower case after the slash), Category:TYPEs in COUNTRY with geodata will be created, the category must be set up manually, of course.
• They can completely override the category names by creating Template:Geobox category/type/Country (example: Template:Geobox category/settlement/Slovakia). This template then takes over assigning appropriate categories or "categorize" the article in any other way. This way temporary categories might be set up during any transition project and when e.g. all settlements in the given area have been added a Geobox, these categories might be changed into any usual names. Slovakia might be given as an example, most smaller settlements don't have yet any Geobox, so while this is being worked on, the auto-categories are set to: "Villages in Slovakia with geodata", "Towns in Slovakia with geodata" and "Cities in Slovakia with geodata". When all Slovak settlements have been "geoboxed", these auto-categories might be switched to jut "Villages in Slovakia", "Towns in Slovakia" and "Cities in Slovakia" by a mere update of the Template:Geobox category/settlement/Slovakia template. This template is handed over both the Geobox type amnd the category field which can be used to further differentiate various categories. I've set up more detailed categories for Slovakia, the Czech Republic and Illinois where Geoboxes are being systematically added.

Any feedback is appreciated, if you object to anything of the new scheme please state clearly where you see the problem. There seem to be some time lag before the articles are put into appropriate categories, saving the page forces the category creation too. I hope the supercategories will be allowed to live, they're useful, the rest of the system is by default off and it can be set up to put the articles into any sort of existing categories automaticaly. – Caroig (talk) 16:04, 11 November 2007 (UTC)

I think this is great. The only thing of it is, is that I don't think they are all being put into their proper categories. I tried to do a new category for unincorporated communities under Category:Settlements in Illinois with geodata, but I don't think it took with say like Chana, Illinois. Any input on this would be great. Thanks.--Kranar drogin 22:47, 11 November 2007 (UTC)

The texts to the left of the equal signs in Template:Geobox category/settlement/Illinois need to be in lowercase; Chana, Illinois (and probably other, found one) locations have an extra space before the closing square brackets in the category field, I fixed those two. – Caroig (talk) 22:56, 11 November 2007 (UTC)

[edit] Support for 8 Free Fields

I love this box. I hope I didn't screw it up but I increased support for 8 free fields (it probably wouldn't hurt to extend it to 12!). I have applied it to a canal at Shinnecock Canal and a factory Kansas City Assembly. I am probably going to apply it to some shipping terminals also. Thanks. Americasroof (talk) 11:40, 27 November 2007 (UTC)

Well, there's no problem with it, but it's preferable to place the data into specific fields because the data can be then easily parsed for any purpose. As for Shinnecock Canal, apart from the lock dimensions there are appropriate fields where the data can go. The free fields are primarily for such data which is too specific for a given location and can't be easily put into a unique database field. – Caroig (talk) 14:21, 27 November 2007 (UTC)

Thanks for the quick response and fixing the Shinnecock article to demonstrate. Now that I see that I will throw it at some other higher profile canals/inlets/straits. Also, I will probably throw it at a neighborhood as soon as I can get a locator map for NYC. We probably need to improve the documentation and have a few more examples. Thanks this really is the template to end all templates! Americasroof (talk) 14:47, 27 November 2007 (UTC)

What you suggest would be excellent. It would be good if you tried the template on a couple of canals/inlets/straits and create an example page for other users to make clear what fields and how they should be used. And as for improving the documentation that would be immense help as the documenation is far from perfect, written from a point of view of a creator of the template, not a user, so comments from someone "new" would be priceless.

The idea of the Geoboxes is to enter the data in a

• uniform way - i.e. the same piece of information should always go to the same field, in the same format
• the values should be raw data, rid of any formatting, comments or html tags, this should all be done thru the various additional fields (_type, _note …) – Caroig (talk) 20:58, 27 November 2007 (UTC)

[edit] Website Functionality Broken?

The website functionality appears broke (as can be seen on Kansas City Assembly. Thanks. Americasroof (talk) 12:40, 27 November 2007 (UTC)

The problem was in the format of the website address, no parameter value in any template (not just Geobox) can contain the equal sign, it must be entered as a HTML entity. Fixed. – Caroig (talk) 13:41, 27 November 2007 (UTC)

Thanks. Figures right out of the box I had to pick a whacky URL. Americasroof (talk) 14:50, 27 November 2007 (UTC)

[edit] Request for Free Form Dimensions

If it is possible I would like the ability to override the dimensions. For instance in my canal example I wanted to change the length to feet but could not figure out through the documentation how to do that. It can default one way but if you want to override you should be able to do so. Likewise when the building type was selected it would not let me describe the total area in acres. Americasroof (talk) 12:40, 27 November 2007 (UTC)

Actualy, you can override any dimension field by adding appropriate _unit field. If you want to override the length field to ft, just add length_unit = ft (this setting would aaply on length1, length2 etc. too, these can be also re-overriden by specific length1_unit, length2_unit fields). – Caroig (talk) 14:25, 27 November 2007 (UTC)

Thanks again! Americasroof (talk) 14:50, 27 November 2007 (UTC)

[edit] help with conversion?

I tried to move from "Geobox River" to "Geobox|River" on the Columbia River page, but two of the parameters were messed up. I tried to find the problem but am stumped. Can anybody shed any light on this? Check this diff. Thanks! -Pete (talk) 19:46, 29 November 2007 (UTC)

[edit] Location map

The location map does not appear to be working correctly or the wrong map was used at the article on Uluru. That article uses Geobox|mountain. Could someone look into this? —MJCdetroit 17:25, 3 December 2007 (UTC)

Fixed. Took some time to track that down. I introduced this bug myself some time ago when extending the functionality of the locator dot placement part of the code. Instead of lat_NS, there was lat_EW. Thanks for pointing that out. – Caroig (talk) 21:24, 4 December 2007 (UTC)

You're welcome. It looks like that particular problem within that particular article may have been like for a very longtime anyway. —MJCdetroit (talk) 02:26, 5 December 2007 (UTC)

[edit] ifexist issues

Several geo templates are mentioned in the first subsection of Wikipedia:Village_pump_(technical)#.23ifexist_limit -- SEWilco 17:32, 3 December 2007 (UTC)

Thanks a lot for this info. I fail to see any rationale for this limitation on the discussion page, unfortunately.

The old Geoboxes should be replaced with the new single Geobox. Nonetheess, even it will get affected, sometimes. It depends on the contents, all subtemplates are only invoked when needed so that the three parameters (Pre-expand include size,

Post-expand include size and Template argument size) are kept as low as possible. Let's hope the promised upgrade of the code will take place soon. If not, some functionality will haev to be stripped or removed completely. That seem to be the current trend on Wikipedia, create more and more unnecessary obstructions instead of helping the project. – Caroig (talk) 21:41, 4 December 2007 (UTC)

Unfortunately, I am not able to understand much from that discussion page. But geoboxes are absolutely awesome as they are now and I really hope the announced change will not limit their functionality. Can the template be somehow fixed in order not to be affected by this new change? At Village pump, Gracenotes said: 'right, many of the problems here come from convenient "autolinking", something like {{#ifexist:{{{param}}}|[[{{{param}}}]]|{{{param}}}}}}. This can be fixed by making the parameter itself a link.' I do not know what it exactly means, but would it help anyhow? Good luck. Tankred (talk) 02:57, 5 December 2007 (UTC)

I think it just means removing the ifexist code from the template (i.e. destroying the autolinking funcitonality), and linking each parameter every time the template is called. Not very helpful, particularly if there are already many instances of Geobox in existence which assume automatic linking. Maybe the technical people can be persuaded to modify their plans so that established templates like this one are not subject to the limit (or to raise the limit at least high enough not to affect these templates).--Kotniski (talk) 09:37, 5 December 2007 (UTC)

Yeah, the problem is in the autolinking feature which isn't a necessary feature of the template but it's as Tankred says convenient, expecially for newbie editors. The parameters can be made wikilinks even now, the template accepts both. Actually, quite a lot of pages assume this functinality so a lot of updates would have to be made. Anyway, I've updated the code so that we always get well below the 100 links limit, hopefully. Technically, the #ifexist function is not invoked directly but thru another subtemplate which is only called when a parameter exists so the #ifexist function is not called for nonexistent values thus greatly reducing the number of the #ifexist calls. It might mean a bit longer execution time. Hope it won't create any further problems and that I haven't introduced any bugs (I nearly always do when doing paste/copy/replace all changes). So please kick me if anything's broken. – Caroig (talk) 20:21, 5 December 2007 (UTC)

Addendum. There are still thousands of pages using the old Geobox templates ({{Geobox River}}, {{Geobox Mountain Range}} etc.). These will get affected by the #ifexist limit much harder. All these templates can be easily upgraded to Geobox v2 by replacing the template call, e.g. {{Geobox River to {{Geobox | River. The parameters are 100% compatible; if some parameters were renamed the v2 template support the old ones for backward compatibility too. Fixing the old templates would be too complicated and besides it's recommended to upgrade, the new templates have much more features and are much easier to upgrade. So if anyone can give a hand replace the template calls (with AWB it's pretty simple) ... it would be great. – Caroig (talk) 20:21, 5 December 2007 (UTC)

I should be able to do it over the weekend. Just a technical question: The only thing I need to replace by AWB in those templates is {{Geobox River by {{Geobox | River (the same for bridge, mountain range, etc.)? Or are there any other differences between the two templates? Any non-compatible fields? I did not use the old templates, so I am not extremely familiar with them. Tankred (talk) 21:49, 5 December 2007 (UTC)

Exactly, you only need to add the pipe between the words Geobox and River (or anything else). Some fields have different names but this shouldn't be a problem as the new Geobox accepts all the old ones for backward compatibility. There are no other changes, just some fields get displayed in a bit different order. But the conversions, units, maps, everything is unchanged. I should have done this conversion myself long time ago ... Unfortunatelly, there are over 5000 Geobox Rivers, over 1000 Geobox Settlements and usually hundreds of other types. I'm real snowed under these days. Thanks a lot indeed.– Caroig (talk) 22:37, 5 December 2007 (UTC)

It seems the new version of AWB is a bit bugged, so I will have to wait until they fix it. Maybe not this weekend, but I will definitely start to convert these templates soon. Tankred (talk) 05:20, 8 December 2007 (UTC)

[edit] Autolinking too many fields causes problems

Why is the default set to autolink names such as mayor? For many places there will never be an article on the mayor resulting in a useless redlink while in other cases the link will be to a disambiguation page. Is there at least an option to turn off autolinking? For example in Souderton, Pennsylvania, the mayor's name is John Reynolds, which is a disambiguation page. While I couldn't say for certain, but I'd consider it extremely unlikely that there will be an encyclopedia article on the mayor unless he later seeks some higher office (in which case he'd no longer be the mayor and the link would be useless for the infobox). older ≠ wiser 03:23, 30 December 2007 (UTC)

I came here to raise the same issue. In this case North Wales, Pennsylvania links to Douglas Ross, but both that and Douglas T. Ross are other people, and the alternate, Doug Ross is an ER (TV series) character. It seems like the only way to make sure the infobox can link to the correct target article, if there even should be one, is to set the link in the article, and not autolink via the infobox. Shawis (talk) 05:58, 28 February 2008 (UTC)

Well, I figured out a kludgy way to de-link the names in these two articles, but I still think the template should be changed because the same problem probably still exists in plenty of other articles. Shawis (talk) 07:01, 28 February 2008 (UTC)

[edit] formations

Should there be a geobox for geological formations? There's a few volcano articles that arn't considered actual mountain ranges but a geological formation, such as the Cascade Volcanic Arc, Anahim Volcanic Belt and the Trans-Mexican Volcanic Belt. Black Tusk 03:23, 15 January 2008 (UTC)

[edit] Ascended by in Geobox/type/mountain

The phrase must be ascended by, not "ascented by." Ascent is a noun (a long ascent). The verb is to ascend and the passive is, therefore, was ascended by. Saying ascented by (as someone entered it in Geobox/type/mountain) was like using the noun pretense to say "was pretensed by" instead of was pretended by. ilmari (talk) 05:11, 13 March 2008 (UTC)

[edit] iucn category

How do you get the iucn_category to display on the protected area geobox? A value is set in the sandbox example but I can't see it displayed. Bleakcomb (talk) 00:22, 14 March 2008 (UTC)

Mmmmm. I shouldn't have looked. The blank template page for Protected Area lists a iucn_category parameter. Values for this parameter don't display. If you use a category_iucn parameter (note reversed word order), values don't display either. If you use the iucn_category parameter with any non-empty value and a category_iucn parameter with the real value, it is displayed in the box. If the iucn_category parameter is present and empty value, nothing is displayed. Bleakcomb (talk) 00:54, 14 March 2008 (UTC)

I think I see the problem in the template code. An if statement looks at the param iucn_category and then uses the value of category_iucn. I am way too chicken to change it, though. Bleakcomb (talk) 01:35, 14 March 2008 (UTC)

I fixed the template. I standardized on category_iucn to be consistent with other parameters.Brian Powell (talk) 04:37, 2 April 2008 (UTC)

Thanks Brian! Bleakcomb (talk) 05:03, 2 April 2008 (UTC)

[edit] Question

Why does the Geobox for a River have the name then the word 'River' underneath. As evidenced in the article River Severn, it is redundant and looks a bit random. I could only see that the field should just be 'Severn' then it would say 'Severn' *translations* 'River', but in British English most rivers have the word River at the start. This is a purely cosmetic thing of course, but I was just wondering if there's any way to make the redundant 'River' below go away. Thanks, Asdfasdf1231234 (talk) 22:08, 29 March 2008 (UTC)

I had the same concern with mountain ranges (see Native name spacing section above). I think it it redundant for most mountain ranges. I think there should be a parameter added that controls whether this line is automatically added. RedWolf (talk) 16:23, 30 March 2008 (UTC)

• You could use "category=&nbsp;" to remove the word displayed but it will still create a blank table row which is still not ideal. RedWolf (talk) 20:55, 12 April 2008 (UTC)

[edit] Dams

Has there been any thought given to creating a Geobox variant for dams that should be used instead of Template:Infobox dam? The existing infobox is rather limited and it would be nice to harness the features of the Geoboxes. I'm thiking the Geobox dam-variant would be closely related to the reservoir variant, just adding some fields related to the dam itself.Brian Powell (talk) 04:19, 31 March 2008 (UTC)

[edit] Topo Maps?

Template:Infobox Mountain has a field for storing the topographic map that includes a mountain. It'd be nice if the Geobox had this functionality. Should this be added as an actual new field or just done as a free field? Brian Powell (talk) 02:42, 13 April 2008 (UTC)

I added a new set of topo_ fields for tracking the maps. They're documented in the Geobox legend. Brian Powell (talk) 07:00, 20 April 2008 (UTC)

[edit] Formatting names in coordinates

As an example, if you go to Hammocks Beach State Park then select either the coordinate at the top right or in the info box, note that on the coordinates page at the top, it shows:

 Title: Hammocks_Beach_State_Park

The underscores play havoc with several map sites that use the GeoTemplate {Title} parameter. The coord template provides a way to specify the space delimited name as a "Name=" parameter that is consumed by GeoTemplate (see Bellevue Botanical Garden). Several other templates will automatically drop the article title into this parameter to get rid of the underscores. Would it be possible for someone to do that for this template? —Preceding unsigned comment added by Heptazane (talk • contribs) 16:48, 22 April 2008 (UTC)

[edit] Update to flag handling template

I have just updated Template:Geobox2 list flag to fix a limitation in the previous version. The problem is that the template used to generate wikicode of the form {{flagicon|XX}} [[XX]], but this scheme did not handle disambiguation article targets. For example, consider the following:

{{Geobox|City
|country = Georgia (country)
|state = Georgia (U.S. state)
|country_flag = true
|state_flag = true
}}

It would be nice to show [[Georgia (country)|Georgia]] and [[Georgia (U.S. state)|Georgia]] respectively, but using those parameters for country and state caused the calls to {{flagicon}} to fail. The solution is to use {{flagcountry}}, which produces both the flag icon and the wikilink, but is smart enough to generate the right display text. I have tested my fix, but not looked at the thousands of involved articles. Please let me know if I broke something. — Andrwsc (talk · contribs) 00:21, 3 June 2008 (UTC)