Drupal Geofield for store finders and facility maps
Geofield stores geographic data for maps, geocoding and location features on a Drupal site, and it supports points, lines, polygons and multi-geometries. According to its Drupal.org project page, the 10.3.4 release supports Drupal ^10.3, ^11 and ^12, so the module fits a store finder, facility directory or event map built on a current Drupal version. Teams usually adopt it when they need editors to place locations on a map without manual coordinate entry, and when visitors need to find the nearest location or browse locations within an area. A partner earns its place when the location model spans several content types, when locations must be imported or geocoded in bulk, or when the map has to work under accessibility and hosting constraints that the team has not tested before.
Geofield is a contributed module licensed under GPL-2.0-or-later, so there is no license fee for the module itself, and the cost of a location feature sits in the planning, configuration and build work around it. DeployOpen plans and builds these features inside the client's own infrastructure, whether that is their cloud accounts, data centers or air-gapped networks, so location records and any geocoding requests follow the client's data handling rules. Before work starts, confirm with your team which geocoding service will be used, whether it may receive addresses from your environment, and who will maintain the API keys and usage limits. Those answers decide much of the architecture and should be written into the scope before a quote is agreed.
What Geofield does on a Drupal site
Geofield adds geographic field types to Drupal entities, so location data sits alongside the rest of your content. Each card below covers one part of that job and the gap a team has to close before a store finder or facility map works in production.
Storing points, lines and polygons
Geofield stores points, lines, polygons and multi-geometries on Drupal entities. A store finder usually needs only points, while a service area or delivery zone needs polygons. Decide the geometry types per content type before editors start entering data, because changing a field's geometry later means reviewing existing records. Confirm in the module documentation how each geometry type is saved and how it appears in the entity edit form.
Geocoding and location features
Geofield supports geocoding and location features, but it does not decide where coordinates come from. Editors can type coordinates by hand, which is error-prone for large directories, or a geocoding service can fill them in during import or save. Choose the geocoder, confirm its usage terms and rate limits with the provider, and decide who corrects a wrong address. Test with a sample of your real addresses, including rural and multi-unit sites.
Feeding map display
Geofield provides the stored coordinates, but the map itself comes from a separate choice of display formatter or map library. Confirm which map renderers and formatters the current Geofield release supports, and whether they load third-party tile or basemap services. Those services have their own licensing and data protection implications that your legal and privacy teams should review before launch.
Working with Drupal entity fields
Geofield behaves as a Drupal field type, so it works with content types, taxonomy terms and other entities, as well as with views, field formatters and the entity API. This keeps location data inside your content model and access rules. Plan which entities carry location data, how editors filter them in the admin interface, and whether any location fields must be restricted to specific roles.
Compatibility with Drupal 10.3 and later
The Geofield 10.3.4 release supports Drupal ^10.3, ^11 and ^12. Sites on Drupal 10.2 or earlier need a core upgrade before they can use this release, which affects project planning. Check the compatibility line of the release you install, then review it again before each Drupal core upgrade, since a module version that works today may need an update for a later major version.
Pairing with Search API for proximity queries
Geofield stores coordinates but does not, on its own, answer the question "which locations are within 10 kilometers of this postcode". Proximity search needs a Search API index with a geospatial backend or a distance-capable query, plus a way to pass the visitor's location into the query. Confirm with the module documentation which search backend supports distance sorting, and test the result order and performance with your full dataset.
Which geometry, geocoder and map renderer to choose
This table compares the main decisions for a Geofield location build: geometry type, when to geocode, where coordinates come from and how maps are rendered. Read each row for when the option fits, what data it needs and what it commits your team to operating. The main takeaway is that the geocoding and rendering choices carry licensing and hosting consequences that should be confirmed before the content model is locked.
| Decision | Choose when | Data and operational consequence |
|---|---|---|
| Point only | Store finders, branch directories and single-location event venues where a pin is enough | One latitude and longitude per entity. Simple to query and index. Service areas cannot be represented, so a separate field or model is needed for them. |
| Lines and polygons for service areas | Delivery zones, catchment areas, sales territories or routes must be shown or tested against a visitor location | Geofield supports polygons and multi-geometries. Expect larger geometry data, more careful data entry or import, and point-in-polygon logic that must be tested with edge cases. |
| Geocode at entry | Editors enter addresses one at a time and need the pin confirmed before publishing | Requires a geocoder call on save, so provider terms, rate limits and error handling apply to every edit. Store the source address and the returned coordinates together so results can be re-checked. |
| Geocode in batch import | Large directories or facility lists arrive from a spreadsheet or feed and can be geocoded once | Runs as a scheduled or queued job. Plan retries, a review queue for unmatched addresses and a way to rerun only failed rows. Costs are driven by request volume, so confirm provider pricing for bulk use. |
| Third-party geocoding service | Addresses change often or you need reliable address matching across many countries | Ongoing dependency on an external API, with terms covering caching, storage and display of results. Confirm each provider's terms, quotas and data residency with that provider before committing. |
| Stored coordinates only | Locations are fixed and seldom change, or your data governance does not allow external lookups | Coordinates are entered or imported once and owned by you. No recurring geocoding fees from this part, but coordinate accuracy depends on the source and needs periodic checks. |
| Client-side map renderer (Leaflet-style) | Visitors need pan, zoom, filters and clickable markers on the page | Map tiles and libraries load in the browser, so accessibility of markers, keyboard control and tile provider terms must be tested. Check which tile provider you use and its usage conditions. |
| Server-generated static image | Maps appear in print, email or low-JavaScript pages, or the list of locations is short | Images are cached and rebuilt when locations change, so cache purging and image generation load must be planned. Interaction is limited, and map images are not searchable. |
How a location build runs from data model to launch
The sequence moves from a agreed location data model to a launched store finder, directory or event map that editors can maintain. Each step produces a artifact the next one depends on, so decisions about geometry, geocoding and indexing are settled before records are loaded or screens are built.
Define the location content type and fields
The team agrees the content type that represents a location, such as a branch, facility, venue or event, and its field set: name, address parts, contact details, opening hours, categories and any editorial fields. DeployOpen writes this as a field specification that lists each field's type, whether it is required, who edits it and which views and search indexes will read it. The step is done when the client signs off the specification and no field is left without an owner.
Choose geometry types for each location
Each record is assigned the geometry it needs: a single point for most store finders and facilities, a line for routes or transit segments, or a polygon for service areas and districts. Geofield supports points, lines, polygons and multi-geometries, so the decision is about what the map must draw and what proximity queries must answer, not about what the module can store. The output is a short geometry decision table that is added to the field specification.
Select geocoding and map rendering approach
The team chooses how addresses become coordinates (entered by editors, geocoded on save through a provider, imported from source data, or a mix) and which map library and tile provider will draw them. Each choice has licensing, usage limits, data residency and cost terms that must be confirmed with the provider before build, because they recur after launch. The output is a geocoding rule set covering when geocoding runs, what happens when it fails, and who corrects coordinates by hand.
Load and clean existing location records
Existing directories, spreadsheets or legacy databases are mapped to the new fields, deduplicated, and checked for missing or malformed addresses and coordinates. Records that cannot be geocoded are flagged for manual review instead of being imported with guessed positions. The output is a cleaned import file, a mapping document and a list of exceptions with an owner for each one.
Configure Search API indexing and proximity sorting
A Search API index is defined over the location content type, including the geofield, the text and facet fields, and the sort or distance calculation used for nearest-first results. The backend is chosen and tested for geospatial support, since a Solr or database backend may behave differently for distance sorting and filtering. The output is an index definition, a set of example proximity queries with expected results, and a reindexing procedure.
Build map and list views with accessibility checks
The map view, the result list and the filter controls are built together so that a keyboard user and a screen reader user reach the same results as a mouse user. Marker popups, list ordering, focus handling and color contrast are reviewed against the accessibility requirements the client has agreed. The step is complete when the views pass the checks written into the test plan and a reviewer confirms the list and map show the same results.
Test on representative records
The build is tested on a representative data set that includes dense urban clusters, rural records far from others, records at the edges of the service area, duplicates, missing coordinates and multi-geometry shapes. Each test case records the input, the expected position, distance ordering and rendering result. The output is a signed test log with defects logged, fixed and retested before launch.
Launch and hand over the runbook
The site is released, the index is built on production data, and geocoding and import jobs are switched to their agreed schedule. DeployOpen hands over a runbook that covers reindexing, correcting coordinates, adding a location type, rotating map and geocoding API keys, and checking indexing after Drupal or Geofield updates. The step is done when the client's editors complete a supervised record change and the owners of each runbook task confirm they can perform it.
How proximity search runs through Search API
Proximity search is a sequence of four steps, and each one needs a decision before the build starts. A visitor enters a place name or postcode, or the browser supplies coordinates. If the input is text, the site geocodes it to a latitude and longitude using the geocoder the team has chosen, and the result is held for the query. Search API then takes that point and asks the index for items whose indexed geofield lies within a radius or is nearest to it. Results come back sorted by distance, and the view renders the distance alongside each record. Geocoding is the step most often left unowned, so decide who pays for the geocoding calls, where results are cached, and what happens when a lookup returns nothing.
The index is the part that determines whether distance sorting works at all. With the database backend, Search API stores indexed values in the Drupal database, so the team must confirm that the Search API and Geofield combination supports the distance and sort operations the finder needs on that backend, and test them with real coordinates before committing to the design. With an Apache Solr backend, the location field is stored in Solr and distance queries run there, which usually suits larger directories, but the team must confirm the Solr server version, the Search API Solr connector and the field type mapping for points. Ask the implementation partner to show a working radius query and a sorted result set on the chosen backend in a staging environment.
Verification should cover the edges of the flow rather than only the happy path. Test a postcode that geocodes to the wrong country, a browser that denies location access, a point with missing coordinates in the index, and a radius that returns zero results. Confirm that the index is rebuilt or updated when facility coordinates change, because stale points produce confidently wrong distances. Record which geocoding service, index backend and Geofield version were used in the runbook, since any of them can change during upgrades. Drupal's own version support is covered in the upgrade notes, so here the key check is that the query, the index and the renderer agree on the same coordinate system and units.
What drives effort and cost on a location project
This table compares the main drivers of effort on a Drupal location project with Geofield, with the direction each one moves cost and the scope items to request. Read each row as a question to settle before quoting, since most overruns start with source data and geocoding decisions made late.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number and quality of source records | Every record needs coordinates, and incomplete or inconsistent addresses add manual review, cleansing rules and exception handling. Cleansing is usually the largest variable line item. | Profile the export before quoting, agree required fields and a canonical address format, and decide who corrects bad records before import. |
| Geocoding need and provider terms | Records with only addresses need a geocoding step. Provider licensing, rate limits and whether results may be stored or cached change both the build and the recurring bill. | Ask whether source files already contain coordinates, confirm provider terms in writing, and cache results so each address is geocoded once. |
| Geometry complexity (points versus polygons) | Point data is the simplest case. Service areas, catchments and boundaries as polygons or multi-geometries need more validation, storage decisions and map styling. | Store only the geometry types the features need, and use points for facilities unless coverage or boundary logic is a stated requirement. |
| Map and list accessibility | An accessible map needs keyboard operation, text alternatives for markers, and a synchronized list view. Custom map interactions add testing effort against accessibility criteria. | Specify an accessible list or table as the primary result view, and require the map to be a progressive enhancement on top of it. |
| Backend choice for proximity search | Radius and nearest-first queries depend on the search backend. Solr or another engine needs hosting and index design, while database-backed search has narrower geographic query options. | Decide the backend at scoping, confirm which distance queries it supports, and size hosting for the index separately from the Drupal site. |
| Number of data sources to migrate | Each source has its own field mapping, deduplication rules and reconciliation checks. Merging directories from several systems often takes more effort than the map itself. | Rank sources by value, migrate the authoritative one first, and set a rule for conflicts between sources before mapping begins. |
| Integrations with CRM or ERP | Syncing locations, opening hours or events with a CRM or ERP adds authentication, error handling, retries and ownership questions about which system holds the record. | Name the system of record for each field, limit the first release to one-way sync where possible, and document failure handling in the scope. |
| Testing and acceptance | Map behavior varies by browser, device and data volume. Test effort rises with the number of record types, filters and geographic edge cases such as records at boundaries. | Agree a test data set with real edge cases, a defined browser and device list, and acceptance criteria written against the sample records. |
Questions buyers ask before hiring help with Drupal maps
Does Geofield cost anything to license?
No. Geofield is an open-source contributed module for Drupal, and Drupal and contributed modules hosted on Drupal.org are licensed under GPL-2.0-or-later, so there is no license fee for the module itself. The costs that do recur sit elsewhere: a geocoding provider may charge per request or per volume, the map tiles or map service may have usage terms, and hosting, backups and maintenance continue every year. Ask a partner for a quote that lists each third-party service separately, with its pricing model and who holds the account and API keys.
How long does a Drupal store finder take to build?
It depends on the data and the scope, and no fixed duration applies to every project. The main drivers are how clean the existing location records are, how many content types and fields carry locations, whether geocoding runs on import or by editors, which map and search features are required, and how many integrations feed the data. Your partner should state the duration in the written scope, with milestones for data import, map rendering, proximity search and acceptance testing. Confirm which of these are included before work starts.
Can our own team build a store finder without a partner?
Yes, if your team has Drupal development skills and time to learn Geofield, a geocoding service and a map library. Configuring Geofield fields and displaying points in a basic view is a manageable task for an experienced Drupal developer. The harder parts are usually data cleanup, reliable geocoding at volume, proximity queries that perform well, accessibility of the map interface, and keeping all of it working through Drupal upgrades. A partner is worth considering when those parts carry real risk, or when the team needs the work finished on a fixed schedule.
What do we need to provide for a map project?
The project needs named data owners who can answer questions about each location field, a representative sample of records including messy or incomplete entries, the rules for which fields are public, and a decision-maker who signs off on the map design, search behavior and test results. Provide access to a staging environment, the geocoding account decision, and any existing spreadsheets or feeds. Agree on who approves data corrections, because most delays come from waiting on answers about addresses, opening hours or service boundaries rather than from the code.
Do we need Solr to run proximity search?
No. Proximity search can be built with Search API on a database backend for smaller datasets, but Solr is a common choice when the directory is large, when the search combines distance with facets and full-text terms, or when response times under heavy traffic matter. Confirm the expected record count, query volume and filter combinations before choosing. Hosting Solr adds a separate service to patch, back up and monitor, so the decision should follow the requirements rather than default to the larger stack.
How do Geofield upgrades work with Drupal 11 and 12?
Geofield's 10.3.4 release supports Drupal ^10.3, ^11 and ^12, so the module is already declared compatible with the current and next major versions. Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026. Plan upgrades by checking the Geofield release notes, running the Upgrade Status audit, testing map rendering and geocoding in staging, and confirming that the PHP version meets the requirement (PHP 8.3 or later for Drupal 11 and PHP 8.5 or later for Drupal 12).
How do we protect location data and visitor privacy?
Start by classifying each location field. Business addresses for public outlets are usually public, but personal addresses, staff home locations or the device locations of visitors need stricter handling. Limit who can edit coordinates, avoid storing precise locations that the public does not need, and check what the map or geocoding provider receives in each request. Review the provider's data processing terms with your privacy team, and record the decisions so an auditor or regulator can see how the data is handled. The Drupal Security Team publishes advisories for Drupal and contributed projects, so subscribe your team to them.
Connecting location data to the rest of the platform
A location record rarely lives alone. Store finders, facility directories and event maps depend on search, forms, master data, geocoding, imports and editor sign-in working together. Each card below names one connection, the decision it forces and what to verify before the build starts.
Search API and Solr for proximity and facets
Proximity queries and map-bound filters run against an index, not directly against the Geofield column. Decide early whether the search backend can sort and filter by distance, and whether the index holds the coordinates in a form your chosen backend understands. Confirm the exact proximity options your Search API backend supports, and test them with real store counts and radius ranges before committing to the index design.
Commerce and Webform for capture
Store locators often start with a product or order record that already carries an address, and event maps start with a registration form. Decide which system owns the address at capture time and whether the location is written to a Geofield field on submission or geocoded later. Validate how Webform or Commerce submissions map to the location fields, including partial addresses and users who skip the map pin.
CRM or ERP as the source of truth
If a facility register or branch list already lives in an ERP or CRM, Drupal should consume it rather than become a second master. Decide which fields are edited in Drupal, which are synced back, and how deleted or renamed locations are handled. Ask the source system owner for the field definitions, change frequency and any coordinates they already hold, because stored coordinates may be stale or in a different reference system.
External geocoding APIs
Geocoding converts street addresses into coordinates, and the provider choice carries licensing, rate limits, data retention and cost terms. Decide whether geocoding runs at save time, in a queue, or as a batch job, and whether results are cached. Confirm the provider's terms for storing returned coordinates and whether your organization can send addresses to a third party, especially for public sector or health data.
Migrate or Feeds for imports
Initial loads of thousands of locations and recurring updates from spreadsheets or feeds call for different tools. The core Migrate API suits one-time moves with mapping rules you can version, while Feeds suits scheduled imports edited by staff. Decide which pattern fits each source, how duplicates are matched on address or external ID, and how coordinates are validated after each run. Ask for a dry-run report before any import touches production data.
SSO for editor access
Regional managers and location owners often need to edit only their own records, and that access must follow the identity provider's groups. Decide whether editors sign in through SAML or OpenID Connect, how roles map from identity groups to Drupal roles, and who removes access when someone leaves. The SAML Authentication module and OpenID Connect module both create accounts on sign-in, so confirm how deprovisioning and role assignment will work before go-live.
How DeployOpen scopes and delivers Drupal location builds
DeployOpen plans, builds, tests and documents Drupal location features inside your own infrastructure, from the geofield data model through map rendering and proximity search. Engagements are fixed-scope, so the written scope defines what Geofield fields, geocoding and search work will be delivered before any build starts.
How we scope
- Inventory every location dataset, its source, owner and expected update frequency before choosing field types.
- Agree in writing which geometries are stored, such as points for facilities or polygons for service areas.
- Define geocoding ownership, including who pays for lookups, where API keys live and how failed addresses are handled.
- Record the map renderer, proximity search backend and hosting constraints so the quote reflects real delivery work.
How we build
- Model location fields and content types in configuration so editors and developers can review changes in version control.
- Build import and geocoding routines that can be rerun safely, with logging for records that could not be located.
- Configure Search API indexes for distance-based queries and test result ordering against known sample locations.
- Test map rendering in the browsers and devices your audience uses, including keyboard access to markers and filters.
How we hand over
- Deliver a written record of field definitions, index settings, geocoding rules and the data import procedure.
- Walk your editors and site administrators through adding and correcting locations, with the steps documented for reuse.
- Provide a checklist for Drupal core and Geofield upgrades, including a test pass on map and proximity features.
- Hand over credentials, environment settings and access lists through your own secrets process, not through email.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the build is live.
- Monitor geocoding quota use, failed lookups and search index health against the targets set in the scope.
- Plan Drupal core and contributed module updates around the monthly bugfix and third-Wednesday security release windows.
- Confirm with your team which support tier covers map provider changes, data refreshes and new location types.
