You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
api/query/reverse.js
Line 43 in c69a960
The text was updated successfully, but these errors were encountered: