@NagisaTakayama ありがとうございます。
臨時改札口の存在を一覧に追記いたします。
@NagisaTakayama ありがとうございます。
臨時改札口の存在を一覧に追記いたします。
@NagisaTakayama 5月22日確認ということなので、とりあえず暫定的に5月に入ってから表示が変わるよう対応致します。
@NagisaTakayama ちょうどその頃、7月2日に変更前と思われる報告があったようです。3日以降に変更されたようですね。
写真で確実な14日以降に切り替わるよう対応したいと思います。
バスの系統情報ですが、実装しながら項目の調整などを実施し、ある程度仕様が決まったところで、改めて系統情報を表示して欲しいという方にデータ作成をお願いすることになると思います。
10カードでは無理ですが、地域専用カードなら乗降両方が履歴に記録されます。
その場合は乗降双方で一致する系統のみを抽出して、履歴タブに表示していますので、乗った可能性の高い系統のみが表示されます。
そんな、ちょっと便利かもしれない機能つくりにご協力をいただければ幸いです。
恐らく次のバージョンから入ると思いますが「表示件数の上限機能」を設定→表示内容設定の最後に追加します。
標準では3件で、0(表示しない)〜1〜20〜無制限の範囲で設定できるようにしておきました。(範囲は1〜10でも充分だとは思いますが)
この設定は、履歴タブや改札タブ(将来的には入出場タブも対応予定ですがまだ未実装です)で有効です。詳細情報では設定にかかわらず全て表示します。
3とした場合、3件なら表示されますが、4件以上となった場合は表示しなくなります(超過分を省くのではなく、表示しません)。
標準の3にしておけば、概ね従来の系統情報入力方針と変わらない表示になると思います。
@KN08 ありがとうございます。
その頃に8台→4台で表示が切り替わるよう対応致しました。
3月3日に「おみやげ小路 京小町 南館」を報告された方:
ここは複数のお土産屋さんがテナントとして並ぶ場所のようです。
レジが共通でないのであれば、店名として「おみやげ小路 京小町 南館」は適切ではなさそうです。もしそうであれば、実際の店名に記憶があればお知らせいただければ幸いです。
このアカウントは、notestockで公開設定になっていません。
作るかどうかはともかくとして、ポール座標の情報をバス停名DBから分離するとした場合の想定
バス停名DBからは座標や住所らしきものは消す。
バス停ポール座標DBを新たに作り、ポールのボタンはこのDBを参照して表示する。
「中心座標」のレコードと、各ポールのレコードが必要になる。
詳細画面でボタンをタップすると、メニュー最上段に詳細表示メニューを入れ、バス停ポール座標DBにある情報を表示する。
バス停ポール座標DBに入れるべき内容
DBのキー情報のほかは、副名称的なもの(広告?)と、座標情報でしょうか。
将来的には系統DBを引いてそのポールに停車する系統の表示も?
ポールごとにバス停名が違う場合
バス停DB側で別の枝番を用意し、DBキー自体変えて混在表示しない方が混乱が少なくて良いかもしれない。必要なら他の枝番の情報も表示できるけど必要かどうかは不明。
とてつもない工数掛かりそう
@NagisaTakayama 今は全部出ます。
件数の制限機能を付ける予定でしたが、しばらく後になりそうです。
今のところは、試験的に確認する以外は表示をOFFにする方が実用的かと思われます。
バス停といっても複数のポールがあります。
系統によって、停まるポール位置はほぼ固定なので、系統情報内に停車するポール位置まで明記することが究極的には可能でしょう。
そうなるとバス停名DBの方も仕様変更が必要になるのかもしれません。
今はポールの座標情報を補足として書き連ねていますが、これを分離して一意に特定する番号を付してあげる必要があるのかもしれません。
今のところ枝番で対処しようと考えていますが、そうではなくポールごとに完全分離する方が本来的には良いのかもしれません。
メンテナンスが大変なことになりますが、座標情報も1レコード1情報となれば、店舗検索と同様、検索処理もやりやすくなるでしょう。
いよいよ本州も梅雨入りの季節ですか
梅雨入り前にやりたかったことは色々ありましたが手の数が足りなすぎて半分もできなかった感じがあります。
夏以降は、増員できるくらいの収益がアプリから得られるよう頑張りたいと思っています。
このアカウントは、notestockで公開設定になっていません。
#ICカードこれひとつ 2.003をリリースしました。
物販も少しだけ対応しましたがまだ大量に残があるため、弊社内で時間をみて随時対応してまいります。その代わり他の機能実装や、開発予定の別アプリは少し遅れると思います。
日本語リソースと英語リソースを含むアプリにしたためか、APKでは警告が出るようになってしまいましたね。
いずれAndroid App Bundleにしないとダメなようです。
#ICカードこれひとつ
一旦締め切って、次のバージョンのリリース準備に取りかかります。
交通は全て対応する予定です。
物販は業者とまた音信不通になりましたので、そろそろ考え直す必要があるかもしれません。
@NagisaTakayama ありがとうございます。
指摘箇所は全て修正致しました。
繁忙期の特殊な運行日はどう記載するかは検討が必要そうです。
ふらっとバスの「大学病院」停留所
座標の報告があったのですが、画像赤ピンの位置になっておりました。
説明を見る限りでは、乗降場所は青ピンの位置付近になるのかと思うのですが宜しいでしょうか?(思った位置に青ピンが立たないのでちょっと位置が変ですが)
#ICカードこれひとつ
いわさきグループ、特に鹿児島交通
従来、大きく「いわさきグループ」と「いわさきバスネットワーク」に別れており区別が必要でしたので、これまで鹿児島交通などは「いわさきグループ」と表示しておりました。
しかし「いわさきバスネットワーク」が廃止されて久しく、もはや表示する必要性がないと判断されましたので、次のバージョンから消去します。少し画面が見やすくなると思います。
今のところは、バス停名の共通DB採用事業者について系統DBの充実化を図るための研究開発をしていますが、他のカードも恐らく需要あると思います。
ナイスパス、Rapica(いわさき以外)は他のカードと互換性がないバス停番号を持ってはいますが技術的難易度は他社とさほど変わらないと思います。
ICaといわさきはバス停番号自体が系統番号依存ですので簡単な系統情報は必ずつきますが、バス停を一意に特定する番号を持たないので、弊社側で何かしらの独自IDを発行しない限りはその停留所を通る他の系統検索といったものは実現できないと思います。
「北門14丁目」「北門町14丁目」ですが、ノーコメントで追加計7回の報告が届いておりました。
とりあえず何かしらの証拠になるものがないと対応が難しいため、車内の電光表示の写真であるとか、放送の録音であるとか、そういったものがあれば確実だと思います。
また影響範囲として、北門●丁目は9、14、15、16、19、21の6停留所があるようですから、全てで対応の必要が生じる可能性があります。
#ICカードこれひとつ
北陸鉄道 金沢ふらっとバス菊川ルートと材木ルートが報告されております。
両ルートとも、連番方式で推定対応できそうでしたので全停留所を登録しました。
具体的な位置が不明だった菊川ルート15大学病院を除く全停留所で座標も登録しております。
他に、此花ルートと長町ルートもあるようですが、同様に推定対応可能なのではないかと予想しています。
https://www4.city.kanazawa.lg.jp/11310/taisaku/flatbus/all-route.html
またこの系統は前払いの均一区間とのことです。カードに特殊な使途番号が書かれていました。
判定可能であるため、文言が適切かは不明ですが「均一運賃」と右上に表示する対応を実施しました。
このアカウントは、notestockで公開設定になっていません。
#ICカードこれひとつ
旭川電気軌道の停留所ですが、公式サイトで「北門14」と表示されている停留所について
現在は法則として町を省略することはないということでしたので「北門14丁目」で登録されておりますが、これを「北門町14丁目」に修正する報告が届いております(2回目)
本当に北門「町」14丁目と案内されているのでしょうか?
@NagisaTakayama Web一覧、余裕ががあればアプリでも、往路復路を見やすく表示する予定ですが、この系統だけは分離してしまいますね。仕方がありませんが
営業所名のフィールドを系統DBからルートDBに移動完了
アプリ処理も変更
表向き従来通り動いているように見える
@NagisaTakayama いま、営業所名を系統DBから下位のルートDBに移す仕様変更作業をしています。
ぐるっとバスの営業所名は、いっそ省いてもいいのかなと思っておりますが、どうなのでしょうか。
系統の名称の階層構造
今までよく分からなかったのですが、どうも、
事業者名→営業所名→コミバス名(任意)→系統名
※ではなく※、
事業者名→コミバス名(任意)→系統名→営業所名
この順序なのではないかという気がしてきました。
@NagisaTakayama ぐるっとバス
大宮通りルート(青ルート)が登録されているので、DB更新の都合上から、残る現行の赤および橙色?と、3月までの赤青を全て登録しておきたいと思います。
前にも確認したような気がしますが、営業所はルートごとにどうなっている&いたのでしょうか
バスの系統
一つの系統で、ルートごとに営業所が異なる場合、どう対処するべきか。
営業所名は系統DBに持たず、その下位のルートDBに持つべきなのかどうか
@KN08 情報ありがとうございます。
定期券と共存できないということは、定期券用の領域を使用して運用されるのでしょうね。
このアカウントは、notestockで公開設定になっていません。
@NagisaTakayama なるほど、分かりました。運行日注意の系統として登録致します。
@NagisaTakayama 11-1-TT 天理市内線1 ですが、路線図をみても実在が確認できませんでした。どういった路線なのでしょうか
@NagisaTakayama ありがとうございます。
確認次第登録をさせていただきます。
バス停についての駅ナンバリング
バス停に付されているものと、系統で停車順などに付番されているものの二種類がある
両方に対応できるようにするため、系統のバス停リストにもフィールドを追加する必要あり
@NagisaTakayama ありがとうございます。
中央改札口は過去報告がなかったようですが、3月1日以降と22日以降でそれぞれ切り替わるように推定対応を追加したいと思います。
@NagisaTakayama とりあえずは電子メールが無難でしょうか。
加工に数日かかるかもしれませんが、現状に対応させ追加致させていただきます。
他と決して重複しない方法として、バス停番号16進数4桁-枝番、として格納する方法
例:
本体 0001
枝1 0001-1
枝2 0001-2
枝はWebのバス停名一覧に表示させない。
枝の番号は重複しなければ何でも良く、1からの連番でも、ポール番号でも、何でも良い
この方法ならアプリの処理を変えなくても検索にヒットすることがないので枝番を安心して追加できる。
-以降を削除すればカード内番号も簡単に求められるので都合も良い。
系統DBに記載するバス停番号は、この枝番付き番号とする。
とりあえずこの方法でしばらく試してみましょう
枝番の付け方、フィールドを増やすのはやめて別の方法にした方が良いかもしれません。再検討します。
バス停名DB、小さくするつもりが余計大きくなりました
系統DBに情報移行を終えて不要になったフィールドを消すまではちょっとAPKのサイズも膨らむかと思います。
バス停名DB 設計変更方針
・カード内に書かれる番号をキーとするのは維持
・カード内に書かれない番号は、独自に付番して別途DBに格納する
・このためにフィールドを一つ追加し、IDの枝番としてsubidを加える
・元々あるバス停情報はsubid=0とし、検索もsubid=0を条件
・系統DBから引くための情報としてsubid>0の項目を用意する
#ICカードこれひとつ
バス系統DBですが、京都バスで路線図にあるものは恐らく全て登録できたと思います。
市営バスはまだまだ先は長いですが、こちらも時間をみながら作っていきたいと考えております。
Webの一覧表示ですが、今のところ系統DBは参照していないので、参照して情報補完できないか検討していきたいと考えています。
また、同じ停留所番号でありながら異なると判断できる停留所への対応も、今後進めてゆきます。
@NagisaTakayama このデータベースにおける停留所名はあくまでメモなので、どの停留所か特定可能であれば無くても問題ありません。
@NagisaTakayama 海外だとやはり基本はマイカーだからでしょうか。
政府レベルで公共交通への移行を打ち出す国が増えるとチャンスはあるかもしれませんね。
東南アジアあたりでも鉄道開発が進んでいますし、日本のODAで開発されていてFeliCaが入る入らない的な話は聞かれます。
@NagisaTakayama 海外でも、首都圏の鉄道ならそのくらいのスペックは必要になると思うのですが、どうなんでしょうか。
日本の改札機メーカーやバス運賃箱メーカーも、FeliCa仕様のままで輸出などすると面白いことになりそうな気はしていますが、今後の海外展開などはどうなのでしょうね。
@NagisaTakayama せっかくなので、GoogleもFeliCaを世界に広めてくれると色々喜ばしいのですが、そこまではする気がなさそうです。
最近はクレジットカードのコンタクトレスが出てきていますがNFC-A(MIFARE)やBですと暗号鍵なしでは読み取れませんので面白みが全くないですね。
中に何があるか楽しめるのもマニアックな要素としてFeliCaの魅力のような気はしますし、これはこれひとつが誕生した理由でもあります。
このアカウントは、notestockで公開設定になっていません。
@tomoya117 それもあるでしょうね。
言いたかったのは、サービスのレイヤー(層)が異なる、ということでした。
このアカウントは、notestockで公開設定になっていません。
恐らくですが、こんな感じじゃないでしょうか。
「おサイフケータイ」は、電話機内部に入っているFeliCaチップの愛称。
および、広義にはFeliCaチップを内蔵している電話機自体の通称。
このおサイフケータイ(FeliCaチップ)内には様々な電子マネーやポイントサービスを記録できる。モバイルSuicaなどもその一種。
「Google Pay」は、そのおサイフケータイ(FeliCaチップ)を用いたGoogleの決済サービスブランド。
FeliCaチップ内に記録された様々な電子マネー類をGoogle製アプリで管理できる。
Googleに認めてもらってないものは、FeliCaチップ内にあっても表示されない、使えない。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@NagisaTakayama 大丈夫です。
こちらも、必要に応じて部分的に作成している状況ですし、網羅はそう簡単ではないですから、できるところから作っていく方法で良いかと思います。
ちなみに初期設計からかなりデータ形式変わりました(また今後も少しずつ変わると思います)ので、必要に応じてこちらに投げていただければ、形式を整えて登録してから、整えたものをお返しいたします。
@NagisaTakayama ありがとうございます。片方向のみに設定いたしました。
データベースの内容をどのように画面表示するか決定したら随時Webで公開してゆきたいと思っておりますので、その際に再チェックいただければ幸いです。
#ICカードこれひとつ
次のバージョンですが、週中頃にリリース予定で作業中です。
不具合修正といつも通りの交通系の情報更新が入ります。
物販については、数日中に業者側で作業着手できるらしいので、次の次のバージョンあたりからハイペースな登録が復活すると思います。もうしばらくお待ちくださいませ。
@yukipsn 情報ありがとうございます。
2月128日(木)となっていましたが、曜日からして28日、2月末閉店でしょうか。
C8になってからの報告は残念ながらなかったようです。有効期限を設定いたしました。
今後、バスのデータベース周りで必要なことメモ
①番号未知のバス停にも一意の独自番号を付ける
②バス停番号に枝番を付けられるようにする
③バス停名DBから将来的に、営業所名、コミバス名、路線名、系統番号などの情報を削除する(別のDBに移動)
#ICカードこれひとつ
ICOCAにおける、JR西日本の車内補充券発券機
ダンプデータで報告されておりますが、特にこれといった細かな情報は記録されておりませんでした。
今回得られたGooglePlayに関する知見
月極契約のアプリ内課金
アプリ自体を配信終了すると、自動請求は止まる(請求可能状態のまま実際の請求に移行しない)
勝手に請求が続いてしまうのではないかという不安がありましたが、それはないようなので安心しました。