20. Feuille de réponses¶

20.1.1. Préparation¶

Vous devriez voir un grand nombre de lignes, symbolisant les routes. Toutes ces lignes sont dans la couche vectorielle que vous venez de charger pour créer une carte de base.

Retour au texte

20.2.1. Aperçu (Partie 1)¶

Reportez-vous à l’image montrant l’agencement de l’interface et vérifiez que vous vous souvenez des noms et fonctions des éléments de l’écran.

Retour au texte

20.2.2. Aperçu (Partie 2)¶

1. Sauvegarder sous

2. Zoom sur la couche

3. Aide

4. Rendu on/off

5. Mesurer une longueur

Retour au texte

20.3.1. Shapefiles¶

Il devrait y avoir cinq couches sur la carte:

• places
• water
• buildings

• rivers et

• roads.

Retour au texte

20.3.2. Bases de Données¶

Toutes les couches vectorielles devraient être chargées dans la carte. Cela ne donnera probablement pas un joli rendu pour le moment (nous corrigerons les couleurs laides plus tard).

Retour au texte

20.4.1. Couleurs¶

• Vérifiez que les couleurs changent telles que vous l’escomptez.

• Il suffit de changer la couche water pour l’instant. Un exemple est indiqué ci-après, mais il pourrait être différent de ce que vous avez selon la couleur que vous avez choisie.

Retour au texte

20.4.2. Structure des Symboles¶

Votre carte devrait maintenant ressembler à ça:

Si vous êtes un utilisateur débutant, vous pouvez vous arrêter ici.

• Utilisez la méthode ci-dessus pour modifier les couleurs et les styles pour toutes les couches restantes.

• Essayez d’utiliser des couleurs naturelles selon les objets. Par exemple, une route ne devrait pas être rouge ou bleue, mais peut être en gris ou en noir.

• De même, n’hésitez pas à expérimenter différents paramètres de Style de remplissage et de Style de bordure pour les polygones.

Retour au texte

20.4.3. Couches de Symbole¶

• Personnalisez votre couche buildings comme vous le voulez, mais souvenez-vous qu’il doit être facile de distinguer les différentes couches de la carte.

Voici un exemple:

Retour au texte

20.4.4. Niveaux de symboles¶

Pour obtenir le symbole requis, vous avez besoin de deux couches de symbole :

La couche de symbole du bas est une large ligne jaune continue . Au sommet de celle-ci, il y a une ligne continue grise et légèrement plus mince .

• Si vos couches de symboles ressemblent à celles de l’image au-dessus mais que vous n’obtenez pas les résultats que vous voulez, vérifiez que vos niveaux de symboles ressemblent à ceci :

  

• Maintenant, votre carte devrait ressembler à ça:

  

Retour au texte

20.4.5. Niveaux de Symbole¶

• Ajustez vos niveaux de symbole avec ces valeurs :

• Essayez différentes valeurs afin d’obtenir différents résultats.

• Ouvrez à nouveau votre carte originale avant d’aborder l’exercice suivant.

Retour au texte

20.5.1. Données Attributaires¶

Le champ NAME est le plus utile pour afficher les étiquettes. Ceci est dû au fait que toutes ses valeurs sont uniques à chacun des objets et peu susceptibles de contenir la valeur NULL. Si vos données contiennent des valeurs NULL, ne vous inquiétez pas du moment que la plupart de vos places ont des noms.

Retour au texte

20.6.1. Paramétrage des étiquettes (Partie 1)¶

Votre carte devrait maintenant représenter les symboles en points et les étiquettes devraient en être décalées de 2.0 mm: Le style des symboles et des étiquettes devraient être tout deux bien visibles sur la carte :

Retour au texte

20.6.2. Paramétrage des étiquettes (Partie 2)¶

Une solution possible aboutit à ce résultat final:

Pour arriver à ce résultat:

• Utilisez une Taille de police de 10, une Distance de 1,5 mm, une Largeur du symbole et Hauteur du symbole de 3.0 mm.

• En outre, cet exemple utilise l’option Retour à la ligne sur le caractère:

  

• Entrez un espace dans ce champ et cliquez sur Appliquer pour avoir le même effet. Dans notre cas, quelques-uns des noms de lieux sont très longs, étant alors mis sur plusieurs lignes, ce qui n’est pas très agréables. Vous pourriez trouver ce paramétrage plus approprié à votre carte.

Retour au texte

20.6.3. Utiliser les Valeurs définies par des données¶

• Toujours en mode d’édition, mettez pour le FONT_SIZE les valeurs que vous préférez. L’exemple utilise 16 pour les villes, 14 pour les banlieues, 12 pour les localités et 10 pour les hameaux.

• Pensez à sauvegarder vos modifications et sortir du mode d’édition.

• Retournez dans les options de format du Texte de la couche places et sélectionnez FONT_SIZE dans Champ d’attribut du menu déroulant de la taille de police.

  

  Vos résultats, en utilisant les valeurs ci-dessous, devraient être ceux-ci:

  

Retour au texte

20.7.1. Affiner la Classification¶

• Utiliser la même méthode que dans le premier exercice de la leçon pour vous débarrasser des bordures:

  

Les paramètres que vous avez utilisés pourraient ne pas être les mêmes mais, avec Classes = 6 et Mode = Ruptures Naturelles (Jenks) (et bien sûr, en utilisant les mêmes couleurs), la carte ressemblera à ça:

Retour au texte

20.8.1. Numérisation¶

Le style importe peu, mais les résultats devraient plus ou moins ressembler à celui-ci:

Retour au texte

20.8.2. Topologie: Outil Ajouter un Anneau¶

La forme exacte importe peu, mais vous devriez obtenir un trou au centre de votre entité, comme sur celle-ci:

• Annulez vos modifications avant d’entamer l’exercice du prochain outil.

Retour au texte

20.8.3. Topologie: Outil Ajouter une Partie¶

• Tout d’abord, sélectionner Bontebok National Part:

• Maintenant, ajoutez votre nouvelle partie:

• Annulez vos modifications avant d’entamer l’exercice du prochain outil.

Retour au texte

20.8.4. Fusionner les entités¶

• Utilisez l’outil Fusionner les entités sélectionnées en vous assurant d’avoir au préalable sélectionné les deux polygones que vous souhaitez fusionner.

• Utilisez l’entité avec le OGC_FID de 1 comme la source de vos attributs (cliquez sur son entrée dans la boîte de dialogue, puis cliquez sur le bouton Prendre les attributs de l’entité sélectionnée) :

Note

Si vous utilisez un jeu de données différent, il est fort probable que le

OGC_FID de votre polygone d’origine ne soit pas de 1. Choisissez simplement l’entité qui a un OGC_FID.

Retour au texte

20.8.5. Formulaires¶

Pour le TYPE, il y a de toute évidence un nombre maximum de types de voies, et si vous regardez la table attributaire de cette couche, vous verrez qu’ils sont prédéfinis.

• Mettez l’outil sur Valeur de carte et cliquez sur Charger les données depuis la couche.

• Sélectionnez routes dans le menu déroulant Couche et autoroute pour les options Valeur et Description :

  

• Cliquez sur Ok trois fois.

• Si vous utilisez maintenant l’outil Identifier sur une rue pendant que le mode d’édition est activé, la boîte de dialogue que vous obtenez ressemble à ceci :

  

Retour au texte

20.9.1. Extraire vos couches à partir des données OSM¶

Aux fins de cet exercice, les couches OSM auxquelles nous nous intéressons sont des multipolygons et des lines. La couche multipolygons contient les données dont nous avons besoin pour produire les couches houses, schools and restaurants. La couche lines contient les jeux de données des routes.

Le Constructeur de requêtes se trouve dans les propriétés de la couche:

En utilisant le Constructeur de requêtes pour la couche multipolygon, créez les requêtes suivantes pour les couches houses, schools, restaurants et residential :

Une fois que vous avez entré chaque requête, cliquez sur OK. Vous verrez que la carte met à jour la vue uniquement pour les données que vous aviez sélectionnées. Puisque vous aurez besoin d’utiliser à nouveau les données multipolygon du jeu de données OSM, à ce stade, vous pouvez utiliser une de ces méthodes suivantes :

• Renommer la couche OSM filtrée et ré-importer la couche osm_data.osm, OU

• Dupliquer la couche filtrée, renommer la copie, effacer la requête et créer votre nouvelle requête dans le Constructeur de requêtes.

Pour créer la couche roads, construisez cette requête pour la couche OSM lines :

Vous devriez vous retrouver avec une carte qui ressemble à ce qui suit :

Retour au texte

20.9.2. Distance des écoles secondaires¶

• Votre boîte de dialogue du tampon devrait ressembler à cela :

  

  La Distance tampon est 1000 mètres (c’est-à-dire, 1 kilomètre).

• La valeur Segments pour l’approximation est fixée à 20. C’est optionnel, mais recommandé, car il rend les contours de tampon plus lisses. Comparez ceci :

  

  A cela :

  

La première image montre le tampon avec la valeur Segments pour l’approximation fixée à 5 et la seconde montre la valeur fixée à 20. Dans notre exemple, la différence est subtile, mais vous pouvez voir que les angles du tampon sont plus lisses avec la plus grande valeur.

Retour au texte

20.9.3. Distance des Restaurants¶

Pour créer la nouvelle couche houses_restaurants_500m, nous allons passer par un processus en deux étapes :

• Premièrement, créez un tampon de 500m autour des restaurants et ajouter la couche à la carte.

  

• Puis, sélectionnez les bâtiments dans cette zone tampon :

  

• Maintenant, sauvez la sélection dans notre nouvelle couche houses_restaurants_500m :

  

Votre carte devrait maintenant montrer uniquement les bâtiments qui sont à 50m d’une route, 1km d’une école et 500m d’un restaurant :

Retour au texte

20.10.1. Calculer l’aspect¶

• Configurez votre boîte de dialogue DEM (Analyse de terrain) comme ceci :

  

Votre résultat:

Retour au texte

20.10.2. Calcul de la pente (moins que 2 et 5 degrés)¶

• Configurez votre boîte de dialogue Calculatrice Raster comme ceci :

  

• Pour la version à 5 degrés, remplacer le 2 dans l’expression et le nom du fichier avec 5.

Vos résultats:

• 2 degrés :

  

• 5 degrés :

  

Retour au texte

20.11.1. Raster vers Vecteur¶

• Ouvrez le Constructeur de requête en faisant un clic-droit sur la couche all_terrain dans la Légende, sélectionnez l’onglet Général.

• Ensuite, créez la requête "suitable" = 1.

• Cliquez sur OK pour filtrer tous les polygones où cette condition n’est pas respectée.

Lorsqu’on regarde sur le raster d’origine, les zones doivent se chevaucher parfaitement :

• Vous pouvez sauver cette couche en faisant un clic-droit sur la couche all_terrain dans la Légende et choisir Sauvegarder sous..., puis continuez en suivant les instructions :

Retour au texte

20.11.2. Contrôler les résultats¶

Vous pouvez remarquer que certains des bâtiments dans votre couche new_solution ont été “tranché” par l’outil Intersection. Cela montre que seule une partie du bâtiment - et donc qu’une partie de la propriété - repose sur un terrain approprié. Nous pouvons donc sensiblement éliminer ces bâtiments de notre jeu de données.

Retour au texte

20.11.3. Affiner l’analyse¶

A ce stade, votre analyse devrait ressembler à peu près à ceci:

Considérez une aire circulaire, continue sur 100 mètres dans toutes les directions.

If it is greater than 100 meters in radius, then subtracting 100 meters from its size (from all directions) will result in a part of it being left in the middle.

Therefore, you can run an interior buffer of 100 meters on your existing suitable_terrain vector layer. In the output of the buffer function, whatever remains of the original layer will represent areas where there is suitable terrain for 100 meters beyond.

To demonstrate:

• Allez à Vecteur ‣ Outils de géotraitement ‣ Tampon(s) pour ouvrir la fenêtre Tampon(s).

• Définissez-le comme ceci:

  

• Utilisez la couche suitable_terrain avec 10 segments et une distance tampon de -100. (La distance est automatiquement en mètres car votre carte utilise une projection CRS.)

• Sauvegardez la sortie dans exercise_data/residential_development/ comme suitable_terrain_continuous100m.shp.

• Si nécessaire, déplacez la nouvelle couche au-dessus de votre couche d’origine suitable_terrain.

Votre résultat ressemblera à peu près à ceci :

• Maintenant, utilisez l’outil Sélection par localisation (Vecteur ‣ Outils de recherche ‣ Sélection par localisation).

• Configurez comme suit :

  

• Sélectionnez les entités de new_solution qui croisent les entités de suitable_terrain_continuous100m.shp.

Voici le résultat:

Les bâtiments jaunes sont sélectionnés. Bien que certains des bâtiments soient en partie à l’extérieur de la nouvelle couche suitable_terrain_continuous100m, ils se trouvent bien dans la couche d’origine suitable_terrain et répondent donc à toutes nos exigences.

• Sauvegardez la sélection sous exercise_data/residential_development/ comme final_answer.shp.

Retour au texte

20.12.1. Ajout d’une autre couche WMS¶

Votre carte devrait ressembler à ceci (vous aurez peut-être besoin de réorganiser vos couches):

Retour au texte

20.12.2. Ajout d’un Nouveau Serveur WMS¶

• Utilisez la même approche qu’avant pour ajouter le nouveau serveur et la couche appropriée comme hébergée sur ce serveur :

  

• Si vous zoomez sur la zone Swellendam, vous remarquerez que ce jeu de données a une basse résolution :

Par conséquent, il est préférable de ne pas utiliser ces données pour la carte actuelle. Les données Blue Marble sont plus adaptée à une échelle globale ou nationale.

Retour au texte

20.12.3. Trouver un serveur WMS¶

Vous pouvez remarquer que la plupart des serveurs WMS ne sont pas toujours disponibles. Quelque fois cela est temporaire, d’autres fois permanent. Un exemple d’un serveur WMS qui fonctionne au moment de l’écriture est le World Mineral Deposits WMS sur http://apps1.gdr.nrcan.gc.ca/cgi-bin/worldmin_en-ca_ows. Il ne nécessite pas de frais ou n’a pas de contraintes d’accès, et il est mondial. Par conséquent, il satisfait les prérequis. Gardez cependant à l’esprit que ce n’est qu’un exemple. Il existe beaucoup d’autres serveurs WMS possibles.

Retour au texte

20.13.1. Propriétés de la table d’adresses¶

Pour notre table d’adresses théorique, nous pourrions stocker les propriétés suivantes :

House Number
Street Name
Suburb Name
City Name
Postcode
Country

When creating the table to represent an address object, we would create columns to represent each of these properties and we would name them with SQL-compliant and possibly shortened names:

house_number
street_name
suburb
city
postcode
country

Retour au texte

20.13.2. Normalisation de la table Personne¶

The major problem with the people table is that there is a single address field which contains a person’s entire address. Thinking about our theoretical address table earlier in this lesson, we know that an address is made up of many different properties. By storing all these properties in one field, we make it much harder to update and query our data. We therefore need to split the address field into the various properties. This would give us a table which has the following structure:

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

Retour au texte

20.13.3. Further Normalisation of the People Table¶

Notre table people ressemble actuellement à ceci:

id |     name     | house_no | street_id |  phone_no
---+--------------+----------+-----------+-------------
 1 | Horst Duster |        4 |         1 | 072 121 122

The street_id column represents a ‘one to many’ relationship between the people object and the related street object, which is in the streets table.

One way to further normalise the table is to split the name field into first_name and last_name:

id | first_name | last_name  | house_no | street_id |  phone_no
---+------------+------------+----------+-----------+------------
 1 |    Horst   |   Duster   |     4    |     1     | 072 121 122

We can also create separate tables for the town or city name and country, linking them to our people table via ‘one to many’ relationships:

id | first_name | last_name | house_no | street_id | town_id | country_id
---+------------+-----------+----------+-----------+---------+------------
 1 |    Horst   |   Duster  |     4    |     1     |    2    |     1

Un diagramme ER pour représenter cela devrait ressembler à ça :

Retour au texte

20.13.4. Create a People Table¶

The SQL required to create the correct people table is:

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 );

The schema for the table (enter d people) looks like this:

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)

Retour au texte

20.13.5. La commande DROP¶

The reason the DROP command would not work in this case is because the people table has a Foreign Key constraint to the streets table. This means that dropping (or deleting) the streets table would leave the people table with references to non-existent streets data.

Retour au texte

20.13.6. Insérer une nouvelle rue¶

La commande SQL que vous devez utiliser ressemble à cela (vous pouvez remplace le nom de la rue avec un nom de votre choix) :

insert into streets (name) values ('Low Road');

Retour au texte

20.13.7. Add a New Person With Foreign Key Relationship¶

Voici la syntaxe SQL correcte à utiliser :

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');

Si vous regardez à nouveau dans la table des rues (en utilisant une déclaration de sélection comme avant), vous verrez que l’id pour l’entrée Main Road est 2.

That’s why we could merely enter the number 2 above. Even though we’re not seeing Main Road written out fully in the entry above, the database will be able to associate that with the street_id value of 2.

that the new Main Road has an ID of 3 not 2.

Retour au texte

20.13.8. Return Street Names¶

Voici la syntaxe SQL correcte à utiliser:

select count(people.name), streets.name
from people, streets
where people.street_id=streets.id
group by streets.name;

Résultat:

count |    name
------+-------------
    1 | Low Street
    2 | High street
    1 | Main Road
(3 rows)

(e.g. people.name and streets.name). This needs to be done whenever the

field name is ambiguous (i.e. not unique across all tables in the database).

Retour au texte

20.14.1. Les Unités utilisées dans les requêtes spatiales¶

Les unités utilisées dans l’exemple de requête sont des degrés, car le SCR utilisé pour la couche est WGS 84. C’est un SCR géographique, ce qui signifie que ses unités sont en degrés. Un SCR projeté, comme les projections UTM, est en mètres.

Souvenez-vous que lorsque vous écrivez une requête, vous avez besoin de savoir quelles unités le SCR de la couche utilise. Cela vous permettra d’écrire une requête qui retournera le résultat que vous attendez.

Retour au texte

20.14.2. Création d’un Index Spatial¶

CREATE INDEX cities_geo_idx
  ON cities
  USING gist (the_geom);

Retour au texte

20.15.1. Création de polylignes¶

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);

Retour au texte

20.15.2. Linking Tables¶

delete from people;
alter table people add column city_id int not null references cities(id);

(capture cities in 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,
           '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)');

Si vous obtenez le message d’erreur suivant:

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".

then it means that while experimenting with creating polygons for the cities table, you must have deleted some of them and started over. Just check the entries in your cities table and use any id which exists.

Retour au texte

20.16.1. Populating Tables¶

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 );

Retour au texte

20.16.2. Populate the Geometry_Columns Table¶

insert into geometry_columns values
      ('','public','cities','the_geom',2,4326,'POLYGON');

Retour au texte

20.16.3. Adding Geometry¶

select people.name,
       streets.name as street_name,
       st_astext(people.the_geom) as geometry
from   streets, people
where  people.street_id=streets.id;

Résultat:

     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)

Comme vous pouvez le voir, notre contrainte autorise l’ajout de valeurs nulles dans la base de données.

Retour au texte