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

[François Lacombe]

Désolé pour le mail vide... la même et on recommence.

Le 4 septembre 2013 08:07, Ista Pouss <istaous at gmail.com> a écrit :

> Le 4 septembre 2013 01:06, François Lacombe <
> francois.lacombe at telecom-bretagne.eu> a écrit :
>
>> - 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 ?
>>
>
> Cet identifiant n'occupe pas de place en mémoire, puisqu'il est constitué
> des propriétés de l'objet.
>

Observation très intéressante. Il va falloir que je ne modifie pas trop non
plus les données OSM des objets pour les reconstituer et ne serait-ce que
pour les republier en entier derrière en cas d'édition chez moi.

Enfin le fait de le construire à la volée plus que de le stocker en
parallèle du reste ne m'était pas venu à l'idée, il était tard :)


> Toutefois il peut être consommateur en temps pour retrouver l'objet
> identifié ; il existe alors la technique du hashcode, soit un nombre qui
> "résume" l'objet, et qui permet de sélectionner rapidement les objets
> possibles, puis, en vérifiant sur les valeurs des paramètres identifiants,
> trouver le bon objet.
>

C'est pour ça qu'importer OSM avant de publier à mon tour m'évite de faire
plein de requêtes pour retrouver les objets :
- Sois mon objet n'a pas d'équivalent OSM, dans ce cas on le publie comme
nouvelle entrée
- Sois il en a une, et on a déjà son numéro actuel (puisque je vais tourner
avec overpass).


> Si le haschcode est bien choisi, il trouve le bon objet directement dans
> la plupart des cas ; la vérification sur les valeurs reste nécessaire, mais
> consomme très peu de temps.
>

C'est là où je vais voir si mon ORM est performant.
La plupart des objets que je cible sont identifiés par un code
(l'infrastructure, les opérateurs, c'est cadré), ca permet directement de
retomber sur la bonne chose en identifiant les champs attestant de
l'unicité de l'objet en question.
C'est pour ça qu'il faut surtout pas se gêner :
http://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo :)


>
> Je pense que c'est une erreur que de fonder l'identifiant sur les
> coordonnées, sauf peut être pour un truc complètement fixe, à titre de
> facilité : une île, un continent, un océan...
>
> En effet, le traitement des coordonnées est une prise de tête, et
> n'identifie en rien quoi que ce soit : si je déplace sur la lune n'importe
> quel objet, l'objet reste évidemment le même. Si je déplace Paris sur la
> lune, j'ai toujours Paris.
>

Ca ok, +1


>
> Alors continue avec et tiens nous au courant :-)
>

Il va y avoir un mix entre ça, l'utilisation des codes d'infra, etc...
Plusieurs sénarii plutôt qu'un seul permettront de réduire les rejets
(parce qu'il y en aura forcément).


Peut être pourrais-tu t'inspirer des solutions d'import du milieu qui
> exploite les données open data ; tu ferais ta base, avec ta saisie, chez
> toi, puis à l'aide d'un plugin open data Josm (il y a le modèle quelque
> part) tu enverrais les données sur OSM. Tu te désignes comme source de
> données, et tu y mets tes identifiants comme tu le souhaites.
>
> Mais avec ce système, tu ne pourrais pas relire les données si quelqu'un
> les modifie sur OSM. C'est une des faiblesses, je pense, du mouvement open
> data actuel, mais je pense (en plus), que cette faiblesse sera résolue un
> jour avec les progrés de ce mouvement.
>
> Donc, si je résume : fait ton petit open data perso :-)
>

On verra comment ça évolue mais je compte bien avoir quelque chose qui
tourne tout seul.
Sinon ça perd de son intérêt.


@Philippe : Je pense que c'est ce qui va se retrouver dans ma base.
Il ne faut pas perdre de vue que je cible tout de même des objets d'un type
particulier. Comme dit plus haut, ils souvent un identifiant métier donner
par l'opérateur et dans ce cas, ça évite pas mal de problème de les
reporter dans OSM.
Une boulangerie n'a pas ce genre d'identifiant par exemple.



Bonne après-midi, merci pour vos réponses.


*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/20875307/attachment.htm>