PSMV Cône de vue PRES 40-50

[GT-CNIG-DDU]

J'avais posé la question au Ministère de la Culture, afin de savoir

si le symbole est orienté
si le symbole est ponctuel ou bi-linéaire ou cela les importe peu
si l'angle est constant à 30°
si l'arc de cercle à proximité de l'intersection est important ou pas

[GT-CNIG-DDU]

Le Ministère de la Culture a répondu :

• L’orientation du cône de vue peut-être modulée en fonction de la direction ;
• Le cône de vue reste le même (pas de modification des angles) et l’arc de cercle doit être également maintenu ;
• Enfin ce cône de vue est une « indication » qui peut être ponctuelle et non exhaustive, le cône de vue devant renvoyer vers une liste détaillée.

Il s'agit donc d'un symbole ponctuel (pouvant être) orienté

[GT-CNIG-DDU]

Le Ministère de la Culture a complété sa réponse :

Le cône de vue est orienté en fonction du point de vue à protéger sur un monument ou un lieu remarquable. A noter que ce cône de vue peut être également utilisé dans un immeuble bâti, pour maintenir la transparence d’un porche et protéger la vue qui apparaît depuis la rue sur des immeubles protégés.

Une liste intégrée aux pièces écrites du règlement ou au document graphique permet de préciser ce qui est protégé par ces cônes de vue : perspective, vue cadrée, vue panoramique, etc.

Une fiche pratique a été mise en ligne ici sur le site internet du ministère sur la légende des PSMV. (et ici sur le Drive du GT CNIG DDU)

[alhyss]

Ok... Donc il faut modifier le standard pour spécifier un champ où stocker l'angle ?

[GT-CNIG-DDU]

Exactement. Soit créer un champ, soit utiliser le champ TXT en décrivant un quatrième cas : ex4 : azimut d'une prescription "cône de vue" (codée 40-50) | valeur vide autorisée sauf si TYPESC = 40 et STYPEPSC = 50 Qu'en pensez-vous ? Mais cela suppose aussi que l'on arrive à orienter le symbole.

[alhyss]

Est-ce que le champ TXT ne devrait pas plutôt contenir la référence/le numéro du cône de vue dans la liste ?

[GT-CNIG-DDU]

Tu as raison. Donc :

• soit un nouveau champ, par exemple : ORIENTATION, à définir l'unité (probablement degré) la référence de l'azimut (azimut=0 est le nord ?) et le sens (est-ce le sens trigonométrique ?)
• soit une convention du type : TXT (qui est limité à 10 caractères) rempli par (n° cône)(separateur)(azimut) ex : 12-165 ou 12DIR165 ou 12AZIMU165 ou 12ORIEN165, avec ces trois éléments obligatoires (et par convention <n° cône>='0' en absence de numéro)

La modification du standard relèvera du GT DDU, suivant recommandations du SG5. Cela suppose aussi que l'on arrive à orienter le symbole, je suppose que oui pour QGIS et ArcGIS, @JenniferIGN nous répondra pour Geoserver. Ces trois outils et leurs paramètres peuvent nous guider dans le choix de l'unité, le sens et la direction de référence (azimut=0)

[alhyss]

ORIENTATION fait 11 caractères, c'est un de trop pour les shapefiles...

Le symbole est composé des signes < et ), qui sont tous deux horizontaux, donc côté QGIS le style utilisera un angle à partir de l'horizontale, mais ça ne change pas grand chose de partir d'un azimut et de lui enlever 90°. Par contre, ça simplifierait beaucoup les choses de dire qu'on parle de l'angle entre la verticale et l'axe de symétrie du symbole (et pas avec la branche supérieure du <).

Je ne sais pas trop pour ce qui est de mettre l'angle en plus du numéro dans le champ TXT. Ça ne me semble pas très lisible pour les utilisateurs, qui risquent d'essayer de trouver "12-165" dans la liste des cônes de vue.

Et donc, oui, côté QGIS produire un symbole orienté selon un attribut ne posera aucun problème.

[alhyss]

En attendant la modification du standard PSMV, proposition de spécification pour la PSC 40-50 avec un symbole non orienté :

Symbole de police
• caractère(s) : < (unicode 60)
• couleur de remplissage (RVB) : 255,0,0
• décalage (en x, en y) : 0,-3 pt
• famille de police : Times New Roman
• taille : 30 pt

Symbole de police
• caractère(s) : ) (unicode 41)
• couleur de remplissage (RVB) : 255,0,0
• couleur de trait (RVB) : 255,0,0
• décalage (en x, en y) : 0,-1 pt
• famille de police : Arial
• largeur de trait : 0.8 pt
• taille : 7 pt

C'est surtout sur la taille que je m'interroge (cf. discussion dans l'issue #11). Le symbole ci-avant reste plus gros que les ponctuels PLU, comme cela avait été suggéré. Est-ce que l'équilibre vous paraît bon entre visibilité sur les plans et minimisation des risques de superposition ? Je l'ai aussi allégé un peu pour qu'il ne cache pas tout s'il est placé sur des bâtiments, mais je ne sais pas si ça suffit.

[GT-CNIG-DDU]

@alhyss je note ta remarque sur la longueur du champ. Le projet GPU donnera son avis sur les options ajout champ / convention TXT. A ce sujet, je viens de me souvenir de la demande de @JenniferIGN et je viens d'inviter M. Dumont au Github. Concernant la symbolisation, l'angle devrait être plus aigu et le symbole beaucoup plus allongé si l'on se réfère à la légende nationale et à l'illustration de la fiche pratique du Ministère de la culture :

[alhyss]

Le truc, c'est que plus le symbole ressemble à un véritable angle, plus on pensera (à tort) que c'en est un... Je trouve moins trompeur d'avoir un symbole plus clairement schématique, à mi-chemin entre l'angle et l'oeil.

Si on voulait un aspect plus proche de celui de la légende, on pourrait faire quelque chose comme ça (en passant sur le fait que ça ne tient plus dans le carreau de visualisation) :

Symbole de police
• caractère(s) : ) (unicode 41)
• couleur de remplissage (RVB) : 255,0,0
• couleur de trait (RVB) : 255,0,0
• décalage (en x, en y) : 10,-1 pt
• famille de police : Arial
• largeur de trait : 0.8 pt
• taille : 3 pt

Symbole simple
• couleur de trait (RVB) : 255,0,0
• décalage (en x, en y) : 0,-15 pt
• largeur de trait : 1.2 pt
• nom du symbole : line
• rotation : 80°
• style de trait : ligne continue
• taille : 30 pt

Symbole simple
• couleur de trait (RVB) : 255,0,0
• décalage (en x, en y) : 0,-15 pt
• largeur de trait : 1.2 pt
• nom du symbole : line
• rotation : 100°
• style de trait : ligne continue
• taille : 30 pt

[GT-CNIG-DDU]

@alhyss : je suis d'accord avec cette proposition de symbolisation, mai si je comprends bien les trois composantes (1 ponctuel + 2 lignes) devraient être orientées, mais je ne vois pas de rotation pour le ")" L'angle me paraît supérieur à 20° dans la légende, j'ai mesuré 25°

[GT-CNIG-DDU]

Je reviens sur l'évolution du standard PSMV : 1- soit un nouveau champ, je propose ANGLE en cohérence avec les informations HABILLAGETXT du standard PLU : "ANGLE (entier) : Angle de l’écriture exprimé en degré, par rapport à l’horizontale, dans le sens trigonométrique"_ 2- soit une convention du type : TXT (qui est limité à 10 caractères) rempli par (n° cône)(separateur)(azimut) ex : 12-165 ou 12DIR165 ou 12AZIMU165 ou 12ORIEN165, avec ces trois éléments obligatoires (et par convention <n° cône>='0' en absence de numéro) Remarque : dans les deux cas définir le sens : trigo ou anti-trigo. Apparemment QGIS utilise plutôt le sens anti-trigonométrique.

@JenniferIGN et @mariondumont : le projet GPU peut-il :

• nous confirmer que geoserver supporte l'orientation des symboles ponctuels et linéaires cf la proposition ci-dessus de @alhyss, et préciser le sens utilisé (trigo, anti-trigo)
• nous donner son avis sur les options (1) "ajout attribut ANGLE" ou (2) "nouvelle convention pour l'attribut TXT".

[JenniferIGN]

@GT-CNIG-DDU

• Le sens est anti-trigo pour Geoserver, on peut appliquer une orientation mais il y a déjà des soucis pour caler < et ) ensemble, Geoserver n'en affiche qu'un. Le mieux serait d'avoir une image svg (ou png) du symbole que l'on peut orienter ensuite.

• Entre les deux propositions d'attributs, s'il faut récupérer une valeur on préfère qu'elle soit dans un nouvel attribut dédié ANGLE plutôt que de devoir l'extraire dans TXT et complexifier davantage les contrôles sur cet attribut. Il faudra quand même faire une vérification validateur sur ANGLE donc qu'elle soit obligatoire, quitte à mettre '0' par défaut. Mais de façon plus générale, on s'éloigne un peu du principe du catalogue de symbole où on souhaitait baser chaque symbole sur 1 attribut code SYMBOLE unique...

[GT-CNIG-DDU]

@JenniferIGN, merci de ta réponse. QGIS et Geoserver fonctionnent en mode anti-trigonométrique. J'en déduis le projet de création d'un nouvel attribut ANGLE sur la table PRESCRIPTION_PCT des PSMV : entier compris entre 0 et 359 défini comme l'angle d'un symbole ponctuel exprimé en degré par rapport à l’horizontale dans le sens anti-trigonométrique. C'est à dire le sens des aiguilles d'une montre. Valeur vide possible (et c'est le cas général), mais interdite pour PRESC 40-50. QGIS peut très bien utiliser une façon de représenter le symbole, soit ')' et deux traits dans la dernière proposition de @alhyss, et Geoserver une autre façon : un svg ou png orienté.

[alhyss]

Dans le premier jet de spécifications PSMV que je viens de publier sur la branche beta (je préfère qu'on valide tout ça à la prochaine réunion du SG5 avant d'écraser la branche par défaut du Git), je suis finalement également partie sur un SVG pour QGIS.

Le fichier est dans le répertoire PSMV/SVG. Le principal intérêt côté QGIS est qu'il est beaucoup plus facile de modifier la taille - avec une combinaison de lignes et parenthèses, il fallait recaler les éléments à chaque changement.

Visuellement, ça donne ça :

À l'échelle :

[Laetitia-aga]

En effet, je viens de mettre les codes 40-50 sur le PSMV de Strasbourg et j'ai réussi plus facilement avec le symbole SVG. J'ai créer un champs ANGLE après je ne suis pas sure de la technique que j'ai utilisé car je ne saisie pas toutes les informations que vous avez écrit avant mais je suis plutôt satisfaite du résultat :)

[alhyss]

Le symbole a l'air bien orienté sur ta capture. J'imagine que tu as configuré la rotation du symbole pour qu'elle prenne la valeur inscrite dans le champ angle ? Il n'y a rien de plus à faire.

[alhyss]

Le SG5 du 2021.09.07 valide la proposition avec SVG.