Ward Maps

[WelchTC]

LUWS is scheduled for some major work and we plan on reviewing all of the suggestions and bugs at that time.

Tom

[mkmurray]

Tom,

I just tried to edit kgthunder's link to another thread by making it a relative link rather than an absolute one (we aren't going to be in beta forever, and thus the beta.tech.lds.org would break the link when we go live). However, it appends http:// to the front of whatever I type in. Perhaps you can show me how it is done? Thanks. :rolleyes:

[WelchTC]

Tom,

I just tried to edit kgthunder's link to another thread by making it a relative link rather than an absolute one (we aren't going to be in beta forever, and thus the beta.tech.lds.org would break the link when we go live). However, it appends http:// to the front of whatever I type in. Perhaps you can show me how it is done? Thanks. :rolleyes:

Read here on how to link to threads and posts. These links will be relative.

Tom

[greenwoodkl]

Thanks mkmurray for the update and tomw for the link - am I missing the link to this in the normal navigation, or is it buried several layers deep? Could it be moved to a more conspicuous location for easy reference?

[mkmurray]

Thanks mkmurray for the update and tomw for the link - am I missing the link to this in the normal navigation, or is it buried several layers deep? Could it be moved to a more conspicuous location for easy reference?

I believe the way to find it is FAQ on the black navigation bar near the top. From there, it appears to be one or two more clicks away.

[WelchTC]

Thanks mkmurray for the update and tomw for the link - am I missing the link to this in the normal navigation, or is it buried several layers deep? Could it be moved to a more conspicuous location for easy reference?

The other way to find it is to look at the bottom of the page (while viewing or writing a post) and you will see a box that says "Posting Rules". In this box you will see a link called "vB Code" which links you to all of the legitimate vBulletin markup codes you can use and how to use them.

Tom

[James-p40]

What Kevin has done with his site is very cool. We would like to add this functionality to the LUWS and because of Kevin's great work, we are organizing a team to understand if and how quickly we could add this type of capability to our site. We have asked for Kevin's help since he was the original author of the code.

In our ward, we did something very similar, but used Google Earth to avoid some of the privacy issues mentioned in this thread. It offers very similar functionality to Google Maps, but not online, so that access to the data can be restricted to those who should have it.

[charlesb-p40]

We rearranged the boundaries within our stake last year. I had never been involved in boundary changes before, and I was shocked at the amount of work involved in doing it right. It was a significant part of my life for over a year. I of course wanted to be able to put the data on a map, draw boundaries and do "what if" scenarios with immediate feedback. I started looking at various GIS solutions and playing with different ideas, and was shocked at the cost of any product that was useful, and the lack of anything out there that did what I needed.

I ended up combining MS MapPoint, MSAcceess, Yahoo, & a custom program I wrote in VB (called "GeoCodesMP") to do it. I originally thought I could do most of it in MapPoint, but then I realized what a pain it was to change polygons, and how sad the data was. Even when 2006 was finally available, it wasn't much improvement. The data was old, and more importantly, there was no centerline data included, putting everyone's house squarely in the middle of the road, right down the middle of a lot of urban ward boundaries. I was almost ready to write my own GIS program to parse the Census Tiger/LINE files and mange boundaries, but I didn't have *that* much time on my hands!

Here's the process I ended up with:
1. Export membership from MLS
2. Use GeoCodesMP to append Long/Lat info to the file through the Yahoo mapping API.
3. Import the data into MapPoint, geocoding based on Lat/Long rather than address.
4. Break stake up into many (sub-ward) geocodes by drawing polygons.
Each polygon has exactly one text box in it with the boundary name.
All polygons butt up against adjacent shapes.
5. Use GeoCodesMP to export data from MapPoint, tagged with geocodes
(MapPoint merely allows you to export the data within a single polygon)
6. Import the data into specially prepared Access Database
7. Run a series of 7 macros to build additional tables to establish baselines
and make stat calculations easier.

The database itself is pretty involved; looking at my old file here I see 10 tables, 35 queries (3 are temporary), 4 reports, 5 macros, and a VBA module.

At this point we had a system where we could easily assign geocodes to different wards and get instant updates on statistics, as well as view details. (We did end up massaging geocode boundaries, which meant that we had to restart at step 4. Actually, in the course of a year, we ended up refreshing the data and re-geocoding it, too, which was a pain.)

Once we did everything, it was beautiful. We were able to easily complete the paperwork for Salt Lake (using real numbers, not wild guesses), and after the changes were approved I handed each bishop a huge packet with a overview maps, detail maps of the changes, summary reports of stat changes, and detailed reports of families moving in, moving out, major calling losses, etc.

The downside: Now that we made it look easy, all the wards think we have a fancy GIS, and they all want a copy of it so they can refine the geocodes for emergency preparedness. I told them they're welcome to a tagged list and copies of our maps, but they don't believe me when I tell them that there's no program they can borrow to easily sit down and do everything they want.

The overall result? Fantastic. The process? Ugly! The idea that units across the globe go through this process all the time, and while some are probably simple "This ward's huge. Let's draw a line down the middle and split it, and guess at the stats for the paperwork" revisions, I'm sure many have had more effort put into them than ours -- the total amount of duplicated & wasted effort just boggles my mind!

Now that I've been through the process the hard way, I realize how much (time or money) a system would be worth to me that made it easier. If someone wanted to sell me a product that would do it all the easy way, I'd sell my firstborn on the black market and write a check for $1000 in a heartbeat. (Okay, maybe not the first part. Shouldn't fib on a church board...)

Anyway, that's my story. Just had to share it, since we were talking about boundary changes. BTW, if anyone is in dire need something to help them organize a boundary change and is geeky enough to work with a really raw toolset, you're welcome to what I have. I can't offer a lot of support, though, because I've got a lot of other projects that I need to devote some serious time to right now.

[blackrg]

Looks like I'll need to halt my efforts as well. I wasn't aware of the others who have been working on this. I've been working on one for our ward using Perl/MySQL/PHP. I export the data from MLS, use a Perl script to load the DB and check Lat/Long on everything, and then the users use the PHP interface for search criteria and maps. The server involved was my own, hosted by my company, utilizing SSL. I'm a clerk for our ward currently so I already had access to the data, and the Bishop approved who did and didn't have access. It's still not in a "Finished state" as a large number of the features we wanted to add still need to be implemented. Before I started on this project, I spent some time talking to the various leaders who would need access as well as falling back on some of my own experience in some of these positions to determine what features were needed and would be useful. I would like to list some of what I found here in hopes it may be helpful for what the Church is working on.

1. Search Criteria

This is actually a much more difficult issue than it may at first appear - probably the most difficult part of the whole thing. Quite often, what is needed with these maps is not a map of all members in the ward, it's a map of members meeting certain criteria such as all the elders, all the single parent homes, all new members, all homes containing children between 12-18, etc. Some of these searches are pretty obvious such searches to help with planning home teaching or visiting teaching routes, but others were a bit less expected and tended to come from the Bishop and fell along the lines of "well I'm going to be in X area today, and after we finish our visit there, I'd like for us to go visit all Y type families in the nearby area".

In working out how the search criteria would function, the first thing I had to realize was that they were not searching for individuals. They were searching for families that contained individuals of X type. That made everything much easier once I started working along those lines. I also realized that recognizing whether or not a particular person was either a head of household or a spouse to the head of household was important as well as their other attributes (age, gender, priesthood, etc.) so my search form took on more the form of the family (fathers criteria, mother's criteria, children criteria) with and/or options available between the different household members. This gave the program a fair amount of flexibility in what could actually be searched, though I always felt my form layout could somehow be better than it was to help cut down on possible confusion (Searching for all Elders would require filling out a slot for Father matching elder as well as filling out a child slot matching elder since elders could be present in a household as either children or parents).

As a separate criteria from this, I also allowed them to select one of the households in the ward and specify that all results must be within X miles of that household (as the crow flies).


2. Display results

It's tricky to map points like this where there may be a fair amount of data needed from each point and yet keep that data from obscuring the map in some way that makes it less than useful. I had all the traditional map features included (drag, zoom in and out, etc.) and am presently using a generic diamond shaped icon large enough to be noticed but small enough to stay out of the way. I had some discussion going on about the possibility of using icons composed of colored bars to represent different things about each household with significance being placed on the location of the bars as well ( husband member/priesthood, wife member, children, etc.).

My icons would allow you to mouse over them for some info and click on them for additional info. The info displayed was something I was in the process of allowing them to select from the search form (Head of Household name, phone number, names of all household members, ages of all household members, priesthood held, address, etc.) so the user could find only the data they wanted without having to wade through to much of what they didn't want.

What really starts to make this tricky is when you start to consider printing. What makes it even more tricky is when you realize that sometimes you need to print vastly different things depending on the need for the data to begin with. Sometimes you only need the locations with a key for household names, other times there's a lot of additional data you need. Often, in my case, I was faced with people who wanted it for directions as well to visit those people. In that case you might be better off dumping the matching households out to something else to produce driving directions. Printing was something I hadn't implemented yet and was still trying to work out how to manage, meet their needs in the process, and stay in compliance with any of the applicable usage rules.

3. Unexpected results/benefits

One of the unexpected benefits of all of this, was that I could generate reports from the DB of how well the lat/long conversion had gone. Based on the results, it was much easier to spot bad address information in our MLS and then set about doing the homework required to get it fixed.


Also, for whatever reason, we had a number of people in our MLS with an address outside of ward boundaries (bad address, kid of to college and the records haven't been moved for some reason, etc.). As a built in part of the search criteria, I skipped over anyone outside of a generous Lat/Long box I drew around our ward boundaries. This also made it easier to determine whether or not someone was actually IN our ward boundaries (given the design of both our boundaries, and the roads around here, that's not as easy as you might think).

I hope some of this is of use. If there are any other questions about what I found, or what I did, feel free to ask or contact me directly. Also, if the Church is looking for some beta testers, I've got a Bishop (and probably a few others) who would like to wear it out for you and provide feedback. If you want it broken, I'll be glad to do my best for testing purposes

[WelchTC]

Awesome feedback! It always helps when someone has done a lot of the pioneering work!

Tom