Over the last week or so, I've had a chance to consider the data structure, start looking at linking tabular data to spatial data, think about deadlines, and add a ZIP code basemap to my EK demo map. Here's where we're at to date:
There are 5 people working on this project, so naturally, we'll have 5 methods for getting to our goal. It was agreed we wanted an interactive map that would make it easy to find which SCA branch a particular ZIP/FSA code fell into. One way would be to simply assign a branch to a ZIP/FSA code and show it on a map. That's fine in a desktop software application, but we also want to serve it up in a map on the internet. The limitations here are file size, the number of features (records in the table), and complexity of the geometry. Basically, we can't upload all of the ZIP/FSA codes to the website and expect the back-end servers to render that much data. We have to dumb it down a bit. This means dissolving the ZIP/FSA codes to the branches. Then, if we want to zoom out to see Kingdoms, zoom halfway to see regions, or zoom in further past Baronies & Shires to see cantons, ridings, colleges, ports, or stongholds, that has to be in the dataset as well. We can dissolve the ZIP/FSA polygons to each level. That means there will be a Kingdom level, regional level (Principalities or groups of branches for those kingdoms that have them), a Barony/Province/Shire level, and a canton/riding/college/port/stonghold level. Breaking the ZIP/FSA codes down this way means that at a minimum, the table must have these four columns. The added benefit is that we can show which local levels belong to which parent levels. OK, so I've spent a lot of time thinking about this, but it seems logical to me. (Another complication will be islands and coastlines, but I'll get to that later.)
So now that I have spreadsheets of branches by ZIP/FSA codes, I'll need to link them to the corresponding ZIP/FSA polygons. Linking the data based on ZIP/FSA codes is pretty easy, it's the clean-up that stinks. There will undoubtedly be orphaned ZIP codes because the polygons are ZIP Code Tabulation Areas (ZCTAs). ZCTAs are ZIP codes used by the U.S. Census Bureau. You can read more about ZCTAs at this website: http://www.unitedstateszipcodes.org/. Anyway, there are more ZIP Codes than ZCTAs. Also, ZIP Codes get added and deleted all the time, so we're bound to find some that local Seneschal's missed or are legitimately "Crown Lands" unclaimed by local branches. This clean-up will probably be the most time consuming part.
With so much work to do, knowing timelines and deadlines will help. Most of the SCA Known World Mapping Team will be discussing this Saturday evening (11/9/13). One deadline mentioned so far was by the end of the year. That's about seven weeks from today. Seems reasonable (I hope).
Finally, there has been this idea that we would want to see the ZIP (ZCTAs) code boundaries. Luckily ESRI has done this work for us! I'm not sure how they did it, but the layer can be added to the map and rendered the way we want to see it. I've added another page to the blog called, "SCA EK Branches with ZIP Code Basemap". If you zoom down to the local branch level, you'll see the ZIP code polygons. Pretty neat! I'd still prefer to enter a ZIP code and search/zoom to it though.
This project is still a work in progress, but a labor of love. I'm excited for people to use it. =)