Si on veut éviter les réimports grace à un travail préalable de fusion, cela demanderait d'avoir dans la base des références sur les objets supprimés. Seulement les APIs d'OSM ne sont pas aisées actuellement pour obtenir des listes d'objets supprimés dans une zone donnée.
Personnellement je préférerai qu'une telle API existe plutôt que de devoir surcharger la base do'objets en replaçant les attributs "key=value" par "deleted:key=value" (similaire à "disused:key=value" déjà discuté ici pour les objets qui existent encore mais ont perdu leur usage, et aux autres attriburs comparables concernant les projets ou objets en cours de construction, ou temporairement fermés pour travaux et qui pourront nécessiter des mises à jour une fois ces travaux finis). Encore une fois on tombe dans les limites du système actuel qui n'est bien taillé que pour gérer les seules données actuelles (moyennant un retard des mises à jour) mais aucune donnée historique ou prévisionnelle, et taillé aussi pour ne gérer correctement que les niveaux les plus fins (tout bonnement car les modèle utilise des primitives géométriques trop simples, et n'utilise pas assez efficacement ses "relations", comme si seule la géométrie pouvait tout résoudre seule alors qu'il y a des tas de données relationnelles qui rentrent très mal dans ce moule où ne peut exister qu'une seule géométrie, la plus fine et la plus détaillée, mais aussi la plus volumineuse et la plus compliquée à analyser. Et plus cela évolue, plus le travail de préparation-fusion devient compliqué. Tôt ou tard, OSM devra évoluer pour se spécialiser en créant des sous-bases ayant plus de cohérence en interne, mais gérées sinon comme des couches transparentes superposables mais non liées géométriquement entre elles (on l'a déjà vu ici, certains se plaignent de la fusion géométrique des frontières admin et des routes/rivières/voies ferrées, ou de routes avec les "landuse", et nombreux sont aussi ceux qui se plaignent de la présence du bâti qui n'a pas strictement obligation d'être partout détaché des routes et des "landuse", en "forçant" les choses quitte à les décaler artificiellement quand ils ont pourtant physiquement liés... Déjà j'espère voir rapidement apparaître la nouvelle primitive surfacique (qui devra prendre en charge une partie de ce qu'on met soit dans des chemins (ways), soit dans des relations), histoire de pouvoir distinguer ce qui est filaire (et souvent sur un tracé arbitraire) comme les réseaux routiers ou fluviaux ou itinéraires balisés, de ce qui est occupation physique du terrain. La séparation pour l'instant n'existe qu'entre chemins et noeuds (mais dans certaines limites car il n'est pas facile de garder la séparation entre deux noeuds qui doivent occuper pourtant la même position mais pour des usages distincts sans avoir à en déplacer un arbitrairement). Le 16 septembre 2013 22:06, Nicolas Frery <nico...@zoubi.info> a écrit : > Le 16/09/2013 21:31, PierreV a écrit : > > Fausse bonne idée... comment ferais-tu pour déterminer les batis qui ont > été > > détruits? > > En comparant un fichier de bâti généré au préalable ? > Si c'est bien mis à jour une fois par an, encore que, il faudrait garder > en mémoire tout les fichiers de toutes communes. > Générer un nouveau fichier du bâti, comparer les manques et ajouts. > Générer en conséquence un fichier ne contenant que les différences. > > Sacré usine à gaz ! Tout n'est pas rose, décalage possible d'une année > sur l'autre, etc. > L'option de comparer avec le bâti présent dans OSM n'est même pas > envisageable.. :-( > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr