Re: [OSM-talk-fr] Sourcer les limites administratives
Le Wed 02 Jun 2010 à 17:46 +0200, sly (sylvain letuffe) a ecrit : On mercredi 2 juin 2010, Pieren wrote: Je ne pensais pas que certaines limites seraient dérivées de tracés GPS, il doit y en avoir assez peu. Juste pour dire que le cadastre en montagne, au niveau des limites, c'est pas extraordinaire parfois. Et, quand j'ai la chance de pouvoir parcourir l'élément géographique qui fait la limite (Une crête montagneuse, où cassure de pente), ben je la complète avec un source=gps Tiens ! en septembre dernier j'avais proposé d'ajouter un tag natural=edge pour les lignes de crête, en précisant que l'une des utilités pouvait être celle-là. Allez, tant pis, je me cite : (http://www.mail-archive.com/talk-fr@openstreetmap.org/msg13951.html) - souvent, des limites administratives (communes, pays) sont alignées sur des lignes de crête. Il peut être particulièrement intéressant de savoir où les limites administratives suivent la ligne de crête et où elles en dévient. Je reviens donc à la charge ;-). Un tel tag ridge (+ source=gps) permettrait d'expliquer par exemple pourquoi une limite communale diverge du cadastre, et d'indiquer que c'est normal. -- ° /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
Le mercredi 2 juin 2010 17:20:27 Emilie Laffray, vous avez écrit : Même pour les traces GPS, on ne peut pas se fier autre mesure a ce qu'on obtient. Si tu veux vraiment quelque chose qui soit plus utile, doit on enregistrer aussi les données comme les différents DOP, la position des satellites dans le ciel, les alentours (pour savoir si le multipath est important ou pas), sa vitesse (histoire d'avoir une meilleure idée de l'effet Doppler), le firmware du GPS, la version de la puce? Ce sont autant de facteurs qui peuvent jouer sur la qualité d'une trace GPS sans parler que ces paramètres changent a travers le temps. Mais peut-être que ça aurait son intérêt même si on n'a pas tout de suite les outils pour exploiter de tels données. Pour revenir au cadastre, des fois je me dis que le niveau de zoom dans josm au moment d'ajouter un point à partir du cadastre pourrait aussi être un indicateur de qualité. Pour ma part, je n'attache pas la même importance lorsque je trace une voie urbaine que lorsque je trace une limite administrative perdu en cambrousse. Dans le premier cas, je m'attache à bien tomber par rapport aux repères (bâti, voirie, notes), dans le second je suis les grandes lignes de plus haut … Bon après, on me dira que le zoom ne suffit pas, il faut aussi des infos sur l'écran, la précision de la souris, et l'état de la vue du mappeur :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
Le Thu 03 Jun 2010 à 09:03 +0200, Guillaume Allegre a ecrit : Le Wed 02 Jun 2010 à 17:46 +0200, sly (sylvain letuffe) a ecrit : Juste pour dire que le cadastre en montagne, au niveau des limites, c'est pas extraordinaire parfois. Et, quand j'ai la chance de pouvoir parcourir l'élément géographique qui fait la limite (Une crête montagneuse, où cassure de pente), ben je la complète avec un source=gps Tiens ! en septembre dernier j'avais proposé d'ajouter un tag natural=edge pour les oups ! natural=ridge pardon -- ° /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
On jeudi 3 juin 2010, Guillaume Allegre wrote: Tiens ! en septembre dernier j'avais proposé d'ajouter un tag natural=edge pour les Je me souviens de cette proposition, et je n'avais pas réagi car je n'étais pas vraiment convaincu de l'utilité de noter les talweg et les crêtes. ça me semble max de boulot, pour que soit noté finalement un peu tout dedans, et je pense que cette donnée est/devrait/sera disponible par quelque chose de plus automatique : les MNE/MNT -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
On mercredi 2 juin 2010, Denis wrote: pourtant elle (la donnée) acquiert de la qualité parce que ses limites et utilisations sont clairement définies. Je suis tout à fait d'accord Une donnée moyenne bien documentée vaut plus qu'une donnée pointue mais mal ou pas documentée. Je ne suis pas d'accord Loin de moi de trouver le moindre défaut au fait de sourcer (puisque c'est le barbarisme en cours d'utilisation) les données, je le fais, et je recommande de le faire. Mais je ne suis pas d'accord avec cette affirmation un peu rapide. Comme dirait un vieux pote à moi : Tout est relatif - relatif à l'utilisation qu'on veut en faire. Beaucoup des cas que tu as présenté sont des cas d'utilisation par des professionnels, qui veulent des normes, des mesures, des marges d'erreurs, etc. En tant que contributeurs, et utilisateur amateurs, ce n'est pas toujours ce que je recherche. Allons y pour les phrases choc : (En randonnée en montagne avec un GPS) : Je préfère largement ne pas savoir que je ne suis pas perdu, que parfaitement savoir que je suis perdu - cas 1: le tracé gps du sentier que je suis est très précis, mais je ne le sais pas, mais je suis au bon endroit - cas 2: le tracé gps du sentier n'est pas précis, mais je le sais, et donc je suis perdu -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
Le jeudi 03 juin 2010 à 09:56 +0200, sly (sylvain letuffe) a écrit : On jeudi 3 juin 2010, Guillaume Allegre wrote: Tiens ! en septembre dernier j'avais proposé d'ajouter un tag natural=edge pour les Je me souviens de cette proposition, et je n'avais pas réagi car je n'étais pas vraiment convaincu de l'utilité de noter les talweg et les crêtes. Les talwegs sont à 95% déjà dans OSM puisque cela correspond quasiment au réseau hydrographique. Les crêtes peuvent être intéressante selon les cas et en particulier sur une carte sans courbe de niveau mais seront confondus généralement avec une route, un chemin ou une limite administratives. Savoir que l'on a affaire à une crête est aussi une info touristique intéressante si on cherche des beaux points de vue... ça me semble max de boulot, pour que soit noté finalement un peu tout dedans, et je pense que cette donnée est/devrait/sera disponible par quelque chose de plus automatique : les MNE/MNT Librement, ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
Le jeudi 03 juin 2010 à 10:07 +0200, sly (sylvain letuffe) a écrit : On mercredi 2 juin 2010, Denis wrote: pourtant elle (la donnée) acquiert de la qualité parce que ses limites et utilisations sont clairement définies. Je suis tout à fait d'accord Une donnée moyenne bien documentée vaut plus qu'une donnée pointue mais mal ou pas documentée. Je ne suis pas d'accord Loin de moi de trouver le moindre défaut au fait de sourcer (puisque c'est le barbarisme en cours d'utilisation) les données, je le fais, et je recommande de le faire. Mais je ne suis pas d'accord avec cette affirmation un peu rapide. Comme dirait un vieux pote à moi : Tout est relatif - relatif à l'utilisation qu'on veut en faire. Beaucoup des cas que tu as présenté sont des cas d'utilisation par des professionnels, qui veulent des normes, des mesures, des marges d'erreurs, etc. En tant que contributeurs, et utilisateur amateurs, ce n'est pas toujours ce que je recherche. Allons y pour les phrases choc : (En randonnée en montagne avec un GPS) : Je préfère largement ne pas savoir que je ne suis pas perdu, que parfaitement savoir que je suis perdu - cas 1: le tracé gps du sentier que je suis est très précis, mais je ne le sais pas, mais je suis au bon endroit - cas 2: le tracé gps du sentier n'est pas précis, mais je le sais, et donc je suis perdu Qu'est ce que la précision, et quel est le besoin d'OSM. Une précision à 10m, voire 100m ne me perturbe pas plus que ça dans OSM. La précision ne pouvant qu'évoluer dans le temps avec l'augmentation de la densité d'information. Par contre une précision à 5km voire plus d'une personne qui positionne pifométriquement des sommets de montagnes me pose un plus gros problème de confiance envers la qualité des données d'OSM. L'arrivée des points géodésiques m'a permis de corriger beaucoup de déviation... Chipoter sur une précision à 2cm me parait par contre complètement contre productif. Sourcer n'est d'aucun intérêt si on ne connait pas la précision de la source et on ne connait pas la précision absolu d'un GPS ou du cadastre qui confronté au terrain montre tout autant une extrême précision que des décalage abyssaux ! J'ai par ailleurs constaté que la précision du cadastre évoluait avec les révisions, et donc la seul mention cadastre n'est pas suffisante. De même que les limites administratives semble parfois être modifié avec l'urbanisation (modification du cours d'une rivière, nouveau tracé routier...) Librement, ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
Le Thu 03 Jun 2010 à 09:56 +0200, sly (sylvain letuffe) a ecrit : On jeudi 3 juin 2010, Guillaume Allegre wrote: Tiens ! en septembre dernier j'avais proposé d'ajouter un tag natural=edge pour les Je me souviens de cette proposition, et je n'avais pas réagi car je n'étais pas vraiment convaincu de l'utilité de noter les talweg et les crêtes. J'ai l'impression qu'on refait le même débat, alors je vais certainement refaire les mêmes réponses, désolé. Pour référence : http://www.mail-archive.com/talk-fr@openstreetmap.org/msg13951.html ça me semble max de boulot, pour que soit noté finalement un peu tout dedans, je ne comprends pas très bien un peu tout dedans max de boulot : tu parles de mener la proposition de tag ? Ou de s'occuper du balisage effectif à partir des traces GPS ? et je pense que cette donnée est/devrait/sera disponible par quelque chose de plus automatique : les MNE/MNT devrait je suis d'accord, mais on est très très loin d'avoir des donées MNT libres qui donneraient une précision équivalente à un relevé terrain (sauf contre-exemple). D'ailleurs, on a déjà natural=cliff, qui rentre dans le même cadre. Et sinon, je te concède que l'intérêt de talweg peut paraître plus faible que celui de ridge, mais : - c'est le symétrique de ridge, donc autant traiter les deux en même temps - pour l'emplacement des ruisseaux temporaires, tant qu'on n'a rien de clair dans waterway, c'est une bonne indication -- ° /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives - crêtes et talweg
On jeudi 3 juin 2010, Guillaume Allegre wrote: J'ai l'impression qu'on refait le même débat, alors je vais certainement refaire les mêmes réponses, désolé. Pour référence : http://www.mail-archive.com/talk-fr@openstreetmap.org/msg13951.html Ha oui tiens, marrant ça, j'ai répondu à peu de chose prêt ce que j'avais déjà répondu à l'époque, non je ne suis pas un robot, je suis un être humain ! Donc, je pense avoir plus ou moins déjà dis ce que je pensais, c'est à dire pas grand chose, je ne voudrais pas te faire perdre plus ton temps avec moi, certains seront sans doute moins rétifs que je ne le suis et plus ouvert à en débattre. je ne comprends pas très bien un peu tout dedans Oui, je ne n'arrive pas trop à formuler ce qui me gêne, des crêtes il y en a des tas de partout, certaines sont très visibles, d'autres son anodines, si je m'imagine en rentrer disons 10 (de plus de 500m, avec point de vue, etc.) qu'un autre en rentre 100 (de moins de 100m, bordant le moindre ruisseau) à la fin, utiliser cette donnée deviens difficile. max de boulot : tu parles de mener la proposition de tag ? non, tagguer. Je sais que je ne suis pas clair, que mon avis n'est pas très compréhensible, que mes arguments ne valent pas grand chose, que je me base sur un feeling, mais, pas d'inquiétudes, je ne voterais ni pour ni contre, bien au contraire. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives - crêtes et talweg
Le Thu 03 Jun 2010 à 10:47 +0200, sly (sylvain letuffe) a ecrit : max de boulot : tu parles de mener la proposition de tag ? non, tagguer. Dans ce cas la réponse est simple : l'existence d'un tag officiel ne nous oblige à rien. Par contre, on l'a a disposition le jour où on en a besoin. S'il y a un chemin de crête déjà balisé (path ou footway), ajouter un tag natural=ridge ne coûte rien. Pareil s'il y a une limite de commune correcte = qui corresponde raisonnablement aux relevés GPS, dans les zones où le cadastre n'est pas fiable. Je sais que je ne suis pas clair, que mon avis n'est pas très compréhensible, que mes arguments ne valent pas grand chose, que je me base sur un feeling, mais, pas d'inquiétudes, je ne voterais ni pour ni contre, bien au contraire. Merci ;-) -- ° /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
2010/6/3 Christophe Merlet red...@redfoxcenter.org Sourcer n'est d'aucun intérêt si on ne connait pas la précision de la source et on ne connait pas la précision absolu d'un GPS ou du cadastre qui confronté au terrain montre tout autant une extrême précision que des décalage abyssaux ! J'ai par ailleurs constaté que la précision du cadastre évoluait avec les révisions, et donc la seul mention cadastre n'est pas suffisante. C'est bien pour ça que le millésime a aussi son importance. Et la précision du cadastre peut être reconstituée à postériorie (pour les fanatiques de la précision) alors qu'on ne pourra pas le faire avec une source GPS. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
et je pense que cette donnée est/devrait/sera disponible par quelque chose de plus automatique : les MNE/MNT L'expérience de ceux qui bossent en hydrographie montre que les MNT ne sont pas une bonne source pour la détermination des lignes de crêtes (et des bassisn versants correspondants). Ils doivent en général redéfinir manuellement les lignes de crêtes pour avoir des résultats pertinents. Donc, il ne serait pas totalement aberrant de les tracer manuellement dans OSM... mais j'ai d'autres priorités en ce qui me concerne :-p Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
Le 30/05/2010 17:34, Pieren a écrit : Etienne, ça serait pas mal si Osmose pouvait aussi signaler les limites administratives non sourcées. http://osmose.openstreetmap.fr/map/cgi-bin/index.py?source=43-707 Je ne met que les ways n'ayant pas de source. C'est pas encore sur l'interface principale, j'attends vos commentaires et remarques avant de l'inclure. -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
2010/6/2 Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net Pas mal. Ça met en évidence les bouts de limites qui sont des routes et qui ont été saisis à partir de traces GPS et qui n'ont pas reçu le tag source=survey. Hmmm. 1. Je ne suis pas sûr que le GPS soit une source plus fiable que le cadastre (les deux ont des inconvénients maintes fois cités ici) 2. Comment savoir si le tracé de la route vient du cadastre ou d'un GPS ? Si on est pas l'auteur, on ne peut vérifier qu'en superposant cadastre et données OSM, tâche bien difficile à automatiser. Et que faire en cas d'écarts importants puisqu'on ne connait pas non plus la qualité du tracé GPS. Ne devrait-on pas forcer au niveau des deux principaux éditeurs la saisie du tag source pour tout ajout de données ? Ah non, surtout pas 'forcer'. JOSM veut aussi 'forcer' les commentaires de changeset. A vouloir 'forcer' trop de choses, c'est les contributeurs qui iront voir ailleurs. (mais d'accord pour suggérer, inciter) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
2010/6/2 Pieren pier...@gmail.com 2010/6/2 Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net Pas mal. Ça met en évidence les bouts de limites qui sont des routes et qui ont été saisis à partir de traces GPS et qui n'ont pas reçu le tag source=survey. Hmmm. 1. Je ne suis pas sûr que le GPS soit une source plus fiable que le cadastre (les deux ont des inconvénients maintes fois cités ici) 2. Comment savoir si le tracé de la route vient du cadastre ou d'un GPS ? Si on est pas l'auteur, on ne peut vérifier qu'en superposant cadastre et données OSM, tâche bien difficile à automatiser. Et que faire en cas d'écarts importants puisqu'on ne connait pas non plus la qualité du tracé GPS. +1 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
On mercredi 2 juin 2010, Emilie Laffray wrote: +1 ;-) +1 -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
Le mercredi 2 juin 2010 16:32:42 Pieren, vous avez écrit : Hmmm. 1. Je ne suis pas sûr que le GPS soit une source plus fiable que le cadastre (les deux ont des inconvénients maintes fois cités ici) 2. Comment savoir si le tracé de la route vient du cadastre ou d'un GPS ? Si on est pas l'auteur, on ne peut vérifier qu'en superposant cadastre et données OSM, tâche bien difficile à automatiser. Et que faire en cas d'écarts importants puisqu'on ne connait pas non plus la qualité du tracé GPS. Oui, je suis d'accord. Justement, je trouve aussi que ce n'est pas raisonnable d'évaluer la source a posteriori à moins de contacter l'auteur et encore. D'où l'idée de « forcer » un peu plus le sourçage a priori. Bon, c'est déjà bien qu'on ait un sourçage automatique pour le cadastre, mais bon pour le reste savoir si une donnée est sourcée comme survey, knowledge, historical, voice ou image donne un indice qualitatif non négligeable. En l'occurence, pour les erreurs détecté par osmose, je pense que le mieux est de reprendre le cadastre ajuster ou vérifier et sourcer « cadastre ». Après, je pense que ça rejoint la question de qualité des données, car le sourçage tel qu'il est pratiqué pour l'instant n'est peut-être pas suffisant … -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
2010/6/2 Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net Oui, je suis d'accord. Justement, je trouve aussi que ce n'est pas raisonnable d'évaluer la source a posteriori à moins de contacter l'auteur et encore. D'où l'idée de « forcer » un peu plus le sourçage a priori. Bon, c'est déjà bien qu'on ait un sourçage automatique pour le cadastre, mais bon pour le reste savoir si une donnée est sourcée comme survey, knowledge, historical, voice ou image donne un indice qualitatif non négligeable. En l'occurence, pour les erreurs détecté par osmose, je pense que le mieux est de reprendre le cadastre ajuster ou vérifier et sourcer « cadastre ». Après, je pense que ça rejoint la question de qualité des données, car le sourçage tel qu'il est pratiqué pour l'instant n'est peut-être pas suffisant … Je pense que le sourçage est important mais qu'on n'aurait jamais un sourçage qui équivaudra aux méta données du monde de la geomatique. Comment fait on quand on a le premier point crée en utilisant Yahoo, puis modifie avec une trace GPS maison et en superposition avec le cadastre? Doit on mettre source=Yahoo;GPS;Cadastre? Je ne suis pas sure que ça aide beaucoup et que ça aide a l'évaluation de la qualité. Maintenant on peut parler des sources auxquelles on a accès comme le cadastre qui est une source fantastique pour tracer. Est ce que mettre source=cadastre indique vraiment la qualité des données? Après tout, il y a une bonne part d'interprétation puisqu'il n'y a pas de données vectorielles pour les routes. Maintenant pour un bâtiment, la source=cadastre veut vraiment dire quelque chose, pour une route, nettement moins puisque la qualité du cadastre n'est pas homogène, et que ça dépend beaucoup de l'utilisateur qui fait l'interprétation. De plus dans mon cas, je vérifie toujours quand j'ajoute une roue d'après le cadastre que ça corresponde a peu près aux images Yahoo. Mettre source quand on peut oui, inciter a l'utilisation, je ne suis pas convaincue que ça aide vraiment au débat sur la qualité des données en règle générale. Même pour les traces GPS, on ne peut pas se fier autre mesure a ce qu'on obtient. Si tu veux vraiment quelque chose qui soit plus utile, doit on enregistrer aussi les données comme les différents DOP, la position des satellites dans le ciel, les alentours (pour savoir si le multipath est important ou pas), sa vitesse (histoire d'avoir une meilleure idée de l'effet Doppler), le firmware du GPS, la version de la puce? Ce sont autant de facteurs qui peuvent jouer sur la qualité d'une trace GPS sans parler que ces paramètres changent a travers le temps. Je pense que le débat de la qualité des données se résoudra d'une autre manière a terme, mais a mes yeux, source n'est qu'une petite partie de ce débat surtout quand on a une source hybride au final. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
2010/6/2 Emilie Laffray emilie.laff...@gmail.com Pour revenir à la question de départ, mon postulat était que toutes les limites administratives étaient dérivées du cadastre avec lequel nous avons une obligation légale de citer la source (en dehors des limites cartographes associés qui devraient disparaitre à terme). Je ne pensais pas que certaines limites seraient dérivées de tracés GPS, il doit y en avoir assez peu. J'ai demandé une interface Osmose surtout pour nous aider à respecter la clause légale de la DGFiP. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
On mercredi 2 juin 2010, Pieren wrote: Je ne pensais pas que certaines limites seraient dérivées de tracés GPS, il doit y en avoir assez peu. Juste pour dire que le cadastre en montagne, au niveau des limites, c'est pas extraordinaire parfois. Et, quand j'ai la chance de pouvoir parcourir l'élément géographique qui fait la limite (Une crête montagneuse, où cassure de pente), ben je la complète avec un source=gps Bref, ne lançez pas un robot qui va mettre source=cadastre à toutes les frontières ;-) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
Le mercredi 2 juin 2010 17:20:27 Emilie Laffray, vous avez écrit : Je pense que le sourçage est important mais qu'on n'aurait jamais un sourçage qui équivaudra aux méta données du monde de la geomatique. Comment fait on quand on a le premier point crée en utilisant Yahoo, puis modifie avec une trace GPS maison et en superposition avec le cadastre? Doit on mettre source=Yahoo;GPS;Cadastre? Je ne suis pas sure que ça aide beaucoup et que ça aide a l'évaluation de la qualité. Je suis bien d'accord que l'unique tag source est insuffisant. Loin de moi la prétention d'apporter une solution, mais justement ces points me questionne quand à l'évaluation et à la vérification des données. Si j'ai une donnée sourcée comme cadastre qui me semble fausse, je peux aller vérifier d'où vient l'erreur. Après si le cadastre a été mélangé à d'autres sources (survey, knowledge), on ne peut effectivement plus vraiment opposer la donnée à une source. La solution serait d'avoir un système de métadonnée plus poussée pour tracer les modifications, mais bon là je ne suis effectivement pas trop au courant de ce qui se fait ailleurs. En conclusion, ça ne m'inquiète pas outre mesure, je me pose juste des questions :-) C'est que c'est intéressant tout ça, d'autant qu'au boulot j'essaie de développer des outils de traçabilité d'expérimentations numériques (calcul) collaboratives. Bonne soirée -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
+1 pour le cadastre en (haute-)montagne où le gars a tracé une ligne droite à la louche depuis la vallée et qui ne suit absolument pas la ligne de crête délimitant les communnes. Pas gênant pour le cadastre vu qu'il n'y pas de parcelle. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
2010/6/2 sly (sylvain letuffe) sylv...@letuffe.org ben je la complète avec un source=gps Bref, ne lançez pas un robot qui va mettre source=cadastre à toutes les frontières ;-) Justement, on ne parle ici que des boundaries non sourcés. L'avantage de la carte Osmose, c'est qu'on voit immédiatement que le tag source manque la plupart du temps sur toute la commune ou même un groupe de communes. Pour ceux-là, on est à peu près sûr que ça vient du cadastre et que c'est un oubli de l'auteur (sauf si vous connaissez quelqu'un qui a fait le tour de sa commune à pied, GPS à la main, en suivant les chemins, ruisseaux, bornes de parcelles et crêtes de montagne qui font la limite - notez que ça peut être un challenge intéressant) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
Le 02. 06. 10 16:51, sly (sylvain letuffe) [via GIS] a écrit : On mercredi 2 juin 2010, Emilie Laffray wrote: +1 ;-) +1 = 2 ;-) begin:vcard fn;quoted-printable:St=C3=A9phane Brunner n;quoted-printable:Brunner;St=C3=A9phane adr:;;Suisse email;internet:courr...@stephane-brunner.ch x-mozilla-html:FALSE url:http://stephane-brunner.ch version:2.1 end:vcard -- View this message in context: http://gis.638310.n2.nabble.com/Sourcer-les-limites-administratives-tp5118942p5132030.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] Sourcer les limites administratives
Emilie Laffray a écrit : Je pense que le sourçage est important mais qu'on n'aurait jamais un sourçage qui équivaudra aux méta données du monde de la geomatique. Le sourcage fait partie des métadonnées des données géolocalisées, selon l'ISO 19115 (et autres normes annexes). J'aurai plutôt tendance à dire qu'OSM est un poil plus loin que beaucoup d'acteurs de la géomatique classique. En effet, nous parlons de sourcage au niveau objet tandis que le monde de la géomatique raisonne en terme de lot de données. Ainsi, on pourrait imaginer un lot limites administratives issu de la base OSM dont le texte descriptif de la provenance pourrait être libellé ainsi : Digitalisation à partir des données cadastrales pour l'essentiel du lot. Par endroits, des corrections peuvent avoir été effectuées par repérage GPS ou par conflation avec des informations issues d'autres lots de données (réseau routier, réseau hydrographique). Même le sourcage, au niveau objet, tel que pratiqué par l'IGN dans sa BD, Topo, ne renseigne pas beaucoup l'utilisateur final quand c'est indiqué : précédente version de la BD Topo (exemple pris dans le monde réel ;-) Comment fait on quand on a le premier point crée en utilisant Yahoo, puis modifie avec une trace GPS maison et en superposition avec le cadastre? Doit on mettre source=Yahoo;GPS;Cadastre? Je ne suis pas sure que ça aide beaucoup et que ça aide a l'évaluation de la qualité. Un sourcage au niveau point ne me parait pas indispensable car, au ,final, ce n'est qu'un couple (ou un triplet) de coordonnées géographiques. L'important c'est l'objet qu'il constitue. La qualité géométrique n'est qu'une composante, parmi beaucoup d'autres de l'analyse de la qualité d'une donnée (exhaustivité, précision temporelle, respect d'une sémantique, etc.) Bien évidemment, les POI sont à la fois des points et des objets. Il ne faut pas oublier que l'historique disponible des objets constitue un système de métadonnées en lui-même (processus de constitution de la donnée). Certes, il y a des applications à développer pour rendre cette information plus utilisable (genre osmdiff), mais l'info de base est déjà stockée. Maintenant on peut parler des sources auxquelles on a accès comme le cadastre qui est une source fantastique pour tracer. Est ce que mettre source=cadastre indique vraiment la qualité des données? Après tout, il y a une bonne part d'interprétation puisqu'il n'y a pas de données vectorielles pour les routes. Maintenant pour un bâtiment, la source=cadastre veut vraiment dire quelque chose, pour une route, , nettement moins puisque la qualité du cadastre n'est pas homogène, et que ça dépend beaucoup de l'utilisateur qui fait l'interprétation. De plus dans mon cas, je vérifie toujours quand j'ajoute une roue d'après le cadastre que ça corresponde a peu près aux images Yahoo. A mon avis, il ne faut pas confondre qualité et qualité. Je m'explique : Des limites de PNR digitalisées sur fond de scan25 peuvent être d'une qualité suffisante pour beaucoup d'utilisateurs aux conditions que : 1. la source de création doit identifiée 2. les seuils de tolérance soient explicités (longueur minimale d'un tronçons de x m) 3. la plage d'échelles d'utilisation de la donnée soit indiquée etc. Bref, la donnée peut être d'une qualité 'absolue' pas terrible ; pourtant elle acquiert de la qualité parce que ses limites et utilisations sont clairement définies. C'est l'objectif de la directive INSPIRE D'un autre côté on peut avoir des objets parfaitement positionnés mais sans le minimum de documentation, la qualité géométrique, même l'exhaustivité, la conformité aux critères de définition seront inutiles s'ils restent implicites. Une donnée moyenne bien documentée vaut plus qu'une donnée pointue mais mal ou pas documentée. Mettre qu'une route a été digitalisée à partir du cadastre ne veut pas dire qu'elle sera plus juste qu'une autre version réalisée à partir de traces GPS. L'utilisateur, en revanche, s'il veut estimer plus finement la qualité géométrique de la donnée, ira consulter les planches concernées dans le premier cas ; dans le second cas il saura qu'en milieu urbain, le niveau de précision peut chuter. Mettre source quand on peut oui, inciter a l'utilisation, je ne suis pas convaincue que ça aide vraiment au débat sur la qualité des données en règle générale. Ne pas mettre de source à un objet équivaut à jeter une ombre sur sa provenance. Même si ce n'est pas toujours facile mais mieux vaut faire maladroitement que pas du tout. Même pour les traces GPS, on ne peut pas se fier autre mesure a ce qu'on obtient. Si tu veux vraiment quelque chose qui soit plus utile, doit on enregistrer aussi les données comme les différents DOP, la position des satellites dans le ciel, les alentours (pour savoir si le multipath est important ou pas), sa vitesse (histoire d'avoir une meilleure idée de l'effet Doppler), le firmware du GPS, la
Re: [OSM-talk-fr] Sourcer les limites administratives
Le 02/06/2010 20:58, Denis a écrit : ... Intéressant... On apprend des choses sur cette liste... C'est dans le wiki, ça ? Digitalisation à partir des données cadastrales pour l'essentiel du lot. Par endroits, des corrections peuvent avoir été effectuées par repérage GPS ou par conflation avec des informations issues d'autres lots de données (réseau routier, réseau hydrographique). C'est peut-être une métadonnée qui peut être codée source='cadastre + GPS + ...' avec explicitation dans un tableau du wiki. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sourcer les limites administratives
Le 02/06/2010 16:32, Pieren a écrit : Ah non, surtout pas 'forcer'. JOSM veut aussi 'forcer' les commentaires de changeset. A vouloir 'forcer' trop de choses, c'est les contributeurs qui iront voir ailleurs. (mais d'accord pour suggérer, inciter) ...mais une option débrayable (ou embrayable pour les gens consciencieux), comme il existe l'option genre rappel d'ajout de commentaire dans mediawiki, c'est jouable. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Sourcer les limites administratives
Bonjour, Juste une note en passant : j'ai remarqué que récemment quelqu'un avait importé de nombreuses limites communales sans les sourcer. Il est important d'ajouter l'origine de cette donnée et de suivre le guide: http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives Etienne, ça serait pas mal si Osmose pouvait aussi signaler les limites administratives non sourcées. Bon mapping à tous, Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
