Using Web Tools to Map the Members

Use this forum to discuss issues that are not found in any of the other clerk and stake technology specialist forums.
russellhltn
Community Administrator
Posts: 25283
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Sat Jun 28, 2008 9:54 pm

To my knowledge, there is nothing in MLS to signify a "no not contact" or otherwise restrict information.

The way I've seen that done is to blank out the fields in MLS itself, such as putting "unlisted" in the phone number field. Those who need to know the phone number is given it outside of MLS. So the only thing I can think of for your script is to realize that some addresses can't be geocoded because they are not addresses but notes.

But the upshot of it is, there is no standardized way to deal with the problem in MLS. I say if you're provided with a geocode-able address, display it. If the information isn't intended for the general ward, then the leadership would have to be "sanitizing" all of the print-outs from MLS. In that case they probably wouldn't allow the result of your program to be posted publicly until they had done the same.

What you might consider doing is keeping a local database of "names to exclude" so they can automatically be excluded from future updates. You might also consider a database of "places to include" such as the location of the chapel, bishop's storehouse and other important locations that are not going to be in the MLS file.

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

Postby RossEvans » Sun Jun 29, 2008 6:33 am

RussellHltn wrote:To my knowledge, there is nothing in MLS to signify a "no not contact" or otherwise restrict information.

The way I've seen that done is to blank out the fields in MLS itself, such as putting "unlisted" in the phone number field. Those who need to know the phone number is given it outside of MLS. So the only thing I can think of for your script is to realize that some addresses can't be geocoded because they are not addresses but notes.

But the upshot of it is, there is no standardized way to deal with the problem in MLS. I say if you're provided with a geocode-able address, display it. If the information isn't intended for the general ward, then the leadership would have to be "sanitizing" all of the print-outs from MLS. In that case they probably wouldn't allow the result of your program to be posted publicly until they had done the same.

What you might consider doing is keeping a local database of "names to exclude" so they can automatically be excluded from future updates. You might also consider a database of "places to include" such as the location of the chapel, bishop's storehouse and other important locations that are not going to be in the MLS file.


You are conflating two distinct conditions: "Unlisted" and "Do Not Contact." Neither is tracked or screened in MLS. Only the former, apparently, is screened in LUWS, and that only seems to relate specifically to a commitment to the sensitive members to keep their addresses from being published online.

Apparently, no one ever promised such members that they would be unlisted in any way in directories or ward lists, but church policy (perhaps for legal reasons?) is to suppress their publication in the web site directory if the members request it.

So I will amend my ReadMe in the first maintenance release to caution that the contents of this KML file should not be published on the web site. (The file cannot be posted as an attachment anyway, AFAIK, because LUWS only allows .doc, .xls and .pdf extensions as attachments.) These restrictions apply not only to my script's output, but to anything else extracted from MLS.

It would be useless and silly to include a ReadMe statement that says, in effect, "Some members listed in this file may not wish to be listed, but we can't tell you who they are." That same condition applies to any MLS report, and there is no such boilerplate disclaimer.

And there is no way I am going to attempt to maintain a local database, outside MLS, that purports to track such members and exclude them.

The whole concept of "Do Not Contact" is a different can of worms entirely, and outside the scope of this application. I emphatically disapprove of kludged methods of trying to write such comments into address, phone fields, etc.. A phone number field is a phone number field, and should not contain an essay. Ditto for addresses and email fields. This goes for "Do Not Contact" or any other notes one is tempted to make.

The annoying problem of lack of note-taking field in MLS is, I believe, deliberate. The church does not want to keep dossiers on members in church computer systems. It would be very convenient for local leaders to have such a comments field, but if the church wants us to have one, MLS should provide one. The same goes for a "Do Not Contact" flag field.

However, that has nothing to do with maps.

danpass
Member
Posts: 425
Joined: Wed Jan 24, 2007 5:38 pm
Location: Oregon City, OR
Contact:

Postby danpass » Sun Jun 29, 2008 2:07 pm

boomerbubba wrote:You are conflating two distinct conditions: "Unlisted" and "Do Not Contact." Neither is tracked or screened in MLS. Only the former, apparently, is screened in LUWS, and that only seems to relate specifically to a commitment to the sensitive members to keep their addresses from being published online.

Apparently, no one ever promised such members that they would be unlisted in any way in directories or ward lists, but church policy (perhaps for legal reasons?) is to suppress their publication in the web site directory if the members request it.

So I will amend my ReadMe in the first maintenance release to caution that the contents of this KML file should not be published on the web site. (The file cannot be posted as an attachment anyway, AFAIK, because LUWS only allows .doc, .xls and .pdf extensions as attachments.) These restrictions apply not only to my script's output, but to anything else extracted from MLS.

It would be useless and silly to include a ReadMe statement that says, in effect, "Some members listed in this file may not wish to be listed, but we can't tell you who they are." That same condition applies to any MLS report, and there is no such boilerplate disclaimer.

And there is no way I am going to attempt to maintain a local database, outside MLS, that purports to track such members and exclude them.

The whole concept of "Do Not Contact" is a different can of worms entirely, and outside the scope of this application. I emphatically disapprove of kludged methods of trying to write such comments into address, phone fields, etc.. A phone number field is a phone number field, and should not contain an essay. Ditto for addresses and email fields. This goes for "Do Not Contact" or any other notes one is tempted to make.

The annoying problem of lack of note-taking field in MLS is, I believe, deliberate. The church does not want to keep dossiers on members in church computer systems. It would be very convenient for local leaders to have such a comments field, but if the church wants us to have one, MLS should provide one. The same goes for a "Do Not Contact" flag field.

However, that has nothing to do with maps.


There are a multitude of reasons why contact information or even names might need to be excluded from some publications and not others. Having had the responsibility of producing Stake Directories for my stake, I've had to deal with these same considerations. Before I perform the final assembly of the directory document, I send a file containing what I have produced from MLS to each ward clerk. Along with this preliminary file, I send a checklist of common errors to check for as well as instructions to remove names that should not be included. I also instruct the clerk to have the Bishop review the file and approve it before sending the revised file back to me.

I think the bottom line has to be that the Bishop, or someone he delegates, needs to consider how the data will be used and who will have access to the data and decide whether any filtering of the data is necessary before the data is released.

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

Postby RossEvans » Sun Jun 29, 2008 3:14 pm

danpass wrote:I think the bottom line has to be that the Bishop, or someone he delegates, needs to consider how the data will be used and who will have access to the data and decide whether any filtering of the data is necessary before the data is released.


I have no problem with this concept, and neither does my bishop. It is the bishop's call, as my ReadMe file makes clear. In my case, the bishop fully supports this project and agrees with the general principle that the Families KML file should be available to anyone in the ward who wants it, since it contains the same name/address/phone/email information that a ward directory produced by MLS would contain, and any ward member can get that.

The ward directory from MLS is not the same as the periodically produced, printed and immediately obsolete tome that a typical stake directory is. Rather, it is a report generated by MLS, a simple roster of the ward members and their basic contact info. By design, it changes constantly, at least weekly, and is generated on demand. I am pretty confident that neither my bishop nor any bishop wants to proof each name in each copy of the directory before it is disseminated to members, either weekly or case-by-case. If the name and address are in MLS, they will be in the ward directory. The KML file is simply a derivative of that ward directory.

User avatar
Mikerowaved
Community Moderators
Posts: 3517
Joined: Sun Dec 23, 2007 12:56 am
Location: Layton, UT

Postby Mikerowaved » Sun Jun 29, 2008 4:01 pm

boomerbubba wrote:...since it contains the same name/address/phone/email information that a ward directory produced by MLS would contain, and any ward member can get that.


That might not be true in all cases. Ward members can request a Ward list from someone with access to the MLS computer, but they can't get these themselves. Whether this is to be given out should really be under the direction of the local Unit leadership. The LUWS on the other hand, IS available for all Unit members to print a roster from at anytime.

I maintain our LUWS and a couple of times a year also print a Ward directory to distribute to the general membership. This directory (and the LUWS) have several exclusions that the Bishop has made known to me of members that do NOT wish to be included in any published Ward list. Technically, Unit lists that are published are supposed to include ONLY those that have given their consent to be on it. (I wish I can remember where I read that.) We fudge that a little by removing those who so request it.

I am not trying to belittle your efforts, or your program. I think it's a great script. I'm just trying to point out that if you use MLS as your source, then it runs the risk of including some individuals that might not wish to be included and somehow we must respect their wishes.

Wouldn't this all be a LOT simpler if MLS included a flag, like LUWS does, to exclude certain members from a simple Ward List? (Hint, hint!)
So we can better help you, please edit your Profile to include your general location.

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

Postby RossEvans » Sun Jun 29, 2008 10:36 pm

Mikerowaved wrote:That might not be true in all cases. Ward members can request a Ward list from someone with access to the MLS computer, but they can't get these themselves. Whether this is to be given out should really be under the direction of the local Unit leadership. The LUWS on the other hand, IS available for all Unit members to print a roster from at anytime.

I maintain our LUWS and a couple of times a year also print a Ward directory to distribute to the general membership. This directory (and the LUWS) have several exclusions that the Bishop has made known to me of members that do NOT wish to be included in any published Ward list. Technically, Unit lists that are published are supposed to include ONLY those that have given their consent to be on it. (I wish I can remember where I read that.) We fudge that a little by removing those who so request it.

I am not trying to belittle your efforts, or your program. I think it's a great script. I'm just trying to point out that if you use MLS as your source, then it runs the risk of including some individuals that might not wish to be included and somehow we must respect their wishes.

Wouldn't this all be a LOT simpler if MLS included a flag, like LUWS does, to exclude certain members from a simple Ward List? (Hint, hint!)


I am coming to the conclusion that I made a flawed design decision in basing the Family KML output only on the MLS extracts.

My intention was to produce a simple output file that could be distributed to all members with no questions asked, but I failed to understand all the unwritten policy nuances and local variations. Perhaps I will write a different module that is driven primarily by the LUWS file to select the set of familiies that populate a KML file. (I think I would have to require it to be a subset of the MLS universe of families, which would still drive the master geocoded table of addresses. So an address that was not in both the LWUS and MLS extracts at the point in time where MakeKML runs would just not appear in the new file.)

With that caveat, the new file could be distributed to all in the ward without concern because it would include no information not in LUWS. I would name the new file <UnitName>WebSiteFamilies.KML. It would be an additional or alternate output. I suspect there are lots of wards that are like mine and would prefer the output as-is. So I would keep <UnitName>Families.KML, too.

I don't know how long it will take me to write and test that new module -- probably not that long, except my day job and real life limit the time I can invest.. If the church releases its own member-mapping application on LUWS very soon, I might not bother.

I did not realize that it was common practice in other wards to enforce manual edits on standard MLS outputs such as ward directories. (I've clerked in two wards a decade apart, using MIS and MLS, and this was a new one on me.) If this is common practice, and bishops do have this requirement, I think it is pure madness that MLS does not support the need with suppression functionality built-in. It is elementary that the design of custom software such as MLS should be driven by the "business rules" of the organizations that use them. Apparently the designers of MLS flubbed that one. But MLS is what it is.

For users of my scripts, my instructions would be this for wards that have a suppression requirement:

1) If and when I get the new module written and released, the easiest thing for you to do will be to discard <UnitName>Families.KML and distribute <UnitName>WebSiteFamilies.KML instead. (Meanwhile, until I get around to creating such a file, this is not an option. What is an easy option is not distributing a general families KML file at all, limiting is distribution to leadership, or choosing not to run these scripts.)

2) If you do want to distribute <UnitName>Families.KML and must edit the content, do not edit the MLS extract files. You risk breaking the scripts if you do. Instead, let the scripts run and load the results into Google Earth, make your edits there, and save the edited KML files for distribution.

If, like Mikerowaved, your ward's practice would be to produce a directory twice a year by manual edits, updating the KML file to match would not be that burdensome. You would just have to make your edits in two places. If, however, you have a lot of turnover like our ward does (we plan weekly updates) the feasibility of this gets shakier. (Heck, if I only cared about biannual updates, I would scrap the Yahoo geocoding and spend 50 bucks a year to get the edited files commercialy geocoded with superior quality and fewer exceptions to deal with.)

A note about internal table-handling of the MakeKML.vbs script: It already aborts at certain places if there are obvious signs that the MLS extract files have been altered, to protect against undefined results. Now that I understand there is a propensity for users to edit the MLS extract files, in future releases I will probably try to lock down the files and queries even more. I can't make the script bulletproof, but I will try to make it idiot-resistant. Meanwhile disregard the instructions above at your own peril.

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

Postby RossEvans » Mon Jun 30, 2008 9:26 am

boomerbubba wrote:Perhaps I will write a different module that is driven primarily by the LUWS file to select the set of familiies that populate a KML file. (I think I would have to require it to be a subset of the MLS universe of families, which would still drive the master geocoded table of addresses. So an address that was not in both the LWUS and MLS extracts at the point in time where MakeKML runs would just not appear in the new file.)


A sad followup: I have looked more closely under the hood of the LUWS extract file, and I am less optimistic that this idea could work reliably because the addresses are fielded differently than they are in the MLS extracts. So comparing addresses between the two would be too flaky.

I already knew that the content of the names fields did not match. So AFAIK there is nothing in the two file formats accessible to me that could be used as a reliable link between them. (Perhaps church developers are not so constrained.)

So my idea of last night -- adding a module to my scripts that would also create a <UnitName>WebSiteFamilies.KML file, driven off LUWS -- was less than fully baked. Given all the well grounded speculation that the church is about to release a member-mapping page on LUWS anyway, I don't see much benefit in my trying. The results would introduce significant errors of omission in my script that would just turn end-users off.

So don't expect such a module from me after all. I could reconfigure my whole system, including the geocoding and exceptions-handling, around the LUWS extract. But that would cripple its utility for ward leaders. There could be no home- and visiting teaching maps produced, and even the bishop could not see where all the members live.

Therefore, it seems the best I could do would be to graft on suppression functionality that properly belongs in MLS, but which MLS fails to provide. That would mean adding yet another table (a .csv file) to be edited by the user of the scripts: a list of church member ID numbers for families to be excluded from output in <UnitName>Families.KML, if the user chooses such exclusion at runtime.
.
I will consider that enhancement in a future release, instead.

Meanwhile, users can edit the output manually if they are obliged to suppress certain families. I repeat my admonishment above: Do not edit the MLS extract files. You risk breaking the scripts if you do. Instead, let the scripts run and load the results into Google Earth, make your edits there, and save the edited KML files for distribution.

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

V 1.1 of GeoDB ward-mapping scripts released here

Postby RossEvans » Fri Jul 04, 2008 6:46 pm

This post releases v 1.1 of my GeoDB ward-mapping scripts, responding to several suggestions discussed in this thread.

Among other enhancements, this version:

Changes default color of families rendered in <UnitName>Families.kml, and <UnitName>HomeTeaching.kml (for families taught by High Priests) from green to yellow. These color settings can be changed back to green by commenting/uncommenting either of two constants at top of script.

Supports suppression of particular families pursuant to ward policies and practices that honor members' requests to be excluded from ward directories for general distribution. There is a separate file maintained to facilitate this functionality. Any head-of-houselhold members who wish to be excluded could have their 15-character church membership numbers listed in this file. Suppression can be overridden at runtime by the user, to produce a general families KML file for limited distribution to ward leaders.

Adds a new flat file to the ouput. This file (GeoDB_FinalGeocodedFamilies.csv) represents the final geocoding for each family, including any substitute lat/lon coordinates from manual geocoding of exceptions. If the user elected to map ungeocodable records to a default location, these records and the default lat/lon will also be included with a flag. So will any families that were suppressed, similarly flagged. The purpose of this flat file is just to provide a flexible file for loading into other applications.

For details, see the attached release notes and expanded ReadMe.txt.

Thanks to those commenters who contributed to these improvements.
Attachments
GeoDB_v1_1.zip
(29.85 KiB) Downloaded 34 times

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

V 1.1 of GeoDB ward-mapping scripts released here

Postby RossEvans » Fri Jul 04, 2008 6:56 pm

This post releases v 1.1 of my GeoDB ward-mapping scripts, responding to several suggestions discussed in this thread.

Among other enhancements, this version:

Changes default color of families rendered in <UnitName>Families.kml, and <UnitName>HomeTeaching.kml (for families taught by High Priests) from green to yellow. These color settings can be changed back to green by commenting/uncommenting either of two constants at top of script.

Supports suppression of particular families pursuant to ward policies and practices that honor members' requests to be excluded from ward directories for general distribution. There is a separate file maintained to facilitate this functionality. Any head-of-houselhold members who wish to be excluded could have their 15-character church membership numbers listed in this file. Suppression can be overridden at runtime by the user, to produce a general families KML file for limited distribution to ward leaders.

Adds a new flat file to the ouput. This file (GeoDB_FinalGeocodedFamilies.csv) represents the final geocoding for each family, including any substitute lat/lon coordinates from manual geocoding of exceptions. If the user elected to map ungeocodable records to a default location, these records and the default lat/lon will also be included with a flag. So will any families that were suppressed, similarly flagged. The purpose of this flat file is just to provide a flexible file for loading into other applications.

For details, see the attached release notes and expanded ReadMe.txt.

Thanks to those commenters who contributed to these improvements.

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

Postby RossEvans » Wed Jul 09, 2008 6:59 am

boomerbubba wrote:This post releases v 1.1 of my GeoDB ward-mapping scripts, responding to several suggestions discussed in this thread.

... . Any head-of-houselhold members who wish to be excluded could have their 15-character church membership numbers listed in this file.


Correction: The church membership number, including embedded hyphens, is 13 characters long.

This correction also needs to be applied to the ReadMe.txt and ReleaseNotes.txt files, and will be in any subsequent release.


Return to “General Clerk Discussions”

Who is online

Users browsing this forum: No registered users and 2 guests