Add *_icon_url to facilitate icons on maps and itineraries

[skinkie]

No description provided.

[RachM]

Custom icons would be great for users, but one concern I have is that different consumers will likely have different guidelines that the icons must meet. For example, at Google we'd need multiple versions of an icon in varying sizes, formats and potentially foreground colors. To see what I mean, have a look at the 'Maps' icons at https://material.io/icons/.

We'd probably need the url to point to an icon set/package (maybe have them all zipped?), where the icons are named such that consumers know which ones they want. This would have to be documented in the spec.

Also, what happens when a consumer needs a new icon that isn't in the set? How would they go about getting it added?

[skinkie]

It might be a good practise to define the requirement for a vector resource, in a specific aspect ratio. But I agree, this is a discussion we must have. Then again, favicons gracefully solve this problem, so we could make it complex or just define the intent by an URI, where the consumer knows that the URI is the intent and local resources may replace it.

[barbeau]

I agree that multiple icons would be needed. I think we'd also need to give very specific examples of how the icons are used.

@RachM It looks like Google Maps shows some agency-specific icons on the map tiles - see San Francisco BART example below:

Does Google have a standard template icon set that they ask agencies for? Or is this done more on an ad-hoc basis?

I was thinking if Google can share this template it would be a good starting point, especially if multiple agencies are already sharing icons in this format.

If not, maybe the best way to approach this is to look at the specific use cases in apps (e.g., stop icons on map tiles) and back into a generic format from there, and then see if agencies are able to provide this.

[RachM]

Good question @barbeau - I will find out and report back.

[LeoFrachet]

Maybe pointing to vectorial icon, like an .svg, could be a solution. On WikiMedia you can either access the .svg or the .png (when the .svg is available).

Example for the bullet of the Paris Subway Line 1:

As .svg:
https://upload.wikimedia.org/wikipedia/commons/f/f4/Paris_m_1_jms.svg

As .png, width 200px:
https://upload.wikimedia.org/wikipedia/commons/thumb/f/f4/Paris_m_1_jms.svg/200px-Paris_m_1_jms.svg.png

[RachM]

Reporting back:

• Customisation of icons is done on a case-by-case basis, so unfortunately I don't have a set of guidelines for you
• We require a few different sizes, so svg would be a good solution
• Transparent background is ideal

[stevenmwhite]

Posting the same comment I did over on #269 because we closed that one.

I think generally there's an agency "logo" that represents the agency, but it may not be the icon/symbol that represents their services. One agency may have multiple services with distinct brands (circulators vs commuter routes, or rapid vs local) so perhaps the service icons should be defined at the route level? Both are important, and the route-level icons could be treated as an override to the agency-level one. For many agencies, just the single agency-level logo/icon will suffice.

[skinkie]

@stevenmwhite we have a regular discussion if agency.txt is actually used as "brands.txt" since many map service providers only have a single way to distinguish between "the operator" and "the product formula". Further complexity is observed when "the authority" that hires the "the operator" wants to be the brand visible. The solution is not about route level, because routes on their own can have different branding styles which are currently being facilitated by line color et al. In addition even a direction (headsign) may have a distinct icon which GTFS does not support as as normalised concept, rather only as denormalised trip_headsign.

[stale]

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

[stale]

This pull request has been closed due to inactivity. Pull requests can always be reopened after they have been closed. See the Specification Amendment Process.

[skinkie]

Keep open.

[github-actions]

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

[skinkie]

Keep open.

[github-actions]

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

[skinkie]

Keep open.

[sccmcca]

@skinkie Is there something actionable to work on for this proposal (i.e., working through solutions, listing producers/consumers, calling a vote)? I think that would be a more effective way to advocate.

[gcamp]

This is generally not something we could use directly because we have specific requirement that don't make sense to be in the specification (mono-color, some specific code to use the route color inside the image, height requirements, etc).

However, we could use those fields are "good default" that we base ourselves on for the final value that will be used in the app. Would that be enough to be considered as a "consumer"? We use route_color the same way because we modify it most of the time for our context.

Other comments :

• Heavy +1 to enforce SVG
• Some guidelines/best practice on the level of details that is required on the image would be good.
• I think we need some additional field to define if the image is enough to represent the route by itself. Images on routes are often stylized text with the same content as route_short_name, we need a way to know if we should show the route_short_name in addition to the image or not. Same to know if the color is embedded inside the image or it should be shown in addition.

[skinkie]

Keep open.

[github-actions]

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

[skinkie]

Keep open.

[github-actions]

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

[skinkie]

Keep open.

[Bertware]

The allowed image formats should be defined, and in case that formats other than SVG are allowed, a recommended image size could help as well to prevent big differences in image size/quality between feeds. Agree with @gcamp that SVG would be ideal.

[skinkie]

While I generally agree that SVG is the ultimate format for these things. It only works (well) from a minimum dpi. Let's say the 16x16 icon you see on a map is very difficult to achieve with SVG, because it requires pixel alignment prior to rasterization. I am sure we can work out the best way to do this.

[github-actions]

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

[github-actions]

This pull request has been closed due to inactivity. Pull requests can always be reopened after they have been closed. See the Specification Amendment Process.

[felixguendling]

GBFS has this in system_information.json. Since this approach seems to work well for GBFS, it could work for GTFS as well?

Field Name	REQUIRED	Type	Defines
license_id (added in v3.0)	Conditionally REQUIRED	String	REQUIRED if the dataset is provided under a standard license. An identifier for a standard license from the SPDX License List. Provide license_id rather than license_url if the license is included in the SPDX License List. See the GBFS wiki for a comparison of a subset of standard licenses. If the license_id and license_url fields are blank or omitted, this indicates that the feed is provided under the Creative Commons Universal Public Domain Dedication.
license_url	Conditionally REQUIRED (as of v3.0)	URL	REQUIRED if the dataset is provided under a customized license. A fully qualified URL of a page that defines the license terms for the GBFS data for this system. Do not specify a license_url if license_id is specified. If the license_id and license_url fields are blank or omitted, this indicates that the feed is provided under the Creative Commons Universal Public Domain Dedication. (as of v3.0)
attribution_organization_name (added in v3.0)	OPTIONAL	Array<Localized String>	If the feed license requires attribution, name of the organization to which attribution should be provided.
attribution_url (added in v3.0)	OPTIONAL	URL	URL of the organization to which attribution should be provided.
brand_assets (added in v2.3)	OPTIONAL	Object	Object containing branding information about the system.
brand_assets.brand_last_modified (added in v2.3)	REQUIRED	Date	Date that indicates the last time any included brand assets were updated or modified.
brand_assets.brand_terms_url (added in v2.3)	OPTIONAL	URL	A fully qualified URL pointing to the location of a page that defines the license terms of brand icons, colors, or other trademark information. This field MUST NOT take the place of license_url or license_id.
brand_assets.brand_image_url (added in v2.3)	REQUIRED	URL	A fully qualified URL pointing to the location of a graphic file representing the brand for the service. File MUST be in SVG V1.1 format and MUST be either square or round.

While I generally agree that SVG is the ultimate format for these things. It only works (well) from a minimum dpi. Let's say the 16x16 icon you see on a map is very difficult to achieve with SVG, because it requires pixel alignment prior to rasterization. I am sure we can work out the best way to do this.

Maybe this could be solved by adding a 16x16 URL field? This could be another PR to keep things simple for now.

Edit: I am re-starting this discussion because we would like to bring icons into Transitous and MOTIS and of course it would be nice to not do a custom solution that works only for us if there could also be a solution that would help the whole ecosystem.

[skinkie]

It might be but only as part of agency.txt, not feed_info.txt.
Then again, this was a very clean proposal, and I think we should just ask mobility data to open it again, and bring it to a vote.

[etienne0101]

Thanks for bringing this up, @felixguendling. I suggest opening a new pull request just for the icon, and referencing this issue in the description.

[skinkie]

@etienne0101 why don't you just reopen it?

[etienne0101]

@etienne0101 why don't you just reopen it?

@skinkie It is an 8 year-old issue, so a new one makes it easily accessible from the first page on Github.

[skinkie]

Nonsense.

[felixguendling]

I think opening a new issue for discussion will produce duplicates which is something to be avoided. Having only one place where one topic is discussed is the best approach IMO. Sorting by "last updated" is just two clicks away.

Anyway, we're discussing a concrete proposal at #585, so I would like everyone to join the discussion there and I will continue to update the proposed changes to reflect the results of our discussion.