SmartPLU/Numen - Proposer un format XML pour l'instanciation des règles d'urbanisme

[mborne]

Objectif :

• Permettre la conservation du texte source de la règle
• Gagner en souplesse par rapport aux CSV (en particulier en cas de non remplissage)

Remarque :

• Les données SmartPLU/numen ont vocation à être en opendata. Le CSV initialement traité et converti en XML en guise d'exemple dans ce dépôt
• Faire du XML simple (laisser ouverte la porte pour alternative JSON)

[mbrasebin]

Hello,

cool de voir qu'il y a du neuf. Ca sera du XML à plat ou du plus évolué ? Les règles sont les mêmes que celles qu'on a traitées ou il y en a de nouvelles ? Dispo pour échanger si tu as besoin d'un coup de main.

En tout cas, la version 2010 (https://github.com/SimPLU3D/3DBuildableHull) du simulateur de règles avait déjà prévues que le XML serait l'avenir.

++

Mickaël

[mborne]

Salut!

Bien ça risque de ressembler à ce genre de schéma : https://github.com/SimPLU3D/3DBuildableHull/blob/master/src/main/resources/fr/ign/cogit/gtru/schema/reglesUrba.xsd

L'idée que j'ai en tête est :

• Faire une page "docs" sur plu-formel
• Propriété de la règle

Nom	Type	Description
id	URL	URL pointant sur la fiche descriptive de la règle (ex : https://github.io/plu-formel/registry/IAUIDF-001.html)
document	URL	URL identifiant le document d'urbanisme (ex : https://www.geoportail-urbanisme.gouv.fr/document/by-id/6f92c5dac436cc99c862b50ac0c429cb )
zone	̀string	Libelle de la zone d'urbanisme (équivalent à ZONE_URBA.LIBELLE dans le standard CNIG)
citation	string	Extrait du texte du document d'urbanisme fournissant les valeurs de params (produit par SmartPLU)
params	RuleParam[]	Valeur des paramètres

[mborne]

Après, rien de figé... Il faut à mon avis :

• Expérimenter par rapport aux règles livrées en CSV
• Sûrement reprendre les fiches du registre pour être en mesure de les dériver en schéma XSD et JSON afin de spécifier les paramètres

Je te demanderai validation en plus de numen si tu as un peu de temps pour échanger

++

[mborne]

Salut @mbrasebin !

Je serais preneur d'un coup d'oeil là dessus si tu as un peu de temps : https://mborne.github.io/plu-formel/

En bref :

• La page principale a été épurée
• Passage en github pages pour illustrer le principe des fiches ( https://mborne.github.io/plu-formel/registry/IAUIDF-001 ) et sous peu la négociation de contenu pour les schémas
• Ajout d'exemple de ce que ça pourrait donner en XML et JSON
• Passage au second plan du CSV

Reste à faire (court terme) :

• Discuter le modèle avec numem
• Produire les schémas
• Valider avec équipe de recherche et migrer "https://mborne.github.io/plu-formel/" en "https://simplu3d.github.io/plu-formel/"

Long terme :

• Trouver un domaine stable du type "plu-formel.ign.fr" (voire un nom meilleur que "plu-formel" pour le registre de règle)
• Remplacer tout "https://mborne.github.io/plu-formel/" en "https://plu-formel.ign.fr/" une fois le domaine créé/hébergé

[mbrasebin]

Hello, si je regarde ça la semaine prochaine ce n'est pas trop tard ? ++ Mickaël Le ven. 12 juil. 2019 à 19:22, MBorne <notifications@github.com> a écrit :

…

Salut @mbrasebin <https://github.com/mbrasebin> ! Je serais preneur d'un coup d'oeil là dessus si tu as un peu de temps : https://mborne.github.io/plu-formel/ En bref : - La page principale a été épurée - Passage en github pages pour illustrer le principe des fiches ( https://mborne.github.io/plu-formel/registry/IAUIDF-001 ) et sous peu la négociation de contenu pour les schémas - Ajout d'exemple de ce que ça pourrait donner en XML et JSON - Passage au second plan du CSV — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=ACT4M4GVF7QLS3CN5B3X773P7C4V3A5CNFSM4H55Z272YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ2LVOI#issuecomment-510966457>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACT4M4GRDL6CCCVBX5NDCCDP7C4V3ANCNFSM4H55Z27Q> .

[mbrasebin]

Quelques retours sur la modélisation 👍

• Je ne suis pas sûr de comprendre : la forme {AuteurDuModeleDePhrase}-{NumeroDeLaPhrase} et notamment AuteurDuModeleDePhrase. L'idée à terme serait d'avoir des structures confirmées qui communiqueraient des modèles de règles ?

• En regardant le concept de registre, je me suis demandé à quel niveau devait être définis les éléments géographiques nécessaires à l'application des règles. Je pense par exemple à la notion de limite séparative latérale qui se détermine différemment en fonction du PLU. Il me semble que les registres définissent une règles avec des concepts abstraits. Mais pour les développeurs d'applications qui utiliseront ce format, comment seront ils sûrs de bien exploiter ces contraintes ?

• Je me suis demandé si pour être un peu plus léger, il ne serait pas envisageable d'avoir un petit système d'héritage (mais ça complique l'exploitation) du genre :

 <zone code="U">
     <!-- 1 bande de constructibilité de 6m -->
             <rule id="IAUIDF-000">
                 <param name="B1_T_BANDE">1</param>
                 <param name="B1_BANDE">6.0</param>
                 <citation>
                 ... extrait de texte définissant la contrainte...
                 </citation>
             </rule>
 
            <!-- IAUIDF-007 - Hauteur maximale des constructions -->
             <rule id="IAUIDF-001">
                 <params>
                     <param name="B1_ART_6">6.0</param>
                 </params>
             </rule>
 </zone> 
 
 <zone code="U1">
     <!-- 1 bande de constructibilité de 6m -->
             <rule id="IAUIDF-000">
                 <param name="B1_T_BANDE">1</param>
                 <param name="B1_BANDE">7.0</param>
                 <citation>
                 ... extrait de texte définissant la contrainte...
                 </citation>
             </rule>
 </zone>

Avec les règles définies dans U et non définies dans U1 qui s'appliqueraient

[mborne]

Comme indiqué par mail :

• {AuteurDuModeleDePhrase}-{NumeroDeLaPhrase} : L'idée est de donner la liberté aux différents rédacteurs de PLU pour proposer leurs formulations/fiches, puis de faire des recherches d'équivalence pour interprétation par SimPLU3D & autres, sachant que dans les faits, c'est ce qui s'est passé avec IAUIDF et Rennes

• Rien n'empêcherait d'avoir un registre de définition exploité par le registre de règle. L'originalité de ce dernier est d'avoir des définitions associés à des définitions de paramètre. Les paramètres du type "mode de calcul de la hauteur", "unité", etc. pourrait très bien être définie dans un registre de définition.

(voir registre de définition des concepts INSPIRE : http://inspire.ec.europa.eu/featureconcept )

• Je demande à l'équipe SmartPLU comment il voit la chose. Peut-être se réserver pour plus tard un héritage explicite du type suivant?

<zone code="U1" extends="U">
<!-- les règles U1 s'applique en plus de celles qui suivent -->
</zone>

(éviterait de faire des calculs sur chaîne de caractères ou connaissance pour savoir qui hérite de quoi)

[mborne]

On progresse : https://mborne.github.io/plu-formel/#format-xml

Il reste à :

• Ajouter des xs:annotation et xs:documentation au niveau du schéma
• Statuer sur le caractère implicite ou non de la notion d'héritage