[OSM-talk-fr] Base de données pour le développement

Frédéric Rodrigo fred.rodrigo at gmail.com
Mar 10 Fév 20:30:28 UTC 2015


Le 10/02/2015 19:27, Vincent Frison a écrit :
> Le 7 février 2015 15:59, Frédéric Rodrigo <fred.rodrigo at gmail.com
> <mailto:fred.rodrigo at 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).

Tu n'a pas l'air de t'assurer que c'est le bon bâtiment, non ?

> 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.

Les objets on des versions. Que tu doit renvoyer à l'API. Elle va 
refuser la modification si la version a changé. C'est une façon bien 
plus efficace de faire.

>
> 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...

Ok



Plus d'informations sur la liste de diffusion Talk-fr