Jump to content

Wikipedia talk:WikiProject Elections and Referendums/Archive 11

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5←Archive 9Archive 10Archive 11Archive 12Archive 13→Archive 15

Kinds of tree maps and other county maps

We should prefer a tree map of election outcomes that includes both major candidates, and groups in the third parties, by breaking down the counties by color (fourth image on the right) rather than use color tone to convey the county's winner's [sic] proportion (second image). I prefer pies on maps over either, but between these two tree maps, the one we're using is misleading.

I'm normally a big fan of tree maps because empirical data says they give readers the least error-prone estimate of the actual data. They also use the entire rectangle of page space you allocate, rather than wasting space, like pies, or bar charts. But they have their limits. The wasted space of pies gets turned into a feature when you're using that wasted space to display geography, as when you put pies on maps. Pies often mislead readers, but when there are only two, or maybe three, colors, it's not a large error.

The most misleading graphs are filled areas of geography, such as File:Nevada Presidential Election Results 2016.svg. The overwhelming impression is that this is a landslide for Trump in red, because it dominates the view. This map doesn't even give you any idea who even won, let alone by how much, because it contains no information whatsoever about how many votes were cast. Elections are, if nothing else, about how many votes were counted, yet here is this ubiquitous graph that leaves out how many votes were counted. WTF? It only shows the size of the lead of a candidate by acre of land, which is a statistic that means nothing at all. The only reason to keep these is inertia.

So a tree map like File:United States presidential election in Nevada, 2016.svg is a big improvement, but it's still misleading. At least you can say the data is all there: number of votes is shown by size and their lead is there. Sort of. You have no idea if they had a plurality or a majority in the county. It strongly implies that counties are "won", by coloring the whole county for the candidate, when in fact states are won. It's very misleading to introduce prizes into elections that don't exist, especially hen the American electoral college system is confusing enough. Given the inherent confusion, where should never introduce more red herrings like, "number of counties won". The obvious problem with File:United States presidential election in Nevada, 2016.svg is that it's awash in blue, implying that blue won the state by a landslide. At least we get the idea of who the winner of the state is, which is more than you can say for the filled area. But it fails to convey the important fact that neither candidate in Nevada 2016 won a majority, and it tells us nothing about third party candidates. Communicating the margin by intensity of color is not accurate; readers have little chance of approximating the numbers.

Or consider File:United States presidential election in Connecticut, 2016.svg. The majority of almost 55% by Clinton in blue leaves almost the same as the 47.92%/45.50% plurality win in Nevada. Two somewhat different election outcomes should look somewhat different.

There's no good way to do this, and I still think that pies on a map like, File:Nevada 2016 presidential results by county.png is the best compromise, because you can see if it was close or a landslide, and who got proportionately how many votes, and what the geographic concentration is.

But since we can simply use multiple graphs, I think we should change the way the tree maps are presented. File:Tree map of Nevada 2016 Presidential election by county.png. This shows each county's size by the number of votes, but it also includes the size of each candidate within that county, so that it creates a clearer impression of how well they actually did, such as a close race or landslide, plurality or majority. It also conveys the role of third party candidates. There are lots of improvements possible here, but I thin the basic idea is better than the tree maps (or filled maps) that used color intensity only for the candidate with the most votes in the county, incorrectly implied to be the "winner" of the country. --Dennis Bratland (talk) 00:01, 2 March 2017 (UTC)

I would prefer to use all three when available; the shaded county map is definitely the simplest and provides a quick view of who received the most votes in each county; while the pie map more accurately displays the data, it is slightly more confusing to read. The tree map's main flaw is that it gives no indication of the location of the counties in question (and therefore should not be used alone), otherwise it is great. MB298 (talk) 01:11, 2 March 2017 (UTC)
I'm sorry I rambled on about so many different things, but the question I meant to ask is: which of the two types tree maps shown above do we prefer, File:United States presidential election in Nevada, 2016.svg or File:Tree map of Nevada 2016 Presidential election by county.png? We have many examples of the first type on various articles, and I think they're OK, but kind of misleading. Instead of color grades, I think we should split the counties in the tree map to show the proportions of votes between candidate A, B, and other. --Dennis Bratland (talk) 01:44, 2 March 2017 (UTC)

@Dennis Bratland: There was already a discussion about using those pie chart maps, and we agreed that those are helpful, as they are already in the infobox of each state's election article. For the tree maps, I understand what you are saying, but there are many reasons that I decided to create those treemaps. The discussion you are bringing about treemaps doesn't sound right to me. You mentioned your opinion about using "color intensity" in the maps and other types charts, and said it is not the best way to present the data. Using "color intensity" has been already accepted in Wikipedia for a long time and changing that policy most likely would not be acceptable for many users. Actually changing that policy means removing and replacing every single election map (that used color intensity) in any articles we find! I actually found maps using color intensity really helpful, as MB298 said, they "provides a quick view of who received the most votes in each county". This is exactly the whole goal! For the treemaps I created, the main goal is to provide a basic view of each single county and showing what candidate is popular + showing how the each county, based on its population, affects the election result in each state.
You also said those treemaps are "misleading". As it is been already typed below each treemap, percent difference of the votes between the major candidates is shown for each county, and it doesn't mean “other candidates” were waived. It is also worth to mention that not a single “other candidate” won a single county in the United States, in 2016 election. Besides that, I've already given the link of the raw data in the source part of each file. If any reader wants the exact data, he/she may open the link and find each county number and percentages (by more than 10 significant figures!).
Another reason for using the current treemaps is type of them. They are SVG files (the most accepted type of images that are used in Wikipedia pages). You can zoom on each treemap and the image doesn’t lose its quality (unlike PNG or JPG images). It means that small counties would be clearly visible by simply zooming on the image. But in the new treemap that you offered, it wouldn’t be possible.
Another problem with the new treemap is that small counties do not even have their name on the treemap. Besides that, dividing each county into three parts make the treemap extremely confusing (imagine the states with large number of counties). It means it would be much harder and pretty impossible for readers to view how smaller counties actually voted in the election.
Besides all these clear reasons I just gave and more, for me (after working diligently for long hours and hours on these treemaps), it’s too unfair and very discouraging to see a discussion about removing or replacing the current treemaps. Ali 14:41, 2 March 2017 (UTC)

  • Using color tones on election maps is not a Wikipedia policy. See policy. The fact that something has been done several times is not a good enough reason to keep doing it. The whole point of how Wikipedia works is that it can change. Saying because it's policy is false, it's not policy. Saying, because we've done it many times only begs the question. Why keep doing it if it there's a better option?
  • It isn't possible to have any graphic that has the names of the smallest-population counties at the same scale as the largest, let alone have legible names written on them. In California in 2016 Los Angeles county had 3.4 million votes, while Alpine had 602. That's a ratio of 5,700 to 1. How are you going to have legible words on Alpine county, and then show LA County 5,700 times larger? It isn't important because counties, in any election, in any state, that have so few votes relative to the largest that you can't fit the names on don't matter enough to worry. If it's 1,000 times smaller than a rounding error, then we don't need to know the name of it.

    This inability to comprehend scale is at the core of many of the graphic misconceptions. File:United States presidential election in Nevada, 2016.svg is almost 2,904 × 3,201 pixels in order to allow the microscopic text of the Esmerelda county to be legible. The same graph could be made just as absurdly large in PNG or any other format, if we really wanted to. But why?

  • Choosing a misleading or uninformative graphic simply because it's in your preferred format is very destructive. SVG is great and all, but if the desire for the features of SVG is preventing us from meeting more basic goals of accuracy, then our priorities are backwards. This habit of demanding SVG files is also part of the pattern of excluding editors from participation. Most people don't have access to SVG editing tools. Most editors will make graphs in common GIF, PNG and JPEG formats. We cannot reject contributions because they aren't in your favorite, obscure and esoteric format.
  • All of these points are red herrings. The heart of the matter is whether or not readers can get any information from a tree map where area represents the number of votes and color tone represents the percent difference between candidates. I have a simple question: how do you multiply area times color tone? If area 1 is twice area 2, but area 1 is a lighter color tone, are they equal? You're asserting that a graph that shows votes as area and percent difference as color tone communicates the election outcome, but it communicates nothing. The tone times the area is not a meaningful value.
As with the previous attempts to justify the filled maps, nobody has provided evidence that it communicates the data. Filled maps communicate nothing. Tree maps with color tones are unreadable because tone x size is not a number. This is all so much decoration with no function. --Dennis Bratland (talk) 18:28, 3 March 2017 (UTC)

Examples

Here is a basic example for comparison:

The color gradient tree map shows some very simple data which should be a very easy case. But what can you tell from this image? We should be able to see that these two states had identical outcomes: 60 votes for Whig, 40 for Know Nothing. The added detail that one state has two counties and the other has only one complicates things so much that they look totally different. Is it realistic for anyone to be able to mentally estimate that the large lead of Whig in First County in Michitoba creates an equivalent outcome to Arizolania?

State County Party Votes
Arizolania One big county Know Nothing 40
Arizolania One big county Whig 60
Michitoba First county Know Nothing 20
Michitoba First county Whig 40
Michitoba Second county Know Nothing 20
Michitoba Second county Whig 20

Now consider the same two states, same data, but encoding all the vote data as size, and using color only to distinguish parties:

Parties grouped together

We haven't lost the information that the counties are different in the two states, we can see they tied in First county, but the most basic fact, that each state was a 60/40 win for Whig is immediately clear. Even if you sort the counties above the parties, the visual impact is the same:

counties are sorted together, parties sorted after that

We're seeing nearly identical images for Michitoba and Arizolania because they are nearly identical. The slight difference, the counties, is there, but the major similarity is unmistakable.

Now consider a more complicated example:

Does this tell us what happened? It should be saying things like: Whig won a close race with a small plurality. Nobody reached a majority. The third party played a significant role. Who won? This color gradient graph actually makes it look like Whig lost the state.

State County Party Votes
Pluto A county Know Nothing 40
Pluto A county Third party 10
Pluto A county Whig 20
Pluto B county Know Nothing 30
Pluto B county Third party 30
Pluto B county Whig 30
Pluto C county Know Nothing 10
Pluto C county Third party 1
Pluto C county Whig 60

Here is the simpler tree map.

The existence of the third party is shown. We didn't even know there was a third party in the color gradient example. It's still clearly a close race, and you could be unsure who won from this image. But it is at least possible to detect that the red area is larger than the others.

The reason why these work better is that they don't code vote totals in two ways: percentage difference AND size. Instead, the actual data, number of votes by party and county, has a 1 to 1 relationship with how much color is on the graph. You don't have to distinguish 10 different tones of red and 10 others of blue. Note that the pie-on-map graph has the same 1 to 1 relationship with vote totals; the amount of color you see is telling you how many votes each candidate got. You see it and don't have to try to work it out.

Another question: what would happen if a third party actually won a county? The color gradients have no way to account for that. That information is simply lost.

Many more examples are possible. Even in the best case, you're putting a lot of work on the reader to decode these color tones and sizes, and in the end, they have to scroll down and read the crosstab if they really want to know what happened. Even the simplest facts about the election are a mystery. Why would we want to keep doing it this way if we don't have to? It's fine if one editor doesn't have the capabilty to produce this or that kind of graphy, but any time another editor can, we should favor the better one.

You are already giving the same reasons that you've given before (with more pictures), and based on the clear reasons that I just stated, I strongly oppose. Ali 16:10, 4 March 2017 (UTC)
Yes, it shouldn't be necessary for me to have to go into so much detail, and to have to provide illustrious for facts that are obvious. But you are disputing obvious facts, forcing me to rebut them point by point. The claim that using color intensity is a "policy" is false, or and it has not been "accepted" in any meaningful sense. You don't cite this supposed consensus or policy because it doesn't exist. Sorry to say, but you're making it up.

This obsession with "who received the most votes in each county" is really turning into a problem. It's overemphasized in the overused filled maps, then overemphasized again in these color tone tree maps, on top of the harmful practice of coloring county-level results tables red or blue to overemphasize the "winner" of the county.

One other important falsehood to mention here is this one: "Actually changing that policy [sic] means removing and replacing every single election map (that used color intensity) in any articles we find!" My proposal to "prefer a tree map of election outcomes that includes both major candidates, and groups in the third parties" rather than using color tone, does not mean removing and replacing anything. It means in cases where both options are available, we would prefer one over the other. If the only graph we have is the tree map with color tones, replacing it isn't mandatory.

I'm sorry so much time must be spent on these long rebuttals, but this is what happens when you make false assertions. If you would be more careful with facts, we could focus on more important questions. --Dennis Bratland (talk) 20:03, 4 March 2017 (UTC)

Some bad data in 2016 United States presidential election Treemaps

There's another problem: the data for 2016 United States presidential election Treemaps is sourced at Github, meaning it's self-published. Apparently two people are maintaining it, collected from media sources such as The Guardian. This might work out, but it appears that it's outdated. Either the Guardian, or whoever these guys are at Github, didn't update it with the latest official results from the Secretaries of State or elections commissions. I haven't checked every row of data, but when I compare the states of Nevada and Wisconsin (post-recount), there are small discrepancies. It might not be enough to make a big difference on the graphic in most cases. In some cases (Sawyer County, Wisconsin) the discrepancy is quite large, more than 10%.

We shouldn't be citing any personal web repositores or self-published data troves. The cited source for our data should be the original, preferably the official state source, or else a reputable media publication.

It shouldn't be a big deal that there's some errors here. Wikipedia is all about incremental changes that move us closer to perfection. But one of the things I'm trying to say about this "policy" [sic] of having this one type of map across many articles, and this "policy" [sic] of insisting on SVG, is that it prevents others from correcting errors. If next year we're all elsewhere, and some new editor discovers errors in some election data, it shouldn't be onerous for that new editor to make corrections and upload a new tree map or county map. But if we're clinging to this specific graph style, and excluding commonly available file formats like PNG, GIF and JPG, then that makes it all the harder to fix any future errors, and generally maintain articles. That's why I dislike this argument that we have to do X because X is done on lots of other articles. I'd rather be inconsistent if it means maintainability and error correction.

Github/Guardian? Secretary of State Official Differences
State County Name Votes Dem Votes Gop Total Votes County Clinton Trump (other) Grand Total Dem Error Rep Error Total Error Dem error % Rep error % Total error
Nevada Carson City 9,610 13,125 25,016 Carson City 9,610 13,125 2,281 25,016 0 0 0 0.0% 0.0% 0.0%
Nevada Churchill County 2,210 7,828 10,936 Churchill 2,210 7,830 898 10,938 0 -2 -2 0.0% 0.0% 0.0%
Nevada Clark County 401,068 319,571 765,421 Clark 402,227 320,057 44,872 767,156 -1,159 -486 -1,735 -0.3% -0.2% -0.2%
Nevada Douglas County 8,453 17,406 27,871 Douglas 8,454 17,415 2,016 27,885 -1 -9 -14 0.0% -0.1% -0.1%
Nevada Elko County 3,400 13,542 18,545 Elko 3,401 13,551 1,607 18,559 -1 -9 -14 0.0% -0.1% -0.1%
Nevada Esmeralda County 65 329 423 Esmeralda 65 329 29 423 0 0 0 0.0% 0.0% 0.0%
Nevada Eureka County 74 723 854 Eureka 74 723 57 854 0 0 0 0.0% 0.0% 0.0%
Nevada Humboldt County 1,386 4,521 6,433 Humboldt 1,386 4,521 526 6,433 0 0 0 0.0% 0.0% 0.0%
Nevada Lander County 403 1,828 2,413 Lander 403 1,828 182 2,413 0 0 0 0.0% 0.0% 0.0%
Nevada Lincoln County 285 1,671 2,132 Lincoln 285 1,671 176 2,132 0 0 0 0.0% 0.0% 0.0%
Nevada Lyon County 6,146 16,005 23,762 Lyon 6,146 16,005 1,611 23,762 0 0 0 0.0% 0.0% 0.0%
Nevada Mineral County 637 1,179 1,997 Mineral 637 1,179 181 1,997 0 0 0 0.0% 0.0% 0.0%
Nevada Nye County 5,095 13,320 19,592 Nye 5,094 13,324 1,177 19,595 1 -4 -3 0.0% 0.0% 0.0%
Nevada Pershing County 430 1,403 1,982 Pershing 430 1,403 149 1,982 0 0 0 0.0% 0.0% 0.0%
Nevada Storey County 752 1,616 2,558 Storey 752 1,616 190 2,558 0 0 0 0.0% 0.0% 0.0%
Nevada Washoe County 97,032 94,529 209,282 Washoe 97,379 94,758 17,772 209,909 -347 -229 -627 -0.4% -0.2% -0.3%
Nevada White Pine County 707 2,723 3,773 White Pine 707 2,723 343 3,773 0 0 0 0.0% 0.0% 0.0%
Nevada Grand Total 537,753 511,319 1,122,990 Grand Total 539,260 512,058 74,067 1,125,385 -1,507 -739 -2,395 -0.3% -0.1% -0.2%
Wisconsin Adams County 3,780 5,983 10,107 Adams 3,745 5,966 419 10,130 35 17 -23 0.9% 0.3% -0.2%
Wisconsin Ashland County 4,136 3,428 7,926 Ashland 4,226 3,303 503 8,032 -90 125 -106 -2.1% 3.8% -1.3%
Wisconsin Barron County 7,881 13,595 22,514 Barron 7,889 13,614 1,168 22,671 -8 -19 -157 -0.1% -0.1% -0.7%
Wisconsin Bayfield County 4,953 4,125 9,491 Bayfield 4,953 4,124 535 9,612 0 1 -121 0.0% 0.0% -1.3%
Wisconsin Brown County 53,358 67,192 127,497 Brown 53,382 67,210 8,419 129,011 -24 -18 -1,514 0.0% 0.0% -1.2%
Wisconsin Buffalo County 2,531 4,049 6,921 Buffalo 2,525 4,048 408 6,981 6 1 -60 0.2% 0.0% -0.9%
Wisconsin Burnett County 2,948 5,412 8,719 Burnett 2,949 5,410 379 8,738 -1 2 -19 0.0% 0.0% -0.2%
Wisconsin Calumet County 9,634 15,345 26,429 Calumet 9,642 15,367 1,586 26,595 -8 -22 -166 -0.1% -0.1% -0.6%
Wisconsin Chippewa County 11,875 17,912 31,471 Chippewa 11,887 17,916 1,765 31,568 -12 -4 -97 -0.1% 0.0% -0.3%
Wisconsin Clark County 4,225 8,645 13,548 Clark 4,221 8,652 800 13,673 4 -7 -125 0.1% -0.1% -0.9%
Wisconsin Columbia County 13,525 14,160 29,287 Columbia 13,528 14,163 2,007 29,698 -3 -3 -411 0.0% 0.0% -1.4%
Wisconsin Crawford County 3,426 3,844 7,678 Crawford 3,419 3,836 473 7,728 7 8 -50 0.2% 0.2% -0.6%
Wisconsin Dane County 217,506 71,270 304,729 Dane 217,697 71,275 20,382 309,354 -191 -5 -4,625 -0.1% 0.0% -1.5%
Wisconsin Dodge County 13,968 26,643 42,818 Dodge 13,968 26,635 2,475 43,078 0 8 -260 0.0% 0.0% -0.6%
Wisconsin Door County 8,026 8,584 17,398 Door 8,014 8,580 998 17,592 12 4 -194 0.1% 0.0% -1.1%
Wisconsin Douglas County 11,342 9,657 22,185 Douglas 11,357 9,661 1,518 22,536 -15 -4 -351 -0.1% 0.0% -1.6%
Wisconsin Dunn County 9,025 11,487 22,029 Dunn 9,034 11,486 1,586 22,106 -9 1 -77 -0.1% 0.0% -0.3%
Wisconsin Eau Claire County 27,271 23,301 54,080 Eau Claire 27,340 23,331 4,354 55,025 -69 -30 -945 -0.3% -0.1% -1.7%
Wisconsin Florence County 666 1,897 2,651 Florence 665 1,898 93 2,656 1 -1 -5 0.2% -0.1% -0.2%
Wisconsin Fond du Lac County 17,391 31,044 51,094 Fond Du Lac 17,387 31,022 3,387 51,796 4 22 -702 0.0% 0.1% -1.4%
Wisconsin Forest County 1,583 2,787 4,507 Forest 1,579 2,787 179 4,545 4 0 -38 0.3% 0.0% -0.8%
Wisconsin Grant County 10,047 12,347 24,051 Grant 10,051 12,350 1,967 24,368 -4 -3 -317 0.0% 0.0% -1.3%
Wisconsin Green County 9,121 8,693 18,791 Green 9,122 8,693 1,170 18,985 -1 0 -194 0.0% 0.0% -1.0%
Wisconsin Green Lake County 2,700 6,210 9,315 Green Lake 2,693 6,216 507 9,416 7 -6 -101 0.3% -0.1% -1.1%
Wisconsin Iowa County 6,669 4,809 12,123 Iowa 6,669 4,809 797 12,275 0 0 -152 0.0% 0.0% -1.2%
Wisconsin Iron County 1,273 2,090 3,477 Iron 1,275 2,081 157 3,513 -2 9 -36 -0.2% 0.4% -1.0%
Wisconsin Jackson County 3,821 4,907 9,202 Jackson 3,818 4,906 543 9,267 3 1 -65 0.1% 0.0% -0.7%
Wisconsin Jefferson County 16,559 23,409 42,324 Jefferson 16,569 23,417 3,123 43,109 -10 -8 -785 -0.1% 0.0% -1.8%
Wisconsin Juneau County 4,100 7,188 11,736 Juneau 4,073 7,130 532 11,735 27 58 1 0.7% 0.8% 0.0%
Wisconsin Kenosha County 35,770 36,025 75,825 Kenosha 35,799 36,037 4,468 76,304 -29 -12 -479 -0.1% 0.0% -0.6%
Wisconsin Kewaunee County 3,623 6,616 10,742 Kewaunee 3,627 6,618 522 10,767 -4 -2 -25 -0.1% 0.0% -0.2%
Wisconsin La Crosse County 32,402 26,384 62,785 La Crosse 32,406 26,378 4,890 63,674 -4 6 -889 0.0% 0.0% -1.4%
Wisconsin Lafayette County 3,288 3,977 7,602 Lafayette 3,288 3,977 397 7,662 0 0 -60 0.0% 0.0% -0.8%
Wisconsin Langlade County 3,260 6,436 10,093 Langlade 3,250 6,478 458 10,186 10 -42 -93 0.3% -0.6% -0.9%
Wisconsin Lincoln County 5,370 8,400 14,563 Lincoln 5,371 8,401 940 14,712 -1 -1 -149 0.0% 0.0% -1.0%
Wisconsin Manitowoc County 14,563 23,234 39,991 Manitowoc 14,538 23,244 3,004 40,786 25 -10 -795 0.2% 0.0% -1.9%
Wisconsin Marathon County 26,476 39,010 68,849 Marathon 26,481 39,014 4,023 69,518 -5 -4 -669 0.0% 0.0% -1.0%
Wisconsin Marinette County 6,243 12,995 19,979 Marinette 6,409 13,122 812 20,343 -166 -127 -364 -2.6% -1.0% -1.8%
Wisconsin Marquette County 2,808 4,712 7,813 Marquette 2,808 4,709 374 7,891 0 3 -78 0.0% 0.1% -1.0%
Wisconsin Menominee County 1,003 269 1,279 Menominee 1,002 267 39 1,308 1 2 -29 0.1% 0.7% -2.2%
Wisconsin Milwaukee County 288,986 126,091 434,970 Milwaukee 288,822 126,069 26,162 441,053 164 22 -6,083 0.1% 0.0% -1.4%
Wisconsin Monroe County 7,047 11,442 19,554 Monroe 7,052 11,356 1,291 19,699 -5 86 -145 -0.1% 0.8% -0.7%
Wisconsin Oconto County 5,886 13,255 19,924 Oconto 5,940 13,345 921 20,206 -54 -90 -282 -0.9% -0.7% -1.4%
Wisconsin Oneida County 8,103 11,677 20,837 Oneida 8,109 12,132 1,290 21,531 -6 -455 -694 -0.1% -3.8% -3.2%
Wisconsin Outagamie County 38,087 49,884 93,474 Outagamie 38,068 49,879 5,986 93,933 19 5 -459 0.0% 0.0% -0.5%
Wisconsin Ozaukee County 20,167 30,458 53,368 Ozaukee 20,170 30,464 3,926 54,560 -3 -6 -1,192 0.0% 0.0% -2.2%
Wisconsin Pepin County 1,345 2,228 3,746 Pepin 1,344 2,206 185 3,735 1 22 11 0.1% 1.0% 0.3%
Wisconsin Pierce County 8,380 11,260 21,089 Pierce 8,399 11,272 1,705 21,376 -19 -12 -287 -0.2% -0.1% -1.3%
Wisconsin Polk County 7,568 13,864 22,691 Polk 7,565 13,810 1,370 22,745 3 54 -54 0.0% 0.4% -0.2%
Wisconsin Portage County 18,524 17,310 38,123 Portage 18,529 17,305 2,755 38,589 -5 5 -466 0.0% 0.0% -1.2%
Wisconsin Price County 2,671 4,562 7,560 Price 2,667 4,559 342 7,568 4 3 -8 0.1% 0.1% -0.1%
Wisconsin Racine County 42,506 46,620 93,678 Racine 42,641 46,681 4,980 94,302 -135 -61 -624 -0.3% -0.1% -0.7%
Wisconsin Richland County 3,577 4,021 7,962 Richland 3,569 4,013 487 8,069 8 8 -107 0.2% 0.2% -1.3%
Wisconsin Rock County 39,336 31,483 75,043 Rock 39,339 31,493 5,242 76,074 -3 -10 -1,031 0.0% 0.0% -1.4%
Wisconsin Rusk County 2,171 4,564 7,029 Rusk 2,171 4,564 353 7,088 0 0 -59 0.0% 0.0% -0.8%
Wisconsin Sauk County 14,692 14,791 31,238 Sauk 14,690 14,799 1,868 31,357 2 -8 -119 0.0% -0.1% -0.4%
Wisconsin Sawyer County 2,846 4,625 7,767 Sawyer 3,503 5,185 449 9,137 -657 -560 -1,370 -18.8% -10.8% -15.0%
Wisconsin Shawano County 6,056 12,742 19,697 Shawano 6,068 12,769 973 19,810 -12 -27 -113 -0.2% -0.2% -0.6%
Wisconsin Sheboygan County 22,636 32,368 58,290 Sheboygan 23,000 32,514 4,252 59,766 -364 -146 -1,476 -1.6% -0.4% -2.5%
Wisconsin St. Croix County 17,496 26,123 46,819 St. Croix 17,482 26,222 3,804 47,508 14 -99 -689 0.1% -0.4% -1.5%
Wisconsin Taylor County 2,398 6,589 9,417 Taylor 2,393 6,579 499 9,471 5 10 -54 0.2% 0.2% -0.6%
Wisconsin Trempealeau County 5,645 7,370 13,581 Trempealeau 5,636 7,366 685 13,687 9 4 -106 0.2% 0.1% -0.8%
Wisconsin Vernon County 6,351 6,994 14,193 Vernon 6,371 7,004 900 14,275 -20 -10 -82 -0.3% -0.1% -0.6%
Wisconsin Vilas County 4,769 8,169 13,453 Vilas 4,770 8,166 675 13,611 -1 3 -158 0.0% 0.0% -1.2%
Wisconsin Walworth County 18,706 28,848 50,570 Walworth 18,710 28,863 3,818 51,391 -4 -15 -821 0.0% -0.1% -1.6%
Wisconsin Washburn County 3,283 5,404 9,059 Washburn 3,282 5,436 475 9,193 1 -32 -134 0.0% -0.6% -1.5%
Wisconsin Washington County 20,854 51,729 76,246 Washington 20,852 51,740 4,165 76,757 2 -11 -511 0.0% 0.0% -0.7%
Wisconsin Waukesha County 79,200 142,521 233,273 Waukesha 79,224 142,543 15,826 237,593 -24 -22 -4,320 0.0% 0.0% -1.8%
Wisconsin Waupaca County 8,303 16,013 25,491 Waupaca 8,451 16,209 1,435 26,095 -148 -196 -604 -1.8% -1.2% -2.3%
Wisconsin Waushara County 3,802 7,669 11,961 Waushara 3,791 7,667 616 12,074 11 2 -113 0.3% 0.0% -0.9%
Wisconsin Winnebago County 37,054 43,447 85,892 Winnebago 37,047 43,445 6,643 87,135 7 2 -1,243 0.0% 0.0% -1.4%
Wisconsin Wood County 14,232 21,502 37,712 Wood 14,225 21,498 2,095 37,818 7 4 -106 0.0% 0.0% -0.3%
Wisconsin Grand Total 1,380,823 1,403,694 2,937,326 Grand Total 1,382,536 1,405,284 188,330 2,976,150 -1,713 -1,590 -38,824 -0.1% -0.1% -1.3%

--Dennis Bratland (talk) 23:16, 4 March 2017 (UTC)

Well, for me, updating these SVG treemaps, after working hours on them, is not a big deal now. I would gladly take any requests regarding the data and updating those treemaps! Also it definitely worth to mention that by looking at "Total error" part of the table, you can see that there is barely 1% error for some counties and for most of the counties the "total error" is actually less than 1%!. It means since I use "color intensity", by using the updated data, the treemap would not change at all, but again I am glad to check your preferred source of data and update every single treemap! Ali 01:02, 5 March 2017 (UTC)
Yes, mostly the errors are small, which is why I said "It might not be enough to make a big difference on the graphic in most cases". But there is one case, after checking only two states, where the error is significant. I'm not sure what part of this you're objecting to. If all 50 states have a similar error pattern, then perhaps 25 states have a county that is off by a lot. Who knows?

It's great that you are willing to check the data (Using my "preferred source"? There us only one source, the official count), but you're missing the point. This attitude of resistance to change, and the unwillingness to accept any graphs that deviate from the type used on the other election maps, and rejecting maps merely because they don't use SVG, means that if you're not around, fixing any newly discovered errors is going to be rather difficult. Are you using custom software of your own creation to generate these tree maps? We have to be willing to accept contributions by any editor, using a wide variety of commonly available tools, especially free, low cost, and non-proprietary tools.

Once again, I'm just giving a paraphrase of Wikipedia:Editing policy. We can't get there from here unless we can take small steps, and unless we do everything possible to let anyone edit. Instead of giving objective reasons why alternate graphs should be rejected, you're giving reasons that limit who can edit. That is a bigger problem than one graph that is a little hard to read or has a few data errors. --Dennis Bratland (talk) 01:28, 5 March 2017 (UTC)

Nobody is trying to prevent you from adding your graphs, but you are trying to delete and remove the graphs I made without giving enough supportive reasons, and that is completely unacceptable here. To me, it seems you really like to start an edit war! Ali 01:34, 5 March 2017 (UTC)
No, you started an edit war. I objected to a change you were making, and you ignored me, and continued on your merry way as if my objections were irrelevant. Yet when I behave in exactly the same way as you, you accuse me of starting an edit war. Your self-justification is that you perceive yourself as the "owner" of these election articles, and you perceive me as an interloper. When you do it, your action valid by default. Edits by non-owners, such as myself, are labeled "edit warring" unless I received permission ahead of time from one of the "owners". Needless to say, this is not how Wikipedia works. --Dennis Bratland (talk) 02:34, 5 March 2017 (UTC)
Ok, then you have NO right to touch my treemaps, as I don't touch yours.Ali 04:21, 5 March 2017 (UTC)
"Mine, mine mine!" Listen to you. See, here's the thing. Let's say there's an article about birds, but it doesn't mention ducks. An editor decides to add some content about ducks. Great! Now another editor comes along, and says, "Ducks! I love ducks." That editor keeps the part about ducks, but changes it a little. Adds some, adjusts a little. You're accusing me of "deleting" your addition (which would be totally valid thing to do, by the way) but no, I did not delete your addition of a treemap. I kept a treemap in the article, and kept the same essential information in the treemap. I only made some changes.

The problem here is your assumption that it is "mine mine mine". You think nobody has a right to change "your" work. That is not how Wikipedia works. Everything you do is a donation to Wikimedia that others can take and change some more. You already know this. The policy on ownership of articles is well known to you. --Dennis Bratland (talk) 04:52, 5 March 2017 (UTC)

Ok, if I'm wrong who says you are right?!?! Really! You are telling your false assumptions and do whether you want. Remember, being older doesn't make you wiser! It seems you cannot get convinced, so it is time to notify administrators. Ali 05:00, 5 March 2017 (UTC)
You wanted a treemap added to the article. You got a treemap added to the article. You wanted the graph to show the election results by county. You got a treemap that shows the election results by county. The problem? It isn't your exact treemap graphic. The way you said it was, "you have NO right to touch my treemaps, as I don't touch yours". Once again, the policy ownership of content is clear that you aren't allowed to do this.

Another weird thing: the one and only graphic that you insist we use above all others is based on flawed data, which I detailed above. Yet you reject an alternative that is basically the same graph, but with correct data, as well as being easy enough to read that you can actually tell who won. Imagine that. It matters to some people, you know. Also, I didn't modify your [sic] file, I created a new version.

The edit warring issue is simply this: you think your preferred version is privileged over another editor's. Again, the false belief in content ownership. Alternatively, accept that nobody owns a Wikipedia article, let alone owns the entire category of election articles, and that means we all have to accept compromise. You got almost everything you wanted. I got some of what I wanted, but not much. In the future, more editors will make changes. That, too, is allowed. They can touch your [sic] treemaps, because they are not really yours at all. --Dennis Bratland (talk) 07:27, 5 March 2017 (UTC)

Don’t try to use your own opinion as a fact. Simply, because you don’t like “color intensity” in the maps doesn’t means the maps are wrong and should be deleted; as I said multiple times, I have no problem with using both treemaps at the same time, and after all explanations I gave, you still insist on doing edit wars. I added the RfC, so the dispute may be finally resolved. Ali 18:59, 5 March 2017 (UTC)

Results breakdown articles

Proposals are being made at Wikipedia:Articles for deletion/Results breakdown of the European Parliament election in Spain, 1987 to remove all election breakdown articles (Spain, Canada, UK, Turkey, etc). Further input would be needed, given than this notably affects this WikiProject. Cheers. Impru20 (talk) 07:58, 6 March 2017 (UTC)

Sources for polling tables

Has a consensus ever been established on the formatting of sources for polling tables? Ed88 tagged a bunch of articles with Template:External links a few days ago citing WP:CS#Avoid embedded links and WP:EL#cite_note-7, leading to this discussion on one of the tagged articles' talk pages. Mélencron (talk) 01:54, 7 March 2017 (UTC)

You are invited to join the discussion at Talk:Opinion polling for the French presidential election, 2017#Embedded links in lieu of inline citations. Marchjuly (talk) 03:04, 7 March 2017 (UTC) -- Marchjuly (talk) 03:04, 7 March 2017 (UTC)

Coloring of U.S. presidential ballot access maps

I want to have y'all's input on this before I go recoloring every map on the website. I think that the way that the ballot access maps of the 2016 U.S. presidential election were colored was a bad idea. Since there were a lot of parties that had ballot access, there ended up being a lot of different colors. I personally think it would be better to use one coloring scheme for every map, detailing the type of access they have in a particular state. I'll show you what I mean:

This is the original map.
  On ballot
  Write-in
  Not on ballot
This map shows where Darrell Castle was on the ballot, where he had write-in access and where he wasn't on the ballots. Since the coloring doesn't go into more detail about what his ballot label was, people are led to assume that the Constitution Party had ballot access in all the dark purple states and that every state affiliate nominated Darrell Castle.
This is an example of a new way to color in the original map.
  On ballot
  On ballot, other party
  Write-in access
  Not on ballot
With this type of coloring, you don't have to come up with different colors for different parties. You can also see that Darrell Castle was on the ballot in Idaho, but not as the Constitution Party candidate. This coloring method gives more information, and using a green scheme for every map would make ballot access maps easier to make.

Does this require an RfC, or can I go ahead and recolor all the existing maps? Thank you!--Mr.Election (talk) 22:28, 10 March 2017 (UTC)

I personally would not have any problems with it. Ali 22:46, 10 March 2017 (UTC)

RfC on type of treemap

Note: This is not an RfC as explained at the bottom of the discussion section below.

Option 1
Option 2

Dennis Bratland and I are having a long discussion about using the type of treemap on the 2016 United States presidential election in each state articles. You may see the full discussion here. To prevent the continuous edit war that has been already started, I think RfC can resolve the dispute. The discussion part of this section, which presents the brief and shorten explanations of the previous discussion between me and Dennis Bratland, may help you to decide your vote.

Question
Which type of treemap should be used on United States presidential election in Nevada, 2016 and other articles, related to the 2016 presidential election results in each state?

  • A) Only option 1
  • B) Both option 1 and 2 at the same time
  • C) Only option 2

Survey

  • A) Only option 1 Ali's treemaps are higher quality and provide more information.— Preceding unsigned comment added by Mr.Election (talk • contribs) 5 March 2017 (UTC)
  • Option 1 I support option one, due to the fact that it displays the county results by shading, the structure seems to me to be an easier concept to understand. PalmerTheGolfer (talk)PalmerTheGolfer
  • A (option 1 only) – Option 1 is logical, informative, and visually compelling; option 2 adds no value. — JFG talk 22:13, 5 March 2017 (UTC)
  • A) Only option 1 or B) Both option 1 and 2 at the same time: All advantages of option 1 are already mentioned. I would also agree to option two, since the other map also shows the votes the third parties got, which are invisible at the first option.--Ermanarich (talk) 22:29, 5 March 2017 (UTC)
  • I vote for Option 1. Looks better. – Illegitimate Barrister (talk • contribs), 00:26, 6 March 2017 (UTC)

Discussion

  • Why I support option 1?
    • Option 1 and rest of the treemaps that are same type, have used the exact same logic as the main election maps in the infoboxes. What is their goal and why are they widely used? Because they are simple and provide a quick view of who received the most votes in each county. It means by a glance, a reader can see how each county voted in election, and in what level each county favors one party over another one. It also worths to mention that Dennis Bratland had already shown strong opposition toward the maps that use "color intensity" (including the main maps) and has tried to remove them from the articles, but after several disagreements from multiple users, he was unsuccessful. [1], [2], [3], [4], [5]
    • Please view the option 2 and ,for instance, take Washoe county into the consideration. How a reader can infer that Washoe favored more democrat? As both rectangles in Republican and Democrat side have a close size, it is nearly impossible for a reader to get who got more votes in Washoe county.
    • Unlike option 2, option 1 is a SVG format map. For the graphs and charts (as our main election maps), SVG is the most accepted type of file, because of having several advantages over other types of files (PNG and JPG). Using the SVG format for treemaps means that even the smallest counties would be clearly visible by simply zooming on the image, while image doesn't lose its quality (won't get pixelation). Besides, the small counties on option 2 don't even have their names on them.

As my final word, I would strongly favor option 1 (A) over option 2 and even with all that, I have no problem with using both treemaps at the same time (B). Ali 19:04, 5 March 2017 (UTC)

For the record, your argument on Washoe county is backwards. The 46.39 to 45.14 is very nearly a tie, only 1.25 points separate them. The viewer is supposed to be unable to see a clear winner in Washoe County. There isn't a clear winner; you have to refer to the tabular data to find the winner. By presenting this large swath of blue, the color scale creates a misleading impression that this was a strong victory for Clinton. This is error exacerbated because the 1.25% margin is rounded up to 10%, instead of rounded down to 0%. In the same way that this graph conceals the influence of third parties on a vote, it also conceals ties and near-ties and converts them to 10% margin wins for one or the other. It also create a misleading impression that Washoe county played an important role in Nevada.

In fact, if nobody in Washoe county had voted at all, the outcome would be almost the same: 48.27% Clinton, 45.58% Trump. It still would be a narrow plurality for Clinton. The overall problem with using color tone this way is that it magnifies Clinton's narrow win, giving the visual impression that the state is dominated by blue.

It turns the filled map's defect on its head, and gets it wrong the different way. --Dennis Bratland (talk) 02:49, 7 March 2017 (UTC)

  • I'm going to request immediate closure of this RfC as no consensus for WP:VOTESTACKING. [6][7][8][9][10][11][12][13][14]. These 9 editors were hand-picked by Ali Zifan. So far 3 of the 9 have arrived and they have !voted exactly as Ali Zifan had hoped.

    No personal invitation was given to several other editors active in discussions right here, for example Impru20, Gerrit, Μαρκος Δ, and many more. There are over 50 editors in the Elections Project, and most of them were not notified on their talk pages. There are many editors who have been editing the 2016 state election pages, such as KhnewKreator, Comeh, JustBerry, Cerretalogan13, and many, many more. None of these many editors personally notified of this RfC. Only the 10 that Ali Zifan wanted.

    Violations of the ownership of articles policy among some of the editors here are a problem, excluding contributions by anyone else.

    Ali Zifan needs to accept that nobody gets total control of any article content. He wanted a tree map added, and he got it. He wanted it to be a county-level breakdown, and he got it. But you have to accept that while you get some of what you want, you also have to allow others to modify it. This RfC was created because Ali Zifan can't stand having an image he personally created replaced by one that is basically the same thing, but created by someone else. --Dennis Bratland (talk) 19:10, 6 March 2017 (UTC)

  • @Dennis Bratland: Why do I have to message the users you mentioned (Gerrit, Impru20, Μαρκος Δ and …) who visit this page and see the sections in this page on a regular basis?? You expected me to message them individually?! Ok, I just did it! Still, by giving irrelevant accusations, you try to pervert the consensus and reject the result. I added a message for all users that you mentioned above (Gerrit, Impru20, Μαρκος Δ, and others) to come and put their comment. I also notified an admin to watch this RfC, end the RfC at a proper time, and be a judge, so people like you don't come and try to dodge and flee from the fair, actual results.
It is also very funny. You try very very hard to portrait me as someone who claim to "own the articles" , while in reality, it is completely opposite!Ali 04:01, 7 March 2017 (UTC)
Please, carefully read Wikipedia:Canvassing. Perhaps that would help. --Dennis Bratland (talk) 04:51, 7 March 2017 (UTC)
  • Showing only the top two candidates makes Utah in 2016 look almost like any other election in previous years, and look like any other Republican-leaning state. This is the first time a Republican has not won a majority in decades, and the combined vote of the third party candidates almost equaled the Democratic vote. None of that detail is apparent in this image.
    This shows us the unique characteristics of the Utah election in 2016. When you compare this image to other US states, you see that this election was not like the others, because third parties were so prominent. Compared to earlier years, this 2016 image looks totally different.
    Some comments have trivialized the importance of third party candidates. Utah is a good illustration of how misguided this is. The false idol of "how many counties did they win?" have obscured the importance of how many votes a candidate gets. McMullin didn't need to win a single Utah county to be a major factor in this election. On top of McMullins 21.5%, the other 3rd party candidates pulled in 5.5%. When have we seen anything like this before in Utah, or any other state? Not often. --Dennis Bratland (talk) 07:33, 7 March 2017 (UTC)

I don't believe it's fair or even polite to insinuate just because one has been previously in debate with an editor (A polite one, that resulted in a compromise, that I would have a pre-determined view. I saw the maps, and I found the left one to be easier to deduce, and to be more detailed. For one who has a dog in the fight to question the legitimacy of an RFC is the definition of being a sore loser. I'd like an apology because I feel that the editor in question wishes to deligitimize my view. Thank you. PalmerTheGolfer (talk)PalmerTheGolfer

There's no insinuation about it. The requests for closure noticeboard made that determination, not me. --Dennis Bratland (talk) 23:00, 7 March 2017 (UTC)

While I prefer map 1, map 2 would not be a poor alternative at all. PalmerTheGolfer (talk)PalmerTheGolfer

But if I were to be honest, both of these graphs are not really necessary, it seems they both are misleading to an extent. PalmerTheGolfer (talk)PalmerTheGolfer

Both? There's nothing misleading about a graph that represents every vote, and displays the quantity in accurate proportions. What is misleading? --Dennis Bratland (talk) 23:02, 7 March 2017 (UTC)

Yet the Utah graph by Dennis is much better than the other and a good point is raised regarding 3rd party PalmerTheGolfer (talk)PalmerTheGolfer

I apologize, I read the Nevada graph incorrectlyPalmerTheGolfer (talk)PalmerTheGolfer


As much as I like the 1st graph, the second one displays the full story. PalmerTheGolfer (talk)PalmerTheGolfer

Utah errors

County Name Github Votes Dem Official Clinton Clinton Error Clinton Error % Github Votes Gop Official Trump Trump Error Trump Error % Total Votes Official Total Total Error Total Error %
Beaver County 264 264 0 0% 1,838 1838 0 0% 2,490 2485 5 0%
Box Elder County 1,814 2282 -468 -21% 10,324 12230 -1,906 -16% 16,548 19735 -3,187 -16%
Cache County 6,705 8563 -1858 -22% 16,643 21139 -4,496 -21% 35,879 46147 -10,268 -22%
Carbon County 1,696 1717 -21 -1% 5,182 5275 -93 -2% 7,818 7952 -134 -2%
Daggett County 76 77 -1 -1% 327 331 -4 -1% 465 474 -9 -2%
Davis County 22,575 28776 -6201 -22% 46,985 62219 -15,234 -24% 104,661 138396 -33,735 -24%
Duchesne County 500 500 0 0% 5,505 5505 0 0% 6,932 6932 0 0%
Emery County 379 380 -1 0% 3,402 3425 -23 -1% 4,263 4288 -25 -1%
Garfield County 352 358 -6 -2% 1,577 1606 -29 -2% 2,294 2344 -50 -2%
Grand County 1,932 1960 -28 -1% 1,934 1975 -41 -2% 4,456 4532 -76 -2%
Iron County 2,104 2450 -346 -14% 10,025 11561 -1,536 -13% 15,354 17654 -2,300 -13%
Juab County 436 442 -6 -1% 2,759 2827 -68 -2% 4,076 4177 -101 -2%
Kane County 739 739 0 0% 2,248 2248 0 0% 3,482 3482 0 0%
Millard County 431 431 0 0% 3,860 3860 0 0% 5,234 5234 0 0%
Morgan County 572 577 -5 -1% 3,156 3188 -32 -1% 5,136 5192 -56 -1%
Piute County 31 47 -16 -34% 537 626 -89 -14% 617 729 -112 -15%
Rich County 104 104 0 0% 786 797 -11 -1% 1,096 1109 -13 -1%
Salt Lake County 154,831 175863 -21032 -12% 117,901 138043 -20,142 -15% 361,347 418853 -57,506 -14%
San Juan County 1,997 2042 -45 -2% 2,635 2645 -10 0% 5,385 5447 -62 -1%
Sanpete County 1,026 1061 -35 -3% 6,436 6673 -237 -4% 9,778 10162 -384 -4%
Sevier County 673 695 -22 -3% 6,455 6740 -285 -4% 8,308 8654 -346 -4%
Summit County 10,251 10503 -252 -2% 7,160 7333 -173 -2% 20,133 20630 -497 -2%
Tooele County 4,015 4573 -558 -12% 9,693 11169 -1,476 -13% 18,905 21829 -2,924 -13%
Uintah County 1,002 995 7 1% 9,876 9810 66 1% 12,883 12797 86 1%
Utah County 24,579 28522 -3943 -14% 89,755 102182 -12,427 -12% 174,942 201542 -26,600 -13%
Wasatch County 3,063 3063 0 0% 6,115 6115 0 0% 12,120 12120 0 0%
Washington County 9,583 10288 -705 -7% 39,566 42650 -3,084 -7% 57,494 61962 -4,468 -7%
Wayne County 271 271 0 0% 959 966 -7 -1% 1,410 1421 -11 -1%
Weber County 22,187 23131 -944 -4% 38,447 40235 -1,788 -4% 81,451 85038 -3,587 -4%
Grand Total 274,188 310674 -36486 -12% 452,086 515211 -63,125 -12% 984,957 1131317 -146,360 -13%

Since I was working on the Utah graph I worked through the errors in the data that is crowdsoured at Github for the SVG treemaps, compared to the official results from Utah. It's in the neighborhood of 13% overall, with some of the smaller counties being off by as much as 20% and even 30%. Again, can someone tell me what's the point of an SVG format that lets you zoom into fine detail of the smallest counties when the underlying data is basically garbage? I'd like all of these tree maps checked and corrected rather than left on the articles in this state. Even if the errors are fixed, the presentation is still misleading, for reasons already given. I went ahead and replaced the Utah treemap with one based on accurate recent data.

Remember: A CSV some guy posted on GitHub is not a reliable source. You have to check it yourself. Don't assume anything. —Dennis Bratland (talk) 21:33, 7 March 2017 (UTC)

@Dennis Bratland:
  • 1. Remember, we are talking about the type of chart, not source of data. After the resolving dispute and agreement, I will change every single map based on your preferred source of data.
  • 2. About Utah (and every other maps), instead of "percent difference", I will use the vote percentage of each candidate in each county (after the dispute resolved), exactly as the the main map. Is that also wrong?! Ali 01:54, 8 March 2017 (UTC)
First problem is that it leaves out so much data. It leaves out that McMullin was a major factor in Utah, on top of the significant share taken by all the other third party candidates. The main map, the filled map of the counties, is terrible. I would like to get rid of all of those because they are so misleading. The treemap version is less bad, in that it doesn't distort the county's vote by scaling it with how much empty land it has. Utah and Nevada have a lot of deserts where hardly anybody lives, but most places have uneven population distributions.

The big disadvantage of any kind of treemap is that you lose all the state's unique geography and population distribution. We have a graph -- the pies on a map -- that preserves every vote, in proportion, and preserves the size and shape of the land, and their geographic arrangement. It's all there. But now we're choosing between two kinds of treemap, so...

We need to do something the use of 20 grades of color. There should be 21. Grant County, Utah was a virtual tie. Trump got 0.3% more votes than Clinton. This should be rounded down to 0 and colored gray. Instead it's rounded up to 10% and colored red. Not that people can actually identify every one of these 10 shades of red and blue. There should probably be only 5 shades of blue and 5 of red, plus gray. At least then the viewer could tell them apart. But then you're rounding the nearest 20% which is crude. We don't have to round at all if we use size alone to show vote totals.

The big question I have, and one nobody can tell from looking at the graph is: what is the size of the squares on the treemap? Does it represent the total number of votes for the county? Or only the total of Clinton + Trump? And why? Either of these two options is wrong. If it is the total for the whole county, than you can have to identically sized counties, one where the vote was 40% GOP, 30% Dem, and 30% Other, which will be coded as +10% GOP. Another county, same total number of votes, could have 55 GOP and 45 Dem. This will also be coded +10% GOP. The box is the same size, and the color is the same. Yet in one the GOP won a decisive majority. In the other, they won a narrow plurality due to a split opposition between the Dems and third parties. Yet you want to present them as indistinguishable? Why?

And all along we have a perfectly good alternative type of treemap, which is accurate and proportionate. It doesn't ignore any votes; every vote in the election appears on the map. All the proportions are correct. If you compare the Republican wins in Utah and South Dakota, they will not look the same; they will look much different because they were different. Just as the Democratic wins in California and Nevada were quite different.

And if we're talking about the type of chart, then you are conceding that this has nothing to do with whether it's in SVG or another file format? We can make either type of treemap and convert it to whatever file type we like later on. If we can stop talking about file formats that would be progress.

I think you're personally invested in this because you've hand coded your own program or script to create these. Your goal of preserving your own work, and publicizing your work, is in conflict with he goal of illustrating the election results. --Dennis Bratland (talk) 02:27, 8 March 2017 (UTC)

United States presidential election in Utah, 2016 (main election map)
Exact same logic is used as the main election map. Results by county (based on the number of total votes, including the third parties), shaded according to winning candidate's percentage of the vote.
I uploaded the new version using the data table you provided in the article, and using the same color scale as the main election map. Now there won't be any problems left (especially with third parties). As I said from the beginning, in my opinion, using both treemaps would a good combination on the article. The reasons for using both maps is that in your treemap, for counties that the race was very closed, it is really hard and confusing to infer which candidate actually won that county; That is what the treemap under would instantly make that clear, and gives a quick and perfect overall view of the votes in every single counties, based on the number of total votes. I update and do the same for every single counties in other states after we finally get done with the dispute. Ali 05:35, 8 March 2017 (UTC)
Stuffing these articles with no less than four different graphics which each illustrates the same data set is laughable. Do you see quality election coverage on Wikipedia or anywhere else that does that? At some point you have to put your ego aside and accept that not every single one of your creations is going to stay in every article. --Dennis Bratland (talk) 05:48, 8 March 2017 (UTC)
Now you see! You just make up reasons! After I resolve every single problem associated with the map, now you say It is silly to have 4 graphs on the page! Why you didn't tell that in the first place?! If 4 graphs is silly for you, you may remove your own graph. Ali 13:12, 8 March 2017 (UTC)

UTC)

It's not mine. It belongs to Wikipedia. Just like the color tone version doesn't belong to you. The article was not your private turf, and your version is not privliged over other editors. Also: you've done nothing to resolve the problem that the color tone scale only tells us how many votes one candidate got in each county. It is a poor illustration of this race. It's also redundant, with at least two other graphs showing the same data. Why don't you make one that shows all the candidates? Or let someone else make it? Why does it have to be made only by you? --Dennis Bratland (talk) 22:32, 8 March 2017 (UTC)
There is no strict limit for the number of graphs that can be included on the page. Why not provide them all with an explanation for how each parses the data, and let the reader use that information however they like? bd2412 T 01:21, 9 March 2017 (UTC)
UTC)
There's no strict limit on anything. But would you want the article Dog to have four photos of pugs? I do like the idea of explaining WTF these images represent. A caption telling us what the size of the counties would help. Is it all the votes in the county? Or just the two candidates? Or just the winner, in sync with the colors? And again, creating this false impression of the Utah race is misleading. It's opinated, biased, and partisan. It overstates Trump's dominance, and also overstates Clinton's level of success at the expense of McMullin and others. In Nevada, it also creates a false impression, that it was a solid Clinton majority win, rather than a contested plurality. It distorts the facts in almost every state. It's inherently invested in a 2-party, polarized POV, excising inconvenient facts that counter those assumptions. --Dennis Bratland (talk) 03:26, 9 March 2017 (UTC)
@Bd2412: That is exactly what I tried to tell Dennis from the beginning of the discussion, but he still refuses to accept the actual results of the discussion by making up irrelevant and false statements. @Dennis Bratland: It is also very funny the way you portrait me. You portrait me as someone who claims to own the articles, while in reality, it is exactly opposite. Dennis, you need to accept Wikipedia is a voluntary community. Simply because you don't like something, you cannot start doing edit war and cannot do whatever you want. Instead of being an accuser, bullying users who have fewer number of edits than yours, doing edit wars, and starting disputes, help to improve the encyclopedia. Remember Wikipedia is not your own website, which means you don't own the pages, and anyone allows to edit articles (as far as they don't put wrong information). Ali 03:32, 9 March 2017 (UTC)
  • I wouldn't expect four pictures of a pug at dog; but I would expect them at pug (which, in fact, has eighteen such pictures). Four charts of the Nevada election on the article about the Nevada election hardly seems excessive. bd2412 T 05:18, 9 March 2017 (UTC)

UTC)

That would only be true if the article subject was the county results of the 2016 Utah race. It's not. The subject is the presidential election, which rests entirely on the state total. Analysis by county is only one way of breaking it down. This obsession with counties enforces the false assumption that it's a race to win the most counties. What would make sense is four graphs that analyzed it in different ways, not all the same way. One by county, one by precinct, one by congressional district, perhaps also by other demographics like age, occupation, income. But for county level data, we only need one graph to tell the whole story: pies on a map. The filled county map is pure misinformation. The only reason for the multi-candidate treemap is to counter the false impression given by the filled map.

What if we stuck to WP:NOR and didn't even try to decide this ourselves?

Go to the ===Analysis=== section and rewrite it using only quality expert sources. Write a reasonable survey of what the broad consensus is of how the Utah election played out. Once done, create graphs that illustrate whatever the sources tell us is essential to understanding it. Maybe they will say the election was all about religion, which precincts or zip codes or districts were most Mormon? Maybe they'll say the average income by county is the key. Whatever it is, your argument for a given type of visualization will rest on independent sources, not what I like or what you like. --Dennis Bratland (talk) 18:59, 9 March 2017 (UTC)

Dennis, as you can already see in the articles, we have already used both the main map and the pie chart map, with each other in the infobox, without any problems. Exact same logic is going to be applied for treemaps. Using two treemaps is not excessive at all because although both are called "treemaps", they are different type and show the breakdown of counties results based on different perspectives. As admin bd2412 said, which is completely true, please let the readers decide. The updated treemap does not have any problems related to the third candidates, since it has used the total votes and does not use percent difference between Trump and Clinton anymore. As you said it not about what I like or what you like. The updated treemap uses the same logic as our main map and our main map has been accepted in the Wikipedia community for a long time. I am going to start updating the rest of the treemaps based on the winning candidate's percentage of the vote, instead of percent difference, as I did for Utah, so we don't have any problems regarding the misinformation or misleading factor, and hopefully our long discussion may come to an end. Ali 22:44, 10 March 2017 (UTC)
You're not going to persuade me by reminding me that you've always done it that way. The more I hear that, the more convinced I become that you have no other argument. "Let readers decide" is another way of saying "l don't have any rational basis, so let's punt." You keep talking about what's accepted, and what editor's opinions or readers' opinions are? But not any verifiable facts? And not anything found in reliable sources? If you're wondering why I don't seem to be listening, that's why. Persuade me with objective, independent facts and sound arguments. Wikipedia is not a democracy and poorly reasoned, fact-free opinions can be ignored. --Dennis Bratland (talk) 16:38, 11 March 2017 (UTC)
I've already given many facts above. Do you expect me to repeat them again for multiple times? When you don't accept the facts how do you blame me?! Ali 21:27, 12 March 2017 (UTC)

Naming format change

I was wondering what other editors thoughts were on amending the naming format of election/referendum articles from French legislative election, 2017 to 2017 French legislative election. Elections/referendums seem to be one of the last sets of articles to have the year at the end, whilst almost all other types of articles now have them at the front (this change was made in football articles some time ago, resulting in moves like FA Premier League 2006–07 to 2006–07 FA Premier League). It will involve renaming thousands of articles, but I think it would make the titles slightly more logical (especially for associated articles like Fundraising in the United States presidential election, 2016). If people seem to be in favour, I will initiate a formal RFC at WP:NC-GAL and post invites at the various Politics WikiProjects too. Cheers, Number 57 21:05, 13 March 2017 (UTC)

I'd be in favor of such changes. –HTD 04:07, 14 March 2017 (UTC)
I wonder what the original purpose of this naming convention was – I assume that it's to make it convenient to find articles for other years (e.g., typing in "French presidential election" and seeing entries for various years). Mélencron (talk) 12:17, 14 March 2017 (UTC)
I think it's just that most sets of articles used to use the format with the year at the end (football seasons certainly did). You make a good point about typing in the search box though, which I hadn't thought of. On balance, I still think a move would be a plus (for instance, helping Turkish constitutional referendum, 2017 and 2017 Turkish constitutional referendum 'Yes' campaign match up. Also, we can still create redirects from the old title format that would appear when the search box is used in the way you suggest. Number 57 12:19, 16 March 2017 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Elections_and_Referendums/Archive_11&oldid=1136416067"