Changes between Version 21 and Version 22 of BluePrintGISGeolocator
- Timestamp:
- 11/17/10 04:12:34 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
BluePrintGISGeolocator
v21 v22 27 27 == Notes == 28 28 29 There have been a avenues explored for this project that have proven to be deadends. Great pains were taken in order to get the right information out of the geocode() controller's return, which, at the moment, happens to be raw returns from Google. The problem with those efforts is that Yahoo returns a completely different data structure. These obviously have to be standardized.29 There have been a few avenues explored for this project that have proven to be dead ends. Great pains were taken in order to get the right information out of the geocode() controller's return, which, at the moment, happens to be raw returns from Google. The problem with those efforts is that Yahoo returns a completely different data structure. These obviously have to be standardized. 30 30 31 31 It was originally thought that the 3rd party geopy python module would be useful to achieve this standardization, however there are two problems. The geopy module still returns different data structures for both Google and Yahoo. Additionally, for Google it only returns the long form of the address, and the lat/lon values, which are both trivial to parse out of the Google returns anyway (using "address" and "Point" as keys into the returned placemark). Using this module proved to be a bit of a dead end. It may be possible to use this module as a basis, however, with some slight modifications. 32 33 At present, the geocode() controller calls the s3gis GoogleGeocoder get_kml() method, which works only in strings, not with an easily modifiable data structure. It is actually possible to do an eval() on the JSON "page" variable in this method, but obviously that should be avoided in with web returns (or anything, for that matter). 32 34 33 35 == API ==