Vous évitez les fonctionnalités d'étiquetage si elles sont chevauchées par une autre couche dans QGIS?


16

Avec QGIS 2.12.2, comment puis-je configurer l'étiquetage des couches pour éviter de placer des étiquettes là où des entités d'une autre couche existent déjà?

Par exemple, si j'ai une couche de polyligne de cours d'eau / rivière qui contient des "lignes centrales" de lac et que je place une couche de polygone "lac" au-dessus dans l'ordre de dessin, je ne veux pas que la couche de rivière place une étiquette à l'intérieur du lac . Au lieu de cela, je préfère que la rivière soit étiquetée à l' extérieur du lac (au besoin). De cette façon, je peux placer des étiquettes à partir de la couche des lacs et je ne rencontre pas de collisions d'étiquettes.

Voici un exemple, où (j'ai intentionnellement placé les lignes au-dessus à des fins visuelles) ce que j'espère réaliser n'est pas d'étiquettes de ligne médiane de la rivière affichées à l'intérieur du polygone du lac: Les lignes marquent l'intérieur du polygone


4
Comment vos données sont-elles stockées et servies? En travaillant avec PostGIS, je serais tenté de définir mes rivières avec une vue, où les parties des rivières qui croisent les lacs sont entièrement coupées. Un bon étiquetage automatisé est un problème difficile, la géométrie l'est moins.
alphabetasoup

Il s'agissait de fichiers de formes, mais votre idée de passer à PostGIS et de gérer les problèmes de données à la volée est vraiment bonne. Je vous suggère de déplacer votre commentaire vers une réponse, car je pourrais faire un argument assez valable que c'est une bonne résolution.
RyanKDalton

Réponses:


9

L'étiquetage automatisé est un problème très difficile, mais la géométrie des entités n'est pas si mauvaise.

Même si le placement peut fonctionner correctement la plupart du temps, il y aura probablement des exceptions. Vous en remarquerez certaines et vous pourrez peut-être les résoudre. D'autres que vous ne remarquerez pas lorsque vous créez une grande carte ou un ensemble de tuiles, car vous ne pouvez pas verser chaque centimètre de votre carte à différentes échelles. Presque toujours, vous aurez envie de déplacer manuellement certaines étiquettes placées automatiquement, d'un point de vue cartographique.

Comme je l'ai suggéré dans mon commentaire, je faciliterais le problème pour le moteur d'étiquetage. Dans ce cas, je le ferais en définissant mes rivières comme une vue de table *, avec des géométries de rivière coupées pour respecter les limites du lac. De cette façon, il n'y a pas d'entités fluviales à l'intérieur des lacs à étiqueter et pas de collisions d'étiquettes.

* Je suppose que l'utilisation d'un SGBDR ici, comme PostgreSQL / PostGIS, pour plus de commodité et la possibilité de mettre à jour uniquement votre source de données faisant autorité et de faire fonctionner la vue elle-même sans votre intervention. Mais vous pouvez également travailler à l'avance avec des fichiers statiques pour découper et supprimer des entités, mais je ne le recommande pas si vous prévoyez de revoir une carte.

Exemple:

En commençant par deux fichiers de formes (qui pourraient être des tableaux de bases de données) de rivières et de lacs, les rivières intersectant les lacs et causant des problèmes d'étiquetage difficiles à résoudre complètement et en toute confiance:

entrez la description de l'image ici

Apportez-les dans Postgres si vous en avez besoin avec shp2pgsql :

shp2pgsql -s 4326 /data/lake public.lakes | psql -d mydb

shp2pgsql -s 4326 /data/river public.rivers | psql -d mydb

Définissez ensuite une vue avec ST_Difference :

CREATE OR REPLACE VIEW rivers_clipped AS
SELECT r.id, ST_Difference(r.geom, l.geom) AS geom, r.name
FROM public.rivers AS r, public.lakes AS l;

Ajoutez la vue à votre mise en page:

entrez la description de l'image ici

Bien que le problème dans mon exemple soit délibérément fabriqué, les styles des deux couches de la rivière (original et vue) sont les mêmes, et ils sont placés au-dessus du lac dans l'ordre de dessin. Lorsque vous mettez à jour les géométries des lacs ou des rivières, vous n'aurez pas besoin de faire beaucoup plus que d'actualiser le rendu.

entrez la description de l'image ici


2
Même si je ne travaillais pas directement avec une couche de base de données, cette solution était la plus logique pour moi, car elle ne nécessitait pas de modifier la géométrie des sources de données initiales (autre que de les charger dans la base de données). Il s'agit d'un excellent exemple pour sortir des limites des fichiers de formes et des limites des applications, et pour trouver une solution créative au problème en combinant à la fois la logique d'application et la logique de base de données.
RyanKDalton

13

Dans QGIS> = 2.12, vous pouvez définir la couche polygonale "lac" comme obstacle d'étiquette. Cela se fait via les propriétés de la couche de la couche "lac", sous la section "Étiquettes". Modifiez la zone de liste déroulante en haut de " Pas d'étiquettes " à " Décourager les autres étiquettes de couvrir les entités de ce calque ".


1
Merci. Je cherchais quelque chose comme ça, et je n'avais pas remarqué cette option déroulante auparavant. Cependant, je dirais que cela n'a été que modérément réussi. 1) Il n'y a que "une sorte de" sorte d'étiquettes découragées de la couche River (elles apparaissent toujours dans le lac, mais moins), et 2) maintenant je n'ai pas mes étiquettes de nom de lac :( J'ai également essayé de définir les étiquettes de la rivière> Obstacles "Décourager les étiquettes de couvrir les fonctionnalités" (pas de succès) et de définir des poids bas et élevé (pas de succès), et de définir Placement> Priorité = faible et élevé (pas de succès).
RyanKDalton

Ah, peut-être que j'ai mal compris. Si vous avez des étiquettes sur la couche lac, assurez-vous que la case "décourager les étiquettes de recouvrir les entités" sous l'onglet de rendu est cochée. Vous devrez peut-être jouer avec le curseur "poids" et d'autres options de ce groupe pour obtenir les résultats souhaités.
ndawson

1
Non, vous étiez définitivement sur la bonne voie. J'ai joué avec les poids (poids élevé sur les polygones du lac + "minimiser le placement d'étiquettes sur l'intérieur des caractéristiques, faible poids sur les rivières) et je me suis rapproché, mais je n'ai jamais vraiment atteint le point où les étiquettes de la rivière n'étaient pas sur le lac. Le problème semble être associé à des lignes qui sont à la fois à l'intérieur et à l'extérieur du polygone
RyanKDalton

4
pourquoi ne supprimez-vous pas (ou ne divisez-vous pas) ces lignes en ce qui concerne l'étiquetage? De toute façon, ils ne sont pas utiles pour votre carte.
radouxju

4

Je trouve l'étiquetage en général assez difficile, au moins pour générer des étiquettes qui plaisent aux sens de mon cartographe. Bien que la fonction d'étiquetage automatique fonctionne correctement 80% du temps, il existe des cas comme votre problème d'étiquetage de rivière / lac où il ne génère pas un bel étiquetage. L'étiquetage automatique est souvent lié à la géométrie de l'entité, par exemple le nombre de pièces sur une ligne, de sorte qu'au début, toutes les pièces sont étiquetées. Bien sûr, QGIS a les moyens d'empêcher l'étiquetage répété, qui dépend également de l'échelle de la vue cartographique actuelle.

De toute façon, mon conseil n'est pas une solution rapide. Je crée souvent un calque spécialisé juste pour l'étiquetage, afin que mes étiquettes soient plus facilement contrôlées. Et souvent, la géométrie des caractéristiques pour la représentation cartographique peut entrer en collision avec une bonne géométrie pour l'étiquetage. Je proposerais donc de créer une nouvelle couche où les cours d'eau ne traversent pas les lacs, afin que vous puissiez contourner complètement le problème. Le fait d'avoir une couche d'étiquetage supplémentaire peut également aider à éviter les problèmes lorsque la direction d'étiquetage n'est pas celle voulue car elle est liée à la façon dont la géométrie a été créée.

Eh bien, je crains que mon conseil ne soit pas ce que vous attendiez, mais j'espère que mon approche alternative pourra vous aider d'une manière ou d'une autre.


Vous faites valoir que je pourrais créer un nouvel ensemble de données (ce qui serait facile à faire dans ce cas ... effacez simplement les entités linéaires sous les polygones), doubler des ensembles de données ne semble pas trop attrayant ou gérable, sauf si vous utilisez une méthode basée sur une base de données comme @Richard Law mentionnée.
RyanKDalton

Je vois votre point et je comprends votre hésitation à créer deux fois un ensemble de données similaire. D'après mon expérience, la couche d'étiquettes est souvent plus différente que la couche de données d'origine. Par exemple, pour vous en tenir à votre exemple de rivière, vous souhaiterez peut-être modifier davantage la géométrie de la rivière pour joindre ou diviser des pièces d'entité afin de créer un étiquetage plus agréable qui sera répété plus régulièrement. C'est du moins souvent le cas pour moi lorsqu'il s'agit de routes OSM par exemple qui sont parfois organisées de façon assez arbitraire.
Frank

3

il existe un plugin appelé " Mask " qui peut être utilisé pour filtrer les étiquettes en fonction des polygones.

Comme mentionné dans mon commentaire précédent, cependant, il serait beaucoup plus facile si vous pouviez diviser vos lignes à l'intersection avec les lacs (voir les différentes méthodes ici ). Ensuite, vous pouvez définir une étiquette de taille nulle pour les segments qui se trouvent dans les lacs ("Couche"> "Étiquetage"> "Paramètres définis par les données"> "Taille" puis sélectionnez la colonne dans laquelle vous stockez la taille d'étiquette). Le fractionnement conserve la plupart des propriétés de votre réseau fluvial et est réversible avec la dissolution, vous pouvez donc continuer à travailler avec une seule couche (stocker la longueur totale dans une table d'attributs spécifique si nécessaire).


Merci, le plugin semble prometteur, donc je vais essayer.
RyanKDalton
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.