Membership maps

I was able to create membership maps using Google Earth and i love it. I have all the members in the entire county. Before i introduce it to leaders in the stake, i wanted to know the privacy policies with this as to not let this information get out of hands. I was planning to send it to a few people like some high counselors, stake president and my own elders quorum presidency. I know this it talked a lot on this forum. i just wanted some advice about this.

falisrm wrote:I was able to create membership maps using Google Earth and i love it. I have all the members in the entire county. Before i introduce it to leaders in the stake, i wanted to know the privacy policies with this as to not let this information get out of hands. I was planning to send it to a few people like some high counselors, stake president and my own elders quorum presidency. I know this it talked a lot on this forum. i just wanted some advice about this.

There are several threads in the Forums that discuss privacy matters as it relates to using mapping software on third party servers. I will try to find some of them for you and include them in another post. The short of it is that due to privacy, no information about members may be exported from MLS and stored on a mapping program such as that found at Google Earth. You can use the addresses as long as the names and any other privacy information are not included. Using mapping programs such as Google Earth implies that the data you supply will be stored on their servers and potentially available to the rest of the world.

I was debating to include names in the addresses too. I did on some of them with names just to see if it would work and it does. If anything its for a visual description of the area to see where members are located in proximity to the county. It could help with boundary adjustments or determining where chapels should be built.

I'm amazed with the number of members in the county. It's a lot.

After just a quick search of the LDS Technology Forums the forum "MLS Support, Help, and Feedback" has several threads related to your question. The first thread, GoogleEarth and Membership Data, directly addresses the issue of privacy. There is another thread, Yet another Map-maker post, that discusses privacy.

You can do your own searches to find a large list of threads around the topic of mapping and geocoding. Membership privacy is sometimes addressed in these threads.

jdlessley wrote:There are several threads in the Forums that discuss privacy matters as it relates to using mapping software on third party servers. I will try to find some of them for you and include them in another post. The short of it is that due to privacy, no information about members may be exported from MLS and stored on a mapping program such as that found at Google Earth. You can use the addresses as long as the names and any other privacy information are not included. Using mapping programs such as Google Earth implies that the data you supply will be stored on their servers and potentially available to the rest of the world.

Actually, I think that generalization gets it quite wrong with respect to falisrm's post..

Google Earth, a local application installed on the user's PC, does not share the user's name-address data with anyone. The user's data is not sent to a third-party server. Google Earth merges the local data with base-map data pulled from the Internet.

[Addendum:. And the ancient thread "Google earth and Membership Data" jdlessley' just linked to is misleading. I never bothered to post on that thread because it is so old. If you read it carefully, you will see that the poster's worry about Google Earth boiled down to a rather breathless, unsupported suggestion that Google Earth might actually be spyware, "phoning home" data to the mothership. Even he acknowledged that was far-fetched. I would pay it no heed.]

That is quite different from some Internet mapping engines, such as Google Maps, Yahoo, etc. Uploading data to the My Maps feature of Google Maps would be storing the data on Google's server, in which case jdlessley's advice applies.

There also are other configurations that use the Yahoo Maps API to build a web page using client-side code. In that case, while address data only might be sent to Yahoo for geocoding, the resulting map is assembled client-side, on the user's PC, so there is no privacy problem. kevandcan's seminal Ward Maps application is a good example of that http://tech.lds.org/forum/showpost.php? ... stcount=32

There's been some discussion here on scripts that will create maps of members. I don't see any problem with sending the KLM file to another person who has access to the underlying information. I would be a bit concerned on how the file would be sent. Not everyone has their own email or their own personal computer so I'd give some thought as to how sensitive the information contained may be. It's probably not a issue, but it's worth examining in case it contains information the general membership wouldn't normally have access to.

falisrm wrote:I was debating to include names in the addresses too. I did on some of them with names just to see if it would work and it does. ... I'm amazed with the number of members in the county. It's a lot.

There is no inherent reason not to put names in KML files, just as there is no inherent reason not to put names into Excel files or Word docs or printed directories. It depends on what the content is, where you got it, and who you are giving the files to.

In our ward, we have KML files showing all the ward members, as well as specialized files showing all our home- and visiting-teaching assignments. The scripts that produce those files have been published here http://tech.lds.org/forum/showpost.php? ... stcount=67 Others here have also used Google Earth a handy, secure medium for viewing such files.

If there are privacy concerns with these files, they might pertain to members who have requested that their names not even appear in ward directories. (See discussion preceding the link above.) That could be an issue with respect to using my scripts above, because their source data is the ward's MLS system.

So where you are getting your data makes a difference. I am curious as to the source of data, which "amazed" you to find so many members in your county. My county certainly does not publish a directory of known LDS members. What is your source?

It would be very personal to use google earth. I think that's why i like it. And the technology is great. Maybe the biggest thing i'll do is post it on the News and Information Section in the official ward website. That way people with passwords and an account will be able to download it.

Oh, i got the data from each wards (cvs?) list in excel from the ward websites. We have 2 stakes so i used my moms account for the other stake (so sneaky, i grew up in that stake plus i'm moving back into it next month). It was easy to copy the column with all the addresses in excel into one list. there was a program that automatically converted the list into a file for google earth. It took like 1 hour to do.

falisrm wrote:It would be very personal to use google earth. I think that's why i like it. And the technology is great. Maybe the biggest thing i'll do is post it on the News and Information Section in the official ward website. That way people with passwords and an account will be able to download it.

That is not possible, I believe, because the only attachments allowed are .PDF, .XLS and .DOC.

So you would need another distribution medium.

And, once again, whether you distribute the files and to whom depends on their actual content, where you got the data, and the intended audience. RussellHltn cautions to be careful with email, which I second in the sense that I also recommend sensible precautions about distributing any other file formats via email.

[Just saw your post. If your source is the LUWS web sites, then it has already been pretty well scrubbed. Any member with access to their local website can download the directory as a .csv and make their own map. I won't comment on using your mom's username and password for the other stake. And the usual warning applies about appropriate use of that data in any form, which warning is displayed at the time the directory is downloaded.

As a technical matter, be aware that Google Earth's methods you describe for geocoding the roster are inherently error-prone to a significant extent. See http://tech.lds.org/forum/showpost.php? ... ostcount=7 ]

falisrm wrote:Oh, i got the data from each wards (cvs?) list in excel from the ward websites. We have 2 stakes so i used my moms account for the other stake (so sneaky, i grew up in that stake plus i'm moving back into it next month).

Upon reflection, I will comment after all on your abuse of your mother's username and password to gain access to the neighboring stake's directory. I find it quite abhorrent, and I can't imagine why you thought your stake president might be impressed if you give him a show-and-tell based on that misbehavior.

This criticism has nothing to do with maps or Google Earth, but with the terms of use of the church web site.

I strongly suggest that you delete the data you downloaded from the other stake and start over.

I think that sending someone data that is freely available through the ward website, in any format should be ok. All addresses, phone, etc. are available on the site. That being said, you can also remove your info from that site so using it would be acknowledging a members request not to be shared.

Just a thought...

Boomerbubba ,thanks for the script and fantastic directions (& included prompts). I had gone so far as to purchase Microsoft Streets & Trips to try to make the maps the bishopric needed. This works much much better.

By the way, the labeling on that MS program is haphazard and does not make a good final product.

IMHO, the privacy policy would not prevent clerks or bishopric members from using MLS data on desktop apps like Google Earth. It is the same as using Excel to sort the data in an export file.

Mr. M wrote:I think that sending someone data that is freely available through the ward website, in any format should be ok. All addresses, phone, etc. are available on the site.

This is a dangerously broad-sweeping statement that in some cases is just not true. First of all, this information is NOT "freely available". Users must properly identify themselves by registering and logging in before access to it is granted. Second, this information is considered confidential and should NOT be given to anyone outside the Stake, or given to anyone at all for political, business, or commercial purposes.

I hope that's what you meant to say.

Mike

falisrm wrote:I was able to create membership maps using Google Earth and i love it. I have all the members in the entire county. Before i introduce it to leaders in the stake, i wanted to know the privacy policies with this as to not let this information get out of hands. I was planning to send it to a few people like some high counselors, stake president and my own elders quorum presidency. I know this it talked a lot on this forum. i just wanted some advice about this.

The policy is that Membership personal information should not be distributed to the general public. The steward for the local unit data is the Bishop. If you coordinate with each bishop about your project and they are ok with sharing this information you will be ok. Also make sure that you stake president is aware.

Gaertnerg wrote:The policy is that Membership personal information should not be distributed to the general public. The steward for the local unit data is the Bishop. If you coordinate with each bishop about your project and they are ok with sharing this information you will be ok. Also make sure that you stake president is aware.

I would add that if you are in a calling that supports, advises, or counsels with the Bishop that you research Church policies and the legalities before taking it to the Bishop. Your request for his OK may imply that you have checked all the issues of which he may not be aware. This forum is one tool to help you do just that.

Gaertnerg wrote:The policy is that Membership personal information should not be distributed to the general public. The steward for the local unit data is the Bishop. If you coordinate with each bishop about your project and they are ok with sharing this information you will be ok. Also make sure that you stake president is aware.

If you follow the facts as they unfolded in the thread above, it turns out the original poster had obtained half the data by "so sneaky," unauthorized access to a neighboring stake's LUWS directories. So the first question the second stake president would ask would be, "How in the world did you get your hands on our data?" The first stake president, in the stake where the poster actually resides, could not be pleased, either.

I believe it has been repeated quite a few times on this thread that the data should only be used for church purposes and not used for any other purpose. The question I would ask is for what purpose is the ward and/or stake being mapped out? If there is a reason, who is involved, how is the data being distributed to interested parties?

I think, the answers to these questions will address many of the concerns voiced in this thread. If the endeavor is being undertaken to help oneself in locating members in connection with a calling, the data is not being distributed to anyone and it is not being served by a third party but residing on a local computer it is no different than downloading the xls or cvs file from the LDS website. There should be no major concerns. If however, one is geocoding and mapping out your members and then distributing the data to other members it would be good practice to let the unit(s) priesthood leaders know what is going on.

It could be argued that as long as the data is not being stored by a third party there is no need to let leaders know what is going on. After all, the data is being sent to other church members for church purposes and it being stored locally by members, which is akin to sending xls files back and forth. However, the information is now being distributed by an "unauthorized" source and the data is being visualized in a way that is still relatively new and alien to many members/leaders.

For what it's worth - I have 8 children. Today I saw a map that a very well intentioned member of our ward put online. It had my name, my wife's name, my children's names, and our address all listed in a public forum. Granted it's not readily available because the URL isn't publicly available - but it's still concerning. I'm very nervous about having that information available for other people to see - particularly if there is any potential for abuse. I don't want my kids to inadvertently be put in harm's way.

I see the usefulness of knowing where a lot of members live - especially if you're moving to a new area and would like to live around Terrestrial and Celestial people or if you're a WML or missionary who wants to see where various members live. So taking just the addresses, but no names, and making a map is not nearly as concerning to me personally. But I think that the Church would be the better steward of that data and that they would be the best party to produce such maps in a more secure fashion.

I can also see how such maps would be useful when setting stake boundaries - knowing where the concentration of members is geographically, where the Priesthood leaders are, and perhaps identifying growth areas so that you don't create a large ward in an area with a lot of new homes being built - you could start with a smaller ward, expecting it to grow.

I like the idea of Google Earth because it provides the same desirable information, just not in a public forum. Does anyone have a link to a tool that will take the LDS CSV file and convert it to a KLM file? That would be quite useful.

rhusted wrote:For what it's worth - I have 8 children. Today I saw a map that a very well intentioned member of our ward put online. It had my name, my wife's name, my children's names, and our address all listed in a public forum. Granted it's not readily available because the URL isn't publicly available - but it's still concerning. I'm very nervous about having that information available for other people to see - particularly if there is any potential for abuse. I don't want my kids to inadvertently be put in harm's way.

The Church has asked us not to post name-address information, in maps or otherwise, on third-party servers -- especially if the content was extracted from Church sytems such as the LUWS or MLS. That even extends to third-party servers under password protection. See this authoritative post.

Church developers are known to be working on an official member-mapping project that likely will meet most of the desire for general mapping. Presumably access to that dat would be secured, just as the existing LUWS data is.

rhusted wrote:I like the idea of Google Earth because it provides the same desirable information, just not in a public forum. Does anyone have a link to a tool that will take the LDS CSV file and convert it to a KLM file? That would be quite useful.

Google Earth is a much more secure format, because it is a local application and all private data is retained locally.

There are generalized ways to convert CSV files to KML, but they do so quite imperfectly. (Search "geocoding" on this forum and you will find many threads discussing it. See, for example, this recent thread.)The main problem is one of detecting and correcting the inevitable errors, and doing so reliably, cheaply and legally.

I have published scripts here to geocode ward addresses and create KML files, including error handling, but withdrew them to avoid violating legal restrictions on the free geocoding engine I used, Yahoo's. Instead, I now geocode our ward's roster directly from public-domain data available for my particular city, but that doesn't do most anyone else any good. The best hope for a general solution probably lies in the project underway at CHQ.

What is the name of the maps project that the Church is working on? What features / functionality will it provide? Is there a wiki page or anyplace where I can get additional information? Since we'll likely have to inform our well-intentioned members that they need to pull this information off Google, I'd like to give them some information about what the Church is doing and hopefully thus avoid any hurt feelings.

rhusted wrote:What is the name of the maps project that the Church is working on? What features / functionality will it provide? Is there a wiki page or anyplace where I can get additional information?

We're lucky if we know they're even working on a project, much less the details.

RussellHltn wrote:We're lucky if we know they're even working on a project, much less the details.

Yeah, it was only a 2 or 3 sentence statement by Church CIO, Joel Dehlin, somewhere on these forums.

rhusted wrote:What is the name of the maps project that the Church is working on? What features / functionality will it provide? Is there a wiki page or anyplace where I can get additional information? Since we'll likely have to inform our well-intentioned members that they need to pull this information off Google, I'd like to give them some information about what the Church is doing and hopefully thus avoid any hurt feelings.

Only general information has been released. The most authoritative statement is probably this short statementby Joel Dehlin, the Church's CIO.

While I have high hopes for this project, it is inherently ambitious. All those problems with finding and fixing geocoding errors for a single unit are multiplied a thousandfold. So don't set expectations too high about all this being accomplished immediately.

After reading all the posts on geocoding I am a little confused. Is it OK to use Google Earth to map the members homes? I have managed to do this but I hesitate to offer ti to anyone else in the ward...

zaneclark wrote:After reading all the posts on geocoding I am a little confused. Is it OK to use Google Earth to map the members homes? I have managed to do this but I hesitate to offer ti to anyone else in the ward...

It really depends on your tolerance for errors.

If you are using the batchgeocode.com method described in the other thread, I think there is a good chance your KML output would contain at least a few families mapped at incorrect locations, and would omit a few others. Or perhaps you will get lucky and have no errors at all.

rhusted wrote:For what it's worth - I have 8 children. Today I saw a map that a very well intentioned member of our ward put online. It had my name, my wife's name, my children's names, and our address all listed in a public forum. Granted it's not readily available because the URL isn't publicly available - but it's still concerning. I'm very nervous about having that information available for other people to see - particularly if there is any potential for abuse. I don't want my kids to inadvertently be put in harm's way.

...

(The following is my personal opinion, not necessarily held by any sane person.

I admire your restraint. If it were me, I would have already told the person who posted the information online the basic meaning of your last two sentences above and that I wanted the personal information about my wife and children taken down immediately, ...

rhusted wrote: ...
Since we'll likely have to inform our well-intentioned members that they need to pull this information off Google, I'd like to give them some information about what the Church is doing and hopefully thus avoid any hurt feelings.

... and I would let any hurt feelings be the problem of the person who posted the info. Again, I admire your restraint.

If you need backup to get the "well-intentioned" person to take the info down, I know of a police officer I used to home teach who now works in a high-tech crimes unit catching online predators. I'm sure he could convince the person to do the right thing.

zaneclark wrote:After reading all the posts on geocoding I am a little confused. Is it OK to use Google Earth to map the members homes? I have managed to do this but I hesitate to offer ti to anyone else in the ward...

I interpreted your question to be more about policy, and as far as I know, Google Earth is not going to send an ounce of your ward's personal information over the net. As far as redistributing within your ward, my personal opinion is that it is okay, but I would keep close reigns on it and only give it to those who really need it and would actually benefit from it. I would also give them a charge to be very careful with the information as well, maybe even securing it by password-protection in one way or another.

mkmurray wrote:as far as I know, Google Earth is not going to send an ounce of your ward's personal information over the net.

I'm sure there is a way of uploading information via GE, so there's a way the info could get public. Hopefully no one is that dumb, but that one possibility keeps me from giving it a catagoric "It's safe".

RussellHltn wrote:I'm sure there is a way of uploading information via GE, so there's a way the info could get public. Hopefully no one is that dumb, but that one possibility keeps me from giving it a catagoric "It's safe".

Since our ward has been using Google Earth as a tool in our missionary work (we just implemented a new program that involves nine ward missionary couples in nine ward missionary districts) I have been keeping the enthusiasm to spread household information properly oriented - supported by discussion information I have garnered from these forums. After instructing our ward mission leader in the use of MLS export information, batchgeocode.com geocoding, and Google Earth tools, he became so excited that he was promoting the idea of uploading Google Earth KML files to Google Maps for better distribution of information throughout the ward and ward missionary couples. Of course once he and the others were informed of the dangers and conflicts with Church policies on use of exported MLS and LUWS membership information over the web they restrained from using Google Maps as part of our missionary tools as he had planned.

I had no idea Google Maps could import KML files. But after researching it I discovered that Google Maps cannot directly import a file from a PC, or Google Earth, but it can import a KML file from a web site. The work around described in the Google Maps forum is to host the KML file at a URL address and then use the search feature of Google Maps to find the KML file on the other web site. So I guess indirectly it can be done. And with as many people out there that are not aware of, or familiar with, the Church's policies on MLS and LUWS data there is a chance for personal information to be inappropriately, or inadvertently, disclosed.

jdlessley wrote: I had no idea Google Maps could import KML files. But after researching it I discovered that Google Maps cannot directly import a file from a PC, or Google Earth, but it can import a KML file from a web site. The work around described in the Google Maps forum is to host the KML file at a URL address and then use the search feature of Google Maps to find the KML file on the other web site. So I guess indirectly it can be done. And with as many people out there that are not aware of, or familiar with, the Church's policies on MLS and LUWS data there is a chance for personal information to be inappropriately, or inadvertently, disclosed.

Actually, in addition to the hosted URL method you mention, the Google Maps web site this year added the capability to import a KML file directly from a user's PC. (There are some limitations.)

So members may be tempted to do this. However, I think that uploading name-and-address data to Google Maps clearly violates the policy guidance we have received from the Church. Uploading address-only data is probably okay, but that would not be very useful for a general ward directory.

We are using the Google Maps site in our ward for a particular purpose: generating printable maps of fast-offering routes, because Google Earth has lousy print functionality. (I expect to post about that application soon.) But we don't even upload addresses, just lat/lon coordinates. All the name-address data that accompanies the maps is assembled locally.

(BTW, for missionary purposes, we use a completely different method: A printed map of the ward using shrink-wrapped software, because the full-time missionaries generally lack Internet access. See details in this post.) I should think that ward missionaries would be able to use Google Earth directly.

Personally, in my discussions with friends and family, a more general mapping using Google Earth is more along the lines of most of my associates wants.

i.e. We're looking for Ward/Stake/Area/Mission/Temple bounderies shaded or outlined on the map with appropriate screening options included. For instance, while looking for a place to live in Taylorsville, I wanted to look in the area of a specific Stake and Ward but had no real idea of the actual bounderies. Being in California, our bounderies are a little more... ummm... less complicated. However, you get into a more member-intensive neighborhood or community and you may have three stakes within a five-mile sphere. One block could end up being a junction point for five Wards, two Stakes, and three Temple districts! (point-in-fact: the Stake/Ward I was looking at is one of the most compact in the entire church)

Having a comprensive map that shows ward boundries with appropriate meeting houses and stake centers would be invaluable in my estimation. It wouldn't show individual member addresses, so the privacy issue shouldn't come up.

goldcntry wrote:
Having a comprensive map that shows ward boundries with appropriate meeting houses and stake centers would be invaluable in my estimation. It wouldn't show individual member addresses, so the privacy issue shouldn't come up.

I thnk there is demand for both boundary and member mapping. (In our ward, the leadership uses member-mapping for several purposes. And many rank-and-file members want it, too.) The priivacy issues for KML files are manageable, just as the privacy issues for downloaded CSV files are manageable. All members who log on to the LUWS site are already trusted with those.

Meetinghouses are already mapped at maps.lds.org. And the Church's applications under development are expected to include display of unit boundaries. I don't know if they will also include an easy download function.

In any event, the boundaries themselves are not a secret. Units can get printed maps or PDF files for the asking from CHQ. Given those, it is not difficult to make boundary files yourself in Google Earth. You can just trace the boundaries carefully to create a polygon file. (To get greater precision, I use GIS software to do that and create the KML file, but not everyone requires such precision.)

Which GIS software do you use? Are there any good trial/freeware versions available? When our stake re-created all the wards and bounderies earlier this year, I was able to cobble together a fairly accurate map using (mashing together) Illustrator and Photoshop. It'd be great to create a clearer KML file (I'm one of those nit-pickers when it comes to dynamic graphics... *sigh*).

goldcntry wrote:Which GIS software do you use? Are there any good trial/freeware versions available? When our stake re-created all the wards and bounderies earlier this year, I was able to cobble together a fairly accurate map using (mashing together) Illustrator and Photoshop. It'd be great to create a clearer KML file (I'm one of those nit-pickers when it comes to dynamic graphics... *sigh*).

I use Manifold (www.manifold.net), a commercial product, at home and at work. Not free, but moderately priced compared to the industry-leading ESRI. There is some freeware out there, but I don't have the experience to recommend any of it. The major investment is really in wetware. Any GIS program is going to have a pretty significant learning curve.

boomerbubba wrote:There is some freeware out there, but I don't have the experience to recommend any of it.

Any thoughts on QGIS? It sounds like it has enough features, but knowing nothing about GIS, I wouldn't know.

RussellHltn wrote:Any thoughts on QGIS? It sounds like it has enough features, but knowing nothing about GIS, I wouldn't know.

I just discovered QGIS a couple of months ago, and have not made time to try it. All I really know about the software is from reading the web site. It does have a relational back end (PostgreSQL), and does offer a way to import shapefiles, which are the most common format for publishing public domain data. I didn't notice anything about exporting KML, which is becoming very useful for publishing maps via Google products. But that is not too hard to program.

The price is right. But since I have a pretty full-featured solution in hand, I just haven't been motivated to invest the time. Too much to learn and do elsewhere.

Just listing the functions we'd most likely be interested in would be a huge help. I know that's not something I'd know I was missing until I had invested a great deal of time in the product.

RussellHltn wrote:Just listing the functions we'd most likely be interested in would be a huge help. I know that's not something I'd know I was missing until I had invested a great deal of time in the product.

Or in other words, if you wouldn't mind, please list the most common and helpful features that one would need in GIS software (for the purpose of doing membership maps and the like).

mkmurray wrote:Or in other words, if you wouldn't mind, please list the most common and helpful features that one would need in GIS software (for the purpose of doing membership maps and the like).

Well, here is a modest description and primer on features I think are important. I am not trying to define all possible features of GIS systems, but focusing on what I think wards and stakes might need. Conceptually, it is helpful to think of GIS software as a conventional DBMS married to geographic objects. It's not just about drawing maps.

The sofware must read and write common GIS file formats. The most common interchange format is the ESRI-sponsored, open format called a shapefile, which really is a collection of several physical files. (Years ago I wrote some software from scratch to read and create .shp files. I don't want to do that again.) In recent years, the Google-sponsored KML file format also has become important, mostly as a platform for publishing maps to end-users. KML is not readily comparable to a GIS format, partly because it lacks tabular data, but it is becoming a popular display format that does define basic geographic coordinates. (I find it useful that my own GIS sofware, Manifold, will import and export simple KML. To create rich and complex KML, I write my own scripts.)

It is important to remember that just having the GIS software is not sufficient. One must also have base map data for the areas in question. Hopefully the user can locate public-domain sources for such data. Commercial map layers are expensive. A good, but not perfect, source of U.S.base map data is the Census TIGER data, which now is being disseminated in shapefile format. Some states and localites publish their own base map data. (Luckily,my own cityis such a place. If yours is not, start pestering your local officials. They probably have this stuff internally.)

The GIS sofware should be able to read and convert a variety of map projections-- the various schemes that geographers have devised for representing a curved planet on a flat surface. It also should be able to read and convert from one datumto another. (A datum is a mathematical model of the Earth, which is not a sphere but an ellipsoid. Unless you know what datum you are using, you don't know precisely where a given latitude-longitude coordinate is on the planet.)

The GIS platform should provide a GUI for displaying, selecting, editing and creating basic geographic objects (points such as addresses, lines such as streets and creeks, and polygon boundaries defining such areas as counties, cities, census tracts, stakes and wards.) Typically, these geographic objects are organized into separate layers. There should be tools to transform sets of intersecting lines into poylygons, and vice versa. Also, there should be the capablity to combine such objects from different map layers into new layers. The interface should provide easy means to divide existing polygon areas with bisecting line objects or polygon subdivisions, and to merge line and polygon objects. In practice, for example, that allows a user to define a stake or ward boundary that combines streets, creeks, political boundaries and custom-created lines.

The program should provide rich options for formatting and displaying maps that are created by such dynamic processing -- both on screen, in print, and in export formats.

The sofware should provide relational tables for storing, querying and transforming text and numeric data (integer, decimal and floating point) associated with such geographic objects. For example, streets and street segments associate street names and address ranges; creeks typically are associated in network hierarchies; points might be associated with addresses and with families or indiviudals; polygon areas might have names and codes for counties, Census tracts, population values, etc. I consider a decently implemented SQL engine to be the best database platform. It should allow import and export of common tabular data formats and sources such as ODBC or OLEDB in Windows. That way, for example, all the MLS export files can be imported and manipulated as SQL tables. Some of those tables, such as addresses, would be associated directly with geographic coordinates.

The basic SQL query language also should be extended include geographic functions. One such basic function is commonly known as a "point in polygon" query -- find all points from a certain map layer that are within a certain polygon. Similar functions should exist to find lines and polygons that contain, touch or overlap each other. In addition to the query language, it is useful to have a scripting language to perform repetitive tasks, and and API is even better.

Taken together, those functions allow the user to perform such tasks as calculating the total number of members, families, priesthood holders with current temple recommends, YM/YW, etc. within a given boundary area or set of boundary areas. In performing such analysis, the user is essentially performing the same task that a legislature does when gerrymandering congressional districts. The typical method is to divide the overall area into small jigsaw pieces and recombine them in different ways to provide different possible outcomes. A legislature does this with voting precincts; stakes do this with "GEO Code" areas of their own choosing. With a GIS system, it is often useful to start with the work of others, such as the Census Bureau, or postal service, who have professionally created areas such as Census tracts and carrier routes that make intuitive sense on the ground. These can then be customized as needed. Of course it is also possible to invent such jigsaw pieces from scratch. It is also nice if the GIS package provides any easy GUI to do all that what-if querying by clicking around a base map. This is much easier than combining pieces in SQL queries.

Some GIS software offers add-on modules for geocoding. This function can be integrated, and might theoretically involve some of the same base map data. But it really is a distinct function, and I consider the choice of geocoding tools to be a separate question.

There are other nice-to-have features, such as calculating driving directions and measuring driving distances. Even if the GIS software has this functionality, it requires sophisticated base-map data that handles such things as one-way streets and freeway ramps. So it is difficult to implement well in a reasonably priced, standalone package. The online providers such as Google and Microsoft have a natural advantage there because of the expensive base maps they license from providers such as Tele Atlas and NAVTEQ.

For further GIS primer stuff, here is aWikipedia link.

I'm leaving out a lot of stuff. In general, a full-featured GIS program has a lot of complex functionality. So I have no qualms about writing a check for such power if I can afford it. (That's why I like Manifold when I am spending my own money.) I should add that the professional GIS market is dominated by ESRII certainly can't afford ESRI's flagship products myself, and its price tag would make a stake president blanch. Another significant commercial player is MapInfo, which my state agency uses for its web site and some desktop mapping. I like the feature set of Manifold better, so it is on my desktop at work.

Thanks for the info! That's a lot to digest.

Wow... Ask and ye shall receive indeed! I think I just blew a synapsis, only in a good way :^) Now to get the creative juices perculating...

HELP! Someone posted a great site to get the instructions for converting a csv membership file so it could be loaded on google earth to map the ward. I did this successfully and sent the instructions to my son who also loaded his ward. I want to give these instructions to someone else and I can't find them! I have looked at every mapping post and cannot find the original post.... Anyone know what I am referring to?

zaneclark wrote:HELP! Someone posted a great site to get the instructions for converting a csv membership file so it could be loaded on google earth to map the ward. I did this successfully and sent the instructions to my son who also loaded his ward. I want to give these instructions to someone else and I can't find them! I have looked at every mapping post and cannot find the original post.... Anyone know what I am referring to?

I suspect you are referring tothis thread. I did not think the method described there was so great because it fails to deal with all the resulting errors, but I recall that you liked it.

boomerbubba wrote:I suspect you are referring tothis thread. I did not think the method described there was so great because it fails to deal with all the resulting errors, but I recall that you liked it.

That's it! Thank you... I know some have reported errors but for me, since I am mostly an end user type and not very tech savvy, it worked fine....

zaneclark wrote:That's it! Thank you... I know some have reported errors but for me, since I am mostly an end user type and not very tech savvy, it worked fine....

Errors do not affect only "tech-savvy" people, but end-users too! Just because someone doesn't understand errors does not mean the errors do not exist.

That is the nature of the problem I described: The process is deficient because it fails to identify known and potential errors for you. There likely will be errors but they will not be readily apparent by just browsing the output. So you actually do not know that "it worked fine" at all, only that the process produced output that looks good and is mostly right. Most families will be mapped okay, but that does not mean there were not significant errors.

Because of the deficiency of the process, the only way you could know about the errors would be to manually inspect the output of each mapped family compared to the ward roster to find 1) families on the roster that were not mapped at all and 2) families that were mapped in the wrong place.