Examples of Python C extensions that work on Python 2 and 3
Software Carpentry Workshop at SciPy 2015
jiffyclub/dc-python-meetup-nov-2012 14
Material for the Number Crunching in Python workshop.
jiffyclub/2015-03-18-sfpython-project-night 5
LBL Lab Day 2014
ivanov/ipython-trainingwheels 4
A beginner student friendly profile for IPython notebook
LBL Lab Day 2014
Advent of Code
Pull request review commentopenmobilityfoundation/mobility-data-specification
If a vehicle is matched with a rule, then it _will not_ be considered in the sub The internal mechanics of ordering are up to the Policy editing and hosting software. +[Top][toc]++### Requirement++The agency Policy Requirement file ennumerates all of the parts of MDS that an agency requires from providers, including APIs, endpoints, and optional fields, as well as information for providers about the APIs the agency is hosting. The requirements are specific to the needs and use cases of each agency, and ensures there is clarity on what data is being asked for in operating policy documents from providers, reducing the burden on both. This also allows additional public transparency and accountability around data requirements from agencies, and encourages privacy by allowing agencies to ask for only the data they need.++This endpoint it not authenicated (ie. public), and allows the discovery of other public APIs like Geography, Policy, and Jurisdiction. The agency can host this as a file or API on their servers, on a third party server, or the OMF can host on behalf of an agency in the [agency requirements repo](#). See this [hosting guidance document](#) for more information. This requirements file can be [referenced directly](https://github.com/openmobilityfoundation/governance/blob/main/technical/OMF-MDS-Policy-Language-Guidance.md) in an agency's operating permit/policy document when discussing program data requirements.++See [Policy Requierment Examples](/policy/examples/requirements.md) for how this can be implemented.++An agency's [Requirements](#requirements) endpoint contains a number of distinct parts, namely [metadata](#requirement-metadata) and [MDS version](#requirement-mds-version) (with sub sections on applicable providers and relevant [MDS APIs](#requirement-mds-apis)). ++```jsonc+{+ "metadata": {+ // metadata fields per the "Requirement Metadata" section+ },+ "mds_versions" [ + {+ "version" : "[MDS VERSION NUMBER]",+ "provider_ids": [+ // provider id array+ ],+ "mds_apis": [+ {+ "api_name" : "[MDS API]": {+ // MDS endpoints, urls, optional fields+ }+ },+ // other MDS APIs per the "Requirement MDS APIs" section+ ]+ }, + // other MDS versions per the "Requriement MDS Version" section+ }+}+```+[Top][toc]++#### Requirement Metadata++Contains metadata applicable to the agency and at the top of its [Requirement](#requirement) data feed in the `metadata` section. ++| Name | Type | Required / Optional | Description |+| ---------------------------- | --------------- | -------- | ----------------------------------- |+| `mds_release` | text | Required | Release of MDS that the requirements data feed aligns to, based on official MDS releases. E.g. "1.2.0" |+| `version` | integer | Required | Version of this file. Increment 1 with each modification. E.g. "3" |+| `last_updated` | [timestamp][ts] | Required | When this file `version` was last updated. E.g. "1611958740" |+| `max_update_frequency` | integer | Required | The expected maximum frequency with which this file could be updated. E.g. "P1D" |+| `omf_review` | Enum | Required | yes/no. Was this file reviewed by OMF Staff for accuracy? E.g. "yes" |+| `omf_review_date` | [timestamp][ts] | Optional | If `omf_review`, add timestamp. E.g. "1611958749" |+| `agency_uuid` | UUID | Required | UUID of the agency this file applies to. Must come from [agencies.csv](/agencies.csv) file. E.g. "737a9c62-c0cb-4c93-be43-271d21b784b5" |+| `agency_name` | text | Required | Name of the agency this file applies to. E.g. "Louisville Metro" |+| `agency_time_zone` | text | Required | Timezone used for dates and times across all MDS endpoints. E.g. "America/New_York" |+| `agency_currency` | text | Required | Currency used for all monetary values across all MDS endpoints. E.g. "USD" |+| `agency_policy_website_url` | URL | Required | URL of the agency's transportation policy page. E.g. "https://www.cityname.gov/transporation/shared-devices.htm" |+| `agency_policy_document_url` | URL | Optional | URL of the agency's operating permit rules that mention data requirements. E.g. "https://www.cityname.gov/mds_data_policy.pdf" |+| `gbfs_required` | Enum | Required | yes/no. Is public GBFS required explicitly by providers? E.g. "yes" |+| `url` | URL | Required | URL of this file. E.g. "https://mds.cityname.gov/requirements/1.2.0" |++[Top][toc]++#### Requirement MDS Version++Contains a list of providers and APIs/endpoints/fields that a version of MDS applies to in its [Requirement](#requirement) data feed. Unique combinations for MDS versions and specific providers can be defined. For example an agency can devine MDS version 1.2.0 for Provider #1 in a pilot with beta endpoints and optional fields, version 1.2.0 for other providers without beta features, and version 1.1.0 for Provider #2 with docked bikeshare. ++```jsonc+// ... + "mds_versions": [+ {+ "version" : "[MDS VERSION NUMBER]",+ "provider_ids": [+ "[PROVIDER UUID]",+ "[PROVIDER UUID]"+ ],+ "mds_apis" [+ {+ // ...+ },+ // other MDS APIs+ ]+ }+ ]+// ...+```++| Name | Type | Required / Optional | Description | +| ---------------------------- | -------------- | -------- | ----------------------------------- | +| `version` | text | Required | Version number of an official MDS release | +| `provider_ids` | UUID[] | Required | Array of providers that apply to this part of the requirements | ++[Top][toc]++#### Requirement MDS APIs++For each combination of MDS version and provider list, you can specify the MDS APIs, endpoints, and optional fields that are required per your agency's policy. This is an array within the [Requirement MDS Version](#requirement-mds-version) `mds_apis` section in the [Requirement](#requirement) data feed.
I think SLA should wait for a future version of this, so let's put a pin in it. I did add vehicle_types here so you can optionally specify an array of types that apply to the specific version and providers in question. Does this solve your mode idea?
comment created time in 6 hours
push eventopenmobilityfoundation/mobility-data-specification
commit sha 6c6a89d7ed24f220eaa6607caf0efcd7a853aa4e
Added optional vehicle types
push time in 6 hours
push eventopenmobilityfoundation/mobility-data-specification
commit sha eb0a6eb80e60e8c66026386e01f6a1b6a9f1f3d9
Updated link to Policy section
push time in 7 hours
startedjiffyclub/snakeviz
started time in 8 hours
startedjiffyclub/snakeviz
started time in 9 hours
startedjiffyclub/scipy-2021-intro-to-python
started time in 20 hours
issue commentActivitySim/activitysim
I think this might be issue #392, which I think is just a holdover from CT-RAMP. The line of interest is here. @esanchez01 - I think you mean trip_purpose.py instead of simulate.py above?
Yes, trip_purpose.py. This does seem to be the same issue you referenced. Thanks!
comment created time in a day
issue commentActivitySim/activitysim
I think this might be issue #392, which I think is just a holdover from CT-RAMP. The line of interest is here.
comment created time in a day
issue commentActivitySim/activitysim
@bstabler, on an at-work tour, should the first outbound trip purpose set to a 'real' purpose such as eat out, recreational, etc instead of at-work?
comment created time in a day
issue commentActivitySim/activitysim
@esanchez01 , what is the outbound purpose of this at-work tour example?
The overall tour purpose is atwork. The first outbound trip purpose appears to always be atwork. The inbound trip purpose is then Work as described above.
comment created time in a day
issue commentActivitySim/activitysim
@esanchez01 , what is the outbound purpose of this at-work tour example?
comment created time in a day
issue openedActivitySim/activitysim
While summarizing the SANDAG 3 Zone example outputs, we noticed that both a work and Work trip purpose existed. After investigating, it appears that Work trips are strictly inbound at-work sub-tour trips with a workplace destination -- this is enforced in simulate.py.
With that said, should the purpose instead be work so that it is consistent with other work trips? If it was intentionally named Work to differentiate these trips from non-at-work sub-tour trips, would it make sense to rename this purpose to a name that makes its difference to 'normal' work trips more explicit? Otherwise, Work trips could be interpreted as additional work trips or possibly duplicates.
created time in a day
issue closedActivitySim/activitysim
GitHub Permissions for WSP Team
The following users need privileges in GitHub for Phase 6B.
- @danielsclint (Clint Daniels): Appropriate permissions to address and merge Pull Request and assign issues
- @billyc (Billy Charlton): Appropriate permissions to update Wiki / potentially merge pull request and assign issues
- @e-lo (Elizabeth Sall): Appropriate permissions to address and merge Pull Request and assign issues
- @ddorinson (Diana Dorinson): Appropriate permissions to update Wiki
At this point in time, the rest of the WSP contributors will issue PR to the ActivitySim repo.
closed time in a day
danielsclintissue commentActivitySim/activitysim
GitHub Permissions for WSP Team
I granted everyone write access. Thanks.
comment created time in a day
issue openedActivitySim/activitysim
GitHub Permissions for WSP Team
The following users need privileges in GitHub for Phase 6B.
- @danielsclint (Clint Daniels): Appropriate permissions to address and merge Pull Request
- @billyc (Billy Charlton): Appropriate permissions to update Wiki / potentially merge pull request
- @e-lo (Elizabeth Sall): Appropriate permissions to address and merge Pull Request
- @ddorinson (Diana Dorinson): Appropriate permissions to update Wiki
At this point in time, the rest of the WSP contributors will issue PR to the ActivitySim repo.
created time in a day