yamat47/japanese_address_parser

Japanese address parser written in Ruby.

japanese_address_parser's Issues

市区町村や町が見つからなかったときの処理を書いておく。

Dockerで動かすための環境を作る。

自分の手元で Ruby がビルドできなくなってしまったので。
せっかく作るので、リポジトリにも上げておく。

Ruby 3.2に対応する

町域を前方一致で探索するのをやめる。

あまり直感的ではない一致の仕方をしてしまうことがあるので。

元々は長野県の県庁所在地の解析をするための対応だった。
こちらを特例として特殊対応する方針にする。

CSVのデータが更新されたときのこのリポジトリの更新処理の仕方を整える。

欲を言えば自動反映したい。
難しいとしたら、手順をまとめておきたい。

型定義を書く。

geolonia/japanese-addresses が提供している最新の CSV ファイルに追随していない

geolonia/japanese-addresses が提供している最新の CSV ファイルに追随していないようです。
たとえば、

geolonia/japanese-addresses#118

で issue に挙がっていた「福島県東白川郡矢祭町」のローマ字表記がデモサイトでは、「HIGASHISHIRAKAWA GUN YAMATSURI MACH」(MACH -> MACHI でないといけない)になっています。これは最新の latest.csv では修正済みです。

japanese-addresses で提供する CSV ファイルは、issues に挙がってくる問題を修正したり、ほかにも国土地理協会が提供する地名変更情報を取り込んだりと、毎月更新しているので、できれば、更新があったときに japanese_address_parser も更新される仕組みがあると望ましいと思います。

町域が全く入力されていないときに最初の一つ目にヒットしてしまう。

小字・通称名を考慮して解析する。

例えば「沖縄県宮古島市平良字西里186」は解析できない。
元データのふりがな欄も不十分だが、とりあえず解析できるようにする。

最新のRuby（head）でCIを実行できるようにする

関連Issue

• #90
• #96

内容

• #97 によってraccがbundleされるようになったため、最新のRubyでCIを再度動かせるようにする

英数字を漢数字に変換する仕組みを別のライブラリに切り出したい。

住所のパースをしている処理が不要になったので掃除をする。

#30 をマージしたことで不要になったコードがたくさんある。
ドキュメントの更新と合わせて対応する。

解析に失敗したとき、例外を吐かないようなモードに切り替えられるようにする

Steepでの型検査を試してみる。

parser gemを最新にしてraccがbundleされている状態にする

関連Issue

• #90

内容

rubyのheadでCIが落ちる原因はraccがdefaultのbundledから外れてしまっていることが原因のようです。
そのため、raccを利用しているparser gemをupdateすれば最新のRubyでCIが動かせるようになると思います。

参考

• whitequark/parser#927
• https://bugs.ruby-lang.org/issues/19702

ドキュメントを充実させる。

町丁目がない住所データに対して誤ったふりがなデータが返ってくる

町丁目がない住所データに対して、以下のように誤ったふりがなデータが返ってくる。

[1] pry(main)> JapaneseAddressParser.call('富山県滑川市1-1').furigana
=> "トヤマケンナメリカワシアカハマ"
[3] pry(main)> JapaneseAddressParser.call('東京都調布市1-1').furigana
=> "トウキョウトチョウフシコクリョウチョウ"
[4] pry(main)> JapaneseAddressParser.call('東京都三鷹市1-1').furigana
=> "トウキョウトミタカシキタノ 4"

都道府県のリストを表示するときに参照しているCSVにたどり着けていない

irb(main):001:0> JapaneseAddressParser.call('東京都北区赤羽1-2-3')
/Users/yamat47/.rbenv/versions/3.1.0/lib/ruby/3.1.0/csv.rb:1433:in `initialize': No such file or directory @ rb_sysopen - lib/japanese_address_parser/data/prefectures.csv (Errno::ENOENT)                                                      

依存しているライブラリのバージョンをどんどん更新していきたい。

schmoozeの型をpolyfillで入れているのを公式なものにする。

住所の文字列の正規化の幅を広げる。

デモページへのリンクを貼る。

https://japanese-address-parser-demo.herokuapp.com/

処理の効率を上げたい

Schmoozeを使うようになり、明らかに処理にかかる時間が延びた。

何かしらの方法で、パフォーマンス改善をしたい。
キャッシュ？ トランスパイル？ 独自実装？

元のCSVデータに旧字体で登録されているときにうまく解析できていない。

解析するときには表記揺れを防ぐために旧字体を新字体に置き換えている。
これが CSV データの方で行われていないため、町域が見つからなくなってしまっている。

市区町村の役所の住所のテストを追加する。

いろいろなところをテストに追加したい。

CIで並行して処理する内容をrspecだけにする。

RuboCop や Steep のチェックは一回だけ実行すればいい。
並行処理する中に入れるとリソースが勿体ない。

とりあえず公開する。

そこそこ動くようになったので。

最新のRubyでCIが失敗するようになってしまっている。

参考: https://github.com/yamat47/japanese_address_parser/actions/runs/5630989328/job/15257504912

3.3 の preview1 では問題なく動く。
さらに最新のバージョンだと動かなくなってしまっている。

一時的に CI で head を実行するのを停止する。

「愛知県名古屋市中村区名駅1-1-10」のふりがなデータが正しくない。

pry(main)> JapaneseAddressParser.call('愛知県名古屋市中村区名駅1-1-10').furigana => "アイチケンナゴヤシナカムラクメイエキ(1-1-8、1-1-12、1-1-13、1-1-14、1-3-4、 1"

「愛知県名古屋市中村区名駅1-1-10」のふりがなデータが正しくない。
「アイチケンナゴヤシナカムラクメイエキ 1」と返してほしい。

READMEのCIバッジが壊れている

CIの設定ファイルの名前が変わったのが原因。

住所を解析するときに呼び出す仕組みがエラーを返したときにハンドリングできていない

稀に、住所を解析するときに Schmooze を使って呼び出す仕組みがエラーを返すことがあるみたい。
そういうときに、このライブラリで吸収して適切なエラーを返すようにしたい。

CIの並列実行の数を増やして実行時間を短くしてみる。

市区町村の解析をするときに表記揺れがあると対応できていない。

geolonia/japanese-addressesのデータをgit submoduleとして取り入れる。

Ruby2.6のサポートを切る。

ついでに、依存する gem のバージョンを上げる。

0から始まる市区町村コードの場合にCSVのパースが失敗している。

https://qiita.com/fisherman08/items/84c0c380de96fa3ee591 の話。

「full_address」メソッドの使用例コメントが実際の結果と異なっている

Actual実行結果が正しいと思うので、READMEを修正するPRを作成いたします！

Expected

address = JapaneseAddressParser.call('東京都港区芝公園4-2-8')
address.full_address #=> "東京都港区芝公園4-2-8"

Actual

address = JapaneseAddressParser.call('東京都港区芝公園4-2-8')
address.full_address #=> "東京都港区芝公園四丁目"

デモ環境の URL を新しいものに更新する。

see: yamat47/japanese_address_parser_demo#13

geolonia/japanese-addressesのバージョンを更新する。

いくつか差分があったので。