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.
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.
Sauvegarder sous
Zoom sur la couche
Aide
Rendu on/off
Mesurer une longueur
Il devrait y avoir cinq couches sur la carte:
rivers et
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).
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.
Note
Si vous souhaitez travailler sur une seule couche à la fois et ne pas être perturbé par d’autres couches, vous pouvez cacher le contenu de ces couches en cliquant sur la case à cocher à côté du nom dans la liste des couches. Si la case est vide, alors la couche ne sera pas affichée.
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.
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:
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:
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.
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.
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 :
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.
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:
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:
Le style importe peu, mais les résultats devraient plus ou moins ressembler à celui-ci:
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.
Tout d’abord, sélectionner Bontebok National Park:
Maintenant, ajoutez votre nouvelle partie:
Annulez vos modifications avant d’entamer l’exercice du prochain outil.
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
OGC_FID de votre polygone d’origine ne soit pas de 1. Choisissez simplement l’entité qui a un OGC_FID.
Note
Utiliser l’outil Fusionner les attributs des entités sélectionnées conservera les géométries distinctes mais leur affecte les mêmes attributs.
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 :
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 avez 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 l’une des 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.
Note
Bien que le champ OSM building dispose d’une valeur house, la couverture de votre aire de travail peut ne pas être complète. Dans notre région de test il plus précis d’exclure tous les bâtiments qui n’ont pas pour valeur house. Vous pouvez décider d’inclure simplement les bâtiments qui sont définis comme house ainsi que toutes les autres valeurs qui n’ont pas une signification précise comme yes.
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 :
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.
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 :
Configurez votre boîte de dialogue DEM (Analyse de terrain) comme ceci :
Votre résultat:
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 :
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 :
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.
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.
Si elle dispose d’un rayon de plus de 100m, retirer 100m de sa taille (dans toutes les directions) résultera dans l’apparition d’une partie restant au milieu.
Vous pouvez donc lancer un tampon intérieur de 100m dans la couche vecteur suitable_terrain. Dans la sortie de la fonction de tampon, tout ce qui restera de la couche originelle représentera les surfaces disposant de plus de 100m autour.
Pour le démontrer:
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.
Votre carte devrait ressembler à ceci (vous aurez peut-être besoin de réorganiser vos couches):
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.
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.
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
Lors de la création de la table qui représentera les objets adresse, nous allons créer des colonnes qui représentent chacune de ces propriétés et nous allons les nommer avec des noms courts conformes au SQL:
house_number
street_name
suburb
city
postcode
country
Le problème principal avec la table people est qu’elle contient un seul champ adresse qui enregistre l’adresse complète d’une personne. En pensant à la table address étudiée précédemment, nous savons qu’une adresse est composée de plusieurs éléments. En stockant ces éléments dans un seul champ, il sera plus complexe de mettre à jour et de requêter nos données. Nous devons donc séparer le champ adresse en autant d’éléments que nécessaire. Cela nous donnera une table avec la structure suivante:
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
Note
Dans la prochaine section, vous étudierez les relations basées sur les clefs étrangères qui peuvent s’appliquer à cet exemple pour améliorer la structure de notre base de données.
Notre table people ressemble actuellement à ceci:
id | name | house_no | street_id | phone_no
---+--------------+----------+-----------+-------------
1 | Horst Duster | 4 | 1 | 072 121 122
La colonne street_id représenter une relation ‘un à plusieurs’ entre les objets people et l’objet lié street qui est stocké dans la table streets.
Un moyen d’améliorer la normalisation de la table est de séparer le champ de nom en deux: first_name et last_name:
id | first_name | last_name | house_no | street_id | phone_no
---+------------+------------+----------+-----------+------------
1 | Horst | Duster | 4 | 1 | 072 121 122
Nous pouvons également créer des tables séparées pour le nom des villes ou des villages et pour le nom des pays en les liant à notre table people via une relation ‘un à plusieurs’:
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 :
Voici la requête SQL pour créer une table de personnes correcte:
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 );
Le schéma de la table (entrez \d people) ressemble à ceci
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)
Note
Pour des questions d’affichage, nous avons délibérément omis la contrainte de clef étrangère.
La raison pour laquelle la commande DROP ne fonctionne pas dans ce cas est parce que la table people dispose d’une contrainte de clef étrangère vers la table streets. Cela signifie que détruire (ou supprimer des enregistrements dans) la table streets laisserait des entrées de la table people qui pointeraient vers des références non existantes de la table streets.
Note
Il est possible de ‘forcer’ la suppression d’enregistrements dans la table streets en utilisant la commande CASCADE. Néanmoins, cela supprimerait également des enregistrements dans la table people`et toute autre table qui disposerait d’une relation avec la table `streets. A utiliser avec précaution !
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');
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.
C’est pourquoi nous pouvons seulement saisir le numéro 2 ci-dessus. Même si nous ne voyons pas le terme Main Road écrit complètement dans la requête précédente, la base de données sera capable de l’associer avec le champ street_id ayant une valeur de 2.
Note
Si vous avez déjà ajouté un nouvel objet street, vous pourriez trouver que le nouveau Main Road a un identifiant à 3 et non à 2.
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)
Note
Vous avez noté que nous avons préfixé les noms des champs avec les noms des tables (ex: people.name et streets.name). Il est nécessaire de le faire lorsque les noms des champs sont ambigus (c’est-à-dire que plusieurs tables ont les mêmes noms de champs dans la base de données).
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.
CREATE INDEX cities_geo_idx
ON cities
USING gist (the_geom);
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);
delete from people;
alter table people add column city_id int not null references cities(id);
(Capturer les villes dans 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)');
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".
cela indique que lors de votre expérimentation de création de polygones pour la table des villes, vous avez dû en supprimer quelques-uns. Vérifiez les enregistrements de votre table de ville et utiliser un id qui existe.
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 );
insert into geometry_columns values
('','public','cities','the_geom',2,4326,'POLYGON');
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.