大字・字の地域
たとえば山形県西置賜郡飯豊町をみると、大字は大字で番号が振られていますが、字は大字の下にぶら下がる形になっていないですね
小字階層で親がない(大字番号0)状態で小字に連番で付番されているようです。
住所を上から順にたどっての検索を実装するにあたり、この仕様では大字が確定できないので使い物にならなそうです。将来的に改良されるのでしょうか。
大字・字の地域
たとえば山形県西置賜郡飯豊町をみると、大字は大字で番号が振られていますが、字は大字の下にぶら下がる形になっていないですね
小字階層で親がない(大字番号0)状態で小字に連番で付番されているようです。
住所を上から順にたどっての検索を実装するにあたり、この仕様では大字が確定できないので使い物にならなそうです。将来的に改良されるのでしょうか。
日本の住所の処理
地方公共団体コード6桁のうちチェックディジットを削った5桁を使うのは確定で、町丁以下の階層をどう処理するかを長く考えていますが、少なくとも郵便番号は使い物にならないかなという印象です。
地方は地番によって郵便番号が変わったり、都内でも同じ町で丁目の違いで郵便番号が違っていたりするので使いにくい。
違う意味で使いにくいのですがデジタル庁の
https://www.digital.go.jp/policies/base_registry_address
市区町村の下の町字に7桁の番号を振る machiaza_id を使うことを検討しています。
5桁+7桁の12桁で、町大字小字の階層までは確定できるようです。丁目までいれる場合は更に数桁必要。
独自に付番するような運用よりはずっと汎用性が高いと思われますが、いくつファイルがあるのか分からないものを全部ダウンロードして手作業で使えるDBを生成するのはかなり難しそうというのが目下最大の課題
DBが実現した暁には物販報告で将来作り直しのさいに入力された住所でサーバー検索して12桁のIDを付け加え、IDがつかない住所はおそらく入力ミスなのでエラーとして弾くような運用を想定しています。
日本の住所を処理するのは難易度が高すぎますね。
難易度が高いということはその分コストがかかるということでもあります。
辞書でマッチングして…などというのは実現不可能な夢想ですね
とにかく日本の住所のヤバさをもっと知るべきだと思います
https://note.com/inuro/n/n7ec7cf15cf9c
#ICカードこれひとつ
次のバージョンですが、早ければ明日にリリース予定です
いくつかの不具合修正および物販報告機能の改良などを実施します
明日リリース迄の作業時間に余裕があれば明日の報告も対応できるかもしれませんが、交通については今時点を暫定的な締め切りとさせていただきます。
物販については可能な範囲で対応しています。
物販機能の値上げ＋物販報告の高速対応は既にご案内のように予定はしておりますが、今のところ満足いく業者が見つからないため進捗がありません。
もし物販対応をやりたい、という方がおられましたらお知らせ下さい。報酬などについてご相談させていただきます。
#ICカードこれひとつ
セブン‐イレブン 水戸渡里町西店
同じ項目から
1/2 左側
2/2 左側
が報告されているようです。
いずれもレジ番号欄が空欄となっておりました
レシートのレジ番号を記載の上で再報告をいただければ幸いです。
#ICカードこれひとつ
「推し払いキーホルダー 魔法少女まどかマギカ」のダンプデータが報告されました。
https://www.sony.co.jp/Products/felica/osk/
Edyとしての機能のほかに「推し払いキーホルダー」としてのシステムコードを持っていますが、そのシステム内にはサービス(データ)は何も登録されていませんでした。
従って推し払いキーホルダーの種類などを判定することはできません
このシステムコードが推し払いキーホルダー専用なのかは現時点で不明ですが、そのように判断して対応します
このアカウントは、notestockで公開設定になっていません。
この例は良く見たら卸売なので例としてよくなかった
小売だとあんまり細分化されていませんが、
5692 洋品雑貨・小間物小売業
が
56921 下着類
56922 小間物・化粧道具
と分けられるので、例えば靴下専門店は56921、ネクタイ専門店は56922、などのように分けられる
追加
4 将来的に、4桁の産業分類に1桁付け加え、5桁の商品分類番号の入力に対応させる？
データ例
https://www.pref.ibaraki.jp/kikaku/tokei/fukyu/tokei/betsu/syogyo/syogyo19/
このページの一番下、「付表03販売商品による産業分類及び業態分類」のエクセルファイルなど
例えば、報告でよくありそうな
5494 スポーツ用品・娯楽用品・がん具卸売業
は、
54941 スポーツ用品
54942 娯楽用品・がん具
に分ける手段が存在するらしい
#ICカードこれひとつ 新物販報告画面のメモ
日本標準産業分類をより報告しやすくするため、将来的に以下を実装したい
1 小売店や飲食店などよく使う場所にダイレクトジャンプできるようなショートカット機能
2 よくある店のカテゴライズ（コンビニ、ミニスーパー、牛丼屋、などなど）から選ぶ機能も欲しいが、始めると収拾が付かなくなる可能性が高い
3 よく使う日本標準産業分類を履歴として残し選べるようにする機能
以上で産業分類の入力率を高め、なんの店かよく分からず情報を埋めるのに膨大な時間を要する問題を解消していきたい
カフェ・ベローチェ 中洲川端駅前店
3年前の報告と今年1月の報告で交通系SPRWIDが変化しているようです
最近の報告では交通系SPRWIDが記載して報告されているため、このブランドに限らずシャノアール系全般かもしれませんが、IC R/Wの変更およびレシートへの交通系SPRWIDの印字が行なわれる変更が生じているようです。
https://ja.wikipedia.org/wiki/%E3%83%A4%E3%83%9E%E3%83%80%E9%9B%BB%E6%A9%9F
屋号としては
テックランド
LABI
ヤマダモバイル
ヤマダアウトレット
家電住まいる館
などがあるらしいのでこれを屋号にすることになるのかもしれませんが、ヤマダデンキであることがほぼ分かりませんね。
会社側がそういう方針なのかもしれませんが
#ICカードこれひとつ
ヤマダデンキ(旧ヤマダ電機)の店名、屋号、どのようにするべきか考える必要がありそうです
たとえばLABI●●店なら、屋号をLABI、支店名を●●店とするべきなのか、
または従来通りに屋号をヤマダ電機またはヤマダデンキにして、支店名をLABI●●店にするべきなのか
#ICカードこれひとつ
コクミンドラッグ 渋谷マークシティ店
昨年6月に交通系がJREM BT2、9月にWAONがJT-R550CRで報告されており
その間にIC R/Wが交換されたということで宜しいのでしょうか、それとも交通系とWAONは別端末なのでしょうか
#ICカードこれひとつ
昨年、道後温泉本館が交通系電子マネーで報告されております
GMO-FGかGMO-PGかは不明ながらGMOとのことでした。
ここは松山市営らしいので、契約締結などに関する何らかの公開情報があるのかも知れませんが、今のところは不明です
京都・四条河原町界隈ですが、5日にドン・キホーテ 京都四条河原町店が開店したようですね
https://www.donki.com/store/shop_detail.php?shop_id=612
他店同様、交通系電子マネーに対応するようです。
@spinda_kkmr 情報ありがとうございます。
一応確認しましたが、それらしき路線については現状有効な登録はないようでした。
@NagisaTakayama 電話番号、全数チェックはできていないのですがそれでもかなり間違いがあって、見つけ次第修正はしているのですが、この状況でダイアル機能とか実装してしまっても大丈夫なのか不安がありまだ思い切れていません。
#ICカードこれひとつ
店名とかSPRWIDとか、表示だけじゃなくて、クリップボードにコピーする機能はやっぱり必要。弊社での調査でも不便するので。
今の物販の作り直しと一緒にふくめていきたい。
住所はボタンですが、他は何もないところをロングタップでいきなりコピーしましたっていうトーストを表示して処理完了にするか、せめてメニューは出すか。
とりあえず詳細表示の画面もがっつり作り直しする必要があるかも。なかなかアプリを作る時間が取れなくなってしまいましたが、真夏までには何とかしてリリースしたい。
3月3日に「おみやげ小路 京小町 南館」を報告された方：
ここは複数のお土産屋さんがテナントとして並ぶ場所のようです。
レジが共通でないのであれば、店名として「おみやげ小路 京小町 南館」は適切ではなさそうです。もしそうであれば、実際の店名に記憶があればお知らせいただければ幸いです。
このアカウントは、notestockで公開設定になっていません。
作るかどうかはともかくとして、ポール座標の情報をバス停名DBから分離するとした場合の想定
バス停名DBからは座標や住所らしきものは消す。
バス停ポール座標DBを新たに作り、ポールのボタンはこのDBを参照して表示する。
「中心座標」のレコードと、各ポールのレコードが必要になる。
詳細画面でボタンをタップすると、メニュー最上段に詳細表示メニューを入れ、バス停ポール座標DBにある情報を表示する。
バス停ポール座標DBに入れるべき内容
DBのキー情報のほかは、副名称的なもの(広告?)と、座標情報でしょうか。
将来的には系統DBを引いてそのポールに停車する系統の表示も？
ポールごとにバス停名が違う場合
バス停DB側で別の枝番を用意し、DBキー自体変えて混在表示しない方が混乱が少なくて良いかもしれない。必要なら他の枝番の情報も表示できるけど必要かどうかは不明。
とてつもない工数掛かりそう
@NagisaTakayama 今は全部出ます。
件数の制限機能を付ける予定でしたが、しばらく後になりそうです。
今のところは、試験的に確認する以外は表示をOFFにする方が実用的かと思われます。
バス停といっても複数のポールがあります。
系統によって、停まるポール位置はほぼ固定なので、系統情報内に停車するポール位置まで明記することが究極的には可能でしょう。
そうなるとバス停名DBの方も仕様変更が必要になるのかもしれません。
今はポールの座標情報を補足として書き連ねていますが、これを分離して一意に特定する番号を付してあげる必要があるのかもしれません。
今のところ枝番で対処しようと考えていますが、そうではなくポールごとに完全分離する方が本来的には良いのかもしれません。
メンテナンスが大変なことになりますが、座標情報も1レコード1情報となれば、店舗検索と同様、検索処理もやりやすくなるでしょう。
