Integration with addressfield / geofield modules

Moving this to 7.x-4.x as that is where any new functionality will be added.

The difference between location and addressfield is that addressfield is specifically for postal addresses, whereas location is (kind of) aimed more at geographical location, so things like geocoding, proximity and mapping.

Their method of having different address fields depending on what is relevant for the selected country is pretty cool and could no doubt be done in this module if it was desired but so far they only support great britain, united states & brazil. Other countries still have to be added.

I guess something that *may* be possible in future is the location module using their address fields and building on top of that all the coordinate functionality and gmap integration. If that is feasible it might save a lot of code/functionality duplication and increase the ability to interact with other modules (for example addressfield is to be used with the new commerce module suite).

So I guess it's either we leave location as is, borrow their idea of dynamic fields based on country, or use their fields entirely. The second option is not my favourite as I'm not a fan of duplicating/wasting code/effort.

If it is feasible to use their fields and add to that coordinates and proximity functionality that might be good option and would make location a bit more focused and less ever expanding.

I'm currently sizing up my options for a D7 project I'm going to be working on with regards to attaching geo data to nodes.
On the one hand, I'd like to make use of the gmap integration of location.
On the other hand, I will be using commerce, so Address Field is a must.

I'm leaning towards Address Field as commerce is the greater need.
So from my perspective, building on Address Field in D7 would be the better solution.

I shall watch this issue with interest!

Another vote for AddressField here.

As said above, duplication of effort is wasteful so it would make sense to make AddressField a requirement for this module and use the entered and stored address to find the geocoded location. The location module would then only need to store the lat,lon and not worry about storage of addresses.

AddressField integration with Location module would be the ideal direction to go in the future. Maybe have a checkbox which states "use AddressField for location storage" & then have a select drop-down list to choose which address field the location will be stored in, Since Location CCK is not as easy to work with compared to node/user/etc. locations, by adding this functionality we would get the best of both worlds.

Complimentary issue #740970: Migrate data from Addresses Module to Location CCK Module

I also will be needing to use address field as part of drupal commerce, so I would also vote for integration if it's possible and/or not a complete rewrite of everything.

7.x-4.x will definitely be a complete rewrite because the code in 7.x-3.x is very old and can be done better (especially with the advancements from D6 to D7).

I do think the rewrite probably should include a change to utilize addressfield and then just add whatever extra functionality we need on top of that, as outlined in #1.

Have you seen the geofield module? It performs a similar function to Location and the maintainer has added integration with addressfield too.

That looks pretty good from reading the description.

If that module provides sufficient functionality maybe all that is needed is to make sure it is compatible with the gmap module in the same way as this module is and see if it is possible to make an upgrade path between this module and that module (I don't see why it wouldn't be possible).

It is definitely wasting (already very stretched) resources to be working on all these different (almost the same) modules, if it is possible to have one that can cover everything or at least come close.
That way everyone's time can be spent making one excellent module instead of a bunch that all need some work.
At least that is my opinion.

And the fact that it also supports WKT, KML, GPX, GeoJSON & openlayers makes it sound very enticing indeed.

I think my next lot of free time will involve some playing around with that module.
If it is as good as it sounds will have to discuss with bdragon and other location/gmap maintainer peoples about potentially depreciating this module in favour of that one (full upgrade path would have to be provided).

Anything that utilises peoples time more efficiently would be a step forward.

From this post #1089122: Geofield / Location CCK , what's the difference ?, looks like it has been discussed at the last drupalcon and the idea is to get to the point where location depends on geofield and then adds only additional missing functionality.

Which also points to geofield not currently providing all the functionality of the location module.

Here are two additional posts.

A meeting of the minds:http://groups.drupal.org/node/137049
A summary before the thread crashed: http://groups.drupal.org/node/138884

I'm very happy to see post #8. If it looks like something else already implements most of the location functionality, it would save a ton of conversion time, and maybe some of the remaining features can be a module on top versus a completely parallel one.

Great stuff, I'm liking where this thread is going!

here's an other issue discussing similar topic, http://drupal.org/node/861126
For the moment addressfield needs compatibility with GMap. I agree with rooby's point of view here.

For reference here's a related issue in addressfield's queue http://drupal.org/node/960766

Throwing a different spin on things, I needed a fairly custom address module and I've integrated my version of address with geofield via an intermediary field.

The interface is a simple checkbox widget, and the instance settings have an address field source and geofield destination.

i.e. instance settings
Source field [Address instance label \/]
Destination field [Geofield label \/]

entity edit page
[*] Populate [geofield label] using [address field label]

I'm using JScript to do the geoencoding via a Drupal menu callback to ipdbinfo, and populating the destination field.

This is working really nicely and totally decouples the two modules while providing the geoencoding integration. It would be trivial to extend this to say, pulling data from a textfield or another address based widget, and in relation to the data returned from the geoencoding service, this can be saved independently from the two other fields as required. Again, the results could trigger reverse callbacks to the address field to correct information, etc, but I didn't require / need the additional complexity of this.

I'm doing the same thing to integrate multiple address fields, mimicking the Ubercart "[*] Same as postal address" functionality.

Since my node type is an organisation, I'm simply theming the entire node into an empty microformat frame, using partially formatted sections of all the individual elements to complete this. I had played around with using the formatter settings form to combine components into a hCard format, but the interface sucked and after reading about the new schema.org formats, I went with the entity level formatting for ease of use. This is the only downside of this approach.

My ideal solution

1) To extended multifield module into a microformat type field. A different bundle for every component type.

2) To these bundles, make up the components using basic core fields

i.e. For a person microformat, I would use the name field module for the name, an address field, a geofield, and a syncing field.

For a company, simply replace the name field with a text field.

3) Create / set the formatters required by various components to display the completed formatted display. The base multifield would create the wrapping elements and individual field formatters to complete this task.

[I'm not sure if this is possible using hook_field_extra_fields()]
4) Create additional field display items to integrate additional views, for example JScript or image maps. (i.e. reuse the same field to provide two or more displays)

Step 1 is possible but complex. Step 2 is minor and step 3 is trival. Step 4 is over and above anything already out there, but adds that extra level of flexibility. I'll hit this soon, as I need all of the fields to provide this base company microformat, but I'm planning to reuse all of the fields in a vCard and some of the fields in an image map. Current plans are to just do this in the template, but I will put aside some time to investigate alternative possibilities.

So this would result in:
(New) Container microformat module
Reuse any existing textfield, name, address, country, geofield, ... modules with new formatter options
(New or extended) Geoencoder sync field. Maybe provide the field in the microformat, and leave the geoencoding as a widgets for existing modules

It almost seems too easy...

I'm happy to supply code examples, but my code is still in early stages of development and has tight integration with a new countries region module (also in a very early alpha stage) and well as custom modifications for the project that I'm working on. Most of this resides in an custom coded address module, so it would require a lot of refactoring.

subscribe

subscribe

here's an other issue discussing similar topic, http://drupal.org/node/861126
For the moment geofield needs compatibility with GMap. I agree with rooby's point of view here, merging efforts and using addressfield as the address field is the way to go.
+
http://drupal.org/project/phone
http://drupal.org/project/email

(I'm developping on site which needs 2 address fields to work, one user location for GMAP attached to the user and one addressfield for the profile2 field and commerce functionnalities. So duplicate data entry is required !)

For reference here's a related issue in addressfield's queue http://drupal.org/node/960766

Apparently the current maintainer of Geofield is swamped with work and geofield needs a new lead maintainer http://drupal.org/node/1206464

Please note that addressfield now has a fairly flexible plugin system.

subscribe

Frankly, I'm not a particularly big fan of having to use either location or address field, as both are a bit on the rigid side when it comes to their implementation. There are plenty of people who's use of address/location fields has nothing to do with creating shipping address labels. Geolocation is a pretty nice alternative, but the thing I don't like about it is that it commits you to only using a single text field to set location. It would be nice if users could create their own text fields which they want to use for addresses, and then use geolocation to set coordinates based on whatever field the user chooses.

+1000.

Addressfield does only and exactly what it is supposed to do, and that's great. But I need to do a location in the form of "Cairo, Egypt" or "Memphis, TN" and addressfield does not work for that -- nor should it, since its standards-based.

Right now, the location module collects address information in a format truly honest to the address format of a few countries. It then provides geocoding and views integration for those locations to enable proximity searches, filtering by state/province, filtering by country, and so forth.

The addressfield module is strictly about storing address information and rendering it in a way that's consistent with each country's convention for representing addresses.

If these 2 are to be integrated, it should probably be done in a way where the addressfield module is used to collect and display information for an address, but the location module back-end is used for geocoding and all the other stuff that it does right now. Perhaps a plugin for integrating the two could parse addressfield addresses into city, state/province, and country values that could be stored in a location module friendly way so that the other views filtering can be used with locations entered using the addressfield.

The goal here is similar to the one expressed by Alan D. in #12: to separate out the collection and display of address information from the logic for geocoding and other geocoding-related functionality and views-integration.

.

+2

I've been out of action for a while but I'd like to get back into this and get something sorted.

I've spent a very large number of hours on 7.x-3.x and I'm not thrilled at the prospect of spending more time on it when it will be immediately outdated by 7.x-4.x.

Also, with issues like #1064666: Location CCK not saving for entities other than nodes, which mean if that issue isn't fixed we don't have a proper drupal 7 module and to fix it puts us well into 7.x-4.x territory anyway, with need for some upgrade path work and such.

So I will probably now be spending my time working towards 7.x-4.x.

Planning is first up and I need to do some in depth review of the other drupal 7 modules available and propose a solution to other maintainers and users.
The solution will preferably be the one with the least amount of duplicate code, duplicate effort and bloat.

Any solution chosen would of course have a full upgrade path from existing versions of location.

On the surface though it looks like we could have something like:

• Addressfield for storing displaying addresses
• Geofield for storing coordinates
• Geocoder for geocoding addressfield addresses into geofield fields.
• Field collection for in case you want to group your fields nicely as the location module does.
• Phone, Email, Link and others can be used to add extra data as required.

What is missing (I need to have a better think about this as we don't want to lose functionality):

• Views filters/arguments etc. - Some will likely be available in those other modules but I doubt post code proximity will be available at least. And that I think would be used by a lot of people.
• Addressfield, out of the box, doesn't allow the flexibility of location in making different parts of the address unavailable/optional/required, as mentioned by shunting. It might be possible though to submit patches to change this in some way or have another add-on module that gives a UI where this can be set (the latter might be more likely after seeing some of the addressfield issues regarding this). I don't mind making patches for other modules in addition to the location side of things if it is a preferable way to go.
• There may be others yet.

I also understand people might not like the idea of having to install many modules instead of 1 but there are benefits such as the integration with addressfield and drupal commerce and maybe more.
Also, many people only need part of the solution, like address only or geofield only and with location they are getting a lot of bloat they don't need as it all comes together.

I suppose it would be fair to argue that there could be room for the addressfield/geofield/etc modular option and the all in one location solution, just being a rewrite of location 7.x-3.x for drupal 7, still keeping everything in location.
In which case a module could potentially be written to migrate from using location to using the modular addressfield/geofield solution for those who want it.

I will think about it more anyway and invite any ideas and opinions on solutions.

I like the modular approach. Would there be a case for wrapping up the relevant entities etc in a feature?

Another module to consider is Relation, for the Views integration. I'm currently working on a project which uses the Organic Groups module. Groups have the same add-on "relation" to nodes as Locations do. I can tell you that working out the Views integration in OG 7.x would be WAY easier if it was made using a defined Relation.

I'd be in favor of a 7.x-4.x that makes more proper use of the fields API. I think with the port of the location_cck module to D7, we're most of the way there. From there, then, I'd start looking into integration with other modules for inputting of locations and maybe even the storage of them. This path, I think, would be the least amount of work as much of the logic in the code would remain unchanged, initially.

I think the biggest things we're lacking right now are the ability to add locations to any entity and the incomplete views integration. I think starting a 7.x-4.x branch from scratch, where we attempt to tie the other modules together, might be too much of a reset, whereas modifying location_cck into a proper field implementation and then merging it into the main location module (so as to get rid of location_node and location_user) would be much less work and would preserve much of the work that has already gone into maintaining and porting the module. It'd also make the upgrade path much easier.

A rewrite from scratch that tries to act as glue code between other modules might be more of a pain to maintain, esp. given the maintenance resources we have right now.

Finally, after a discussion w/ bdragon on IRC about this a couple weeks back, it might just make more sense to start the fields implementation as a new 7.x-5.x branch with the current 7.x-3.x branch as the starting point, since the 7.x-4.x branch is out-of-date. This would make it easier to just merge bug-fixes and similar commits to 7.x-3.x into a new 7.x-5.x branch while we work on the 7.x-5.x branch.

Finally, after a discussion w/ bdragon on IRC about this a couple weeks back, it might just make more sense to start the fields implementation as a new 7.x-5.x branch with the current 7.x-3.x branch as the starting point, since the 7.x-4.x branch is out-of-date. This would make it easier to just merge bug-fixes and similar commits to 7.x-3.x into a new 7.x-5.x branch while we work on the 7.x-5.x branch.

+1
This is what I've been hoping for for a while so it's good to know others think the same thing.
7.x-3.x is much further along so it mekes sense not to waste that work.
This will give me renewed enthusiasm so I'll probably start on this soon.
It's a bit annoying to have to jump up another major version number but there are worse things in the world :)

An alternative solution with the modular approach could be done separately to location with a new feature that ties those other modules together as was mentioned above.
Down the line someone could also write a migration module between location and addressfield/geofield for people who want it.

@ankur:

I haven't been on IRC for ages but did bdragon happen to mention he was going to use 7.x-4.x for anything?

If not it might be good to clear it out and make it the same as the current 7.x-3.x and start there instead of skipping 4x and going to 5x.

Just one question: An location entity or FAPI based plugin system? I started playing around with the latter and could be a better option than an entity based solution as you would want control of the output, etc, but you loss big time on being able to significantly extend it.

@rooby in #28:

When I talked to him in a PM chat on IRC, bdragon said he didn't have any plans (or time) any time soon to continue working on the 7.x-4.x branch that he started a while back. I think his feeling was that the repository history might be confusing if we were to wipe out the current 7.x-4.x branch and restart it from the current 7.x-3.x branch, which was why the suggestion of a 7.x-5.x branch was made. I don't think it'd be too bad to start an entirely new branch. I've seen other projects on here where a newer branch is being developed, never results in any kind of stable release, and is completely scrapped for an even newer branch. He did, however, ultimately express that he'd be fine with whatever route was taken and would simply be more glad to just see development continue.

@Alan D. in #29: I think we're also thinking of a Fields API route instead of an entity one. In fact, rooby's port (6.x-3.x to 7.x-3.x) of location_cck is pretty much a port from the D6 CCK API to the D7 Fields API, but it's still bound by some legacy issues that restrict the D7 fields to only be available for nodes and users.

Ctools and plugin system
With Views and Panels requiring it, what are your thoughts about Ctools? This would enable a fairly clean plugin system allowing other modules to extend it. This way you could define address components and allow other modules to provide additional widgets. [I haven't implemented this personally, but for larger modules the implementation appears much cleaner]

This would then allow you to write component plugins for CCK Phone / Phone modules, dropping location_[fax|phone] and maybe implement location_postcode as a separate project. The shear size and complication would be drastically minimized without loss of functionality.

I guess that you will be dropping location_[node|user|taxonomy], location_addanother and provide a single location field. Maybe either a sub-module or even a separate project for migration issues if these prove significant.

Schema
With the static field system schema what thoughts have people had about the schema? Currently there is the main location table, but with plugins potentially allowing these to be extended, having one table could result in a number of NULL fields. [btw, hook_field_schema() should be in the install file as of D7+]

From personal experience, using the field system effectively locks you into a static schema at the point of field creation, but moving to anything more complex, like per-field based schema would negate any benefits from not using the entity system. (Ie: Time to implement would be likely to be more than the time required to bend the field system into what you require.)

So maybe an administrative page that allows you to define the available components of all locations, and alter the schema of {location} based on the selected values. Once enabled here, they can be enabled to any field via a list of available components in the field settings.

I wonder what the complication would be to make it an entity with the additional fields added too. There is minimal overhead in creating the entity, but I'm not sure about embedding an entity subform into an existing form. It would allow you to ignore strange feature requests for additional fields.

Summing up
Sorry, I've waffled enough, but to paraphrase a possible road map:

• Base entity which defines a field wrapper and does nothing but to coordinate components.
• Plugin system to define base fields about a location. (alias of the node title field)
• Make the entity fieldable to enable infinite possible combinations
• Define core plugins to cover existing location fields. Split phone / fax off into either component plugins or simply let them be integrated via the field system.
• Migrate the old node/user/taxonomy modules to the new field based system.

I may play around tomorrow and see how feasible this idea is like. This is a fairly massive undertaking, maybe too much for 7.x-5.x?

Sounds very complicated, but this would be my ideal system, if someone had the cajones to pull it off.

Short response for now until I have some more time to investigate:

I'm thinking along the same lines but I haven't put as much thought into potential implementations yet.
(Sorry, there is some repetition here from Alan's post)
* A location entity makes perfect sense because a location should be a first class entity. Locations need to be able to exist separately to users, nodes taxonomy etc. Being an entity also allows for integration with search api etc. This will also allow us to rid ourselves of the dodgy hook_locationapi() so people can form alter etc. as expected.
* Needs to be fieldable to solve all the issues we currently get along the lines of adding various new fields like email, website, mobile etc. People need to be able to add the fields they deem necessary.
* We definitely want to do away with location_node, location_user, location_taxonomy, location_cck modules.
* I was thinking location_phone and locaiton_fax would be replaced with fields but a plugin is another option.
* Relationships with other entities can be done using fields line node reference, the relation module and potentially a new location field that essentially embeds a location entity's form into the other entities form. Kind of along the lines of how a file field can create a media entity.
* Upgrade path is a given and I don't think needs too much consideration during the planing phase. I'm confident an upgrade path is doable no matter what we end up with in the new version. And I'm happy to code it. Potentially the hardest thing to migrate would be location views. How much of that would need to be supported is debatable.

I'm quite exited and enthused about this and I'm confident we can pull it off, and I think it is doable in one version 7.x-5.x. I think doing parts of it across multiple versions would be harder on both developers and users and while we have the chance I say go all out seeing as we've just been stuck with patching up an old drupal 4.6 module for so long.

So now we just need to plan in a bit more detail the roadmap and we can get on it.

I've still never had an in depth look at the ctools api's yet either so I'll have to do that.

I'm short on time for the next couple of weeks but after that I can dedicate some regular time.

I'm away for a holiday for most of next week and it would be the perfect time to research possible development options but I've been banned from taking my laptop, damn it :)

Seeing as this issue is being derailed I have opened a new issue with a more logical name at #1346746: Roadmap for next gen location (7.x-5.x)

So at least for now, integration with addressfield & geofield etc. is off the cards.

A solution with something like a feature that ties together those other modules as mentioned in #23 could happily live alongside location though.

I hoping not to derail this. Personally, after trying Addresses Field for the first time, reading the hype for over 6 months, I disliked it in relation to the standard Location method. However most people like it, so I think that there should be two plugins that provide the Address components, one for both modules!

If that's feasible it would be a great solution.

It looks like we are trying to mix all available ingredients and make one soup. From what i have seen from the issues que of address field and what it does, Address fields scope is limited.
Evey one has different ways of seeing things and i don't think it will ever reach any port, and it is never complete.some one adds some country patch, and another from the same country disagrees with it.And the purpose of Postal address on on site?

1.The draw backs of address field, there is no complete list of all the countries
2.there is no support for cities

I feel what an address should have,
1.Easily selectable Country, State/province, city
2.A geo-code/Map integration with co-ordinates
3.the flexibility to add required fields, i.e Name, organization name so on that's it.
A library is good concept for a start.