gbfs icon indicating copy to clipboard operation
gbfs copied to clipboard

Add image URL to station_information.json

Open kumatira opened this issue 2 years ago • 7 comments

Have you read our FAQ? It’s possible your question can be answered there!

Yes

If you are new to the specification, please introduce yourself (name and organization/link to GBFS). It’s helpful to know who we're chatting with!

I'm @kumatira(real name: KUMANO Soma).I work at VAL Laboratory, Inc. in Tokyo. We develop the search engine specialized in route planner. It also covers bike-share service.

What is the issue and why is it an issue?

Currently, there is no way to express position of stations as image. Image of station is very useful when you are looking for that, because bike-share stations are often provided in shade of building or back street.

When developer of application wants to display images of station, he/she can't get that from GBFS and need to work hard to collect images.

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

I propose adding image_url to station_information.json as optional field.

View of producers of data:

  • they can clearly tell the location of the stations to mobility users.
  • To define the field, they must host image files and distribute as URL.

View of consumers of data:

  • They show up graphically where the station is in their application.
  • The field is optional one. They should consider a mixture of urls and nulls.

details

  • Allowed formats: JPEG, PNG.
  • What kind of images is desired: A image that clearly conveys the location.
    • It is desirable to include entire appearance of the station.
    • Signs that can be seen locally will be helpful for users. a service logo, station name and border line.
    • It would be nice if the landmarks were included. e.g post office, Famous building or Starbucks.
    • It may be okay to have a note in the image. e.g "At parking lot down the stairs in front"

still thinking

I think the following will be an issue. I want community opinion, knowledge and past cases.

  • I think the format should be defined in more detail. For example size, resolution or orientation of the images. However specifications that are too detailed put an excessive burden on the producers.
  • Should Consumers host images by themselves and redistribute that? Or is it allowed that their app refers to image sources on producers's server directly? This becomes a problem when used by apps with huge users like google maps.

Please add if you notice.

related

  • I posted on Mobility Data Slack #bgfs my post
  • This idea is mentioned in #7, But the discussion seems to be over.
  • vehicle_image which was just added in v2.3 is similar to this idea.
  • In Japan, it is common to display an image of a station on an app. Here are some examples.

スクリーンショット 2022-04-10 16 10 13

Is your potential solution a breaking change?

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

kumatira avatar Apr 10 '22 07:04 kumatira

+1

futuretap avatar Apr 10 '22 20:04 futuretap

This seems like a worthwhile while addition that could provide value to end users. It's similar to vehicle_image but I think because this would involve multiple photographs of stations in the public right of way there are some additional considerations that would need to be addressed. GBFS consuming applications would be reluctant to use these images without some assurances regarding copyright and attribution. This would probably mean adding additional fields. Copyright could apply the entire data set and be covered by license_url in system_information.json but attribution information would probably have to be done individually for each image.

mplsmitch avatar Apr 15 '22 15:04 mplsmitch

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.

stale[bot] avatar Aug 15 '22 21:08 stale[bot]

This discussion has been closed due to inactivity. Discussions can always be reopened after they have been closed.

mobilitydataio avatar Sep 21 '23 04:09 mobilitydataio

Totally agree.

PEICHINWU avatar Dec 20 '23 02:12 PEICHINWU

Hi @PEICHINWU and welcome! Thank you for this contribution. I reopened the Github issue to restart the discussion. Best, Fabien

richfab avatar Dec 20 '23 10:12 richfab

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

mobilitydataio avatar Feb 19 '24 04:02 mobilitydataio

This discussion has been closed due to inactivity. Discussions can always be reopened after they have been closed.

mobilitydataio avatar Mar 20 '24 04:03 mobilitydataio