postgis-workshop/introduction — Japanese @ OSGeo Weblate: **Concurrent users can cause corruption and slowdowns.** While it's possible …

Translation

English

Japanese

Needs editing

Skip

	English	Japanese	Actions
	A common question from people familiar with open source databases is, "Why wasn't PostGIS built on MySQL?".	オープンソースデータベースに精通している人々からのよくある質問に「なぜ PostGIS は MySQL で作らなかったのか？」があります。
	PostgreSQL has:	PostgreSQL は次の機能を持っています:
	Proven reliability and transactional integrity by default (ACID)	証明されたデフォルトの信頼性とトランザクション完全性 (ACID)
	Careful support for SQL standards (full SQL92)	SQL標準 (完全なSQL92) の慎重な対応
	Pluggable type extension and function extension	入れ替え可能な型拡張と関数拡張
	Community-oriented development model	コミュニティ指向の開発モデル
	No limit on column sizes ("TOAST"able tuples) to support big GIS objects	大きな GIS オブジェクトに対応するために必要なカラムサイズ無制限 ("TOAST"可能なタプル) 機能
	Generic index structure (GiST) to allow R-Tree index	R木インデックスを可能にした一般性のあるインデックス構造 (GiST)
	Easy to add custom functions	カスタム関数の追加が容易
	Combined, PostgreSQL provides a very easy development path to add new spatial types. In the proprietary world, only `Illustra <https://en.wikipedia.org/wiki/Illustra>`_ (now Informix Universal Server) allowed such easy extension. This is no coincidence; Illustra is a proprietary re-working of the original PostgreSQL code base from the 1980's.	あわせて、PostgreSQLは新しい空間型を追加するための非常に簡単な開発パスを提供してくれます。プロプライエタリの世界では `Illustra <https://en.wikipedia.org/wiki/Illustra>`_ (現在の Informix Universal Server) だけがこのような簡単なエクステンションが可能でした。これは決して偶然ではありません。Illustra は、1980年代からオリジナルの PostgreSQL コードベースから作り直したプロプライエタリです。
	Because the development path for adding types to PostgreSQL was so straightforward, it made sense to start there. When MySQL released basic spatial types in version 4.1, the PostGIS team took a look at their code, and the exercise reinforced the original decision to use PostgreSQL.	PostgreSQL への型の追加の開発順路が非常に素直だったので、ここから開始するのは意味のある事です。MySQL が 4.1版で基本的な空間型をリリースした時に、PostGIS チームはコードを見て、前に PostgreSQL を使用した決断を補強しました。
	Because MySQL spatial objects had to be hacked on top of the string type as a special case, the MySQL code was spread over the entire code base. Development of PostGIS 0.1 took under a month. Doing a "MyGIS" 0.1 would have taken a lot longer, and as such, might never have seen the light of day.	MySQL 空間オブジェクトは文字列型の先頭を特別に扱う必要がありました。このため、MySQLコードはコードベース全体に及びました。PostGIS 0,1の開発は1ヶ月とかかりませんでした。"MyGIS" 0.1を開発しようとしていたなら、もっと長い時間が必要になり、日の目を見なかったかも知れません。
	Why not files?	なぜファイルではないのですか？
	The `Shapefile <http://en.wikipedia.org/wiki/Shapefile>`_ (and other formats like the Esri File Geodatabase and the `GeoPackage <https://www.geopackage.org/>`_) have been a standard way of storing and interacting with spatial data since GIS software was first written. However, these "flat" files have the following disadvantages:	GIS ソフトウェアが最初に書かれた時から、`Shapefile <http://en.wikipedia.org/wiki/Shapefile>`_ (と Esri File Geodatabase や `GeoPackage <https://www.geopackage.org/>`_ のような他のフォーマット) は、空間データの格納と使用の標準的な手法であり続けました。しかしながら、これらの「平坦な」ファイルは次の欠点を持ちます:
	Files require special software to read and write. SQL is an abstraction for random data access and analysis. Without that abstraction, you will need to write all the access and analysis code yourself.	ファイルは読み書きに特別なソフトウェアを必要とします SQLはランダムデータアクセスや分析のための抽象化です。この抽象化が無い場合には、全てのアクセスと分析のコードを自身で書く必要があります。
	Concurrent users can cause corruption and slowdowns. While it's possible to write extra code to ensure that multiple writes to the same file do not corrupt the data, by the time you have solved the problem and also solved the associated performance problem, you will have written the better part of a database system. Why not just use a standard database?	複数ユーザの同時利用は破損と速度低下を引き起こす可能性があります。同一ファイルへの複数書き込みがデータ破損を起こさないことを保証するよう外部コードを書くことができますが、こういった問題解決と関連する効率上の問題を解決するまでの時間で、データベースシステムの大部分を書くことができます。標準データベースを使用することをお勧めします。
	Complicated questions require complicated software to answer. Complicated and interesting questions (spatial joins, aggregations, etc) that are expressible in one line of SQL in the database take hundreds of lines of specialized code to answer when programming against files.	複雑な質問に答えるには複雑なソフトウェアが必要です。データベース内の1行のSQLで表現できる、複雑で興味深い質問 (空間結合、集約など) は、ファイルに対するプログラムを書く時は、答えるのに数百行の特別なコードを必要とします。
	Most users of PostGIS are setting up systems where multiple applications will be expected to access the data, so having a standard SQL access method simplifies deployment and development. Some users are working with large data sets; with files, they might be segmented into multiple files, but in a database they can be stored as a single large table.	ほとんどの PostGIS ユーザは複数アプリケーションがデータにアクセスすることを期待するシステムをセットアップしているので、標準 SQL アクセス方法を持つことで、配備と開発を単純化できます。大きなデータセットで作業を行うユーザは、ファイルを使う場合には複数ファイルに分割することになるかも知れませんが、データベースでは単一の巨大テーブルとして保存することができます。
	In summation, the combination of support for multiple users, complex ad hoc queries, and performance on large data sets are what sets spatial databases apart from file-based systems.	要約すると、複数ユーザ、複雑なアドホッククエリ、大きなデータセットのパフォーマンスに関する対応の組合せによって、空間データベースをファイルベースのシステムから分離することができます。
	A brief history of PostGIS	PostGIS の歴史
	In the May of 2001, `Refractions Research <http://www.refractions.net/>`_ released the first version of PostGIS. PostGIS 0.1 had objects, indexes and a handful of functions. The result was a database suitable for storage and retrieval, but not analysis.	2001年5月、`Refractions Research <http://www.refractions.net/>`_ は PostGIS の最初のバージョンをリリースしました。PostGIS 0.1 は、オブジェクト、インデックス、少数の関数がありました。データベースは保存と検索には適切ですが、解析には不向きだとの結果でした。
	As the number of functions increased, the need for an organizing principle became clear. The "Simple Features for SQL" (:term:`SFSQL`) specification from the Open Geospatial Consortium provided such structure with guidelines for function naming and requirements.	関数の数が増えるにつれ、組織化の原理の必要性が明らかになりました。Open Geospatial Consortium から出ている "Simple Features for SQL" (:term:`SFSQL`) 仕様は、関数命名と要件に関するガイドラインとともに、この構造を提供しました。
	With PostGIS support for simple analysis and spatial joins, `Mapserver <http://mapserver.org/>`_ became the first external application to provide visualization of data in the database.	PostGIS の単純な解析と空間結合への対応で `Mapserver <http://mapserver.org/>`_ は、データベース内のデータの可視化機能を提供する最初の外部アプリケーションになりました。
	Over the next several years the number of PostGIS functions grew, but its power remained limited. Many of the most interesting functions (e.g., ST_Intersects(), ST_Buffer(), ST_Union()) were very difficult to code. Writing them from scratch promised years of work.	次の数年間で PostGIS 関数の数は増えましたが、その能力は制限されたままでした。最も興味深い関数の多数 (例えば ST_Intersects(), ST_Buffer(), ST_Union()) は、コーディングが非常に難しいものでした。それらを最初から書くには何年もの仕事が必要となりました。
	Fortunately a second project, the "Geometry Engine, Open Source" or `GEOS <http://trac.osgeo.org/geos>`_, came along. The GEOS library provides the necessary algorithms for implementing the :term:`SFSQL` specification. By linking in GEOS, PostGIS provided complete support for :term:`SFSQL` by version 0.8.	幸運なことに、二つ目のプロジェクトの「Geometry Engine, Open Source」あるいは `GEOS <http://trac.osgeo.org/geos>`_ が登場しました。GEOS ライブラリは、:term:`SFSQL` 仕様を実装するために必要なアルゴリズムを提供します。GEOS をリンクすることで PostGIS は 0.8 までに、:term:`SFSQL` の完全な対応ができるようになりました。
	As PostGIS data capacity grew, another issue surfaced: the representation used to store geometry proved relatively inefficient. For small objects like points and short lines, the metadata in the representation had as much as a 300% overhead. For performance reasons, it was necessary to put the representation on a diet. By shrinking the metadata header and required dimensions, overhead greatly reduced. In PostGIS 1.0, this new, faster, lightweight representation became the default.	PostGIS データ容量が増加するにつれ、他の問題が表面化しました。ジオメトリ保存に使われる表現では比較的非効率です。ポイントや短いラインストリングのように小さいオブジェクトでは、表現のメタデータには300% のオーバヘッドがあります。効率性のため、表現をダイエットする必要がありました。メタデータヘッダと求めらえれる次元の収縮によって、オーバヘッドは非常に減収します。PostGIS 1.0 では、新しく、速く、軽い表現がデフォルトになりました。
	Recent releases of PostGIS continue to add features and performance improvements, as well as support for new features in the PostgreSQL core system.	PostGIS の最近のリリースでは、PostgreSQL コアシステム内の新機能対応だけでなく、機能追加と性能改善の追加を継続しています。
	Who uses PostGIS?	PostGIS を使用するのは誰ですか？
	For a complete list of case studies, see the `PostGIS case studies <https://postgis.net/category/casestudy/>`_ page.	ケーススタディの完全なリストについては `PostGIS case studies <https://postgis.net/category/casestudy/>`_ ページをご覧下さい。
	Institut Geographique National, France	フランス IGN (Institut Geographique National)
	IGN is the national mapping agency of France, and uses PostGIS to store the high resolution topographic map of the country, "BDUni". BDUni has more than 100 million features, and is maintained by a staff of over 100 field staff who verify observations and add new mapping to the database daily. The IGN installation uses the database transactional system to ensure consistency during update processes, and a `warm standby system <https://www.postgresql.org/docs/devel/warm-standby.html>`_ to maintain uptime in the event of a system failure.	IGNはフランスの地図作成機関で、PostGIS を国の高解像度地形図 "BDUni" の保存に使用しています。BDUniには1億を超える地物があり、観測を検証し、データベースに新しい地図を毎日追加する 100人以上の現地作業員によって維持されています。IGNの設備は、データベーストランザクションシステムを使用して更新処理中の一貫性を確保し、また `温待機システム <https://www.postgresql.org/docs/devel/warm-standby.html>`_ を使用してシステム障害が発生した場合でも稼働するようにしています。

Loading…

yellow73

Translation added

English

Japanese 169 characters edited Current translation Translated

**複数ユーザの同時利用は破損と速度低下を引き起こす可能性があります**。同一ファイルへの複数書き込みがデータ破損を起こさないことを保証するよう外部コードを書くことができますが、こういった問題解決と関連する効率上の問題を解決するまでの時間で、データベースシステムの大部分を書くことができます。標準データベースを使用することをお勧めします。

a year ago

Browse all string changes