Mon Club Près de Chez Moi had a non-negotiable constraint: it needed to be live before the Olympics. Not “when it’s ready”, not “after a few iterations” — it had to ship on time, work first time, and scale.
The other constraint was less glamorous — but more common: the data was a mess.
We weren’t handed a neat, relational dataset with consistent naming, clean addresses, and one record per location. We were handed something closer to real life: ungrouped records, inconsistent structure, and “associations” that might represent one place or dozens of places depending on the entry.
So the job wasn’t “put points on a map”. The job was:
- convert chaotic inputs into a clean, queryable model
- represent association → multi-location relationships correctly
- ingest it into Woosmap in a way that is maintainable and scalable
- build a locator experience that still feels instant to users
Step one: accept the truth — data quality is product quality
For a locator, the map UI is only as good as the underlying data. If your records aren’t normalised, you end up with:
- duplicates and near-duplicates (“same club, slightly different name”)
- broken grouping (“association” split into several unrelated entries)
- missing geo, wrong geo, inconsistent addresses
- filters that don’t behave reliably because the taxonomy is noisy
We treated “data purification” as a first-class deliverable.
Step two: design a canonical model that matches reality
The key modelling insight was that associations and locations are not the same thing.
An association can have:
- one physical location
- several branches
- seasonal / secondary sites
- or a “parent entity” identity that should stay consistent even as locations change
So we defined a canonical structure that preserved association identity while correctly representing multiple locations beneath it — the difference between “who” and “where”.
Step three: transform into Woosmap assets (repeatably)
Once the model existed, we did the hard bit: turning the chaos into Woosmap-ready assets.
This meant building a transformation pipeline that could:
- clean and standardise fields (names, addresses, categories)
- deduplicate and merge records safely
- assign stable IDs so data could be updated without breaking references
- output assets in the shape Woosmap expects, at scale
The goal wasn’t a one-off import. It was something you can run again with confidence when the source data changes.
Step four: use Woosmap the way it’s meant to be used (not “demo code”)
A lot of locator builds “use” mapping tools the same way people “use” a gym membership: technically present, but not doing the work.
This project exploited the strengths of Woosmap JavaScript properly — and that required two kinds of expertise at once:
- strong JavaScript competence (because the UI behaviour matters)
- strong Woosmap knowledge (because the APIs have sharp edges and real power)
We leaned into Woosmap’s full suite: Stores, Distance, Geolocation, and Map JS — not as isolated features, but as one cohesive system.
Step five: build for “fast feel”, not just “fast enough”
With large datasets and real-world filters, performance is not optional. If the UI hesitates, users assume the site is broken.
So we engineered for fast feel:
- filters that respond immediately
- map updates that don’t stutter
- dense areas that remain navigable
- a UX that still makes sense even when there are “too many points”
The result
Under a hard public deadline, we delivered a locator platform that:
- cleans and structures messy data into maintainable assets
- represents associations and their multiple locations correctly
- uses Woosmap’s JavaScript tooling to its full potential
- stays fast and responsive even at scale
Shipping before the Olympics meant the solution had to be robust — not just clever. That’s what made this project prestigious: it wasn’t theory. It had to work in the real world, at the exact moment it mattered.
Leave a Reply