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.
Post Reply
tortdog
Member
Posts: 165
Joined: Mon Jul 28, 2008 8:00 am
Location: Austin, Texas

#81

Post by tortdog »

boomerbubba wrote:To some that might raise policy issues having nothing to do with maps or KML files, but rather the third-party server question you were posting on in this thread http://tech.lds.org/forum/showpost.php? ... stcount=59

Here I presume the content of your KML file is name-address-phone. Right? Also HT assignments? Who has password access to the files?
The content is merely the household name, address and phone. Sometimes the phone is left off. That part isn't consistent.

The file isn't password protected. Not even sure if that's possible with a KML. The e-mail account that it sits on is password protected.
By GDrive, are you referring to the Firefox PlugIn that uses Google's GMail as a generalized, virtual file system? Do they and their storage partner have a privacy policy that covers this?
Do they have a privacy policy?

GDrive is a tool used to point a person to data stored on a Gmail account. The privacy policy would be at Google's end - not the GDrive extension. Unless the Church prohibits the use of Gmail accounts for Church-related e-mail, then I'm not sure of how it could be a violation of Church policy.
I am not passing judgment on those policy interpretations, just trying to elicit the facts.

No worries at all. I completely understand and getting more information is why I'm here.
FWIW, with our bishop's approval I distribute weekly updates of our HT/VT files , as well as a general ward membership map, in KML format to a leadership list of bishopric, PEC members, clerks and RS leaders. The content of our general ward-membership KML files -- essentially the MLS ward directory plotted on a map -- is intended to be suitable for distribution to anyone in the ward who asks for a copy, but we have not yet put that distribution into effect. The only distribuiton medium we have considered would be some kind of email list. Mostly we have not gotten around to deciding that, but I don't expect it to be controversial.
Distributing the KML via e-mail is the equivalent (well, a little worse) of storing the KML on ONE Gmail account online. As opposed to a "distribution," we merely keep ONE KML file in ONE place - the Gmail account.

We only use the KML to setup the districts and such. It's not used on a daily basis. The district map is more relevant. Since we know where our members live (or we can easily find out by Googling them from lds.org), it shows up on Google maps which then as the district map layered on top. You Google the address and with the ward map up, you can see which district that house is in.

Easy. No fancy Google Earth that a lot of people find intimidating. They also don't mess with the KML file on a regular basis.

Another way that we have used Google maps is to set up Scouting activities with other stake units. When a bi-council triathlon took place, we mapped the triathlon out on Google maps and the other scouting leaders "collaborated" in setting the route up. The individual units could then participate by "seeing" what they were in store for.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#82

Post by RossEvans »

tortdog wrote:The content is merely the household name, address and phone. Sometimes the phone is left off. That part isn't consistent.

The file isn't password protected. Not even sure if that's possible with a KML. The e-mail account that it sits on is password protected. ...

Do they have a privacy policy?

GDrive is a tool used to point a person to data stored on a Gmail account. The privacy policy would be at Google's end - not the GDrive extension. Unless the Church prohibits the use of Gmail accounts for Church-related e-mail, then I'm not sure of how it could be a violation of Church policy.

Distributing the KML via e-mail is the equivalent (well, a little worse) of storing the KML on ONE Gmail account online. As opposed to a "distribution," we merely keep ONE KML file in ONE place - the Gmail account.

We only use the KML to setup the districts and such. It's not used on a daily basis. The district map is more relevant. Since we know where our members live (or we can easily find out by Googling them from lds.org), it shows up on Google maps which then as the district map layered on top. You Google the address and with the ward map up, you can see which district that house is in.

Easy. No fancy Google Earth that a lot of people find intimidating. They also don't mess with the KML file on a regular basis.

I don't see any problem with using GMail as email. It is a reputable email provider like many others, any has a good privacy policy. But on the use of GMail as a shared virtual file server, I do see one significant difference: Password administration. You have a set of persons in leadership callings who know the common password, When they leave the ward or a released from these callings, whose responsibility is it to change the password and communicate it to everyone else?

The Google Maps web site is a different case entirely.

I gather that the districts map -- essentially a subdivided ward-boundary map -- is not stored in this manner but in the My Maps section of the Google Maps web site. And the individual name-address records are not stored there. Right?

Google's privacy setup governing the My Maps feature on that web site are different from email. When you store a map on My Maps, you are creating a web page with a public URL. Even if you set that map to be "unlisted," in Googlespeak, the URL is protected only by its obscurity. And Google itself still has internal access to your map as a map. FYI, here is what Google saysabout that:

Public and Unlisted Maps

You can choose to make your maps public or unlisted.

Public maps are maps that you want to publish and share with everyone. Public maps will be included in the search results on Google Maps and Earth. Public maps also appear in your user profile (if you have created one).

Unlisted maps are maps that you only want to share with a few select people. Unlisted maps will not be included in the search results, so they are accessible much like an unlisted phone number -- anyone who knows the specific URL of the map can view it, but there's no directory or search for finding unlisted maps.

You can change this setting at any time. However, please remember that all maps have a public URL. In general, we recommend that you don't create any maps that you prefer not to share with anyone.

In our ward we have wrestled with the policy implications of using this Google Maps feature to map fast-offering districts. After researching this issue and seeking the best guidance we could get about Church policy, we decided not to upload names to Google Maps; we might decide to upload addresses only, or use another solution entirely.

We have not confronted the policy issue of disseminating our ward boundary map in this medium. To be safe we consider boundary maps at least quasi-confidential, for ward-member use only. We do have a precise ward boundary map as a KML file, and draft files subdividing the ward into fast-offering districts. But we disseminate them only as files like any other church-use-only file, and display them in Google Earth. Because that application's architecture keeps all the user's data on the user's PC, there are no problems with the "no third-party server" guideline.
tortdog
Member
Posts: 165
Joined: Mon Jul 28, 2008 8:00 am
Location: Austin, Texas

#83

Post by tortdog »

boomerbubba wrote:I gather that the districts map -- essentially a subdivided ward-boundary map -- is not stored in this manner but in the My Maps section of the Google Maps web site. And the individual name-address records are not stored there. Right?
Correct. Basically, it's just a map of districts with no household information. Just pretty polygons of different shades. But when you Google an address, even if you weren't familiar with the member's location and districts it will pop up and you can see where it would be on the district map.

It would be VERY nice if we could have an LDS.org hosted alternative to using GDrive as a file server - but . . .

One day maybe that will happen.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

Making printed maps for full-time missionaries

#84

Post by RossEvans »

Following up on the subject of making printed maps...

We discovered a new tool geared to the needs of the full-time missionaries serving in our ward. They can't really benefit from Google Earth or the other electronic media we use, because they live in an alternate universe with practically no access to computers. Only printed maps will do the missionaries much good. So I made them printed maps of the ward membership and boundaries.

Since missionaries are always keenly interested in who is active and who is not, we color-coded a rough indicator: Any households with someone serving as a home or visiting teacher, or in any calling, is coded in red; all other households are labeled in blue. That's about the best I could do automatically, because of course MLS has no status field for "active." Everyone understands that a few outliers will be miscoded for a variety of reasons. The legend on the map does not say "active," lest anyone see it and be offended.

I created the map with DeLorme Street Atlas USA 2009 Plus, leveraging the geocoding of the ward already being performed to feed our Google Earth KML dissemination. I made the missionaries a 36" X 48" wall map for their quarters, and a rescaled, paginated version on hole-punched letter paper they can put in their area book or carry around with them. I expect to update these maps on a roughly quarterly schedule.

The missionaries were suitably effusive when I surprised them with these maps this evening.
russellhltn
Community Administrator
Posts: 34417
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

#85

Post by russellhltn »

boomerbubba wrote:I made the missionaries a 36" X 48" wall map for their quarters
How did you do that? With the toys you have at work, is it a set of 8x10s, or did you go to a copy shop?
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#86

Post by RossEvans »

RussellHltn wrote:How did you do that? With the toys you have at work, is it a set of 8x10s, or did you go to a copy shop?

We do have a large-format printer at work, used mostly for GIS maps, but I won't use it for personal or Church business. (In a different employment setting I might just ask the top manager for permission. The marginal cost of the consumables to print the 36" X 48" map is only about $2.)

So I looked at professional alternatives and got sticker shock, FedEx-Kinkos quoted $93 for the job, and an AlphaGraphics franchise quoted $75. I was about to punt, but on a word-of-mouth referral found a local architectural priinting shop that did the job for $30 ($2.50/ sq ft). I uploaded a PDF file, formatted for the final dimensions, to their FTP server and placed my order. They printed the map on rolled 20# white bond in a couple of hours. It looks great.

The fallback alternative would have been just to print the paginated map at a somewhat smaller scale on the color Laserjet in the clerk's office. (The DeLorme software will print a single map paginated into 9 letter-sized pieces that can be manually trimmed and taped together for a poster-sized map.) That is the format I printed redundantly for the missionaries' area book. Also, I think Adobe Acrobat will paginate a large file into 16 pieces.

p.s. Another alternative, a little more expensive, would be to try this online photo-poster printer, which quotes $3.33/ sq ft plus shipping for a print on glossy photo paper.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

Geocoding Scripts Withdrawn From Publication

#87

Post by RossEvans »

It has come to my attention that my script's use of the free Yahoo API to geocode members' addresses may violate Yahoo's terms of service for the API, because a second script applies those geocoded coordinates to create files for the Google Earth application.

This was my own mistake, which I discovered on my own today. I had simply missed this provision in the Yahoo document when I first read it, and discovered that error today when I read it again.

Consequently, I am ceasing to use the scripts that way, and am withdrawing them from publication here and the original release here. I just deleted the attachments of the zipped scripts that had been uploaded to this site in those two posts.

I apologize to those who may have downloaded the scripts in good faith. Needless to say, I feel very badly about this mistake. Further explanations are for another time.

I may subsequently create a new process built around some other geocoder, but that is uncertain.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

Is there demand for v 2.0 of these geocoding/mapping scripts?

#88

Post by RossEvans »

I do plan to redo my geocoding and mapping scripts, most likely using a commercial vendor for the geocoding phase -- as before with a local process for clerks to resolve errors and ambiguities. I still would employ KML files for Google Earth as the primary publication medium.

There are just too many restrictions around the free geocoding alternatives. You can do geocoding for free or practically no cost; you can do geocoding pretty accurately and completely; but you really can't do both. And in any case you can't do accurate geocoding without some manual effort.

Although I think this is doable and affordable, and I am confident I can get it done for my own ward, the new architecture might have limited use to other units unless they, too, elected to pay the same vendor I use. I am leaning toward this vendor, Tele Atlas, which is one of the larger industry players and which offers a pricing model and interface suitable for small customers.

Compared to my previous scripts, I would have to revise the flow of the processing to make prudent use of the service, maintaining a local table of addresses that have been successfully geocoded so the user doesn't pay for the same records multiple times. This architecture also would change the precedence of the exceptions file: If clerks have manually geocoded an address for any reason, those coordinates would override any attempt to geocode the address automatically. Using this service would make address correction and standardization upstream in MLS even more critical.

So I am wondering if others have any interest in using such a process. Bear in mind that the Church is probably going to release its own geocoding solution sometime, maybe this year.

If there is not much interest in a shared process, I would worry less about portability and polishing what passes for a user interface, and just handle my own ward's needs more directly.

So this is my own crude market research before undertaking this task. What do others think?
russellhltn
Community Administrator
Posts: 34417
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

#89

Post by russellhltn »

What was the limitation on Yahoo mapping that prevents you from using that?
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#90

Post by RossEvans »

RussellHltn wrote:What was the limitation on Yahoo mapping that prevents you from using that?

The Terms of Use for the Yahoo APIsay:

f. YOU SHALL NOT: ...

(ix) use the stand-alone geocoder for any use other than displaying Yahoo! Maps or displaying points on Yahoo! Maps;

.. (xi) use the Yahoo! Maps APIs in a product or service that competes with products or services offered by Yahoo!.

Beats me how I was so dumb to miss that before. I know I started with the perhaps-naive assumption that since batchgeocode.com -- a pretty high-visibility, third-party site that surely is not unknown to Yahoo -- uses the Yahoo API to do or facilitate both those things with impunity, it must be okay.

[Addendum: In hindsight, I suspect that I read the Terms of Service for Yahoo Maps, but failed to read the other document quoted above, which pertains specifically to the Yahoo Maps API.]

I think that in practice the rigid TOS terms of Yahoo, Google, MS and the like are not being enforced very aggressively, because these mass-market online companies are basically in evangelizing mode trying to grow their user bases. But they are constrained by licensing arrangements with their own suppliers -- companies such as Tele Atlas and NAVTEQ -- who are protecting their own intellectual property. The online services at least have to be able to point to the language of their user TOS agreements as proof of good faith, and the suppliers may be protecting the territories of some key customers of their own.

Meanwhile, there is a fair amount of "don't ask, don't tell" ethos in the community of some end users, some of whom never read the TOS documents. In an application for users in the Church, I think we have to be more conservative, even if we don't expect to be busted by the online companies. See my dialog with mfarley in this thread.

As an added aggravation, I am not sure that the vendors such as Tele Atlas really want to bother doing business with individuals or small non-profits. So there may be a Catch 22 that if folks like me want to play by the rules and pay the vendors their market rates, we can't. I have an inquiry in to Tele Atlas now about their own licensing terms. I know that another high-end vendor would not let me register on their eCommerce site without a "corporate" email address. That site is primarily a vehicle to capture entry-level business customers who later might be migrated to a $100K product.

That's how it is in the high-tech, service-based economy, where everyone is selling air to each other.
Post Reply

Return to “General Clerk Discussions”