Roadmap for next gen location (7.x-5.x)

Subscribing.

@NathanM & other interested users
There is a subscribe button that should notify you of additional posts. It is the big green button to the left of the issue overview at the top.

@rooby
I will try to get a working prototype of the possible implementation notes that I wrote in the previous thread for review tomorrow. Feel free to either go with this, use parts of it, or to ignore it all together!

I have a bit of free time and would love to push this forwards, but in case other users do not realize this, I'm not associated with the project, so my comments. ideas, etc do not necessarily reflect the opinions of the core Location maintainers :)

A quick update, my progress on the prototype of a dual method is proving more complex than expected. I'll try and put more time into this over the next week to get the base functionality working. However, I'm not sure if the additional complexity is worth the gain.

Note, time to create a base entity is only ~1 hour, maybe 2 hours for full integration with entity api. This side is not the complex bit!

..just a thought, i think a clean from-scratch reimplementation with some transplantation of snippets from 7.x-3.x is a better idea than to clone 7.x-3.x and refactor that... i'd guess using the api docs and other entity implementations for reference will get you to a working view/field/entity/relation integration faster than trying to mess with the old code.
But that's just my unsalted two cent ;-)

Well, I'm new to Drupal (and PHP, HTML, CSS, MySQL etc. etc.) and building a website in which the lcoation module is a significant feature so I'll give you my 2 cents.

The website I'm developing will have a number of views that will filter based on the same proximity data (lat, lon & distance). This proximity data would be something other than the user's location or a node location.

I would like to see a slightly more sophisticaed form to enter this proximity data that would allow the user to enter the lcoation using zip code, address, click a map or use the proximity data from the user settings (and enter the distance). I don't intend that the user would regularly set the proximity so I would like to be able to place it in a block or on it's own page. I realize that this form wouldn't be too difficult for me to write (I have some of it working) but I would rather it be part of the module. I would also like the proximity data to be persistant (registered and anonymous users) so I think that would mean that it would be (or could be) placed in the session data. This would allow the user to visit the site without having to enter the proximity data each time (or at least until the session timed out).

With the proximity data (including the distance) placed in the session data I would need an additional option in the views configuration to select "session data" as the proximity source. Ideally, if the session data was set then it would be used. If not then the user data would be used (if set) otherwise some default data would be used. Providing this simple enahancement (even without the above mentioned proximity form) would help me a lot. My original plan was to simply put some PHP in the "PHP option" in the views configutarion but I've read that placing PHP in the database is taboo (that's what I figured was happening there).

If my previous requests fall flat would it be possible to allow the distance to be provided through the PHP option?

Sorry for the length and thanks for the great module,
Dave

I'd be in favor of the approach that involves cloning the 7.x-3.x branch, simply because that would make it easier to merge in changes/tweaks made to the 7.x-3.x branch back into the 7.x-5.x branch. After a while, they probably will have diverged enough for merging (even manually) to be moot. Hopefully, by then, a 7.x-5.x would be good enough for experimental dev releases.

@rooby, if you're a bit pre-occupied in the next few days, I might try to get the ball rolling this weekend.

@rooby

I went ahead and created a 7.x-5.x branch.

I removed location_node and location_user from this new branch.

If I get time before you are able to work on this again, I'll see if I can figure out what's necessary to modify location_cck into a proper field implementation so that we can add it to any entity (and perhaps creating a separate ticket for detailing that problem).

I'm sure we can dump some of the other modules in the contrib/ directory as well. Once we have a proper field, we can probably do away with location_fax and location_phone, since I'm sure there will be (if there isn't already) a way in D7 to set-up multiple fields as a single record within an entity (similar to CCK Multigroups in CCK 6.x-3.x).

location_addanother should probably go, too (since there has to be a way to do this for any field in general; if there isn't, that logic probably should be abstracted out into a separate module that can be used for any field, not just a location field).

Ultimately, I'm thinking maybe we should fix location_cck in its current files until we're ready to drop the '_cck' part, rename all the functions, and merge the files' contents into the location.module and location.inc files. My rationale is that if we delay the actual merging of location_cck.* files into location.* files until the end, then we can continue merging in bug-fixes from the 7.x-3.x branch into the 7.x-5.x branch. But we should probably merge the files and rename all the location_cck implementations of hooks before putting out a dev release for the 7.x-5.x branch.

Anyway, these are just some of my thoughts. I'm tempted to draw up a sequence of steps and a list of discrete pieces of work that can be done, so we're all on the same page. However, given how this 7.x-5.x effort relies on sporadic volunteerism, I'm worried it might do more harm than good to try to create a rigid roadmap at this stage. I'm open to either way.

At the very least, I'd like to think that making it possible to add the location fields to an entity should probably be the first goal, before we start talking about re-implementing views-integration or use of the Entity API or integration with search or whatever.

How about using the geofield as the field to store location information? http://drupal.org/project/geofield

Hi, I was one of those guys who really wanted to use Location 7.x-4.x. Since I'm not really a techie, just thought I gave my views from a deployer's perspective.

Background: Deploying a open source tutor search platform (Asian parents love tuition)
Considerations:

+ I have 26,000 rows of data to handle at the start and this number will likely grow and belong to several geo locations
+ Location Search is very important because that's the number 1 consideration for choosing a tutor

Loved Location because:
+ Handles geocoding of addresses automatically and it was so easy to setup
+ Views Filter for Proximity is a godsend for my project

Gripes with it:
+ Could not use fields API to put it into Profile2 and manipulate data like the rest of fields api.
+ Unchangeable field labels (I changed it by editing tpl files, hiding away labels etc but it feels very hackish)

Suggestions:
Due to the Fields API issues and my lack of programming skills, I couldn't implement a proper workflow (e.g. Profile couldn't save location information, SOLR didn't see location as a searchable field etc) and trying to overcome these problems overwhelmed a novice like me.

Other than my chief gripe that Location was not a 'real' D7 field, I personally find that Location provides a lot of features (views filters, search etc) and all of them are usable but just lacking a little for primetime use. Perhaps some resources can be saved by being more integrative with other mods and 'giving up' some of these features.

I personally, will hope to see:
+ Entity & Fields API => Any entity can have a location field and can be geocoded
+ A way to internationalize Location? (i.e. changeable labels and different address details that can be set by users)
+ Built in integration with popular mods like SOR search (i.e Location focuses on providing lat/lon data and automatic geocoding site-wide to be used by other mods and provides the integrations for these mods).

Thanks. Apologies if I stated anything wrongly.

I'm very excited about the 5.x branch. I think making locations into fieldable entities is a great idea, since different sites have different needs regarding what types of info need to be recorded with a location. Some examples that come to mind:

• an Attn: line (name of the person who handles the mail for some topic, or the person to ask for when you get to the location)
• a phone or fax number field need not be part of the Location module but could use the Phone module; same for Email, etc.
• a date/time range when the location is open for business, or during which months mail should be sent there vs. another location
• an image of the location from the street, a la Google Street View, but allowing the content creator control over what photo to use
• written directions for finding the location, in case the GPS instructions are incorrect or a bridge is out, etc.

There are just a lot of cool fields that could be associated with a location -- and not with a node -- if the location itself were fieldable. I'm really very excited about the possibilities for my projects.

That said... I have to wonder whether the Location module still needs to supply the address and geographic fields, since we now have Addressfield and Geofield. Assuming Geocoder can geocode Addressfields as well as Location does its own fields (I haven't tried it), maybe Location module could just supply the fieldable location entity, and Addressfields and Geofields could be optionally attached to that entity as needed. And Location Search could become Geo Search or some such.

I'm looking forward to seeing how this turns out. Thank you, and good luck! If you need bounties to make this happen, say the word -- I've got a lot riding on this module, and I'm sure others do, too.

I will offer my 2 cents since I just had to build something similar to what location is trying to do for D7. I can share my experience.

I created a "Location" entity, which I called "venue", with 4 types:
Point - (an address)
Polygon -( a bounding box: Central Park, New York, The Bronx)
Line - (a series of points: NY Marathon)
MultiPolygon- (a series of boxes: the EU, US, NATO, high crime rate)

The location entity then had automatic fields similar to commerce products, where a point had an addressfield and a geofield, and the other fields just had a geofield. If you needed to have an addressfield display differently in different context is it rather easy to build a plugin for addressfield and store additional information in that field like phone, fax, and hide other fields on the address part, and serialize this extra data in the data column.

These location entities were then attached to other entities via entityreference field, which provides 3 basic input widgets, including autocomplete, but has a class based interface that allows you to easily add other methods to query location entities. For display, entityreference allows you to select any view mode for that entity.

What the location entity ends up providing is a class-based approach to performing all location functions, so most of the helper functions in location module would be turned into class methods.

Other things that my location entity had to do was to find parent bounding boxes, and do other spatial calculations. For example, given zip code 12345, what neighborhood is this point in, what city is it in, what are the nearest 50 node type x to this location.

In short, Drupal 7 is capable of being much more modular that D6, so location, as broad category of thing, should serve as a framework of managing different types of locations, the data for which can be stored using existing contrib modules.

There will always be new ways to store geodata. See #1325000: PostGIS, this project application just got approved and will be a geofield for Postgres GIS. I would like to think that location module could use any geodata providing fields and just provide the "glue"

Is anyone else wondering if there should be a 5.x branch of Location at all?

@rooby has a great rundown of the "new ecosystem" of location related modules at http://drupal.org/node/1063920#comment-5246464. There's a clear separation of concerns between each module yet they all work very well together. Instead of majorly refactoring Location and duplicating efforts, why not focus on extending this stack to areas where it is weak? For example, work is needed on a proximity solution (see http://drupal.org/sandbox/jpstrikesback/1367194) and integrating Gmap with geofield. There's also a lot of room for making pre-packaged features built on top of these solutions to make things easier for site builders.

I hope you all don't mind my 2 cents. Location has helped many, many people for many years. It just feels like it needs to be split apart, similar to Event being replaced by Date and Calendar.

@rickvug
I like the idea of integrating with other modules such as address field, but I don't really care for requiring that we use them to create location-like data. I would prefer an entity-based system where we could extend and build our location data in the way we want, which could optionally include address field, geofield, etc, but wouldn't necessarily be tied to them, and could use standard cck text fields and things like that. This is where I think having location's status as a separate project has value. It doesn't need to be a comprehensive solution to tackle every possible location-based scenario by itself, but it should allow the flexibility to be extended in ways that those other modules cannot provide for on their own or even in concert with one another.

@NathanM If what you are wanting is a location entity what about creating the entity and attaching geofield, address field, post code field etc. to that? Is it that you're wanting the location data to be part of the entity itself rather than attached via a field? If so what are the advantages that you see? At the moment I'm seeing individual fields as the more flexible solution.

I think one advantage is That you can tie all that information together into a single entity which can then be attached to and referenced by other entities. In my ideal setup, I would like to have a base node/entity which could be a name of the business, and be able to create multiple locations for that business which could then be easily referenced by that node as well as by views and by other entities which could reference a combination of business and address information from both the parent node as well as the various locations. I would also like to be able to structure the way in which the location information is structured, perhaps having addresses in more than one language and a location picker button where I can set the location on a google map based off of one or both of those addresses, which may or may not be created in the same format. If I have a directory structure similar to this:

Business 1
-Location 1 with map
-Location 2 with map
-Location 3 with map

...there is no good way, at the moment, that I can think of, where I would be able to display all three of those locations on a single map under the "Business 1 Entity" without using Location 3.x, nor is there a way I can think of to reference "Business 1, Location 2" in another entity at all. If I'm mistaken on this, please let me know, because I desperately need a solution like this for a project I'm working on.

Beyond that, I think location could help define how the different field types interact with one another and how they can be displayed in the node or entity that references them.

Right now, if a developer wants to make their module compatible with geofield, geocoder, address field, etc, they have to code for all of those different modules separately. Location could provide the interface by which all those different modules interact with one another by defining field and widget types and passing that information from one field to another. Therefore, if a developer wants their geo-like module to work with both geocoder and address field, they would simply need to plug it into the location system, rather than code for both of those modules.

...coming from #1418884: Update the project's page with info about the 7.x-5.x branch.

Any news of the upgrade of this module to 7.x-5.x ?Can I use it to a production site?Thanks

I installed the 7.x-5.x version.The site worked well,but I have the same issue with the 7.x-3.x version,I cannot add the map to a panel.Any thoughts?Thanks

@rooby - in reading your comment above, it might be worth dropping a notice on the project page similar to what Gmap has:

GMap is considered a legacy module. For new installations, you may find your geospatial needs better served by more modern modules such as OpenLayers, Geofield, Geocoder, Address Field, and Get Locations, among others.

Perhaps not quite so severe, but at least making people - who only knew of Location from D4.7, D5, and D6 sites - aware of the other options now available.

Just a thought.

Dear developers,

Let me tell you that the location module looks extremely promising to me. I watched this youtube movie: http://www.youtube.com/watch?v=AxeskzN8BAc and got very excited.

I installed location 7.x-4.x (using GIT) as the guy told me... but I'm hit with errors like:

Allows you to add a phone number to a location.
This version is not compatible with Drupal 7.x and should be replaced.
I didn't get the proximity search working yet and after reading here, I'm hesitant to go on in this direction.

So I started reading and came to this thread...

I'm a complete noob regarding PHP (but I'm able to set up Drupal on nginx on my own servers, just a hobby, I'm actually a biologist), I'm working on an idea I'm passionate about and learning as I go. So far I'm very impressed with Drupal as a whole, I works exactly as I would expect such a complex system to work with the nodes and the fields that can be added to them, it is just very logical. The idea of views to gather specific nodes is just brilliant.

What am I babbling about you might ask?
Well I just want to share that I appreciate all your efforts however, if this is a dead end I would very much like to be pointed in the right direction to set op proximity search. Is there another way? Is there anything a noob can do? Can we start a kickstarter for a kick-ass location module in drupal 7?

Because of the idea I have, the locations module will be a the center of my website. I don't want to take the risk of going with something that will slowly become unsupported/unstable.

Great work so far!

https://drupal.org/node/1944648

... Seems to provide at least a starting point for similar features.

@teek: if I were you I would stay away from 7.x-4.x because it hasn't been touched since September 2012. You should stick with either 7.x-3.x or perhaps 7.x-5.x if you are feeling dangerous. .

supported version now
all others - postponed

...proper status then ;)

This issue is about the roadmap towards a stable-ish 7.x-5x branch. Better keep it separate from all 7.x-3.x issues (when we filter issues by version).

Thank you for your reply, but I have already constructed what I needed using views, geofield, addressfield, geocoder and geophp (dev versions I have to add) like this: https://drupal.org/node/1944648

It works well and does what I need.

Adding note about expected timeframe.

Podarok and others, has there been any more thought or development on features to allow for reuse of locations since the 3.x version?

I need this and I've been working on an add on module that would allow for this. I'm not entirely sure if it works the way it should yet. I'm doing some testing on it and will take it live soon so I'm about to find out at least if it'll work the way I wanted it to.

It seems that the location module has a overwhelming tendency to define differences very very strictly so that you almost always get new location entries. I'm not sure if this was a necessity for other operations to work correctly or if it's just a reflection of how difficult it is to decide that two very similar locations are indeed the same place.

If it's a case of the latter, then I might have something I can contribute in a month or two. My module runs before the location_node module is executed and does some initial lookups in the database for locations that might be related to the entered location and assigns a locaton ID to the freshly inputted location so that it's evaluated as if it were an existing location that had possible edits instead of a freshly entered location that jumps into "COW" mode and almost never comes back.

Of course, this approach brings up a whole host of other issues that I'm working to minimize. If this is something that's needed and altering the bias of the location module to reuse old locations instead of spawning new entries is acceptable to it's core logic, I'll work on getting it to a releasable state for a contrib.

Resetting to 5.x in accordance with #34.