groundwired / apex-geocoding-service Goto Github PK

All the services throw exceptions when they fail, except GeocoderUs which returns an error string. We need to settle on a consistent strategy, and then the scheduled service and the page need to use them appropriately and log failures.

Cicero can provide data for public officials based on address or district. The Cicero class already includes API support for this, but there is no code to actually take advantage of it.

Steve also has code from Sam / IAVA, not yet in this project, that uses web services to get officials, data about current legislation, and voting records.

After we solve the geocoding problem, we should provide the option to create contact and account records for public officials, and connect every contact to their official based on the district data we have filled in. Legislator records could then "roll up" the number of constituents in the database who correspond to each official.

The page now uses only Cicero, and doesn't provide many options (and they don't all do what they say yet). Instead, it should use the generic service and should provide an interface to the different options the service provides. In other words, there should be checkboxes for each of the types of data it can get.

When you request the service, you only get a successful service record if all the data types you request are provided. For this reason, I think the page needs to be a little smart - it should first look a service that provides everything requested, then look for one that simply geocodes, and look for a secondary service to get the other data needed.

Another possibility would be to look ahead of time at ALL the data types provided by available active services, and disable the checkboxes for those that are not actually available.

The page does not actually update records after it gets the geodata back. I think it should provide the option to do so, and if the option is selected it should fill any custom field on the target object that has the same name as the custom field on the geo_data__c object. This way you can add only the fields you like.

If the page can't update all the records you have selected (for example, if you have selected more than 10 or than the service allows), it should mark them for future scheduled updates.

We need an interface to set up and monitor the scheduled updating of geo data. It should allow you to specify which records should get added to the queue whenever they get address changes.

Triggers are needed to queue records (contact and account?) as needing geocoding whenever their address changes. Geocode fields (esp Lat and Long) should get cleared out when address changes. (NOTE: both contact and account have two sets of address fields - not sure how to manage this.)

Less important but also helpful would be a VF wizard for configuring services in the first place. Although we have engineered it to be somewhat service-agnostic, there really are just a few configurations that make sense (Cicero only, or Yahoo/Google/GeocoderUS + optionally MobileCommons + optionally Cicero for some additional data). But some of these options require getting an account with the service, and we should help explain, provide links, and validate that everything is set up right.