21. 回答シート¶
21.1. Results For 最初のレイヤを追加¶
21.2. Results For インタフェースのあらまし¶
21.3. Results For ベクターデータで作業¶
21.4. Results For シンボル¶
21.4.1. 
色¶
色が期待通りに変わっているか確認してください。
現時点では 水系 レイヤを変えるだけで十分です。下記はその例ですが、選んだ色によっては違って見えるかもしれません。
ノート
他のレイヤに煩わされずに一度にひとつのレイヤだけで作業したい場合、レイヤ一覧内のその名前の隣にあるチェックボックス内をクリックしてレイヤを非表示にできます。ボックスが空の場合にレイヤは非表示です。
21.4.2. シンボルの構造¶
これであなたのマップはこのように見えていると思います:
あなたが初心者レベルのユーザであれば、ここで止めた方が良いかもしれません。
上のメソッドを使って残りのレイヤすべての色とスタイルを変更します。
オブジェクトにはできるだけ本来の色を使うようにしてください。たとえば、道路は赤や青ではなく、グレイまたは黒であるべきです。
別のポリゴンの 塗りつぶしスタイル ボーダーStyle 設定も遠慮なく試してください。
21.4.4. 
シンボルのレベル¶
必要なシンボルを作るには２つのシンボルレイヤが必要です:
いちばん下のシンボルレイヤは幅広の黄色の実線です。その先頭にはやや狭いグレーの実線があります。
もしあなたのシンボルレイヤが上記に似てはいるが欲しい結果が得られていない場合は、あなたのシンボルレベルが次のように見えるかどうかチェックしてください:
これであなたのマップは次のように見えるようになったはずです:
21.5. Results For 属性データ¶
21.6. Results For ラベルツール¶
21.6.1. ラベルのカスタマイズ (パート 1)¶
今、地図はマーカ・ポイントを示さなければならず、ラベルは 2.0 mm だけオフセットされなければなりません：マーカーとラベルのスタイルは、両方が地図上ではっきりと見えることを可能にする必要があります。
21.6.2. ラベルのカスタマイズ (パート 2)¶
一つの可能な解決策は、この最終製品があります。
この結果に到着するには：
フォントサイズ 10 、 ラベル距離 1.5 mm 、 シンボル幅 と シンボルサイズ 3.0 mm を使用します。
さらに、この例では characterラベルをラップ オプションを使用します。
このフィールドに space と入力し Apply をクリックして、同じ効果を達成します。この場合には、地名の一部は非常に長く、その結果複数の行を持つ名前で、非常にユーザーフレンドリーではありません。この設定が自分の地図にとってより適切と見つけるかもしれません。
21.7. Results For 分類¶
21.8. Results For 新しいベクターデータセットの作成¶
21.8.2. トポロジー: リングツールを追加¶
正確な形状は重要ではありませんが、あなたの地物の中央には穴が空くことになります。こちらのように。
次のツールのための演習を続行する前に編集を取り消します。
21.8.3. Topology: パートツールを追加¶
最初に Bontebok National Park を選択します:
新しいパートを追加:
次のツールのための演習を続行する前に編集を取り消します。
21.8.4. 
地物をマージ¶
選択した地物のマージ ツールを使う際には、最初にマージしたいポリゴンを両方選んでください。
1 の属性の OGC_FID を持つ地物をソースとして使用します（ダイアログでそのエントリをクリックし、それから 選択地物から属性を取る ボタンをクリックしてください）：
ノート
- 別のデータセットを使用している場合、それはあなたの可能性が高いです
元々のポリゴンの OGC_FID は 1 にはならないでしょう。 OGC_FID を持っている地物だけを選択してください。
ノート
選択地物の属性をマージ ツールを使用すると、ジオメトリは別々のまま、それらに同じ属性を与えます。
21.8.5. フォーム¶
type について、道路がなりうるタイプの量は明らかに限られており、そしてこのレイヤーのための属性テーブルをチェックすると、それらが事前定義されていることがわかります。
ウィジェットを バリューマップ にセットして レイヤからデータをロード をクリックしてください。
Label`ドロップダウンで :guilabel:`roads を、 値 と Description オプション両方のために highway を選択します：
Ok を３回クリックしてください。
今路上で :guilabel:`Identify`ツールを使用している場合は、編集モードがアクティブな間、出てくるダイアログは次のようになります。
21.9. Results For ベクター分析¶
21.9.1. OSM データから自分用のレイヤを抽出¶
この演習の目的のために、私たちが興味を持っているOSMレイヤーは multipolygons と :kbd:` lines`です。 multipolygons レイヤーには、 houses 、 schools と restaurants レイヤーを生産するために必要なデータが含まれています。 lines レイヤーには道路データセットが含まれています。
クエリビルダー はレイヤプロパティにあります:
multipolygons レイヤーに対して クエリBuilder を使用し 、 houses 、 schools 、 restaurants と residential レイヤーのために以下のクエリを作成します：
各クエリを入力したら、OK をクリックしてください。地図が更新されて選択したデータのみが表示されることがわかります。OSMのデータセットから再び multipolygons データを使用する必要があるので、この時点では、 次のいずれかの方法を使用できます。
フィルタされたOSMレイヤーの名前を変更し、 osm_data.osm からレイヤーを再インポートします 、または
フィルタレイヤーを複製し、コピーの名前を変更し、クエリをクリアし、クエリBuilder 中で新しいクエリを作成します。
ノート
OSMの building フィールドの値は house 値ではありますが、お住まいの地域のカバレッジは - 私たちのように - 完全ではないかもしれません。テスト領域ではそれゆえ、 house 以外と定義されているすべての建物を*除外* することがより正確です。 house など明確な意味を持っていない他のすべての値 yes を単にとして定義されている建物を含めることを決定できます。
OSMの lines レイヤーに対して、このクエリを構築し、roads レイヤーを作成します：
次のようになりマップで終わる必要があります。
21.9.2. 高校からの距離¶
あなたのバッファダイアログはこのように見えるはずです:
バッファ距離 は 1000 メーターです (すなわち 1 キロメーター)。
セグメントをapproximate 値は 20 に設定されます。これはオプションですが、出力バッファがよりスムーズに見えるのでお勧めです。これと比較してみてください：
これに：
第1の画像は、 セグメントapproximate 値が :kbd:` 5` に設定されたバッファを、第2の画像は値が 20 に設定されたバッファを示しています。この例では違いは微妙ですが、より高い値を持つほどバッファのエッジがより滑らかであることがわかります。
21.10. Results For ラスタ分析¶
21.11. Results For 分析を完了させる¶
21.11.1. ラスタからベクタ¶
レイヤーリスト 中の all_terrain`レイヤー上で右クリックすることで :guilabel:`クエリBuilder を開き、 一般 タブを選択します。
次に、「適切な」= 1 クエリを構築します。
OK をクリックしてこの条件が満たされていないすべてのポリゴンをフィルタリングします。
オリジナルのラスタ上で閲覧するとその領域は完全にオーバーラップされるはずです:
レイヤーリスト 中の all_terrain レイヤー上で右クリックし 名前を付けて保存... を選択することでこのレイヤーを保存できます。その後は指示に従って続けます。
21.11.2. 結果を精査¶
Intersect ツールによって :kbd:` new_solution` レイヤー中の建物の一部が「スライス」されることがあることに気づくことがあります。これは、建物の一部のみ - それゆえ資産の一部のみ -が適した地形の上にあることを示しています。したがって、賢明にデータセットから、これらの建物を排除できます
21.11.3. 分析を改善する¶
現時点ではあなたの分析は次のように見えるはずです:
全ての方向に100メートルのための連続円形領域を考えます。
それは半径100メートルより大きい場合、（すべての方向から）、その大きさから100m減算して、それが途中で放置された部分になります。
そのため、既存の suitable_terrain ベクトルレイヤー上で100メートルの*内部バッファ*を実行できます。バッファ機能の出力においては、元のレイヤーのどんな残りも、100メートルを超えて適した地形がある領域を表すことになります。
証明するために：
ベクトル - >ジオプロセシングツール - >バッファ に行き、バッファダイアログを開きます。
このようにセットアップします:
10 のセグメントで -100 のバッファ距離で suitable_terrain レイヤーを使用します。（地図が投影CRSを使用しているため、距離は自動的にメートル単位です。）
exercise_data / residential_development / と suitable_terrain_continuous100m.shp で出力を保存。
必要に応じて、あなたのオリジナルの suitable_terrain レイヤの上に新しいレイヤを移動してください。
作業結果は次のように見えるはずです:
今 Locationで選択 ツール（ ベクトル - >研究のツール - > locationにより選択 ）を使用します。
このようにセットアップします:
:guilabel:` suitable_terrain_continuous100m.shp` の中の地物に交差する new_solution 中の地物を選択します。
結果はこちらです:
黄色の建物が選択されています。建物の一部は、新しい suitable_terrain_continuous100m レイヤー外に一部が落ちるものの、それらは元の suitable_terrain レイヤー範囲内に十分にあり、したがって私たちの要件のすべてを満たしています。
選択を exercise_data/residential_development/ 下に final_answer.shp として保存してください。
21.12. Results For WMS¶
21.12.2. 新しいWMSサーバの追加¶
新しいサーバーとそのサーバー上でホストされているように、適切なレイヤーを追加する前と同じアプローチを使用します。
Swellendam 領域にズームインした場合、このデータセットは低解像度を持っていることに気づくでしょう：
したがって、現在の地図にこのデータを使用しない方が良いです。ブルーマーブルデータは、グローバルまたは全国規模での方が適しています。
21.13. Results For データベースの概念¶
21.13.1. アドレステーブルのプロパティ¶
私たちの理論上のアドレステーブルのために、私たちは、次のプロパティを保存したい場合があります:
House Number
Street Name
Suburb Name
City Name
Postcode
Country
アドレスオブジェクトを表すために、テーブルを作成するとき、これらのプロパティのそれぞれを表現するために列を作成し、SQL準拠し、おそらく短縮名とそれらに名前を付けるでしょう:
house_number
street_name
suburb
city
postcode
country
21.13.2. 人々表を正規化します¶
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.13.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.13.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.13.5. DROPコマンド¶
people テーブルは streets テーブルへの外部キー制約があるため、DROPコマンドは、このケースでは動作しない理由があります。これは、 streets テーブルをドロップする（または削除する）、存在しない streets データを参照して people テーブルを離れることを意味します。
ノート
それは力 ‘ CASCADE`コマンドを使用して削除する streets`テーブルに可能であるが、これはまた people`と streets`テーブルへの関係を持っていた他のテーブルを削除します。注意して使用してください！
21.13.6. 新しい街路を挿入します¶
使用する必要があるSQLコマンドは、（選択した名前を持つ通りの名前を置き換えできます）、このようになります:
insert into streets (name) values ('Low Road');
21.13.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.13.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.14. Results For 空間問合せ¶
21.14.1. 空間クエリで使用される単位¶
レイヤーが使用しているCRSこれは、その単位は度であることを意味する地理CRS、あるWGS 84であるため、例えば、クエリで使用される単位は、度です。投影CRSは、UTM投影でのように、メートルです。
クエリを書くときはレイヤーのCRSがどの単位かを知る必要があることを忘れないでください。これにより期待する結果が返されるクエリを記述できるでしょう。
21.15. Results For ジオメトリ建設¶
21.15.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.15.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".
それは都市テーブルのポリゴンを作成して実験しながら、それらのいくつかを削除してやり直していなければならないことを意味します。都市テーブルのエントリをチェックし、いずれか存在する:kbd:id を使用するだけです。
21.16. Results For 簡易機能モデル¶
21.16.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.16.2. * GEOMETRY_COLUMNS表を移入*¶
insert into geometry_columns values
('','public','cities','the_geom',2,4326,'POLYGON');
21.16.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 の追加を認めています。