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.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.
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.
