Skip to content

Remove many hardcoded lists of layers and sources #1161

@orangejulius

Description

@orangejulius

While the Pelias project has intended to support custom data from day one, in practice much of the code was written largely under the assumption that the number of possible layers (distinct types of records) was limited and unchanging.

Over time we've found cases where these assumptions, while once convenient and simple, prevent people from fully using Pelias with custom data.

We need to go through the API code looking for cases where lists of layers (and sources, to a lesser extent) are hardcoded, and figure out ways to make them more extensible.

Some general guidelines:

Assume there are lots of non-administrative area layers

Thsese should be essentially equivalent to venues but with additional semantic meaning. Transit stops is a good example here.

Move towards the list of administrative areas being configurable as well

This is harder because admin areas also generally imply a hierarchy (countries contain regions, for example). In the long run, we want to support this not just in the API but placeholder and the PIP service as well.

Allow addresses and streets to be a special case, to an extent

Addresses and streets are unique because they are part of well-formed postal addresses, so capturing that relationship and meaning is useful. However, our code often assumes that venues, streets, and addresses are the only non-administrative area layers, which isn't good going forward.

Consolidate as much as possible into configuration driven lists

We recently created the TypeMapping object, which is a great place to add any lists that must remain. All those lists should be configurable.

Known hardcoded lists

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions