-
Notifications
You must be signed in to change notification settings - Fork 14
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
Jdh/update docs #155
Jdh/update docs #155
Conversation
…to geofences, removed config/doc references to demand forecast files
Hmm, looks like some of our unit tests are still reliant on the Denver demand forecast files. I can update the unit tests or restore the demand forecast files. Let me know what you prefer. I also noticed references to demand forecast files in both |
I think it would make sense to remove the demand forecast file from the input config at the very least. I would also be open to pulling out the forecaster module but that could be deferred. |
right. in general, i think this is the strategy:
for today, we could probably target the least amount of refactoring to get the tests working again, and make it a future task to really clean up all references to forecasting. does that sound right? forecasting is a useful thingie but it really shouldn't be hive's problem. it can instead just a property of a custom InstructionGenerator to load and incorporate any forecasting. |
…ile from mock config in mock lobster, removed default forecast file key pair in default hive config
Alright, this should be ready for review. I've left the forecaster module alone, but I've removed note: I've left one reference to the demand forecast file and geofence in the example log outputs in the README. I figured we should just update the entire log and that we can have that be a good first issue for someone at pycon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good. thanks for removing those references, they can be distracting when we are introducing people to the model. as for geofence, i have this idea that we could come back to geofences as a special case of fleet id generation (a membership relationship is another way of describing geofencing and probably faster to compute under-the-hood too).
ok pycon's gonna be a party now fo sho!
This PR contains the following:
Looks like this also closes #111
If there are any additional changes to the docs that we think would be beneficial, please let me know!