Re: [OSM-talk-fr] Encore un peu d'opendata... sur mp2013.fr
Le 9 octobre 2012 16:03, Sylvain Maillard sylvain.maill...@gmail.com a écrit : au début j'ai pensé n'avoir rien compris à ce fichier xml, mais dans l'exemple que j'ai donné le point est clairement situé dans la mer (enfin, dans le port) et non pas en pleine ville, et il doit bien y avoir 2 km de décalage ! Si c'est déjà dans le port c'est déjà dans une commune, et c'est sans soute suffisant à l'échelle du secteur couvert par eux dans leur asso. Bref ils n'ont pas eu à géolocaliser la ville, il ont fait comme sur une carte de France affiché au mur avec des punaises et ça leur suffit, ils n'ont pas été plus loin. 2 km d'écart c'est pas si mal pour la couverture locale d'une asso dont la portée est souvent bien plus grande que ça. J'en reviens donc à ma solution proposée de qualifier les points importés avec une distance maximale d'imprécision, comme si on importait non pas des points mais des cercles du rayon donné, dans lequel le point réel est localisé, pour assurer le suivi de ce qui n'a pas été rellement intégré avec une meilleure précision. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un peu d'opendata... sur mp2013.fr
Salut, pour ma part je met un gros WARNING sur ce fichier ! un géo-codage effectué par la fédération de tourisme des bouches-du-rhône c'est suspect par nature (quand on a vu ce qu'ils ont sorti sur http://data.visitprovence.com), et à première vue les quelques poi que j'ai testé ont tous une position absolument mauvaise, au mieux pas bonne ! exemple: objet 13EVT027352 La Vieille Charité cdt:SituationGeographique cdt:Latitude43.3174701/cdt:Latitude cdt:Longitude5.3599355/cdt:Longitude http://www.openstreetmap.org/?mlat=43.3174701mlon=5.3599355zoom=18layers=M Sylvain PS: ça doit être la section Il est composé d’éléments non-définitifs de l’avant-programme présenté en janvier 2012 et d’événements tests fictifs. dans le texte d'explication qui fait ça ... en tout cas je vais poser la question à Evolix si ils ont plus de détails sur le géocodage ;) 2012/10/9 Christian Quest cqu...@openstreetmap.fr Dans le cadre de Marseille-Provence 2013 - capitale européenne de la culture, un fichier en LO/OL est disponible avec des lieux géolocalisés: http://www.mp2013.fr/espace-geek/ -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Encore un peu d'opendata... sur mp2013.fr
Le 9 octobre 2012 15:19, Sylvain Maillard sylvain.maill...@gmail.com a écrit : Salut, pour ma part je met un gros WARNING sur ce fichier ! un géo-codage effectué par la fédération de tourisme des bouches-du-rhône c'est suspect par nature (quand on a vu ce qu'ils ont sorti sur http://data.visitprovence.com), et à première vue les quelques poi que j'ai testé ont tous une position absolument mauvaise, au mieux pas bonne ! Peut-être parce que leurs données ont été géocododées uniquelent pour une représentation sur une carte à une échelle limitée. L'imprécision est suffisante pour leur application et pour pouvoir discerner les points entre eux et localiser les zones que chaque POI dessert (par exemple tout un quartier). Cela n'ôte pas l'intérêt de ces données, si elles sont assez exhaustives. Mais cela veut dire qu'il faut les regéolocaliser de façon plus précise lors de l'intégration, en cherchant autour de façon plus fine. C'est le même problème d'ailleurs avec les données des bureaux de La Poste, ou des agences bancaires, ou d'autres sociétés, qui ne sont pas à 200 mètres près, ou qui se contentent de localiser un point au milieu de la bonne rue mais pas forcément au bon numéro ni du bon côté de la rue. Bref on ne les importe pas directement, on les intègre. Ce serait bien d'ailleurs que les imports de données qui contiennent des positions géolocalisées indiquent une longueur de rayon pour estimer l'erreur maximale commise dans la source. Ce qui aurait pour effet de ne pas importer des nœuds simples mais des cercles autour du point. Le tag de rayon de recherche indiquerait alors explicitement où chercher le point si on veut le positionner de façon plus précise. Et cela pourrait être suivi : en repositionnant le point plus précisément, le tag de rayon pourrait alors être enlevé manuellement. On aurait ensuite un suivi possible par des outils automatique, du travail d'intégration consistant à les repositionner précisément. Et tant que ce tag d'imprécision est présent, le nœud ne devrait pas apparaître sur aucune carte de rendu (il devrait être caché par défaut et ne serait visible que dans les éditeurs, et ne devrait même pas pouvoir être lié à d'autres objets précis ne contenant aucun objet imprécis, ou juste lié à des objets de d'imprécision équivalente). Cela permettrait de distinguer effectivement dans la base ce qui est importé (imprécis par défaut et non rendu, y compris les bâtiments, pusique le rayon d'imprécision serait même plus grand que les points de polygone du bâtiment lui-même) de ce qui est intégré. Jusqu'à même permettre d'importer des doublons qui ne gêneront pas le rendu de l'existant plus précis, et par des outils de vérifier ces doublons. Je proposerais par exemple import_precision=longueur en mètres de l'imprécision, à mettre surtout sur tous les noeuds importés (des polygones peuvent être formés dessus, mais ils n'ont pas besoin de ce tag car ils seront cachés par défaut dans les rendus puisqu'ils référencent des noeuds imprécis. A la limite un rendu pourrait malgré tout les afficher si nécessaire pour un rendu a faible niveau de zoom/échelle, où cette distance d'imprécision n'est pas perceptible et fait moins de 1 pixel (mais il resterait le risque de doublon non éliminé), ou bien les présenter effectivement juste comme des disques semi-transparents ayant ce rayon. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un peu d'opendata... sur mp2013.fr
non, là les points sont beaucoup plus loin que pour l'affichage sur une carte à grande échelle ! Sinon c'est qu'ils ont voulu positionner des points dans une ville depuis une carte au 1:100 ... au début j'ai pensé n'avoir rien compris à ce fichier xml, mais dans l'exemple que j'ai donné le point est clairement situé dans la mer (enfin, dans le port) et non pas en pleine ville, et il doit bien y avoir 2 km de décalage ! A ce point là ça n'est plus de l'affinage de position qu'il faut faire, c'est carrément la géolocalisation complète qui est à revoir ... Sylvain Le 9 octobre 2012 15:49, Philippe Verdy verd...@wanadoo.fr a écrit : Le 9 octobre 2012 15:19, Sylvain Maillard sylvain.maill...@gmail.com a écrit : Salut, pour ma part je met un gros WARNING sur ce fichier ! un géo-codage effectué par la fédération de tourisme des bouches-du-rhône c'est suspect par nature (quand on a vu ce qu'ils ont sorti sur http://data.visitprovence.com), et à première vue les quelques poi que j'ai testé ont tous une position absolument mauvaise, au mieux pas bonne ! Peut-être parce que leurs données ont été géocododées uniquelent pour une représentation sur une carte à une échelle limitée. L'imprécision est suffisante pour leur application et pour pouvoir discerner les points entre eux et localiser les zones que chaque POI dessert (par exemple tout un quartier). Cela n'ôte pas l'intérêt de ces données, si elles sont assez exhaustives. Mais cela veut dire qu'il faut les regéolocaliser de façon plus précise lors de l'intégration, en cherchant autour de façon plus fine. C'est le même problème d'ailleurs avec les données des bureaux de La Poste, ou des agences bancaires, ou d'autres sociétés, qui ne sont pas à 200 mètres près, ou qui se contentent de localiser un point au milieu de la bonne rue mais pas forcément au bon numéro ni du bon côté de la rue. Bref on ne les importe pas directement, on les intègre. Ce serait bien d'ailleurs que les imports de données qui contiennent des positions géolocalisées indiquent une longueur de rayon pour estimer l'erreur maximale commise dans la source. Ce qui aurait pour effet de ne pas importer des nœuds simples mais des cercles autour du point. Le tag de rayon de recherche indiquerait alors explicitement où chercher le point si on veut le positionner de façon plus précise. Et cela pourrait être suivi : en repositionnant le point plus précisément, le tag de rayon pourrait alors être enlevé manuellement. On aurait ensuite un suivi possible par des outils automatique, du travail d'intégration consistant à les repositionner précisément. Et tant que ce tag d'imprécision est présent, le nœud ne devrait pas apparaître sur aucune carte de rendu (il devrait être caché par défaut et ne serait visible que dans les éditeurs, et ne devrait même pas pouvoir être lié à d'autres objets précis ne contenant aucun objet imprécis, ou juste lié à des objets de d'imprécision équivalente). Cela permettrait de distinguer effectivement dans la base ce qui est importé (imprécis par défaut et non rendu, y compris les bâtiments, pusique le rayon d'imprécision serait même plus grand que les points de polygone du bâtiment lui-même) de ce qui est intégré. Jusqu'à même permettre d'importer des doublons qui ne gêneront pas le rendu de l'existant plus précis, et par des outils de vérifier ces doublons. Je proposerais par exemple import_precision=longueur en mètres de l'imprécision, à mettre surtout sur tous les noeuds importés (des polygones peuvent être formés dessus, mais ils n'ont pas besoin de ce tag car ils seront cachés par défaut dans les rendus puisqu'ils référencent des noeuds imprécis. A la limite un rendu pourrait malgré tout les afficher si nécessaire pour un rendu a faible niveau de zoom/échelle, où cette distance d'imprécision n'est pas perceptible et fait moins de 1 pixel (mais il resterait le risque de doublon non éliminé), ou bien les présenter effectivement juste comme des disques semi-transparents ayant ce rayon. ___ 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] Encore un peu d'opendata... sur mp2013.fr
Je n'ai pas regardé le contenu du fichier, mon message avait juste pour but de signaler son existence... Il est peut être exploitable pour certains croisements d'infos, pour compléter des POI existants ou futurs, mais visiblement pas importable en l'état (comme dans la majorité des cas). -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
