Le portail francophone de la géomatique

ChristopheV · Fri 17 June 2016 11:39

Bonjour,

La définition de la tâche urbaine par la méthode répandue des tampons donne un résultat qui n'est vraiment pas joli, je ne l'ai pas pratiquée mais les résultats sont visibles dans beaucoup de documents publics (le PADDUC Corse par exemple).

La critique étant aisée mais l'art difficile, j'ai voulu étudier une autre approche de traitement autopmatique à l'aide de postgresql/postgis (2.2).

Source de la donnée : EDIGéO DGFiP 2013, couche bâtiments (polygones), table postgis : 'batiment'

La première étape consiste à créer des polygones uniques pour un ensemble de bâtiments qui partages une arête commune.

Utilisation de st_clusterintersecting pour générer des multipolygones, puis un st_union(st_dump(geom)) sur chaque grappe créée pour obtenir un polygone unique pour chaque grappe.

Utilisation de st_clusterwithin pour générer des multi-polygones en fonction d'une distance (ici 50 m).

Puis génération de l'enveloppe uniquement pour les bâtiments qui ne sont pas isolés avec la requête suivante :

WITH p as (SELECT id,(st_dump(geom)) AS path FROM grappe_bati50),
t as (SELECT id,count(id) as nb FROM p GROUP BY id)
SELECT st_concavehull(geom,0.98)
INTO env_bati_50
FROM grappe_bati50 WHERE id IN (SELECT id FROM t WHERE nb>1)

L'ensemble du traitement pour la région prends environ 30 mm sur une base locale avec un poste de travail de type HP Z600 12 Go RAM double XEON quadcore.

Tout ceci pour souligner les apports de postgres/postgis dans leur nouvelle version et la puissance d'une approche SIG par rapport à celle logiciel SIG (je ne cite pas de marques ).

Nicolas Ribot · Fri 17 June 2016 12:14

Nice

Nico

ppluvinet · Fri 17 June 2016 12:38

Très intéressant !
Au delà de la rapidité des traitements, pourrait on avoir une comparaison visuelle des deux approches?

Bruno · Fri 17 June 2016 22:37

Salut l'artiste,

Effectivement, je rejoins Pascal, et j'attends de voir

Bruno

Sylvain M. · Mon 20 June 2016 10:02

Super intéressant !

La première partie de ton travail correspond exactement à quelque chose que je souhaite faire sur PostGis sur une thématique différentes. J'avais posé la question sur le Forum SIG à cette adresse.
Il me semble, sauf erreur, que ta méthode répond à ma question.
Pourrais-tu détailler un peu plus les requêtes que tu utilises pour cette partie de ta méthode :

La première étape consiste à créer des polygones uniques pour un ensemble de bâtiments qui partages une arête commune.
Utilisation de st_clusterintersecting pour générer des multipolygones, puis un st_union(st_dump(geom)) sur chaque grappe créée pour obtenir un polygone unique pour chaque grappe.

Si je trouve le temps, j'essaierai d'appliquer ces requêtes aux données EDIGEO de mon territoire : merci du partage !

A+

Sylvain M.

ChristopheV · Tue 21 June 2016 09:11

Bonjour,

Pour dans un premier temps répondre à Sylvain:

Code:

WITH     p as (SELECT st_collectionextract(unnest(st_clusterintersecting(st_accum(geom))),3) as geom FROM batiment),
    t as (SELECT row_number() OVER() as id, geom FROM p)
 
SELECT     id,((st_dump(geom)).geom) as geom 
INTO test2 
FROM t; 

SELECT id,st_union(st_makevalid(geom)) as geom 
INTO polybatiment
FROM test2 
GROUP BY id;

La première CTE créée les grappes des bâtiments qui se touchent (qui ont une intersection en fait). Le tableau résultat est distribué pour chaque ligne du tableau. La seconde CTE (t) permet d'attribuer un identifiant unique à chaque grappe.
On décompose ensuite la géométrie multipolygon de chaque grappe et on enregistre. Car la fonction a pu générer des polygones dont la géométrie est invalide (self-intersection).

Ensuite après avoir rendu valide la géométrie un union sur les polygones appartenant à la même grappe, d'où l'utilité de l'ID générée par row_number() over().

Ci-joint deux captures d'écran, capture2 : les bâtiments capture3 : polybatiment

Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

ChristopheV · Tue 21 June 2016 09:12

?

Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

ChristopheV · Tue 21 June 2016 09:17

Pour répondre à Bruno et Pascal:
Methode des tampons

Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

ChristopheV · Tue 21 June 2016 09:17

Enveloppe selon mon procédé

Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

ChristopheV · Tue 21 June 2016 09:18

Superposition des deux

Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

JP LLORENS · Tue 21 June 2016 09:55

Bonjour.
Très intéressant. Merci pour la méthodo et les requêtes détaillées.

JP

ChristopheV · Tue 21 June 2016 10:24

Bonjour,

Un petit enfin des petits oublis:

Une carto avec les bâtiments, c'est mieux pour voir l'enveloppe ... !
La méthode de fusion des bâtiments adjacents permet de passer d'une table de 275 361 polygones à une table de 156 970 polygones.
Deuxièmement outre le fait qu'en fonction du nombre de bâtiments dans une grappe et de la surface de la grappe on peut faire varier le traitement st_concavhull().
Que l'ensemble étant cohérent avec le reste du cadastre on peut faire une requête de type quelles sont les parcelles incluses dans l'enveloppe qui ne sont pas bâties (génération de trous), ou quelles sont les parcelles non bâties ayant une intersection sans être entièrement contenues dans l'enveloppe (amélioration du contour).

Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

CGuillaume · Tue 21 June 2016 12:21

Merci Christophe, direction les marques pages à tester

Sylvain M. · Tue 21 June 2016 14:57

ChristopheV a écrit:

Pour dans un premier temps répondre à Sylvain:

Merci beaucoup !
Bon, par contre j'ai juste un souci (certainement lié à mon apprentissage encore trop partiel de PostGis) : je ne trouve pas la fonction st_clusterintersecting() dans la liste des fonctions de ma base de données (recherche via PgAdmin).
Comment faut-il faire pour ajouter cette fonction ? (installer une extension particulière ?)

Encore merci !

Sylvain M.

ChristopheV · Tue 21 June 2016 15:14

Bonjour,

Il faut la version 2.2 de Postgis

ppluvinet · Tue 21 June 2016 16:02

Intéressant effectivement, néanmoins le résultat est bien différent, et donc la méthode dépend certainement de ce que l'on recherche. Si on a une forêt au milieu de la ville sans bâtiments, j'ai l'impression que cette forêt sera prise en compte dans un cas et pas dans l'autre.

Pour avoir des enveloppes urbaines un peu moins arrondies, j'avais testé ceci :

Code:

create table shtest.tachurb as
select 'tachbat'::text as typ, 
(st_dump(
    st_buffer(
        st_union(
            st_buffer(geom,50,'join=mitre endcap=square mitre_limit=5.0')
        ),
    -50, 'join=mitre endcap=square mitre_limit=5.0')
)).geom as geom
from shtest.bati  ;

L'option "join=mitre endcap=square mitre_limit=5.0" permet de prendre en compte la forme carré des bâtiments.

Dernière modification par ppluvinet (Mon 27 June 2016 09:34)

ChristopheV · Tue 21 June 2016 16:16

Bonjour,

Effectivement, le but étant d'obtenir automatiquement une enveloppe caractérisée (nb de bâtiments par grappe).

Comme précisé ensuite, ces enveloppes vont faire l'objet d'un travail spécifique. Pour le cas de la forêt il est simple de connaître toutes les parcelles non bâties dans une enveloppe par exemple.

Je répètes il s'agit d'un traitement automatique, l'intérêt étant d'obtenir un premier zonage et de pouvoir identifier chaque zone et le tout rapidement.

Sylvain M. · Wed 22 June 2016 12:00

Il faut la version 2.2 de Postgis

Merci beaucoup : la requête s'est donc exécutée sans problème après mise à jour de PostGis.

sigPnrmcb · Fri 24 June 2016 13:06

Bonjour à tous,
Je regarde avec intérêt vos échanges car nous sommes en train de réaliser une étude comparable sur notre territoire de parc naturel régional.
Nous utilisons aussi la méthode du CERTU (Détermination d'un MOS et calcul d'une tache urbaine à partir de la BD TOPO ® de l'IGN) en
travaillant sur des croisement BDTOP, Cadastre ...
Nous travaillons en dilation-erosion avec des buffer que que avons repréciser suite à nos testes sur un petits secteur (15 communes).

Pour les testes logiciels, nous utilisons actuellement QGis et ArcGIS (gdb)+ extensions ...
En l'état actuel, nous avons lancé et travaillons à l'échelle de deux départements avant de découper pour notre territoire ou des sous secteurs.

Ma question est assez simple, j'avais envisagé de travailler avec PostGis dès le départ mais je viens juste de m'y mettre, mes compétences sont très basiques pour l'instant. Vous allez me dire, il faut bien commencer mais le temps nous manque énormément...

Aussi, j'en appelle à la communauté, quelqu'un a peut-être déjà écrit un requête ou des bouts qui nous permettrais de tester cette méthode sous PostGIS.

Notre schéma de traitement / requête est assez simple (je pense pour un spécialiste) une fois les données importées dans la base :
On travaille en deux groupes de données sur quatre millésimes des données

Dilation - érosion
1 - squelette bâti
- Dilation 50m. avec fusion des buffers : Regroupement des couches utiles pour une dilation à 50m : BdTopo + bâti cadastre.
+ Fusion en sortie
+ ajout de champs pour faire les statistiques
- Dilation 100m avec fusion des buffers : Regroupement des couches utiles pour une dilation à 70m : Zones urbaines
+ Erosion -70 avec fusion des buffers
- regroupement de toutes les couches du squelette bâti
- Mise à jour et calcul des champs
-
2 - Squelette Infrastructures
Même procédure mais dilation selon le champs de valeur de la BDtopo avec des mise à jour par nos soins

3 - Chaque squelette devant à la fin être passé en multitosimple polygone et redécoupé par secteur voir par communes afin de créer des stats par secteurs, communes

Voilà, si jamais l'un de vous la requête en stock ou des bouts de codes, je suis très preneur.

Naturellement, nous diffuserons nos résultats et nos testes de dilation-érosion, notamment un dossier techniques sur qu'elle données utiles, quels buffers ? quelles marge d'erreurs ...

J'espère avoir été clair dans notre descriptif succinct,
Un grand merci par avance à la communauté,
Un grand débutant....
Laurent A.

ChristopheV · Mon 27 June 2016 08:56

Bonjour,

Pour les testes logiciels, nous utilisons actuellement QGis et ArcGIS (gdb)+ extensions .

une fois les données importées dans la base

Quelle base ?

Si j'ai proposé ici des requêtes et un processus détaillé c'est uniquement pour mettre en lumière l'utilisation de fonctions récentes de Postgis qui ne sont pas faciles à utiliser a priori.
Votre approche est pour moi peu claire conformément à beaucoup de processus ou documents publié par des spécialistes qui ne sont pas des spécialistes. Je m'explique ils sont spécialistes de l'urbanisme, mais en matière de base de données, d'algorithmes, de normalisation informatique ... En plus leur spécialité c'est d'utiliser des acronymes et autre mots "qui font bien", comme disait Coluche c'est le genre de type à qui tu poses une question et tu ne comprends plus la question posée quand il t'a répondu.

Il faudrait déjà se mettre d'accord sur la définition de la tâche urbaine, le CERTU dans son document
http://www.territoires-ville.cerema.fr/ … 7e63d5.pdf
reconnait que la chose est floue. (entre parenthèses il y a des grosses bêtises sur les données cadastrales dans ce document).
Ensuite je n'arrive pas à concevoir que ces services publics fassent la promotion de solution logicielles propriétaires, c'est plus facile d'augmenter les impôts que de réduire les coûts ?
Et enfin comme je le disais dans mes précédents messages il faut différencier l'approche logiciel SIG de l'approche SIG. Un système d'information repose sur trois composantes, l'architecture physique (un véritable SI c'est pas sur un portable), l'architecture logique (moteur de BD, architecture relationnelle des données), et enfin l'architecture logicielle qui est l'interface entre l'homme et le système.
Vous parlez de QGis et d'Arcview, très bien mais ce ne sont que des moyens pour visualiser les données, certainement pas un moyen efficace de les interroger.
Cette problématique est générale, et lorsque l'on lit les document cité en lien, il est clair que l'approche architecture logique est complétement ignorée.

Lucie D. · Fri 03 March 2017 08:49

Bonjour,

Comme je le disais à ChristopheV dans un autre sujet, je fais des tests sur cette autre approche de la tache urbaine.
J'ai fait le test sur un département tout entier, mais il me sort une grosse tache sur l'ensemble de mon département...(voir pièce jointe).

J'ai effectué un st_concavhull(st_union(geom),0.98) mais peut-être n'aurais-je pas dû lancer le st_union??? J'aimerais avoir plusieurs tâches de ce type mais plus petites pour identifier les zones plus urbaines...? =p

Merci beaucoup!

Bonne journée.

Bien cordialement,

Lucie D.

Dernière modification par Lucie D. (Fri 03 March 2017 08:50)

Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

ChristopheV · Tue 14 March 2017 09:48

Bonjour,

Il y a tous les éléments plus haut pour comprendre ...

Regardez bien à quoi sert la clause GROUP BY ...

CRIGBAB · Wed 29 March 2017 23:14

Bonsoir à tous,

Sujet vraiment passionnant. Même si je n'ai pas testé je vois le résultat et m'interroge sur les fonctions dont la ''st_clusterintersecting'' car à la vue du extrait capture6.png j'ai du mal à voir une cohérence dans la construction de ''l'enveloppe'' qui laisse des ''failles'' sur certaines zones et bouche des trous énormes dans d'autres.
L'ordre d'enregistrement des entités a-t-elle une influence?
Tout cela mérite une analyse plus approfondie pour comprendre un tant soit peu le processus mathématique de calcul.

Je m'intéresse au sujet car dans le cadre de la révision du PLUI nous cherchons a ''créer'' les zones agglomérées avec un minimum de cohérence. Si nous nous arrêtons à sa définition dans le cadre de la loi littorale c'est simple, à priori méthode du tampon. Mais vos travaux peuvent nous amener à avoir une approche un peu différente.

Mes questions sont simples et sûment aussi à poser sur une autre partie du forum.
Avez-vous eu à traiter dans le cadre de documents réglementaires, PLU et SCOT entre autres, ce genre de problématique et si oui quelle méthode avez-vous mis en oeuvre? Quel argumentaire technique a accompagné sa mise en oeuvre?

Merci par avance de vos réponses

A suivre donc, même si le manque de temps ne me permettra probablement d'analyser les méthodes. J'espère que ma collègue en charge du PLUI pourra le faire un peu.

ChristopheV · Thu 30 March 2017 11:17

Bonjour,

Comme indiqué plus haut il s'agit avant tout d'illustrer l'utilisation de fonctions postgis 2.2.

Nous avons mis cet exemple à disposition, mais bien entendu il s'agit d'une approche "brute". Nous n'allons pas publier tous nos "petits secrets"

C'est effectivement l'algo de st_concavhull qu'il faut examiner. Et je précise encore que ce n'est qu'une première approche qui doit être "raffinée" (au sens chimique du terme) et couplée à d'autres.

Jkerebel04 · Thu 23 March 2023 17:36

Bonjour
J'ai lu avec intérêt les discutions sur le sujet car je cherche à faire la même chose, mais pour des polylignes.
J'ai tenté d'utiliser le script de ChristopheV, mais j'ai le message suivant :

ERREUR : ERREUR: la fonction st_accum(geometry) n'existe pas

J'ai cherché la fonction St_Accum et je ne l'ai pas trouvé

j'ai la version 3.1 de Postgis,
Pourriez-vous m'indiquer ou est cette fonction et comment la charger et la rendre active SVP ?

Merci par avance de vos réponses

tumasgiu · Thu 23 March 2023 17:46

Bonjour,

la fonction st_accum a été supprimée de postgis à partir de la version 3, vous pouvez la remplacer par array_agg.

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Sites amis	Agenda Biblio Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

Annonce

#1 Fri 17 June 2016 11:39

Taches urbaines une autre approche

#2 Fri 17 June 2016 12:14

Re: Taches urbaines une autre approche

#3 Fri 17 June 2016 12:38

Re: Taches urbaines une autre approche

#4 Fri 17 June 2016 22:37

Re: Taches urbaines une autre approche

#5 Mon 20 June 2016 10:02

Re: Taches urbaines une autre approche

#6 Tue 21 June 2016 09:11

Re: Taches urbaines une autre approche

Code:

#7 Tue 21 June 2016 09:12

Re: Taches urbaines une autre approche

#8 Tue 21 June 2016 09:17

Re: Taches urbaines une autre approche

#9 Tue 21 June 2016 09:17

Re: Taches urbaines une autre approche

#10 Tue 21 June 2016 09:18

Re: Taches urbaines une autre approche

#11 Tue 21 June 2016 09:55

Re: Taches urbaines une autre approche

#12 Tue 21 June 2016 10:24

Re: Taches urbaines une autre approche

#13 Tue 21 June 2016 12:21

Re: Taches urbaines une autre approche

#14 Tue 21 June 2016 14:57

Re: Taches urbaines une autre approche

#15 Tue 21 June 2016 15:14

Re: Taches urbaines une autre approche

#16 Tue 21 June 2016 16:02

Re: Taches urbaines une autre approche

Code:

#17 Tue 21 June 2016 16:16

Re: Taches urbaines une autre approche

#18 Wed 22 June 2016 12:00

Re: Taches urbaines une autre approche

#19 Fri 24 June 2016 13:06

Re: Taches urbaines une autre approche

#20 Mon 27 June 2016 08:56

Re: Taches urbaines une autre approche

#21 Fri 03 March 2017 08:49

Re: Taches urbaines une autre approche

#22 Tue 14 March 2017 09:48

Re: Taches urbaines une autre approche

#23 Wed 29 March 2017 23:14

Re: Taches urbaines une autre approche

#24 Thu 30 March 2017 11:17

Re: Taches urbaines une autre approche

#25 Thu 23 March 2023 17:36

Re: Taches urbaines une autre approche

#26 Thu 23 March 2023 17:46

Re: Taches urbaines une autre approche

Pied de page des forums