Adressages et batiments dans les zones d'activités

Je procède en ce moment à des tests d’enrichissement de la BD OSM dans le cadre particulier des ZA.

Nous avons un projet qui nécessitera d’améliorer de manière conséquente notre connaissance de la position de chaque bâtiments et de leurs adresse dans certaines Zone d’Activités.
Je teste donc la possibilité d’utiliser OSM afin de bénéficier du travail déjà constitué par la communauté et de reverser en contrepartie le travail d’adressage assez laborieux que nous devrons effectuer.

Pour l’instant cela semble bien partit, néanmoins vous trouverez ci-dessous trois points qui me posent encore problème, ainsi que le protocole que je propose d’appliquer.
Je souhaiterai savoir vos avis avant de modifier un peu radicalement le zones sur lesquelles je ferais des éditions.

Et pour info je travaille avec JOSM.

  • 1 Problème des bâtiments découpés
    Des bâtiments apparaissent découpés soit par une limite cadastrale, soit car il s’agit d’extensions séparées par une fine rayure blanche sur le cadastre.
    C’est très embêtant pour mon utilisation finale, car je souhaiterais récupérer l’ensemble des bâtiments avec adresse via l’API Overpass (déjà testé et concluant)
    Si j’ai bien compris dans une zone peu cartographiée comme les ZA ces découpages sont dans la plupart des cas des artefacts liés à la digitalisation du cadastre.
    Dans des cas plus rares ils correspondent réellement à des détails architecturaux (surtout dans le cas des extensions)
    Solution envisagée : fusionner tous les contour qui correspondent à un bâtiment de même adresse
  • 2 Problème des bâtiments multi-polygones
    J’ai vu qu’on peu créer une relation entre plusieurs polygones pour les bâtiments comportant des annexes, ce qui sera un cas de figure récurrent dans les ZA.
    Mais dans ce cas comment se passe l’adressage?
    Puis-je placer le tag « addr:housnumber » sur un seul polygone de la relation… qui n’auras du coup pas de parent associatedStreet, puisque c’est la relation multipolygon qui portera ce lien.
    Ou alors dois-je place le tag addr sur la relation multipolygon… mais dans ce cas à quel endroit l’adresse apparaitra-t-elle dans les moteur d’étiquetage et/ou d’export comme Overpass.
    Faut-il ajouter un tag « Site » ou similaire?
    Solution envisagée : heu…
  • 3 Contradiction entre adresse d’usage et cadastre
    Sur deux zone test j’ai déjà au moins deux cas ou l’adresse publiquement communiquée par l’occupant du bâtiment diffère de celle affiché sur le plan du cadastre…
    Ais-je l’autorisation de renseigner l’adresse d’usage plutôt que celle du cadastre.
    Solution envisagée : utiliser l’adresse d’usage
  • 4 La question con
    Quand j’ai fini mon adressage avec numéro et associatedStreet, faut-il que je renseigne en batch ville, adresse et code postal de chaque point d’adresse…
    …ou bien est-ce une redondance inutile vue que nominatim s’en sort déjà très bien sur ma zone test.
    Solution envisagée : ne pas renseigner ces tags vu que nominatim s’en sort

Protocole envisagé pour les ZA que je traiterais
Assigner un nom et le tag « area=yes » au périmètre de la ZA qui sera de type « landuse=* ».
Créer les relations associatedStreet pour toutes les rues de la ZA.
Tagger les adresses connues.
Fusionner les parties de bâtiments découpées (et créer des multi-polygones quand la relation fonctionnelle est avérée?)
Assigner les bâtiments sans adresses aux bonnes « associatedStreet ».
Boire un café quand c’est fini.

Ça vous parait cohérent? j’attends vos remarques et vos réponse pour le point 2 en particulier.
Merci !

  1. fusion ou pas ?
    Si il s’agit d’artefact dû aux parcelles du cadastre, on peut fusionner.
    Si il s’agit de parties différentes (toit différent, différente hauteur, en gros des bâtiments mitoyens)… on ne devrait pas fusionner ou alors conserver ces particularités avec building:part=*

  2. multi-polygones
    Tu semble vouloir placer l’adresse sur le polygone du bâtiment.
    Je préfère indiquer l’emplacement de la plaque adresse (donc souvent l’entrée ou la boite aux lettres).
    Ca permet d’avoir plusieurs adresses sur un même bâtiment, ce qui est courant sur des immeubles d’habitation, moins sûrement dans des ZA/ZI.

‘site’ sert à autre chose, c’est à dire à regroupe des objets éloignés qui forment un tout, par exemple une université répartie sur plusieurs lieux distincts qu’on ne peut pas englober dans un polygone. Revoir le wiki.

Donc pour moi la solution c’est l’adresse sur des node. Oui, je sais, ça ne simplifie pas la réutilisation que tu veux en faire. Il faudrait mapper les parcelles cadastrales correspondant à une même adresse pour gérer tout ça au mieux, mais jusqu’à maintenant on n’est pas rentré dans ce niveau de détail.

  1. contradiction cadastre/usage
    grosse contradiction ? c’est quoi la différence entre les deux dans les cas en question ?

  2. question con
    Non, pas besoin de renseigner tout ça, on le détermine par les géométries du découpage administratif.
    Par contre, sache que nominatim gère pour l’instant très mal les codes postaux :frowning:

Protocole…
area=yes est inutile sur des landuse=* qui ne s’applique QUE sur des surfaces, jamais sur du ponctuel.
Tu peux prendre un café avant que ça soit terminé :wink:

Tout à fait d’accord avec les propositions de Christian.
Pour en discuter de manière plus détaillée, il existe aussi une liste locale : http://listes.openstreetmap.fr/wws/info/local-alsace
Par ailleurs, tu peux compiler ton expérience sur une page dans le wiki pour capitaliser les bonnes pratiques.
J’essaierei de suivre l’avancée de ton projet.

Denis

Merci pour vos réponses si rapides!

1) fusion ou pas ?
Ok, merci d’avoir pointé le tag building:part=* qui répond parfaitement a mes besoins quand j’observe un décrochement notable dans la toiture.
Par contre en l’état je ne pourrais pas détailler les caractéristiques précise de chacune de ces parties.

2) multi-polygones
J’avais envisagé de rattacher les adresses aux noeuds et en terme de réutilisation ça ne me posera pas d’énormes problème, et ça résout effectivement les cas ou deux entrées existent.
Par contre ça me pose deux nouveaux problèmes (je suis chiant hein :stuck_out_tongue: )

  • 2a) Cela va me conduire à placer des point adresse arbitrairement car certain batiments ont une forme complexe et l’entrée n’est pas forcément identifable facilement. Quoi qu’avec Bing on devrais repérer le perron dans la majorité des cas.

2b) Pour mes réutilisations il faudrait à un moment que je récupère tous les bâtiments de la zone. L’idée que j’avais est de collecter ces éléments via Overpass API en cherchant tous les bâtiments associé à une rue de la ZA.
Mais si l’adresse est sur un point cette méthode ne fonctionnera pas. Mais bon ce point là j’y reviendrais plus tard, car cela rejoint ta remarque sur le tag landuse.

3) contradiction cadastre/usage
J’ai une entreprise qui communique sur tous ses supports une adresse au numéro 3 rue bidule, alors que sur le cadastre son bâtiment bien reconnaissable est signalé au numéro 6 rue bidule…
Je suppose qu’en pratique personne ne regarde jamais le numéro de rue vu la taille du panneau et du batiment, mais pour réutiliser le plan il faut bien que je fasse un choix dans un sens ou l’autre.
Dans la pratique, un utilisateur lambda cherchera l’adresse d’usage (n°3) mais dans ce cas nominatim ne renverrai rien si j’affecte le numéro du plan cadastral. C’est pourquoi je pense initialement affecter l’adresse d’usage.

Protocole…

area=yes est inutile sur des landuse=* qui ne s’applique QUE sur des surfaces, jamais sur du ponctuel.

J’ai du mal m’exprimer, pour le coup je parlais du polygone général qui constitue le périmètre de la ZA.
Il me semblait de prime abord qu’ajouter area=yes serait nécessaire pour récupérer les objets à l’intérieur de la zone via Overpass API.
Mais j’ai constaté qu’un utilisateur a supprimé ce tag lors d’une session de vérification via osmose donc j’ai du faire une bêtise. Pour être un peu plus précis voilà la zone test.
Ne vous formalisez pas sur les noms d’utilisateurs, j’ai décidé en cours de projet de créer un compte (osm) pro “MarHoff” et distinct du compte perso que j’avais crée pour mes premier tests.

Du coup deux question si je constate comme sur l’exemple que des bâtiments industriels ne sont pas dans le polygone nommé land-use=industrial, puis-je modifier ce polygone pour inclure tous les bâtiments. Ce zonage modifié ne correspondra donc plus à une source officielle identifiable, mais à de la photo-interprétation depuis Bing (donc je rajouterais la source) mais correspondra mieux à la situation fonctionnelle sur le terrain. Pour vous cette approche est elle ok dans le cadre d’OSM?

Et question subsidiaire pouvez vous me confirmer que le tag landuse=industrial suffit à autoriser la recherche d’objet via l’enveloppe de la zone dans Overpass API et que donc area=yes est un tag inutile?

Tu peux prendre un café avant que ça soit terminé > :wink:

Je ressent l’appel de la caféine en ce moment même :smiley:

  1. fusion ou pas ?

Fusionner : oui si ça forme un “corps de bâti”. Par exemple, des bâtiments mitoyens, comme le dit Christian, qui se touchent mais ont leurs propres murs porteurs et leurs propres adresses ne devraient pas être fusionnés. Mais il y a de nombreux artefacts liés à l’import du cadastre qu’il vaut mieux supprimer (mais attention à conserver la distinction “building=yes” vs “building=yes” + “wall=no”). Pour les “building:parts”, c’est compliqué. Souvent les sous-éléments du cadastre ne correspondent pas à grand chose dans la réalité. J’ai souvent constaté que c’était purement fantaisiste, ou alors peut-être lié à des plans d’architectes qui ont évolués. Et même si c’est comme dans la réalité, il faut alors se lancer dans une cartographie plus complexe avec un polygone d’ensemble qui forme le contour extérieur du bâti (celui qui sera taggué en “building=yes”) puis des polygones plus petits à l’intérieur (sans compter les difficultés liées aux étages, 3D, etc). Beaucoup de travail que peu de contributeurs font, surtout pour une zone d’activité. Il vaut mieux fusionner et laisser ces détails à d’autres.

  1. multi-polygones

En général, on adopte les relations que si on n’a pas le choix :wink: La relation de type “site” en est un exemple. Si tu ne veux pas passer à un modèle avec l’adresse sur un noeud mais absolument le garder sur un polygone qui regroupe l’ensemble des bâtiments, tu pourrais tracer un simple polygone qui suit les limites parcellaires (ou la propriété) et le tagguer en “landuse=commercial” (ou “industrial”) et y ajouter les tags d’identification (nom + adresse). Cette image tirée du wiki montre un exemple de comment il faut faire avec une école qui a plusieurs bâtiments:
http://wiki.openstreetmap.org/wiki/File:Amenity_school_usage_example.svg

  1. contradiction cadastre/usage

Là, c’est simple : c’est le terrain qui prime. Il y a un petit pourcentage connu d’erreurs dans le cadastre. Il faut juste mettre les bons numéros et adapter le tag “source” (source:addr=survey ou local_knowledge)

  1. question con
    Pareil que Christian. S’il y a un polygone qui fixe les limites adminitratives de la commune, il n’y a pas nécessiter à dupliquer ces info. Par contre, il faut que le code postal soit aussi présent dans ce polygone de limite communale. Il y a aussi le cas des villes qui ont plusieurs codes postaux. La solution actuellement dans ce cas est d’ajouter le code postal à chaque adresse (en attendant qu’une convention claire apparaisse pour utiliser des polygones uniquement dédiés aux codes postaux et à condition d’en connaitre les limites géographiques)

NB: note que la relation “associatedStreet” est un moyen de lier numéro et nom de rue. Il est surtout employé en France mais très peu dans les autres pays. L’autre solution est d’ajouter le tag “addr:street” directement sur chaque adresse. Bien sûr, chacune des deux méthodes a ses avantages et inconvénients mais aucune des deux n’est obligatoire.

Autres remarques :

  • la méthode de l’addresse sur noeud suggérée par Christian offre aussi l’avantage de mieux identifier la façade/entrée de l’activité. C’est aussi plus facile pour les bâtiments qui ont plusieurs adresses. Certains logiciels ont du mal avec “addr:housenumber=3;5”

  • dans ma première réponse, j’ai suggéré l’emploi de plus petits landuse, quasiment individualisés. On peut quand même conserver le grand landuse qui identifie l’ensemble de la zone d’activité. Ce qu’il faut éviter, c’est que des “landuse” de nature différente se superposent (par exemple, un “residential” par dessus un “industrial”).

  • il faut effectivement éviter le tag “area=yes” qui souvent improprement utilisé pour afficher un nom sur la carte principale.

  • overpass-api est un outil pour extraire les données par filtrage. Ca n’est pas un outil officiel du projet OSM mais un service fournit par des tiers. Il faut donc être très prudent et ne pas adapter les tags à l’outil mais faire l’inverse.

Tout à fait ok.

La source officielle (Corine Land Cover) est loin d’être parfaite car basée sur l’interprétation de photos satellite. La corriger par une connaissance locale est donc approprié, en ajoutant la source qui a servi à la correction (comme tu l’as mentionné).

:exclamation:

Je me pose aussi des questions pratiques concernant la description des ZA. Je me doutais que je n’était pas le seul.

Il me semblerait utile de documenter les expériences, actions menées, bonnes pratiques et discussions sur un… hum… “support structuré d’intelligence collective”. Comprendre: le Wiki OSM. ça n’empêche pas d’en discuter sur des forums et mailing lists mais au moins la production serait structurée et facilement disponible.

WikiProject ou ensemble de pages de documentation ?

Les projets cartographiques sont des efforts de collaboration conduits par une communauté de personnes partageant un intérêt commun, qui peut être de cartographier un territoire particulier ou d’améliorer la couverture cartographique sur un sujet d’intérêt particulier.

(source : http://wiki.openstreetmap.org/wiki/FR:Mapping_projects)

Quelque chose dans le genre des "Projets thématiques spécialisés " http://wiki.openstreetmap.org/wiki/FR:Mapping_projects#Projets_th.C3.A9matiques_sp.C3.A9cialis.C3.A9s
:question: Des suggestions ?

:nerd: En passant : un des enjeux de la chose serait, pour ceux qui ont besoin de gagner leur vie et aimerait pouvoir le faire en participant au bien commun OSM, de pouvoir proposer des prestas aux organismes gestionnaires des ZA, aux collectivités, etc…

Merci pour cette avalanche de réponses! (et la proposition de bière IRL :wink: )

Je vais synthétiser tous ça et continuer à tester cette méthodologie sur deux zones test.
Si c’est concluant je vais essayer de me mettre au wiki pour mutualiser et conserver une trace plus pérenne de la démarche.

@Pieren: Désolé si je focalise un peu sur Overpass. Mais il est toujours compliqué d’expliquer à son patron qu’on va consacrer du temps de travail à remplir un “pot commun”.
Et dans mon cas la condition sine qua non à l’extension de ce projet c’est que l’on puisse récupérer régulièrement les données des zones traitées sous une forme exploitable pour nous. Du coup je suis obligé de me poser cette question très en amont!

A+

On ne taggue ni pour le rendu, ni pour l’overpass :wink:

Pour exploiter un maximum de données, il faudra s’adapter à celles-ci plutôt que d’ajouter des tags peu cohérents comme area=yes dans le cas présent.
Donc peaufiner les requêtes est la solution la plus “passe-partout”.

Ok c’est imprimé :wink:

Sur le coup ça ne me paraissait pas incohérent, mais au final c’est complétement redondant et inutile vu qu’une ZA à déjà un tag landuse=industrial|commercial
C’est donc automatiquement considéré comme une “area” et lui rajouter un nom suffit visiblement à provoquer son indexage lors de la prochaine itération de make-area

J’ai pas mal galéré avec la doc qui est un peu atomisée entre plusieurs pages wiki mais j’ai réussi à bricoler une requête qui semble faire le job que j’attendais.
A savoir récupéré l’objet zone et les objets filtrés par tags qui sont contenus à l’intérieur (et sans rien ajouter d’inutile dans osm!).

Pour l’instant je n’ai pas le temps de rédiger un retour plus construit car je suis pris par d’autre projets plus urgents.

Concernant ce qu 'a dit @EddieJavelle, je ne sais pas si mon initiative mérite de dédier une page de projet wiki.
En revanche je verrais bien à terme un petit tutorial par rapport à la méthode du style “Comment utiliser, améliorer et suivre les modifications des données OSM dans vos zones d’intérêts métier”

Mais après ptet que ça existe déjà? Et dans tout le cas il faudra sérieusement que je valide ma démarche avant de pouvoir communiquer dessus!

Bonjour à tous et bonne année 2014.

Je continue sur ce fil vu que mon projet avance.

Mais tout d’abord une question assez urgente.
Dans le cadre d’une application Leaflet légère affichant quelques tuiles aux niveaux 15-18 en fond de plan et un geojson qui est hébergé chez moi… Ais-je le droit de taper ici directement http://{s}.tile.osm.org/{z}/{x}/{y}.png?
Les conditions d’usages du serveur de tuiles principal détaillent clairement ce qui est interdit, mais pas vraiment ce qui est autorisé.
Dois-je en conclure que c’est possible pour un usage à priori léger car le service n’aura pas un grand nombre d’utilisateurs, même si je m’attend à un pic lors de la présentation officielle.
Dois-je contacter un admin pour être sûr? Si oui comment?

Point d’avancement
-Enrichissement de la base OSM sur mes deux zones test.
-Mise en place un script de synchronisation des objets inclus dans mes zones d’intérêt (batiments/adresses/zone) via OverpassAPI->Osmosis->Postgis
-Création d’un modèle de données pour stocker les données métiers qui me sont nécessaires, mais non intégrables à OSM
-Création d’un prototype sous leaflet pour afficher un geojson généré à partir de mon modèle

A faire
-Documentation!
-Affiner encore la base OSM avec les retours des partenaires à partir de ma carte leaflet qui sera leur porte d’entrée initiale vers OSM

Pour les tuiles osm.org, pour un usage léger, cela ne pose pas de problème.

Tu peux aussi utiliser celles françisées d’OSM-FR: http://{s}.tile.openstreetmap.fr/osmfr/{z}/{x}/{y}.png

J’avais peur par rapport à la monté en charge sauf que je viens de réfléchir et je me trouve un peu bête…
Comme je passe par Leaflet, logiquement les connexion aux tuiles se feront en direct depuis chaque client connecté et donc le trafic ne sera pas imputé à mon site ou mon Appli mais à chaque client.

Merci pour ta réponse rapide et rassurante :wink:

Euh, les admin savent très bien d’où viennent les requêtes grace au Referer dans l’entête HTTP.
http://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Comme rappelé par BrunoC, le referer indique qui a demandé les tuiles… donc on peut voir qui abuse :wink: