CODEX

Behind the Scenes of The Forgotten Adapter in Geospatial

Applications of the Adapter Design Pattern in Geospatial

4 min readJan 29, 2021

Why are design patterns used?

The use of design patterns is to apply the design of common solutions to similar problems. They are not precise implementations of code but a template for the context of a given problem.

Avoiding repetition is not enough to explain why design patterns exist. The design patterns have the intent of reinforcing clear principles. Our interest is embedding those principles in our architecture.

To quote Uncle Bob, the goal is minimizing the effort to build and maintain our systems. We use design patterns with this goal in mind. To reach this goal, we also seek to delay decisions (see “Clean Architecture” by Bob Martin).

What are the principles design patterns reinforce? If you are curious, you can read on the SOLID principles:

Single responsibility
Open–closed
Liskov substitution
Interface segregation
Dependency inversion

The Challenges with Design Patterns

Learning and understanding design patterns are easy, reapplying them is harder. Finding the right design for a given context is tricky. Even when we recognize an opportunity for the pattern, we must adapt it to our needs.

My series on geospatial design patterns presents typical applications of common patterns. These concrete examples provide the introduction for exploring common design patterns.

Why should we use the adaptor design pattern in geospatial?

Many reasons justify the use of the adaptor design pattern. We may want to protect our code from changes outside of our control. We could fit many different data sources to a given problem. We could even avoid costly commitments to a specific implementation outside of our control.

The greatest complexity in geospatial is in our data. The algorithms are straightforward once we narrow it down to our use case. The complexity comes in developing a scalable solution with many sources of data. Many companies thrive off of combining data sources. They partner with data-generating organizations and create a centralized API. They can then sell access to the API. We can apply their same strategy in our development operations.

Geocoding Service Example

Geocoding is the simple process of associating coordinates with an input. The most common inputs being address and common names. For most address-management and mapping applications, our goal is retrieving those coordinates. It should be simple, but the geocoding landscape is far more complex than you would expect. Vendors use different ways of representing the precision or the confidence of the geocoding results. Some even have complicated terms and conditions (ToC) for storing data. There is no one-size-fits-all. The right solution for your needs is harder to find than you think.

Teams build their application around a commitment to a single vendor. As their application evolves, they rely more and more on their vendor's choices. With time, there will be a mismatch between the vendor and the team’s needs. The vendor could reap havoc by making unexpected changes to the API. A competitor could emerge as a preferred option. Making a switch can be costly when we have committed to the same vendor for years.

Using a single vendor could also be a missed opportunity. Justifications could be price optimization or developing a best-of-breed scenario using many vendors. The adapter pattern can help you avoid vendor lock-in.

Two different vendors are in the schema but we could use as many as we want.

We define the standard of our application with the geocode interface. Having a geocode interface brings stability to the other components of our application. The other components can rely on the interface knowing that we control the changes brought to it. The adapter (or wrapper) classes are an implementation of our geocode interface. They adapt the parameters of the interface to call the specific vendor method. In this case, both vendor geocoding methods use the same parameter: a single line address. Since vendors can change their API from each other, we define distinct wrappers.

Real Estate Data Example

Centralized real estate data is hard to access because of its proprietary nature. It is in the best interest of realtors to keep their information for themselves. They will only share their information to benefit their transactions. An entire business evolved to enable realtors to collaborate: “Multiple Listing Service” (MLS). For more information on the different MLS in Canada, you can visit this link.

Every organization does not follow the same conventions for their property data. Different standards have been created, the most recent being RESO. Not every realtor seems to conform to the standard.

We can use the adapter pattern to integrate different real estate data sources. The RESO standard could even be considered overkill for your mapping application. Having coordinates and a link for every property could suffice. The adapter reduces our vulnerability to new standards and changes to any APIs.