emergency prep zones support on new lds.org maps functionality

So you have the BIG idea that the Church or community needs to develop. Discuss that idea here. Maybe you just want to make a suggestion on a new forum topic. Let us know.
pbelb
New Member
Posts: 2
Joined: Sun Feb 28, 2010 2:21 pm
Location: texas, USA

emergency prep zones support on new lds.org maps functionality

Postby pbelb » Thu Dec 23, 2010 7:48 am

the maps are a great feature of the new lds.org web site.

as our ward's emergency prep specialist, prior to the new lds.org site being available, I created a reasonable solution using postgresql + postgis with google earth + code to:

a) download from the lds.org (old site) the list of ward member families
b) insert those 'families' into the db, while also adding distinct 'address' records.
c) perform geocoding for each newly discovered 'address'
d) generate KML for all families for use with google earth
e) draw emergency prep 'districts' within our ward boundary
f) import these district boundaries into the database
g) use gis queries to generate listings of families grouped into districts
h) I can make google maps or earth viewable results of my work available to others.
i) allow repositioning of families in google earth to be imported back into the database.


the beauty of this is that:

1) I can manually position family locations if need be
2) I can re-run the import of families to add/remove families
3) re-importing families does not do away with previously geocoded addresses
4) without having to re-geocode addresses that have already been geocoded.
5) I can focus on creating the boundaries without the headache of manually creating updated district assignments listings.

since you now have much better mapping available on-line via the new lds.org site, and allow people to manipulate their location... how about:

allowing the bishopbric to identify an emergency prep person and enable them with somewhat similar kml generation/import capabilities for off-line creation tasks, or, do it all online.?

this could potentially be extended to being used to prepare potential ward boundary change scenarios.

the main thing would be to leverage the geocoding functionality so that lists can be generated as result of being aware of which families the boundaries encompass rather than having to resort to by-hand geocodes.

emergency prep zone details could then also be made available individually via lds.org so that families could see what the groupings are. you might also allow the emergency prep specialist to nominate / record emergency response assignments so that (for example) district 'captains' and other per-district resources can be tagged and seen / printed by members. eg: per district, which priesthood leaders have been assigned as issue escalation paths?

pbelb
New Member
Posts: 2
Joined: Sun Feb 28, 2010 2:21 pm
Location: texas, USA

seems like you already have 85% of the puzzle already in hand

Postby pbelb » Wed Jan 05, 2011 5:43 pm

well, I haven't seen any comments as yet, but it does seem to me that the new lds.org site has 85% or so of the needed functionality already available to make this happen.

I'm sure you guys are using the gis functionality in the oracle databases for helping figure out who is in which ward's boundaries - it just needs the ability to allow sub-boundaries to be created (perhaps even just imported from google earth) so that they could then be shown to all of the ward membership, and then, allow a listing per sub-boundary so that members can easily see / print a listing of who is in which area.

you could also (if you don't do this already) allow the export of the member details / locations in a google earth friendly way.

how 'bout it?

lwaynej
New Member
Posts: 4
Joined: Wed Jan 26, 2011 9:37 am

I have also worked with this

Postby lwaynej » Wed Jan 26, 2011 9:57 am

I have also worked on this. The problem with using google is that it basically uploads the ward list to google and I believe this is against church policy. Because of this I did some research and went a different route. Using the US Census Bureau Tiger data I created my own geocoder. I then route a small program that geocoded each address and then sorted them into geographic lists. I used google earth to create the polygons and exported the as a KML file. The list of members in each zone also included the lat. lon. so no addresses were uploaded to google. Once this is done sorting into zones is mostly trivial. Point in polygon algorithms have been in use for graphics (and GIS) for decades. The only issue that I did not resolve. Typically you want to use streets as boundaries so which zone do you put an address in when it falls on the polygon line? I think this is fairly trivial to solve in most cases.

Since doing this I have run across an open source project, used by emergency response organizations, that probably does a better job. This project uses Ruby, the TIGER data, and Sqlite with spacial capabilities added as a module. I don't have the name of the project right with me right now. I will find it and post it here for those interested.

RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Postby RossEvans » Wed Jan 26, 2011 11:11 am

The problem with using external geocoding methods is that the coordinates never get captured in the Church's own system.

The online geocoding tool that has been deployed is, ultimately, manual. The only way to capture accurate coordinates offset from the street centerlines and aligned with each property is to click and drag manually and visually. This presumes that the local ward clerk will know the correct location when he sees it. Outside the Wasatch Front, that typically requires viewing some external reference source, one household at a time.

But the system is what it is, and labor is free in the Church. So it seems that wards should just staff up and get the manual work done to capture the coordinates and build this database asset. (I say this even though my ward has not yet undertaken this task comprehensively. For internal purposes we still use external geocoding from a local public-domain source, which happens to be excellent. But all the accurate locations do not get captured in the central Church database or displayed on the web site.)

It is also true that there is not yet any support for boundaries -- for emergency preparedeness districts, unit boundaries, "Geo Code" boundaries, fast offering routes, home teaching routes, etc. And there is no point-in-polygon GIS functionality. So at this point, such functionality requires exporting the data captured in the maps site and using some external tool. (I happen to own GIS software, but I am an unusual outlier.) The export functionality of maps.lds.org is somewhat crippled by the recent move to remove the confidential MRN from the exported files as a relational link to ward rosters. But it is still possible to try linking via the addresses themselves.

lwaynej
New Member
Posts: 4
Joined: Wed Jan 26, 2011 9:37 am

Geocode source

Postby lwaynej » Wed Jan 26, 2011 7:12 pm

I don't think manual is the way to go. This problem has already been solved. I am not sure online is the way to solve this either. The trivial solutions are CPU intensive but if you run it in the clerks office computer who cares. Wards in our Stake have about 70% turn over from year to year.

Here are the resources promised:
This is a Ruby tool that will take the Cenus Bureau TIGER data and create a Geocode database for the US. It will probably be almost as good as Google, Yahoo, etc.

https://github.com/geocommons/geocoder

The point in polygon algorithm is explained here:

http://local.wasp.uwa.edu.au/~pbourke/geometry/insidepoly/

My implementation was about 18 lines of code.

PostgreSQL has spatial extensions and I think the geocommons code referenced above relies on spatial extensions for SQLite.

Wayne

RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Postby RossEvans » Wed Jan 26, 2011 7:46 pm

lwaynej wrote:I don't think manual is the way to go. This problem has already been solved. ...


Actually I agree that the manual step is lamentable, but it is the way the mapping site was built so the fact remains it is the only way to capture accurate coordinates in the Church database. Yes, the state of the art in automated geocoding is much better for most U.S. urban/suburban addresses. But implementing state of the art geocoding can be expensive on this scale.

(BTW, I don't agree that TIGER-based geocoding is state of the art. It is one method to do approximate batch geocoding for free. The better geocoding systems improve on this by applying parcel-based accuracy. But that typically costs more. And the objective of the Church system is to capture "rooftop level" accuracy for all households, at least for single-family homes. By doing this in the labor-intensive way, at least the Church can build a valuable database asset for a lower cost. This is really only feasible because labor in the Church is free.)

lwaynej
New Member
Posts: 4
Joined: Wed Jan 26, 2011 9:37 am

State of the art

Postby lwaynej » Thu Jan 27, 2011 10:18 am

I never meant to imply that TIGER was state of the art. It is what most other geocoders are based on. They do spend money making them more accurate. However, for generating lists of people that live in a specific area it is good enough. In my ward there were only about 10 addresses that did not geocode very close to the actual location. I do think that 10 addresses can be geocoded manually. If the system is setup correctly these addresses can be geocoded using other means (eg Google Earth) and added to the list. Other than generating the 'zones' I don't think mapping is really necessary.

The problem we are trying to solve is grouping people by geographical area. Once the groups are created there are numerous ways to plot them on a map that don't cost very much. Commercial solutions are available for < $50. It's the sorting that cost money.

Running the whole ward list through Google/Yahoo/etc. does cause problems but running one or two addresses manually through them does not really create a situation that does not already exist.

RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Postby RossEvans » Thu Jan 27, 2011 11:28 am

lwaynej wrote:I never meant to imply that TIGER was state of the art. It is what most other geocoders are based on. They do spend money making them more accurate. However, for generating lists of people that live in a specific area it is good enough. In my ward there were only about 10 addresses that did not geocode very close to the actual location. I do think that 10 addresses can be geocoded manually. If the system is setup correctly these addresses can be geocoded using other means (eg Google Earth) and added to the list. Other than generating the 'zones' I don't think mapping is really necessary.

The problem we are trying to solve is grouping people by geographical area. Once the groups are created there are numerous ways to plot them on a map that don't cost very much. Commercial solutions are available for < $50. It's the sorting that cost money.


I am not arguing against using external solutions in addition to the Church tool. In fact, in my ward I continue to geocode all members externally using a method that is far more accurate than either the Church's approximate geocoding, any other approximate methods based on TIGER, or most other free resources. Our addresses are mapped exactly in this external tool, although we have not yet done anything to map apartment dwellers within their multifamily properties. I routinely use external GIS tools to do such geographical groupings for some purposes, and adding "emergency prep districts" would be no big deal. It also would be no big deal to do precise unit boundary analysis far more easily than in MLS, which remains geographically dumb.

I am saying that ignoring the manual, Church-supplied geocoding tool has the major drawback that accurate coordinate data never gets captured in the central Church database. Thus it fails to meet the Church's objective of building a comprehensive rooftop-level database -- one that is far more accurate than most local users can build for themselves automatically at relatively low cost.

Once that database is accumulated , it becomes feasible to use it for multiple purposes -- most of which, as of today, still require external mapping or GIS tools. But so long as the geocoded data is exportable, those external tools can still be used. Hopefully, some of that functionality will get added into the Church systems themselves someday. But GIS functionality is not very useful without accurate geocoded data. As I said above, it is lamentable that Salt Lake could not afford state-of-the-art geocoding to capture most address coordinates (in the United States, at least) accurately and automatically. I certainly made that argument during the early beta of the Church system. But that view did not prevail, and I think cost was likely a determining factor. So the tool that was developed substitutes free manual labor (aka the priesthood) for that purpose. That burden does not fall on the emergency preparedness specialists, but on the ward clerks and their assistants.

I also suggest that there is more to emergency preparedness than just grouping households into approximate areas. Modern civil authorities would never consider approximate geocoding adequate to support dispatch of first-responders in an emergency. To support real emergency use when the tornado, flood or blizzard hits, and the stake or ward priesthood leaders might need to dispatch a team to the field to aid the widow Jones, true rooftop-level geocoding is important. That is one reason it is the goal of the central Church mapping system, which actually was driven by emergency prep as one of its primary requirements. The time to collect accurate geocoded data is before the emergency happens.

lwaynej
New Member
Posts: 4
Joined: Wed Jan 26, 2011 9:37 am

Manual Geocoding

Postby lwaynej » Thu Jan 27, 2011 4:45 pm

I am not against capturing the data. It's just that it would probably work a little better in your area than in mine.

There about 33,300 housing units in my ward. We have about 350 members on the rolls and about 1/3 make it to Sacrament meeting on a given Sunday. We have somewhere between 100 and 200 people move ins (and about as many move out) every year.

At least in our area Google already building comprehensive geocoding. If I include the apartment number it will show me the building in most complexes. Clearly using Google for the entire ward list (or even significant parts of it) would not be the right thing to do.

What it all boils down to i our emergency response needs are much different than yours. In most areas of Utah the Elders Quorum president can rely on Home Teachers to check on the members . That doesn't work so well here. Our Ward is about 14 miles long and 5 miles wide (an educated guess) There is one major free way the runs through the ward and in the invent of a large earthquake it may be impossible for members on one side of the freeway to access the members on the other. We have talked about assigning home teachers based on geographic regions but limits who can be assigned to families with needs.

Our solution was to break the ward up in to 'neighborhoods' and assign an active family or families in the neighbor hood to be responsible for reporting into the Bishop (it's a little more involved than that.)

For this purpose sorting people into zones is good enough. People tend to know their neighborhoods well enough that close is good enough.

I'll have to checkout the mapping tools when I get a chance.

RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Postby RossEvans » Thu Jan 27, 2011 6:09 pm

lwaynej wrote:I am not against capturing the data. It's just that it would probably work a little better in your area than in mine.

There about 33,300 housing units in my ward. We have about 350 members on the rolls and about 1/3 make it to Sacrament meeting on a given Sunday. We have somewhere between 100 and 200 people move ins (and about as many move out) every year.


Actually, that sounds pretty easy compared to my ward, which has about 900 members spread over a much larger area than yours -- about 160 square miles of urban-suburban landscape containing several times more housing units than your boundaries do. I estimate that verifying all the addresses online would take many man-hours, which is surely one reason my ward has not done it yet. And of course it all has to be maintained.

To be clear, I don't think there is anything easy about the online capture tool using click-and-drag to verify each address. (The set of "unverified" addresses is probably about as accurate as your TIGER-based geocoding would be, albeit unfortunately placed in the middle of the streets.) One inherent problem is that the clerk usually has to find some external reference to know where the correct point for each address is. That might be some official public source, it might be Google (I see nothing wrong with using Google or Bing interactively as a visual reference), or in extreme cases it might mean a drive with a GPS.

I just think the online tool is what it is, and we apparently will have no other method to populate the central database other than through such work. Since clerks are so integral to success of the mapping project, I'm a little surprised at the low-key rollout of the site. It was in beta for a long time, then just quietly went live along with the new lds.org site. The "unverified" database is not supposed to be a finished product, but rather a starting point. It still requires clerks to do a lot of work. However, I am unaware of any top-down instruction through channels telling units to saddle up and do it.


Return to “Ideas & Suggestions”

Who is online

Users browsing this forum: No registered users and 1 guest