[OSM-talk-fr] Un peu d'aide pour du développement complexe

[François Lacombe]

Merci pour vos réponse, il y a encore matière à se triturer les neurones :)


Le 3 septembre 2013 13:41, Christian Quest <cquest at openstreetmap.fr> a
écrit :

> L'overpass peut sortir autre chose que du XML si besoin (json par exemple).
> L'avantage d'interroger une API c'est que tu accède toujours aux infos
> actuelles. Un import nécessitera de gérer les mises à jour, de filtrer
> aussi pour ne garder que ce qui t'intéresse et un schéma osm2pgsql est
> plutôt destiné au rendu qu'à un véritable accès aux données.
>

Ok c'est noté. Oui je disais xml comme format de base mais JSON sera
peut-etre préféré, je n'ai pas encore fait mon choix.


>  Oui... un identifiant composite avec localisation+attributs de base, que
> tu peux traduire à la volée en requête overpass pour récupérer les données
> actuelles correspondantes dans OSM.
>

Ça c'est intéressant.
Néanmoins je vois quelques inconvénients :
- Un tel identifiant peut vite devenir très lourd. Avec ~ 400K transfos
HTA/BT EDF, ~5K postes HTB, plein de réservoirs d'eau de pipeline etc... ma
base va exploser non ?
- A la différence de l'identifiant numérique, si l'objet est déplacé et que
la position fait partie de l'identifiant composite, je le perds :(

En exécutant obligatoirement les deux sens de cette "synchro", OSM =>
IR.com puis IR.com => OSM on peut s'éviter d'avoir à faire une
correspondance objet par objet puisqu'on charge les données actuelles OSM
d'abord.
Ce qui doit être publié depuis ma base est ce qui n'est pas sorti dans les
données OSM.


> Sûr que c'est intéressant car c'est un problème qui revient souvent:
> comment maintenir 2 bases distinctes synchronisée et sans ID commun.
>

En effet. Espérons que ca ne se transforme pas en prise de tête insoluble :)


Le 3 septembre 2013 13:48, Ista Pouss <istaous at gmail.com> a écrit :

> Heu... si "historisation" veut dire "historique"... oui ; aucune solution
> technique. Il faut utiliser un système historique :-)
>
> Apparemment, chez OSM on voit l'histoire comme une sorte de propriété de
> plus, qu'il suffirait de rajouter. Qu'ils la rajoutent, ça fera des
> vacances.
>

En fait mes versions correspondent uniquement à des modifications terrain.
Je n'ai pas les moyens d'annuler une édition comme le peu le staff d'OSM,
ca n'étais pas ce qui était recherché.
Sur ce plan c'est incompatible oui.
Créer des nouvelles versions de mon côté à chaque édition OSM serait trop
lourd... tout écrire dans la même version écraserait complétement tout
historique. Il va falloir choisir.


>  Huuuuummm.... Ne lis-tu pas cette liste ?... Oriente toi selon les
> opinions que tu as sur les débats.
>

Si si, j'ai bien déjà lu des choses sur les identifiants d'objets métier.
Pour autant j'ai pas réussi à trouver de solution "abordable" dans mon cas.
L'idée alternative de Christian n'est pas bête, parce que ce que je
recherche n'a pas tellement à voir avec une notion "métier".


> Je suis arrivé dans la galaxie OSM au moment des hurlements suites à des
> imports en masse, et ça m'a traumatisé, aussi j'ai très peu avancé sur les
> modifs de la base par programme, j'ai l'impression que c'est mal vu par la
> communauté, sauf par l'intermédiaire d'un plugin Josm. Là dessus, je trouve
> que la communauté est sage.
>

Certes mais j'ai pas envie de saisir deux fois la même chose.
Dans ce sens je prévois vraiment de faire un truc solide et blindé pour
éviter de transformer cette initiative en vandalisme.



Le 3 septembre 2013 18:27, Marc SIBERT <marc at sibert.fr> a écrit :

> Bonjour,
>
> Ma marotte... vous allez trouver que je tourne un peu en rond, mais
> jusqu'à preuve du contraire, il ne sera pas possible de faire des
> synchronisations bi-directionnelles entre deux référentiels.
>

Non il ne s'agit pas de synchroniser les référentiels mais les données.

Dans chaque sens, le traitement va s'accompagner d'un routage des tags OSM
vers mes champs et de mes champs vers les tags en vigueur d'OSM (oui il
faudra suivre pour les mises à jour).

Le but est vraiment d'utiliser les données OSM avec mes outils et de
publier ce que je connais de mon côté sur OSM. La traduction est
obligatoire et plutôt bienvenue pour justement étanchéifier les deux
référentiels qui ne sont pas construits pour la même chose.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130904/06500ee4/attachment.htm>