I'm finding that the array of distances (5, 10, 25, 50, 100, 250) set by the form_select in the location_proximity_form() function aren't quite appropriate for my project. How about setting these with one of the $prefilled_values, say an array in $prefilled_values['distance_vals']?
Also it'd be nice to have one of the select options return ALL items sorted by proximity. So my dropdown might contain: "50, 100, 200, 500, 1000, ALL". Now that I think about this, I could just format my array to:
$prefilled_values['distance_vals'] = array('50'=>50, '100'=>100, '200'=>200, '500'=>500, '1000'=>1000, 'ALL'=>12450);
12450 is half of the circumference of the earth (24900mi - thanks Google!). That should cover everyone, right? And incidentally, the key values are quoted so that 'ALL' comes after '1000' and doesn't get a numerical index value of 0, putting it at the top of the menu. Don't know if that matters or not, but I thought I'd be safe.
Anyway, how 'bout 'distance_vals'?
-Jeff
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | location-granularity.patch | 0 bytes | jjeff |
Comments
Comment #1
jjeff commentedOkay... Here's a patch to location.inc
The information gets into the form correctly, BUT when I submit a search over 250 miles, I get this type of error:
Fatal error: Got a packet bigger than 'max_allowed_packet' query: UPDATE cache SET data = 'a:21411:{s:7:\"us02771\";a:3:{s:4:\"city\";s:7:\"Seekonk\";s:8:\"province\";s:2:\"MA\";s:8:\"distance\";N;}s:7:\"us02916\";a:3:{s:4:\"city\";s:7:\"Rumford\";s:8:\"province\";s:2:\"RI\";s:8:\"distance\";s:14:\"2524.014991185\";}s:7:\"us02862\";a:3:{s:4:\"city\";s:9:\"Pawtucket\";s:8:\"province\";s:2:\"RI\";s:8:\"distance\";s:15:\"4267.4861899443\";}s:7:\"us02861\";a:3:{s:4:\"city\";s:9:\"Pawtucket\";s:8:\"province\";s:2:\"RI\";s:8:\"distance\";s:15:\"5020.5121508099\";}s:7:\"us02914\";a:3:{s:4:\"city\";s:15:\"East Providence\";s:8:\"province\";s:2:\"RI\";s:8:\"distance\";s:15:\"5074.2131277786\";}s:7 in /Users/jeff/Sites/drupal/includes/database.mysql.inc on line 66
Maybe there is a reason that searches over 250 miles aren't allowed? That would be a bummer.
-Jeff
Comment #2
ankur commentedYes, there will be architectural changes in the project for the 2nd release that will allow you to use a search-radius of unlimited lenghth, but right now we limit the search radius to 250 miles to avoid the max packet error.
This is really a result of the direction of the original project which was a us-centric zipcodes module where everything was dependent on zipcodes. Still, searches for nodes by location are dependent on lists of zipcodes being determined first and then using that list to query for nodes. For a large search radius, that list can be very big and cause problems with PHP complaining about max_packet_size and such.
The idea being considered for the next release is to attach lat/lon data to the location_node table itself when a node is being saved. That way, instead of querying the "zipcodes" table for that long list of zipcodes (which we cache, which is what is causing the error) and then using that list to query for the nodes, the new plan will be to directly query location_node since each node will have it's lat/lon. That way, we don't have to depend on a list of zipcodes. It also makes it possible to make a node geographically searchable even if it doesn't have a postal code, because we can now use other sources of data to assign a lat/lon to a location_node row where there is no postal code (assuming we have a city and data to map a city-name/province/country triple to a lat/lon pair.
So, for now, wait till the 2nd release while we fine tune the first one.
-Ankur
Comment #3
catchBumping to 2.7 so this can be closed if/when no longer valid.
Comment #4
bdragon commentedNow that location_search is rewritten, this should be fixed.
Of course, the real solution for "long distance" work will have to wait for geo.module integration.
Comment #5
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.