D7 port wishlist (Openlayers Geocoder)

I'm planning to start to work on the D7 port after OL will have its first 7.x-dev out: http://drupal.org/node/743856#comment-3471410

@antoniodemarco: Now that OL has a 7.x-dev release, I just wanted to check in and see if any more progress had been made on a OpenLayers Geocoder D7 port.

Thanks,
Ben

subscribe

I'd love to see Address Field (http://drupal.org/project/addressfield) support in the D7 version of this module. It looks like Address Field is going to be a great address storage solution in D7 (it's already working really well for me with Drupal Commerce). If an initial port gets underway, I'm happy to contribute extensive review and testing.

--Ben

subscribe

Antonio, any update?

I too am interested in seeing some movement on porting this module to D7. Unfortunately I'm poor but I have time right now that I would be willing to contribute, and I may be trying to raise money for my own site development. What is it going to take to get this done?

Hello everybody. Unfortunately it's a busy period right now but I do confirm my interest in porting the project to D7, hope to have more time or an actual use case soon.

Hi Antonio!

thanks!

I'm panning on start porting the module: does anybody have any wish for the D7 version? Any feature that would be cool to add or something to change from the D6 version?

@antoniodemarco: That's really great news! What do you think about support for Address Field (http://drupal.org/project/addressfield) as an address storage solution that can be geocoded by Openlayers Geocoder?

I'd love, for instance, to be able to geocode the locations of my customers that order via Drupal Commerce (http://drupal.org/project/commerce). Because Address Field provides the address storage for Drupal Commerce, if Operlayers Geocoder could integrate with Address Field, geocoding customer locations would be fast and easy.

Thoughts?

--Ben

as i remember, input field, from that geocoder reads the the address to process, after save the node, its empty.

maybee is better in module options allow to select that field u want use as address, so, after create new node the selected input value is processed (geocoded) and after save is stored....

+1

subscribe

In terms of storing the geocoded coordinates, I'd love to see support for storing it as a Geofield (https://github.com/developmentseed/geofield). That's a module that Development Seed has been working on.

--Ben

i think that is better manually create fields in content type.

and after, in module options, select that fields must be populated from what parsed data from geocoder.

for example:

in content type add:
- Address (text)
- Longitude (text)
- Latitude (text)
- PostalCode (text).

in module options, select:

field for geocode: Address
field for longitude: Longitude
field for latitude:Latitude
field for postal code: PostalCode
etc...

in node add form, after type something in Address field, this info is geocoded, and possible suggestions are showed. After select one, the info from this is assigned to rest of fields.

that do u think?

Sub

@steinmb: the first D7 version will not include any new feature, it will be mostly a port of the actual functionalities and behavior. Still I believe that the suggestions of people that where using the D6 version could help me in achieving a new and better design of the module.

#19: this could be a possibility but it is based on the assumption that the user will want to spot and save only a single location while currently you can input multiple points, shapes, etc... I would keep such a flexibility as a requirement, what do you think?

#5, #13 and #18: surely both modules deserve attention. In the d6 version you can only auto-complete text and select fields, in the D7 we could think to a pluggable system of auto-completion controllers that could make the integration of other kind of fields easier (3rd party CCK fields, taxonomy term widgets, etc...).

Drupal Commerce's dependency on the Address Field will probably make Address Field very popular and it makes sense for it to be supported by Openlayers Geocoder. However, the idea of pluggable auto-completion controllers for integration with any D7 Field is a fantastic idea and the most flexible and future-proof implementation.

subscribe

subscribe

subscribe

Since I need this module pretty quickly I got to work. I was surprised to find there's no D7 branch in CVS so I got started from Head on D6. I have ported most of the module to D7 now. It's extremely limited but mostly by my knowledge of openlayers.

Right now I've defined a geocoding field type and widget. It renders a text box that performs the ajax autocomplete of an address being typed in and saves the lat/long data in a hidden field.

Good things:

• It works in D7
• Using D7 field API and field schema for storing data rather than separate table
• Stores the lat/long data rather than going and getting it via ajax calls

Problems:

• The lat/long data isn't in any 'standard' format. It's simply an object saved using php's serialize function like a lot of the old drupal variables.
• The field is simply a single textfield that takes in an address
• There's no actual mapping done. I can do the auto-complete, ajax, and fields...no clue where to start in actually making a map show up.
• I took out some of the extra options to simplify things since I was having to implement the fields, this includes tokens

I cleaned up my code a bit. Hopefully it'll give this module a bit of a head start.

This is definitely not ready for use but it's something.

subscribing

subscribing

sub and can maintainer bump up a new branch for 7.x

subscribing

A code-sprint to port OL Geocoder to D7 has been scheduled for Thursday 10th of February. Stay tuned!

Sorry, I think I saw this post too late to contribute.... Any news on that code-sprint?
#29 looks like a good starting point.... and will save lots of time.

I think the big part that makes this difficult is the field. In 6 it was all through CCK and that was a separate module that was already done but in 7 there isn't a CCK, it's a field and nobody's ported that yet. All my code does is do an autocomplete on an address and store it with its associated lat/long.

Correct me if I'm wrong but from my point of view, all we need to do now is formating the output. For example if it's displayed as WKT data then we can use this module with OpenLayers. Or even better, if there is an option on views to choose between WKT and latitude,longitude then we could use this module with GMap, OpenLayers and a whole bunch of other modules for displaying the data!

subscribing

Any news on this port?

subscribe

subscribe

How did the code sprint go?

++

We are in March. Is porting OpenLayers Geocode still on the table at this point?

The Openlayers CCK widget (in the main Openlayers module) is now depricated in Drupal 7. http://drupal.org/node/1022994 Which means the Openlayers Geocoder module might not be supported in Drupal 7.

There is a lot of interest and development in the Geolocation Field module for Drupal 7. It would be great if you guys piped in and contributed interest, support, feature requests and testing. http://drupal.org/node/1040640 It both geocodes and reverse geocodes.

If the Geolocation Field Module can map the Lat and Lon to text fields you will then be able to use Views to create an Openlayers data layer for each node. Openlayers Geocoder does it very elegantly and hopefully the maintainers of Geolocation Field module can use it for a little inspiration.

subscribe

Might be slightly off topic but the best turnkey d7 solution ive found is:

Addressfield (to store addresses) > geocode (to translate automatically) > geocode (to store geodata lat/lon, and integrate with mapping) > openlayers (to map data in maps).

Im having a little trouble with the openlayers integration for map display but the rest works amazingly well.

Subscribe

subscribe

Subscribe

subscribe

Please, use the new "following" button on the top right of the issue.

Really needed. No other modules with same :
- good interface
- simple to use logic

Please help us.