profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jean-populus/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Jean Kao jean-populus @populus-ai San Francisco www.populus.ai Principal Product Manager @populus-ai

issue commentopenmobilityfoundation/mobility-data-specification

[Policy API] Ability to express data sharing requirements

The City and Provider Working Group Steering Committees met last week for the Midway Checkpoint for the 1.2.0 proposed release. The Checkpoint let them review feature proposals, align current work to goals, and ensure the release features and work is on track.

For this work, we have created a new rubric to help guide the evaluation, looking at feature utility, stakeholder adoption, implementation simplicity, direction consensus, and work completed as part of the evaluation criteria. The outcomes and actions from these discussions are summarized here:

Good utility and consensus on this, but not sure who will commit to adopting it yet, and the administrative implementation of this is mostly unknown.

Would need an effort up front from the OMF to get adoption and build tools/hosting for the new format. It won't replace paper work done now, but is a step in that direction. Good for agencies to do their homework and be clear about what parts of MDS they are requesting. Would help with discovery of what services by other agencies and providers/third parties and is good for transparency. There is a need for this but not necessarily urgency.

Actions: Get agencies/cities/providers on board to commit to using this once complete.

quicklywilliam

comment created time in 16 hours

issue commentopenmobilityfoundation/mobility-data-specification

Support for self-driving vehicles

The City and Provider Working Group Steering Committees met last week for the Midway Checkpoint for the 1.2.0 proposed release. The Checkpoint let them review feature proposals, align current work to goals, and ensure the release features and work is on track.

For this work, we have created a new rubric to help guide the evaluation, looking at feature utility, stakeholder adoption, implementation simplicity, direction consensus, and work completed as part of the evaluation criteria. The outcomes and actions from these discussions are summarized here:

Very good utility and adoption potential for this, as well as potential consensus on urgency and direction. Not sure of how much work is needed, how to implement, or how complex changes would be.

Actions: Create a “Community Group” (in the creation process by the OMF) to have the discussions needed, decide on a solution, and find stakeholders to commit.

jfh01

comment created time in 16 hours

issue commentopenmobilityfoundation/mobility-data-specification

Better indication of mobility type.

The City and Provider Working Group Steering Committees met last week for the Midway Checkpoint for the 1.2.0 proposed release. The Checkpoint let them review feature proposals, align current work to goals, and ensure the release features and work is on track.

For this work, we have created a new rubric to help guide the evaluation, looking at feature utility, stakeholder adoption, implementation simplicity, direction consensus, and work completed as part of the evaluation criteria. The outcomes and actions from these discussions are summarized here:

Very good utility and adoption potential for this, as well as potential consensus on urgency and direction. Not sure of how much work is needed, how to implement, or how complex changes would be.

Actions: Create a “Community Group” (in the creation process by the OMF) to have the discussions needed, decide on a solution, and find stakeholders to commit.

pomgod

comment created time in 16 hours

issue commentopenmobilityfoundation/mobility-data-specification

[Policy API] Add multi-modal support to Policy

The City and Provider Working Group Steering Committees met last week for the Midway Checkpoint for the 1.2.0 proposed release. The Checkpoint let them review feature proposals, align current work to goals, and ensure the release features and work is on track.

For this work, we have created a new rubric to help guide the evaluation, looking at feature utility, stakeholder adoption, implementation simplicity, direction consensus, and work completed as part of the evaluation criteria. The outcomes and actions from these discussions are summarized here:

Seems to be useful and relatively simple to implement, but there is no work done on this yet, so the solution is unclear. Need a bit more organization interested and committed to adopting.

Actions: Could be part of new self driving modes “Community Group” discussion, and would need to involve modal operators. Needs more details and a proposal and discussion. Ensure to stay synced with GBFS.

karcass

comment created time in 16 hours

issue commentopenmobilityfoundation/mobility-data-specification

[Provider API] - Include crash data as part of the `/status_changes` endpoint, `event_type` = `accident`

The City and Provider Working Group Steering Committees met last week for the Midway Checkpoint for the 1.2.0 proposed release. The Checkpoint let them review feature proposals, align current work to goals, and ensure the release features and work is on track.

For this work, we have created a new rubric to help guide the evaluation, looking at feature utility, stakeholder adoption, implementation simplicity, direction consensus, and work completed as part of the evaluation criteria. The outcomes and actions from these discussions are summarized here:

This proposal needs work across the board, since currently 3 options are proposed, and there is not agreement on implementation or how it would work, within MDS or from equipment/data available from providers. Agencies certainly would like this data, but people self report and it's not real time so data is minimal. What city would use the sensor data in a meaningful way and rely on it?

Actions: Create a clear proposal based on discussions and see if it's possible and multiple orgs can commit to it.

tybaltspark

comment created time in 16 hours

GollumEvent

issue openedopenmobilityfoundation/mobility-data-specification

Provider/Agency Stops - Feedback to move out of beta

Gather real world feedback to see how we can move the beta feature Stops out of beta.

Describe the solution you'd like

From the MDS Survey, about a third of agencies are using Stops, almost no providers are, and most companies support it. Moderate usage, but companies are supporting it well. We need feedback here from those that are using it to know what may need to change before it becomes a stable part of MDS.

Is this a breaking change

  • I'm not sure yet

Impacted Spec

For which spec is this feature being requested?

  • [provider](https://github.com/openmobilityfoundation/mobility-data-specification/tree/main/provider#stops)
  • [agency](https://github.com/openmobilityfoundation/mobility-data-specification/tree/main/agency#stops)

Describe alternatives you've considered

Leave as a beta feature for longer until we have feedback.

Additional context

Reviewed as part of the MDS 1.2.0 release review Midway Checkpoint by the Working Group Steering Committees.

created time in 16 hours

issue openedopenmobilityfoundation/mobility-data-specification

Provider Vehicles - Feedback to move out of beta

Gather real world feedback to see how we can move the beta feature Vehicles out of beta.

Describe the solution you'd like

From the MDS Survey, about half of agencies are using Vehicles, most providers are, and almost all companies support it. Seems to have good real world usage. We need feedback here from those that are using it to know what may need to change before it becomes a stable part of MDS.

Is this a breaking change

  • I'm not sure yet

Impacted Spec

For which spec is this feature being requested?

  • [provider](https://github.com/openmobilityfoundation/mobility-data-specification/tree/main/provider#vehicles)

Describe alternatives you've considered

Leave as a beta feature for longer until we have feedback.

Additional context

Reviewed as part of the MDS 1.2.0 release review Midway Checkpoint by the Working Group Steering Committees.

created time in 16 hours

GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent

issue commentNABSA/gbfs

License of data available in systems.csv

@mplsmitch Thank you for your comprehensive answer! It would definitely be useful because this is the data that you don't know if you can use :-) I will take part in the discussion in https://github.com/NABSA/gbfs/issues/249

bartoliniii

comment created time in 4 days

pull request commentNABSA/gbfs

For Spin, removed Rotterdam and updates links to new GBFS hostname

Of course! I think it would be important information in systems.csv file.

I've created topic for that - https://github.com/NABSA/gbfs/issues/309 There is also discussion about improvement of systems.csv - https://github.com/NABSA/gbfs/issues/249

dirkdk

comment created time in 4 days

pull request commentNABSA/gbfs

infos regarding terms and conditions added to system_information

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 60 days if no further activity occurs. Thank you for your contributions.

matt-wirtz

comment created time in 5 days

pull request commentNABSA/gbfs

For Spin, removed Rotterdam and updates links to new GBFS hostname

Hi @dirkdk I see that you have updated Spin data. I wonder what is license of this data? Can we used it in commercial app? Is there any "license" file available?

Thanks for any help!

let me get back to you on this, good question!

dirkdk

comment created time in 5 days

issue commentNABSA/gbfs

License of data available in systems.csv

Q: If any feed is published in systems.csv it means that it can by used by any app (e.g. mobility aggregator)?

A: No - inclusion in systems.csv does not imply any kind of license. You would need to check each feed for license information. Look at systems_information.json - license_url for the location of any license. Many feeds listed in systems.csv are either not licensed or do not publish license information. A lot of the feeds listed in systems.csv were added by the community, not by their publishers so systems.csv shouldn't be viewed as a source of truth - always look to the actual feed for information about the data.

Q: is there any "minimal" license restriction to publish feed url in systems.csv?

A: Currently there is not a licensing requirement for inclusion in systems.csv. Licensing info will be required in starting with v3.0 of the specification and we are considering whether it should be a requirement for inclusion in the systems catalog. Currently if it were required the systems catalog would be much smaller because so few feeds publish licensing info.

Q: if not, maybe it would be worth extending the system.csv file with license information (e.g. link or license type) in each record of new data? A: Inclusion of license info is one of the changes under consideration for the systems catalog. There's an open discussion in #249 about possible changes and improvements. It would be helpful if you could also add any additional thoughts you have to that issue.

Hope that helps

bartoliniii

comment created time in 5 days

issue openedNABSA/gbfs

License of data available in systems.csv

I'm looking information about license of GBFS feeds stored in systems.csv but unfortunately I didn't find such an information. So I have some questions:

  • If any feed is published in systems.csv it means that it can by used by any app (e.g. mobility aggregator)?
  • is there any "minimal" license restriction to publish feed url in systems.csv?
  • if not, maybe it would be worth extending the system.csv file with license information (e.g. link or license type) in each record of new data?

Thanks for any help and explanations!

created time in 5 days

pull request commentNABSA/gbfs

For Spin, removed Rotterdam and updates links to new GBFS hostname

Hi @dirkdk I see that you have updated Spin data. I wonder what is license of this data? Can we used it in commercial app? Is there any "license" file available?

Thanks for any help!

dirkdk

comment created time in 5 days

issue commentNABSA/gbfs

Enhance free_bike_status.json schema to add provider_name .

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 60 days if no further activity occurs. Thank you for your contributions.

ebebpl

comment created time in 6 days

issue openedNABSA/gbfs

irregularities in geofencing_zones.json

whoami

My name is Andrés Viesca and I am a software engineer at Dott, I have been working on implementing and maintaining Dott's GBFS service (gbfs.api.ridedott.com).

What is the issue and why is it an issue?

The current specification for geofencing_zones.json has some irregularities, which are an issue to me since they make the specification confusing:

  1. The fields described in geofencing_zones do not match its own example. a. Field geofencing_zones is indicated to be of type GeoJSON FeatureCollection, however in the example this is an array:

    {
      "geofencing_zones": [{...}]
    }
    

    b. The rules field is indicated to be of type Array, however in the example this is an object:

    {
      "geofencing_zones": [
        {
          "type":"FeatureCollection",
          "features": [
            {
              "type":"Feature",
              "geometry": {...},
              "properties" : {
                ...,
                "rules": {...}
              }
            }
          ]
        }
      ]
    }
    

    c. The rules field is indicated to be optional, however it holds two required fields: ride_allowed and ride_through_allowed. Are these only required if there is a rule present?

  2. The geofencing_zones' example does not include de common fields for all json files as indicated in the JSON Files Output Format, which are present in every other example.

Please describe some potential solutions you have considered (even if they aren’t related to GBFS).

The solution would be: For points 1.a and 1.b, Updating the example to accurately reflect what is stated in the geofencing_zones section.
For point 1.c, adding the necessary clarification (maybe in the filed description).

For point 2, adding the common JSON fields to the example.

Is your potential solution a breaking change?

  • [ ] Yes
  • [x] No
  • [ ] Unsure

The changes needed are only to make the specification consistent and clear for any consumer, it does not add, edit or remove fields or endopoints, therefore it is not a breaking change.

created time in 6 days

GollumEvent
GollumEvent
GollumEvent
GollumEvent

issue commentopenmobilityfoundation/mobility-data-specification

[Policy API] support utilization policies

@avatarneil and @karcass Could you take a look at this, like you mentioned on the WG call last week? Thank you.

jean-populus

comment created time in 8 days

issue commentopenmobilityfoundation/mobility-data-specification

[Policy API] support vehicle distribution by %

@karcass @avatarneil Could you all add an example of how it may be possible to do this with Policy now? And if it's not possible, an idea of what it would take to support this?

The Metrics methodology may also benefit from a standard way to calculate this.

jean-populus

comment created time in 8 days

GollumEvent

push eventNABSA/gbfs

Dirk de Kok

commit sha 3b11b713402d9532147c969eebc636acf892ab9c

for Spin, removed Rotterdam and updates links to new gbfs host (#307)

view details

push time in 8 days