<div dir="ltr">Le 3 septembre 2013 13:20, François Lacombe <span dir="ltr"><<a href="mailto:francois.lacombe@telecom-bretagne.eu" target="_blank">francois.lacombe@telecom-bretagne.eu</a>></span> a écrit :<br><div class="gmail_extra">

<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Plusieurs problématiques lourdes se présentent encore à moi :<br>

</div></div><div>1. Dans le sens OSM => Infos-Réseaux.com<br></div><div>- A la différence d'OSM, ma base gère l'historisation du terrain. C'est très difficile de savoir si une nouvelle version OSM est une version terrain ou une correction d'incohérence.<br>


- Parser du xml d'overpass API peut-il suffire où faut-il carrément 
prévoir un import dans pgSQL via osm2pgsql avant de travailler sur les 
données ?<br></div></div></div></div></blockquote><div><br></div><div>L'overpass peut sortir autre chose que du XML si besoin (json par exemple).</div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div><div>- Les identifiants d'objets OSM peuvent changer, c'est pourtant la seul info que je peut conserver de mon côté pour rendre la correspondance persistante dans le temps. D'autres idées ?<br>


</div><div><br></div></div></div></div></blockquote><div><br></div><div>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.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div><div>2. Dans le sens Infos-Réseaux.com => OSM.<br></div>

<div>- On ouvre un changeset standard pour publier l'intersection du diff local depuis la dernière publication avec les données actuelles OSM (que le nécessaire quoi, comme le ferait un humain).<br>
</div><div>- Il va y avoir des doublons, il va falloir sélectionner ce qui n'existe pas du tout sur OSM avant de le publier (que des données compatibles avec ObDL cela va de soi, ce sont majoritairement mes propres observations terrain). C'est ce qui me semble le plus compliqué en l'état.<br>


<br></div><div></div>Il existe une foultitude d'outil tous aussi alléchants les uns que les autres pour répondre à ces besoins, je m'y perd encore quant à la pertinence réelle de l'utilisation de telle ou telle solution dans mon cas.<br>


<br></div>Si cela intéresse des gens de monter ce système, l'expérience pourra surement servir à d'autres. Ceci a d'ailleurs peut-être déjà été fait auquel cas je veux bien avoir des retours d’expérience.<br>

</div></div></blockquote><div><br></div><div>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.</div></div><div><br></div>-- <br>

Christian Quest - OpenStreetMap France<br>Un nouveau serveur pour OSM... <a href="http://donate.osm.org/server2013/" target="_blank">http://donate.osm.org/server2013/</a>
</div></div>