Can you recommend any specific software titles (in case our Stake President elects to purchase for the Stake for future - and this - boundary realignment)? I've searched but nothing seems to come up.
But for now, what we have will get us started with the analysis phase. When we provide the Clerk with options, he will have to enter codes in MLS for the 'new unit' membership for final analysis.
Help Converting CSV file to KML
-
johnshaw
- Senior Member
- Posts: 2273
- Joined: Fri Jan 19, 2007 1:55 pm
- Location: Syracuse, UT
sumrhome1,
The GEOCode part is particularly interesting when you want to compare multiple scenarios, If GEO Codes are not already arranged nicely already by stakes and wards, which we find very difficult in our stake, I would make some suggestions... add to your member spreadsheet the default geo codes (in my case, I went through each unit in consideration and labled them as their own ward using abbreviations. That was my default position for everyone. Then as we created 'options' by using Google Earth to see the member groupings and how they could be divided, we create lists of people... for instance I would then create another GEOCODE for those lists... and a new column in the spreadsheet for each new option - base, option 1, option 2... and created meaningful names for geocodes for each option for example Ward1toWard2, or Ward1toWard3 Ward2toWard3 etc....Ward2toWard1 - once you have pre-defined each boundary option, then created your geocodes you must go in and change the geocodes for the members... change from default position to the geocode under the first option - then go into the software and get your data - you have to be careful with the software and remember to create one option, then take a snapshot of all the data, and then do a second option and take a snapshot of all the data because after you put in the 2nd option it typically messes up the 1st option because some of the same people are part of both options. This is the best way to really see how MP, Primary, RS, Youth will be divided up, etc...
I hope this is making sense, when you start using the boundary re-alignment tool you'll understand, and again, this all hinges on whether you already have good geocode data or not. The only good geocode data our stake had was my former ward where we put that data in when I was a head clerk, and in fact, was used successfully to change a recent boundary.
The GEOCode part is particularly interesting when you want to compare multiple scenarios, If GEO Codes are not already arranged nicely already by stakes and wards, which we find very difficult in our stake, I would make some suggestions... add to your member spreadsheet the default geo codes (in my case, I went through each unit in consideration and labled them as their own ward using abbreviations. That was my default position for everyone. Then as we created 'options' by using Google Earth to see the member groupings and how they could be divided, we create lists of people... for instance I would then create another GEOCODE for those lists... and a new column in the spreadsheet for each new option - base, option 1, option 2... and created meaningful names for geocodes for each option for example Ward1toWard2, or Ward1toWard3 Ward2toWard3 etc....Ward2toWard1 - once you have pre-defined each boundary option, then created your geocodes you must go in and change the geocodes for the members... change from default position to the geocode under the first option - then go into the software and get your data - you have to be careful with the software and remember to create one option, then take a snapshot of all the data, and then do a second option and take a snapshot of all the data because after you put in the 2nd option it typically messes up the 1st option because some of the same people are part of both options. This is the best way to really see how MP, Primary, RS, Youth will be divided up, etc...
I hope this is making sense, when you start using the boundary re-alignment tool you'll understand, and again, this all hinges on whether you already have good geocode data or not. The only good geocode data our stake had was my former ward where we put that data in when I was a head clerk, and in fact, was used successfully to change a recent boundary.
-
RossEvans
- Senior Member
- Posts: 1345
- Joined: Wed Jun 11, 2008 9:52 pm
- Location: Austin TX
- Contact:
Well, I happen to use a commercial product called Manifold, including its Business Tools optional addin that has a nice interactive districting tool. Including that option, it cost me about $400 several years ago. One qualm I have about recommending its purchase today is that the small Manifold company has not had a major new release for a couple of years, although the current version is well supported. See main Manifold site here, online user manual here, and support forum here.sumrhome1 wrote:Can you recommend any specific software titles (in case our Stake President elects to purchase for the Stake for future - and this - boundary realignment)? I've searched but nothing seems to come up.
I considered that $400 a bargain at the time, considering that the market leader GIS system, ArcGIS from ESRI, is many times as expensive -- far beyond what any stake budget could bear. Although ESRI products are the "industry leader," I have never worked in an organization that could afford the licenses. My workplace uses MapInfo, which is not as expensive but still pricy. I consider MapInfo inferior to Manifold for most of the desktop tasks I perform, so I have desktop license for Manifold at work and own a personal license at home just because I'm a map geek.
If I were starting out today, I would definitely explore several free and open-source alternatives, notably Quantum GIS, gvSIG, and MapWindow GIS. At least the price is right.
Learning curve is probably the biggest barrier. It does require developing some specialized skills. So one consideration is whether the stake has the talent that can be called or assigned, and keeping that calling stable.
The method you are using is a pretty decent middle ground. It's just that MLS requires a lot of manual work. We did something similar in our unit. Our stake, which as far as I know does not have GIS software, determined that it wanted ward clerks to code all households by a certain scheme for the Stake Geo Code field in MLS. What I did for our ward clerk, within Manifold, was twofold: First I build a layer matching the stake's specification. With that resource, I exported a household spreadsheet with all codes added for each record. Then became a matter of copy-paste for our clerk using MLS. For subsequent updates, such as new move-ins, I built him a KML overlay file of these Stake Geo Code areas. Then, one address at a time, he can paste the new address into Google Earth with the overlay loaded, then click next to the mapped marker to pop up the requisite code in Google Earth for copy-pasting back into MLS. It would have been hard to create this overlay outside of a GIS application, but using the manual copy-paste method only requires Google Earth for the clerk's machine.sumrhome1 wrote:But for now, what we have will get us started with the analysis phase. When we provide the Clerk with options, he will have to enter codes in MLS for the 'new unit' membership for final analysis.
-
RossEvans
- Senior Member
- Posts: 1345
- Joined: Wed Jun 11, 2008 9:52 pm
- Location: Austin TX
- Contact:
Just as a footnote to my comment above about BatchGeo.com, after testing a few hundred random addresses I must say that this geocoding site is much more accurate than I expected for my area, and better than it used to be. (I was familiar with BatchGeo's performance when it used to employ Yahoo's geocoding API, but it now uses Google's) At least in my city, almost all well-formatted addresses seem to be geocoded with rooftop accuracy, particularly those for single-family homes.
Like just about any geocoding process, there are some errors, though. Maddeningly, such errors are unreported by BatchGeo. I suspect that these are cases where the Google API is guessing and returning something fuzzier than a true address-based lat/lon, and that status is reported under the hood to BatchGeo, but the accuracy status is kept from the BatchGeo.com user. So the service still must be used with a grain of salt.
Accuracy aside, however, for reasons of privacy I still would choose not to upload membership name-address data to BatchGeo.com.
In the long run, capturing accurate lat/lon coordinates on the Church's maps.lds.org site seems the better alternative to satisfy privacy requirements. In the short run, I confess, I still do not use this data for serious tasks because our ward has not invested the clerk time to manually verify (and reverify as needed) all our addresses online. Surely this would have to change if performing that now-optional task were mandated by our stake. So if stakes do want to use this securely private data for boundary work or other purposes, they would be well advised to instruct their ward clerks to undertake and maintain the work. Stake clerks lack the privilege to do it themselves. Meanwhile, the gross processing errors that remain when addresses change still need to be fixed upstream by CHQ.
Like just about any geocoding process, there are some errors, though. Maddeningly, such errors are unreported by BatchGeo. I suspect that these are cases where the Google API is guessing and returning something fuzzier than a true address-based lat/lon, and that status is reported under the hood to BatchGeo, but the accuracy status is kept from the BatchGeo.com user. So the service still must be used with a grain of salt.
Accuracy aside, however, for reasons of privacy I still would choose not to upload membership name-address data to BatchGeo.com.
In the long run, capturing accurate lat/lon coordinates on the Church's maps.lds.org site seems the better alternative to satisfy privacy requirements. In the short run, I confess, I still do not use this data for serious tasks because our ward has not invested the clerk time to manually verify (and reverify as needed) all our addresses online. Surely this would have to change if performing that now-optional task were mandated by our stake. So if stakes do want to use this securely private data for boundary work or other purposes, they would be well advised to instruct their ward clerks to undertake and maintain the work. Stake clerks lack the privilege to do it themselves. Meanwhile, the gross processing errors that remain when addresses change still need to be fixed upstream by CHQ.
-
johnshaw
- Senior Member
- Posts: 2273
- Joined: Fri Jan 19, 2007 1:55 pm
- Location: Syracuse, UT
-
RossEvans
- Senior Member
- Posts: 1345
- Joined: Wed Jun 11, 2008 9:52 pm
- Location: Austin TX
- Contact:
The geocoded downloads from maps.lds.org have been there for some time, but the content has varied. Notably, the confidential fields available to leaders used to include the MRN; then that key data was taken out; now it is back again. The inclusion of that unique key is very important for doing any local database work to slice and dice the demographic analysis because the geocoded download can be linked to the MLS export tables. (BTW, that has enabled me to compare the Church's geocoding with my own locally generated "gold standard," so I can generate an objective measure of accuracy within my GIS application.)JohnShaw wrote: I agree with your assessment, when I used batchgeo it was prior to the downloads being available in the maps tools, or prior to my knowledge that they contained them --> so I endorse the method of downloading the maps.lds.org and running the csv through a conversion utility to KML
I have noticed that the quality of the automatic geocoding done for maps.lds.org has improved over time, although the complete process still assumes manual verification by ward clerks. The most egregious problem remaining is not in the geocoding itself, but in the logic in the backend workflow determining when addresses are geocoded (or not). When an address changes in the household record, even within the unit, that should trigger a reset, with fresh geocoding and fresh verification. Right now, when a household moves, its new address will be displayed but the location will still be plotted at the old coordinates. Even worse, if the old location had been marked as "Verified," that bogus location will still show as "Verified" even though it may be miles away from the new address.