*François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com
Le 4 septembre 2013 08:54, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Le 4 septembre 2013 08:07, Ista Pouss <ista...@gmail.com> a écrit : > > Le 4 septembre 2013 01:06, François Lacombe < >> francois.laco...@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. >> >> 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. >> >> 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. >> >> >> >>> - 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 :( >>> >>> > OSM a déjà un id stable utilisable : pas seulement le type d'objet et son > id, mais aussi son numéro de version. > > Avec ça on a ce qu'il faut pour rester en synchronisation et détecter les > changements pour faire les rapprochements dans une base externe. > > Pour les rapprochements, on a des tas de façon de retrouver l'objet à > partir des historiques, et notamment la liste des objets dans le changeset > de chaque changement. > Après ça il y aura toujours des difficultés à résoudre ce qui a > profondément changé et il n'y a aucun moyen de définir un processus de > rapprochement totalement automatique qui résoud tout. > > Créer un autre "identifiant" à partir d'un certain nombre de > caractéristiques ne changera rien : l'idée du hashcode des caractéristiques > sera encore pire puisqu'il sera impossible de déterminer des critères de > rapprochement autres que ceux d'une liste prédéfinie exactement sur une > base arbitraire non évolutive. > > Donc pour moi un rapprochement avec OSM est un identifiant simple comme > "r12345v2" (version 2 de la relation 12345). Et pour le reste OSM a assez > de métadonnées pour pouvoir appliquer des critères de rapprochement moins > figés ou répondant à divers problèmes différents sans qu'on soit obligé de > coder les tags (qui sont déjà accessibles dans les objets identifiés et > versionnés). > > Et ces rapprochements ne nécessitent même pas d'importer dans OSM d'autres > identifiants externes (hormi ceux correspondant à des normes bien établies > et incontournables utilisées plus massivement et dans beaucoup plus > d'applications que dans OSM, ces normes étant nationales ou > internationales) correspondant à des sources incontournables (mais elles > aussi évolutives dans leur contenu; et donc les identifiants externes > devraient aussi être versionnés pour lever les ambiguités avec ce qui a été > qualifié et déjà rapproché). > > >> > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
