21. 回答シート¶
21.1. Results For インターフェイスのあらまし¶
21.2. Results For 最初のレイヤーを追加する¶
21.2.1. 
準備¶
ダイアログのメインエリアには、色の異なる多くの図形が表示されているはずです。各シェイプは、左側のパネルでその色によって識別できるレイヤーに属します（実際の色は下のものと異なる場合があります）。
21.3. Results For シンボル¶
21.3.1. 色¶
色が期待通りに変わっているか確認してください。
凡例で water レイヤを選択してから
レイヤスタイルパネルを開く ボタンをクリックすれば十分です。色を水のレイヤに合う色に変更します。
注釈
他のレイヤに煩わされずに一度にひとつのレイヤだけで作業したい場合、「レイヤ」リスト内のその名前の隣にあるチェックボックス内をクリックしてレイヤを非表示にできます。ボックスが空の場合、そのレイヤは非表示になっています。
21.3.2. シンボルの構造¶
これであなたの地図はこのように見えていると思います:
初心者レベルのユーザーはここで止めた方が良いかもしれません。
上の方法を使って残りのレイヤーすべての色とスタイルを変更します。
オブジェクトにはできるだけ本来の色を使うようにしてください。たとえば、道路は赤や青ではなく、灰または黒であるべきです。
ポリゴンに対する別の 塗りつぶしスタイル ストロークスタイル 設定も遠慮なく試してください。
21.3.4. 
シンボルのレベル¶
必要なシンボルを作るには３つのシンボルレイヤーが必要です:
一番下のシンボルレイヤは、幅広の灰色の実線です。その上にはやや細い黄色の実線があり、最後に別の細い黒い実線があります。
シンボルレイヤが上記のようになっていても、必要な結果が得られていない場合は：
シンボルレベルが次のようになっていることを確認してください：
これであなたの地図は次のように見えるようになったはずです:
21.5. Results For Vector Attribute Data¶
21.5.1. Exploring Vector Data Attributes¶
rivers レイヤーには9つのフィールドがあるはずです。
レイヤ パネルでレイヤを選択してください。
右クリックして 属性テーブルを開く を選択するか、 Attributes Toolbar の
ボタンを押します。列の数を数えます。
ちなみに
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)¶
一つの可能な解ではこの最終製品があります：
この結果に到着するには：
フォントのサイズは
10を使用します周りのポイント配置距離に
1.5 mmを使用しますマーカーのサイズは
3.0 mmを使用しますさらに、この例では 文字をラップ オプションを使用します。
このフィールドに「スペース」を入力して 適用 をクリックして、同じ効果を実現します。ここでの場合、非常に長い地名があり、名前が複数行になっているため、あまりユーザーフレンドリーではありません。この設定が地図により適していると思われる場合もあります。
21.6.3. 
データ定義された設定を使用して¶
Still in edit mode, set the
FONT_SIZEvalues to whatever you prefer. The example uses16for towns,14for suburbs,12for localities, and10for hamlets.Remember to save changes and exit edit mode
Return to the Text formatting options for the
placeslayer and selectFONT_SIZEin 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 を持つ地物をソースとして使用します（ダイアログでそのエントリをクリックし、それから 選択地物から属性を取る ボタンをクリックしてください）：
注釈
If you're using a different dataset, it is highly likely that your
original polygon's OGC_FID will not be 1. Just choose the
feature which has an 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 レイヤを右クリックし、 タブを選択して クエリビルダ を開きます。
Then build the query
"suitable" = 1.OK をクリックしてこの条件が満たされていないすべてのポリゴンをフィルタリングします。
オリジナルのラスター上で閲覧するとその領域は完全にオーバーラップされるはずです:
レイヤー パネル中の all_terrain レイヤー上で右クリックし 名前を付けて保存... を選択することでこのレイヤーを保存できます。その後は指示に従って続けます。
21.13.2. 結果を精査¶
You may notice that some of the buildings in your new_solution layer have
been "sliced" by the Intersection tool. This shows that only part of the
building - and therefore only part of the property - lies on suitable terrain.
We can therefore sensibly eliminate those buildings from our dataset.
21.13.3. 分析を改善する¶
現時点ではあなたの分析は次のように見えるはずです:
全ての方向に100メートルのための連続円形領域を考えます。
それは半径100メートルより大きい場合、その大きさから（すべての方向から）100m減算すると、それが真ん中に残された部分になるでしょう。
そのため、既存の suitable_terrain ベクターレイヤー上で100メートルの 内部バッファ を実行できます。バッファ機能の出力において、元のレイヤーの残りはどれも、100メートルを超えて適した地形がある領域を表すことになります。
証明するために：
に行き、バッファダイアログを開きます。
このように設定します:
Use the suitable_terrain layer with
10segments and a buffer distance of-100. (The distance is automatically in meters because your map is using a projected CRS.)Save the output in
exercise_data/residential_development/assuitable_terrain_continuous100m.shp.If necessary, move the new layer above your original suitable_terrain layer.
作業結果は次のように見えるはずです:
ここで 位置で選択 ツール（ ）を使用します。
このように設定します:
suitable_terrain_continuous100m.shp の中の地物に交差する new_solution 中の地物を選択します。
結果はこちらです:
The yellow buildings are selected. Although some of the buildings fall partly outside the new suitable_terrain_continuous100m layer, they lie well within the original suitable_terrain layer and therefore meet all of our requirements.
Save the selection under
exercise_data/residential_development/asfinal_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 の追加を認めています。