サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
地方公務員の非正規化が進んでいる。非正規公務員は15年で1.5倍に増加。4人に3人が女性という割合だ。当事者を中心に昨年設立した支援団体「公務非正規女性全国ネットワーク（通称・はむねっと）」は、自立できない賃金水準にあることなどの実態を明かし、このままでは「公共サービスが持続できなくなる」と警鐘を鳴らす。20日に都内で設立1周年の集会を開く。（畑間香織） 都内の放課後児童クラブで働く女性（48）は3月末で退職することを決めた。女性の給料は手取り月14万円、年収は200万円に満たない。単身のため、収入を増やせないかと、別の仕事を入れることも考えたが、児童の相手をしながら事務作業に追われる状況では体力的に難しく限界だった。女性は「現場を担うのは非正規やパート。行政がこの待遇で仕事をやれる人に甘えている」と憤る。
note.com を読みました。私自身も日本の住所の扱いを何とかしないと業務アプリケーションの運用に支障が出ると感じ、2003年に「住所正規化コンバータ」というソフトウェアをリリースし、20年が経過しました。現在は国際航業株式会社様に取り扱っていただいています。 www.kkc.co.jp このブログにあるような指摘にどこまで応えられただろうかということで、社内で試してみました。利用したバージョンは最新の R7.2.0 で、住所マスタは2022年秋版と組み合わせました。その結果を公開します。 住居表示 丁目表記と地番表記の混在に対応しています。 浦安市舞浜2-1-1 郵便番号 都道府県 市区町村 町域 小字・丁目 番地・号 マッチレベル 2790031 千葉県 浦安市 舞浜 2 1-1 号レベル 浦安市舞浜2-11 郵便番号 都道府県 市区町村 町域 小字・丁目 番地・号 マッチレベル 2
Geolonia がオープンソースで公開している住所正規化エンジン normalize-japanese-addresses のバージョン 3 を公開しました。 住所マスターの更新 これまでのバージョンでは、国土数値情報や郵便局データを使った住所マスターをベースに動作していました。今回のバージョンでは、住所マスター自体も更新しております。具体的には、デジタル庁が公開しているアドレス・ベース・レジストリ（ABR）を元に作り直しました。 これにより、正規化できる住所の網羅性、精度の向上、更新頻度の安定化が期待されます。 デモサイトのご案内 新バージョンを早速お試しいただけるデモサイトをご用意しました。ぜひご利用ください。 デモサイトはこちら 出力形式の変更点 v3 へのアップグレードの際には、出力形式が変更されているためご注意ください。 v2 はそのまま利用いただく場合は出力形式が変わりません
T/O と書きたいところだけど説明してみる。 実際に相続とかで戸籍を取ってみればわかるけど、現状の戸籍って個人（名前・性別・生年月日）と住所と血縁関係のリレーションテーブルなんだけど、主キーであるはずの住所が更新されないことが当然とされているっていう、DB的にはかなり不都合のある状態なんだよね。 あと血縁関係についても正確さが保証されていないし。 それだったら、ちゃんとメンテされるリレーションテーブルを作ろうよ、というのが戸籍廃止論で、正規化を理解しているまともなITエンジニアなら全員理解できると思う。 （正規化を理解しているまともなITエンジニアは少数かもしれないけど）
はじめに 数か月ほど前、住所の正規化が話題になりました。こちらの記事が特に有名ですね。 関連して、こちらの記事も話題になりました。 当時はほかにも色々な人が日本のヤバい住所の例をあげてくれて、とても楽しかったです。 実は弊社でもAddressianという住所正規化サービスを提供しています。初めて目にする変わった住所を見かけたら、とりあえず自社のAPIに投げてみて「おお、正規化できた」「すごい！」などといいながら遊んで働いています。 サービスは無料で利用できますが、今までは利用の手順が面倒でした。 ユーザー登録する APIキーを発行する 住所正規化APIを呼び出すプログラムを用意する（サンプルコードあり） プログラムを実行して住所を正規化する そこで、もっと気軽に住所正規化を試してもらえるように、ユーザー登録しなくても使えるデモ機能を作ってみました。 デモ機能の概要 住所正規化デモ画面 こち
Sansan Engineering Unit マスターデータグループ（データ戦略部門）の松本です。 私たちのチームは、「Activating Business Data」というミッションを掲げ、企業の活動の礎となる重要なデータ、いわゆる「マスターデータ」とその利活用という課題に、技術を駆使して向き合っている組織です。 さて、ビジネスデータを扱う上で「住所」は欠かせない情報です。 それは単に「モノを届ける場所」を示すだけではありません。 お客様を深く知るための「解像度」になる: 顧客のオフィスの位置を正確に知ることは、効果的なマーケティングや営業戦略を立てる上で不可欠です。 データ統合の「鍵」になる: 複数のサービスやデータベースに散らばったお客様の情報を「同一人物である」と正しく繋ぎ合わせる（名寄せする）際、住所は氏名と並んで最も重要なキー情報となります。 このように、正確な住所データは
NFCではそのまま「パ」として表されますが、NFDでは「ハ」（基底文字）と「゜」（結合文字）の組み合わせとしての「パ(UTF-8でe3 83 8f e3 82 9a)」（合成文字）で表されます。試しにNFDで正規化された「パ(e3 83 8f e3 82 9a)」を任意のテキストエリアに貼り付けて削除してみると、半濁音のみが取れて「ハ」のみになると思います。 このように文字列の正規化形式が異なる場合、単純な比較演算子での評価は困難であり、文字列によっては想定外の挙動を引き起こす可能性があります。 特にMacファイルシステムではNFDを正規化方式と採用しているため、NFC/NFD問題が度々引き起こされています。先日(2023年03月27日)リリースされた「macOS 13.3 Ventura (22E252)」では、ファイル名に濁音や半濁音が含まれるファイルがFinderから開けなくなる
「日本の住所のヤバさ」が6月7日朝にTwitterトレンドになっている。住所表記の正規化・名寄せがいかに難しいかを解説した、inuroさんのnote記事「とにかく日本の住所のヤバさをもっと知るべきだと思います」がバズっているためだ。 6月4日のテレビ番組で、マイナンバーカードに記載される住所をめぐり、河野太郎デジタル大臣が「将来的にはAIの技術を使って住所の表記揺れを判断することがあり得るかもしれない」と発言し、住所の正規化についてネットで議論になっていたことがきっかけだ。 記事は、「日本の住所システムがカオスで、その計算機的な処理がいかに困難か」を解説する内容だ。 まず、日本にはそもそも、新旧の2つの住所システム（A町1丁目3番2号／A町1234番地）が併存しており、例えば、「浦安市舞浜2」の住所が「舞浜2丁目」「舞浜2番地」の2系統あるケースを紹介。 さらに、まったく同じ住所表記が異な
しのゆー𝕏酒クズエンジニア @shinoyu これ経由で元のコードよんだけどなかなかつらい実装になってて、ないちゃった github.com/IMI-Tool-Proje… 絶対これ以外あるでしょ....うわー twitter.com/yuya_presto/st… 2023-06-06 16:31:52 ypresto @yuya_presto 経済産業省・デジ庁が公開していたものの朽ちてしまっていた住所正規化ライブラリ、いろいろ手直しして動く状態にしました！ 河野大臣が挙げていらした「東京都港区赤坂１丁目２の３」も正規化できます。 ブラウザ上でのお試しにも対応しました！ imi-enrichment-address.vercel.app github.com/ypresto/imi-en… 2023-06-06 16:02:27 リンク GitHub imi-enrichment-a
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
バージニア大学で高度道路交通システムを研究するノア・グッド―ル氏が、2021年10月に「部分自動運転車の安全性統計を正規化する方法について」という論文を公開しました。この論文を基にテスラの自動運転車の事故データを正規化すると、「テスラの自動運転システムであるオートパイロットは同社が主張するよりもはるかに安全性が低いことがよくわかる」とジャーナリストのエドワード・ニデルマイヤー氏は主張しています。 View of A Methodology for Normalizing Safety Statistics of Partially Automated Vehicles (PDF)https://engrxiv.org/preprint/view/1973/3986 You know how I've been saying since 2016 that Tesla's compariso
位置情報に関連するクラウド事業を手掛けるGeolonia（東京都渋谷区）は8月16日、住所の表記揺れを正規化できるサービス「クイック住所変換」の提供を始めた。表記ゆれしているExcelデータをアップロードすると、住所を正規化し、緯度経度の情報を付与できる。利用料は1000件まで5000円だが、正規化だけなら半額になる。 クイック住所変換では、番地・号レベルまで住所の正規化が可能。テストデータで検証したところ、約98％の精度で正規化ができたという。デジタル庁のアドレスベースレジストリや法務省の登記所備付地図データ、国土交通省の位置参照情報などを参照し、正規化変換を行っているとしている。
カロリング芋虫🐟 @Osayadon 専門職の非正規化は恐ろしい。昇給もせず継続雇用の保証もないので、いつも失業の不安にさらされるし、貯金もできない。その職に就くのに必要な資格や専門知識を得るのに払った教育費が全然ペイされないどころか下手すると借金が出来るので、目指す人はそのうちいなくなる。 2021-04-07 08:47:09 カロリング芋虫🐟 @Osayadon 専門職の人があまりに食えないからと足を洗ったり、有資格者を雇うと金がかかるから単純作業と見做して無資格で最低賃金でパートにしようとなっていく。そうすると文化教育関連の底がむちゃくちゃ下がると思うのだが。 2021-04-07 08:52:56
[レベル: 上級] Google の Gary Illyes（ゲイリー・イリェーシュ）氏と John Mueller（ジョン・ミューラー）氏、Martin Splitt（マーティン・スプリット）氏の 3 人が『Search Off the Record』というタイトルで SEO をテーマにしたポッドキャストを配信しています。 エピソード 9 では、重複コンテンツの処理についてゲイリーが詳しく説明しました。 Google 検索の内部の動きに関心がある人にはとても興味深い内容です。 この記事で内容を完結にまとめます。 Google が重複を検出し正規化する仕組み 重複コンテンツの処理は次の 2 つのプロセスで成り立っています。 重複検出 正規化 それぞれを順に説明します。 重複検出 重複検出は、URL は異なるけれど中身が同一のページを識別するプロセスです。 同じあるいはほぼ同じとみなしたペー
過去30年間に進行し、私も含めていろいろと議論されてきた労働力の非正規化の一つの解釈として、それまでは企業メンバーシップに包摂されていたミドルスキル労働者が非正規化していったというのがあるわけですが、その一つの例証のような記事が、noteに載っていました。「やま」さんという方の吐露です。 https://note.com/yama0117/n/n39d6666beb0b ○事務派遣時代 私は3年半ぐらい生産管理の事務派遣をしていた。 生産計画を立て日々の進捗を確認してやる仕事。 一品毎に仕様が違う部分があるので設計にフォローを入れて特殊品がある場合は先に購買に情報を流し、更には営業が入れた納期が本当かの確認を行い、生産進捗を行うというまあ後から分かったけどかなり大変な生産管理を経験した。 正社員と同じで担当ラインを持ち、そこを任されるという形。 はっきり言って正社員の方々より上手くやれてい
こんにちは、MNTSQでSREとして勤務している中原といいます。 プライベートも含めて、技術記事は久しぶりな気がします。がんばります。 さて、さっそくですが、日本人にとって、あるいは、韓国の方や中国の方も含めて、コンピュータ上でそれぞれの国の言葉を扱おうとしたときに苦労するのが文字コードです。 かつては（あるいは今も）、Shift JIS、EUC-JPなど、OSや環境などによって使われる文字コードが異なり、相互の連携や、同じOSでも設定次第で大いに苦労したものでした（と聞いておりますし、個人でPCを楽しんでいたときには苦しんだりした記憶があります）。 そうこうしているうち、多くのOSで標準的な文字コードとしてUnicodeが採用されるようになりました。Windowsでは内部でUTF-16LEを採用しています。Linuxでは、UTF-8を標準とすることが多くなりました。 Unicodeに統一
減少を続ける、日本の1人あたりGDP。デフレで売上高が伸びず人件費を抑制することで、更なる悪循環が生まれています。ここでは、銀行での勤務経験をもつ、監査法人アヴァンティア・法人代表CEOの小笠原直氏が「1人あたりの生産性」と「給与」について解説していきます。 GDPに見られる…「日本経済の悪循環」の深刻な状況わが国の1人あたりGDPは、2020年におけるIMFの報告によると、世界23位、4万146ドルです。 私が銀行に入行したバブルの1990年においては、世界8位で、G7先進国ではトップでした。今や人口が約2.5倍のアメリカにGDP総額ということでなく、1人あたりGDPでもかなわない状況です。早晩、韓国にも追い抜かれるという試算もあります。 企業においては、1人あたり売上高がこれにあたります。「生産性」を示す指標ですが、巷間、相対的に低い、といわれているのは1人あたり売上高が伸び悩んでいる
【AI・機械学習チーム ブログリレー2日目】 AI・機械学習チームの池嶋 (@mski_iksm) です。 私達のチームでは、機械学習バッチの実行方法やインターンを含む新配属者のPC初期セットアップ手順など多くのドキュメントがGitLab上で管理されています。Gitでドキュメントを管理するのは、Wiki等と比較して更新時のピアレビューがしやすかったり、CIによる自動チェックがやりやすかったりなどのメリットから採用されています。 CIの自動チェックの１つとしてリンクチェッカーがあります。これは切れているリンクがないかを更新時にチェックするものです。 ある日、ファイルはあるように「見える」のに、なぜかリンクチェッカーのCIが落ちているという事象が発生しました。 タイトルでネタバレしているのですが、原因はUnicodeの正規化でした。 この記事では、何が起きていたのか？どのようなケースで起こりう
choo @choo_s 住所の正規化がいかに難しいかで盛り上がっていて、なんか嬉しい😊 住所関連の開発、個人的にもかなり長い時間をかけたのですが、一番ヤバいと思ったのは ・新潟県新潟市北区東栄町（とうえいちょう） ・新潟県新潟市北区東栄町（ひがしさかえまち） という２つの「異なる」地域が存在することです。 2023-06-06 14:49:36 choo @choo_s なお、この２つの地域は距離が少し離れているらしく、それぞれ別の郵便番号が振られています…！ ただ、片方は住居地域、もう片方は競馬場の厩舎がある場所らしく「どこまで混同されて重大なミスにつながるかは未知数」(※)らしいですｗ ※Wikipedia：ja.wikipedia.org/wiki/%E5%8C%97…) pic.twitter.com/9rN8Fd0yav 2023-06-06 17:18:32 リンク Wik
[レベル: 上級] ページ分割している構成で、すべてのページを 1 ページ目に正規化することができます。 Google の推奨は自己参照の rel=”canonical” EC サイトのベストプラクティスを解説するドキュメントでページ分割について Google は次のように指示しています。 ページ分けされたページ列の最初のページを正規ページとして使用しないでください。代わりに、固有の正規 URL を各ページに付与してください。 2 ページ目、3 ページ目、4 ページ目……を 1 ページ目に正規化することを Google は勧めていません。 それぞれのページには、自分自身の URL を指定した自己参照の rel="canonical" を設置するように推奨しています。 こうすることで、ページ分割したすべてのページをインデックス対象にできます。 ユニークなコンテンツが各ページに十分にあれば、2
ラウドネス・ノーマライゼーションを改めて考える ラウドネス測定法がITU-R BS.1770として定義されてから17年、日本には主としてTV放送運用規定 ARIB TR-B32として導入されてから9年経った2020年現在。また、近年は動画/音楽ストリーミングサービスにラウドネス・ノーマライゼーションが導入されたことで、ラウドネス・ノーマライゼーションに対する解説記事が増えてきました。 本投稿は下記ITmediaに掲載された「君は音圧戦争を生き抜けるか？ 音楽ストリーミング時代のラウドネス・ウォー対策, 山崎潤一郎, 君は音圧戦争を生き抜けるか？ 音楽ストリーミング時代のラウドネス・ウォー対策 (1/3) - ITmedia NEWS . 20200731閲覧」(以下本記事)に対するカウンター投稿です。 明確な誤り 本記事には明確な誤りがいくつか見受けられます。まずはそこを訂正します。 ラウ
AWS Glue DataBrew の発表 – データのクリーニングと正規化を迅速にするビジュアルデータ準備ツール | Amazon Web ServicesAmazon Web Services ブログ AWS Glue DataBrew の発表 – データのクリーニングと正規化を迅速にするビジュアルデータ準備ツール 分析の実行、レポートの作成、あるいは機械学習の導入を始めるには、使用するデータがクリーンで適切な形式であることを確保する必要があります。このデータの準備ステップでは、データアナリストとデータサイエンティストに対し、カスタムコードの記述や、多くの手動操作が要求されます。そこではまず、データを見て、利用できそうな値を把握し、列同士の間に相関があるかどうかを確認するための簡単な可視化機能を構築する必要があります。その後、想定を外れた通常以外の値をチェックします。たとえば、200℉（93℃）を超えるような気温や、200mph（322 km/h）を超えるトラックの速度、そして欠落しているデータなどを洗い出します。多くのアルゴリズムでは、特
なぜ書くのか？ SIerでがっつりSQLServer(RDB)を使って開発をしていたため、 正規化思考が抜けずFirestore(NoSQL)のDB設計をするにあたってかなり苦労したので、 同じ苦労をしている方へFirestoreの設計を学習する入り口を書こうと思いました。 RDBとFirestoreの違い 個人的に一番苦しんだ違いは**テーブル結合(inner join, outer join)**ができなかったことです。 Twitterのフォロー一覧のような機能を作ることを例に見ていきます。 RDBの場合 ユーザーテーブル id name imageUrl profile_text
![[Firebase]Firestoreの設計の思考法(正規化/非正規化)](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f685ac2122c268932bd927afbd5b6adbfecf1be60%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fres.cloudinary.com%252Fzenn%252Fimage%252Fupload%252Fs--BfSyQQRK--%252Fc_fit%25252Cg_north_west%25252Cl_text%253Anotosansjp-medium.otf_55%253A%2525255BFirebase%2525255DFirestore%252525E3%25252581%252525AE%252525E8%252525A8%252525AD%252525E8%252525A8%25252588%252525E3%25252581%252525AE%252525E6%25252580%2525259D%252525E8%25252580%25252583%252525E6%252525B3%25252595%25252528%252525E6%252525AD%252525A3%252525E8%252525A6%2525258F%252525E5%2525258C%25252596%2525252F%252525E9%2525259D%2525259E%252525E6%252525AD%252525A3%252525E8%252525A6%2525258F%252525E5%2525258C%25252596%25252529%25252Cw_1010%25252Cx_90%25252Cy_100%252Fg_south_west%25252Cl_text%253Anotosansjp-medium.otf_34%253APictoMki%25252Cx_220%25252Cy_108%252Fbo_3px_solid_rgb%253Ad6e3ed%25252Cg_south_west%25252Ch_90%25252Cl_fetch%253AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzhiNGUyMTc1MmUuanBlZw%253D%253D%25252Cr_20%25252Cw_90%25252Cx_92%25252Cy_102%252Fco_rgb%253A6e7b85%25252Cg_south_west%25252Cl_text%253Anotosansjp-medium.otf_30%253A%252525E6%252525A0%252525AA%252525E5%252525BC%2525258F%252525E4%252525BC%2525259A%252525E7%252525A4%252525BEHAKATOMO%25252520tech%25252520blog%25252Cx_220%25252Cy_160%252Fbo_4px_solid_white%25252Cg_south_west%25252Ch_50%25252Cl_fetch%253AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzg3MjllMjc4ZTcuanBlZw%253D%253D%25252Cr_max%25252Cw_50%25252Cx_139%25252Cy_84%252Fv1627283836%252Fdefault%252Fog-base-w1200-v2.png&f=jpg&w=240)
NTT Tech Conferenceは、NTTグループのエンジニアたちが一堂に会し、NTTグループ内外のエンジニアたちと技術交流を行うためのカンファレンスです。ここで、細田氏が「PDFのコピペが文字化けするのはなぜか？〜CID/GIDと原ノ味フォント〜」をテーマに話します。続いては、文字化けが起きたPDFの修正方法と、文字化けを起こさない対策方法について。前回はこちらから。 もらったPDFの文字化けを修正するには？ 細田真道氏（以下、細田）：文字化けを修正するにはどうすればいいかを説明します。誰かからもらったPDFが文字化けしていたとします。データ分析したいとか、検索したいときに困りますね。一番簡単なのは、正規化しちゃう。これはテキストを抽出してから、問題のブロックの文字を対応する通常の漢字に置き換えるように正規化すれば、データ分析ということならこれでできると思います。 あとはちょっと荒
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事の目的 「テーブル設計、ほんとにこれがベストなのかな...?」 と思うことありますよね。シンプルなテーブル構造だと普通に正規化すれば問題なく運用できるんですが、ビジネスルールが複雑だったりするとあえて正規化を崩した設計を行うこともあります。ですが、「正規化を崩して何が嬉しいのか?」を論理的に考え、メリット・デメリットを考慮することによって、うまくトレードオフスライダーを調整することができるようになります。本記事では正規化も含めて、それぞれの正規化崩しがどのような目的のもと行われるのかを整理してみました。(なので、RAIDなどの物理
Kotlin / Swift での Unicode の扱いまとめ (見た目上の文字数カウント, UTF-8, UTF-16, BOM, 正規化, 異体字セレクタ)AndroidiOSKotlinUnicodeSwift Kotlin と Swift での見た目上の文字数カウント実装を中心に、Unicode について知っておくべき知識をまとめます。 また、モバイルアプリで入力文字数のカウントや入力文字数の上限をどのように扱うかは以下の別の記事にまとめました。 文字数カウント まずは、文字数カウントが難しい例として絵文字と異体字セレクタ表現の例を挙げます。詳しい説明はこの記事の後半を確認してください。 絵文字 🧑🦰 の文字数について確認します。🧑🦰 は以下の Unicode で構成されています。 文字 Code point UTF-8 表現 UTF-16 表現 Descriptio
こんにちは！バックエンドエンジニアの小室です。 先日、4月から入社予定の方に向け「データベース設計」について研修を行いました。 その中でもメイントピックであった「正規化」について改めてまとめてみました。 さっそくですが、データベースにおける正規化とは、 データベースで保持するデータの冗長性を排除し、 一貫性と効率性を確保するためのデータ形式へ変換することを指します。 一般的に第3正規形までで十分とされているため第3正規形までを取り上げます。 第1正規形 テーブルの行と列が交わる1つマスを「セル」と呼ぶことにします。 第1正規形の定義は「1つのセルには1つの値しか含まれない」です。 社員テーブル このように1つのセルに1つの値が含まれているとき、この値を「スカラ値」と言います。 社員テーブル(非正規形) 上のようなテーブルがあった場合、1人の社員は複数の子を養っているので、このように表現した
地方公務員の非正規化が進み、雇用が不安定さを増しています。処遇の改善を目的にした「会計年度任用職員」への移行も、十分に機能しているとは言えません。どんな課題があるのでしょうか。（畑間香織） A 事務補助や保育士、給食調理員、教員、司書、婦人相談員、消費生活相談員、放課後児童支援員など幅広いです。資格や専門性、経験が求められる業務も多いのです。2005年の約46万人から20年は約69万人と、1.5倍に増えました。自治体の財政難を背景に同じ期間に1割減った正規からの「置き換え」が進んでいます。4人に3人は女性が占めている点も特徴で、大半が20年4月に会計年度任用職員に移行しています。
概ね以下のような感じになります。 町丁目レベルまでの数字は漢数字に変換します。 例: 24-2-2-3-3 => 二十四軒二条二丁目3-3 街区、地番レベルの数字は、アラビア数字に変換します。 例: 十四ーイ二十二 => 14-イ22 京都の通り名は削除します。 郡 が省略されている場合は補完します。 例: 和歌山県串本町 => 和歌山県東牟婁郡串本町 が、ケ、ヶ などの揺れを吸収し、国交省が公開する位置参照情報のデータと同じ文字になるように変換します。 旧字体は、新字体に変換します。 大字、字 は削除します。 街区、地番以降の文字列、たとえば建物名などは、そのまま返します。 京都の通り名を削除することには賛否両論あるかと思いますが、この正規化モジュールは住所の名寄せを目的としているため、そのような仕様になっています。 精度が気になる方は、以下にテストケースがありますので、そちらをご覧いた
住所正規化ライブラリ「normalize-japanese-addresses」にローカルファイルの利用に対応した新規リリースを行いました @geolonia/normalize-japanese-addresses （以下 NJA）は Geolonia が開発しているオープンソースの日本の住所の正規化ライブラリです。 NJA の新規のリリースでデータソースとしてローカルファイルを利用するオプションが追加されました。 https://www.npmjs.com/package/@geolonia/normalize-japanese-addresses/v/2.5.0 NJA は町丁目のデータをバックエンドの web API から取得してキャッシュを作成し、これを元に住所の正規化を行なっています。常に最新のデータを参照する一方で、新しい市区町村の正規化を試みるたびにキャッシュの作成のため
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
