Tech Forum

Seems to be a security level problem.

I'm not sure what the best way to solve it is (maybe someone else will describe it better) but I think this will work:
In Internet Explorer go to Tools->Internet Options->Security->Trusted Sites->Sites button
1) untick Require server verification
2) add file:\\C\ (you can enter more of the path if you want.)

Problem found: possibly fixed by allowing the file in the Trusted Sites area. Probably fixed because of a web filtering problem at the office blocking access to the mapping function.

Good process, although Yahoo Maps has some accuracy errors on a few addresses. Not a problem, though. Used the resultant kmz file and then used colored polygons to make geocode areas. Next step will be to add some custom pointers in different areas.

Thanks...Rick...

redzarf wrote:No, it shouldn't be any harder than posting to a forum and installing Google Earth

Try downloading, unzipping, and running the file I'd attached a few posts above.

Once its opened in your browser theres instructions over on the side, the hardest step is probably going to be getting hold of the data from your clerks/LUWS

I tried it, and it worked as advertised, but. . . .

Of over 260 addresses, all standardized to USPS format (including ZIP+4) using this utility, geocoding was successful on only about 160 of the addresses. I suspect this is due to the 911 addressing issues I mentioned elsewhere.

Also, my ward is so spread out geographically, the resulting map in Google Earth is not very useful. I don't know whether there are display settings I can change to see if it the resulting map can be made more usable.

rickhellewell wrote:Good process, although Yahoo Maps has some accuracy errors on a few addresses.

Which is why I use batchgeocode.com, which uses Yahoo Maps, strictly as a backup. Specifically, if it can't find a street, it often places the point in the middle of the ZIP Code; if the ZIP Code is off (as it sometimes is, since I don't have time to check all of them from what the wards have) it can get confused. If it places the point at least in the right ward, I'll usually take what I can get though.

tomw wrote:I've had discussions today with managers from various departments within the Church...

Tom

There's another site at the following URL where someone calling himself "Mormon Hacker" is giving people directions on how to Google Earth their ward directory. The only problem with his directions is that they include POSTING your ENTIRE WARD DIRECTORY (including names) TO a SITE that's likely NOT even ADMINISTERED BY MEMBERS (batchgeocode.com)!
http://mormonhacker.blogspot.com/2007/0 ... ry-on.html

I wonder if you guys need to have a talk with this fellow.

On another note, I was thinking about writing a script myself to convert a ward-directory CSV from lds.org directly to a KML file for Google Earth, but then I realized that I'd better run a net sniff on Google Earth first, to make sure that it's not "phoning home" to transmit the KML-file information back to Google, which would be another security risk. If it all works out, I'll report back here.

I believe the geocode program just does a Yahoo geocode lookup on the address (street, city, state, zip). I don't think that the other personal data is uploaded. I haven't looked at the process, but a Yahoo geocode lookup is only interested in the street/city/state/zip data. That is not really 'personally identifiable information'.

If you are really worried about the other data, then strip it from the CSV, so that only the street/city/state/zip data is left. Or just replace all that other data in the columns with junk, and then cut/paste the geocode info back after the lookup.

I will check into it. Thanks for pointing it out.

Tom

KOlive43 wrote:There's another site at the following URL where someone calling himself "Mormon Hacker" is giving people directions on how to Google Earth their ward directory. The only problem with his directions is that they include POSTING your ENTIRE WARD DIRECTORY (including names) TO a SITE that's likely NOT even ADMINISTERED BY MEMBERS (batchgeocode.com)!
http://mormonhacker.blogspot.com/2007/0 ... ry-on.html

I wonder if you guys need to have a talk with this fellow.

On another note, I was thinking about writing a script myself to convert a ward-directory CSV from lds.org directly to a KML file for Google Earth, but then I realized that I'd better run a net sniff on Google Earth first, to make sure that it's not "phoning home" to transmit the KML-file information back to Google, which would be another security risk. If it all works out, I'll report back here.

JTaber wrote:Which is why I use batchgeocode.com, which uses Yahoo Maps, strictly as a backup. Specifically, if it can't find a street, it often places the point in the middle of the ZIP Code; if the ZIP Code is off (as it sometimes is, since I don't have time to check all of them from what the wards have) it can get confused. If it places the point at least in the right ward, I'll usually take what I can get though.

That is a property of batchgeocode.com, not of Yahoo. What the batchgeocode.com web page does (client-side) is send repeated calls to the Yahoo geocoding API. Yahoo actually returns two additional data attributes for each address, describing the quality of the geocoding transaction. But the implementer of batchgeocode.com -- which is otherwise nicely done -- chose not to do anything with those attributes. It just accepts the coding to a zip centroid without so much as a warning.

I found this unacceptable. So I wrote my own VBScript that talks to the Yahoo API directly, and retrieves the addresses along with the precision attributes. Then I can deal with the exceptions offline before plotting the map. Most often the root cause of a bad geocoding transaction is poorly formatted input data in MLS. Garbage In, Garbage Out.

My script does do some minimal preprocessing of the input data to scrub some common style errors in addresses. I plan to experiment with preprocssing the addresses further through calls to a Postal Service API, but that may be gilding the lily.

I have found the quality of Yahoo's lat/lon geocoding to be quite good for my urban location. Of about 570 records I submitted for our huge ward, all but about 7 errors were due to bad address data. On these 7 records, Yahoo's geocoding database could not find the correctly formatted addresses, but I was able to geocode them manually on other sites such as Google. So I ended up with 100 percent of the geocodable records successfully geocoded. I am working on a way to store such exceptions locally so the work doesn't have to be repeated for the next update..

BTW, my own solution --a work in progress -- uses .Yahoo's geocoder, but the output is KML for display in Google Earth. ( I also have a precise ward boundary layer that I produced in commercial GIS software, but that's a separate piece. Easily done with the right tools.)

The smarts offered in Google Earth's interface, which runs as a local application, surpass those of a purely web-based viewer.

The next step I see is producing Google Earth hierachies of HT/VT routes for the appropiate leaders to use. Beyond just visualizing, they should be able to do interacive what-if geographic editing of routes inside Google Earth, then export the results. (The only thing missing would be integration with MLS

p.s. I'm new here. Thanks to the work of those implementers upthread, whose ideas I have adapted.

Wow, welcome to the forum! I'm very much interested in test driving your VBS when you get it ready. It sounds like you've found and addressed some of the problems I've run into with other solutions.

Mike

Mikerowaved wrote:Wow, welcome to the forum! I'm very much interested in test driving your VBS when you get it ready. It sounds like you've found and addressed some of the problems I've run into with other solutions.

I posted a status report and general description on another thread. http://tech.lds.org/forum/showpost.php? ... stcount=36 (There are several mapping / geocoding threads on LDS TECH, and I have a hard time keeping them straight.)

Basically I am almost through with development of a VBScript-based solution, and have shared the results with our ward leaders. There are two scripts, one geocodes and the other uses the results -- after review and offline editng of address exceptions --
to produce KML files for general ward membership, home teaching and visiting teaching.

But the complexity is reaching the point that it really ought to be wrapped into a real application if it is to be shared with end-users. This is driven by the inherent requirement to edit exceptions and manage them for ongoing updates. In our huge ward, with many incoming and departing families, that should include weekly updates from MLS.

I am wondering where to go from here.