Template talk:Infobox settlement

From Wikipedia, the free encyclopedia
Jump to: navigation, search

"Auto" density should compute based on land area, not total area[edit]

This conversation has been revived from the archives, and tagged to prevent autoarchiving. Remove the {{DNAU}} tag upon completion of this discussion.

Population density has to do with settle-able area. While there are cities with "houseboat" units, these are never a significant portion of any particular settlement and, if there were such a settlement, it ought to use a different template. I fear that a lot of the listed densities for cities are wrong due to this error. Zelbinian (talk) 07:30, 21 August 2012 (UTC)

100% agree. See Lauderdale-by-the-Sea, Florida whose actual population density is 6,913 persons/sqmi (when calculated based on land area) and not 3,900 persons/sqmi (when calculated based on total area). 70.42.69.221 (talk) 14:15, 21 September 2012 (UTC)
If the land area is given, sure. But if only the total area is known, the template should still display a density. —Stepheng3 (talk) 17:06, 21 September 2012 (UTC)
how about if we add the option for "density_km2 = land" to have it use the land area? Frietjes (talk) 19:28, 21 September 2012 (UTC)
We shouldn't have different instances of this template displaying values calculated using different methods, under the same heading. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:58, 21 September 2012 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Reviving this conversation... I agree with Andy Mabbett, yet I must say that this is a valid request, and I think Stepheng3's suggestion is sound – that is, if |area_land_*= is specified, then use it, else use |area_total_*=. The U.S. Census computes and reports density using land area. Note the following, from Census.gov Geographic Definitions -- Population Density:

"Population and housing unit density are computed by dividing the total population or number of housing units within a geographic entity (for example, United States, state, county, place) by the land area of that entity measured in square kilometers or square miles. Density is expressed as both "people (or housing units) per square kilometer" and "people (or housing units) per square mile" of land area." (emphasis added)

For many communities, the difference is negligible, but for others, this is significant. In Provincetown, Massachusetts, for example, with a 2010 total population of 2,942, a total area of 17.5 sq. miles, and land area of 9.7 sq. mi., the density is being calculated as 168, where it should be 304. Provincetown (CDP), Massachusetts is even more substantial, where the present formula yields a density of 505, when it should calculate to 1479. Anyone have a problem adding an {{edit protected}} request? Grollτech (talk) 18:23, 18 December 2012 (UTC)

Please don't do that until you've found or written code that would permit this. It's a very good idea, but you need to make it plain for non-tech-savvy admins like me. Nyttend (talk) 20:40, 18 December 2012 (UTC)
US Census data is not mandatory for that field. If WP would only show US Census data, it would be much smaller. But the field should show where the value comes from, i.e. "Density (Land)" or "Density (Land+Water)" or show both if there is a diff. NVanMinh (talk) 06:46, 20 December 2012 (UTC)
There's nothing more reliable than the Census Bureau, so we should use Census Bureau results for the fields in question. However, I don't understand why you bring this up here; could you explain why you mention it? Nyttend (talk) 13:40, 23 December 2012 (UTC)
If nobody who's already familiar with this template's code is available to make the change, I'd be happy to go ahead and code the changes in the sandbox. NVanMinh, I understand that U.S. Census data isn't mandatory for the field, and that this is a global (not U.S.-centric) template. However, it is obvious that the 'area', 'population' and 'density' fields within this infobox are based on the Census Bureau's data model. More importantly, as the OP stated, "Population density has to do with settle-able area." This view is consistent with the population density article, which defines biological population density as "population divided by total land area or water volume, as appropriate." Since humans are the subject biota of {{Infobox settlement}}, Land Area is really the only valid basis for computing density. And yet, since this template presently provides the "courtesy" of automatic calcs based on Total Area, it should probably continue to do so, but only if the value for "Land Area" is absent – in that instance, it may be appropriate to annotate the result with something like "(based on Total Area)"? Grollτech (talk) 20:50, 23 December 2012 (UTC)
Infobox settlement
Area
 • City 100.105 sq mi (259.27 km2)
 • Land 97.915 sq mi (253.60 km2)
 • Urban 246.8 sq mi (639 km2)
 • Metro 357.9 sq mi (927 km2)
Population (2010)
 • City 466,488
 • Estimate (2011) 477,891
 • Density 4,700/sq mi (1,800/km2)
 • Urban 1,440,000
 • Urban density 5,800/sq mi (2,300/km2)
 • Metro 2,600,000
 • Metro density 7,300/sq mi (2,800/km2)
Geobox
settlement
Area 100.105 sq mi (259 km2)
 - land 97.915 sq mi (254 km2)
 - urban 246.8 sq mi (639 km2)
 - metro 357.9 sq mi (927 km2)
Population 466,488 (2010)
 - urban 1,440,000
 - metro 2,600,000
Density 4,660 / sq mi (1,799 / km2)
 - urban 5,835 / sq mi (2,253 / km2)
 - metro 7,265 / sq mi (2,805 / km2)
I agree with the suggested change, but to make it simpler I would keep the title Density if calculated based on area_total and use the title Density (land) if calculated based on area_land. I also have two related suggestions that I think should be implemented at the same time:
Suggestion #1: To the far right is an infobox with population_total (for an official census) and population_est (for a more recent estimate). As can be seen in the example (or by examining Template:Infobox settlement/densdisp), the auto density calculation is currently population_total divided by area_total (4660 which the template rounds to 4700), not divided by population_est (4774 which would be rounded to 4800). However, this may not be clear to the reader since the density appears below the estimated population. Therefore I suggest that the density be displayed above the estimate, immediately below the total population, as is done with both the urban and metro population densities (note: Geobox uses a different order, which is all populations first, followed by all densities).
Suggestion #2: The auto density calculation should be rounded to the nearest whole number. In the examples to the right, the auto density calculation in Template:Geobox rounds to 4660 (the nearest whole number) but Template:Infobox municipality rounds to 4700. This is handled in Template:Infobox settlement/densdisp which appears to round the number based on its order of magnitude. If there is no good reason to do this, that code could be simplified to always display a whole number. If there is a good reason to leave it as is, then I suggest the addition of a parameter named population_density_round (such as exists in Template:Geobox) which could override the default rounding for the auto calculated density.
-- Zyxw (talk) 06:47, 29 January 2013 (UTC)

Template redesign feeler[edit]

Hello, everyone! Let me preface this with a disclosure that I've never been a great fan of this template, feeling that its bloat and inflexibility often comes in the way of its expansive features and suitability for a great array of needs. While my feelings in that area have not really changed, this time I would like to put out a feeler about a possibility of this template's redesign.

First off, this is neither a call for immediate action, nor a !vote, nor even an RfC, but merely a place to collect other people's thoughts about the proposal which follows. If at any point you see serious problems with this proposal, by all means please post something below. Whatever happens next, this isn't going anywhere until we get the general idea how editors feel.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); November 12, 2014; 22:03 (UTC)

Brief introduction

The way this template is currently built is by providing an expansive set of sections dealing with various aspects which may need to be covered in an infobox. All sections are optional and are not displayed when fed no data. While that is great, once a section is fed proper data, it displays them in a particular way and in a particular place; in other words, the template's section order is rigid and unchangeable and same goes for the internal organization of individual sections. While in many situations that does not really matter, in some it creates problems.

Problems

On some occasions, Infobox Settlement (IS) cannot be used. While many stand-alone templates had been re-designed into IS wrappers over the past few years, there are still a few holdouts for which utilizing a separate template unrelated to IS is a more practical solution. The most common such problems include infoboxes with sections whose formatting is significantly different from what IS provides, where section order is important and different from the section order used by IS, where more than one section of the same type is required, or where IS is missing some very specific section. Modifying IS in its current form to address those problems is often impractical, since it requires adding large chunks of code to deal with only a handful of articles, adding to bloat and confusion.

Proposal

All of the problems above and more can be addressed by replacing IS (as a catch-all concept) with a set of building blocks handling individual sections and by making sure those building blocks can be seamlessly combined. There would be, for example, a separate template for names, for symbols (flags, coats of arms, anthems, etc.), for maps, divisions, government information, and so on.

Benefits
  • Building blocks provide a more manageable solution for customizing the sections, while still supporting overall standardization.
  • Building blocks themselves can be more customizable than IS sections currently are.
  • Discussions dealing with individual building blocks can be consolidated and kept separate from the overall IS discussions, where anything and everything is dealt with all in one place.
  • The building blocks can be combined in any order, which makes possible re-arranging them in cases where order is important.
  • Existing stand-alone templates, many of which currently duplicate much of the IS functionality yet are still kept separate due to the presence of important, but highly specific information, can be re-written using the standard building blocks. Separate, country-specific blocks can be created and plugged only into the country-specific wrappers.
  • Once all of the building blocks are available, IS itself can be re-written to utilize their standard forms. If done correctly, none of the articles currently relying on IS will be affected. Crudely, the IS code (or, indeed, the code of any template using these blocks) will look something like this:
    {{Infobox settlement|{{Names block|params}}{{Symbols block|params}}{{Maps block|params}}...}}
  • This point is so important, that I'll repeat it: if the proposal is implemented properly, no edits to individual articles will be required, nor will there be any visual change (unless one is desired and provided from within the building blocks themselves).
Conclusion

Frankly, I'm not seeing any downsides to this solution. The biggest obstacle, of course, is finding volunteers to design the building blocks and to make sure they all fit seamlessly together. The hope is that volunteers will show up if this proposal is favorably received. Please add your thoughts in the Discussion section below, and thank you for your time and consideration!

Discussion[edit]

Adding pronunciation information to template[edit]

I have recently started an RfC on whether to add pronunciation information to person infoboxes (not necessarily to move pronunciations to the infobox, but to at the very least give the option). I think in general it would be useful to have the pronunciation in the infobox even if it is in the lead, but it's particularly relevant for names of people and places where the pronunciation might be useful information, but which is not so non-intuitive as to really justify space in the lead (this may be particularly for non-native speakers who may have different intuitions about how a place name would be pronounced and where the emphasis might go). I was thinking it would likely be useful to do the same thing here, re-using the same implementation that will eventually be used at {{Infobox person}} in this infobox. It does not seem to be a very controversial addition over at {{Infobox person}}, so I'm thinking there probably doesn't need to be a separate RfC here. If you have some objections or think a separate RfC is warranted, please let me know. Comments at the RfC are also appreciated. Thanks. 0x0077BE (talk · contrib) 15:12, 17 November 2014 (UTC)

Removal of dot map function[edit]

I would like to propose the removal of the |image_dot_map= since they are generally inferior to |pushpin_map=. the usage has been tracked in Category:Settlement articles with dot maps, which is now empty. in the rare case where it's not possible/desirable to use a {{location map}} you can always pass a call to {{infobox map}} through the |image_map= parameter. removing the |image_dot_map= would simplify the code, reducing the complexity. any objections or comments? Frietjes (talk) 18:46, 25 November 2014 (UTC)

I have no objections to removing obsolete code. CRwikiCA talk 18:54, 25 November 2014 (UTC)
Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:59, 25 November 2014 (UTC)
now removed and I added a check for any non-blank unsupported parameters which will most likely significantly expand Category:Settlement articles requiring maintenance. Frietjes (talk) 16:38, 26 November 2014 (UTC)

Pocahontas County, Iowa[edit]

I've been trying to get an image into the infobox there and haven't made any progress. I've left the article with the line

"| image_skyline = File:Pocahontas County Courthouse.JPG" in it, which doesn't show up, but have tried several other variation, e.g. without the "File:"

What am I doing wrong?

Smallbones(smalltalk) 20:31, 30 November 2014 (UTC)

Smallbones, that article uses {{Infobox U.S. county}}, which is a different infobox. Frietjes (talk) 15:52, 1 December 2014 (UTC)
Fantastic! Smallbones(smalltalk) 16:09, 1 December 2014 (UTC)

Location map no longer centred[edit]

Can this edit by reverted? The location map is no longer horizontally centred. 213.7.22.7 (talk) 12:38, 8 December 2014 (UTC)

@Gadget850: There was already a float parameter set to none on lines 107, 152 and 179. You're gonna have to remove these if |float=center is gonna work. 213.7.22.7 (talk) 12:52, 8 December 2014 (UTC)
fixed. Frietjes (talk) 17:08, 8 December 2014 (UTC)
Thanks: I will keep an eye out for that in the future. --  Gadget850 talk 17:14, 8 December 2014 (UTC)