[OSM-talk-fr] cadastre.openstreetmap.fr

[Philippe Verdy]

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 <nicolas at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130916/33ed1a2e/attachment.htm>