week 8: choosing a store site in San Francisco

This week we looked at two more ways of defining market area: by the sales figures within a radius around the store, and by drive time to the store. In fact if one was looking at a potential store site in downtown San Francisco, drive time may be less relevant because - especially for something like bookstores, and in a city that is as walkable as San Francisco - probably a significant proportion of buyers are walking to the store. However "drive time" could be altered to walking time without much difficulty.

So far the assignment is pretty straightforward, although I can see that determining the best store site is going to be tricky because each potential site is good in some important areas (e.g. high population growth) but bad in others (e.g. lower household income).

This week two maps were the products. One shows market area measured by drive time and by the proportion of store sales. The other shows the location of potential available stores as well as the location of current competitors.

Week 7? Project 3 Prepare: Market Analysis, Site Selection

The multisectioned map above shows the San Francisco area with two storefronts of the hypothetical Better Books business, and various demographic aspects (household income, percent with some college, etc.) of the area. The one-part map on the left shows average house value (for my own interest) but it also indicates a one-mile buffer around each of the stores, which is presumed to be the market area. This week's work was relatively uncomplicated one. In some ways the tables I created (not shown) to go along with the maps were more interesting, because they showed a smaller overall dollar intake from the Steiner market area but a considerably higher average purchase for each Steiner Book Lover customer. Nice to know that it's not always maps that are illuminating.

An unrelated but useful map-related thing I learned this week - for my internship work, not for this - was that cutting down the size of your data can make a big difference. In my case it was the difference between having ArcGIS run and having ArcGIS freeze, so I was pretty thrilled when I finally figured it out. The dataset in question was a huge watershed file. It was a big advance when I realized that even though I could use a definition query to reduce the size of the visible file, that wouldn't stop my freezing problem. Selecting and exporting part of the data file made an astonishing difference. Next time I have big files I hope I remember to spend a small amount of useful time at the beginning to avoid spending a lot of unproductive time later.

Week 6: Saving Energy via Trees

For this , the report week of the landscape design section, we had first to calculate the energy savings produced from planting trees in our study area. This was more a mathematical than a GIS exercise (once we had the proportion of Marin City, or several Marin City neighborhoods) that was covered by trees. For the second part, we had to determine how many trees would be needed to offset the anticipated energy demands of a new Marin City Center (its area outlined in yellow on the map). This was based on a combination of a) the area covered (calculated with GIS), b) the average monthly electricity usage of a commercial building (from a Department of Energy table), c) the annual energy savings produced by one tree (from another table) and d) the previously-calculated (maximum) number of trees that could be put on the site. It is interesting to see how GIS can intersect with this type of work, and also interesting to see how much of the input is tentative, or at least hypothetical - we don't know whether the average tree's energy savings will be the same as our Marin City average tree, for instance. Still, interesting to do.

Week5: Carbon Sequestration and Tree Cover

This week we had to calculate tree cover from our previous week's raster creation. Last week we had to generalize a raster that was classified into 50 classes (or 25 if ArcMap kept crashing), and generalize it to 3 classes: trees, grass and impervious surfaces. (So that's how it's done!) This week we calculated the area of the tree cover as a percent of the whole, and also did some carbon sequestration calculations. The three resulting maps (shown here) are quite similar. The 2nd and 3rd display, carbon storage and carbon sequestration, are really the same thing multiplied by a different constant.

This week I learned more (than I wanted to know, really) about the Field Calculator, but it was useful. I also discovered how to join the five neighbhorhoods that we focused on, using the Append function. That was useful too.

Last week we had the task of joining 7 smaller rasters into one big file. This didn't go at all well for me until Mari suggested using mosaicking, a technique I had never used before but that was very useful and worked like a charm.

All in all things are going pretty well. Except for the eyestrain this week...

Week 3: Mapping Proximity to Target Population and Asthma Triggers

For the final week of this asthma-related project we had to do a proximity analysis to show which Alameda county hospitals were a) close to census tracts with a high proportion of black residents, the target population (I used more-than-50%-black; most of the census tracts were near South Berkeley and in Oakland), b) close to major roads (buffered by 0.1 mile), and c) close to Toxic Release Inventory (TRI) facilities (buffered by 0.5 miles). All went fairly well until I got to the point of doing Euclidean Distance for each of the inputs (hospitals, high-black-pop, TRI and roads). First I made at least 20 tries to endeavor to figure out which of the "environments" and "analysis" settings for the Euclidean Distance function did what. Eventually I discovered the distance between a mask, which could be the shape of a shapefile if needed, and the raster analysis extent, which is a rectangle. (Perhaps I was told this earlier - but if so, I had forgotten.) I also discovered that if you set the analysis extent to "extent of display", and adjust the display, the distance radii become longer or shorter. It was an instructive, if frustrating, process. I was pretty excited when I finally got it straight, but it was a long road to enlightenment.

Perhaps I shouldn't have shown this map, since it makes glaringly obvious the difference between the outline of the Alameda County boundary shapefile (the western part, where I did the analysis, is in color) and the outline of the Alameda County census tract shapefile (that grey thing sticking out at the bottom is a high-black-percent census tract that extends beyond the Alameda County boundary shapefile that I intersected with the analysis extent). However it does show the areas where the hospitals are close to a combination of high black population, major roads, and TRI facilities (closest hospitals are in the lightest yellow section). I made the black population file the most important (worth 60%) when I did the weighted overlay of the four files (hospitals (10%), TRI (15%), roads (15%) and black population) because the most important thing is for the hospitals to be close to where the target population is.

Fall Week 1: Preparing Data for GIS & Public Health

In this first 3-week section, we will be producing maps of Bay Area demographics as well as asthma hospitalization rates and some pollution indices. As part of the preparation, we had to compile a metadata chart containing the layers we would need to use. I can't for the life of me figure out how to link it to this, so instead here (to the left) is a screen shot of the layers I plan to use; below is a link to the same thing, only bigger.

http://students.uwf.edu/db27/BayArea/Week1ScrShot.jpg

I haven't included anything in this screenshot other than the outlines of the Bay Area counties. I'm still having some problems, with a) having a correct, or complete, roads file - although the roads aren't crucial for the public health part, I think, so far; and b) with the correct projection for the air sampling stations, which so far has eluded me. Maybe by next week...

Week 5: Using LiDAR

This week we learned how to import a .txt file of raw LiDAR point data into ArcMap, convert the data into a raster image in ArcMap and transfer that image back into ERDAS. This wasn't so hard; the difficult parts for me in the challenge part of the lab were

a) figuring out the scale (until I read the .xml metadata file and realized what the projection was I kept getting impossibly small figures for the scale),

b) wondering where on earth I was - when I was still confused about the scale I did discover - by checking the coordinates into Google Earth - that the location must be the Florida coast again and not in the middle of Iran as I thought for a perplexed moment! - and

c) 'reading' the raster image to figure out which was road and which was sand dune. The road, I concluded, was the part at the top right (it shows up in red in this image) with fairly uniform elevation and a longish straight side, but it took a while before my different classifications showed that. I think I got it eventually - it was initially hard to see. With the manual classification I did (I chose not to use a "stretched" continuum of color) I found it easier to find the road. I ended up creating a rather luridly colored image but water shows up clearly, here as blue (because the elevation is near zero) and sand dunes are yellow and orange. The whole process did reinforce for me what a rube I am when it comes to remote sensing. If only I'd taken a full semester of it when I had the opportunity!