Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
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 :( 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. L'idée alternative de Christian n'est pas bête, parce que ce que je recherche n'a pas tellement à voir avec une notion métier. Alors continue avec et tiens nous au courant :-) Je suis arrivé dans la galaxie OSM au moment des hurlements suites à des imports en masse, et ça m'a traumatisé, aussi j'ai très peu avancé sur les modifs de la base par programme, j'ai l'impression que c'est mal vu par la communauté, sauf par l'intermédiaire d'un plugin Josm. Là dessus, je trouve que la communauté est sage. Certes mais j'ai pas envie de saisir deux fois la même chose. Dans ce sens je prévois vraiment de faire un truc solide et blindé pour éviter de transformer cette initiative en vandalisme. 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 :-) http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
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
Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
*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
Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
Désolé pour le mail vide... la même et on recommence. 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. 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
Si ce sont des identifiants métier, quel intérêt y a-t-il a les mettre dans OSM ? On peut faire l'inverse et reporter de la même façon l'identifiant OSM dans la base métier. Dès lors qu'il y a correspondance, et d'autant plus que la correspondance est complexe (par exemple M objets dans OSM correspondant à N objets dans la base métier), il faut de toute façon une table de relation supplémentaire et non un seul tag d'un côté ou l'autre. Sinon si la correspondance est bijective, qu'on stocke l'identifiant métier dans OSM ou l'identifier OSM dans la base métier, c'est équivalent. Si la correspondance est surjective, on mettre aussi l'identifiant OSM dans la base métier. Ce que je veux dire c'est que l'identifiant versionné OSM (comme r12345v2) suffit pour aller renseigner la base métier. Je ne vois que dans le cas où l'identifiant métier est celui d'une base de données publique ouverte, avec une source de référence (issu d'une norme publiée) qui n'est pas OSM mais cette base métier, qu'il y a intérêt à stocker cet identifiant métier dans OSM. Si l'identifiant métier n'est pas associé à une norme publiée, on ne pourra rien en faire en dehors de celui qui a mis cet identifiant métier dans OSM pour sa propre application fermée : ce n'est pas une donnée ouverte et cela n'a donc pas sa place dans OSM car ce n'est pas compatible avec sa licence. Le 4 septembre 2013 12:45, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Désolé pour le mail vide... la même et on recommence. 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. 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
Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
Le 4 septembre 2013 15:06, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Le 4 septembre 2013 13:41, Philippe Verdy verd...@wanadoo.fr a écrit : Si ce sont des identifiants métier, quel intérêt y a-t-il a les mettre dans OSM ? On peut faire l'inverse et reporter de la même façon l'identifiant OSM dans la base métier. Dès lors qu'il y a correspondance, et d'autant plus que la correspondance est complexe (par exemple M objets dans OSM correspondant à N objets dans la base métier), il faut de toute façon une table de relation supplémentaire et non un seul tag d'un côté ou l'autre. L'astuce c'est que ce n'est pas LA base métier, mais MA base métier. J'avais bien compris que ce n'était LA base métier puisquu'il n'y en a évidemment pas qu'une seule (sinon ce n'est pas une base métier). Mais si tu insistes pour dire que c'est TA base métier, raison de plus pour que tu ne viennes rien mettre dans OSM qui se réfère au contenu de TA base. Rien n'empêche TA base de contenir des objets (ou liste d'objets) directement associés à OSM. Tu crée TA table interne de liens vers OSM (ou vers autre chose, à toi de voir à quoi tu veux te lier. Elle n'est pas complète, OSM peut l'enrichir et je peux enrichir OSM. Tu n'enrichiras pas OSM en y mettant des liens vers TA base. Si ce sont des identifiant qui viennent du terrain, ils ne procinnent pas de TA base mais d'une autre base tierce. Si cette base n'est pas ouverte, OSM n'a pas besoin et ne veut pas de ces identifiants, même si tu les as vus sur le terrain (avec ta connaissance à prori de leur signification). Si tu vois un petit panonceau ou une inscription, qui te dit que ce panonceau est à jour et sers même encore à celui qui l'a posé ? Cet identifiant peut êtte historique mais plus celui utilisé, mais il n'a pas été enlevé du terrain par l'exploitant actuel qui dispose d'autres méthodes d'identification (par exemple des numéros de série d'appareils, ou des numéros de parcelles cadastrales à la place d'anciennes zones de collecte ou de distribution, ou des numéros laissés par un titlulaire précédent de concession). Les numéris peuvent ne pas être uniques au plan national mais à une échelle locale (l'exploitant seul le sait si ce n'est pas une donnée ouverte, lui seul dispose des cartes avec les limites de zones dans lesquelles ces numéros sont utilisés, ou des codes couleur, ou logos permettant de repérer le bon numéro). Si on prend l'exemple des réseaux d'énergie ou d'eau, c'est souvent le numéro série de l'appareil de mesure comme un compteur (plombé et certifié par les mines) qui va servir de référence sur le terrain, il changera dès que l'appareil sera changé alors que l'emplacement n'a pas varié et personne ne dira quand il a changé ou va être remplacé (ce qui peut avoir lieu à tout moment et seul l'exploitant est prévenu). L'appareil étant dans une armoire normalement fermée, personne d'autre que l'exploitant (ou le propriétaire dans le cas d'une installation sur un terrain privé) n'y a normalement accès, ce n'est pas une donnée libre. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
Le 4 septembre 2013 13:41, Philippe Verdy verd...@wanadoo.fr a écrit : Si ce sont des identifiants métier, quel intérêt y a-t-il a les mettre dans OSM ? On peut faire l'inverse et reporter de la même façon l'identifiant OSM dans la base métier. Dès lors qu'il y a correspondance, et d'autant plus que la correspondance est complexe (par exemple M objets dans OSM correspondant à N objets dans la base métier), il faut de toute façon une table de relation supplémentaire et non un seul tag d'un côté ou l'autre. L'astuce c'est que ce n'est pas LA base métier, mais MA base métier. Elle n'est pas complète, OSM peut l'enrichir et je peux enrichir OSM. Des deux côtés, les identifiants métier proviennent du terrain. Entre recopier le terrain, potentiellement créer de la données dont nous ne disposons pas encore et recopier à la main des identifiants OSM mon choix est fait. Là il n'est question que de la correspondance sur l'existant. Pour tout nouvel objet, la correspondance est faite automatiquement lors de la bascule puisque l'identifiant métier vient avec le reste des données. Ma réflexion évolue, je sais qu'il va falloir plusieurs scénarii pour identifier convenablement tout les cas qui se présentent. Une identification métier n'est pas possible dans tous les cas, à partir de là, on aura peut-être besoin de créer subjectivement ces identifiants en utilisant pourquoi pas des données représentatives ou les numéros id/version. Le plus gros exemple que j'ai pour l'instant, ce sont les codes GDO ERDF. La norme est complétée en temps réel sur le wiki au fur et à mesure que je progresse, elle ne fait pas partie de mon référentiel perso. http://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo On pourrait faire la même avec le réseau téléphonique public et c'est pour ça que je cherche un référentiel national sur les réseaux de flotte. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Un peu d'aide pour du développement complexe
Bonjour, J'interviens sur OSM en producteur de données depuis un certain temps maintenant, j'aimerais commencer à les consommer. Je souhaiterais synchroniser une base de données perso, qui n'a rien à voir avec le formalisme OSM (elle reprend tout de même nœud, chemin, relation), avec une partie du jeu de données disponible sur les réseaux de transport et de communication. Le but est d'enrichir cette base avec des objets d'OSM, mais aussi d'enrichir OSM avec des données de cette même base. Il y a donc des échanges à prévoir dans les deux sens, en gardant un oeuil sur la quantité d'information à brasser. Il n'y a pas que des primitives compatibles avec OSM dans ma base, je ne peux donc pas la remplacer complètement. Les domaines visés sont ceux de mon site web : télécoms, énergie et eau potable. Plusieurs problématiques lourdes se présentent encore à moi : 1. Dans le sens OSM = Infos-Réseaux.com - 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. - 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 ? - 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 ? 2. Dans le sens Infos-Réseaux.com = OSM. - 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). - 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. 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. 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. Merci par avance pour vos lanternes. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
Le 3 septembre 2013 13:20, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Plusieurs problématiques lourdes se présentent encore à moi : 1. Dans le sens OSM = Infos-Réseaux.com - 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. - 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 ? L'overpass peut sortir autre chose que du XML si besoin (json par exemple). 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. - 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 ? 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. 2. Dans le sens Infos-Réseaux.com = OSM. - 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). - 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. 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. 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. 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. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
De ma toute petite expérience sur ce genre de question Le 3 septembre 2013 13:20, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Plusieurs problématiques lourdes se présentent encore à moi : 1. Dans le sens OSM = Infos-Réseaux.com - 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. Heu... si historisation veut dire historique... oui ; aucune solution technique. Il faut utiliser un système historique :-) Apparemment, chez OSM on voit l'histoire comme une sorte de propriété de plus, qu'il suffirait de rajouter. Qu'ils la rajoutent, ça fera des vacances. - 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 ? Overpass fonctionne très bien ; j'ai l'impression que pgSQL est bon si tu veux faire des requêtes types SQL/géographiques complexes ; avec Overpass tu peux en faire, mais plus simples. Et le système de requête d'overpass est un peu obscur, du moins je trouve je n'ai toujours pas compris ce que veut vraiment dire ._;; ;, mais je verrai ça un dimanche que je m'ennuierai. Le gros avantage d'overpass est qu'il semble synchro avec les données OSM, alors qu'avec pgSQL il y a la synchro que tu pourras y mettre (mais c'est peut être mieux ainsi) - 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 ? Hummm Ne lis-tu pas cette liste ?... Oriente toi selon les opinions que tu as sur les débats. 2. Dans le sens Infos-Réseaux.com = OSM. Je suis arrivé dans la galaxie OSM au moment des hurlements suites à des imports en masse, et ça m'a traumatisé, aussi j'ai très peu avancé sur les modifs de la base par programme, j'ai l'impression que c'est mal vu par la communauté, sauf par l'intermédiaire d'un plugin Josm. Là dessus, je trouve que la communauté est sage. En bonus, il existe la liste dev...@openstreetmap.org pour ce genre de questions, liste nettement moins animée que la présente liste, mais c'est pas plus mal. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
Bonjour, Ma marotte... vous allez trouver que je tourne un peu en rond, mais jusqu'à preuve du contraire, il ne sera pas possible de faire des synchronisations bi-directionnelles entre deux référentiels. Ceci posé, on peut préciser un peu. En fait, un référentiel le l'ai que sur un périmètre bien défini. Cela laisse une certaine liberté pour faire du mono-directionnel sur des périmètres différents. Je me permets un lien où je détaille ma pensée : http://eirl-marc.wp.sibert.fr/2013/04/16/un-referentiel-geographique/. Il faut que je poursuivre l'article en fait. En gros il te reste à toujours produire dans OSM (le référentiel), même à partir d'autres outils de génération automatique de données, et à consommer dans OSM ou dans ton application qui ne sera qu'un réplicat (enrichi c'est possible) d'OSM. Je suis aussi à la recherche de contre-exemples où ça marche histoire de voir ce que vaut ma théorie. Par ailleurs, j'ai un temps utilisé Spatialite ( http://www.gaia-gis.it/gaia-sins/) pour faire des réplicats locaux et ça fonctionne pas mal en mode mono-utilisateur / lecture seule. Les dernières versions ont encore progressé et permette l'import des données OSM. A+ Le 3 septembre 2013 13:20, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Bonjour, J'interviens sur OSM en producteur de données depuis un certain temps maintenant, j'aimerais commencer à les consommer. Je souhaiterais synchroniser une base de données perso, qui n'a rien à voir avec le formalisme OSM (elle reprend tout de même nœud, chemin, relation), avec une partie du jeu de données disponible sur les réseaux de transport et de communication. Le but est d'enrichir cette base avec des objets d'OSM, mais aussi d'enrichir OSM avec des données de cette même base. Il y a donc des échanges à prévoir dans les deux sens, en gardant un oeuil sur la quantité d'information à brasser. Il n'y a pas que des primitives compatibles avec OSM dans ma base, je ne peux donc pas la remplacer complètement. Les domaines visés sont ceux de mon site web : télécoms, énergie et eau potable. Plusieurs problématiques lourdes se présentent encore à moi : 1. Dans le sens OSM = Infos-Réseaux.com - 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. - 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 ? - 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 ? 2. Dans le sens Infos-Réseaux.com = OSM. - 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). - 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. 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. 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. Merci par avance pour vos lanternes. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
Attention que dans sa question, François Lacombe ne parle pas de référentiel. C'est vrai que j'ai un peu tiqué sur sa formulation de synchronisation de base de données, mais il a mis synchroniser entre guillemets, donc j'ai supposé qu'il savait pas exactement ce qu'il allait faire, donc j'ai répondu sans trop savoir aussi. Le 3 septembre 2013 18:27, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Ma marotte... vous allez trouver que je tourne un peu en rond, mais jusqu'à preuve du contraire, il ne sera pas possible de faire des synchronisations bi-directionnelles entre deux référentiels. Ceci posé, on peut préciser un peu. En fait, un référentiel le l'ai que sur un périmètre bien défini. Cela laisse une certaine liberté pour faire du mono-directionnel sur des périmètres différents. Je me permets un lien où je détaille ma pensée : http://eirl-marc.wp.sibert.fr/2013/04/16/un-referentiel-geographique/. Il faut que je poursuivre l'article en fait. En gros il te reste à toujours produire dans OSM (le référentiel), même à partir d'autres outils de génération automatique de données, et à consommer dans OSM ou dans ton application qui ne sera qu'un réplicat (enrichi c'est possible) d'OSM. Je suis aussi à la recherche de contre-exemples où ça marche histoire de voir ce que vaut ma théorie. Par ailleurs, j'ai un temps utilisé Spatialite ( http://www.gaia-gis.it/gaia-sins/) pour faire des réplicats locaux et ça fonctionne pas mal en mode mono-utilisateur / lecture seule. Les dernières versions ont encore progressé et permette l'import des données OSM. A+ Le 3 septembre 2013 13:20, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Bonjour, J'interviens sur OSM en producteur de données depuis un certain temps maintenant, j'aimerais commencer à les consommer. Je souhaiterais synchroniser une base de données perso, qui n'a rien à voir avec le formalisme OSM (elle reprend tout de même nœud, chemin, relation), avec une partie du jeu de données disponible sur les réseaux de transport et de communication. Le but est d'enrichir cette base avec des objets d'OSM, mais aussi d'enrichir OSM avec des données de cette même base. Il y a donc des échanges à prévoir dans les deux sens, en gardant un oeuil sur la quantité d'information à brasser. Il n'y a pas que des primitives compatibles avec OSM dans ma base, je ne peux donc pas la remplacer complètement. Les domaines visés sont ceux de mon site web : télécoms, énergie et eau potable. Plusieurs problématiques lourdes se présentent encore à moi : 1. Dans le sens OSM = Infos-Réseaux.com - 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. - 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 ? - 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 ? 2. Dans le sens Infos-Réseaux.com = OSM. - 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). - 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. 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. 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. Merci par avance pour vos lanternes. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Les dérives de rue : La municipalité de Saint-Étienne applaudit le théâtre emporté par le venthttp://drivrsdu.fr/la-municipalite-de-saint-etienne-applaudit-le-theatre-emporte-par-le-vent/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un peu d'aide pour du développement complexe
Merci pour vos réponse, il y a encore matière à se triturer les neurones :) Le 3 septembre 2013 13:41, Christian Quest cqu...@openstreetmap.fr a écrit : L'overpass peut sortir autre chose que du XML si besoin (json par exemple). 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. Ok c'est noté. Oui je disais xml comme format de base mais JSON sera peut-etre préféré, je n'ai pas encore fait mon choix. 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. Ça c'est intéressant. Néanmoins je vois quelques inconvénients : - 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 ? - 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 :( En exécutant obligatoirement les deux sens de cette synchro, OSM = IR.com puis IR.com = OSM on peut s'éviter d'avoir à faire une correspondance objet par objet puisqu'on charge les données actuelles OSM d'abord. Ce qui doit être publié depuis ma base est ce qui n'est pas sorti dans les données OSM. 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. En effet. Espérons que ca ne se transforme pas en prise de tête insoluble :) Le 3 septembre 2013 13:48, Ista Pouss ista...@gmail.com a écrit : Heu... si historisation veut dire historique... oui ; aucune solution technique. Il faut utiliser un système historique :-) Apparemment, chez OSM on voit l'histoire comme une sorte de propriété de plus, qu'il suffirait de rajouter. Qu'ils la rajoutent, ça fera des vacances. En fait mes versions correspondent uniquement à des modifications terrain. Je n'ai pas les moyens d'annuler une édition comme le peu le staff d'OSM, ca n'étais pas ce qui était recherché. Sur ce plan c'est incompatible oui. Créer des nouvelles versions de mon côté à chaque édition OSM serait trop lourd... tout écrire dans la même version écraserait complétement tout historique. Il va falloir choisir. Hummm Ne lis-tu pas cette liste ?... Oriente toi selon les opinions que tu as sur les débats. Si si, j'ai bien déjà lu des choses sur les identifiants d'objets métier. Pour autant j'ai pas réussi à trouver de solution abordable dans mon cas. L'idée alternative de Christian n'est pas bête, parce que ce que je recherche n'a pas tellement à voir avec une notion métier. Je suis arrivé dans la galaxie OSM au moment des hurlements suites à des imports en masse, et ça m'a traumatisé, aussi j'ai très peu avancé sur les modifs de la base par programme, j'ai l'impression que c'est mal vu par la communauté, sauf par l'intermédiaire d'un plugin Josm. Là dessus, je trouve que la communauté est sage. Certes mais j'ai pas envie de saisir deux fois la même chose. Dans ce sens je prévois vraiment de faire un truc solide et blindé pour éviter de transformer cette initiative en vandalisme. Le 3 septembre 2013 18:27, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Ma marotte... vous allez trouver que je tourne un peu en rond, mais jusqu'à preuve du contraire, il ne sera pas possible de faire des synchronisations bi-directionnelles entre deux référentiels. Non il ne s'agit pas de synchroniser les référentiels mais les données. Dans chaque sens, le traitement va s'accompagner d'un routage des tags OSM vers mes champs et de mes champs vers les tags en vigueur d'OSM (oui il faudra suivre pour les mises à jour). Le but est vraiment d'utiliser les données OSM avec mes outils et de publier ce que je connais de mon côté sur OSM. La traduction est obligatoire et plutôt bienvenue pour justement étanchéifier les deux référentiels qui ne sont pas construits pour la même chose. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
