LDS Maps Regions

LDS maps plots the members, but no option to create regions for HT districts. We have used Google Map Maker to create regions for our HT districts. Anyway to link those two?

tortdog wrote:LDS maps plots the members, but no option to create regions for HT districts. We have used Google Map Maker to create regions for our HT districts. Anyway to link those two?

Are you talking about plotting member information from LDS maps to a map made in Google Map Maker? This would expose that information to the public.

I'm thinking more about being able to layer the Google Map image containing the polygon HT districts on top of what LDS Maps has. But maybe that would not offer much. You'd want to be able to know which members are in each polygon.

The method I used for something similar was to use Google Earth and create the polygons there and then import the kml file with member locations. I could then save the result as a kmz file. While this was for our nine ward missionary districts (that's another topic in itself), but I am certain HT districts could be done the same.

It has been over eight months since I did this. I mention this because the method was tedious. First the membership data was exported from MLS. That data was imported into a spreadsheet. Two copies were made, one with all the data and one with only the address data. I used the site BatchGeoCode.com to geocode the addresses into a kml file. The kml file was opened in Google Earth. Then using the spreadsheet with the complete membership data I added the family information to each location on Google Earth.

I would have loved to been able to just take the spreadsheet with the complete data and convert it on BatchGeoCode.com but then the privacy data would be exposed to public capture and I didn't know if the data was stored on the website servers. Needless to say I only did this twice. BatchGeoCode.com is now BatchGeo.com.

I think that it would be nice if a polygons (.kml file format) like that created in Google Earth could be imported into lds maps would be great.

jdlessley wrote:The method I used for something similar was to use Google Earth and create the polygons there and then import the kml file with member locations. I could then save the result as a kmz file. While this was for our nine ward missionary districts (that's another topic in itself), but I am certain HT districts could be done the same.

It has been over eight months since I did this. I mention this because the method was tedious. First the membership data was exported from MLS. That data was imported into a spreadsheet. Two copies were made, one with all the data and one with only the address data. I used the site BatchGeoCode.com to geocode the addresses into a kml file. The kml file was opened in Google Earth. Then using the spreadsheet with the complete membership data I added the family information to each location on Google Earth.

There is less reason to use something like BatchGeoCode.com (now BatchGeo.com) for the member addresses now that the Church has built the member-mapping tool. The biggest downside of the Church tool is that it requires each address location to be "verified" manually, which is a big barrier indeed. But that tool is what it is, and perhaps units need to call assistant clerks to build and maintain this asset. Once the accurate lat/lon data is captured and exported, converting the file to KML is quite doable. Since the data can be exported as CSV, I see no reason it could not also be exported as KML from the server. The recent decision to remove the confidential MRN data does make this export less useful to local leaders.

jdlessley wrote: I think that it would be nice if a polygons (.kml file format) like that created in Google Earth could be imported into lds maps would be great.

I think what would really be useful would be something even more generalized, and optionally integrated with the MLS "Stake Geo Code" and "Ward Geo Code" fields, so that they could be made to correspond to imported polygons automatically. The point-in-polygon query that tortdog seeks then also could be done automatically, and stake MLS (or "MLS online") could be used for boundary work. This is elementary GIS functionality, which Google Earth and Google Maps lack. The imported file fomats should include not only KMZ/KML, but also allow shapefiles so that a rich resource of public-domain polygons would be available to units.

We do this now at the ward level for automating fast-offering districts, using external GIS software. Once the address geocoding is accomplished by some reliable means (using the manual Church-supplied tool or some other method) with GIS software it is quite easy to group and code the families into flexible polygons that could represent anything -- Stake Geo Codes for boundary work, local emergency districts, fast-offering districts, home teaching districts, etc. But even if that step is automated externally, someone needs to key all those codes into MLS. Building some online GIS functionality seems more doable.

There have been member-created efforts, as well. You could check out http://wardmap.hpaulsen.com as one solution. It reads the Membership.csv file from MLS (at least, the prior version with the membership record number - I haven't tried it with the new export format), and you can draw your home teaching districts or import them from a kml file (if they are polygons) and quickly see which members are in which regions.

The program has been in need of updating for quite a while (the FCC information is completely dead), but should still be functional. I keep hoping the church will come up with a solution....

I would also like to import kmz/kml files from google earth to lds maps. I use polygons (paths) for HT district boundaries. I would also like to import my High Priests and Elders kmz/kml files to match Home Teachers to families. We also use google earth to plot zone boundaries around members for calling trees during Hurricanes as part of our emergency plan since were a coastal stake in florida. Google Earth can be very tedious and time consuming when 85% of the work is already done in LDS Maps.

tommccombs wrote:I would also like to import kmz/kml files from google earth to lds maps. I use polygons (paths) for HT district boundaries. I would also like to import my High Priests and Elders kmz/kml files to match Home Teachers to families. We also use google earth to plot zone boundaries around members for calling trees during Hurricanes as part of our emergency plan since were a coastal stake in florida. Google Earth can be very tedious and time consuming when 85% of the work is already done in LDS Maps.

Since you are doing that much geographic work, you might want to invest the effort and resources into a real GIS program, which neither Google Earth nor the Church mapping application are. That does not mean you can't also visualize the results in Google Earth.

So far, the main vailue added by the Church app, once you get past the novelty of seeing all the members plotted, is that it provides a place to capture geocoded addresses by member as a central asset -- roughly by automation, and accurately by manual effort by clerks. You then can export that data to an external file to do your own manipulation in better software, linking the data to your MLS records by address. (It used to be possbile to link more reliably by Member Record Number, but that capablility has been lost.)

Sounds like you have applications to justify some resources -- time and maybe money. I have been using desktop GIS for years in our ward, where we also have several custom geographic tasks. I did happen to own low-cost commercial software already, but the free offerings are getting better. If you have zero budget, try something like PostGIS. I actually don't use that myself, since I have a commercial tool, Manifold, that I am reasonably happy with. The real cost is time and effort to learn these complex tools.

Someday, hopefully the Church app will grow into something more powerful. Frankly, I doubt that the Church will ever be able to meet all our varied local requirements, but it would be nice if it tries to meet some common needs such as boundary analysis. The same basic capability can be extended to other tasks that also are based on geographic zones.