Template talk:Infobox City/Archive 4

From Wikipedia, the free encyclopedia

Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents

Red dot on blank map

Some infoboxes have started to use a generic blank map with a superimposed red dot to show the location of a city, circumventing the need for location map images for every city. Over on the German wiki, someone has come up with a neat way to achieve this, a way that I have not seen on the English wiki. The template de:Vorlage:Infobox Ort in Deutschland makes use of a standard blank map of Germany and requires only the city's geographical co-ordinates to present the final map. This is achieved by an internal template which performs all the necessary calculations to place the dot in the right place. Pretty clever, I thought.

I have put up an English version of this infobox at {{Infobox German Location}}, which also refers to this internal template, known as {{Lageplan}} (directly copied from the German wiki). The reason for a separate infobox for German cities comes from the desire to directly import infobox data from entries on the German wiki (which is why most variables still have German names) - but I have added a few extra features and changed the appearance to something more like Infobox City. For example, see Cologne.

Perhaps something like this could be used in this infobox. For this, the user would need to pick a map from a set of default images. And the Lageplan template would need to be generalised. Worth a thought. - 52 Pickup 18:49, 6 January 2007 (UTC)

But what about if you want to color/highlight in the region where the city is located? El Greco 20:47, 6 January 2007 (UTC)
Unfortunately, that doesn't work. So this probably won't be possible for most cities in US/Canada, for which many segmented maps have been made. But for locations in other countries, this could save a lot of work. - 52 Pickup 21:13, 6 January 2007 (UTC)
I tried something like this in Infobox:City, but it kept getting reverted by people who weren't interested in learning how it worked. It is hanging on in places like Groveland, New York which don't use Infobox:City. It is implemented in Template:GBNewYorkState. PAR 21:27, 6 January 2007 (UTC)
There's also a thread on this at http://en.wikipedia.org/wiki/Template_talk:Infobox_City/Archive_2#Pin_coords_parameter. -- Rick Block (talk)
Where do you get the map, to use for the red dot? Cause some of the maps, I've seen look very nice. Take Paris or Alexandria for example. I might be interested in a better map of Greece, to use for some Greek cities which is why I'm asking. El Greco 18:01, 7 January 2007 (UTC)
The best place to find such maps would have to be the Commons - then you would need to do a few calculations to calibrate the map to suit the co-ordinate range involved. For Greek locations, someone has taken the Lageplan template and applied it to {{Infobox Town GR}}. For example, see Heraklion. It's a shame that this approach had previously been reverted for this template, perhaps now is a good time to retry it. - 52 Pickup 13:47, 8 January 2007 (UTC)
Thanks for the assistance, 52 Pickup. El Greco 18:20, 10 January 2007 (UTC)
Once you have a map, you then need to come up with the mathematical equation that corresponds the geographical co-ordinates to the location on the map (in terms of a 0-100% scale in each direction). This is the tricky part. - 52 Pickup 08:25, 11 January 2007 (UTC)

flag and seal captions

The flag image appears to have automatic text caption of the form "Flag of {the page name}", even if the image exists and has a different title. What is the purpose of this bit of text? Same for the seal. First noticed on Providence, Rhode Island, but it appears to be consistent(ly weird) on many pages. DMacks 20:00, 22 January 2007 (UTC)

This issue was first brought up in October in the Some issues heading above. I think (but I'm not positive) that the links were placed in there to encourage editors to create articles about the flags and seals if there was not an article present. The problem that you touched on gets even weirder when the official name is not the common name (i.e. City of New York, City of Toronto). I would not be opposed to just removing those links all together. —MJCdetroit 20:49, 22 January 2007 (UTC)
I finally fixed this quirk. Unless the following fields have values (i.e. some other wikipage) filled in then the caption will not be linked. This is not an automatic link it must be filled in manually.
|flag_link=
|shield_link=
|logo_link=
|seal_link=
See Toronto for an example. —MJCdetroit 01:32, 27 February 2007 (UTC)

Automatic Unit Conversion

Just so everyone is aware, the concept of adding automatic unit conversion from metric to imperial has been proposed as a feature request for the wikimedia software. The feature discussion would benefit from participation. Alan.ca 12:57, 23 January 2007 (UTC)

This has been used on other templates like Template:Infobox Former Country very well. However, as I explained on Alan.ca's talk page, it maybe a lot of work to implement. We'll just have to weigh out how much work it would be and then decide if it is worth it. —MJCdetroit 16:20, 23 January 2007 (UTC)
  • As an initial step to automatic conversion, I implemented a population_footnotes field to separate the footnotes from the population values. Check out {{Infobox City}} and let me know what you think. I implemented the change in the Hamilton, Ontario article. Alan.ca 12:07, 23 January 2007 (UTC)
Yes, there already is an automatic conversion for this exact thing and it works very well with a new template. It has been very successful over at Template:Infobox_Former_Country. The problem with infobox city is that it is an old and very used template. In order for this to work you would need to have the fields (in this case km2) entered in without any puncuation, no commas, no spaces, nothing. Some of the U.S. Cities have sq miles entered in before the square kilometers; i.e. this is on one line, in one field total area. If everything is not perfect, then you will get an error expression. Also, the numbers in the fields would be automatically formatted with a comma every three spaces and some people prefer a space and visa-versa. Due to the amount of pages that use infobox city template, changing the total area field to no punctuation and only km2 may be more work than it is worth, but it is worth a look. —MJCdetroit 15:47, 23 January 2007 (UTC)
Follow-Up: There are about 3,500 pages that use the infobox city template. If a small group of editors were to prep all those pages, then the the automatic conversion could be installed very easily. By prep, I mean removing any punctuation or superscripts or anything that is not numbers from the desired field. For example if total_area= 11,000 then it would have to be changed to 11000. Editor comments seem to be OK. It is not the template but the prep work itself that would be the hard work. I don't know if AWB would be helpful in this either. I would probably take 30-40 second per page. I think in the long-run auto-conversion would be the best way to go. —MJCdetroit 21:30, 23 January 2007 (UTC)
Ultimately we would modify the template to only do the calculation if the corresponding unit field was empty while the other was provided. However, I'm not certain if there is anyway to check that the input is valid before rendering a conversion. Possibly there is a way to test that the conversion is correct before displaying it. This would allow us to provide nothing in the space if the conversion was unsuccessful. Alan.ca 22:12, 23 January 2007 (UTC)
I've started the slow process of changing the pages to accommodate automatic unit conversion. This involves removing any commas, spaces, and references from certain fields. For example, in some cities, square miles and square kilometers are listed on the same line (diff) and because it is the field intended for square kilometers the square miles were removed. Auto-conversion will put the square miles back in at a later date. If someone wants square miles (or density/sq mi) added back in before then they can enter them into the appropriate sq_mi fields. There's about 2,700 pages to check so some help would be great. —MJCdetroit 03:22, 27 January 2007 (UTC)
Please stop! This is not appropriate to remove English measurements in preference for metric and force someone else to clean up your mess. Removing conversion is against policy, is unfriendly and reduces the usefulness of articles. If it is worth doing, do it right. So it is right now and in the future. Don't create more problems for others to fix. Rmhermen 01:00, 12 February 2007 (UTC)
Rarely, have I removed any English/Imperial measurements that I did not put back in their correct fields (i.e. Total_area_sq_mi, Elevation_ft, etc). Here are a few examples: example example2 Example 3. If I did remove anything there was a reason for that and in about a week that won't matter because all pages will have both measurement systems displayed and you RmHermen will even be able to swap the unit order if you wish. I have editted close to 2,000 articles and have 800 left to do. At the rate that I am going, I will be done in about 4 days. Do you think you can wait that long? If you can't, and you have a metric only page, then read my instructions above and place the units back into the correct fields. I would have been done by now if AWB had a Macintosh version...P.S. As for preference...as my user page notes, I happen to prefer English measurements over metric.—MJCdetroit 05:32, 12 February 2007 (UTC)
OK, all the pages using this template (Infobox City) have been prepared for this so it should be a smooth transition.MJCdetroit 03:32, 18 February 2007 (UTC)

How it works

Calculations

For the area, population density and elevation fields, values can be converted and even placed in an order. For example many pages only have the metric values entered, automatic conversion will calculate the corresponding imperial values and display them in the infobox. The reverse is also true. Many U.S. pages only have the imperial values entered, automatic conversion will calculate the corresponding metric values and display them too. The calculations will work as long as the values are raw numbers only; no commas or spaces or reference tags. Editor notes (<!--Ed note:-->) are ok. The template will format the numbers displayed in the infobox. There are reference fields (area_footnotes & population_footnotes) if a reference is available; use the <ref name=>Your reference here </ref> tags. If both metric and imperial fields such as area_total =259 and TotalArea_sq_mi = 100 are filled in then both values will be displayed regardless if they are correct or not. This overrides the automatic conversion and can be helpful if the value is a range (see next section).

Elevation ranges

If one value in one of the elevation fields is entered correctly then automatic conversion will convert it and display it. However, if a range is entered such as elevation_ft= 33&ndash;330 '''or''' elevation_ft= 33-330 then automatic conversion will try to convert it but will either generate an Expression Error or will convert it incorrectly base on the - (minus sign). So in this example above:

elevation_ft= 33&ndash;330 will generate this error when trying to convert to meters:
(Expression error: Unrecognised punctuation character "&" m)
However: elevation_ft= 33-330 will generate a negative conversion:
33-330 ft (-67.6 m)

When an editor wants to display an elevation range for a city then they must enter the ranges in both the fields like this elevation =10&ndash;100 elevation_ft=33&ndash;330 . This will over-ride the automatic conversion and display the fields correctly in the infobox.

Unit order

Cities in the United States that have the United States (or some variation of the name) in the field subdivision_name=, will automatically have the unit order switched to imperial first then metric in parenthesis as suggested by 52 Pickup below . However, not all pages have the country name in the subdivision_name field (sometimes it was state name or county). Therefore, if a page is metric first and an editor would like imperial first then metric, they can add unit_pref=Imperial (or English, etc) and the units will flip-flop. Leaving unit_pref blank or entering Metric (or SI) will display the metric units first if the subdivision name is not United States.

I hope that was clear, but any question or errors happen this is the place to post 'em. —MJCdetroit 03:32, 18 February 2007 (UTC)

Location map

I have tried to use {{Location map}} in this template but have not been able to. Could someone correct this? --Eleassar my talk 16:06, 23 January 2007 (UTC)

Proposed changes to support the Location map template

Due to popular demand, I've prototyped some changes to this template to enable support for the {{Location map}} template. I've encapsulated the {{Location map}} template within the {{Infobox City}} template, and exposed two new parameters pushpin_map and pushpin_position which provide the map name and label position configuration for the location map, along with the existing mapsize, map_caption and latitude and longitude parameters of this template. You can see and test the prototype at {{Infobox City Maptest}}. An example of it in use is shown here: Template talk:Infobox City Maptest. The location map will only be displayed if the pushpin_map parameter is specified, and the existing image_map parameter continues to function as before. Please post your feedback here about these proposed changes... (Caniago 18:21, 23 January 2007 (UTC))

  • Does this feature really need to be part of this template, or should it be a separate template that is included inline by those who wish to use it? Not that I object to it, but it just seems this template is never ending as far as fields are concerned. Alan.ca 22:23, 23 January 2007 (UTC)
The main reason for including it as part of the city template is to avoid duplication and double entry of data fields - it uses the values from the existing latitude and longitude coordinate fields of the city template to position the pushpin, as well as the mapsize and map_caption fields. The customized city templates that people are creating to make use of the Location map template such as {{Infobox_Swiss_town}} and {{Infobox_London_place}} take the same approach. The alternative you suggest would still need the addition of at least one parameter to the city template, since the existing image_map parameter is not compatible with the approach {{Location map}} uses, and it would force users to double enter the latitude and longitude coordinate fields as mentioned. (Caniago 02:02, 24 January 2007 (UTC))
One thread above also asked about this feature. It would be great if the {{Location map}} template is supported, because it saves times to create a lot of city locator map images for thousands of cities. Otherwise, several projects chose their own city infoboxes, such as the {{Infobox India City}}, etc. — Indon (reply) — 09:13, 24 January 2007 (UTC)
As I am the one that asked about this feature above, I of course am waiting impatiently to see this implemented. My opinion is that many users already know how to use the {{location map}} so it would be most simple and convenient to just insert it in the image_map field and not to have to learn how to insert such data by using some new parameters. Of course, if someone uses this infobox a lot and doesn't know the {{location map}}, he would have more problems. However, let those that know it do this work. --Eleassar my talk 14:35, 24 January 2007 (UTC)
As I mention above, I don't believe it is possible to integrate it into the image_map field. Furthermore, as I also mentioned above I don't believe it is desirable. My proposed approach is identical to how {{location map}} is itegrated with other city infobox templates such as {{Infobox_Swiss_town}}, {{Infobox_London_place}} and {{Infobox India City}}. As far as simplicity is concerned, nothing could be more simple! With my changes, you need to specify only 1 parameter (pushpin_map - the name of the map) to get the location map to work - everything else is specified as part of the normal parameters of Infobox city. I think most people using Infobox city would not want to use two separate templates as you propose to get a simple map displayed. (Caniago 16:23, 24 January 2007 (UTC))
Ok, feel free to do as you like. Both ways are fine for me. --Eleassar my talk 16:38, 24 January 2007 (UTC)
The way you have set it up in the test template is very good. Nice and simple. The people who have worked on Location map have done very well in coming up with the right mathematical equations for each map (something i requested above, when i didn't know about location map).
For integration with image_map, perhaps you should first check for image_map, THEN go to the pushpin_map if no image_map is given. This should prevent disruption of currently used infoboxes. Using the {{Lageplan}} template, this is how {{Infobox German Location}} works (a separate template was needed for German locations, due to the need to transfer a lot of Germany-specific details from the DE-wiki). Lageplan has also been implemented at {{Infobox Town GR}} for Greek locations. I have tested Location map on the German infobox here and compared the two versions at User:52 Pickup/Drafts/Frankfurt. From the comparison, there are some other features of Location map that should be editable to make it suitable for this infobox instead of using Lageplan. The following list is from my post on the Location map talk-page, but has been copied here for completeness:
  • Border: Is there any way to turn off the image border? It is alright for some cases but, as you can see, not for this one
  • Error: Instead of shifting the dot off the edge of the map if the co-ordinate values are either not given or out of range, would it be neater to have some sort of error display? In Lageplan, a second map can be displayed (DE: Image:Missing Map of Germany.png, GR: Image:Prefectures Greece nocoord.png). So either the addition of a second error image or the overlaying of a question mark image would look better.
  • Dot size: (a minor issue) Can the size of the dot be adjustable?
  • Floating text: (another minor issue) Can the float text be modifiable? Also, Lageplan makes it possible for the dot to also have float text of its own
A final thing: Maybe you should not have the city name present on the map as well (i.e. blank the "label" field), but that's just me. - 52 Pickup 08:59, 25 January 2007 (UTC)
Based upon your feedback 52 Pickup, I've made two changes: (1) the border is no longer present around the map. I think the border should be contained in the map image itself if it is needed. (2) I've added an option to the pushpin_label_position parameter called none which allows you to turn off the label text. The options for pushpin_label_position are therefore left, right, top, bottom, none. Your other comments are more related to the features of the Location map template I think. I've therefore now added the pushpin map functionality to the Infobox City template. You can see an example of it in use here: Padang, Indonesia (Caniago 15:09, 25 January 2007 (UTC))

WP:CCT Project

Hi! We're discussing the best way we can add the Current City Time CCT to articles. One of our suggestions is to have a main site where the time would be purged and updated. I had a suggestions where it places a link to the category:UTC-1 or whatever the UTC is and then we could link those categories to the articles UTC-1, UTC+0, etc... Any other sugestions. --CyclePat 20:48, 25 January 2007 (UTC)

Whitespace

This template creates a white space in first line of articles, see Ahvaz for example. Anyone know how to fix this? Khoikhoi 06:33, 27 January 2007 (UTC)

I'm not seeing any difference in the position of the first line of text between articles that use this template and those that don't (at least not with monobook or classic skins using Safari). What skin/browser/OS are you using? -- Rick Block (talk) 22:06, 28 January 2007 (UTC)
Firefox in OS X. I noticed the whitespace again, but when I reverted CyclePat, it disappeared. To Pat: can you please make edits in a sandbox for now? Once they work, feel free to implement them. Thanks, Khoikhoi 08:59, 30 January 2007 (UTC)

Request for change in behavior of displayed units

I don't know if this is even possible or not, not knowing the internals of this thing, but I have a request: would it be possible to change the template so that either metric or non-metric units would appear first (say, total area), depending on which one was specified first? As it stands now, the default is to display metric units first. This is inappropriate for US cities, where US readers would normally expect to see areas displayed in square miles, not square kilometers.

Any chance of this happening? I understand it may not be technically possible, but it would be a nice amenity, as well as a recognition that the whole world doesn't measure in metric units. +ILike2BeAnonymous 05:05, 28 January 2007 (UTC)

I think some users are working on automatic unit conversion (discussed above), and if this is the case then I think it would be easy (and desired) to put the unit which is supplied first, and the auto conversion value second. --MattWright (talk) 05:54, 28 January 2007 (UTC)
I've created a set of templates that are used within Category:Geobox templates, the existing conversion templates are to be found at Category:Unit display. They automatically convert the figure into its metric/imperial counterpart and print all necessary links. The value from which the other one is calculated gets printed first. The only drawback is the input must be unformatted (i.e. without commas). Check it e.g. on the Vltava (metric values provided) and the Salem River (imperial values provided). – Caroig 09:03, 28 January 2007 (UTC)
To answer ILike2BeAnonymous' question: yes it is possible to swap the unit order. I provided an option for this at {{Infobox Weather}} by entering |metric first= yes. But first we'll take care of the conversion thing, then the order option. —MJCdetroit 16:15, 28 January 2007 (UTC)
Thanks. Glad to see the consensus seems to be that providing this flexibility in the template is a Good Thing. +ILike2BeAnonymous 21:33, 28 January 2007 (UTC)

CSS|XHTML: Size, Border and Background (Globally)

Hope a third time is a charm! I like to know if it's possible to globally change the width, border and background color of this template? I'm trying to match the border and background color to the city colors, and want to adjust the width of rows and columns, too. Doing so manually would be frightful to those who don't engage in web design. Is this template so hardcoded to not pass a simple style="" override?FResearcher 23:59, 29 January 2007 (UTC)

Based on your question at Wikipedia:Help desk I'm not sure I understand what you're trying do. First, are you talking about city articles at this wiki? If so, which ones? The point of the template is to provide a consistent look and feel to Wikipedia's city articles. If you're talking about articles at some other wiki, you can change the template to do whatever you'd like (and we might be able to help). Like I said at Wikipedia talk:Help desk, the background color and border should be fairly easy to change. The width is currently hardcoded in the template. Please provide some more details about what you're trying to do. -- Rick Block (talk) 02:12, 30 January 2007 (UTC)
My talk page has a living example. Want to replace the default gray color of the city box with the green border; green theader with white font of the tables below it. You can see there, long hand CSS is a mess just to substitute the basics. ADDED: If this city template would have more title/leader slots it would eliminate that whole commissioner/sheriff/coroner table. -- FResearcher 03:06, 30 January 2007 (UTC)
I'm still not sure I understand. Do you want to change the Augusta, Georgia article in this way? The additional table on your talk page is not in this article, so changing the Augusta article would make the table look different than the way it looks on the other 3500 or so articles that use it. I'm not saying this can't be done, I'm just trying to figure out what you're attempting to do. -- Rick Block (talk) 03:20, 30 January 2007 (UTC)
Correct me if I'm wrong, but I think he's saying a city in Kenya could have a different color scheme than a city in Chile. If there were a continent=asia parameter (or country=chile perhaps), then the CSS for the table could say <th class='infobox-city-asia'> and provide a different color scheme than <th class='infobox-city-north-america'>. -- SatyrTN (talk | contribs) 05:21, 30 January 2007 (UTC)
Sort of what what I was saying. It would be nice if we can have some custom color CSS options (green, blue, red, etc.,) so the box can be tailored to the city seals/flags, etc.. Doesn't have to be exact colors, just something close, with an option to change the background via a style override like this <class="infobox_drkgreen" style="background:#fff;">. CSS separates the presentation from the code, making it cleaner for non web designers to add/edit Wikis (none of the style code is shown in the rows, just content), and reduces page weight (length). Furthermore, the days we need to remain in programmer gray, let alone 16 safe colors ended when 16/24/32bit graphics came around 6 years ago, an eon in computing. --FResearcher 16:46, 30 January 2007 (UTC)
The style of the infobox matches the style of similar infoboxes for US states (template:US state, used in all state articles e.g. Georgia (U.S. state)) and countries (template:infobox country, used in nearly all country articles e.g. United States). This style is also used in a few other geographical infoboxes, as sort of a global "wikipedia" style (see Wikipedia:Geographical infoboxes). Adding the ability to change the "look" of this template for selected cities as you're suggesting goes in the other direction. I think this boils down to whether we want "article-specific" style or "site-wide" style. As the main proponent for Wikipedia:Geographical infoboxes (which I admit generated virtually no comments, and is currently labeled as "inactive"), I distinctly prefer "site-wide" to "article-specific". I'm willing to defer to a consensus for "article-specific", but I'm not seeing that (yet). -- Rick Block (talk) 04:35, 31 January 2007 (UTC)
Article wide or global, all I'm asking is the ability to edit the borders, background and width and not be depended on user css pages. The hardcode can stay as it is, just the CSS portion can have a manual CSS override. The default gray is depressing. --FResearcher 08:38, 3 February 2007 (UTC)
The background color is inherited from the CSS definition of infobox, defined in MediaWiki:Common.css. It's a site-wide default for all infoboxes. If you'd like this to be changed site-wide, I suggest you bring it up at MediaWiki talk:Common.css. Less globally, I'm not seeing anyone support your suggestion to make the background color of this infobox become a parameter. This is of course technically possible, but I would be personally opposed to adding such an option. My reasoning is that site-wide style parameters are meant to be site-wide, not customizable article by article. Similar reasoning applies the border style and the template width. -- Rick Block (talk) 17:37, 3 February 2007 (UTC)
As a more general question, though related, I was under the impression that wikipedia wouldn't let you put
<style type="CSS">.classhere {font-weight: bold;}</style>
in a page or template or anything. Is that true? -- SatyrTN (talk | contribs) 04:52, 31 January 2007 (UTC)
Right, you can't directly define a CSS style on a page (see Help:HTML in wikitext). You can define a CSS style in MediaWiki:Common.css or any of the skin-specific stylesheets (e.g. MediaWiki:Monobook.css) and then reference this style in a template or a page. The "infobox" and "infobox.geography" styles are both done this way (in common.css). If you're thinking about changes to these, please note that changes should be proposed on the respective talk pages first. -- Rick Block (talk) 05:17, 31 January 2007 (UTC)
Oppose, I like to see the same thing over the whole wikipedia. --Krm500 20:27, 3 February 2007 (UTC)

Problem with references

When you try to put a reference within the infobox, it doesn't work. Although it shows up in the references section, there is a mess of code in the infobox where the ref should be. For example, Federal Way, Washington. Any way to solve this problem? --Schzmo 00:37, 6 February 2007 (UTC)

I fixed it. Here's the real short version: One problem that I seen was too many "pipes". You only need them at the begining (preferred) or the end; not both. Also there is a special field for references. Compare the versions to see what I did. Thanks for letting us know.—MJCdetroit 01:01, 6 February 2007 (UTC)

Land area

Why does this template put emphasis for area on the metric system? It looks odd to see the area listed as kilometers, while miles is stuck in parentheses. Shouldn't there be an option to have it the other way around? TJ Spyke 09:30, 14 February 2007 (UTC)

There will be an option coming soon to change the order if desired. However, I think that I will leave metric as the default and yes I do know that there are more U.S. cities that use this template. —MJCdetroit 13:04, 14 February 2007 (UTC)
Why don't you set the template to first check what country the city is in, and then swap the values around if that country uses imperial units (US,UK)? This way, there is no option, giving all entries a uniform and logical appearance. - 52 Pickup 13:54, 14 February 2007 (UTC)
That's a good idea. TJ Spyke 06:54, 15 February 2007 (UTC)
  • However, Metric units are used in every nation in the world. This is an international encyclopedia and metric is clearly the more popular international unit. If a European is looking at two cities, one from Canada and one from the USA, it would seem to me that it would be sensible for the units to be formatted in a similar fashion. Alan.ca 07:59, 15 February 2007 (UTC)
    • It's not the standard here in the US, it would be like me going to an article about something in Europe and changing it from metric to imperial. The metric units would still be there (just in parenthesis). TJ Spyke 08:32, 15 February 2007 (UTC)

Bug - population

When there is no population as of parameter, footnotes are not shown. Rich Farmbrough, 10:35 14 February 2007 (GMT).

Can you provide a specific example? And are you talking about the population footnotes or the regular footnotes? —MJCdetroit 13:15, 14 February 2007 (UTC)

Option for manually corrected article links?

I have a problem with the image description of the seal of Athens since the template automatically uses input from the first parameter as part of the file name. Would it be possible to include a line to allow a manual input of the article name? One of the other infoboxes has this feature, but I can't remembed which one. If this is done, this possibility should exist for article names for both seals, flags and coats of arms. Valentinian T / C 00:21, 17 February 2007 (UTC)

Another version

Some time ago I created a geography related infobox framework with a few templates (e.g. Geobox River, Geobox Mountain Range) built from scratch. They have certain features such as consistent look, logically named fields, fully automated unit conversion, automated linking and also a version of automated location maps.

I've tried to design a template for Cities/Towns etc. using this system. Having been designed from cratch too it has somewhat more consistently named fields. However, for backward compatibility it also accepts (hopefully) all fields from the existing Infobox City template. So in most situations it can be applied simply by changing the template name to Geobox Town (or Geobox City, which is just an alias). I've started working on this template some time ago, in the meantime some of the issues it deals with have been solved in Infobox City independently too. More info at User:Caroig/Geobox_Town.

You can see the new template at Sandbox:Town. These are copied from existing pages using Infobox City, only the template name has been changed and commas from figures removed and when two values were present, either metric or imperial ones have been removed. If you're interested, you can try it out by simply changing the template name in any existing page (and possibly removing commas from all figures, which is being done on all pages anyway) and post any comments on Geobox Town. – Caroig 16:37, 18 February 2007 (UTC)

Maybe I am misunderstanding you but why would we need another version? We should try and have more of an effort toward using one standard template (this one) and start incorporating some of the smaller and not updated as much city templates into this one. Creating more templates seems like a move in the wrong direction.—MJCdetroit 17:38, 18 February 2007 (UTC)
The template is a part of an effort to unify all geography related infoboxes giving them the same look, same internal logic and consistent field names. Some time ago someone considerably changed the Infobox City template, returning some of the bugs that the previous version had solved, damaging the layout. As various users are adding additional fields they bring even more chaos (take the chaoticly named imperial versions of the fields). Infobox City was primarily designed for US cities, this template tries to be more universal, easier for a newbie user to fill out (e.g. by defining default labes for Country, Region etc. - no need to fill the type in).
The suggested template tries to bring logic into the field names, solves some issues on a more general level (not footnotes someplace but a consistent _note field for everything etc., universal unit conversion) and also tidies the layout which is similar to the existing one, just somewhat neater. It is fully backwards compatible with the Infobox City, accepting all its fields as aliases to the suggested ones. See further info at User:Caroig/Geobox_Town. My primary target are landscape-feature oriented infoboxes, but I've tried to help here too. – Caroig 00:30, 19 February 2007 (UTC)
Actually, Template:US City infobox was designed for US cities and was replaced with this template though a standardization process led by User:Harpchad (who fell off the face of the Earth shortly after); archived discussion here. His user page still has the list of templates that were to be consider for replacement.
I agree that we should probably tried to have better named fields; for example "total_area_km2" and not "area_total" and "sq_mi" on all the imperials and not "mi2". But naming aside, as long as they display properly and look nice...
What are some of the "bugs" that were re-introduced (hope I didn't do that)? —MJCdetroit 17:28, 21 February 2007 (UTC)
I'm really not trying to force anyone to use the other version ... I created a framework with templates for nature elements (rivers, mountains, ranges, protected areas) in a unified style (which was inspirated be Infobox City) and beacause I think it has certain advantages I made a version for Towns/Cities too. I'll try to apply it on Czech and Slovak settlements as they use quite a few various templates but I'm not planning to use them anyplace else (I prefer editing articles on places in my geographic area). I put quite an effort into making the template backwards compatible with Infobox City while also making it more general, more usable for smaller settlemnts.
It's no issue with existing infoboxes how the fields are named, the chaos in field names is rather discouraging for those who wish to use the template on a new location. The Geobox system aims at being as user-friendly as possible.
As of the bugs that had been introduced, I didn't mean your edits but a larger one some time ago (half a year or so …) when somebody completly revamped the internals of the infobox which, at that time, was pretty fine-tuned. That revision returned many issues (well, not exactly bugs) that had already been dealt with (e.g. unnecessary red links on flags etc.) Since then, many of these have been solved again, I guess mainly by yourself. My post had nothing to do with your edits, I was working on the template for some time while you were improving Infobox City as well. I simply thought and think my Geobox had something to offer too, it's a free project so anyone can use it, change it, use parts of it … E.g. it already has some free fields which the next posts asks for. – Caroig 20:38, 21 February 2007 (UTC)
Yes the "red links" in the flag etc are terrible and should be the next thing that is removed. —MJCdetroit 02:52, 22 February 2007 (UTC)

Merge with Geobox Town and perhaps rename to Infobox Place

Merge arrows
 It has been suggested that this page or section be merged with Template talk:Geobox Town. (Discuss)

I would suggest that we merge the two so that they don't compete against each other.—MJCdetroit 01:59, 4 March 2007 (UTC)

Longer reply

Well, yesterday I removed all support for the field names from Infobox City as there seemed no interest in that. Its much easier to maintain the code now. Geobox City is a part of a larger series of coherently named and formatted "Infoboxes".

To be sincere I started Template:Geobox Town as I was unhappy with the situation around Infobox City. As I wrote some time before, I stopped using this template some time ago when someone complete reworked its code (I probably wouldn't find the edit now, it was when someone replaced the wiki table syntax with the classic HTML tags), broke the layout and reintroduce too many bugs or issues that had already been solved. And people still keep adding haphazardly named fields which often broke other things. Sorry MJCdetroit, I see you're trying hard to bring some other here but others do their changes too and not always to the best.

To put it in a nutshell, all Geoboxes use the same field names and internal logic, there's always a fieldname which can have modifiers attached. All unit related fields can have _imperial and _unit and _round attached, some fields (where it makes sense) have _type to change the default label (there's always one default value so there's no need to define the label, take mayor – most towns cities in Europe have just mayors, so I don't need to define that, the same applies for coutry, region, postal code etc. but if you need you can still "retype" the label). Most fields have also _note, a field for various notes, references etc. Not only this is easier for a user, there's no need to include those additional fields in a blank template and some day, hopefully, more advanced syntax will be introduced to the Mediawiki software enabling much easier code – there would be a subtemplate which would have the name of basic field as a parameter and the rest will be done automatically. Well, this could be achieved even today but with the current syntax it doesn't seem that useful. The Geoboxes have also a flexible location map system, which allows input data in either the classic way (deg, min, sec) or just positive/negative decimal numbers, the placement of the locator dot can be achieved in two ways, either fully automatically based on coordinates or seme-automatically using relative coordinates of the dot when the former is from various reasons not possible (conical projection, map with an inset).

You can see all the various Geoboxes e.g. here:

The Geoboxes series is just something new, with a new approach. They offer very consistent sytem of template for geography related "Infoboxes". They offer quite a few new things, their biggest disadvantage being they are not compatible with most existing "Infoboxes" – Caroig 08:56, 4 March 2007 (UTC)

This seems like a very good idea to me. Consistent parameter naming is a good thing - the current infobox suffers from internal inconsistencies and could use some refactoring. The geobox series seems to be well thought out, from scratch, so rather than refactor this one perhaps we should institute a project to convert the 3000 or so cities that use the "infobox" template to use the geobox template. -- Rick Block (talk) 15:26, 4 March 2007 (UTC)
Well, I added support for those fields from Infobox City even if it made the code much more complicated and difficult to maintain. I put the post on the talk page and waited if anyone tries to switch an existing page Infobox City to the Geobox. No one has ever done that so I decided to remove that feature. The support for these fields was added mainly to let people try out the new template as painlessly as possible.
Meanwhile, I finished a "beta version" of a new template in the series Geobox Region, same style, same functions plus one new feature (folding subdivisions) which I might, in some way, implement here two. I still keep this page in my watchlist and follow the development here (recently I added support for leader parties). So I'm not giving up here but I don't think reintroducing support for those old messy field names is a way to go. I've written a simple PHP script which helped me easily convert some existing Infobox City into Geoboxes. I did that only on articles from my country (where actually three or four different infoboxes are used). – Caroig 15:51, 4 March 2007 (UTC)
My suggestion was to Merge the two and use the best of both and to rename the template to Infobox Place (which redircts here now). How easy would this be? I think it's clear that there are things about the geobox templates that we like, otherwise we wouldn't be having this discussion. We should have project to somehow merge the two under the name Infobox Place and redirect others to it. That way we all can agree on a new final version before we unleash it. What do you think? —MJCdetroit 18:58, 4 March 2007 (UTC)
Well, but what do you exactly mean by merging? The previous version was "merged" in a way as it accepted all fields with their names from Infobox City. Geobox Town is a part of a still growing project of geography related "infoboxes" which all start with Geobox so I see no reason to change that name (it can be Geobox Place, sure), neither to change the field names which are coherent across the series, nor to change the internals which use common internal subtemplates. – Caroig 19:29, 4 March 2007 (UTC)
We should do our best to have one template with one look. If we chose to redirect to City to Geobox Town (or vise versa or new name) then we should all have our input into a new look and functionality. —MJCdetroit 20:00, 4 March 2007 (UTC)
I agree, however especially for towns/cities there's a special template for nearly every country in Europe and every one looks completely different … And all the Geoxes have very uniform look. I wouldn't enforce anyone to use neither of these templates. Just let the users decide … that's why I posted the notice about Geobox Town here. I simply see Infobox City like an old house, sometimes it is cheaper and more effective to pull it down and build a new one. – Caroig 20:28, 4 March 2007 (UTC)

Licence plate code

Many European countries specify location in car number plates (See European vehicle registration plates). For example, German number plates starting with "M" come from Munich, while Spanish ones starting with "M" are from Madrid.

Would it be possible to introduce such a field to this template? At the moment, Athens, which uses this template, has the licence plate code in the footnotes field. If this feature were to be added, more European locations could be better served with this template, making it more reasonable to use this template instead of creating more country-specific ones. - 52 Pickup 15:45, 21 February 2007 (UTC)

Sounds fair to me. Besides it would be optional anyway. We should probably think about adding some optional "blank" fields into the template. —MJCdetroit 16:59, 21 February 2007 (UTC)
The addition of some "blank" fields is a good idea - it gives the template greater flexibility. After the request for a new Polish location infobox in WP Infoboxes, it seems that replacing that template with this one is the way to go (discussion here). - 52 Pickup 10:31, 23 February 2007 (UTC)
The suggested Template: Geobox Town (99% compatible with this template) already has such fields, either in the section with postal_code and area_code, or in a dedicated free field section. – Caroig 10:40, 23 February 2007 (UTC)
The Geobox series of templates are brilliant, but we should work on combining them to have a single template. There are many nice features in the Geobox templates that should be imported here. - 52 Pickup 07:33, 26 February 2007 (UTC)
As I wrote earlier, I've put a lot of effort into making the Geobox Town template (aliased as Geobox City) accept the field names from Infobox City. So in most cases if you just switch the name of the template, Geobox Town will work perfectly, however the new field names are preferred. One of the aims of the project is to have consistently named fields across the series as well as consistent formatting of the ouput (done via many subtemplates) which may differ form the output of the Infobox City. (E.g. the first figure for area/population gets displayed on the same line as the label which produces just one line of data for settlements with just one figure for are/population). – Caroig 08:38, 26 February 2007 (UTC)
I tend to agree with 52 Pickup that we should try and implement what is good about the geobox template into this template and keep it at only one standard template. I think the field names should be changed a bit, but not in the exact same way as the geobox.—MJCdetroit 17:27, 26 February 2007 (UTC)

new field: political party of leader

It is possible that the infoboxes used for Dutch locations will be converted to Infobox City. One thing that the Dutch template has that this one does not is a separate field for the mayor's political party. Separating this from the name of the mayor would be very useful since then you could remove the need to wikilink the name - and set the template to check instead if an entry exists under this name. This would remove a few red links.
To help in this, I've been working on a new template {{Polparty}} where you enter the name of the country and the politcal party, and it gives you the correct abbreviation that links to the entry on that party. For example {{Polparty|USA|D}} = [[Democratic Party (United States)|D]]. To test it, I have modified the entry for Chicago. If the list of countries/parties is expanded in Polparty, this might make it a little easier to have the right political information. What do you think? - 52 Pickup 19:34, 25 February 2007 (UTC)

Following on from what i said yesterday, I have just set the leader_name fields to first check if a given entry exists, and modified the Chicago entry to demonstrate. Previously, this was given:
|leader_name = [[Richard M. Daley]] ([[Democratic Party (United States)|D]])
But now it is given by:
|leader_name = Richard M. Daley
|leader_party = D
And the output is the same as before - Richard M. Daley (D). Breaking it up like this (and removing the wikilinking) is IMO more user-friendly. Many fields should have this ifexist check in place. - 52 Pickup 07:58, 26 February 2007 (UTC)
IMO, autolinking like this is not a good idea. Red links are avoided by the ifexist check, but autolinking the content means if the name happens to correspond to an article it will be linked whether it's the right article or not. At the point of invocation of the template, the user should be free to link (or format the link) however they'd like. There are two issues that come up with the current version, one is names that link to the wrong article and the other is piping links so the presentation looks different from the link. Adding an explicitly formatted link fixes the latter issue, but if most uses of the template use auto-linked "plain" names how to do this will not be obvious. Requiring an explicit link requires 4 extra characters in the "plain" case, but shows (by usage) how to both include a non-linked name and a piped link. I'm all for making templates as smart as possible, but this strikes me as trying to make it too smart. -- Rick Block (talk) 19:07, 26 February 2007 (UTC)
OK, maybe autolinking the name is a bit much, but what about the new field for the party? That was the more important thing that I wanted to do here, as installing this is the main thing that will make it possible to convert the Dutch location infobox {{Infobox Dutch municipality}} to this one. - 52 Pickup 15:25, 28 February 2007 (UTC)
The party thing is a good idea. The only reservation I have about it is using the "subdivision_name" parameter as the combining tool. This is usually the country, but doesn't have to be. It'd be kind of a drag to update all the references (again), but I'd be more comfortable with the party idea if there was a parameter that was explicitly "country". -- Rick Block (talk) 01:19, 1 March 2007 (UTC)

Time to fully protect this template?

There are over 3000 pages using this template. Is it time for full protection? -- Rick Block (talk) 04:23, 26 February 2007 (UTC)

If that is the only reason. No. But if this pertains to my request because of alleged vandalism, then yes, of course with the prefered version supporting the new categories until the issue is resolved. I have attempted to add new auto-generated categories. Unfortunelly one of them, category:Cities in the UTC-5 timezone, is nominated for deletion. As you probably know, the recent changes to this templates undermine wikipedia's deletion process for categories, which is why I requested this page be reverted and protected. The manner at which you bring it up here doesn't quite please me because it appears to lack many of the afformentioned details. --CyclePat 04:40, 26 February 2007 (UTC)
It's related to the number of recent changes, yes. We generally don't protect to a "preferred version" (except in cases of obvious vandalism, which IMO this is not). Edit warring is very bad. Edit warring on a template used by 3000 articles cannot be tolerated. -- Rick Block (talk) 05:06, 26 February 2007 (UTC)
After manually checking and editing all 3,000 or so pages with the help of WP:AWB, I would be in favor of the protection. —MJCdetroit 15:02, 28 February 2007 (UTC)
Post Scriptum: Of course in the interest of development, we would have to have some type of a "test sandbox" for editors without access to play with. MJCdetroit 15:10, 28 February 2007 (UTC)

Link fixes

This edit adds parameters for flag_link, seal_link, shield_link, and logo_link (presumably to avoid red links where these articles don't exist). Requiring an explicit link parameter for these articles makes it completely unambiguous whether there's a link or not, and removes any forced association between the name of the city article and the name of the article about the flag (or seal or ...). Unfortunately, it also breaks every link that did exist (like some of the "Flag of" articles here). Another way to do this would be to make these links conditional on the existence of the article (the way the "leader" links are handled, above). Unlike in the leader case, I think it's actually appropriate to automatically link these (if the article exists). These are articles with names like Flag of Denver, Colorado, which are extremely unlikely to need disambiguation. I really think it would be a good idea for folks to start discussing changes to this template before making them. -- Rick Block (talk) 05:04, 27 February 2007 (UTC)

Sorry, my fault :(... The matter has been brought up here a couple different times recently. I do think making the links conditional on their existence would be better so I've reverted my edit. I think changing the way those links are displayed (or not displayed) will improve the template. —MJCdetroit 02:16, 28 February 2007 (UTC)
The only problem is getting people to comment might be worse than pulling teeth. I'd be happy to add ifexist checks for these. Unless anyone has some objection, I'll do this on Friday. -- Rick Block (talk) 02:32, 28 February 2007 (UTC)
Sometimes, you have to just edit and wait for a reaction...—MJCdetroit 14:59, 28 February 2007 (UTC)
Perhaps the additional fields can be used with the following if-format: {{#if:{{{flag_link|}}}|[[{{{flag_link}}}|Flag]]|{{#ifexist:Flag of {{PAGENAME}}|[[Flag of {{PAGENAME}}|Flag]]|{{#ifexist:Flag of {{{official_name}}}|[[Flag of {{{official_name}}}|Flag]]|Flag}}}}}}. This way some control can still be present in linking to the right page, red links are eliminated, and the previously-existing links will still work. - 52 Pickup 15:08, 28 February 2007 (UTC)
Maybe, but if not, I only added the new links to two pages before I reverted. —MJCdetroit 15:13, 28 February 2007 (UTC)
It is a good idea to have these extra link fields. I can't remember where, but I've seen pages which contain such flag/seal information that the template would not have been able detect otherwise. - 52 Pickup 15:18, 28 February 2007 (UTC)
Changed the template to reflect 52pickup's idea. It seems to have worked; see Lethbridge. —MJCdetroit 05:31, 2 April 2007 (UTC)

Nickname

Why is the nickname just floating between the location map and the flag and seal images now? That seems to be an odd place for it. Kaldari 19:46, 27 February 2007 (UTC)

Merging template

I've been thinking in merging {{Geolinks-cityscale}} and Establishment date categories into this template, please tell me what do you think. Thanks. --– Emperor Walter Humala · ( shout! · sign? ) 21:46, 2 March 2007 (UTC)

Master Databases with all City/Town Data for the United States

Does anyone have, know someone who has, or can tell me where I can find databases with all information needed to create infoboxes for every single city and town in the United States? I'm looking to do this in the next few months, but can't find a single source with all the needed data. Right now I'm considering writing a bot to read through every US town/city article and extract the data, but it would much better if I could just find a set master tables (ideally from government databases sitting out there somewhere). I'll also take any information available on counties, census designated places, and any other geographic division that might require infoboxing.

The information I would need is: Town/City name, County, State, population total, population density (per sq mi and per sq km), population date, area total (sq mi and sq km), area water (sq mi and sq km), area land (sq mi and sq km), elevation (ft and m), coordinates, time zone, summer time zone, zip code(s), and area code(s). Optional data would include nickname, motto, type of government, leader type, leader name, website, and any other important notes.

Please let me know if you have anything, and I'll be happy to start compiling it all into a giant Excel spreadsheet for future processing into infoboxes.

Note that this will only be done for cities and towns that currently lack infoboxes (though I could theoretically use it to fill in missing information in cities/towns already having infoboxes).

Thanks, --CapitalR 14:55, 6 March 2007 (UTC)

Maybe we can coordinate something with the UTC time project I tried to do which placed all the cities by time. Or Category:Geography by time. Unfortunatelly not everyone is as enthusiastic about that category but if we ended up making a program that could read through all the information that is on the pages to make a couple SQL like statement searchs into the wiki database on the information provide in the template:infobox city. This could be a another way around my pesky problem of anoying left winged conservatives that don't want to utilise categories. (A database!) Let's talk by email. --CyclePat 22:10, 6 March 2007 (UTC)

Bug Expression error

In Havířov article it shows up "Expression error: Unrecognised punctuation character" sentence in area parameter. - Darwinek 22:48, 6 March 2007 (UTC) It also shows up in the density field, see Frederiksberg for example. --Darwinek 00:14, 7 March 2007 (UTC)

It is actually not a bug. It happens because the numbers are not entered in a raw format; 24000 and NOT 24,000 or 24 000. The numbers will be converted and formated automatically by the template. I fixed them. See How it works Above for a better explaination. —MJCdetroit 01:06, 7 March 2007 (UTC)
A bit more on this - including punctuation causes the parser functions used to do the automatic unit conversions to fail. The template can neither detect nor automatically correct for this (given that m:StringFunctions are not installed here). -- Rick Block (talk) 01:11, 7 March 2007 (UTC)


Background color for name fields

I don't really like the "colored" infobox header version. A graphic designer would be horrified. Please someone revert!.--((F3rn4nd0 ))(BLA BLA BLA) 07:20, 7 March 2007 (UTC)

Anyone else feel the same way? I placed a new version in the test template here. Take a look and talk about it. —MJCdetroit 01:35, 28 March 2007 (UTC)
I like it. Many infoboxes have coloured headers, so this doesn't look at all out of place. - 52 Pickup 08:00, 7 April 2007 (UTC)

I prefer the old color. This way the color is easy out of tune with the top image. Maybe you can make the coloring of the background optional, as in Template:Infobox Actor? – Ilse@ 13:14, 7 April 2007 (UTC) (post moved by User:MJCdetroit)

There wasn't a color before. 52pickup's comments above were/are the exact reason I colored the background for the header. As for making it optional, I would be against that. It should be all colored or all not colored. This infobox is very flexible as it is with only one required parameter. It should have a consistent look throughout; whether that be all with a colored header (like many other infoboxes) or all without a colored header (as before). —MJCdetroit 14:57, 7 April 2007 (UTC)
I agree with the comment of User:F3rn4nd0 above, I'd also like to see the changes reverted. For an encyclopedia, I prefer a neutral outlook of the infobox itself over a colored one. After all, if you want more color, a photograph in the infobox can provide this. It shouldn't be too hard to find a colored photo for any city. – Ilse@ 17:31, 7 April 2007 (UTC)
Let's see what other editors have to say first. If it also makes others puke then of course we'll get rid of it. Regards, MJCdetroit 18:07, 7 April 2007 (UTC)
I strongly oppose the color change. The appearance of this infobox is meant to be consistent with Template:Infobox Country and other geography infoboxes. What purpose does the color serve? How does the color blue relate to the subject of cities? I think there should have been a consensus before the change was made. — Kelw (talk) 18:21, 7 April 2007 (UTC)
I prefer gray or no color as well. Seems to be more in line with the state and country infoboxes too. --MattWright (talk) 18:17, 7 April 2007 (UTC)

Government section and blank fields

Actually, there isn't really a "section". It is just kind of there with the subdivision and the established dates. Therefore, I am going to separate it with a line and give it a section heading like Area and Population have. I think it will make the template look better, but if it makes you puke (like the name color) then feel free to revert it. Also, how about some blank fields for each section and the template? —MJCdetroit 02:27, 9 March 2007 (UTC)

Here's an example of where blank fields would be handy Template:Infobox London/Test. If noone objects, I'll insert them soon. —MJCdetroit 01:25, 15 March 2007 (UTC)
  • I'm in favor of a blank field in each section, as I have some uses for such fields in certain articles. Also, could someone look at Durham, Connecticut. Note that the "Government Type" field has a problem; the word "Type" in "Government Type" wraps to the second line, which is okay, but on the right hand side, the value "Selectmen-town meeting" starts on the same line with "Type" instead of the top line with "Government" (at least on my IE7). This should be examined and fixed. Thanks, --CapitalR 10:25, 18 March 2007 (UTC)
I added two additional blank fields. The fields are named blank_name paired with blank_info and blank1_name paired with blank1_info. This can be useful for cities in Europe that have license plates issued for that city. Example: Warsaw. —MJCdetroit 03:43, 25 March 2007 (UTC)

Geobox Town/City, Chapter Two

Hello, for those interested, a short update on the recent development of this template:

  • several issues concerning display of some fields (especially the maps) in IE7 have been solved
  • a set of fields dedicated to municipal parts has been introduced, there can be a pretty long list which upon the load of the page is "folded", see e.g. here: Pilsen
  • some fields can make use of the title HTML attribute (they're named field_label), i.e. a text displayed on hover (see Plasy and stop your mouse over Little District. This might introduced to all field labels.
  • the coordinates-related fields are more flexible now, they can be filled in in the classic format (deg, min, sec) or using the decimal format, with negative values for the Western and Southern hemisphere (the locator dot system works well with both systems too of course)
  • a secondary field for another map (without the locator dot system, just a plain picture) used e.g. here: West Chester, Pennsylvania - that Geobox makes use of a calibrated Pennsylvania State map so the locator dot is placed based on the coordinates
  • Geobox Town can be used together with Geobox Region when a region has the same name as the town/city and thus there's no need for a special page for that administrative unit (which would usuallly contain not much more than some statistical data anyway). Rather extensive use of the Geobox Region can be seen here: Pilsen Region, a combination of Geobox Town and Geobox Region e.g. here: Radnice. – Caroig 20:33, 11 March 2007 (UTC)
  • News as of 2007-03-16: if value auto is assigned to any population_density field, the actual density figure is calculated automatically from appropriate area and population values. – Caroig 19:42, 16 March 2007 (UTC)

Geographic coordinates with only degrees

Is there a reason (technical or otherwise) to not to support geographical coordinates where only degrees are listed? [1] provides coordinates in decimalized degrees, without minutes and seconds. It make sense to enter this information directly without requiring a calculation that can introduce error or rounding that reduces accuracy. David H. Flint 07:19, 15 March 2007 (UTC)

For reference, on the technical side, it seems that the relevant change could be to replace

  <tr class="mergedbottomrow">
        <th colspan="2" style="text-align: center; font-size: smaller; padding-bottom: 0.7em;">Coordinates: {{#if:{{{lats|}}}
  | {{coor dms|{{{latd}}}|{{{latm}}}|{{{lats|0}}}|{{{latNS}}}|{{{longd}}}|{{{longm}}}|{{{longs|0}}}|{{{longEW}}}|type:city}}
  | {{coor dm|{{{latd}}}|{{{latm}}}|{{{latNS}}}|{{{longd}}}|{{{longm}}}|{{{longEW}}}|type:city}}}}</th>
  </tr>

with

  <tr class="mergedbottomrow">
        <th colspan="2" style="text-align: center; font-size: smaller; padding-bottom: 0.7em;">Coordinates: {{
  #if:{{{lats|}}}
        | {{coor dms|{{{latd}}}|{{{latm}}}|{{{lats|0}}}|{{{latNS}}}|{{{longd}}}|{{{longm}}}|{{{longs|0}}}|{{{longEW}}}|type:city}}
        | {{#if:{{{latm|}}}
                | {{coor dm|{{{latd}}}|{{{latm}}}|{{{latNS}}}|{{{longd}}}|{{{longm}}}|{{{longEW}}}|type:city}}
                | {{coor d|{{{latd}}}|{{{latNS}}}|{{{longd}}}|{{{longEW}}}|type:city}}
  }}</th>
  </tr>

I'd prefer not to make such a change myself, as I do not know the reasons for why it is the way it is now or what could break. David H. Flint 07:50, 15 March 2007 (UTC)

You might want to borrow the code from the Geoboxes, particularly the {{Geobox coor}} template which does the same plus it also accepts negative values for the western and southern hemisphere, see the examples. There's also the {{Geobox coor title}} template which accepts the same input values and prints the coordinates in the article title. Actually, you can use these templates directly. – Caroig 08:56, 15 March 2007 (UTC)
Those templates are pretty neat. Handling signed coordinates properly makes sense too, though I wasn't sure of the best way to do so. Why are there three versions of Coor templates anyway? I noticed the Geobox Town template though, and it actually solves several other issues that I have with the Infobox City template. I have switched to that, but have encountered two small issues which I will bring up on its discussion page. David H. Flint 19:05, 15 March 2007 (UTC)
I tweaked the template using the fix suggusted by Caroig. It seemed to work well in the Sandbox. What were the other issues that you have with the template? —MJCdetroit 03:20, 16 March 2007 (UTC)

Other issues

Thanks for responding so quickly to my problem. The other issues I have with Infobox City are primarily aesthetic. The biggest thing that made me a convert (besides the degree issue) is that Geobox Town does imperial<->metric conversion automatically, thereby eliminating a possible source of error. Another thing is the overall consistency of field names in terms of _type, _imperial and _note. Anything that makes the job of an editor easier should be encouraged. Both templates do their jobs adequately; I just think Geobox Town will be better going forward.
Of course, it would be nice if we could settle on one template, but a lot of the advantages of Geobox Town are only afforded by an outright adoption, and not a modification of Infobox City. Given that at least 5,000 pages use Infobox City, it is a decision that would need to be weighed heavily and garner broad support, especially considering the effort that would be involved in such a conversion and the relatively small benefit from the perspective of a reader. As it is, I might convert those pages in my region, or that I stumble upon, or that need improvement, but I have other, higher priorities.
I appreciate your hard work on this template, and I am sure that it will continue to be used for some time to come. David H. Flint 04:53, 16 March 2007 (UTC)
As for your first issue, this template (Infobox City) does have dual automatic unit conversion; imperial to metric or metric to imperial and it can be over riden for (instances like ranges in elevation) by entering both imperial and metric values. I also made it to try to automatically swap the unit order based on subdivision_name being some variation of United States. There is also unit_pref=Imperial. I think we should make a better table explaining all the fields possible with this template.
As for the names, yes they do need to be improved and some of us have talked about doing that. We've also discussed fixing the flag, logo, seal, shield links that are red on many pages. And some didn't like the nickname and motto position.
I am sure that there are other things that could be tweaked but if no one says anything thing we won't know. So thanks for the coordinates things—I would not have thought of it. —MJCdetroit 17:41, 16 March 2007 (UTC)

Adding to all US Cenus Areas (41,903 cities/towns/townships/villages/etc.)

Overview

I've spent a while compiling a giant database of information on US census division statistics, and I'm nearly ready to request permission to use a bot to add this template to all 41,903 articles that I have information on. However, a serious discussion will need to take place first to determine if this is the correct template to use, and what kind of modifications need to be made to it before its usage jumps from 4100 to 45000 articles. Thus, I will start that discussion here, so please add your comments. I haven't applied for a bot account yet, and will only do so when/if a consensus is reached here that adding this template to the articles is the right thing to do.

My database, which I compiled from many government databases, contains the following information. These are nearly all articles added by User:Ram-Man and User:rambot, but there are about 5000 that are missing (and which I will add in the style of the rambot). The percentage refers to the number of records, out of 41,903, that I have that information on:

  • Name and type (city/town/township/CDP/borough/charter township/balance/etc.) (100%)
  • State and all counties that the location is in, along with all corresponding FIPs codes (99.91%)
  • Place ID, from national geography database (97.80%)
  • Population year, total, density (100%)
  • Area total, water, land, in both km and mi squared (100%)
  • Latitude and Longitude (99.91%)
  • Elevation (97.79%)
  • Time zone, UTC offset, Daylight Savings use, DST offset (100%)
  • Area codes (69.00%, mostly missing from CDPs and townships)
  • ZIP codes (62.20%, mostly missing from CDPs and townships)
  • I also plan on generating and uploading new, standard, and prettier maps for all 41,903 locations (based on a combination of St. Paul, MN, Concord, NH, and Miami, FL map designs).

Information I can't find in public databases (if you know where to find an item, let me know):

  • City/town website listings
  • Area code and ZIP code geographic boundary files
  • List of mayors or other leaders of all cites in the US
  • List of dates settled/incorporated for all locations in the US

Note that I will not overwrite information in articles that already have an infobox, but I will add missing information (though I will record all information already in infoboxes, so I can later examine if it is accurate, and replace it later on if it is not accurate). Also, I do not plan on using the bot to edit the largest 200 cities or so, and these articles will be edited by hand to add the information.

The new maps will only be used on articles that contain no map, or contain one of the simple red-dot maps. Articles with more sophisticated maps will not have their maps modified. However, the maps for all locations will be uploaded, even if it is not used in the infobox, so someone can manually add the new map to an article later on if they choose.

Certain states, such as Massachusetts and New Hampshire already have most of their cities/towns/etc using this template; this project would just be a continuation of this process to extend the templates to all cities/towns in every state.

I have a few requests/suggestions for changes to be made to the template before this huge-scale use:

  1. See Durham, Connecticut. Note that the "Government Type" field has a problem; the word "Type" in "Government Type" wraps to the second line, which is ok, but on the right hand side, the value "Selectmen-town meeting" starts on the same line with "Type" instead of the top line with "Government" (at least on my IE7). This should be examined and fixed.
  2. The five strangely named parameters for area, "TotalArea_sq_mi", "LandArea_sq_mi", "WaterArea_sq_mi", "MetroArea_sq_mi", and "UrbanArea_sq_mi" should be named with more standard names. It would be good if someone could make both the old names and five new names usable, until I can convert all instances of the old names to the new standard names with a bot. At that point these old names could be completely removed.
  3. It would be useful to have a way to include FIPS codes and a FeatureID (see the File Format section in [1]) in this template to help people keep track of the exact record of the city in census and geographical databases. Many places have the same name within states (for example, there are four Exeters in Pennsylvania), and it is difficult to tell them apart without such a number. Perhaps we could add a few official fields at the end (something like id_type1, id_number1, id_type2, id_number2, etc) that don't actually display anything, but just exist for classification purposes only. Or perhaps they could display the ID numbers at the bottom in very small print.

So, please add any questions and comments about this proposed use of the template below. --CapitalR 10:55, 18 March 2007 (UTC)

Discussion

This is not directly connected with your suggestion yet let me point out the existence of {{Geobox Town}} (or if you wish {{Geobox City}} which is just its alias). It was nor originally designed for US cities but as of its current version it can easily accommmodate all its fields from Infobox City and it provides much more functionality in a cleaner design. The fully consistent field names are also useful for any import/export to/from a database.

As of your three issues with Infobox City:

  • {{Geobox Town}} prints all field labels on one line thus you never get the field label split in two parts.
  • one of major advantages of {{Geobox Town}} is that it uses consistent field names, all imperial/customary units are have suffix _imperial (i.e. are_imperial, area_water_imperial, population_density_metro_imperial etc.); furthermore there exist additional fields with the _note suffix that accompany every basic field (for any type of notes, references etc.), there are also _type additional fields (for every basic field) that allow to redefine the default field label
  • there exist four code fields which could be used this way (always code for the value and code_type for the field label, there's code, code1, code2, code3) or four free fields (defined always as free and free_type)

Additionaly, there are two fields for a map, both of which can make use of an automated locator dot placement (given a calibartion template exists for the given map), then there's no need for a special map for each and every place. Of course, plain maps can be used as well. The use of two maps (state map and the location of the state within the USA) is recommendable as non-US readers are usually not familiar with the location of US states.

Some users tried to use this template for US places, see e.g. Springfield, Illinois or West Chester, Pennsylvania. – Caroig 12:17, 18 March 2007 (UTC)

CapitalR, "My what a big database you have"—good job.
"Goverenment type" actually doesn't split. Government is the section title (much like Area and Population) and "Type" should have a dash in front of it. That should be easy to fix.
As for the field names, we've been discussing them and they will be changed to more consistent names soon.
We can always add ID fields to the template as well but we should work on the names first. —MJCdetroit 16:01, 18 March 2007 (UTC)
I do like the idea of having some consistency throughout the city articles. For instance, Bakersfield, California has a seal & logo in box, but picture and dotmap are outside the box. Fresno, California has a seal, picture, flag, and dotmap in the box. Ontario, California has only a picture and dotmap in the box. I'm sure this list continues ad nauseum, as these are just the first three cities I opened up.
Anyway, I think it's a good idea. My hat is off to you, I think even with a bot it's a lot of work. Brien ClarkTalk 04:33, 28 March 2007 (UTC)
See Bakersfield, California. The logo was a little long, so I placed it in the image_map1 field instead of the city_logo field. —MJCdetroit 16:57, 28 March 2007 (UTC)

Rename to Infobox Settlement

Would it make sense to rename this template to Infobox Settlement instead of the current Infobox City? This template is now designed to be used by any settlement type instead of just cities, and I want to make sure that people aren't confused when they see this template in an article that isn't about a city. For example, when I added this template to the 301 Massachusetts towns, some people reverted the changes on the basis that a town isn't a city (it was very irritating to have to go fix these and explain that this template is for more than just cities). I know that Infobox Town redirects here and I could have just used that instead, but I still think that the master template should be named Infobox Settlement, and the Infobox City, Infobox Town, Infobox County, Infobox Township, etc, should all redirect to the master. Just some thoughts to consider, --CapitalR 12:14, 19 March 2007 (UTC)

Infobox Settlement as the master is a change that we could live with. However, the default "settlement" would still be city unless changed in the field "settlement_type". By the way, Infobox Place also redirects here.
Also, in regards to some of your comments above, I have managed to change most of the field names in a sandbox but there's one that is giving me problems, so once we fix that, we'll do some testing before implementing them on the live template. —MJCdetroit 15:17, 19 March 2007 (UTC)
What's the status of merging this with Template:Geobox Town. Is there any reason we need both? What does Infobox City offer that Geobox Town does not? --MattWright (talk) 15:29, 19 March 2007 (UTC)
I suggested it before. It would be in our best interests to have just one standard template having the focused effort among editors. We can call it whatever. There are a few differences, but with Infobox City transcluding on 3,500 pages there would have to be some compromises made to not upset the editors of those 3,500 plus pages. —MJCdetroit 17:12, 28 March 2007 (UTC)
Hey MJC, thanks for the reply (I had seen it). I didn't followup because I didn't have any great solutions for merging them and hadn't had the time to explore it more. --MattWright (talk) 20:43, 29 March 2007 (UTC)
I think that making "infobox settlement" the master and "infobox city" the redirect seems appropriate. Unless there are strong objections, I will see about completing this in the next few days. —MJCdetroit 16:30, 25 May 2007 (UTC)

New more consistent parameter names and an explaination table

The parameter names have been (or will be) changed so that they are a little more consistent with each other. Infobox City/Test has already been changed. It has side by side infobox comparisons —which look the exact same. It also has a table showing the new field names and the deprecated (old) names. After the new names are implemented in the template, the old names will still work and we can get a bot to switch all the pages using this template to use the new names. Please see Infobox City/Test. —MJCdetroit 01:06, 22 March 2007 (UTC)

Nice job getting those new names in there. --CapitalR 16:25, 23 March 2007 (UTC)

Edit conflict...I made the change to the live template so that it will accept the new names. The documentation on the main template page has been updated to reflected this change. There is also a table to help explain the template a little better. The only article that I changed to the new names was San Jose, California. We can get a bot to change the rest. In the future, articles should only use the new parameter names. —MJCdetroit 16:34, 23 March 2007 (UTC)