They sent over this LA times geojson that I stuck in CartoDb:
https://cityenergyproject.cartodb.com/tables/la_county_neighborhoods_v2
(metadata on the table notes source)

Not sure what we're going to do with this, if anything. Their desire is that we assign all buildings to neighborhoods as a one-time favor. But they went ahead and started sorting city Council districts themselves. So that might be enough. But if it comes up while I'm gone, here's the data they sent over.

1. Search can return all addresses in region and show on the map
2. Region of the map is assumed
3. Search will show known CE addresses with the highlight
4. Ideally, building name, for major buildings would be searchable (ex: Nineteenth Street Baptist Church)

Begin high-level exploration of how we could adapt the current platform for mobile per ongoing multiple partner and potential partner needs. Goal is to determine a design and technical plan with a tight estimate for pitching. "Real designs" would be helpful but not essential.

autocomplete, missing marker and return 10 results should be merged from DC fixes

• Evaluate other "model" objects for performance issues.

Most or all cities will need tabular address data geocoded. I tried LA's data in CartoDB and got very inaccurate results (I deleted the table before taking a screenshot unfortunately). I may have erroneously selected the wrong field for the postal_code or something. The second attempt used this free service after I concatenated the addresses in a spreadsheet:
http://www.findlatitudeandlongitude.com/batch-geocode/

Results:

• Address:196
• Street:62
• Locality:3
• General:0
• FAIL:0

Way better, since the CartoDB pass had most of the buildings in other states and countries, but still worrisome that 65 of 261 buildings are not geocoded to address.

Generally, geocoding is not an ideal way to deal with data tied to very precise building footprints. But it's all we've got for this project. Just bookmarking this as a risk -- some dots in each city are likely to misplaced.

• Table view will need to be re-designed & coded to accommodate new data loading strategy. There is no value to rendering thousands table rows.

@nicolettehayes Is addressing design in the context of Seattle Phase 2 work. Implementation will come back to this issue.

Seems the scales don't match. Slider is linear and histogram is bucketed.

• Expose BuildingColorBucketCalculator model objects as globals so they can be shared more efficiently. Currently, they are generated for each range filter in three components: "building_comparison.js", "building_layer.js" and "filter.js". They only need to be calculated once when buildings are loaded. They could be possibly passed through state as well.

A note for future energy benchmarking projects.

Carto changed their name and the domain to access the SQL api -- <cartouser>.carto.com/v2/api/sql. Changing the domain alone does not render the tiles even though the requests returned payloads. Upgrading to cartodb.js version 3.15 from 3.14 was the fix

[ ] Create dummy dataset w/ 20k buildings
[ ] Measure performance across app
[ ] Report findings to #22

We can improve the map performance in a few ways:

1. reduce the amount of data by filtering according to the viewport (see #18). This only helps when we're zoomed in on the map. If you are viewing the whole city, you still need to load all the buildings.

2. Use clustering (via the Leaflet plug-in, presumably) to reduce the number of features we render on the map, even though we still would load all the buildings from the server.

3. Switch the map library to a GL map (Tangram or MapboxGL). Either of those should handle 20K points just fine. My main concern with that approach would be to check what browsers we need to support, and how well they handle GL.

Menus vary in width depending on the description of the Heading which leads to left/right . This is causing the show all | hide all to break in a weird place and to introduce an awkward horizontal scroll.

4-digit values are currently special-cased to omit commas in case they're years. If we had a way of distinguishing value types (since years can work for both range and categorical filters), we'd omit them from years but allow them to display for all other numeric values.

The Building comparison table just doesn't draw:

Here's a link to test with a broken field name: http://city-energy.herokuapp.com/#los_angeles/2014?layer=weather_normalized_source_eui_kbtu_ft&metrics[]=weather_normalized_source_eui_kbtu_ft&metrics[]=weather_normalized_eui_kbtu&sort=weather_normalized_source_eui_kbtu_ft&order=desc&lat=34.093041824023125&lng=-118.30215454101562&zoom=11

It should fall back to default view on error. Not sure how to make that happen though.

• Change data loading behavior. Right now we're loading and showing all data from a remote Carto layer, we would need to figure out a different approach. Most likely it would be a combination of clustering and viewport bounds limiting.

should look like

As a result, numbers don't include commas.

This may also occur in other browsers.

Use a loading progress indicator or something similar to let uses know something is going on during the sluggish processes. See #12 for sluggish processes.

These three processes seem to impact the performance the most on the site:

• Layer selection
• Filtering
• popups

Notes:

• Possibly optimize "BuildingBucketCalculator.toBuckets" function
• Minimize rendering in BuildingComparisonView
• Does there really need to be so many carto API calls?