I am happily using gmaps tools in production to match content (music venues and their related events) with a user's (registered or anonymous) location. Currently, I use the generated geonames taxonomy with depth to limit nodes by returning the user's postal code as the argument and displaying nodes -3 levels deep (up) in the vocabulary (which corresponds to neighborhood, town, and county in my configuration).
I would like to be able to:
- display nodes within a proximity (bounds or radius) of the user's specified location.
I am able to set the reference location from a block or user profile and display the distance for all the nodes that match the taxonomy argument in my view, but I have not been able to filter or create an argument based on that distance.
The argument handler seems to require a node id as the argument. I'd prefer:
- the option to use reference location as the argument rather than a nid. Or better yet:
- implement as a filter so that it could optionally be exposed to the user to enter their preferred proximity.
Are these features you have considered? I believe they would be relevant to many sites and I'm happy to elaborate further and provide views exports or example links if that helps.
Unfortunately, my php skills are not strong enough to offer a reasonable patch for this, but I'm happy to provide further documentation and integration guidance as much as I can. This is a great module which attempts to address a wide variety of geo-location issues by utilizing open APIs.

Comments

xmarket’s picture

xmarket commented
Status: Active » Fixed

You should use the exposed location filter, not the reference location filter.

dchampine’s picture

dchampine commented

Thanks! I did get further along, but I have some feedback on the implementation of the location filter which may help others and/or lead to modification.
The collapsed fieldset at the bottom of the filter configuration screen labeled "Radius Operator Options" allows the administrator to change which radius settings show up in the exposed (or not) filter Operator above it. This is not intuitive since it appears after the configuration of the Operator itself. On it's own that's not a big deal, but the Operator itself is currently overloaded by combining address/bounds with radius in the same filter. It would be less confusing and more useful to have separate filters for radius and address/bounds. This way, if a location point was already known and the view is for proximity, you could expose just the Radius Operator to the user and let them choose from the different distances the administrator has configured. This would be much cleaner UX. Having a separate Address/Bounds Operator would also be handy in other circumstances where the view is used for matching an address part (town, postal code, etc.).
I still have other notions on using the reference location - or better yet ip_address() as a filter but I'll spend some more time with the module and address in another post.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.