-
Notifications
You must be signed in to change notification settings - Fork 232
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
Qualitative description of device position: surface location type #767
Comments
Are you thinking this optional field will be sent by the providers if they know the value? How many providers can know this now? Do we anticipate more in the future? It would be nice to have some providers chime and say this is possible and that they would implement it. |
@dirkdk would you like to comment here? |
We at Spin know for certain vehicles equipped with more advanced IoT devices what type of surface the vehicle is on yes. Examples are |
I believe this is possible now, especially with extra tech provided by companies like Drover which can detect in real time and at the edge if a rider is on a streets, sidewalk, bike lane, crosswalk, parking garage, etc. A location_type enum could be added to both Agency and Provider, keeping up with #759 symmetry. |
Bringing this back up, is this an optional field that stands a chance of making it within MDS 2.0 ? It is a minor addition, and an optional field so I don't expect it would cause some challenge. |
Yes we could add this, but need more details from you or Drover or others who have this ability. We need an enumerated list of the kinds of surface types possible, and ideas on where it could be added to the speck (eg every telemetry point?). |
If we would like this in MDS 2.0, we need some feedback and suggestions to make it happen. It affects some of the #506 work based on how it should be added to telemetry points. |
As of today, we know from our partnership with Drover that the surface type can take the following values:
I expect this to cover the needs for the whole of the micromobility needs for now. @marie-x maybe that can be used as a base to define the values this field can take, and could easily be enriched moving forward. Let me know your thoughts. |
Drover AI’s product, PathPilot, has had this capability since 2020. Specifically, it has the capability to identify the infrastructure being ridden on while the vehicle is being ridden above a predetermined speed (ex 4 mph). We propose to add an optional field “location_type” to every telemetry point.
Currently, we support the above values. In the future, we could add more to the enum. |
I support this - the PR should be downstream of the Agency/Provider unification work. Would you like me to do that? |
@marie-x once you get the A/P work draft done and we merge to dev, then someone could do that PR. |
Please review the new
|
Complete with #829. |
Is your feature request related to a problem? Please describe.
GPS positioning is great but don't carry any qualitative assessment of the position of a device. For instance, receiving the location (34.0205834, -118.4876028) allows placing a device in downtown SaMO. However, we don't know if a device is located in a street, on a sidewalk, in a parking bay etc....
Describe the solution you'd like
We propose to add an optional location_type field to the /telemetries to give additional qualitative information regarding the precise location of a device.
The location_type field would be of Enum type with a list of predefined possible location types:
Bike lane
Crosswalk
Garage
Invalid
Side
Street
Possibly adding parking bay
Is this a breaking change
Impacted Spec
For which spec is this feature being requested?
agency
Describe alternatives you've considered
This seems to be the implementation with the least impact
Additional context
The text was updated successfully, but these errors were encountered: