Wikipedia talk:WikiProject Elections and Referendums/Archive 11

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.

Archive 5

←

Archive 9

→

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:

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:

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.

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
	Github/Guardian?				Secretary of State Official					Differences
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)

Discussion at Talk:Opinion polling for the French presidential election, 2017#Embedded links in lieu of inline citations

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.

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)

Speedy close with no consensus, requested at Requests for closure. --Dennis Bratland (talk) 02:17, 7 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)

Notice: This isn't an WP:RFC. It does not follow the clear and very detailed instructions at WP:RFC. In addition, it is non-neutral; it mentions another editor. It also is not signed. Softlavender (talk) 13:05, 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 5 7 21:05, 13 March 2017 (UTC)

I'd be in favor of such changes. –H T D 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 5 7 12:19, 16 March 2017 (UTC)