Two of my favorite things: my trusty ARC/INFO mug from 1990, and my trusty dog Pepper, painted in the style of Andrew Wyeth's Homer . At the recent FOSS4gNA conference , I had the pleasure of hearing about some of the new features in PostGIS. One such set of features were the Coverage related features ( ST_CoverageInvalidEdges , ST_CoverageUnion , ST_CoverageSimplif y ). These functions made certain adjustments in the data structure to allow for faster spatial operations. L

In my last post, I gave a brief overview of the website I created that mimics the S&P 500 over the last 100 years , as it relates to simulating retirement saving potential. That post was geared toward older adults who are getting close to retirement age. Today's post is geared for the twenty-something who has just entered the workforce, and might not be thinking about retirement. The goal here is to remind those younger adults just how important the phrase it's never to ea

This will be the first of two blog posts related to retirement and investment. This post will focus on people approaching retirement age, and how secure they may be in a retirement that might be around the corner. The next post will be targeted toward young professionals entering the job marketing and thinking about how to invest for the future . So, if you like this post, tell your children to check out the next one! If you don't want to read the blog, I just created a v

For today's post, I'm going to have Will Edmunds discuss some of the decisions he had to make when creating his map of average monthly runoff for the major watersheds in the conterminous United States. As a reminder, Will is a Senior at Salisbury University, majoring in Geography with a focused track in Geographic Information Science. The following are Will's observations: This map was the most time-consuming project I’ve worked on to date. It was a surprisingly difficult

I promised that I would provide some insight into how I prepared the data for our average monthly runoff map, and Will Edmunds will provide a follow up post on how he made the map. I took two approaches for preparing the data: a database centric approach, and the Esri approach that used geoprocessing tools. Both work, so I wanted to give you the option of doing it either way. Obtaining the Data The first thing I needed to do was obtain the data from the USGS water data sit

Estimated Annual Monthly Runoff for Major Watershed Regions in the Conterminous United States I was inspired by a map that my good friend Chul Sue Hwang made for South Korea that showed watershed discharge for the nation: It's just an incredibly beautiful map, and it helps understand the geography of South Korea and the influence of the summer monsoon season. I asked the USGS if we had a map like this, and I came to find out that we do not. That presented a nice challenge:

I don't think ARC/INFO ever had the ability to create a bivariate map. The first time I saw it, it was implemented in ArcMap. There are also cool looking bivariate maps produced with ArcOnline . ESRI also has a .dll you can use, and there is a good article here . So of course that got me thinking: could we make the same map with PostGIS? Well, sure, and it is super easy. If you want to get spun up on what these 9 color bivariate choropleth maps are, and the theory be

As promised, I'm going to expand on the BUFFER example and talk about the Multi-Ring Buffer . I felt it was too much to go over in one blog post, so we'll cover it now. The Esri help manual has a nice diagram for the buffer operation: Returning to the set of points we've been using: a multi-ring buffer would be as follows: This one is a little tricky because we don't want the concentric circles to overlap one another. So, if we are buffering by 0.5, 1.0, and 1.5 then we ha

Another ARC/INFO function that we often use is DISSOLVE . This is an easy one, as PostGIS has the command ST_Union. An example from the Esri manual shows how counties in Iowa are dissolved: But I'm going to use an example of counties in the Northeast United States: The query to do this is simply: This is simply performing a Union operation on the geometry field, and then grouping that union on a field name. You can group by multiple names, or even make other conditions. T

Having walked through the ARC/INFO INTERSECT and IDENTITY command, we'll now move on to UNION . In this case, we keep the polygons of the input layer and those of the output layer that intersect it. We'll follow the same shapes that Esri users in their example. Once again, I digitized my own example to look like Esri's: Let's look at the query to perform the topological union of the two layers. This one is trickier than the somewhat complicated IDENTITY command. We need

Having walked through the ARC/INFO INTERSECT command, we'll now move on to IDENTITY . In this case, we keep the polygons of the input layer and those of the output layer that intersect it. We'll follow the same shapes that Esri users in their example. Once again, I digitized my own example to look like Esri's: Let's look at the query to perform the topological identity of the two layers. This one is much more complicated than the simple INTERSECT command. While the SQL l

Thinking back, the ARC/INFO INTERSECT command is probably where I fell in love with GIS. I think what I loved more than the function itself was the circle and squares they used in the old ARC/INFO user manual. The new user manual sort of replicates that, but not as nicely as the original I'm afraid: Once again, I digitized my own example to look like Esri's: Let's look at the query to perform the topological intersection of the two layers. The key here is using the PostGIS

Having just tackled Symmetrical Difference, we'll move to the murderer's row of topological operations: ERASE, INTERSECT, IDENTITY, and UNION. Esri has a nice description of the Erase function , and I actually created a similar looking layer to the example they use: The code is relatively straightforward: the key to this query is in line 3 where we use ST_Difference to find those areas that don't intersect one another. From there, in lines 6 and 7 we perform a join on the a

Today we'll start exploring some of the topological functions in ARC/INFO such as Symmetrical Difference, Erase, Intersect, Identity, and Union. These are known as the overlay toolset in ArcGIS Pro . But, years and years ago, these tools were the bread and butter of what made ARC/INFO such a powerful tool. Funny side conversation and name drop In 1990 I was in Redlands, CA benchmarking ARC/INFO.  We had a really “difficult” task for them: overlay 25,000 hexagons with 25,000

In previous posts we determined the nearest neighbor and replicated the NEAR command. Sometimes, the nearest neighbor isn't enough. Perhaps we want the three nearest neighbors. We'd call that k nearest neighbor , with k , being the number of nearest neighbors we want. Looking back at the figure from my textbook An Introduction to Statistical Problem Solving in Geography , we have our 7 points: Instead of the nearest neighbor, we might be interested in the 3 nearest neigh

Our previous post showed how to identify the central feature in a geographic layer using PostGIS.  Today’s post will show how to calculate the nearest neighbor index. Recall from An Introduction to Statistical Problem Solving in Geography  (third edition), the formula and computation of the nearest neighbor index. This isn't rocket science, but you'll start to see that things will start to get a little more complex as we build this one out. Again, let's do this in stages.

In my previous post we saw how easy it was to compute the mean center of a geographic dataset in PostGIS.  Today’s post examines the SQL code necessary to generate the weighted mean center for a geographic data set.  Recall from An Introduction to Statistical Problem Solving in Geography  (third edition),  the formula and computation of weighted mean center and the 7 point data set used. We'll solve this one in steps, as well, so you know how the SQL functions can build on on

We'll continue our look into ESRI commands in PostGIS by examining another simple task: calculating the Mean Center of a data set. To illustrate these concepts, I will be showing examples from my book Statistical Problem Solving in Geography .  In my textbook, I have an example of 7 data points: So, we can recreate the same results with the following SQL: this query gets the average X and Y coordinate values for a point layer by first converting the geometry into X and Y val

Our previous post showed how to extend the mean center of a geographic dataset to incorporate the weighted mean center in PostGIS.  Today’s post examines the SQL code necessary to generate the central feature for a geographic data set.  Recall from my textbook An Introduction to Statistical Problem Solving in Geography  (third edition), the formula and computation of the Central Point. This is where the power of spatial SQL gets used.  As you can see, finding the central poin

If you've worked with ARC/INFO (or any GIS really), you often have to make a determination about the coordinate system of your data: if you want to reproject the data into another coordinate system, you use PROJECT , but if you want to simply overwrite the coordinate system of a layer, you would use DEFINE PROJECTION . PostGIS allows you to do both commands rather easily. So today, I'll show you both of them. I often find that I need to do these commands a lot, especially