プログラムやデータ開発むけのFANTIAって感じのようですが、これを活用する方法がないかなと考えています

ICカードこれひとつのプログラムやデータは万が一に備えてBitbucketに非公開レポジトリを置いてありますが、例えば「コンビニなどを含む店データ」などが現在開発に苦戦しているので、SPRWIDを含まない情報を外部に出してGitHubでオープンソース化はありかなとは思っています。

月額どの程度設定すればよいのかは全く想像できませんが

GitHub、スポンサーだけが見られるリポジトリ「Sponsors-only repositories」発表
https://www.publickey1.jp/blog/22/githubsponsors-only_repositories.html

@wondergil 情報ありがとうございます。

あとは昼割が除外される系統のバス停情報が集まれば、実用的な水準で区別ができる可能性があります

このアカウントは、notestockで公開設定になっていません。

南海バス「なっち」で、「通常」「昼割」の残高を分離するために考えないといけないこと
未来情報産業ブログ
https://miraicorp.blog.fc2.com/blog-entry-574.html

#ICカードこれひとつ
モスバーガー 博多バスターミナル店
どうやらこの店は、モス全体で交通系電子マネー正式対応する前も後も、nimoca決済端末はレジと連動せず、金額手入力による決済運用をしているようです

IC R/Wとレジが1対1で対応しない運用はよくありますが、レジとそもそも連携していない運用も考慮が必要そうです。

ゆえに今後決済端末の処理方法について

・複数のレジで共有
・レジと連動しない金額入力式決済端末

の上手い処理方法も考えたいところです(現在は必ず何かしらのPOSレジにリンクする仕組みであるため)。

#ICカードこれひとつ
モスバーガー 博多バスターミナル店

昨年頃、SUGOCA契約でレジは2台あるようですが、2年前頃にnimocaで1/1と報告され登録されているようです。

nimocaのみ別決済するレジが1台だけあるということなのでしょうか、それとも端末更新や契約変更等があったのでしょうか

メモ
端末の機種名が同じ(同一個体かは不明)で、交通系とWAONでCARDNETまたはINFOXの番号が異なるもの（ざっと眺めた範囲、順不同）

(Suicaエリア)
幸楽苑 道玄坂店
米山SA(上り) ショッピングコーナー
米山SA(下り) ショッピングコーナー
大積PA(上り) ショッピングコーナー
栄PA(上り) ショッピングコーナー
黒埼PA(上り) ショッピングコーナ
阿賀野川SA(下り) ショッピングコーナー

(ICOCAエリア)
丸亀製麺 ならファミリー店

なんらかの設計変更が必要そうだが工数が掛かるのでかなり厳しい

#ICカードこれひとつ
IC R/Wは恐らく同一で、ICOCA等とWAONでCARDNETの番号が異なる例が報告されている。この扱いをどうするか

丸亀製麺 ならファミリー店 の報告では、
ICOCAで31091-510-74849
WAONで31091-510-74736

これが事実だとすると、いまCARDNETの番号などは端末DBに置いているため、端末の段階で分ける必要があって矛盾が生じる。

CARDNETの番号などはSPRWID DBに置かないといけない可能性があるが、こういった例外以外はほぼ共通であるので、これも無駄が多い

CARDNETの契約の仕組みは詳細不明ながら、

端末DB→各SPRWID DB

から

端末DB→契約→SPRWID DB

の階層構造にして必要に応じて契約の情報を増やす必要があるのかもしれない

#ICカードこれひとつ
JR九州&西日本 博多駅の新幹線改札

新幹線改札では利用の条件？によってJR九州または西日本の駅番号が書かれるようです。

これまで両者で異なる内容で登録されていましたが、内容を合わせました

JR九州
https://allnfc.app/jp/gatelist/95196f5d/395dcfdc_9d9028aa.html

JR西日本
https://allnfc.app/jp/gatelist/1ed7059b/ec3bd948_9d9028aa.html

乗り換え改札が主たる対象となりますが、改札口名は詳細不明のため、適当に合わせてあります。より正確な名称があればお知らせ下さい

新幹線中央乗換口・北乗換口・3階連絡改札口は、JR西日本側で報告なく登録されておりませんが、JR九州として報告があるため、推定対応を加えてあります。

また「新幹線中央改札口」についてはJR西日本でのみ報告があり登録されておりますが、JR九州としての番号書き込みがあるのかどうかは不明です。

「新幹線ひかり広場口」も報告のない改札口で、アプリではJR西日本側にのみ名前だけ登録されております。
こちらもご利用の機会があれば報告をいただければ幸いです。

東京メトロ 日比谷線 六本木駅に、エレベーター専用改札と思われる新改札が昨年12月21日に供用開始したようです。
https://travel.watch.impress.co.jp/docs/news/1376004.html

改札機番号は9番と10番で、近くにある「六本木交差点方面改札」と連続ですが、改札口番号が同一かどうかは今のところ不明です。

R/W IDの作り方案

POS IDが「店ID-レジ番」だった時、R/Wが1台だけの場合、R/W IDも「店番-レジ番」である

R/Wが複数台ある場合、R/W IDは「店番-レジ番:番号」のようにする

区切り記号を変えることで、登録端末が一つか複数かが一目で分かる

仮案

番号1　POS本体に内蔵されているもの(3大コンビニ等)、または別端末でも主たるもの(大手コンビニではミニストップやヤマザキが該当)

番号2　9カード交通系電子マネーで副次的なもの1(メインが9カード対応の状態で、SuicaやICOCAなど特定JR系電子マネーを別端末処理する場合)　※吉野家で報告あり

番号3　9カード交通系電子マネーで副次的なもの2(メインがSuicaやTOICA時のPASMOやmanaca)　駅ナカのセブンイレブンで報告あり

番号4　主に地方専用交通系電子マネー用のもの(SAPICA、IruCa等)　特にIruCaは別端末処理する店が多い模様

番号5　主にWAON用のもの

アプリでの表示内容は今後検討が必要だが、現状の報告範囲内では、5種類からの選択で支障は無さそう

#ICカードこれひとつ
複数のIC R/Wがあるときの内部的なIDの付け方についての草案

現在のDB構成
DB1 店
DB2 売場
DB3 POS
DB4 R/W
DB5 交通系SPRWID
DB6 WAON SPRWID

IC R/Wが複数ある場合、DB4のIDで対応が必要で、結果として上位DBのIDを持つDB5やDB6が影響する。

DB4のIDは現状ではほぼPOSのIDと同じだが、複数のR/Wを区別し、互いに衝突しないようにする仕組みを付ける

R/Wが複数あるといっても多くても2〜3台と思われるので、あらかじめタイプ分けされた中から選択してもらう仕組みにしても大きな支障はないと思われる。

選択結果は内部的には1桁の数字で扱うこととする

続く

セブン銀行や松屋など、navitimeがサービス提供している公式店舗一覧ですが、どうも機械的なダウンロードができなくなっているようです

今のところ、Webブラウザーを使い人力でクロールする以外に現状確認の方法がなく、弊社では時間が取れないため独力での現状確認を放棄せざるをえません。

松屋は殆どないですがセブン銀行は報告が非常に多いため、現状確認できないのはなかなかつらい所です。
サービス維持が困難になりつつありますので、ボランティアで手動で調査して下さる方おられましたらご協力下さい。

続き
●BC 入出場について

1 有効状態 [無制限で通行可] [時限通行不可]、[常時通行不可(HW)] [常時通行不可(SW)]、[常時通行不可&封鎖(FIX)]、[条件不明の通行不可]

2 磁気状態 [常時利用可] [常時利用不可(HW)] [設定による磁気券不可]、[時限 磁気券不可]、[条件不明の磁気券不可]

3 IC状態 [常時利用可] [常時利用不可(HW)]、[設定によるIC不可]、[時限 IC不可]、[条件不明のIC不可]

4 各種補足と予備情報
　4-1 [QR券用カメラ付き]
　4-2 [非接触クレジットカード対応]

続き

入出場の情報の登録について
前提

従来の入専/出専という報告ではなくなり、入場について、出場についてを、別々に報告する。

入専は入場側が[無制限で通行可] 磁気券ICは[常時利用可]などとし、逆に出場側は[常時通行不可(HW)] 磁気券ICは[常時利用不可(HW)]のように選択して報告する。

「ソフトウェアで入専になっていて出場できないが、しかし出場側だけなぜかIC専用機になっている」といった変な改札機も、これによって自然に記述できるようになるほか、乗り換え改札口の登録作業は入場側と出場側の記述を入れ替えるだけで済み、書き換え時の誤記がなくなるメリットがある

続く

続き

●A-3 機能面
ポール型簡易改札機をどこで表現するか迷っているが、暫定的に扉状態欄で記載する計画

1 扉状態 [通常、または簡易改札の状態不明] [常時開放] [無扉] [ポール型(無扉)]

2 幅広状態 [幅広でない] [詳細不明の幅広] [幅広HW] [幅広機を通常幅配置] [通常機を幅広配置]

3 各種補足と予備情報
　3-1 東京メトロ&都営 [磁気のりかえ(オレンジ改札)]

その他、IC専用を除いた何らかの色分けでの案内等が顕著でありメモが必要な状況がある場合は、臨機応変に対応できるようにする

続く

●A-1 稼働状態
[稼働] [休止] [時限休止]

時限休止は深夜早朝や人の少ない時間帯で一時的に停止し節電するもの。休止は工事などの都合で長期にわたり封鎖されたりするもの。

●A-2 設置状態
有人改札のフルタイム/時限の判定は、その改札口の営業時間内で判断する。終電前に閉まる改札でも営業時間中有人改札が営業されるならフルタイム有人改札であり、自動改札機は通れる時間帯で有人改札が閉まる場合は時限有人改札である

1 有人状態 [自動改札機] [フルタイム有人改札] [時限有人改札] [営業時間不明の有人改札]
2 簡易改札状態 [特記事項なし(通常型)] [簡易] [車載]
3 分離柵の有無

分離柵は、
南海 極楽橋駅
西鉄 櫛原駅、安武駅
で報告があり、一対で向かい合う改札機を分断するように柵があり入出場を区切るもの。つまり自動改札機の片方ずつが置かれ仕切りが柵になっている状態である。

続く

#ICカードこれひとつ
次々と謎運用が発覚する自動改札機を記述するための言語の案

A 全体について
　A-1 稼働状態
　A-2 設置状態
　A-3 機能面
B 入場について
C 出場について

それぞれの可能性を英数文字や記号文字を用いて列記する形になります。

ある程度の予備欄は用意しますが、今後登場するであろう未知のタッチレス改札機については記述できない可能性があります。

更に考慮が必要と思われるものがあれば、指摘いただければ幸いです。候補案は未収載でぶら下げます

このアカウントは、notestockで公開設定になっていません。

#ICカードこれひとつ
新物販のタブの表示について

Androidのタブ機能APIとして、従来は FragmentManagerとViewPager というものが使われていました。しかしこれはdeprecated(非推奨)になっており、将来的に廃止が決まっています。

代替としてFragmentStateAdapterとViewPager2が用意されているため、こちらに変更していますが、これがバグだらけで使い物になりません。

こちらの対策に時間を取られるのも厳しいため、諦めて元の古い非推奨APIに戻しました。

これがいつまで使えるか分かりませんが、Android 12でもまだ使えますので13か14か、そのくらいまでは猶予があるものと思われます。その頃までにはバグも直っていることに期待して、時間切れになるまでは従来通りのタブ制御でいようと思います。