磁気式などの電子マネーを管理するアプリの開発

増え続けるお店専用電子マネー対策


ICカード式電子マネーは「全国のICカードこれひとつ」シリーズで管理できます。弊社としてはもっともお勧めの方法です。

しかし、磁気カード式、現在だとスマホを想定したQRコード式の、店舗の独自電子マネーも徐々に普及し始めていると思われます。

理由は色々あると思いますので店舗の思惑がどうかは一概には言えませんが、おつりの小銭を用意するのも最近では銀行手数料がとてつもなく高額になり、そんな無駄金を銀行なんかに払うくらいならお客に還元した方がいい、となって最近ではスーパーマーケットですらクレジットカードや電子マネーに対応するのが日本の現状なのだろうと認識しております。
また、政府の後押しもあり、今後もキャッシュレス化が進むことは疑いようがないでしょう。

ただ、大きな所(ようするに交通系電子マネー)に乗っかることができない事情も店によってはあると思われ、そういった店では「その店(または店グループ)専用電子マネー兼ポイントカード」という、従来の磁気式あるいはバーコード式ポイントカードに電子マネー機能が付いて便利さupという、そういう方向性の電子マネー導入になることもあると思われます。

そういった電子マネー、数が多いと(多くなくとも)「今残高いくらだっけ?」となるのは間違いありません。
ネットから、あるいは専用アプリから残高や履歴確認できるものも多いですが、一つ一つ確認するのは大変なので、もうちょっと何とかならんのか、と思うのが実際の所ではないでしょうか。
つまり、アプリで一覧管理できることが望まれるわけです。

ならば管理するアプリを作ろう


そこで、インターネット経由で残高や履歴確認できるそれら電子マネーを管理するアプリを開発する計画です。

時期については未定ですが、開発初期の無料配布はなく、機能が乏しい最初の時点から有料での販売となり、随時改良版の更新配信を実施してゆきます。
また、月極ではなく、売り切り販売のアプリになることが予定されています。

1年ないし数年ごとに新製品を新発売して年貢を徴収するのが資金調達的には無難ではありますが、売上が良好であれば一度買った人から再徴収せず、価格改定(値上げ)でご新規さんの負担を増やす方向もありかもしれません。予定は未定ですのでどうなるかは今後考えていくことになると思います。

どういった操作性にするのが使いやすいのだろうか


作るのは良いのですが、どういった操作性にするのが良いのでしょうか。
「全国のICカードこれひとつ」も、従来にない新しい操作性で一世を風靡し、ICカードビューアーという既に数多のアプリがある世界に新風を巻き起こしましたが、電子マネー管理アプリなどというものは既存品は存在せず、完成すれば弊社製品が恐らく初になると思われます。

参考にするものがない中で操作性を考える必要がありますが、ICカードこれひとつと同様にタブ式の操作にすることは既に決まっています。

一覧と選択した電子マネーの詳細の切り替え


初期画面は登録したアプリの電子マネー額一覧にするのが良いと思うのですが、それをタップすると右側にタブが追加されるような感じが良いのでしょうか。
他の電子マネーを選択したらそれらタブは一旦全部消えて、選択した電子マネーのタブのみが追加される方がいいのか、前のタブは残る方がいいのかで設計が大きく変わりますが、前のを残すと色々と無理が出そうではあります。

電子マネー名と確認した最終残高の一覧表示は間違いなくするとして、それをタブ1枚で初期画面にするのが良いのでしょうか。

操作性アイディアとして良さそうと思っているのは、アプリを起動すると強制的にドロワーメニューが左から出てきて、そこに一覧表示しておき、詳細確認したい電子マネーをタップ(選択)するとネットアクセスして最新状態をゲットしてタブ表示する方式、というものがあります。

タブも、履歴タブ1枚で済むものもあれば、Webでは月ごとにページが切り替わるもの(PiTaPaなど)もあるのでこういったものは月ごとにタブを分けた方が間違いがないと思いますし、履歴以外にも残高の有効期限などの情報を表示するタブは別途必要でしょう。

無理なく、すっきりした画面表示にするためには、複数の電子マネーのタブを混在させることはせず、常に選択した電子マネーに限ったタブのみ表示する方が恐らく良いのでしょう。

想定する対応電子マネー


ネットから残高および履歴等が確認可能な電子マネー、ポイントカード類すべて。

ただカード自体を入手しないとネットから見られないことが多いと思われるので、その入手が困難なものは、なかなか対応できないことも想定されます。

現時点で、対応できそうなものを以下に書いておきますが、関西系以外は入手困難なため、すぐの対応は難しいと思われます。
また、これ以外にも要望あり次第、全てに対応していく計画です。

・CoCGa (CGCグループ)
・litta (イズミヤ、阪急グループ)
・PiTaPa
・SMART ICOCA
・majica(ドン・キホーテ)
・uniko(ユニコ) (旧ユニー系)
・LaCuCa (ライフ)
・ほぺたんカード (コープみらい、東京・埼玉・千葉)
・吉野家プリカ (吉野家)

そのほか、以下もネットで確認できるらしいという情報を得ています。
・記名式SUGOCA
・VISAやMasterプリペイド/デビット


ご意見やご要望などは随時募集しておりますので、お気軽にコメント等でお寄せください。マストドンでも随時ご意見への対応や現状報告を実施しております。

2019/05/21(火)19:36 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

ICカードこれひとつ「バスの系統」協力募集

ICカードとバス


交通系ICカードのシェアの過半数がSuicaですので、つまり本アプリのユーザーの過半数は関東在住であろうと予想されます。今回は話が長くなりました。SuicaやPASMO圏などの方には全く無関係の話となりますから、読み飛ばしていただいて構いません。

現行の交通系ICカードは約50種類


今日時点で、日本全国で約50種類の交通系ICカードが利用されており、うち45種類が読み取れます。ICカードこれひとつはその45種類全てに対応する、日本で(というか世界で)唯一のアプリと言うことになります。

バス対応という側面からみると、全国対応のカード(10カード)では関西のPiTaPa圏でのみバス停情報を履歴に書き込みますし(念のため、ICOCA圏は書き込みません。PiTaPa圏のみです)、そもそも読めないカードや沖縄のOKICAなど一部例外を除いては、地方のバスICカードの殆どは乗降または精算バス停の番号などを記録する機能を持っています。

10カードでも、PASMO、manaca、nimocaといった各地方のバス圏ではカード内にバス停番号を書きませんから、残念ながら国民の過半数は、技術的に可能なはずの恩恵を受けられずにいると言うことになるのでしょう。もったいないことです。

バス停の情報の表示機能


さて本題に戻りまして、カードの履歴情報からバス停番号が読み取れるとなると、バス停名を表示したくなります。そのシンプルな欲求を満たすためICカードこれひとつは全力を尽くしました。
結果、現在はバス停名データベース(以下バス停名DB)として4種類のDBをアプリ内にもち(基本DB、ナイスパス用DB、ICa用DB、Rapica/いわさき用DB)、基本的なDBとナイスパス用で計7万件弱、全部あわせると10万件近い量のバス停情報を保有するに至っております。ここまでのバス停情報を持ち対応するのも、ICカードのビューアーとしては本アプリが日本で(というか世界で)唯一のアプリと言うことになるのでしょう。

これだけの情報を集めるだけでもとてつもない努力があったわけですが、現在はこのバス停名DBに、名前だけでなく、読み、ローマ字、停車するバスの路線名や系統番号、住所とGPS座標情報といった様々な情報を格納できるよう拡張が続けられています。

こういった努力と経験の積み重ね、つまりノウハウが蓄積された現在、幾つかの問題に直面してきております。
今回は、このデータベースの改良と今後について書いてゆきます。


現アプリの動きについて


「ICカードこれひとつ」は、ICカードを読み取るアプリです。
ICカードから読み取った「バス停番号」から「バス停名称ほか各種情報」を得るデータベース構成となっていて、データベースから引き出した情報を画面に表示しております。
現在、バス停名だけでなく「バスの系統」情報も需要が高まっていて、報告からクレームまで多数が寄せられておりますが、系統情報はバス停名を格納するデータベースに、停留所の情報の一部として記録されています。

しかしこの方式では、ダイヤ改正のたびにバス停名データベースから系統を探し出して修正する必要があります。
需要への対応として系統情報もデータベースに追加してまいりましたが、バスの系統は変遷が激しく、この修正作業も情報が増えるほど大変になってきています。


解決の方法


「バスの系統」情報を充実させてゆくためには、方法は一つしかありません。そのバスの系統情報をまとめたデータベースを作ることです。

従来、

「バス停番号」→「バス停名DB」→画面表示

だったものを、

「バス停番号」→「バス停名DB」と「バス系統DB」→画面表示

とし、バスの系統情報をバス停名DBから分離することが、需要を満たす最良の解決方法となります。


今後の方針と現状


現在開発中の新アプリで機能を開発中で、その開発自体は順調です。
今のところ、履歴タブと改札タブで、「バス系統DB」に情報があった場合はそちらを表示(新方式)、さもなくば従来の「バス停名DB」の系統情報を表示(旧方式)、というような試験的な実装で開発を進めています。
特に履歴タブでは、乗車と降車の双方に合致する系統のみを抽出して表示することを目指しています(乗降双方を記録するカードのみ)。

詳細情報画面では、「バス系統DB」に情報があった場合はその停留所に停車する全系統の一覧化を実現させたいと思っており、タップすることでその系統の停留所一覧表の表示→バス停名タップでそのバス停の情報表示→また系統の停留所一覧表の表示も可能…という感じで動かせるような機構を想定しています。

新旧双方の方式の混在はできませんから、新方式をするならある程度の情報が必要になります。さもないと、バスターミナルのように多数の系統が集まる停留所では、乗った系統が表示されず乗っていない他の系統が表示されるという現象が生じるため、これは確実にアプリへのクレームに繋がる動作になります。ですから、プログラム自体は完成したとしても情報が集まるまでは有効化できないだろうと思っております。ただ、バスの「系統」に関する情報は今後は原則「バス系統DB」として記録し、「バス停名DB」からは徐々に情報を抜いてゆく方針でおります。
従って、機能が有効化されるまでは、徐々にバスの系統が表示されなくなりますが、いずれ機能を有効かできるほど情報が充実したときは、改めてバスの系統情報も表示することができるようになるでしょう。

データベースの分離に成功すれば、バスの系統が様変わりしてもバス停がそのままならバス停名DBに影響が及ばなくなります。
まずデータベースを作るコストは莫大ですが、ダイヤ改正での影響範囲の調査は最小限で済むようになるため、保守費用は軽減できるのではないかと見込んでいるところです。


情報の募集について


これまで「バスの系統」情報を充実させなかった理由は一つしかありません。簡潔に言ってしまえば、極めて俗な結論ですが、お金がないからです。
ICカードこれひとつは黒字化を目指してはおりますが、このアプリは基本的に個人向けアプリであり企業向けではないですから得られる収入も多くはなく、このため黒字化もなかなか難しいため、弊社の力だけでは要望全てにお応えすることが難しい状況です。

試験的にいくつかのバス系統情報を作ってみました。手作業ではやはり時間が掛かります。ある程度熟練して効率化したとしても、短い系統で1系統あたり10分程度、長い系統は更に時間が掛かると思われ、平均1系統あたり30分程度を見込んでおくものとします。
それだけの時間を要すると言うことは、それだけのお金が掛かると言うことになりますが、今のところその投資ができるだけの収益がアプリから得られていませんから、それを弊社だけの力で実現することは無理と判断致しました。

そこで、ICカードこれひとつで、バスの系統情報を充実して欲しいという方にお願いがあるのですが、この「バス系統DB」用のデータ作成を手伝って欲しいのです。

大赤字の現状で特に何か見返りを進呈することはできないため原則としてボランティアとなりますが、弊社指定の形式か、または機械的に弊社指定の形式に簡単に変換できる形式、のいずれかでデータを作成していただき、それを提供していただきたく思っています。
提供するために作成されたデータ自体は、もちろん自由に公開していただいて構いません。弊社は、その公開された情報を活用させていただく、という形でデータを使わせていただきます。

日本国の国内法では、事実であるデータ自体は著作権の対象にならないそうですが、データ作成の労力は深く認識するところですので、クリエイティブコモンズでいえば「CC-BY」相当のライセンスであれば、データを作成された方のお名前はアプリ内に表示をさせていただきたく思っております。


データ形式


現在は開発中で、データ形式も試作中につき、今後少しずつ変更される可能性があります。

方針
・データはタブ区切りファイル(TSVファイル)とする
・文字の符号化にはUTF-8を用い、ファイル先頭にBOMは含めない
・改行は原則としてCR+LF (Windowsスタイル)

DB構成方法は二種類、分離方式「系統情報DB+系統に属する停留所一覧DB」と混在方式「系統情報DB内に停留所情報も含む」
保守性を考えると、DB内には各種の番号だけでなく、日本語の名称を含んだ方がよい。となると、それは単なるメモではなく情報として活用する方が望ましいので、DBサイズ的には非効率になるが、保守性を優先して後者の混在方式を採用するものとする。

各項目の意味
※は検索用情報で、うち一部はKEYとなる。マークなしは原則として表示用

1 ※事業者番号
2 ※系統ID
3 ※連番 (1からスタートの10進数とする。系統の停留所数が10以上の場合は01、100以上の場合は001のように頭に0を付けて桁数を合わせる)
4 ※内部利用のフラグ (未使用では0としておく)
5 ※有効期限開始日 (YYYYMMDD、特に指定がないばあいはオール0とする)
6 ※有効期限終了日 (YYYYMMDD、特に指定がないばあいはオール9とする)
7 バス=B
8 事業者名 (日本語名と英名は|で区切って併記する)
9 営業所名 (日本語名と英名は|で区切って併記する)
10 コミバスなどの名称 (日本語名と英名は|で区切って併記する)
11 路線名 (日本語名と英名は|で区切って併記する)
12 系統のフラグ(急行・特急・臨時などの情報をおく)
13 系統番号(表示用)

14 系統の起点(表示用)
15 系統の終点(表示用)
16 系統の経由地(表示用)
17 ※リレーション用の停留所番号(バス停名DBのキー)
18 停留所のフラグ(自由乗降などを表わすフラグ類おきば)
19 停留所名1
20 停留所名2
21 停留所名3


停留所のフラグ(暫定仕様)
助 = 国・自治体・沿線住民による補助路線
免 = 免許維持路線
臨 = 臨時駅・停留所
自 = 自由乗降区間(CI-CA)
由 = 自由乗降区間(CI-CA以外)

☆13と14の間に「系統のニックネーム(表示用)」も必要かもしれないと考えています。

データサンプル


ここではタブコードを ‣ 記号で表わす

奈良交通の21系統を例とする。

項目2「系統ID」はDB内で事業者番号と組み合わせて一意になる必要がある。系統番号で一意化を目指すものとするが、奈良交通の場合は営業所が違うと同じ番号を用いる傾向にあるため、営業所番号と系統番号を組み合わせて用いることとする。
例えば北大和営業所(学園前)は運行系統図でmap31.pdfとあるため、31番を営業所番号とみなし、31-21とする。
なお、奈良交通は同じ営業所番号ですら系統番号は重複するので、その場合は更に起点と終点のイニシャルを付すなどして、一意になるよう命名する。
往路と帰路で経路が異なる場合は、どちらかをA、どちらかをBなどと命名し、それを付して用いることとする。

こうして暫定仕様
0E51‣31-21‣01‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣大和町線‣‣21‣学園前駅(南)‣学園大和町五丁目‣‣033B‣‣学園前駅(南)‣‣
0E51‣31-21‣02‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣大和町線‣‣21‣学園前駅(南)‣学園大和町五丁目‣‣0121‣‣学園南三丁目‣‣
0E51‣31-21‣03‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣大和町線‣‣21‣学園前駅(南)‣学園大和町五丁目‣‣0123‣‣学園大和町‣(奈良西警察署)‣
0E51‣31-21‣04‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣大和町線‣‣21‣学園前駅(南)‣学園大和町五丁目‣‣0139‣‣学園大和町二丁目‣‣
0E51‣31-21‣05‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣大和町線‣‣21‣学園前駅(南)‣学園大和町五丁目‣‣5F29‣自‣自由乗降指定地‣(大和町①)‣
0E51‣31-21‣06‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣大和町線‣‣21‣学園前駅(南)‣学園大和町五丁目‣‣013A‣‣学園大和町三丁目‣‣
0E51‣31-21‣07‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣大和町線‣‣21‣学園前駅(南)‣学園大和町五丁目‣‣5F2A‣自‣自由乗降指定地‣(大和町②)‣
0E51‣31-21‣08‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣大和町線‣‣21‣学園前駅(南)‣学園大和町五丁目‣‣013B‣‣学園大和町四丁目‣‣
0E51‣31-21‣09‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣大和町線‣‣21‣学園前駅(南)‣学園大和町五丁目‣‣5F2B‣自‣自由乗降指定地‣(大和町③)‣
0E51‣31-21‣10‣0‣00000000‣99999999‣B‣奈良交通|Nara Kotsu‣北大和営業所(学園前)‣‣大和町線‣‣21‣学園前駅(南)‣学園大和町五丁目‣‣013C‣‣学園大和町五丁目‣‣

これを手作業でどのように効率的に作るべきかは一つの課題となりそうです。

最後に


上記のような形式で、リレーション用の停留所番号(バス停名DBのキー)、つまりカード内に書き込まれる停留所番号の欄は空欄で構いませんから、系統のDB作りをボランティアで手伝って下さる方を募集しております。

将来的に、この系統情報の最新状況もWebで一覧表示できるようにする予定ではおりますが、いつ頃になるかは現時点では未知となっております。

皆様からのご協力をいただければ幸いです。

2019/05/09(木)13:54 |Comments(0) |Trackback(0)

地域振興 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

マストドンのすすめ 21世紀の必須ツール

既に広く普及した国際標準


マストドンが実用化されて久しく、マストドンおよび国際標準プロトコルActivityPub対応の他のSNSもどんどん広まっております。

これまでの時代、SNSは、サービスの形こそ違いましたが幾多の変遷を経てもそれぞれのコミュニケーションは一つの会社により独占されている時代が続いていました。独占が成立すると運営は必ず横暴な振る舞いをし、そしてそのサービスは衰退をする、ということが繰り返されました。
そこに待望の国際標準プロトコル登場、普及によって、私たちはより自然に、より自由に、コミュニティを形成することが可能となったのです。

コミュニケーションならは今はマストドン


初期には開拓者によって使われ始めたマストドン、今では多くのユーザーに利用されており、日々、様々な新しい情報の交換がなされております。
弊社もICカードこれひとつのサポートをマストドンで実施しております。
おかげさまで様々な情報をマストドンでお寄せいただいておりますため、アプリの開発にも大いに役立たせていただいております。

専門的な話は今はマストドン


ICカード、鉄道・バス、決済、こういった人気分野では専門のサーバー(インスタンス)が複数あり、それぞれでユーザー層も異なり、それでいて活発に情報交換がされています。
もちろんここでの情報が世界最速などとは申しませんが、その話をするために集まった同志なのですから、情報の共有はかなり速いだろうことは、想像に難くありません。
新しい情報を得るための最適な手段は、今となってはマストドン一択であることを疑う余地はありません。

大抵の分野では、そのためのサーバー(インスタンス)があるでしょうから、最先端の話題で話す場は、もうマストドンに移っています。
マイナー分野であり、適当なサーバー(インスタンス)が見つからないと言うのであれば、その時は自分でサーバー(インスタンス)を用意し運用することができます(もちろん相応の技術力と資金は必要です)。これがマストドンの最大の特徴となっています。

ダイレクトメッセージもマストドン


マストドンは、各トゥート毎に公開範囲を決めることができ、話(メンション)の途中からダイレクトメッセージ(DM、メール機能)に移行する事も可能です。
更に良いのは、ダイレクトメッセージの会話であっても、それぞれはトゥートであって、URLを持ちます。
急ぎの時に大事なDMが届いた場合でも、それをふぁぼる(★を付ける)ことで、後からゆっくり確認することができ、またURLを保存しておいて後から確認、ということも、とても簡単にできます。

かつては弊社も使っておりました、今となっては懐かしいTwitterの場合、DMはただのチャットルームであって、UIが通常のツイートと全く違っていました。DMの投稿に対してふぁぼる(ハートを付ける)ことで後から確認することもできませんでしたし、その投稿単体のURLも得ることもできませんでしたから、忙しい時にTwitterで重要な情報をDMされた場合、後でそれを忘れてしまうことも良くありましたし、対応にも苦慮しておりました。

チャットルームは、見た目は良いのでしょうが真面目な用途には非常に使いにくいものでした。
情報一つ一つにURLなどの識別子(URI)が付くことは、とても重要なことです。これがマストドンではできるわけです。

情報を分散することの大切さ


情報は一箇所にまとまっていた方が分かり易いことは事実ですが、そうやって特定のコミュニケーションツールに情報が集まってしまうと、その運営が情報を独占しようとし、コミュニティはとても閉鎖的になります。

マストドンは、サーバー(インスタンス)を分散させることで情報が特定の一箇所に集まりすぎないようにしつつ、ActivityPubという国際標準プロトコルでそれぞれのサーバー(インスタンス)を結び、交信を可能とすることで、新しいコミュニティを実現しています。
複数のサーバー(インスタンス)があり、相互に交信できること自体は特段新しいものではなく、電子メールに似ています。
マイクロブログという現在の必須ツールが、ようやく往年の電子メールに技術的に追いついた、と言うこともできるでしょう。

なお、サービスを提供するコンピューターを最新版でサーバーと呼びますが、以前のバージョンではインスタンスと呼ばれていました。そこでここではサーバー(インスタンス)と併記をしています。

複数のサーバー(インスタンス)併用は当たり前


どのサーバー(インスタンス)が自分に一番合うのか?は、使ってみないと分かりません。
サーバー(インスタンス)は世界中にあるわけですから、日本より海外のサーバー(インスタンス)の方が自分の肌に合う、という人もいるかもしれません。
マストドンは、複数のサーバー(インスタンス)を併用するのが当たり前のツールです。あるサーバー(インスタンス)のアカウントを使用休止にし、いまはこちらに引っ越しました、と案内する機能も、マストドンの公式機能で提供されています。
マストドンは、ユーザーを囲い込んで独占することが難しいツールです。

マストドン用のクライアントアプリも、そういった事情にあわせて、複数のアカウントに対応するものが多く存在します。
既にマストドン用のクライアントアプリは様々なものが作られていますし、今後更に増えてゆくことでしょう。アプリを作ることに何の制限もないですし、プログラミングを愛好する方は、今こそマストドン用クライアントを作る時です。

最先端のコミュニケーションツール


時代を後戻りする事はできません。マストドンという便利な時代は、もう既に到来しているのです。
交友関係お誘い合わせの上、自分に合ったサーバー(インスタンス)を探しマストドンを使ってみてはいかがでしょうか。
どんなサーバー(インスタンス)でも、既存のユーザーが歓迎してくれることでしょう。
その時は、ぜひ弊社アカウントをフォローしてください。
ICカードこれひとつについて何度かメンションを下さった方は、こちらからフォローバックさせていただいくこともあります。

主なサーバー(インスタンス)


弊社が利用中またはフォロワーなどが利用中の主な個人運営サーバー(インスタンス)を幾つか紹介致します。
これ以外にも、企業運営で有名なものを含め大小様々なものがありますから、自分にあったサーバー(インスタンス)が見つかることを期待しております。

まちトドン
地理、鉄道やバスなど公共交通、お店から銭湯まで、「まち」に関する話題を主に扱うサーバー(インスタンス)です。
弊社アカウントはここに置かれています。

決済オタク丼
電子マネー、クレジットカードなどでの「決済」を好む人たちが集まるサーバー(インスタンス)です。
ここの管理人さんにお世話になっております。

:don:
携帯電話機やプログラミングなどを愛好する技術者などが主に集まるサーバー(インスタンス)のようです。

ボカロ丼
作詞作曲家からリスナーまで、音楽を愛好する人が集まるサーバー(インスタンス)のようです。
個人出資のようですが電気通信事業届出は法人名義になっています。


インスタンス紹介サイトも多数ありますから、そちらもぜひ検索して見て下さい。

2019/03/29(金)17:44 |Comments(0) |Trackback(0)

技術情報 | インターネット | コンピュータ | [編集]

▲ページトップ

「ICい〜カード」と「ですか」の研究について

進捗


ICい〜カードの研究について」で、情報提供を求めたところ、1件報告がありました。

乗車前・乗車中・乗車後の3情報を比較したところ、乗車時タッチの時点で乗車停留所番号が記録されており、かつ「乗車中のフラグ」らしきものが立てられていることが分かりました。

これで、ナイスパスと同様に乗車停留所・降車停留所なども表示できる可能性が高まったわけですが、一つ問題がありました。事業者をどうやって特定するか?ということです。

「ICい〜カード」と「ですか」


元々は「ICい〜カード」があり、それと互換性を持つように仕様を定めて採用したものが「ですか」です。
今なお相互利用はされていませんが、もし相互利用をするのなら、他のカードとするよりは実現は容易でしょう。
富山のパスカに対するえこまいかよりは、双方の仕様は近いものと思われます。

事業者番号はあるのか


履歴情報にあるのは確実ですが、乗車時タッチで書き込まれる情報に、果たして事業者番号はあるのでしょうか。
過去に提供いただいたダンプデータなどを眺めてみましたが、今のところ何とも言えません。ここだけは「ICい〜カード」と「ですか」で仕様が違うかもしれませんし、同じかもしれませんし、これについては情報が必要となります。

募集


バスだけでなく郊外電車も含めて、「乗車前(タッチ前)」「乗車中(タッチ後)」「降車直後」という3種類のダンプデータを募集しております。

ICい〜カードで、現行事業者番号で分類すると、概ね次のように事業者が分類されています。

伊予鉄道バス
とさでん交通(郊外電車)
とさでん交通バス (旧土佐電気鉄道グループ)
とさでん交通バス (旧高知県交通)
県交北部交通
高知西南交通
高知東部交通
ジェイアール四国バス/高知駅前観光/四万十交通

この各カテゴリーごとのダンプデータを提供いただければ、事業者番号のありかが分かり、もって停留所の特定も可能となります。

また市内電車でも、降車時タッチ後のダンプデータをいくつか送っていただけますと他との判断の情報として活用させていただくことが可能です。

ご協力をいただければ幸いです。

2019/03/19(火)18:40 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

ICい〜カードの研究について

ICい〜カードですが、バスの乗車時タッチの際に何らかの記録がされていないかどうか、という調査依頼がありました。

いただいたダンプデータは残念ながら正常に読み取れておらず情報に欠損があったため判断ができませんでしたが、もしICい〜カードでバスや郊外電車に乗車のご予定がある方、次の調査に協力をいただければ幸いです。

バスまたは郊外電車
①乗車前の状態をダンプツールで送信
②乗車時タッチ後、精算の前にダンプツールで送信
③精算し降車後、次の乗車より前にダンプツールで送信

この3情報をいただけると、少なくとも①→②の段階で、タッチ時書き込みがあるかどうか分かります。
そしてもし書き込みがあり、乗車中かどうかの情報を検出可能であれば、アプリ画面に乗車中と表示する処理を追加することが可能です。
また②→③の段階で、降車の際に変化する内容を確認できるため、乗車中かどうかの情報があるかどうか、より分かり易くなります。

鉄道であれば、きちんと出札されていないと次回乗車時に「出場(降車)記録がありません」エラーとなり、乗車できません。駅員に処理をしてもらう必要がありますが、無人駅だったり、駅員がいない時間帯だったりすると絶望的です。
何となく身に覚えがある場合、アプリで正常に出札記録されていないことが事前確認できれば、乗車する日は少し時間に余裕をもって駅に行き、処理をしてもらうことも可能になるでしょう。

興味のある方は、ぜひICカードこれひとつから報告をいただければ幸いです。

※また、同じ仕様のカード「ですか」でも乗車情報を書き込んでいる可能性がありますので、こちらでも報告をいただければ幸いです。

2019/03/18(月)18:15 |Comments(0) |Trackback(0)

製造開発 | ソフトウェア開発 | コンピュータ | [編集]

▲ページトップ

カレンダー

09 | 2019/10 | 11
- - 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31 - -

プロフィール

miraicorp

Author:miraicorp
未来情報産業(株) 社長

主として「ICカードこれひとつ」や「文字、文字コード」処理、時々C++などについて記述しています。

twitterマストドン

管理用

検索フォーム

お知らせ

コメント等お気軽にどうぞ。

気に入ったら拍手して頂けると、今後の記事を書く際の参考や励みになります。

■お仕事を募集しております
ソフトウェア製造の仕事や、原稿執筆の仕事などを随時受け付けております。
お気軽にご相談下さい

■初めての方へ
こまごまと更新しているため、他にも関連する記事があるかもしれません。
「月別アーカイブ」「検索フォーム」「カテゴリ」などをお試し下さい。
トップページはこちら

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

広告枠

メール

メールはこちら

リンク

このブログをリンクに追加する

RSSリンクの表示

QRコード

QR