開発者からのオープンデータ

オープンデータを使用してモバイルアプリケーションで作業する過程で、多くのポータルのコンテンツに精通する必要がありました。その結果、開発者の利益のために「オープンデータポータルの内部世界」を改善する提案がありました。

これに興味があり、すでにこの分野での経験がある場合は、調査結果を以下に記載されている調査結果と比較できます。



ポータルでの作業の中心は、データセットパスポートです。 データセットにアクセスし、パスポートを見つけ、セットの名前、番号、セットへのリンク、およびセット内のフィールドの説明を抽出します。

人が主導する手動ファイルキャビネットの観点からはすべてが論理的なように見えますが、ソフトウェアのデータセットの内容に関する情報を取得することは不可能であるため、アプリケーションの観点からはこれは十分ではありません。

開発者は最初に、それがどのようなセットであるか、どこにあるのか、どのような形式のデータであるのかを自問する必要があります。



セットのパスポートは、アプリケーションがその内容を伝えるのに役立ちます。



可能です。 ネットワーク内にすべてのロシアのオープンデータポータルのレジスタを作成し、データセットに統一された番号付け構造（またはID）を採用し、フィールドの命名とコンテンツの手順を標準化するだけです。



1.ロシアのオープンデータポータルの登録。



すべてのオープンデータポータルがリストされているネットワーク上の場所（レジストリ）。

現在、検索エンジンを使用してネットワーク上のポータルへのリンクを探しており、ポータルを見つけた後、そのコンテンツに精通しています。 ロシアのオープンデータのすべてのポータルのリストとそれらへのリンクを含むサイト/ページ（まだ私には不明です）。



2.データセットの番号（またはID）の統一された構造。



（アイテム1のレジストリを使用して）ポータルにアクセスしました。ポータルに投稿されている内容を理解したいと思います。 各セットは、名前とその番号/ IDによって決定されます。

今日、誰もがそのような数字を望んでいます。 あるポータルではこれらは数字であり、他の言葉では3番目の文にあります。 一部のポータルでは、TINはデータセットの番号/名前に含まれています。既に有効であり、リージョンを引き出すことができます（TINがあることを理解している場合）が、これでは十分ではありません。

セットはカテゴリ（まだどこでもない）にアセンブルされます。これはアセンブルされると非常に論理的です。 ただし、カテゴリのディレクトリの実装には、それぞれ独自のカテゴリがあります。 情報の範囲に関するポータルのレベルも異なり、連邦政府、地域、都市、村のポータルがあります。

その結果、1つのアプリケーションでさまざまなポータルの情報を見つけて使用し、ポータル、セット、およびカテゴリの番号を作成する必要があります。



プログラムでデータセットの内容を理解しやすくするために、データセットの番号/ IDに意味を入力してみませんか。



これを行うには、セット番号（ID）に含めるだけです：



ID1-一意のポータル番号（連邦/地域コード/市年/コードに関連付けられています）、統一ロシア分類のポータルIDでもあり、

ID2-データセット内の情報のカテゴリの単一のコード（つまり、カテゴリの単一のディレクトリを作成して承認する必要があります）、

ID3-ポータルのダイヤル番号。



すべての部門は、オープンデータポータルを整理し、アプリケーションを経理機関に送信し、ID1（ポータルとカテゴリの単一ディレクトリ）を受信します。 その結果、ポータル上のデータセットは次の形式で番号を受け取ります。

ID1-ID2-ID3、および開発者は、任意のポータルで必要なデータセットをすばやく見つけるための既製のメカニズムを取得します。



各都市が独自のサービスを実装する個別の素晴らしいアプリケーションを作成する必要はありません。 ユーザーの位置情報に応じてポータルへのリンクを変更し、任意の地域でアプリケーションを使用します。 適切なポータルとカテゴリが簡単に見つかります。 また、必要に応じて、都市、地域、国の選択したカテゴリで利用可能なすべてのポータルを簡単に「引き出し」ます。



3.データセットのフィールドの名前と内容に対する標準化されたアプローチ。



適切なセットが見つかりました。 次に、その内部構造に対処する必要があります。



そして今日、誰もが独自の方法を持っています。



-データ座標（地理座標）を持つフィールド。 セットの誰かが自分の緯度と経度（2つの異なるフィールド）を呼び出し、誰かが地理座標と値を1つのフィールド（x、y）に入れ、誰かが配列として、誰かが辞書として。 同時に、複数のオプションを1つのポータルに簡単に表示できます（RosTourism、モスクワ政府）。 開発者にとって、すべてのポータルに地理座標を格納するための単一のオプションがあればいいと思います。 誰にでも適しています。 また、キットのパスポートには、入手可能性だけでなくタイプもマークする必要があります。 ポイント、ラインまたはリージョン。

-コンテンツフィールド。 内部に配置されたhtmlページを除いて、何でもかまいません。今日では、文化省のポータルが埋められています。 開発者は情報を必要とします。これは、ドキュメントを定義する際に、HTMLページの形式ではなく、機械で読み取り可能な形式で記述することが通例であるためです。 開発者は誰かのサイトを複製するのではなく、アプリケーションを作成しています。 また、トラフィックを忘れないでください。これは、マークアップとフォントを一緒にドラッグするhtmlの形式で情報を受信すると劇的に増加します。 モバイルアプリケーションは、Webページを表示するための別のオプションではなく、HTMLを回避し、「裸の」情報を取得する方法です。

-写真へのリンク。 今日、これはデータポータルの所有者の想像力の別の領域です。 写真付きのpdfファイルへのリンクを保存することもできます（文化省）。 そして、これは実際のファイル拡張子を指定せずに行われます。 開発者は、画像へのリンクを見て、そこに何かを見つけることを期待しますが、pdfファイルは見つかりません。

-ドキュメントへのリンク。 標準化も必要です。

-写真のサイズ。 残念なことに、彼らはほとんどいつもそれが撃たれた方法で提供されます。つまり、それらはウェブやモバイルアプリケーションの高解像度では必要ないという事実を考えずに。 利用可能なものを広めます。 非常にわかりやすい例、モスクワ政府のポータル上の従業員のディレクトリ。 ご覧ください。 ドキュメントからスキャンされた小さな写真から、オフィスの内部にある巨大な写真まで。 ここにも一定の基準があるといいでしょう。



3.データの可用性。



ポータルはメンテナンス作業である場合があります。 誰にも通知されない。 明らかに、これはできません。 しかし、現時点では、オープンデータを使用するアプリケーションは実行不能になり、ユーザーの怒りをすべて受けます。 これは、アプリケーションが無罪であることを理解していません。 彼にとって、それは「バギー」です。 このため、ユーザーはアプリケーションを拒否するか、それについて悪いレビューを書きます。 たとえば、モスクワ政府のポータルでは、これは土曜日に定期的に発生します。



ポータルは、APIにOpen / Closedのポータルリクエストを追加する必要があります。 そして、ポータルがまだ提案されたオープニングの推定日を返す場合...その後、私たちは癒します。



4.データ品質。



ポータルデータの品質には2つの要因があります。 データ自体のエラーおよび破棄されたデータの構造のエラー。

「写真」などのフィールドおよびコンテンツの名前の文法は、なんとか生き残ります。



データのエラー。



1年以上、データセットで、モスクワ政府のポータルの地下鉄の入り口/出口に個別の入り口がなく、地下鉄の駅全体が悪い場合は悪いことです。 また、「公共交通機関の停止」データセットから、ルートXXのバスが1か所だけで停止することがわかります。 他に彼のルートが通る場所は不明です。 または、ミドルネームフィールドに姓が登録され、フィールドに姓がミドルネーム、文化省のポータルです。 繰り返しますが、冗長性があります。同じセットにフルネームのフィールドがある場合、名前、姓、ミドルネームを別々に入力するのはなぜですか？ 混乱した緯度と経度などのトリビアは、まだ考慮していません。



データ構造のエラー。



このエラーグループは、csv形式でデータをダンプするときに表示され、この形式で使用される区切り文字に関連付けられています。 フィールド内に同じコンマが存在する区切り文字「」でデータを見つけるのは非常に簡単です。 ご存知のように、この場合、行を別々のフィールドに正しく分離することは不可能です。 フィールド内に改行文字がある場合のように。 同様の状況は、各行のすべての区切り文字が単に表示されない場合に発生します。 彼らは十分ではありません。 どうやら、ポータルのデータセットを埋めると、美しいXLSファイルが取得され、すべてのヘッダーで直接リセットされます。 これはできません。

CSVファイルは、このようなエラーのため、開発者にとっては静かな恐怖であり、悪夢です。 壊れた構造のために、取得したデータを理解できないことをユーザーに説明してください。 しかし、この形式は依然として最先端です。



そして、最も不快な間違いは、モスクワ地域の政府のポータルでの開発者へのリクエストの形成に関する説明によると、jsonを取得する必要があるが、csvの形式で回答を取得する場合です。どのカテゴリに割り当てるかさえわかりません。 到着したコードをすぐにコードに挿入し、APIの説明で約束された内容ではなく、指定した内容（csvまたはjson）に応じて受信データの処理を選択する必要があります。 存在することは、アプリケーションの動作を決定します。



5.データの関連性。 2014年から2015年はすべての人に存在しますが、2016年以降は...これは困難です。



6.ストレージの構成とデータへのアクセス。



OpenDataを使用してデータを照会および更新するものもあれば、MongoDbを使用するものなどもあります。 開発者にとって、各新しいポータルは新しい構文解析であり、アプリケーションは成長しています。 新しい機能に取り組む代わりに、データを受信するための次のオプション（リクエスト/レスポンス）をデバッグする必要があります。 スキーム（パスポート-セット）は存在しますが。 これは不可能です。

1つのAPIを使用して、1つのソリューションをネゴシエートして使用する必要があります。



開発者側からの最適なオプションは、1つのDBMSに基づいた1つのプロバイダーからのクラウドポータルであり、単一のAPIを使用して、どの部門でもオープンデータポータルとそれを操作するためのユニバーサルツールの場所を取得できます 国内のオープンデータプログラムを担当する規制機関の手配が難しくないことを願っています。 さらに、彼女はこのプログラムに割り当てられた資金の支出を実際に制御できます。

たとえば、Windows Azureに基づいて簡単に実装できます。 コスト、試運転速度、信頼性、および所有コストの面でのこのオプションのすべての利点は、開発者だけでなく理解できると確信しています。



そして、経験がどこから来たのか、つまり、モバイルアプリケーションについての少しの作業は、上記につながった作業。

このアプリケーションはiOS用に作成され、5つのオープンデータポータルで動作します。これらは1147セットであり、ロシア中央銀行からの情報です。



-モスクワ政府のポータル-697セット、

-モスクワ地方の政府-266セット、

-文化省-49セット、

-ロシア連邦政府観光局-135セット。

-中央銀行のポータルは、オープンデータポータルとは直接呼ばれていませんが、基本的にそのようなものです。これは、中央銀行が提示する通貨のレートに関する情報をあらゆる期間にわたって提供するためです。 オープンデータポータルに投稿されたルーブル統計を通貨換算に必要な情報。