Il sufit de charger dans ton postgres de test non pas la base OSM normale, mais une récupération des données sur l'API de test... là tu aura tout synchro pour tes tests.
Une fois que tout est ok, tu recharge les vraies données OSM et tu relance ton script. Le 10/02/2015 19:27, Vincent Frison a écrit : > Le 7 février 2015 15:59, Frédéric Rodrigo <fred.rodr...@gmail.com > <mailto:fred.rodr...@gmail.com>> a écrit : > > Le 07/02/2015 14:45, Vincent Frison a écrit : > > Du coup je me demande quelle est la bonne procédure à suivre pour > charger un schéma apidb (sans devoir mettre l'option > validateSchemaVersion=no). > > > En pratique personne n'utilise la l'apidb. > Si tu veux faire des tests, l'api de du serveur de dev devrait > sufire c'est des cas biens définit. > > > Le problème de l'api du serveur de dev/test c'est que je ne peux pas > conserver les IDs originaux de la vraie base, or c'est un point > nécessaire pour mes tests. > > Revoici la façon dont fonctionne mon programme qui est vraiment > simpliste : > > 1) Pour chaque immeuble de la base à importer je calcule l'osmId du > building correspondant à la position géographique de l'immeuble (grâce > à une base PostGIS en local contenant les données OSM de toute la > France et avec le schéma osm2pgsql, très rapide puisqu'il y a une > indexation spatiale). > 2) Si un ID de building est trouvé je télécharge l'élément > correspondant depuis l'API d'OSM et si le way ne contient pas > d'informations sur la hauteur ou sur le nombre d'étages alors je les > renseigne (mais si ces données présentes alors je ne fais rien, > histoire d'être sûr de ne pas abîmer le travail qu'aurait pu des > contributeurs). > 3) Je met à jour l'élément dans la foulée, il y a donc très peu de > chance d'avoir des accès concurrents puisque le délai entre le read et > le write n'est de quelques millisecondes. > > Actuellement pour tester je suis obligé pour la phase 1) de coder en > dur les IDs en fonction des coordonnées afin d'avoir les mêmes que > ceux de l'API de test. Mais ça ne marchera plus pour faire des gros > tests. Par contre avec une API de test qui tournerait en local chez > moi (avec The Rails Port + PostGIS avec un schéma apidb) je pourrai > alors charger les données de toute la France en un seul coup.. et > surtout avoir des IDs qui seraient conservés. > > > Sur les données, tu as également le schéma de base osmosis qui est > plus proche de celui de l'api que de osm2pgsql qui est > initialement destiné au rendu et dont le contenu de la base > résultante est partiel. > > > J'imagine que tu parles en fait du schéma pgsnapshot ? Mais à priori > je suis obligé de charger le schéma apidb... à moins qu'on puisse > également faire tourner The Rails Port sur ce schéma ? > > Mon avis est, comme cela a déjà était dit, est que tu veux mettre > la charrue avant les bœufs. S'assurer et obtenir une > licence/accord de l'utilisation des données est primordial, et > peut prendre plus de temps et être finalement plus compliqué que > les aspects techniques. > > > Je pense pas mettre la charrue avant les boeufs car contrairement aux > données de PSS celles d'opendata.paris.fr <http://opendata.paris.fr> > elles sont libres, ça c'est complètement sûr. J'ai donc modifié mon > script pour aller piocher les données de leur fichier (CSV) et je > pourrai aussi l'adapter facilement pour d'autres bases de données > relatives aux bâtiments puisque visiblement il n'y a pas que Paris qui > propose de l'opendata... > > Merci, Vincent. > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
