The OpenLayers Locator is a Drupal 7 feature module that creates a robust, turn-key Locator using the Openlayers, Openlayers Proximity, Addressfield, Geofield and Geocoder modules. Getting up and running with these modules from scratch can be challenging. This feature package simplifies that. Out of the box it provides a Location content type with an address field that is automatically geocoded using Google's Geocoder. The locations are displayed on a combined list & dynamic map view. All views can be searched for locations within a configurable distance of a provided postal code, city, province, state or any other geo-spatial reference point understood by Google.

Features:

  • Search by Closest Proximity within chosen Radius
  • Baked in support for Google Maps, Yahoo Maps, Virtual Earth (Bing) and OpenStreetMap
  • Automatic Geocoding of Locations
  • Global Support (Support for Kilometers or Miles)
  • Automatic Distance Calculations (Sort locations by distance from a given location)
  • Combine maps from different map providers into one
  • Multiple Map Types - Roads, Satellite, Hybrid, Terrain
  • Map interactions like popups, zoom controls, and fullscreen
  • Per-country edit form and formatting of addresses
  • No postal code updates or imports required
  • It uses Views and OpenLayers to create the maps, which provides a ton of options configurable through the Drupal UI to completely make it your own (No coding required).

Motivation

  • There is currently no turn-key "Store Locator" module available in Drupal.
  • GMap and Location modules (Current popular choice for Geospatial tools in Drupal) do not have a recommended release for D7 as of writing this (26 Jan 12)
  • GMap/Location's proximity searching requires large database imports of Postal Codes/Zip Codes. See Example #255995: Canadian postal codes for MySQL zipcodes table. This requires constant updates and in many cases this data is not freely available and requires users to purchase these records for thousands of dollars.
  • The OpenLayers and related modules provide for the most robust and flexible Geospacial Tools in Drupal
  • To configure a simple "Store Locator" using OpenLayers etc, can be very time-consuming and challenging for new to moderate level users.

Goals

  1. To provide a turn-key store locator for Drupal- An under-supported, but often sought after feature.
  2. To utilize the most robust, flexible geosptial tools currently available in Drupal.
  3. To create a highly customizable store locator that is completely configurable in the User Interface.

Review of Existing Projects

To avoid duplication, a research of existing projects/sandbox projects results in:
http://drupal.org/sandbox/ivan.stegic/1220430
http://drupal.org/sandbox/Beanjammin/1207492

Neither utilize OpenLayers and have not had commits in months.

Current state

This feature package is currently pretty solid. It is in production use on several sites (that have helped in identifying bugs or feature enhancements). There are a few minor issues as noted in the Roadmap. They do not keep the module from being used and only help to enhance the user experience. The current lack of a solid release of the OpenLayers Proximity for Drupal 7 is keeping this module from getting a recommended release. The OpenLayers Proximity module is currently in a sandbox and the maintainer is deciding whether to release the module as the official 7.x release of OpenLayers proximity or move it to a new namespace "Proximity" (as the new version is no longer dependent on OpenLayers). Once this is complete a release will be made.

Project page
Try out a demonstration
git clone --branch 7.x-1.x http://git.drupal.org/sandbox/nicoz/1303200.git

Comments

pixelsweatshop’s picture

Issue summary: View changes

typo

pixelsweatshop’s picture

Issue summary: View changes

added link

pixelsweatshop’s picture

Issue summary: View changes

added demo link

pixelsweatshop’s picture

Issue summary: View changes

added more links and fixed typos

pixelsweatshop’s picture

Issue summary: View changes

spacing

pixelsweatshop’s picture

Issue summary: View changes

added git info

pixelsweatshop’s picture

Issue summary: View changes

changed git info

eugene.ilyin’s picture

Status: Needs review » Needs work

Hello. I spent manual review of your module.

Readme.txt - max string length recomended is 80 chars . In other places also.
version = "7.x-1.0-dev" - remove version tag. Drupal.org add it automatically.

pixelsweatshop’s picture

Status: Needs work » Needs review

Thank you for taking the time to review. I have now adjusted the readme and info file. Please also note that I am now working off the 7.x-1.x branch (as I noticed that others are using this naming convention)

git clone --branch 7.x-1.x nicoz@git.drupal.org:sandbox/nicoz/1303200.git

pixelsweatshop’s picture

Issue summary: View changes

code tags

sreynen’s picture

Status: Needs review » Needs work

I can confirm the issues in #1 are fixed now. The only issue I see is namespacing. It looks like you've consistently prefixed the various elements you're defining (e.g. fields, content types, maps) with ol_locator_, which is great. However, that prefix doesn't match your module's machine name, openlayers_locator, so there could be conflicts with a hypothetical module named ol_locator. This is unlikely, but it's also a pain to change later (you'd need to remove and re-create everything), so I suggest changing it before this is promoted to a full project. It's probably easier to change the module name by doing a new export, rather than re-naming everything in the export.

pixelsweatshop’s picture

Status: Needs work » Needs review

I figured that would come back to bite me. I intended to use consistent namespacing as all of the other openlayers projects for consistency, but ran into a problem when defining fields. The name is limited to 32 characters, including the 'field_' prefix. Therefore some of the field names were going to be too long. To avoid this, it was shortened to ol_locator early on and carried though. I have now updated the project to use the ol_locator namespace and it has been committed http://drupalcode.org/sandbox/nicoz/1303200.git/commit/ff553a6

Thank you for reviewing and letting me know. I appreciate it very much.

sreynen’s picture

Status: Needs review » Needs work

Sorry, I should have been clearer before. Changing the project name is a little more complicated than changing the project line in the .info file. And now that I'm looking at it, that line shouldn't be there at all, since it gets added automatically by the packaging script. See: http://drupal.org/node/542202#project

Before you have releases, the project name shows up in two places: file names and function prefixes. So to change your project name to "ol_locator", you'll need to change the name of files like "openlayers_locator.info" to "ol_locator.info" and change the name of functions like "openlayers_locator_openlayers_maps" to "ol_locator_openlayers_maps". You might find this easier to do by re-exporting the feature rather than going through every function and file name.

pixelsweatshop’s picture

Status: Needs work » Needs review

My apologies. I should know that. I guess that's exactly the reason why we go through this process. :) Thanks for keeping an eye on me. These changes have now been committed. http://drupalcode.org/sandbox/nicoz/1303200.git/commit/3d2df21

sreynen’s picture

I hate to keep moving this back to "needs work," but it looks like openlayers_locator_views_api() and openlayers_locator_views_default_views() still need name changes. Everything else looks great.

pixelsweatshop’s picture

sorry, I was in the midst of making the last changes when you were reviewing. you're too quick for me. They are now updated. Sorry for the hassle. http://drupalcode.org/sandbox/nicoz/1303200.git/commit/3d2df21

sreynen’s picture

Status: Needs review » Reviewed & tested by the community

Everything now looks good to me.

klausi’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: +PAreview: single application approval

There are still files other than README.txt in the master branch, make sure to remove them. See also step 5 in http://drupal.org/node/1127732

Thanks for your contribution, nicoz! Welcome to the community of project contributors on drupal.org.

I have promoted your sandbox to a full project.
http://drupal.org/project/ol_locator

Now that this experimental project has been promoted, you'll need to update the URL of your remote repository or reclone it.

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

As you continue to work on your module, keep in mind: Commit messages - providing history and credit and Release naming conventions.

Thanks to the dedicated reviewer(s) as well.

Status: Fixed » Closed (fixed)

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

pixelsweatshop’s picture

Status: Closed (fixed) » Needs review

Just wondering about getting permissions both to create full projects and to promote your sandbox projects to full projects. I thought that now my first one was approved that I would be able to do this?

patrickd’s picture

Status: Needs review » Fixed

Your application got tagged with "Single project promote" what means that your project only gets promoted manually and you don't get a permission to promote on your own.

Usually we use this tag for modules with too few lines of hand-written code that can not be reviewed seriously.
In your case the problem is that this is a feature containing (as far I can see) none custom code.

This process is about reviewing the applicants coding skills for making sure that the applicant knows how to work with drupal's API in a correct and secure way.

I'm sorry this is probably disappointing for you, but you have to get through this process again with at least ~120 lines of custom code and ~5 custom functions, so we can make a serious review.

pixelsweatshop’s picture

That makes total sense. I have added something about this in the documentation, so others will know in the future. If you have a chance to review what I added to the docs for Applying for permission to create full projects (after #7) http://drupal.org/node/1011698

Note: Your project should include at least ~120 lines of custom code and ~5 custom functions to receive a proper review. This will help demonstrate your understanding of writing secure code, following the coding standards, generally following best practices and familiarity with proper usage of the Drupal APIs.

I am a themer/site builder and all I plan on contributing are themes and features. I would hate to clog up the, already overwhelmed, project review process with these every time though.

patrickd’s picture

Great,
then please consider to come back with a theme soon and we'll review it and make you a vetted user.
Surely this will again take some time, but we're tending not to do exceptions as this would not be fair to others, sorry.

See you then

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

Anonymous’s picture

Issue summary: View changes

changed branch