Scholz Week 8 Website Assignment

Scholz Website Week 8 Screenshot - Click to open full page in new tab

This week I added Google Charts functionality to the map.

Progress made this week includes…

  • Fixes to problems with week 7’s map:
  1. No big changes.
  • Added functionality:
  1. On clicking, Google Chart data for racial demographics appears in an infowindow.
  2. Dragging the bouncy marker around the map works to see the chart in different areas.
  3. The census block being shown in the chart is highlighted in the color which represents its largest racial demographic in the popup Google Chart (i.e. polygon will be same color as the largest slice of pie.)
  4. Added source links to Google Charts and Census 2000.
  • Possible improvements
  1. Building more layers on top has made the site slower every week. I think the abundance of US-scale arcGIS layers is the biggest culprit, but I wasted too much time on them to remove them now!
  2. Still ugly formatting. Vertical layout a result of using “narrow-screen” lab monitors, but causes wasted space on typical widescreen monitor. Scaling in and out makes the checks/radios too big for their britches.
  3. Legends for arcGIS layers.
  4. Making the Google Chart infowindows look better.

Scholz Week 7 Website Assignment

Scholz Website Week 7 Screenshot - Click to open full page in new tab

This week I added toggle-able custom overlays via arcGIS server. I chose to add transit-related overlays.

Progress made this week includes…

  • Fixes to problems with week 4’s map:
  1. Changed the stock arcGIS overlay checkboxes from week 4 into radio buttons so that only one could be visible at a time
  2. Added a “clear” radio button to remove all stock overlays (not the custom layers, which can be cleared with their checkboxes and aren’t mutually exclusive.)
  3. Changed the colors of the basemap. Tried to balance Yoh’s preferred monochrome style with the aqua theme of the rest of the page. Waiting for Zhongbo to tell me it’s too dark.
  4. Added source data for UCLA mapshare, where I got the shapefiles for the new overlays.
  5. Squeezed a new column into the “control panel” of the site by shrinking the text in the  previous overlay column.
  6. Set many earlier creations to not display by default, to keep the map from overwhelming the user on opening.
  • Added functionality
  1. Toggle-able overlays of airports, rail lines, highways, and transit terminals.
  2. Radio-button functionality for arcGIS-made layers
  • Possible improvements
  1. arcGIS layers are still slow as molasses, maybe I should steal them and cookie cut them down to a scale smaller than the USA.
  2. Still ugly formatting. Vertical layout a result of using “narrow-screen” lab monitors, but causes wasted space on typical widescreen monitor. Scaling in and out makes the checks/radios too big for their britches.
  3. Legends for arcGIS layers.

Scholz Week 4 Website Assignment

Scholz Website Week 4 Screenshot - Click to open full page in new tab

Scholz Website Week 4 Screenshot - Click image to open website in new tab

This week I implemented toggles and toggles and toggles…. and Google places. Previous weeks’ layers were remade or retrofitted to make the toggleboggling all-inclusive.

Progress made this week includes…

  • Fixes to problems with last week’s map:
  1. Narrowed bus route selection to a few routes near the area of concern. This isn’t really a fix, since it makes the map all but useless for people who live near other lines… but it keeps the focus on the proposed stops and brings the page more in line with the consensus understanding of the assignment
  2. No more freezing of bus routes on the map. Testing of last week’s map showed that a route or bus could freeze on the map if the link to show it was clicked twice in quick succession (likely due to the delay in fetching data from the Metro API). Since the links were replaced by checkboxes, this problem is resolved.
  3. Converted more formatting to CSS. Some HTML coding exists throughout for convenience, until I get better accustomed to doing small things like centering, bolding, underlining, etc. through CSS.
  4. Added source data for Google Earth, which was previously uncredited for the KMZ files.
  5. Restarted code from scratch to eliminate some of the poor formatting and vestigial bits of code from failed efforts in previous weeks. Added a lot more comments within the code because Kristen said it was too hard to follow.
  • Added functionality
  1. Added some of the most important Google places to the map.
  2. Added toggles for every layer of the map (except the base google map layer, obviously).
  3. Color-coded the bus route displays. Did so dynamically such that an input color would alter the color of the stop icons, bus icons, and infowindow text. Probably took more effort than it was worth.
  4. Improved the information available in the infowindows. Google Place infowindows fetch not only names, but exact addresses, phone numbers, Google ratings, and links to website (if available) or Google Place page. Bus stop and bus infowindows are much more infowindormative.
  5. Allow user to select which demographic layer to display.
  • Possible improvements
  1. Functionality with checkboxes could be improved with more understanding of how they work. For example, the map currently allows the user to show multiple demographic overlays at once. I would much prefer that if one layer is checked, all other layers are automatically unchecked, so that the layers don’t stack. Similarly, options to check or uncheck all boxes in a given section would be useful. A button to return all checkboxes and the map bounds to the original level would be handy as well, so one does not have to refresh the entire page.
  2. Better CSS skills could be used to maintain the page. Getting everything aligned was mostly done through guess and check of pixel dimensions, whereas I’m sure there is a way to do so with % values instead. One problem with the map as formatted is that scaling the page decreases the size of the divs, but does not decrease the size of the checkboxes. Thus they begin to overflow the divs. I got the page to look pretty on my computer at standard zoom and was happy with that, but would like to design it to scale better.
  3. Toggleable overlays are nice to use, but slow down the website a lot. I am not sure if it is the computational load or the dynamic method of plotting the overlays, but they disappear temporarily on my crappy computer whenever the map bounds are changed via zoom or pan. This could be considered an unintentional benefit, as it allows the user to see through the overlay when moving around to find something, then returns the overlay once they’ve found it. Really though, it annoys me and I want it to stop.
  4. Legends/descriptions for each overlay would be very handy. Maybe there is a way to call a legend from the arcGIS server and have it display beneath the overlay title when its box is checked. In the interim, the overlays are mostly self-explanatory, and I am too lazy to create the legends/descriptions from scratch.

Scholz Week 3 Website Assignment

Screenshot of Scholz Week 3 Website Assignment

Screenshot of Scholz Week 3 Website Assignment

This week I attempted to integrate the new skills we learned for Metro’s API in order to demonstrate the value of the proposed Expo Phase II stops presented in week 1 and 2. Since the power to map bus routes and even buses themselves is impressive, I made a concerted effort to keep the focus on my route without limiting any of the Metro functionality.

Progress made this week includes…

  • Fixes to problems with last week’s map:
  1. Moved overlay script out of function. It was placed there in week 1, before I learned what all the {}()[] nonsense even meant. As more iterations of the function were added, the problem compounded. Script is now faster more efficient.
  2. Addressed infowindow issue between kml createMarker infowindows. Last week’s map featured the functionality of closing one created marker’s infowindow when another was clicked, but I was still frustrated that the kml infowindows operated in parallel, allowing one created window and one kml window to be open at the same time. This week a function was added to unite the two types so that they will close one another.
  3. Added CSS formatting. Last week I made a hodgepodge of html formatting based on what I remember from making a Geocities page of Sarah Michelle Gellar pictures to become the coolest boy in the 7th grade. CSS is much easier and less confusing, and I would like to go through and replace the leftover HTML formatting from last week with CSS styling. For now it works though.
  4. Added source data so Metro/Google/Arcgis/Nicolas Mollet don’t sue me and take away my Codecademy badges.
  5. Tried to make things look prettier.
  • Added functionality
  1. Added the metro bus selector as shown in class, with modifications. Instead of zooming to the bus line, the map zooms to show the bus route in relation to the proposed stops. I chose to do this rather than cherry pick and show a few static lines near my proposed stops (e.g. 4, 20, 33, 733), because the nature of my proposed stops makes almost every line relevant. Distant stops are made relevant because the vast majority of them connect to my proposed sites via Phase 1 of the Expo Line (shown in the teal line) from Downtown. Nearby bus stops are either improved by the new line (particularly those going perpendicular to the route) or made obsolete by it (if running co-linearly). The focus is further kept on the line by the added functionality of a “clear” link which removes the shown stop and refocuses the map on the original bounds of the proposal site.
  2. Implemented the live tracking of buses along a selected line. Locations of buses are shown in clear markers with ID numbers on mouseover (for Metro’s tracking purposes). For the busriders, the direction of travel of each bus is shown clearly with an arrow in its symbol. Where a bus is going is equally if not more important than where it is right now, so this functionality was worth the effort.
  • Struggles
  1. For fun I tried to add a script which would scan each route to see if any of its stops intersect the current viewing window. In this way a user could scroll around the map and the clickable route links below would update to reflect the new bounds (like google maps/earth does with businesses). I hit a wall when the function to check intersection of bounds made the script so painfully slow that the whole map was useless. There is probably a way to do it efficiently, but pulling the route data from Metro and re-doing the latlong calculations with every change in map boundary was brutal the way I was attempting to do it.
  2. Because the bus routes look messy with a big trail of icons, I tried to add a polyline which traces the route in a cleaner way (some vestigial code is still in the script, commented out). I gave up on this when I encountered problems with global vs. local variables. Specifically, I wanted to modify a global array node by node (i.e. by adding a latlong for each loop of i in the metro fetching functions). This was not too huge of a challenge, and the completed array could be summoned in the console just fine. However, attempting to call it in a subsequent function within the initialize script would fail, as the function somehow thought the array was still as empty (“undefined”) as it was when it was first declared in the global space. Whatever beauty lies within the way javascript handles variables is lost on me as a first time java coder. Perhaps there is a way to accomplish similar feats by using nested functions, but by this time the train of pink bus stops was looking much prettier to me (and I liked being able to see mouseover and see the station name anyway.)
  3. For some reason a route or bus will occasionally get stuck on the map, and not disappear even when the clear function or another bus line function is run. Can’t see a pattern to it, but it might be inefficient coding or web retrieval issues.

 

Scholz Week 1 Site Review B

Review of The Economist’s Republican Primary Map (new window)

Kyle Scholz

April 8, 2012

I. Technology

The technology used on this map is not detailed on the website itself, likely because the Economist is a private entity which would not like its competitors to crib its code for their own similar maps. It does, however, allow users to embed the map into other web pages, which is a good functionality (and a good advertisement for the Economist, too).

One important technological aspect is the dependence on Flash to run the map. For many Mac users this could be a problem. Luckily it is not a problem for me, as I am too poor to afford a Mac (and too dumb to read the Economist, but that is a different problem for a different class.)

All in all, the technology used is predominantly devoted more to the I (information) part of GIS than the G (geographic). The map is a basic map of 50 states, with the capability of hovering over each or zooming in to lock the info windows and explore them further. The information (about each state, primary, vote tally, and candidate) is top notch, so the simplicity of the geographic technology is actually a boon since it connects the user to the data without getting too much in the way of itself.

II. Interface

Economist Republican Primaries Map Main

Economist Republican Primaries Map Main Page

The interface is very good – hovering over a state temporarily changes the info window (shown above for “National”, the default when nothing is moused over) to show a summary detail of that state’s primary process and or results. Hovering over a candidate in one of the bar charts changes the window to show electoral details about that candidate.

One minor issue with the interface is the functionality of clicking on a state. As shown below for California, this click zooms the map onto the state specified and “locks” the info window onto that state so that moving the mouse off of it does not revert the window back to “National”.

Map after clicking on California

Map after clicking on California

The info “locking” functionality is useful, but the zooming in on the state does not appear to serve any purpose other than flashy aesthetics. No smaller-resolution (i.e. voting district) data is revealed, and the information shown by hovering over the candidate bars is not customized to the state in focus. In other words, the clicking provides absolutely no additional information besides a clearer picture of the outline of the state. The price of this “information” is a necessity to hit the “Reset map” button frequently to return to the full map to click on a state outside the immediate vicinity. Not a big deal, but the same amount of information could be garnered by highlighting or otherwise indicating the state in focus without zooming in and requiring extra “reset” clicks.

III. Conclusion

As someone who knows very little about politics (besides the fact that I am already tired of hearing about it on the news), this web GIS interface was very useful, educational, and even fun to use. I learned more from the hour I spent playing with this website than I have in the past month of accidentally hearing people blab about it on the television/radio.

The strengths of the website are in the simplicity of the interface, wherein hovering over or clicking almost anything gives immediate informational feedback. For any website I designed, I would hope to achieve a similar ease-of-use and fast learning curve. I would also aim to create a similar aesthetic beauty and simplicity – nothing on this site is stunningly modern, beautiful, or flashy, but it flows well and the color scheme is well constructed.

The weaknesses which I would try to avoid are unnecessary clicks (i.e. the frequent “Reset map” clicks after needlessly zooming in on a state). Additionally, I might try to make the symbology of the map more immediately clear – it took me a minute to decipher what each color, and each level of each color, denoted. Rather than explicitly showing a legend, the map relies on the user’s “connecting the dots” by the matching of colors to the bar charts at the bottom.

Scholz Week 1 Site Review A

Review of San Francisco Crimespotting (new window)

Kyle Scholz

April 8, 2012

I. Technology

The details on the technology used are a bit sparse (even the “About” page of the site indicates a need to “Fill this in…“). It appears that the project team behind SF Crimespotting designed its own mapping platform called “Modest Maps” (new window) based on a framework of Adobe Flash and Python script. Via this platform, map tiles from the third party developer Cloudmade (new window) are tiled geographically. Crimespotting‘s team boasts that this framework allows the map to be fully explorable, an improvement on previous attempts (such as CrimeWatch) which were more limited in map interactivity.

An important motivation and feature of the Crimespotting project is browser accessibility. The platform is accessible on more browsers than the earlier CrimeWatch, and “gracefully degrades” to preserve functionality even on those browsers without the latest and greatest features.

Unfortunately for many Apple users, the interface does require Flash. For those users, Crimespotting offers an alternative method of browsing through a database for static maps in image form. While this is a valid alternative, the interface and experience is seriously disappointing after using the full Flash interface — even forgiving the fact that at time of writing the crime database main page reads “DB Error: DB Error: unknown error”.

Interface with Flash

Interface with Flash

Interface Without Flash

Interface Without Flash

An excellent feature to the website is the accessibility of well-formatted data for use in spreadsheets for other uses. With no cost, registration, or authentification, users can fetch data via HTTP GET. The format of the data, including data types and metadata, is given on the API tab of the CrimeSpotting website.

II. Interface

CrimeSpotting Timeframe Interface

CrimeSpotting Timeframe Interface

The timeframe interface of the CrimeSpotting website is good, but features a few things which I might change if I had the technological know-how to do so.

The Time of Day interface is excellent, and very user friendly. The clock itself would have been sufficient for any purpose, but the decision to pre-load TOD configurations for time frames over which a user may be interested is a nice touch and shows a desire to take extra steps to make the experience better.

The date interface is slightly less intuitive. For starters, the most obvious indication of the data being shown is the large dropdown menus at the bottom left (as shown, March 2010). In actuality, the time frame being shown is in smaller font along the timeline itself. This confusing is further compounded by the fact that the crime data in the system doesn’t even go back far enough to cover the default date of this historical data drop down menu, so using it leads to blank bars along every date. Perhaps the designers are planning to add crime data as far back as 2010, but until they do so it is misleading to allow users to go back that far. Similarly, the ability to track dates in the future is pointless, as they have not teamed up with those weird jacuzzi aliens from Minority Report to predict crimes which have not yet occurred. Finally, the timeline limits date windows to 28 days. This may be a technological decision, but it seems to me that it would be useful to be able show total number of crimes within a given month, almost all of which exceed this 28 day window. In summary, the date timeline could use some improvement by letting users show a greater number of days at a time, but by disallowing them from viewing dates in the distant past or future for which there is no data available.

CrimeSpotting Crime Type Interface

CrimeSpotting Crime Type Interface

The interface to show types of crime is excellent. It is very easy to check/uncheck types of crimes, and the show all/hide all buttons are added to make the process even easier. Mousing over each type adds a highlighted buffer around each incident, making quick browsing of crime types simple even without hiding all other types.

Improvements on the interface may be to add check marks for each grouping of crimes (i.e. red, blue, green) along with their category descriptions (currently in small type below the map) so that one might easily show only one category of crime.

Another improvement would be to include incidents of sexual crime on the map. There is probably a legal or moral reason why crimes such as rape were not included, so I understand their omission. However, if I were a woman in the San Francisco area planning a route to work I would be far more concerned with being raped than being arson-ed or having my peace disturbed, so perhaps a workaround of highly anonymous data could be used to show incidents of rape without any identifying information about the victim.

Finally, the location interface has one seriously annoying bug: when moused over the map, scrolling up or down on the mousewheel zooms in and out of the map AND scrolls up and down on the page. By doing both at once, neither functionality is useful, and the user is forced to use slower more tedious methods to zoom and scroll on the page. (Note that this issue was observed using Firefox; other browsers may perform better.)

III. Conclusion

SF CrimeSpotting is an excellent website which accomplishes its goals very well. The only real gripes I could make about the system are its flash dependence, slightly confusing timeline, and frustrating mousewheel integration.

The features I would hope to draw from the site for my own project would be the visual clarity/simplicity of the interfaces, the openness of the platform for collaboration with other projects, and the small extra features which are not necessary for functionality, but add to the user experience and demonstrate the designer’s concern for the end-user.

Scholz Week 1 Website Assignment

 

Expo Line Phase 2: Proposed Stations

Kyle Scholz

April 8, 2012

The map above shows 7 transit stations along the general route of the upcoming phase 2 of the Expo Line of Los Angele’s Metro rail system. 2 of the stations (Culver City and Santa Monica (@ 4th and Colorado) are (respectively) the currently specified beginning and end points of the new rail segment. The route between the two points has also been more-or-less decided to follow the abandoned Pacific Electric Railway, as shown below:

Expo Line Route Map

Expo Line Route Map: Phase 1 in solid aqua, Phase 2 in dashed aqua.

This route was chosen for a variety of reasons, not the least of which was the input from a vocal community of local residents. Many voiced opposition to an alternate route which would have established a new right-of-way so as to serve the current demographics of the region, rather than following the path of least resistance along an antiquated route opened over a century ago.

For this assignment I decided to design my own route which connects Culver City and Santa Monica using different criteria than the “not in my backyard” route currently specified. The three criteria I used were:

  1. Proximity to significant locations within the area.
  2. Spacing of stations. Each point along the line is designed to be within walking distance miles of the nearest station, as indicated by the yellow 0.75 mile radius buffers.
  3. Coverage of high unemployment, to provide affordable transportation to residents who may need the transit to reach distant job opportunities. The purple map shows 2010 unemployment data, with darker purple indicating higher unemployment.

The five stations proposed, with justification for each, is listed below from east to west:

  • Motor Ave: This station is proposed to meet all three criteria above. The significant location in this scenario is the density of apartment buildings and other relatively low cost housing. Many students (including Bruins!) live here, as do many young people employed in Hollywood & downtown. The location is also proximal to Overland Avenue and National Blvd, major thoroughfares on the west side. A Motor Ave station is a reasonable distance from its neighbor stations so as to meet criteria 2 as well. Finally, the large dark purple areas within the station’s buffer indicate that the station could serve a community currently suffering high unemployment.
  • 10 & 405: The interchange of the 10 and 405 freeways is a very important crossroad in the area. A station placed there could serve a similar purpose as the one placed at the interchange of the 105 and the 110 freeways: a park & ride transit hub for commuters and ride-sharers. Riders could drive on either freeway to reach and board the Expo line at this station, or riders could ride the line to this station and meet a ride-share to drive either freeway.
  • Santa Monica Airport: Clearly this station is chosen to serve the passengers traveling to and from the local airport. Although Santa Monica Airport is not currently a heavyweight in the region, it serves an important purpose as a relief airport for the often jam-packed LAX. Additionally, it is scheduled for a “revisioning” of its role in the community within the next few years. Access to the EXPO line could be an important part of that vision.
  • Santa Monica College: As the recent protests over tuition at SMC have shown, many students at this highly-reputed community college are concerned about the costs of living and education. While an Expo station would not lower the tuition there, the addition of affordable and convenient mass transit may allow students to pinch pennies elsewhere (such as gas expenses of commuting, or rent expenses of needing to live in the costly residences close to campus). For those who do live near campus, the Expo line could connect students to internships, jobs, and 4-year universities elsewhere in LA.
  • Santa Monica Pier: This proposal is much less practical, but still somewhat valid. The current termination of the Expo line is at 4th and Colorado, about a 10 minute walk from the beach. The long-awaited dream of a “subway to the sea” is thus replaced by a “light rail to the neighborhood about a half mile away from the sea”. And while there are many attractions near the station (including the 3rd Street Promenade), the allure of hopping off a train and onto the historic Santa Monica Pier would be a greater attraction for tourists who otherwise have no idea where “4th and Colorado” is. Obviously there are incredible construction and cost hurdles of building a train station literally on top of a historic beach with some of the highest property values in the state, so this proposal is more fanciful than realistic.