21. 回答シート¶
21.1. Results For インターフェイスのあらまし¶
21.2. Results For 最初のレイヤーを追加する¶
21.2.1. 準備¶
ダイアログのメインエリアには、色の異なる多くの図形が表示されているはずです。各シェイプは、左側のパネルでその色によって識別できるレイヤーに属します(実際の色は下のものと異なる場合があります)。
21.3. Results For シンボル¶
21.3.1. 色¶
注釈
他のレイヤに煩わされずに一度にひとつのレイヤだけで作業したい場合、「レイヤ」リスト内のその名前の隣にあるチェックボックス内をクリックしてレイヤを非表示にできます。ボックスが空の場合、そのレイヤは非表示になっています。
21.3.2. シンボルの構造¶
これであなたの地図はこのように見えていると思います:
初心者レベルのユーザーはここで止めた方が良いかもしれません。
上の方法を使って残りのレイヤーすべての色とスタイルを変更します。
オブジェクトにはできるだけ本来の色を使うようにしてください。たとえば、道路は赤や青ではなく、灰または黒であるべきです。
ポリゴンに対する別の 塗りつぶしスタイル ストロークスタイル 設定も遠慮なく試してください。
21.3.4. シンボルのレベル¶
必要なシンボルを作るには3つのシンボルレイヤーが必要です:
一番下のシンボルレイヤは、幅広の灰色の実線です。その上にはやや細い黄色の実線があり、最後に別の細い黒い実線があります。
シンボルレイヤが上記のようになっていても、必要な結果が得られていない場合は:
シンボルレベルが次のようになっていることを確認してください:
これであなたの地図は次のように見えるようになったはずです:
21.5. Results For Vector Attribute Data¶
21.5.1. Exploring Vector Data Attributes¶
rivers レイヤーには9つのフィールドがあるはずです。
ちなみに
A quicker approach could be to double-click the rivers layer, open the tab, where you will find a numbered list of the table's fields.
町に関する情報は places レイヤーにあります。 rivers レイヤで行ったようにその属性テーブルを開きます。 place 属性が
town
に設定されている地物が2つあります: Swellendam と Buffeljagsrivier 。必要に応じて、これら2つのレコードから他のフィールドにコメントを追加できます。name
フィールドがラベルとして表示するには最も便利です。そのすべての値は各オブジェクトについて一意であり、 NULL 値が含まれている可能性が非常に低いためです。データにいくつかの NULL の値が含まれている場合、場所のほとんどが名前を持っている限り心配いりません。
21.6. Results For Labels¶
21.6.1. ラベルのカスタマイズ (パート 1)¶
Your map should now show the marker points and the labels should be offset by 2mm. The style of the markers and labels should allow both to be clearly visible on the map:
21.6.2. ラベルのカスタマイズ (パート 2)¶
一つの可能な解ではこの最終製品があります:
この結果に到着するには:
Use a font size of
10
Use an around point placement distance of
1.5 mm
Use a marker size of
3.0 mm
In addition, this example uses the Wrap on character option:
Enter a
space
in this field and click Apply to achieve the same effect. In our case, some of the place names are very long, resulting in names with multiple lines which is not very user friendly. You might find this setting to be more appropriate for your map.
21.6.3. データ定義された設定を使用して¶
Still in edit mode, set the
FONT_SIZE
values to whatever you prefer. The example uses16
for towns,14
for suburbs,12
for localities, and10
for hamlets.Remember to save changes and exit edit mode
Return to the Text formatting options for the
places
layer and selectFONT_SIZE
in the Attribute field of the font size data defined override dropdown:結果は、上記の値を使用している場合、このようになります。
21.7. Results For 分類¶
21.8. Results For 新しいベクターデータセットを作成する¶
21.8.2. トポロジ: リングツールを追加¶
正確な形状は重要ではありませんが、あなたの地物の中央には穴が空くことになります。こちらのように。
次のツールのための演習を続行する前に編集を取り消します。
21.8.3. トポロジ: パートを追加ツール¶
最初に Bontebok National Park を選択します:
ここで新しいパートを追加します:
次のツールのための演習を続行する前に編集を取り消します。
21.8.4. 地物をマージ¶
選択した地物のマージ ツールを使う際には、最初にマージしたいポリゴンを両方選んでください。
1 の属性の OGC_FID を持つ地物をソースとして使用します(ダイアログでそのエントリをクリックし、それから 選択地物から属性を取る ボタンをクリックしてください):
注釈
- 別のデータセットを使用している場合、可能性が高いのはあなたの
元々のポリゴンの OGC_FID は 1 にはならないでしょう。 OGC_FID を持っている地物だけを選択してください。
注釈
選択地物の属性をマージ ツールを使用すると、ジオメトリは別々のまま、それらに同じ属性を与えます。
21.9. Results For ベクター分析¶
21.9.1. 高校からの距離¶
あなたのバッファダイアログはこのように見えるはずです:
バッファ距離 は 1 キロメーターです。
近似するセグメント 値は 20 に設定されます。これはオプションですが、出力バッファがよりスムーズに見えるのでお勧めです。これと比較してみてください:
これに:
第1の画像は、 近似するセグメント の値が 5 に設定されたバッファを、第2の画像はその値が 20 に設定されたバッファを示しています。この例では違いは微妙ですが、より高い値を持つほどバッファの縁がより滑らかであることがわかります。
21.10. Results For ネットワーク分析¶
21.11. 最速径路¶
を開き、ダイアログに次のように記入します。
計算するパスタイプ が 最速
であることを確認してください。
実行 をクリックし、ダイアログを閉じます。
出力レイヤーの属性テーブルを開きます。 cost フィールドには2点間の移動時間が含まれています(時間の割合)。
21.12. Results For ラスター分析¶
21.13. Results For 分析を完了させる¶
21.13.1. ラスターからベクター¶
レイヤ パネルの all_terrain レイヤを右クリックし、 タブを選択して クエリビルダ を開きます。
次に、"suitable" = 1 クエリを構築します。
OK をクリックしてこの条件が満たされていないすべてのポリゴンをフィルタリングします。
オリジナルのラスター上で閲覧するとその領域は完全にオーバーラップされるはずです:
レイヤー パネル中の all_terrain レイヤー上で右クリックし 名前を付けて保存... を選択することでこのレイヤーを保存できます。その後は指示に従って続けます。
21.13.2. 結果を精査¶
Intersect ツールによって new_solution レイヤー中の建物の一部が「スライス」されることがあることに気づくことがあります。これは、建物の一部のみ - それゆえ資産の一部のみ -が適した地形の上にあることを示しています。したがって、賢明にデータセットから、これらの建物を排除できます
21.13.3. 分析を改善する¶
現時点ではあなたの分析は次のように見えるはずです:
全ての方向に100メートルのための連続円形領域を考えます。
それは半径100メートルより大きい場合、その大きさから(すべての方向から)100m減算すると、それが真ん中に残された部分になるでしょう。
そのため、既存の suitable_terrain ベクターレイヤー上で100メートルの 内部バッファ を実行できます。バッファ機能の出力において、元のレイヤーの残りはどれも、100メートルを超えて適した地形がある領域を表すことになります。
証明するために:
に行き、バッファダイアログを開きます。
このように設定します:
10 のセグメントで -100 のバッファ距離で suitable_terrain レイヤーを使用します。(地図が投影CRSを使用しているため、距離は自動的にメートル単位です。)
出力を exercise_data/residential_development/ 中に suitable_terrain_continuous100m.shp として保存します。
必要に応じて、元々の suitable_terrain レイヤの上に新しいレイヤを移動してください。
作業結果は次のように見えるはずです:
ここで 位置で選択 ツール( )を使用します。
このように設定します:
suitable_terrain_continuous100m.shp の中の地物に交差する new_solution 中の地物を選択します。
結果はこちらです:
黄色の建物が選択されています。建物の一部は、新しい suitable_terrain_continuous100m レイヤー外に一部が落ちるものの、それらは元の suitable_terrain レイヤー範囲内に十分にあり、したがって私たちの要件のすべてを満たしています。
選択を exercise_data/residential_development/ 下に final_answer.shp として保存してください。
21.14. Results For WMS¶
21.14.2. 新しいWMSサーバーの追加¶
新しいサーバーとそのサーバー上でホストされているように、適切なレイヤーを追加する前と同じアプローチを使用します。
Swellendam 領域にズームインした場合、このデータセットは低解像度を持っていることに気づくでしょう:
したがって、現在の地図にこのデータを使用しない方が良いです。ブルーマーブルデータは、グローバルまたは全国規模での方が適しています。
21.15. Results For GRASS統合¶
21.15.1. マップセットにレイヤを追加¶
ブラウザにドラッグアンドドロップするか( Follow Along: Load data using the QGIS Browser を参照)、またはvectorに v.in.gdal.qgis
を使うことでGRASS Mapsetにレイヤ(ベクタとラスタの両方)を追加できます。ラスタレイヤの場合は r.in.gdal.qgis です。
21.15.2. Reclassify raster layer¶
ラスタの最大値を知るには、コンソールで r.info ツールを実行してください:最大値は1699です。
これで規則を書く準備が整いました。テキストエディタを開き、以下の規則を追加します。
0 thru 1000 = 1
1000 thru 1400 = 2
1400 thru 1699 = 3
ファイルを my_rules.txt
ファイルとして保存してテキストエディタを閉じます。
r.reclass ツールを実行し、 g_dem レイヤーを選択して先ほど保存したルールを含むファイルをロードしてください。
実行 をクリックしてから 結果を見る をクリックしてください。色が変更でき、最終結果は次の図のようになります。
21.16. Results For データベースの概念¶
21.16.1. 住所テーブルのプロパティ¶
理論上の住所テーブルのために、次のプロパティを保存したい場合があります:
House Number
Street Name
Suburb Name
City Name
Postcode
Country
住所オブジェクトを表すテーブルを作成するときは、これらのプロパティのそれぞれを表現する列を作成し、それらにSQL準拠していておそらく短縮した名前で名前を付けるでしょう:
house_number
street_name
suburb
city
postcode
country
21.16.2. People(人々)テーブルを正規化する¶
people テーブルの大きな問題は、人の住所全体を含んでいる単一の住所フィールドが存在することです。以前このレッスンで理論的 address テーブルを考えると、住所は多くの異なる特性で構成されていることがわかります。すべてのこれらの特性を1つのフィールド内に格納することで、データの更新と照会をはるかに困難にしています。そこで、住所フィールドを様々な特性に分割する必要があります。これは、次のような構造を持つテーブルになるでしょう:
id | name | house_no | street_name | city | phone_no
--+---------------+----------+----------------+------------+-----------------
1 | Tim Sutton | 3 | Buirski Plein | Swellendam | 071 123 123
2 | Horst Duester | 4 | Avenue du Roix | Geneva | 072 121 122
注釈
次のセクションでは外部キー関係について学びます。それはこの例においてデータベースの構造をさらに改善するために使用できるでしょう。
21.16.3. 人々テーブルのさらなる正規化¶
people テーブルは現在はこのようになっています:
id | name | house_no | street_id | phone_no
---+--------------+----------+-----------+-------------
1 | Horst Duster | 4 | 1 | 072 121 122
street_id 列は people オブジェクトと関係づけられた street オブジェクト( streets テーブルの中)の間の「1対多」関係を表します。
テーブルをさらに正規化する一つの方法は、名前のフィールドを 姓 と 名 に分割することです:
id | first_name | last_name | house_no | street_id | phone_no
---+------------+------------+----------+-----------+------------
1 | Horst | Duster | 4 | 1 | 072 121 122
また、町名や都市名と国に対して別々のテーブルを作成し、「1対多」関係を介して私たちの people テーブルにそれらをリンクできます:
id | first_name | last_name | house_no | street_id | town_id | country_id
---+------------+-----------+----------+-----------+---------+------------
1 | Horst | Duster | 4 | 1 | 2 | 1
これを表現するER図は次のようになります:
21.16.4. 人々テーブルを作成します¶
正しい人々テーブルを作成するために必要なSQLは:
create table people (id serial not null primary key,
name varchar(50),
house_no int not null,
street_id int not null,
phone_no varchar null );
テーブルのスキーマは(\d people と入力します)このようになります:
Table "public.people"
Column | Type | Modifiers
-----------+-----------------------+-------------------------------------
id | integer | not null default
| | nextval('people_id_seq'::regclass)
name | character varying(50) |
house_no | integer | not null
street_id | integer | not null
phone_no | character varying |
Indexes:
"people_pkey" PRIMARY KEY, btree (id)
注釈
説明のために、FKEY制約は意図的に省略しています。
21.16.5. DROPコマンド¶
people テーブルは streets テーブルへの外部キー制約があるため、DROPコマンドは、このケースでは動作しない理由があります。これは、 streets テーブルをドロップする(または削除する)と、存在しない streets データへの参照が people テーブルに残ることを意味します。
注釈
CASCADE コマンドを使用して streets テーブルを強制的に削除することは可能ですが、これは people と streets テーブルへの関係づけられていた他のテーブルも削除します。注意して使用してください!
21.16.6. 新しい街路を挿入¶
使用する必要があるSQLコマンドは、(選択した名前を持つ通りの名前を置き換えできます)、このようになります:
insert into streets (name) values ('Low Road');
21.16.7. 外部キー関係に新しい人を追加¶
これが正しいSQL文です:
insert into streets (name) values('Main Road');
insert into people (name,house_no, street_id, phone_no)
values ('Joe Smith',55,2,'072 882 33 21');
街路テーブルを再び(以前のようにselect文を使用して)見ると、 主要道路 エントリのための id は 2 であることがわかるでしょう。
だから上では数 2 を入力するしかできなかったでしょう。私たちが上記のエントリで完全に書き出された 主要道路 を見ていないにもかかわらず、データベースはそれを 2 という street_id 値を持つものと関連付けできるでしょう。
注釈
すでに新しい street オブジェクトを追加している場合、新しい 主要道路 のIDは 2 でなく 3 だったということがあるかもしれません。
21.16.8. 街路名を返す¶
これが使用すべき正しいSQL文です:
select count(people.name), streets.name
from people, streets
where people.street_id=streets.id
group by streets.name;
結果::
count | name
------+-------------
1 | Low Street
2 | High street
1 | Main Road
(3 rows)
注釈
テーブル名をフィールド名の接頭辞にしていることに気づくでしょう(例えばpeople.nameとstreets.name)。フィールド名があいまいな(つまり、データベース内のすべてのテーブル間で一意ではない)時はいつでもこれが行われる必要があります。
21.17. Results For 空間クエリ¶
21.17.1. 空間クエリで使用される単位¶
例のクエリで使用されている単位は度です。それはレイヤーが使用しているCRSがWGS 84であるためです。これは地理的CRSです、つまりその単位は度であることを意味します。投影CRSは、UTM投影でのように、メートル単位です。
クエリを書くときはレイヤーのCRSがどの単位かを知る必要があることを忘れないでください。これにより期待する結果が返されるクエリを記述できるでしょう。
21.18. Results For ジオメトリ構築¶
21.18.1. ラインストリングを作成する¶
alter table streets add column the_geom geometry;
alter table streets add constraint streets_geom_point_chk check
(st_geometrytype(the_geom) = 'ST_LineString'::text OR the_geom IS NULL);
insert into geometry_columns values ('','public','streets','the_geom',2,4326,
'LINESTRING');
create index streets_geo_idx
on streets
using gist
(the_geom);
21.18.2. テーブルをリンクする¶
delete from people;
alter table people add column city_id int not null references cities(id);
(QGISで都市をキャプチャ)
insert into people (name,house_no, street_id, phone_no, city_id, the_geom)
values ('Faulty Towers',
34,
3,
'072 812 31 28',
1,
'SRID=4326;POINT(33 33)');
insert into people (name,house_no, street_id, phone_no, city_id, the_geom)
values ('IP Knightly',
32,
1,
'071 812 31 28',
1,F
'SRID=4326;POINT(32 -34)');
insert into people (name,house_no, street_id, phone_no, city_id, the_geom)
values ('Rusty Bedsprings',
39,
1,
'071 822 31 28',
1,
'SRID=4326;POINT(34 -34)');
次のエラーメッセージが出ている場合:
ERROR: insert or update on table "people" violates foreign key constraint
"people_city_id_fkey"
DETAIL: Key (city_id)=(1) is not present in table "cities".
そのときは都市テーブルのポリゴンを作成して実験している間、それらのいくつかを削除してやり直してしまっていることを意味します。都市テーブルのエントリをチェックして、何らかの存在する id を使用するだけです。
21.19. Results For 簡易地物モデル¶
21.19.1. 表を投入¶
create table cities (id serial not null primary key,
name varchar(50),
the_geom geometry not null);
alter table cities
add constraint cities_geom_point_chk
check (st_geometrytype(the_geom) = 'ST_Polygon'::text );
21.19.2. GEOMETRY_COLUMNS表を投入¶
insert into geometry_columns values
('','public','cities','the_geom',2,4326,'POLYGON');
21.19.3. ジオメトリを追加する¶
select people.name,
streets.name as street_name,
st_astext(people.the_geom) as geometry
from streets, people
where people.street_id=streets.id;
結果::
name | street_name | geometry
--------------+-------------+---------------
Roger Jones | High street |
Sally Norman | High street |
Jane Smith | Main Road |
Joe Bloggs | Low Street |
Fault Towers | Main Road | POINT(33 -33)
(5 rows)
ご覧のとおり、私たちの制限ではデータベースへの null の追加を認めています。