GBFS Docomo Bike Share Import in Japan

GBFS Docomo Bike Share Import

Hello all, I am proposing to import the GBFS (General Bikeshare Feed Specification) data of the share cycle service, sourced from DOCOMO BIKESHARE, INC. in Japan.


This is the wiki page for my import:
This is the source dataset’s website:

The data download is available here:

This is a file I have prepared which shows the data after it was translated to OSM schema:


I have checked that this data is compatible with the ODbL.
This data is distributed under CC BY 4.0 DEED.
OSMFJ member contacted the Association for Open Data of Public Transportation and obtained permission from them to use the data under the ODbL license on OSM on 2023-11-20.


  • Information about the dataset: GBFS data
  • The dataset contains share cycle port names and capacities.
  • The size of the dataset is about 3,000 nodes.
  • I use JOSM to import the data.
  • The Tagging plan is shown on the wiki page.
  • My approach to conflation:
  1. Download the existing data from the Overpass API with JOSM.
  2. Merge them with the reference data using the Conflation plugin.
    2-1. If the nodes exist, the coordinates of existing data and GBFS data that seem to be more accurate will be adopted.
    2-2. If some existing data are a way(area) or relation, use the existing way or relation.
    2-3. If no data exists, add new nodes.
    2-4. Docomo Bike Share is essentially limited to use within the same area and cannot be used across areas. Although GBFS does not provide area information, existing data on OSM such as name/brand/network/operator may contain information about the area. In such cases, put it in “network=*.”
  3. Create a merged OSM file and upload it from JOSM.

Any comments/suggestions are welcome.

I am not sure about ref:gbfs key. GBFS is a format. I would use ref:docomo or similar to convey information that’s reference number used by this particular operator
Edit: I don’t have full context. If this number is used only in GBFS, it isn’t visible on a station etc. then ref:gbfs makes sense.

Thank you for your comment.
I use the ref:gbfs tag because its usage is defined in the wiki. Docomo engages in various businesses, with its primary focus on being a mobile phone carrier. Therefore, I believe ref:docomo may not be appropriate in this context. And since this number is only used within GBFS, I don’t think there is a problem.


It is better changed to gbfs:*= to follow gtfs:*= . That was being voted on. Proposal:GTFS Tagging Standard - OpenStreetMap Wiki
ref:*= suffix should be used for different databases and systems, not exactly different formats. All companies will use the GBFS format.
ref:gbfs= is currently an artificial identifier made up for OSM, composed from system_id and station_id . If needed, the ref= of the =bicycle_rental itself should be based on the station_id only.
For data tracking purposes, gbfs:*= should then be used. It can be separated into gbfs:system_id= and gbfs:station_id= . This is simpler to use. I can search for all Docomo stations with gbfs:system_id=docomo-cycle directly based on GBFS specification. No need for regex, which is further slower and less efficient.
The extensibility of gbfs:*= will allow other info to be added in the future easily and authoritatively. Eg gbfs:region_id= for Docomo. This confirms the network= .

In fact, there seems to be a problem with Docomo naming. For name: "04.ドコモ東北ビル" , shouldn’t it be considered as name=ドコモ東北ビル + ref=4 ? The original data can be stored in gbfs:name=04.ドコモ東北ビル separately.
Other comment about website= etc. I have asked @CjMalone in wiki. Talk:Import/Catalogue/GBFS Docomo Bike Share Import - OpenStreetMap Wiki

Thank you for your advice.
Certainly, I think the ref:gbfs tag format differs from the usual one and the gbfs:*= format you suggested is more general and extensible.
I will use the gbfs:system_id= and gbfs:station_id= instead of the ref:gbfs.
Concerning names, some existing nodes in OSM have been separated into ref and name. I will try to follow your suggestion here as well.


I updated the wiki document, .osm file, and conversion script based on the advice provided earlier. The link remains the same as mentioned previously.

Two weeks have passed since my first post.
I have received comments and have reflected them in the plan, so I will proceed with the import process based on this plan.
Thank you for your interest and valuable feedback.