Adding vehicle icons & brand information

[mplsmitch]

What problem does your proposal solve? Please begin with the relevant issue number. If there is no existing issue, please also describe alternative solutions you have considered.

Currently the specification lacks any type of branding assets or ways to graphically represent vehicles. Some consuming applications have expressed a need for Icons and/or other brand related information to represent the mobility services that they aggregate.

What is the proposal?

This proposal adds fields to system_information.json and vehicle_types.json to support brand information and vehicle icons. This issue has been discussed in #317. I have modified some of the field names to increase readability and avoid confusion between the endpoints. I also added a last modified field for both brand assets and vehicle icons. This data is important for consuming applications that cache images so that cached images aren't out of date. We discussed other ways of handling modification dates but none of them seemed as reliable as the addition of dedicated fields.

Is this a breaking change?

• Yes
• No
• Unsure

Which files are affected by this change?

gbfs.md:

• system_information.json
• vehicle_types.json

[draperunner]

Typo: on -> one.

[draperunner]

Hi! Looking forward to having brand assets as part of the standard!

I am a bit skeptical to the proposed properties on vehicle_types (icon_url, icon_url_dark, icon_last_modified), if I understood their purpose correctly. I have some trouble seeing when people would use these and why they should be part of the GBFS.

We are developing client apps that consume GBFS feeds from different systems and display them in a map. We want a consistent design on these that match our own design. I don't think we would or could rely on the icons provided by the feed providers for such a use case.

The system brand assets are OK, since they are "objective, universal facts" tied to the data (provider), no matter how things are displayed in consuming apps. You cannot argue that Lime's logo is Lime's logo, etc.

The icons on the other hand are more related to design than data. And the desired design of applications and display of vehicles/stations will vary for every application.

The specification can also be misunderstood: "A fully qualified URL pointing to the location of a graphic icon file to be used to represent this vehicle type on maps and in other applications". Does this mean that I, as an app developer, MUST use the specified icon_url to represent this vehicle type in my app? Or that I MAY use it if I want to?

Suggestion: Don't add the proposed icon properties to vehicle_types, at least not at this time. Let users decide how to display the data in their own apps, using logos from brand_assets if desired.

Adding @kanagy's original propsal for these props from #317 here:

In future proposals it would be useful to also have icons for different vehicle types (these typically appear on the map in bikesharing apps), e.g. a branded scooter icon, a bike icon, an electric bike icon. Any suggestions of where these should live? In system_information or in vehicle_types feed?

[mplsmitch]

I agree that data consumers might prefer to decide how to represent vehicles in their applications as opposed to using graphics supplied by the publishers, however this proposal comes about in response to requests from data consumers for these assets so there's reason to believe that they will be used. On the consuming side, whether or not to use these assets is optional. I've updated the definition of icon_url to make this explicit:

a graphic icon file that MAY be used to represent this vehicle type

As a data consumer you can choose to use them or not, as is true with most everything in the specification.

[kanagy]

We currently cutomize vehicle or station icons on the map for ridesharing and some GBFS integrations. AFAIK this is because producers tend to care about branding - customizing their experience and visually distinguishing it from other competitiors listed. I can also think of a use-case which shows a map with all the available providers around you; here it might be useful to visually distinguish vehicles and stations beyond just using the brand color.

It does add a layer of complexity though - e.g. checking if the icon plays well with the consumer app scheme. Are there other consumers that are interested in these icons? We'll discuss this more internally.

In meantime, I suggest also wrapping the vehicle type assets into a brand_assets message.

[mplsmitch]

@kanagy

In meantime, I suggest also wrapping the vehicle type assets into a brand_assets message.

Are you suggesting something like this?

"vehicle_assets" : {
"icon_url": "https://www.example.com/assets/icon_bicycle.svg",
"icon_url_dark": "https://www.example.com/assets/icon_bicycle_dark.svg",
"icon_last_modified": "2021-06-15"
}

[kanagy]

Yes.

[mplsmitch]

I've wrapped the icon fields in vehicle_types in a vehicle_assets object per @kanagy's suggestion.

[mplsmitch]

I hereby call a vote on this proposal.

Voting will be open for 10 full calendar days until 11:59PM UTC on September 1st, 2021.

Please vote for or against the proposal, and include the organization for which you are voting in your comment.

Please note if you can commit to implementing the proposal.

[kanagy]

Google Maps supports this and intends on using these fields (initially to just manually get, check and ingest the assets).

[yocontra]

+1 from Stae

[nbdh]

So to represent free floating vehicles, consumers shall display the icon of the corresponding vehicle type. But how are stations (with potentially vehicles of multiple types) supposed to be pictured?

[mplsmitch]

@nbdh use of these icons would be optional, so it's up to the consumer to decide how they want to display the data. In the case of a station the vehicle icons could be used to show the number of each type of vehicle at the station. Selecting a station would display the icons for each vehicle type and their respective totals. We could also add a station_icon field in the future if there's a need for one.

[nbdh]

We could also add a station_icon field in the future if there's a need for one.

This seems sensible, though this opens many more questions. Will the station_icon become part of the brand_assets? This would mean a single icon for all stations of the system - or is there potentially even the need for multiple icons, depending on the type of the station, e.g. to display a station that supports charging (#340) differently. This of course probably is better to be discussed elsewhere.

So from my point of view this seems rather like a start in the "branding and icons" topic that probably needs to be extended at some point.

Nonetheless we support the proposal, though I can't tell when we will start publishing this info.

[viestat]

Dott supports this proposal, might implement this in the future.

[testower]

Entur supports this proposal and will implement it in our aggregation service

[evansiroky]

IBI Group supports this proposal.

[ncancelliere]

Spin support this proposal. We currently advertise some assets, so we likely will implement this and update our feeds to match this standard.

[ezmckinn]

Superpedestrian supports this proposal and will implement it.

[josee-sabourin]

This vote is now closed, and it passes!

Votes in favour:
Google Maps (consumer)
Stae (consumer)
Nextbike (producer)
Dott (producer)
Entur (consumer)
IBI Group (consumer)
Spin (producer)
Superpedestrian (producer)

There we no votes against.

These changes will be merged into a v2.3-RC pending implementation.