Le portail francophone de la géomatique

Bonjour,
Bravo en tout premier lieu.

Notre bureau d'études a développé un outil similaire. Lui aussi basé sur la technologie PostgreSQL-Postgis.
L'ensemble est de fait des requêtes SQL.

Les ouvrages linéaires sont intégrés, y compris dans la problématique de linéaire de voies limitrophe d'une parcelle bâtie.

Nous nous basons sur la couche bâtiments cadastre et la complétons avec les données disponibles (ortho, drone etc ..) ces données sont recalées sur le cadastre pour prendre en compte les notions foncières relatives aux OLD. Nous prenons en compte les piscines, les parkings enfin toutes les installations soumises aux OLD hors réglementation spéciale.

Nous intégrons les données PLU du géoportail de l'urbanisme. Pour les communes au RNU nous définissons les zones urbaines en fonction du calcul de densité de bâtiments défini par les SDIS.

Nous prenons en compte les éventuels arrêtés municipaux modifiant le zonage (100m par exemple) OLD.

Nous intégrons nous aussi les superpositions dans le cadre légal (règle de l'équidistance).
Les données relatives aux propriétaires sont réservées à l'usage du maire et des personnels municipaux dans le cadre du strict respect du RGPD.

Les campings et/ou parc photovoltaïques sont traités dans des études à part, la réglementation étant spécifique pour ces installations.

Nous allons un peu plus loin que les OLD, car nous sommes en mesure d'analyser la défendabilité au regard de l'incendie (famille d'habitat, densité, largeur de voie imposée, ERP et PEI), et aussi l'analyse des aléas induits.

Sur l'aspect traitement informatique nos temps de calculs, comme pour vous, varient de quelques minutes à 2 ou trois heures.

Utilisateur Postgis : Nous ne rencontrons pas de problèmes d'artefacts, c'est effectivement pas un truc évident à résoudre, cette absence de soucis est due à notre méthode d'intégration de données et de calcul, dont je ne peux dévoiler les petits secrets ici (et pas de snaptogrid ).
Je peux vous en donner 1, utilisez l'intégrateur de données EDIGéO que j'ai mis en ligne :
https://georezo.net/forum/viewtopic.php … eur+edigeo

Il intègre le cadastre en respectant sa précision d'origine qui est le cm.
Si vous utilisez le plan cadastral retravaillé (JSON et autre) vous aurez forcément ce genre de problèmes. Il y a eu dans les années précédentes des discussions sur GeoRezo à ce sujet. (où l'on m'a poliment expliqué que c'était pas important ...)

Pour résumé félicitations ! Car ce n'est pas un sujet évident à traiter et le code SQL pour y arriver n'est pas trivial, mes félicitations à celui (ceux, celle, celles ) qui l'ont conçu.

Bonjour,

Pour les experts des OLD!
https://www.crige-paca.org/events/journ … esentation

Bonne journée.

Bonjour,
Merci @bruno pour ces informations. (particulièrement la dernière).

Pour avoir participé à la première réunion du GT CRIGE PACA et avoir participé à d'autres projets en matière de données, je constate régulièrement de nombreuses lacunes en matière de modélisation. C'est un véritable métier qui ne s'invente pas.
Ces lacunes proviennent à mon sens d'un mélange de genres.
Le métier "opérationnel" (ici les spécialistes de la sécurité incendie et des feux de forêts), le métier de codeur, et celui qui fait le lien entre les deux la modélisation.
A ceci s'ajoute une vision en antagonisme avec la modélisation : analyser la problématique sous l'angle réduit du métier en ne considérant que ses besoins immédiats, ou plus familièrement voir le problème par le petit bout de la lorgnette.
Ajoutons à tout cela que la modélisation nécessite une compréhension générale des principes informatiques de bas niveau et des principes objets.

Le fonctionnement "en silos" se traduit malheureusement dans les modèles proposés, l'absence de réelle culture informatique de même.