オープンデータのプロジェクトに取り組む過程で、私は多くの政府データソースを研究しなければなりませんでした。 これらは、連邦政府のポータルと自治体のリソースの両方です。 オープンデータの最も有名なソースは次のとおりです。
これらのリソースはすべて同じ病気です。 ここにあります：
- 無効なデータ。
- データの断片化と標準の欠如。
- 単一の検索エンジンの欠如。
- データアクセス用のAPIの欠如。
これは、それらを使用する意欲とそれらに投稿されたデータを落胆させるのに十分です。
さて、各アイテムの詳細とそれについてどうするか。
無効なデータ
data.gov.ruドキュメントの統計は、ほとんどのデータがCSV形式であることを示しています。
そして、これは大きな問題です。 実際、ほとんどのCSVファイルの形式は無効です。 CSVを間違えるのは簡単です。ユーザーが標準を理解していない場合、エラーの可能性は100％に近くなります。 したがって、最も一般的なエラーは次のとおりです。
1位 - 追加の引用符 。 これは、すべてのCSVデータの惨事です。 引用符が間違っていると、ドキュメント全体が破損する場合があります。
例： ノヴゴロド地域の製薬活動のライセンスの登録は、最初の行です。
" "," "",...
2位 -データ行の異なる列数 。
例： 医薬品の州名簿
regnumber,regdate,enddate,cancellationdate,nameregcertificate,country,tradename,internationalname,formrelease,stages,barcodes,normativedocumentation,pharmacotherapeuticgroup N009886,28.04.2011,,,," """"",,,,~,," , .., Nobelweg 6, 3899 BN Zeewolde, the Netherlands, ",," N009886-280411,2011,; ",
ヘッダーとデータを比較すると、次の結果が得られます。
regnumber = N009886 regdate = 28.04.2011 enddate = cancellationdate = nameregcertificate = country = "" tradename = internationalname = ...
CSVファイルの80％を使用する前に編集する必要があります。 これは、小さくてめったに変更されないデータセットにとっては大きな問題ではありません。 しかし、セットが10万行で、週に1回更新される場合、これは大きな問題です。
これは質問を頼みます、なぜCSVを使用するのですか？
データの断片化と標準の欠如
各サービスは、データをランダムな形式で公開します。
たとえば、 検疫ゾーンの CSVファイルの列ヘッダーは次のとおりです。
" ", " ", " ()", "№ (№ )", " (№ )", " (№ )", " "
地理座標は、コンマを介した1列またはGeoJSONの2列として表すことができます。
リストを表示するためのいくつかのオプションを次に示します。
"№ 223 02.09.2010 № 277 29.09.2011 № 136 14.10.2009 № 556 02.10.2013 № 452 19.10.2012"
"4 : 3 , 9 , 2 , 4 , 37 "
"OVDPhone": [ { "PhoneOVD": "(495) 601-05-36" }, { "PhoneOVD": "(495) 601-05-37" } ]
その他はすべて異なるリソースに散らばっています：
- https://www.magnitogorsk.ru/opendata-マグニトゴルスク
- http://opendata.cheladmin.ru-チェリャビンスク
- https://minvr.ru/opendata-ウラジオストク
- http://data.ekburg.ru-エカテリンブルグ
これらが公式サイトであることを知る方法は？ そして、データを1か所で公開してみませんか？
単一の検索エンジンの欠如
データの断片化により、公開データのすべての公開ソースを検索することはできません。 どうやらオープンデータ用の十分な全国的な検索エンジンがありません...
データアクセスAPIの欠如
プロジェクトでデータを使用するには、ダウンロードする必要があります。 そして、将来的には、変更を自分で追跡して更新してください。 これは、大規模なデータセットにとって大きな課題です。
データをダウンロードせずにAPIを介して使用する場合、これらの問題を回避できます。 これを行うには、APIは、データを操作するためのタスクを実行するのに十分な機能を提供する必要があります。
一部のリソースにあるAPI（たとえば、 data.mos.ru ）は、データを完全に操作するには不十分です。 さらに、実際のプロジェクトで使用するには十分な信頼性がありません。
これはすべて、オープンデータがあるという事実につながりますが、 data.gov.ruのダウンロード数から判断すると、ユニットはそれを使用します。
オープンデータの可能性を最大限に引き出すには、最も便利な方法で利用できるようにする必要があります。 すぐに使用を開始し、正しい形式にするために時間を無駄にしないようにします。
どうすれば状況を修正できますか？
IMHO、GitHubに似ていますが、データ用のリソースは、オープンデータの開発に強力な刺激を与えます。
はい、たとえばdata.worldがありますが、データ用のGitHubになるすべての機能がまだありません。 リソースにはどのような特性が必要ですか：
- 視覚化 -システムではなく、作成者とユーザーが望むようにデータを視覚化する機能。
- 標準化 -データ構造を指定する機能。この構造から逸脱するとエラーが発生し、データをロードできなくなります。
- APIと統合 -豊富なAPIとさまざまなデータソースと統合する機能。
- 社会性 -コミュニティでの議論、評価、データのレビュー。
- 国際性 -国家によるブロックを回避するために、どの国のサーバーにもデータを配置しないでください。
近い将来、このようなリソースが出現し、オープンデータがすべての人の生活の重要な位置を占めるようになると確信しています。