fiveham / nc-elections Goto Github PK

Having all the polygons on a given layer all one single color is boring and makes it easy to get lost when zoomed in.

Rather than using political data like Cook PVI to color the districts, color all districts with an east-to-west orange-to-green color gradient. The orange in the east contrasts nicely against the blue ocean and the green in the west matches up with the green blobs that represent certain forests as well as contrasting better than orange against the average yellow color around there from all the yellow road lines in the interior.

should use as simple a shape as possible to conserve bandwidth and client memory

candidate filing ends July 6th

A huge swath of visible ocean isn't helpful. Neither is having the west end of the state covered by the layer select menu.

Gotta put a maximum height constraint on the divs in the balloons or something.

Also, on mobile the scroll bar often vanishes when not in use, meaning it's not always clear there's anything to scroll to, especially for county balloons.

according to the master election schedule

Then the issue of mismatches between precincts and polling places can be resolved.

If Edgecombe 1205's polling place isn't public after 9/21, then it should be after 10/7

Fusion Tables is deprecated and will go offline December 2019.

To keep all-districts.html functioning for the sake of being able to look back on what this map was like when it was new, the file must transition to use any one or several of the following in order to define each layer:

• KmlLayer based on a KML file
• KmlLayer based on a KMZ file
• KmlLayer based on a GeoRSS file or feed
• KmlLayer based on a KML file that simply contains a NetworkLink to the real KML file
• Data layer based on geometry and styling info provided in the html file itself
• Data layer based on geometry and styling info provided by external javascript files
• Data layer based on GeoJSON defined in the html file
• Data layer based on GeoJSON defined in another file

So far I've tried the first two.

The first one failed to render a layer for state house because the fetched file size was 9.6MB, well over the 3MB limit for fetched file size for a KmlLayer.

The second one rendered but would only provide a splotchy inconsistent smattering of overlay tiles (around 10% coverage). Compressing the house layer that I tried to use for the KML attempt as a KMZ brought it to 2-point-something MB, below the 3MB limit.

It would be handy to be able to link to a specific starting layer on a multi-layered map.

It would also be nice to be able to set the initial location and zoom level of the map to link a user to a specific contextual area.

Recently, Google changed the default sizes for the default controls (map|satellite, zoom in/out, etc.) to be much larger to allegedly better accommodate mobile device users. The change also increased the margin around each control. Consequently, the geolocator button and address lookup bar sit a little closer to the edge than before the change, which doesn't look good. In addition, the geolocator button is now noticeably smaller than the default controls.

So, the max sizes (calc()ulated or pre-calculated for mobile safari) for the address lookup and for the sizes of the popup balloons need to be adjusted.

Alternatively, the call to load the API could specify to use version 3.32. However, there's reason to trust that Google's not stupid when it comes to something like this, in which case, following suit rather than clinging to the past would be wise.

It would be less data than the 20-something kB file currently used, but I'm not certain that there are no major gaps in support for a data URI as an img src. Once that's clear to me, it's okay.

The element itself is properly called a "places search box"

https://developers.google.com/maps/documentation/javascript/examples/places-searchbox

candidate filing ends June 29th.

the places searchbox page at https://developers.google.com/maps/documentation/javascript/examples/places-searchbox from which the html of KmlLayerTest.html is derived states at the bottom:

"Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Java is a registered trademark of Oracle and/or its affiliates."

and the Apache 2.0 license at https://www.apache.org/licenses/LICENSE-2.0 states:

"4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

You must give any other recipients of the Work or Derivative Works a copy of this License; and
You must cause any modified files to carry prominent notices stating that You changed the files; and
You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; [...]"

So it looks like that file, being derived from the sample code on the Places Searchbox page, needs some license info added to it meeting these (and any other) requirements of the Apache 2.0 license.

Need at least these districts:
01
03B
04A
07A
07B
07C
09
10B
12A
12C
13B
14B
15A
18B
18D
19B
19C
24
25A
25B
27A
30B

that way use of each page can be tracked individually.

It's really weird and a bad user experience.

Empowering users to share the map on social media easily would really help make this tool more useful.

One thing is unclear at the moment: How do the trademark and copyright rights of the many IP owners involved interact with the license I've put this project under? Is there a contradiction? Is it totally okay? Are there just some extra hoops to jump through before doing that?

For example, Creedmoor Elementary School has the same location as a polling place as it has as a place that accompanies the roadmap basemap. The basemap-accompanying place marker has a larger trigger area, cause it to be tapped instead of the polling place marker sometimes, preventing the user from easily accessing the relevant popup data such as the links to the ncsbe.gov pages pertinent to that polling place.

That would free up a lot of the space taken up by the left-side radio menu for selecting a layer.

if a fitbounds parameter were available, then a url could be constructed so that the user's device fits the map as (and when) displayed on their device to their device's size. In that way, urls can be used that consistently show the area of interest regardless of device dimensions.

All it'll take is a last-moment check before exiting initAutocomplete so that if there's a bounds parameter, then you try to parse that and if it parses correctly then you use it.

That would better communicate to the user that there is content to scroll to, if and when there is content to scroll down to.

For example, if you zoom in on Wake county, all the state house districts are just this vague orange color and you can't really tell what's in the same district without carefully eyeballing all the district lines.

It would be better to stick to gradients for only those maps that introduce comparatively little new information into the world. For example, Prosecutorial districts, whose borders lie along county lines, could be colored with a gradient without reducing usability since the user will ostensibly be very familiar with their own county's shape. By contrast, state house and senate districts' borders deviate from county lines often and are not as well-known since they have no practical bearing on daily life, unlike counties.

For example, if the statewide popup could link you to a related page containing the bulky text of that balloon for easier reading, easier resizing on mobile, etc., then that'd help to overcome the problem of the balloon being so big.

Probably it'd be best for each layer to have its own balloon-text webpage and for each balloon to link to an anchor point pertaining to its own text on that page. For example, the page for state senate districts would list the balloon text for state senate district 1, preceded by an <a> tag with an id value that the balloon could automatically link to, followed by a similar anchor for state senate district 2, followed by the balloon text for state senate district 2, and so on.