Tech Forum

boomerbubba wrote:I am interested in your workaround to store coordinates in the existing MLS fields. Did you consider using the legacy "Geo code" fields in tandem to store the two coordinates (Stake field = lat, Ward field = lon) or are they already occupied? The notion of keying all that into MLS seems too labor intensive to me anyway. Our solution is to maintain our geocoded tables outside MLS automatically, and manage the exceptions during weekly updates.

Originally we stored the data outside of MLS and this worked fine for the person updating the information. However no other members had access to the information unless the updating person copied the information to the MLS computer. Even if others had access to the data they would have to create joins to relate the MLS list and the XY data together, which was asking too much of most clerks/members. The data would quickly become out of date since our ward seems to turn over quite a few members throughout the year and multiple clerks would be updating the address information.

We tried storing the information in a custom field. This proved to be cumbersome, as the user has to enter the data in a separate form from where most of the membership information is stored. Also the only way for members to gain access to this data is the run a custom report or manually look up the data.
We then tried using the Geocodes, ie the Ward and Stake to store X and Y respectively. This was also cumbersome to input into MLS, even though we could open the form from the membership's record we had to pull up each geocode separately and the amount of characters is limited. If memory serves me correctly only eight characters can be stored, this would equate to -128.345 which is not enough accuracy to reliably locate the location to the house. Additionally, the only way for members to gain access to the data was by exporting the data from MLS and this also reveals information that most of the members do not need access to.

By storing the data in the second address field, separating the X and Y with a coma enables members easy access to the data via the ward website. It is easy to update since the user does not have to content with forms popping up, and if the member's address changes the clerk can easily delete the XY data and/or put in the correct information. (With the other two methods, we would sometimes have old XY data left in the record when an address changed. It is still possible to do this but easier to to remember to change because it is right in front of you.) The only problem is when the bishop or other leaders print off labels for ward members, though I would think the post office could still deliver the mail with the extra information attached to the address.

CuriousGIS wrote:Originally we stored the data outside of MLS and this worked fine for the person updating the information. However no other members had access to the information unless the updating person copied the information to the MLS computer. Even if others had access to the data they would have to create joins to relate the MLS list and the XY data together, which was asking too much of most clerks/members. The data would quickly become out of date since our ward seems to turn over quite a few members throughout the year and multiple clerks would be updating the address information.

Hmm. We have a huge ward with a lot of turnover, and update every week. Our scriptsproduce geocoded KML and .csv files covering everyone in the ward with a valid address, scrubbed by the clerks with errors resolved, The full ward map plus KML files for home- and visiting-teaching are emailed to an expanding list of about 20 ward leaders. Soon we will probably institute an email distribution of the general ward map to anyone who signs up. (If the restrictions on LUWS were ever loosened to allow .kmz attachments, we could just do that. Of course, we could store the .csv file as an .xls attachment. today, but that would only benefit techies who could deal with the coordinates themselves. KML is a one-click operaton for an end user to display it in Google Earth. Even the High Priests can do it.)

I just finished our routine weekly update of the geocdoing update, KML production and distribution. It took about 30 minutes start to finish.

CuriousGIS wrote:
By storing the data in the second address field, separating the X and Y with a coma enables members easy access to the data via the ward website. It is easy to update since the user does not have to content with forms popping up, and if the member's address changes the clerk can easily delete the XY data and/or put in the correct information. (With the other two methods, we would sometimes have old XY data left in the record when an address changed. It is still possible to do this but easier to to remember to change because it is right in front of you.) The only problem is when the bishop or other leaders print off labels for ward members, though I would think the post office could still deliver the mail with the extra information attached to the address.

While I see the appeal of getting this into the LUWS files for those techies who can parse the data, this would not be my choice. I am a bit fanatical about not using address fields for anything but addresses.

I'm posting this here because I thought people following this thread would find this video as fascinating as I did. Moderators feel free to move it elsewhere, since it's not directly related to the thread topic.

Get inside the planes that capture Microsoft Virtual Earth

In the quote below by Joel, he states "In the near future we'll also plot ward membership information". This is something that local ward leadership is really anxious for! Folks love the current maps.lds.org, but most of them don't need to check where their chapel is weekly - or monthly - or yearly. I think the real benefit will be when members can pull up a ward map showing where everyone lives. Hopefully the "near future" is soon!

Joel Dehlin wrote: This was inspired, in part, by Kevandcan's great work. We've created a mapping service which takes the lat/long data for meetinghouses and plots it on Google's or Microsoft's mapping service. In the near future we'll also plot ward membership information.

Lots of good stuff. Stay tuned and get ready to throw in and help. We'll be kicking off an open source projet in the coming months...

I've recently received quite a few emails from people complaining that the VBS file I wrote to generate Yahoo! WardMaps no longer works. I finally had some time to look into this and have updated the code to work with Yahoo!'s latest API.

You can download the new file at the following site: http://wardmap.theballfamily.org

I am a little dense and don't quite understand how to change the script for Vista. I have used the MLS2Google maps, but was looking for an alternative. Thanks

To be honest, I'm not sure, since I don't have Vista, I can't test it. All it is doing is writting an HTML file with the appropriate javascript. If you visit the Windows Scripting link on the URL referenced on my site, there is likely some documentation about writing WSH on Vista. Others in this forum may have Vista and have modified the script to make it work. I've even seen folks who rewrote the script in Perl really quickly too...

kevandcan wrote:All it is doing is writting an HTML file with the appropriate javascript.

The question is where is it writing it to? Vista get unhappy with things being written to C:\Program Files.

If the script can be modified to write to %TEMP%, %APPDATA%, or somewhere under %ALLUSERSPROFILE% then you should be good.

RussellHltn wrote:The question is where is it writing it to? Vista get unhappy with things being written to C:\Program Files.

If the script can be modified to write to %TEMP%, %APPDATA%, or somewhere under %ALLUSERSPROFILE% then you should be good.

The script writes to C:\ (your root). Easy enough to change - just open the script and point to somewhere else.

kevandcan wrote:The script writes to C:\ (your root).

It may not like that either. I know for XP you need to be the local admin to have the full rights to that.

I think the suggested locations are Win2000 and XP compatible and do not require admin privileges to use.