Translation status

15 Strings 100%
Browse Translate
429 Words 100%
2,591 Characters 100%

Strings status

Strings Words Characters
15 429 2,591
All strings Browse Translate Zen
15 429 2,591
Translated strings Browse Translate Zen

Other components

Component Translated Unfinished Unfinished words Unfinished characters Untranslated Checks Suggestions Comments
spatial_relationships_exercises 0 0 0 0 0 0 0
geography_exercises 0 0 0 0 0 0 0
joins_exercises 0 0 0 0 0 0 0
projection_exercises 0 0 0 0 0 0 0
advanced_geometry_construction 0 0 0 0 0 0 0
simple_sql_exercises 0 0 0 0 0 0 0
3d 0 0 0 0 0 0 0
backup 0 0 0 0 0 0 0
license 0 0 0 0 0 0 0
installation CC-BY-3.0-US 0 0 0 0 0 0 0
Browse all components

Overview

Project website postgis.net/workshops/postgis-intro
Project maintainers User avatar komzpa User avatar dmateos User avatar dkastl User avatar jsanz User avatar andischi User avatar cvvergara User avatar astrid_emde User avatar jef User avatar yellow73
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository https://github.com/postgis/postgis-workshops.git
Repository branch master
Last remote commit Merge pull request #136 from latot/topo_intro 3b31e91
Regina Obe authored 16 hours ago
Last commit in Weblate Translated using Weblate (Chinese (Simplified)) 1193e6c
Zuochenwei authored 8 months ago
Weblate repository https://weblate.osgeo.org/git/postgis-workshop/index/
File mask postgis-intro/sources/locale/*/LC_MESSAGES/knn.po
Translation file Download postgis-intro/sources/locale/ja/LC_MESSAGES/knn.po
Last change Sept. 21, 2023, 10:23 a.m.
Last author None
12 days ago

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 15 429 2,591
Translated 100% 15 100% 429 100% 2,591
Needs editing 0% 0 0% 0 0% 0
Read-only 0% 0 0% 0 0% 0
Failing checks 0% 0 0% 0 0% 0
Strings with suggestions 0% 0 0% 0 0% 0
Untranslated strings 0% 0 0% 0 0% 0
Last 12 months Previous

Activity in last 12 months

0 changes 0 changes 0 changes 0 changes 1 change 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 16 changes 0 changes 20 changes 0 changes 0 changes 0 changes
Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct

Quick numbers

429
Hosted words
15
Hosted strings
100%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

—
Hosted words
+100%
—
Hosted strings
+100%
—
Translated
+100%
—
Contributors
—
User avatar None

Changes committed

  1. postgis-workshop
  2. knn
  3. Japanese
Changes committed a year ago
User avatar yellow73

Suggestion accepted

  1. postgis-workshop
  2. knn
  3. Japanese
The explain shows the loop on the subway stations, and the index-assisted order by inside the loop where we want it:
EXPLAIN は地下鉄駅のループと、求めるループ内のインデックスによる ORDER BY を表示します:
a year ago
User avatar yellow73

Suggestion accepted

  1. postgis-workshop
  2. knn
  3. Japanese
Note the way the ``CROSS JOIN LATERAL`` acts as the inner part of a loop driven by the subways table. Each record in the subways table gets fed into the lateral subquery, one at a time, so you get a nearest result for each subway record.
``CROSS JOIN LATERAL`` が地下鉄テーブルで駆動するループ内の処理部分として動作します。地下鉄テーブルの個々のレコードは LATERAL サブクエリにどんどん送られるので、地下鉄レコードごとの最近傍の結果を得ます。
a year ago
User avatar yellow73

Suggestion accepted

  1. postgis-workshop
  2. knn
  3. Japanese
Here we will find the nearest street to each subway station:
地下鉄駅ごとに最も近いストリートを探索します:
a year ago
User avatar yellow73

Suggestion accepted

  1. postgis-workshop
  2. knn
  3. Japanese
Fortunately, there's a SQL language feature that allows us to run a query repeatedly driven in a loop: the `LATERAL join <https://medium.com/kkempin/postgresqls-lateral-join-bfd6bd0199df>`_.
幸運なことに、ループ内で繰り返し駆動されるクエリの実行が可能になる SQL 言語機能 `LATERAL join <https://medium.com/kkempin/postgresqls-lateral-join-bfd6bd0199df>`_ があります。
a year ago
User avatar yellow73

Suggestion accepted

  1. postgis-workshop
  2. knn
  3. Japanese
The index assisted order by operator has one major draw back: it only works with a **single geometry literal** on one side of the operator. This is fine for finding the objects nearest to one query object, but does not help for a spatial join, where the goal is to find the nearest neighbor for each of a full set of candidates.
インデックスによる ORDER BY 演算子は、演算子の一方が**単一ジオメトリリテラル**でないと動作しないという、大きな欠点があります。これはあるクエリオブジェクトに最も近いオブジェクトを探索する場合は良いのですが、候補から一つずつオブジェクトを抜き出して最近傍を検索することを目的とする空間結合には役立ちません。
a year ago
User avatar yellow73

Suggestion accepted

  1. postgis-workshop
  2. knn
  3. Japanese
Nearest Neighbor Join
最近傍結合
a year ago
User avatar yellow73

Translation changed

  1. postgis-workshop
  2. knn
  3. Japanese
This is the output from ``EXPLAIN``, note the index scan over the order by:
"``EXPLAIN"`` からの出力を示しますが、インデックススキャンは ORDER BY に対して実行しています:
a year ago
User avatar yellow73

Suggestion accepted

  1. postgis-workshop
  2. knn
  3. Japanese
This is the output from ``EXPLAIN``, note the index scan over the order by:
"EXPLAIN" からの出力を示しますが、インデックススキャンは ORDER BY に対して実行しています:
a year ago
User avatar yellow73

Suggestion accepted

  1. postgis-workshop
  2. knn
  3. Japanese
How can we be sure we are getting an index-assisted query? It's a good idea to check the ``EXPLAIN`` output for a nearest-neighbor query, because it's possible to get correct answers from non-indexed SQL and the lack of an index might not be obvious until the size of the tables scales up.
インデックスによるクエリをどの程度確定されられるでしょうか? 最近傍クエリの "EXPLAIN" 出力を確認するのが良い考えです。正しい答えを非インデックス SQL から得ることができ、テーブルのスケールアップが無い限りインデックスの欠如が明白にはならないことがあるためです。
a year ago
Browse all translation changes