Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove many hardcoded lists of layers and sources #1161

Open
8 tasks
orangejulius opened this issue Jun 13, 2018 · 0 comments
Open
8 tasks

Remove many hardcoded lists of layers and sources #1161

orangejulius opened this issue Jun 13, 2018 · 0 comments

Comments

@orangejulius
Copy link
Member

orangejulius commented Jun 13, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant