Re: [OSM-talk-fr] [OSM-talk] Rencontre SIG Grand Besançon - OSM
Bonjour, Une question importante de la part de nos interlocuteurs était Comment se passe l'import initial dans OSM et les futures mises à jour ? J'imagine que dans une région vierge ou avec des données de mauvaise qualité, on importe tout en rasant l'existant, point barre. Dans les autres cas comment ça se passe ? Et une fois les données importées, existe-t-il un mécanisme de mise à jour ±automatique si la ville ajoute des objets dans son SIG ? J'ai regardé la doc d'Osmose mais il me semble que cet outil ne fait que de la détection d'erreur, pas d'import de données. Quels sont les outils qui ont été utilisé dans des cas similaires (en France mais aussi à l'étranger) ? Existe-t-il un format de prédilection pour exporter les données de leur SIG et l'importer dans OSM ? Merci, Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OSM-talk] Rencontre SIG Grand Besançon - OSM
Les imports sont de plus en plus rares car justement, OSM possède déjà beaucoup de données, parfois moins bonnes, parfois meilleures que celles mises à disposition que ce soit sur le côté géométrique (précision géo) que sémantique (description). Il me semble qu'on aura de moins en moins de possibilité d'imports massifs sauf sur des jeux de données totalement nouveaux (et pertinents pour OSM). Quelques exemples: - les repères géodésiques: c'est un jeu de données de référence qui a fait l'objet d'un import initial global, sa mise à jour est relativement aisée l'info étant assez unidirectionnelle - Corine Land Cover: il y avait déjà dans polygone d'occupation des sols, une part a été importée automatiquement, une part manuellement... et depuis ils sont affinés petit à petit par les contributeur. De nouvelles données d'occupation des sols deviennent disponibles, mais sont relativement complexe à intégrer... - le bâti extrait du cadastre: l'import est fait commune par commune par les contributeurs. Il impose pas mal de travail manuel pour s'intégrer aux données déjà présentes (bâti déjà tracé bien sûr, mais aussi la voirie pas forcément bien calée et qui a besoin d'être revue, etc)... il y a des ébauches d'outils pour aider à sa mise à jour mais rien de généralisé et d'aussi facilement accessible que cadastre.openstreetmap.fr - les adresses de Nantes: des outils ont été développés pour intégrer les adresses rue par rue avec un contrôle humain, ceci a permis de remonter des erreurs... à voir pour le suivi des mises à jour - les bureaux de poste, établissements scolaires, gares, etc... osmose aide à leur intégration par les contributeurs, mais ne fait pas d'import. C'est vrai que raser l'existant est souvent le plus simple techniquement, mais c'est dommage car on y perd l'historique des données et celui-ci peut être utile (pas toujours) donc si on peut éviter autant essayer. Avant d'éventuellement raser, il faut de plus récupérer les infos complémentaires qui pourraient être présentes pour les reporter sur les nouveaux objets importés... et on n'est plus très loin d'une mise à jour des objets un à un donc sans raser. Facile à écrire... moins facile à coder ;) Le 23 mai 2013 09:59, Yves Pratter yves.prat...@laposte.net a écrit : Bonjour, Une question importante de la part de nos interlocuteurs était Comment se passe l'import initial dans OSM et les futures mises à jour ? J'imagine que dans une région vierge ou avec des données de mauvaise qualité, on importe tout en rasant l'existant, point barre. Dans les autres cas comment ça se passe ? Et une fois les données importées, existe-t-il un mécanisme de mise à jour ±automatique si la ville ajoute des objets dans son SIG ? J'ai regardé la doc d'Osmose mais il me semble que cet outil ne fait que de la détection d'erreur, pas d'import de données. Quels sont les outils qui ont été utilisé dans des cas similaires (en France mais aussi à l'étranger) ? Existe-t-il un format de prédilection pour exporter les données de leur SIG et l'importer dans OSM ? Merci, Yves -- 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] [OSM-talk] Rencontre SIG Grand Besançon - OSM
Autre exemple d'import massif possible : cours d'eau de Guyane, avec rasage systématique de l'existant. -- View this message in context: http://gis.19327.n5.nabble.com/Re-OSM-talk-Rencontre-SIG-Grand-Besancon-OSM-tp5762200p5762331.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OSM-talk] Rencontre SIG Grand Besançon - OSM
Rhondoudjou, arrêtez de parler de rasage, j'en ai les cheveux qui se hérissent. Imaginez que quelqu'un rase votre travail (de bonne qualité). Et la réaction de la fourmi pas abonnée à cette liste. Aller, on rase les limites communales de l'Aisne, le département a mis à disposition les limites avec une précision à 3cm… JB. Le 23.05.2013 10:37, DBigg a écrit : Autre exemple d'import massif possible : cours d'eau de Guyane, avec rasage systématique de l'existant. -- View this message in context: http://gis.19327.n5.nabble.com/Re-OSM-talk-Rencontre-SIG-Grand-Besancon-OSM-tp5762200p5762331.html [1] Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr [2] Links: -- [1] http://gis.19327.n5.nabble.com/Re-OSM-talk-Rencontre-SIG-Grand-Besancon-OSM-tp5762200p5762331.html [2] 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] [OSM-talk] Rencontre SIG Grand Besançon - OSM
2013/5/23 JB jb...@mailoo.org: Aller, on rase les limites communales de l'Aisne, le département a mis à disposition les limites avec une précision à 3cm… Dans ce cas-là, oui, on raserait ;-) Tout dépend de la qualité des nouvelles données. Si elles sont nettement supérieures, les contributeurs doivent accepter que leurs données soient substituées par d'autres. Si elles sont équivalentes ou inférieures, il faut évidemment être beaucoup plus prudent et tout faire pour respecter le travail déjà entrepris. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OSM-talk] Rencontre SIG Grand Besançon - OSM
Bonjour, De : Pieren 2013/5/23 JB : Aller, on rase les limites communales de l'Aisne, le département a mis à disposition les limites avec une précision à 3cm… Dans ce cas-là, oui, on raserait ;-) Eh oui. C'était le sens de ma question vers Christian hier soir : autant viser dans nos chantiers de fourmis des zones où le potentiel de remplacement par des données libérées est faible. Donc typiquement on va se dépêcher de ne pas tracer les limites communales de la Somme. vincent ps. on attaque les derniers 25% du tracé des limites des communes de l'Aisne... Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OSM-talk] Rencontre SIG Grand Besançon - OSM
Je reposte sur talk-FR... Le 22 mai 2013 10:19, Vincent Pottier vpott...@gmail.com a écrit : Bonsoir, Belle rencontre hier en fin d'après midi entre trois personnes du Service cartographique du Grand Besançon et quatre OSMeurs, suivi pour les 4 d'un débriefing autours d'une bière. Il semble que la volonté d'ouvrir les données du SIG du Grand Besançon à OSM soit bien présente chez les techniciens. J'ai été surpris par la connaissance que les techniciens avaient d'OpenStreetMap : forum, wiki, association... Ils s'étaient renseignés avant notre rencontre. Eux étaient surpris par les moyens dont nous disposons : serveurs, études universitaires, outils d'édition et de contrôle qualité... Nous avons abordé les questions techniques sur les formats de données lors des échanges (système ArcGIS sur base de donnée Oracle mais transfert en Shape) L'intérêt, c'est, semble-t-il, de mettre les données à disposition du public, associatif ou particulier, et des municipalités pour décharger le service et lui permettre de se concentrer sur d'autres tâches. Nous avons évoqué les outils de publication et d'édition de données. L'intérêt, c'est de mettre en place des veilleurs locaux pour la qualité des données. Nous avons alors évoqué les outils de suivi de modifications, de contrôle qualité. La question n'est pas tellement celle de la licence : nous avons bien précisé que nous avions besoin de la licence ODBl. Mais plutôt celle du suivi des délais d'intégration et de mise à jours. - Si nous vous passons le filaire de voirie, au bout de combien de temps ces données seront intégrées à OSM ? - Ça dépend... - Mais que dire alors à l'élu qui constatera que la rue devant chez lui n'est pas présente dans OSM ? - Comme sur Wikipédia, il corrige lui-même... OpenStreetMap, ce ne sont que des bénévoles. A moins qu'un stagiaire veille à compléter le travail des bénévoles. Plusieurs thématiques ont été mentionnées : voirie, points adresse, cyclisme, randonnée - promenade, petit patrimoine, équipement urbain, transport en commun (mais on attendra la mise en place du tramway). Et, quoique nous étions plusieurs à avoir eu cela en tête, nous avons oublié de mentionner la thématique accessibilité. Pour le traitement, l'expérience de Brest Métropole Océane est une référence. Maintenant il faut attendre les élus... Puis dès qu'on aura un paquet de données test, on fera appel aux techniciens pour le calcul du différentiel, si nécessaire, pour la mise en place d'une interface pour piquer les éléments à importer (vu la densité existant déjà dans OSM, ce sera probablement une interface à la CLC qui sera à retenir mettre en place) Ceux qui étaient présent hier pourront compléter... À suivre... -- FrViPofm Nous allons avoir le même type de problème avec d'autres sources de données. Nous allons en effet avoir accès aux données brute du cadastre vectoriel dans certains départements. Ces données contiennent bien sûr le bâti et les limites administratives, mais aussi les points adresses et le filaire de voirie ainsi que quelques POI. L'intégration et la comparaison avec l'existant va donc devoir être développé d'une façon ou d'une autre, soit pour une intégration automatique soit semi automatique avec l'intervention des fourmis OSM. Si possible un tel outil ne devrait pas être trop lié à tel ou tel jeu de données libéré pour pouvoir être utilisé dans un maximum de cas qui au final sont assez similaire. Osmose a pu rendre générique l'intégration de POI ponctuels, il faudrait un équivalent pour des données linéaires ou surfaciques... -- 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] [OSM-talk] Rencontre SIG Grand Besançon - OSM
Bonsoir, Le 22/05/2013 14:02, Christian Quest a écrit : Nous allons avoir le même type de problème avec d'autres sources de données. Nous allons en effet avoir accès aux données brute du cadastre vectoriel dans certains départements. Ces données contiennent bien sûr le bâti et les limites administratives, mais aussi les points adresses et le filaire de voirie ainsi que quelques POI. Est-ce que tu peux déjà dire quels départements sont préssentis ? Question pas anodine dans le contexte des limites admins : autant consacrer nos efforts aux départements où rien ne bouge (sauf besoin avéré). L'intégration et la comparaison avec l'existant va donc devoir être développé d'une façon ou d'une autre, soit pour une intégration automatique soit semi automatique avec l'intervention des fourmis OSM. Si possible un tel outil ne devrait pas être trop lié à tel ou tel jeu de données libéré pour pouvoir être utilisé dans un maximum de cas qui au final sont assez similaire. Osmose a pu rendre générique l'intégration de POI ponctuels, il faudrait un équivalent pour des données linéaires ou surfaciques... Quand j'entends générique, je tique. Face aux jeux de données d'un nouveau producteur, il faudra se (re)poser des questions sur la qualité de ce qu'on nous propose. Que l'interface pour les fourmis OSM soit au final la même d'un producteur à l'autre pourquoi pas (c'est même souhaitable), mais en amont il faut par principe être prêt à adapter la donnée, pour la faire converger vers notre cahier des charges : un mélange de compatibilité technique (format osm, système de coordonnées, géométrie correcte) et de choix éditoriaux (quels modèle de tags pour quelles entités), le tout combiné aux particularismes liés de chaque source. De mon côté, volontiers partant pour discuter de tout ça le moment venu. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OSM-talk] Rencontre SIG Grand Besançon - OSM
Le 22 mai 2013 22:01, Vincent de Château-Thierry v...@laposte.net a écrit : Bonsoir, Le 22/05/2013 14:02, Christian Quest a écrit : Nous allons avoir le même type de problème avec d'autres sources de données. Nous allons en effet avoir accès aux données brute du cadastre vectoriel dans certains départements. Ces données contiennent bien sûr le bâti et les limites administratives, mais aussi les points adresses et le filaire de voirie ainsi que quelques POI. Est-ce que tu peux déjà dire quels départements sont préssentis ? Question pas anodine dans le contexte des limites admins : autant consacrer nos efforts aux départements où rien ne bouge (sauf besoin avéré). A très court terme, la Somme... il manque juste un dernier échange de courrier pour officialiser la mise à disposition (j'ai déjà les data EDIGEO). L'intégration et la comparaison avec l'existant va donc devoir être développé d'une façon ou d'une autre, soit pour une intégration automatique soit semi automatique avec l'intervention des fourmis OSM. Si possible un tel outil ne devrait pas être trop lié à tel ou tel jeu de données libéré pour pouvoir être utilisé dans un maximum de cas qui au final sont assez similaire. Osmose a pu rendre générique l'intégration de POI ponctuels, il faudrait un équivalent pour des données linéaires ou surfaciques... Quand j'entends générique, je tique. Face aux jeux de données d'un nouveau producteur, il faudra se (re)poser des questions sur la qualité de ce qu'on nous propose. Que l'interface pour les fourmis OSM soit au final la même d'un producteur à l'autre pourquoi pas (c'est même souhaitable), mais en amont il faut par principe être prêt à adapter la donnée, pour la faire converger vers notre cahier des charges : un mélange de compatibilité technique (format osm, système de coordonnées, géométrie correcte) et de choix éditoriaux (quels modèle de tags pour quelles entités), le tout combiné aux particularismes liés de chaque source. De mon côté, volontiers partant pour discuter de tout ça le moment venu. Quand je parle de générique, c'est plutôt de code réutilisable. Pour osmose, à chaque jeu de données, il y a une phase d'évaluation, puis de mise en forme pour faire rentrer ça dans le moule existant et c'est à ce process que je pensais, mais pour autre chose que du ponctuel. -- 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] [OSM-talk] Rencontre SIG Grand Besançon - OSM
Le 22/05/2013 22:20, Christian Quest a écrit : Quand j'entends générique, je tique. Face aux jeux de données d'un nouveau producteur, il faudra se (re)poser des questions sur la qualité de ce qu'on nous propose. Que l'interface pour les fourmis OSM soit au final la même d'un producteur à l'autre pourquoi pas (c'est même souhaitable), mais en amont il faut par principe être prêt à adapter la donnée, pour la faire converger vers notre cahier des charges : un mélange de compatibilité technique (format osm, système de coordonnées, géométrie correcte) et de choix éditoriaux (quels modèle de tags pour quelles entités), le tout combiné aux particularismes liés de chaque source. De mon côté, volontiers partant pour discuter de tout ça le moment venu. Quand je parle de générique, c'est plutôt de code réutilisable. Pour osmose, à chaque jeu de données, il y a une phase d'évaluation, puis de mise en forme pour faire rentrer ça dans le moule existant et c'est à ce process que je pensais, mais pour autre chose que du ponctuel. En fait il n'y a même pas de mise en forme. Le principe est justement de configurer toutes les spécificités (projection, encodage, tags fix, tags paramétrées...) sur la base d'un code réutilisable. Le but est d'avoir un minium d'opération à faire, et surtout le moins possible d'opération manuelle de traitement, ce qui facilite les mises à jour. Dans la plus grande partie des cas le seul traitement fait sur les données est de faire bz2 du csv, pas plus. Voilà à quoi ressemble un de ces fichiers de configuration type : https://gitorious.org/osmose/backend/blobs/master/analysers/analyser_merge_railstation_fr.py Toutes les analyses merge sont de ce type. C'est un partie de l'avant dernière section d'osmose (item=7xxx), et toute la dernière section (item=8xxx). Osmose est capable de projeter sur des way ou relations mais pas d'en importer. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [OSM-talk] Rencontre SIG Grand Besançon - OSM
Le 22/05/2013 22:01, Vincent de Château-Thierry a écrit : Bonsoir, Le 22/05/2013 14:02, Christian Quest a écrit : Nous allons avoir le même type de problème avec d'autres sources de données. Nous allons en effet avoir accès aux données brute du cadastre vectoriel dans certains départements. Ces données contiennent bien sûr le bâti et les limites administratives, mais aussi les points adresses et le filaire de voirie ainsi que quelques POI. L'intégration et la comparaison avec l'existant va donc devoir être développé d'une façon ou d'une autre, soit pour une intégration automatique soit semi automatique avec l'intervention des fourmis OSM. Si possible un tel outil ne devrait pas être trop lié à tel ou tel jeu de données libéré pour pouvoir être utilisé dans un maximum de cas qui au final sont assez similaire. Osmose a pu rendre générique l'intégration de POI ponctuels, il faudrait un équivalent pour des données linéaires ou surfaciques... Quand j'entends générique, je tique. Face aux jeux de données d'un nouveau producteur, il faudra se (re)poser des questions sur la qualité de ce qu'on nous propose. Que l'interface pour les fourmis OSM soit au final la même d'un producteur à l'autre pourquoi pas (c'est même souhaitable), mais en amont il faut par principe être prêt à adapter la donnée, pour la faire converger vers notre cahier des charges : un mélange de compatibilité technique (format osm, système de coordonnées, géométrie correcte) et de choix éditoriaux (quels modèle de tags pour quelles entités), le tout combiné aux particularismes liés de chaque source. De mon côté, volontiers partant pour discuter de tout ça le moment venu. vincent Tout à fait d'accord. Ce que j'avais en tête en causant avec le Service Carto du Grand Besançon, c'est un processus en deux temps. 1/ * Analyse * tri : éviter les doublons, les superpositions, les objets inutiles * formatage : sémantique, simplification de ways... * import en base de donnée 2/ mise à disposition sur une interface osmose (ou clc qui sert des polygones) * un layer noir blanc pour OSM existant * un layer couleur, fond transparent, pour ce qui est disponible à l'intégration * un layer vecteur cliquable Le défi est de produire un diff sur une thématique, genre bâti (building=*), et d'arriver à le visualiser selon les différents cas * L'objet existe et est identique dans OSM et dans la source = pas d'intégration * L'objet existe dans OSM et dans S, mais les tags sont différents = proposer l'intégration avec report de tags * Un objet existe dans OSM qui est fortement recouvert par un objet de S avec tags équivalents = proposer le remplacement * Un objet existe dans OSM mais pas dans S = afficher une note (besoin de mise à jour ?) * Un objet existe dans S mais pas dans OSM = proposer l'intégration Est-il possible de faire une interface unique qui présente à l'intégration des éléments de sources diverses, avec peut-être un select multiple pour les sources proposées ? Cette interface laisserait passer certains éléments et pas d'autres... On pourrait l'appeler... osmose. (la partie contrôle qualité pourrait s'appeler cosmetic) -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
