{"id":15126,"date":"2024-12-03T06:56:00","date_gmt":"2024-12-03T05:56:00","guid":{"rendered":"https:\/\/www.opengis.ch\/?p=15126"},"modified":"2024-12-03T09:39:41","modified_gmt":"2024-12-03T08:39:41","slug":"des-lieux-pollues-en-geopackage","status":"publish","type":"post","link":"https:\/\/www.opengis.ch\/fr\/2024\/12\/03\/des-lieux-pollues-en-geopackage\/","title":{"rendered":"Des lieux pollu\u00e9s en GeoPackage"},"content":{"rendered":"\n

Impl\u00e9menter et modifier le mod\u00e8le f\u00e9d\u00e9ral INTERLIS du cadastre des sites pollu\u00e9s KbS_V1_5<\/code> sans probl\u00e8me dans un GeoPackage ? Un r\u00eave lointain pendant longtemps, mais d\u00e9sormais r\u00e9alit\u00e9. Avec Model Baker 7.10 et ili2db 5.2, vous pouvez maintenant travailler confortablement avec vos ensembles de donn\u00e9es INTERLIS contenant plusieurs colonnes de g\u00e9om\u00e9trie par classe dans un GeoPackage.<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Un point de douleur qui existe depuis des ann\u00e9es dans le traitement de mod\u00e8les comme celui du cadastre des sites pollu\u00e9s ou de la planification de l’utilisation, c’est que les mod\u00e8les contiennent des classes avec plusieurs g\u00e9om\u00e9tries<\/strong>. Par exemple, ici, une g\u00e9om\u00e9trie de type point et une g\u00e9om\u00e9trie de type polygone.<\/p>\n\n\n\n

CLASS Belasteter_Standort =\n    Katasternummer : MANDATORY TEXT;\n    URL_Standort : MultilingualUri;\n    Geo_Lage_Polygon : MultiPolygon;\n    Geo_Lage_Punkt : GeometryCHLV95_V1.Coord2;\n    [...]\nEND Belasteter_Standort;\n<\/code><\/pre>\n\n\n\n
Lors de l’impl\u00e9mentation de cette classe dans une base de donn\u00e9es relationnelle, des limites sont apparues. Tandis que PostgreSQL n’a pas de probl\u00e8me \u00e0 cr\u00e9er des tables avec plusieurs g\u00e9om\u00e9tries, le GeoPackage rencontrait une difficult\u00e9.<\/p>\n\n\n\n
Le GeoPackage ne pouvait pas g\u00e9rer plusieurs colonnes de g\u00e9om\u00e9trie dans la m\u00eame table et, par cons\u00e9quent, ne pouvait pas visualiser ces g\u00e9om\u00e9tries comme deux couches distinctes dans QGIS avec la m\u00eame source.<\/p>\n\n\n\n
Reformuler le mod\u00e8le n’est pas une option<\/h2>\n\n\n\n
On pourrait penser qu’il suffisait de reformuler le mod\u00e8le pour que cela fonctionne.<\/p>\n\n\n\n
CLASS Belasteter_Standort (ABSTRACT) =\n    Katasternummer : MANDATORY TEXT;\n    URL_Standort : MultilingualUri;\n    [...]\nEND Belasteter_Standort;\n\nCLASS Belasteter_Standort_Punkt EXTENDS Belasteter_Standort =\n    Geo_Lage_Punkt : GeometryCHLV95_V1.Coord2;\nEND Belasteter_Standort;\n\nCLASS Belasteter_Standort_Polygon EXTENDS Belasteter_Standort =\n    Geo_Lage_Polygon : MultiPolygon;\n    [...]\nEND Belasteter_Standort;\n<\/code><\/pre>\n\n\n\n
Mais cette variante – bien que s\u00e9duisante pour les mod\u00e9listes INTERLIS (\u00e9quivalents des Swifties) – est moins lisible que la premi\u00e8re version. Et un mod\u00e8le doit, apr\u00e8s tout, aussi \u00eatre un document conceptuel compr\u00e9hensible pour les professionnels du domaine, afin de comprendre la structure des donn\u00e9es.<\/p>\n\n\n\n
De plus, un d\u00e9veloppeur d’outils m’a dit une fois que, lorsqu’il mod\u00e9lise, il se concentre uniquement sur la mod\u00e9lisation sans se soucier de la capacit\u00e9 des outils \u00e0 la g\u00e9rer. Sinon, le d\u00e9veloppement d’outils s’arr\u00eate. Ce qui est \u00e9galement vrai.<\/p>\n\n\n\n
Cependant, l’impossibilit\u00e9 de mettre en place un mod\u00e8le tel que celui du cadastre des sites pollu\u00e9s dans un GeoPackage constituait une contrainte extr\u00eamement difficile. De plus, les mod\u00e8les f\u00e9d\u00e9raux sont fix\u00e9s et on ne peut pas simplement les modifier \u00e0 sa guise.<\/p>\n\n\n\n
C’est pourquoi les outils arrivent<\/h2>\n\n\n\n
Le besoin \u00e9tait donc dans les outils, et pour pouvoir modifier une table du GeoPackage avec des g\u00e9om\u00e9tries multiples dans QGIS, l’ensemble de la cha\u00eene \u00e9tait impliqu\u00e9 :<\/p>\n\n\n\n