Récupération des géométries des membres d'une relation

[Vincent]

Hello,

Jusqu'à présent dans mes scripts d'imports (pour les hauteurs de bâtiments) je ne gérais que les relations avec un seul membre "outer" mais j'aimerais maintenant gérer aussi ceux qui en ont plusieurs même s'ils sont rares (par ex. sur l'ensemble de Nice il y en a même pas une dizaine).

Le problème est que je n'arrive pas vraiment à récupérer dans PostGIS les géométries pour chacun des membres "outer".

Bizarrement la doc détaillée d'Osm2pgsql a disparu du wiki mais je l'ai retrouvé dans l'historique: http://wiki.openstreetmap.org/w/index.p ... id=1418568

Voici la partie intéressante:

Code : Tout sélectionner

This table contains all polygons (closed ways) which were imported. For polygons which are members in one or more relations, multiple rows will be created: one with the polygon's own ID and tags, and one more for each relation membership. These additional rows contain the tags of the relation and the negative ID of the relation in the osm_id column (since a single relation may contain multiple polygons, negative IDs are not necessarily unique).

De ce que je comprend Osm2pgsql va stocker dans la table osm_polygon plusieurs lignes pour chaque membre "outer" (mais pas pour les membres "inner" à mon avis):
- une ligne avec l'ID inversé (négatif) de la relation + la géométrie du membre + les tags de la relations
- une ligne avec l'ID du du membre outer + la géométrie du membre + les tags spécifiques du membre

Sauf que la 2e ligne ne sera visiblement présente QUE si le membre possède des attributs propre à lui (et non à la relation), ce qui veut dire que dans l'écrasante majorité des cas il n'y aura que la 1ere ligne ! Et du coup je ne vois pas comment je peux différencier les lignes des différents membres "outer" d'une même relation puisqu'ils auront tous le même ID (c'est à dire celui de la relation mais inversé).

Merci pour votre aide, Vincent.

[cquest]

osm2pgsql fait tout un traitement pour les multipolygon, essentiellement pour choisir quels sont les tags à lui appliquer au final car on a encore beaucoup de tags sur les outer (alors qu'ils devraient être sur la relation).

Son fonctionnement a évolué plusieurs fois à ce qu'il me semble.

Tu utilises osm2pgsql ou bien tu veux juste voir comment il fait ?

Autre chose, il y a une option pour osm2pgsql pour soit garder un multipolygone (sans trou) comme un objet unique ou pour le séparer en N polygons. J'utilise toujours la première option qui permet par exemple sur un rendu de n'avoir le nom qu'une fois, sinon pour chaque polygone il sera répété au rendu. Si besoin je peux le reséparer alors que l'inverse est moins simple.

[Vincent]

Oui j'utilise vraiment osm2psql pour mes scripts d'imports, c'est donc pas une question théorique mais bien réelle !

Tu te rappelles pas du nom de l'option dont tu as parlé ? Ceci dit je suis pas sûr qu'elle me soit très utile dans mon cas..

Ce que je voudrais c'est connaitre l'ensemble des membres "outer" d'une relation avec leur vrai ID et leur propre géométrie.

L'idée étant de pouvoir calculer une hauteur différente pour chacun des sous bâtiment des relations, et pour ça il me faut leur ID et leur géométrie pour chacun d'entre eux.

Clairement je pensais pas que ça serait aussi compliqué d'obtenir ces infos là dans le schéma d'osm2pgsql...

[cquest]

Ce schéma est fait pour le rendu, pas pour explorer les données OSM en profondeur.

La table planet_osm_rels contient les relations avec leurs tags et leurs membres.

Exemple avec un bâtiment à trou (1 outer + 1 inner):

Code : Tout sélectionner

   id    | way_off | rel_off |         parts         |               members               |               tags               | pending 
---------+---------+---------+-----------------------+-------------------------------------+----------------------------------+---------
 2014180 |       0 |       2 | {149390442,149389562} | {w149390442,inner,w149389562,outer} | {building,yes,type,multipolygon} | 

members contient les type+id des membres et leur rôle... le stockage en tableau ne facilite pas les traitements mais on y arrive quand même en jonglant un peu.

Il peut éventuellement être plus simple de récupérer la liste des bâtiments provenant de relations dans osm2pgsql (osm_id négatif), puis de faire une requête overpass pour obtenir les détails en XML ou json sur ces bâtments là uniquement.

[Vincent]

Oui je crois que je suis un peu obligé de faire des requêtes "externes" (ie. pas juste dans ma base PostGIS) pour récupérer les IDs et géométries des membres d'une relation.

C'est assez frustrant car si Osm2pgsql stockait le vrai ID du membre dans osm_polygon (éventuellement dans une colonne séparée) il y aurait pas besoin de le faire ! Mais malheureusement c'est pas le cas, enfin sauf si le membre possède des tags spécifiques (c'est à dire quasiment jamais), auquel cas il va bien créer, en plus de la la ligne pour la relation, une nouvelle ligne dans osm_polygon avec le vrai ID.

Sinon pour récupérer la géométrie des membres, le plus simple est de passer par l'API standard ou par Overpass API ?

Avec l'API standard ça me parait assez compliqué: je devrais faire un 1er appel pour récupérer en XML les références des nodes pour ensuite aller refaire N requêtes (si le membre a N nodes ) pour récupérer les coordonnées de l'ensemble des nodes, pour ensuite pouvoir reconstruire une géométrie dans le format WKT.

J'ai pas l'habitude d'utiliser Overpass API mais serait ce vraiment plus pratique ? Je viens de voir qu'il y avait les notions d'area et de pivot mais j'ai pas l'impression de pouvoir récupérer facilement les géométries (ou tout du moins pouvoir reconstruire une géométrie en WKT).

[Vincent]

Du coup je me demande si ça vaut la peine... car je rappelle tout ça est juste pour pouvoir gérer les relations qui ont PLUSIEURS membres "outer" (cas extrêmement rares, moins de 10 sur l'ensemble de Nice par ex).

S'il y a qu'un seul membre "outer" il n'y pas de probleme puisque la ligne dans osm_polygon (avec l'ID négatif de la relation) sera forcément celle du membre ! J'aurais donc sa géométrie, et aussi son vrai ID (en utilisant la table osm_rels).

[Vincent]

Du coup je me demande si ça vaut la peine... car je rappelle tout ça est juste pour pouvoir gérer les relations qui ont PLUSIEURS membres "outer" (cas extrêmement rares, moins de 10 sur l'ensemble de Nice par ex).

En fait il y a exactement 21 relations de bâtiments sur Nice possédant plusieurs membres "outer". Mais bon ça reste négligeable par rapport aux 100 000 buildings de la commune donc pour l'instant je laisse tomber...