-
-
Notifications
You must be signed in to change notification settings - Fork 24
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
Better encapsulate logic for configuring admin lookup #52
Labels
Comments
orangejulius
added a commit
to pelias/openstreetmap
that referenced
this issue
Jun 10, 2016
The admin lookup stream code was incorrectly checking the wrong property, making it harder to enable admin lookup. Related: pelias/wof-admin-lookup#52 Fixes pelias/wof-admin-lookup#51
orangejulius
added a commit
to pelias/openstreetmap
that referenced
this issue
Jun 10, 2016
The admin lookup stream code was incorrectly checking the wrong property, making it harder to enable admin lookup. Thanks to @DylanFrese for helping us figure this out. Related: pelias/wof-admin-lookup#52 Fixes pelias/wof-admin-lookup#51
@dianashk also proposed a similar improvement to the interface in #48 (comment) |
Merged
This was fixed in #89 Creating an admin lookup stream for an importer is now as simple as
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, any importer that uses admin lookup has to make decisions about how exactly admin lookup is performed. For example we currently support admin-lookup via a local set of node processes, or a remote HTTP server.This can be configured in
pelias.json
, but checking the config settings is currently only done in the importers.While we definitely want to support different ways of doing admin lookup, figuring out which method to use, and setting it up, should be done within this module, so that importers don't need to care about it. Right now, a bit too much work has to be done by the code calling this module. For example, most of our importers have code similar to this right now:
Ideally the
var pipResolver
line could go away, and any configuration would be passed in without actually having to know as much about the module internals.Related: #51
The text was updated successfully, but these errors were encountered: