Re-bonne nuit, Je vais intervenir un peu plus en profondeur que tout à l'heure est diviser ma vision des choses tag par tag en ce qui concerne la modélisation des frontières administratives françaises.
== baratin je suis trop balèze == Je vais commencer par me présenter pour ceux qui ne me connaissent pas : C'est moi qui est écrit et lancé cette proposition de type=boundary_segment http://wiki.openstreetmap.org/wiki/Relations/Proposed/boundary_segment C'est moi qui est écrit la page qui explique son utilisation pour la france : http://wiki.openstreetmap.org/wiki/France_boundary_pyramidal_construction C'est moi qui, au début, ais fait le tout premier découpage avec des type=boundary_segment Et c'est moi qui entretient et développe les outils de contrôle et d'exportation des niveau administratifs français 2,4,6,8 http://suivi.openstreetmap.fr/communes/ http://export.openstreetmap.fr/contours-administratifs/ http://beta.letuffe.org Voilà, c'est tout, c'était juste pour la ramener et me venter comme d'habitude. Non, ce que je veux dire par là, c'est que je pense avoir une vision assez poussée tant du coté du développeur que du coté contributeur pour tenter de concilier : données utilisables et donnée rentrables dans osm (et ouvrir ma gueule) == Tag par tag, comment améliorer == Pas la peine de répéter que rentrer des contours administratifs, aujourd'hui, ça marche, mais c'est un peu la pagaille pour des raisons de standardisation mondiale et que même si le modèle actuel est mieux que de superposer 20 chemins les uns sur les autres, il y a sans doute matière à améliorer === role : subarea === ( http://wiki.openstreetmap.org/wiki/Relation:boundary ) Ce modèle nous renvoi directement au débat somme de surface VS contour: http://lists.openstreetmap.org/pipermail/talk-fr/2011-March/031437.html Pour résumer, on ne sait pas de façon certaine lequel est le mieux, bien que je fasse parti de ceux qui pense que notre modèle actuel me semble avoir plus d'avantage, mais pour l'instant, personne n'a pû prouver qu'une utilisation des données était rendue impossible par l'un ou l'autre, ce qui nous amène a conclure que c'est perdre du temps que d'avoir les deux. subarea (modèle somme de surface) est donc inutile dans l'état actuel des contours administratif qui utilise déjà le modèle de frontières, il ne faut donc pas l'encourager ou alors, il faut tout changer et ne faire plus que ça. Pour verdy_p : toutes les utilisations que tu as cités peuvent déjà se faire avec le modèle actuel (modèle frontières) grâce aux bases de données relationnelles === outer/inner/exclave/enclave/(rien) === Au niveau du modèle des données tout ça se résume à deux notions : c'est un trou ou c'est autour, on a donc trop de rôle pour rien à mon avis. Vu que le modèle des mutipolygones est bien défini et utilisent outer/inner, je propose d'utiliser ces rôles pour la france === type=boundary/multipolygon === Encore une fois, la construction des deux est parfaitement similaire, on sait qu'un contour est administratif parce qu'il a boundary=administrative, le type=boundary n'est donc qu'une autre manière de dire type=multipolygon, le traitement des type=multipolygon est aussi très répandu, donc aucune raison d'avoir des incompatibilité d'utilisation "fortes" et cela simplifierait la vie des débutants en leur disant, une fois pour toute, type=boundary/multipolygon c'est pareil, pour éviter que tu te poses la question : Mettons des type=multipolygon pour nos relations administratives === tags boundary=administrative sur les ways === Je vais pas me faire des amis, mais je rappel juste que tagguer les ways qui sont dans la relation est un doublon car vu qu'ils sont dans la relation, on sait qu'il sont des frontières administratives. On règlerait plein de problème de rendu (superposition de couleur) et de travail dupliqué à les enlever. === type=boundary_segment === Le plus dur pour la fin ;-) ha que je regrète d'avoir nommé le tag ainsi ! idem que avant : cette relation porte déjà le tag boundary=administrative, on sait donc ce que c'est une frontière, il eu été plus judicieux d'utiliser le tag type pour définir de manière indépendante de ce que c'est, ça forme. Mon rêve du moment, c'est de la transformer en : type=multilinestring pour ne pas faire bande à part, et utiliser des termes déjà connus dans le monde GIS : http://en.wikipedia.org/wiki/Well-known_text Et aussi pour dire, définissons des formes complexes grâce aux relations mais ré-utilisons les, plutôt que d'avoir ensuite des mappeurs qui peinent à comprendre les relations, des programmeurs qui re-codent plusieurs fois la même chose. Passé ce désagrément de mot (mais je vais écrire une proposition sur le wiki), le modèle de pyramide me plaît toujours, oui car dans notre modèle actuel, il permet de limiter le nombre de relations auxquelles appartient un way de frontière administrative. Et non, en effet, je le dis à mes détracteurs, ça ne va pas être mégasupersimple, mais le peut-on ? Donc, oui à type=boundary_segment sur le principe mais quand et comment faire la transition en douceur et progressivement ? Le faire dans les données, aujourd'hui, c'est possible. c'est pas idéal, mais c'est possible, prions pour que les outils d'édition s'améliorent ensuite au fûr et à mesure qu'on l'utilisera plus. Mais pour l'utilisation des données, c'est plus délicat. (bon, ok, dans les rendus, ça se voit pas trop) Le support de ces pyramides et plus ou moins nul à part dans des outils spécialisés que seul à ma connaissance E. Chové avait développé et qu'on ne peut pas utiliser à grande échelle. osm2pgsql, l'outil qui est à la base du rendu mapnik, de mes logiciels d'export/détection d'erreurs/nominatim/mapquest ne supporte pas ces constructions. Pour verdy_p : hélas sur tes exemples sur nominatim, je peux te dire ce qui va se passer : Plus rien ne pourra plus être indiqué comme étant dans l'ille et vilaine puisque nominatim utilise osm2pgsql qui ne supporte pas cette construction. Pour mkgmap (création de carte pour garmin) pareil, osmand, je crois que c'est pareil. etc. Seulement, seulement, seulement voilà, si on ne fais pas avancer la manière de tagguer, aucun n'outil n'apparaît pour supporter ce qu'il n'y a pas besoin de supporter quand les mutipolygon sont apparus (juste après les dinosaures, souvenez vous !) tous les développeurs ont crié au scandale. Je me rappel des débats autour de mkgmap ! Mais finalement, quel soulagement, c'est super pratique les multipolygon dans une base osm qui regorge de plus en plus de données qu'on aurrait dû superposer maintes fois, et puis au final, c'est supporté (presque?) partout. Mais soyons pragmatiques, une telle opération casserait beaucoup de chose, et cela nuirait au projet, je propose donc de limiter cette construction aux pays pour l'instant et <strike>de faire pression</strike>d'encourager les développeurs en supprimant la relation france qui n'est pas construite sur le modèle pyramidale. Mais si au moins osm2pgsql pouvait supporter ça, qui est le coeur de <strike>mes outils</strike> nominatim, mapnik et plus encore, je changerais alors d'avis pour passer ce modèle au niveau 4 et 6. Fin Si votre lecture vous a mené jusque là, félicitation, vous êtes nominé pour un "addicted osm awards" -- sly (sylvain letuffe) -- View this message in context: http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7218682.html Sent from the France mailing list archive at Nabble.com. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
