Re: [OSM-talk-fr] Tag layer et Osmose
En second élément pour ne pas mettre de layer sur l'objet traversé c'est que mettre un tag layer sur une rivière ou sur un long segment peut aussi créer des erreurs en dehors de la zone d'édition à quelques kilomètres. Exemple classique : la voie ferrée qui peut passer une fois au dessus, une fois en dessous. Le 5 déc. 2013 08:58, Christian Quest cqu...@openstreetmap.fr a écrit : layer=* est utilisé par les moteurs de rendu pour aider à déterminer l'ordre de dessin. Une absence de tag layer équivaut à layer=0, ce qui fait qu'au final layer=0 n'a pas vraiment d'utilité et est donc rather unusual (il y en a quand même plus de 230 000 d'après taginfo). Le 5 décembre 2013 00:48, Simon Miniou simon.min...@gmail.com a écrit : Bonjour, en essayant de corriger les erreurs osmose avec le message *Manque le tag layer aux alentours du pont* j'ai pris l'habitude de mettre la rivière ou la route en layer=0 et le pont en layer=1 (ou 1 et 2 si plusieurs croisement) Dernièrement, j'ai été contacté par un utilisateur concernant mes modifications sur le tag layer et me retourne vers vous pour savoir qu'est ce qu'il faut utiliser? si je vais dans la bonne direction ou me trompe complétement? j'ai pas trouvé d'exemples sur le wiki. la personne avec qui je suis en contact me demande : normally the bridge would be layer=1 and the river without any tags? qu'en est il réellement? autre échange toujours en anglais : I was wondering for example about this: http://www.openstreetmap.org/way/244371711 layer=1 without a bridge or layer=-1 without a tunnel is very frequently an error which is why it caught my attention. Another thing: http://www.openstreetmap.org/way/71175201 - it is not an error to add layer=0 but rather unusual. Merci de vos lumières, Simon ps: par rapport à Osmose, sur le territoire italien, une erreur reporté le 01/11/2013 qui a été corrigé 1 moi avant c'est normal? ( http://www.openstreetmap.org/node/2476544745 -- http://osmose.openstreetmap.fr/fr/map/?username=RicoZzoom=18lat=46.20995lon=10.75401layers=B00FFTitem=level=1 ) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] POI OSM extraits par OpenDataSoft...
Le mercredi 4 décembre 2013 22:52:55 Christian Quest a écrit : OpenDatasoft propose des API et différents services de téléchargement pour publier des données opendata. Ils ont repris les POI OSM amenity=* et mis ça en forme sur leur plateforme qui permet de les explorer de différentes façons (tableaux, carte, analses, API, download, etc). Très amusant en effet :-) On peut voir le classement des contributeurs qui ont ajouté le plus d'amenity=restaurant et source=survey (il manque le source=taste_survey ;-) ) Je suis impatient de voir les utilisations et les évolutions de ce service :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag layer et Osmose
2013/12/5 Christian Quest cqu...@openstreetmap.fr: layer=* est utilisé par les moteurs de rendu pour aider à déterminer l'ordre de dessin. Le tag layer n'est utile que sur des lignes (ways) décrivant un élément physique se croisent sans avoir de noeuds en commun (route sur route, route sur rivière, rivière sur rivière, etc). Il détermine l'ordre d'empilement de lignes qui se croisent. C'est surtout utile pour le dessin/rendu mais ça peut servir aussi à savoir si un point sur l'intersection est nécessaire ou pas (info sur la topologie). En principe, deux lignes sur le même layer (niveau) doivent avoir un noeud commun d'intersection. J'en parle ici parce que je tombe souvent sur des cycleways qui croisent des highways sans noeud d'intersection. A l'inverse, deux lignes qui se croisent mais qui ne sont pas sur le même niveau (avec des layer différents) ne doivent pas avoir de noeuds d'intersection en commun. Une absence de tag layer équivaut à layer=0, ce qui fait qu'au final layer=0 n'a pas vraiment d'utilité et est donc rather unusual (il y en a quand même plus de 230 000 d'après taginfo). +1 layer=0 est rather useless (inutile) et j'en efface assez régulièrement. Tous les objets qui n'ont pas de tag layer sont en layer=0. Et il y a en beaucoup plus sans tag layer qu'avec layer=0 ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag layer et Osmose
Le tag layer n'est utile que sur des lignes (ways) décrivant un élément physique se croisent sans avoir de noeuds en commun (route sur route, route sur rivière, *rivière sur rivière*, etc). Euh... Faudra m'expliquer, là ! ^_^ Francescu Le 5 décembre 2013 10:17, Pieren pier...@gmail.com a écrit : 2013/12/5 Christian Quest cqu...@openstreetmap.fr: layer=* est utilisé par les moteurs de rendu pour aider à déterminer l'ordre de dessin. Le tag layer n'est utile que sur des lignes (ways) décrivant un élément physique se croisent sans avoir de noeuds en commun (route sur route, route sur rivière, rivière sur rivière, etc). Il détermine l'ordre d'empilement de lignes qui se croisent. C'est surtout utile pour le dessin/rendu mais ça peut servir aussi à savoir si un point sur l'intersection est nécessaire ou pas (info sur la topologie). En principe, deux lignes sur le même layer (niveau) doivent avoir un noeud commun d'intersection. J'en parle ici parce que je tombe souvent sur des cycleways qui croisent des highways sans noeud d'intersection. A l'inverse, deux lignes qui se croisent mais qui ne sont pas sur le même niveau (avec des layer différents) ne doivent pas avoir de noeuds d'intersection en commun. Une absence de tag layer équivaut à layer=0, ce qui fait qu'au final layer=0 n'a pas vraiment d'utilité et est donc rather unusual (il y en a quand même plus de 230 000 d'après taginfo). +1 layer=0 est rather useless (inutile) et j'en efface assez régulièrement. Tous les objets qui n'ont pas de tag layer sont en layer=0. Et il y a en beaucoup plus sans tag layer qu'avec layer=0 ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag layer et Osmose
Francescu GAROBY wrote Le tag layer n'est utile que sur des lignes (ways) décrivant un élément physique se croisent sans avoir de noeuds en commun (route sur route, route sur rivière, *rivière sur rivière*, etc). Euh... Faudra m'expliquer, là ! ^_^ Francescu Croisement rivière/rivière : http://lh6.ggpht.com/__zoKJ77EvEc/TbKYwlFZOjI/NHg/yKkbfiQXqAk/magdeburg-water-bridge6%5B13%5D.jpg?imgmax=800 Bon c'est de la triche car en vrai l'une des rivières devrait être taggé bridge mais bon l'idée générale est valide pour illustrer ce cas. Les petits ruisseaux font les grandes rivières. Ovide Bonne journée, CmiF4 -- View this message in context: http://gis.19327.n5.nabble.com/Tag-layer-et-Osmose-tp5788559p5788597.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag layer et Osmose
Dans ce cas, autant considérer les aqueducs comme des rivières aussi :-) Le 5 décembre 2013 10:29, cmi c...@f4-group.com a écrit : Francescu GAROBY wrote Le tag layer n'est utile que sur des lignes (ways) décrivant un élément physique se croisent sans avoir de noeuds en commun (route sur route, route sur rivière, *rivière sur rivière*, etc). Euh... Faudra m'expliquer, là ! ^_^ Francescu Croisement rivière/rivière : http://lh6.ggpht.com/__zoKJ77EvEc/TbKYwlFZOjI/NHg/yKkbfiQXqAk/magdeburg-water-bridge6%5B13%5D.jpg?imgmax=800 Bon c'est de la triche car en vrai l'une des rivières devrait être taggé bridge mais bon l'idée générale est valide pour illustrer ce cas. Les petits ruisseaux font les grandes rivières. Ovide Bonne journée, CmiF4 -- View this message in context: http://gis.19327.n5.nabble.com/Tag-layer-et-Osmose-tp5788559p5788597.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
Je viens de faire la comparaison avec le COG du 1er janvier 2013. Il y a 36681 communes dans le COG et j'en avais 36660 de mon côté dans la table planet_osm_polygon d'osm2pgsql. Cette table ne contient que les communes dont le multipolygone est correctement fermé. Il y en avait 3 non fermées (45302 Saran + 45062 Cercottes et 80701 Saint-Christ-Briost). Il y en a une (52379 Pautaines-Augeville) qui a été fusionnée officiellement le 28 février 2013 avec sa voisine (52187 Épizon): http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT27205711 Voici donc les 4 d'écart, 3 de corrigées dans OSM et 1 plus à jour que le COG... et bien sûr les 17 non disponibles au cadastre à Mayotte. Je me suis penché aussi sur les publications au journal officiel. J'ai fait la liste de ce que j'ai trouvé sur le wiki: http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives J'en ai profité pour remettre un peu à jour cette page avec cette première phase initiale de tracé terminée, vu qu'on entre maintenant dans le contrôle qualité et la maintenance. A propos de maintenance et de suivi des changements, comment conserver les limites précédentes lorsqu'elles changent ? Ces informations sont très utiles car les limites administratives servent souvent aux data visualisations de données qui peuvent être un peu anciennes et donc il faut des limites qui correspondent aux autres données qu'on veut représenter. Sur des fusions de communes, nous avons été plusieurs à conserver les anciennes communes en admin_level=10 Pour les scissions (rare, mais ça existe) avez-vous une idée ? Pour les changements de limite territoriales entre 2 communes... garder l'ancien tracé est utile, mais où le mettre ? C'est surtout sur les EPCI que ça serait utile de conserver les états successifs. Je termine par les EPCI... je vais m'appuyer sur le fichier actuel du ministère de l'intérieur pour vérifier, c'est à dire signaler les différences (sans les corriger) et compléter, c'est à dire créer les EPCI manquants lorsqu'ils n'existent pas dans OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
Je termine par les EPCI... je vais m'appuyer sur le fichier actuel du ministère de l'intérieur pour vérifier, c'est à dire signaler les différences (sans les corriger) et compléter, c'est à dire créer les EPCI manquants lorsqu'ils n'existent pas dans OSM. Tiens ça me fait penser à la couche que tu as ajouté la semaine dernière Christian pour la vérification de la qualité des points triples par comparaison avec le GEOFLA/Route 500. J'ai un peu testé et j'ai l'impression que les sources IGN ne sont vraiment pas fiables et que la position de certains points triples n'a pas été conservée dans la simplification de leurs données. Exemple ici : http://tile.openstreetmap.fr/?zoom=17lat=43.57117lon=3.52051layers=B000FFFTFF J'ai vérifié les 2 erreurs de 115m et 27m toutes les sources cadastrales des différentes communes concordent et les points OSM sont bien placés. Pour l'erreur de 115m, il semblerait que la source IGN ai royalement ignoré le téton de la commune du Pouget dans sa simplification. Du coup je ne sais pas trop si ces informations vont pouvoir nous aider beaucoup pour améliorer la précision des limites dans OSM... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
Le 5 décembre 2013 10:38, Christian Quest cqu...@openstreetmap.fr a écrit : Voici donc les 4 d'écart, 3 de corrigées dans OSM et 1 plus à jour que le COG... et bien sûr les 17 non disponibles au cadastre à Mayotte. Absolument aucune source d'information disponible la dessus ? Je me suis penché aussi sur les publications au journal officiel. J'ai fait la liste de ce que j'ai trouvé sur le wiki: http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives J'en ai profité pour remettre un peu à jour cette page avec cette première phase initiale de tracé terminée, vu qu'on entre maintenant dans le contrôle qualité et la maintenance. A propos de maintenance et de suivi des changements, comment conserver les limites précédentes lorsqu'elles changent ? Ces informations sont très utiles car les limites administratives servent souvent aux data visualisations de données qui peuvent être un peu anciennes et donc il faut des limites qui correspondent aux autres données qu'on veut représenter. Peut-être dans un export hors OSM tout simplement ? C'est surtout sur les EPCI que ça serait utile de conserver les états successifs. Je termine par les EPCI... je vais m'appuyer sur le fichier actuel du ministère de l'intérieur pour vérifier, c'est à dire signaler les différences (sans les corriger) et compléter, c'est à dire créer les EPCI manquants lorsqu'ils n'existent pas dans OSM. Peut être attaquer directement sur les EPIC 2014.Avec comcommaker on peut importer celles n'existant pas du tout. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Controle qualité des limites administratives.
Hello ! J'ai commencé à corriger les limites portant le tag Geofla qui sont recensées sur ce gâteau : http://mapcraft.nanodesu.ru/pie/332 Le petit problème que j'ai rencontré, c'est qu'en suivant certaines limites admin, je me suis rendu compte que certaines qui ne portent pas de tag source=Geofla mais source=cadastre sont pourtant franchement fausses lorsqu'on les compare à celles du cadastre actuel. Je parle de décalages de plus de 100 mètres. Exemple : http://www.openstreetmap.org/node/1722192948 Alors je lance mes questions : - Comment détecter facilement ces problèmes ? Je pense à une comparaison entre les limites de 2 communes voisine, extraites des serveurs du cadastre, ainsi que celle présente dans Osm. - Comment corriger facilement ces problèmes ? Oui, car manipuler plusieurs couches de cadastre vectoriel, ou plusieurs calques comportant les limites admin extraites depuis cadastre.openstreetmap.fr ; ce n'est pas pratique du tout, ni efficace. - Comment gérer les cadastres qui sont décalés, et éviter les mauvaises corrections ? StéphaneP ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag layer et Osmose
Prenons l'expression plus générale cours d'eau sur cours d'eau. Si un canal est un cours d'eau, alors oui c'est possible d'avoir un canal au dessus d'une rivière, et pas qu'un aqueduc, le cas existe avec un canal qui passe par dessus une vallée par un solide pont... Le 5 décembre 2013 10:33, Francescu GAROBY windu...@gmail.com a écrit : Dans ce cas, autant considérer les aqueducs comme des rivières aussi :-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
Le jeudi 5 décembre 2013 10:50:05 Nicolas Moyroud a écrit : Je termine par les EPCI... je vais m'appuyer sur le fichier actuel du ministère de l'intérieur pour vérifier, c'est à dire signaler les différences (sans les corriger) et compléter, c'est à dire créer les EPCI manquants lorsqu'ils n'existent pas dans OSM. Tiens ça me fait penser à la couche que tu as ajouté la semaine dernière Christian pour la vérification de la qualité des points triples par comparaison avec le GEOFLA/Route 500. J'ai un peu testé et j'ai l'impression que les sources IGN ne sont vraiment pas fiables et que la position de certains points triples n'a pas été conservée dans la simplification de leurs données. Salut, Moi aussi, j'ai regardé un peu :-) J'ai vu une erreur de 1670m (!) ici : http://tile.openstreetmap.fr/?zoom=15lat=45.54221lon=2.79535layers=B000FFFTFF En fait l'export city-limit de la commune de Chastreix était faux alors que le cadastre en ligne attribue bien à Chastreix le pavé du milieu. http://www.openstreetmap.org/changeset/19285237 Ce serait sympa d'avoir un export de ces erreurs sous forme de tableau classé par distance avec un lien vers la carte :-) Genre sur le wiki, pour qu'on puisse apporter des commentaires (mais ça complique la mise à jour). -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
L'IGN peut largement se tromper, et cela n'est pas dû au processus de simplification (la doc indique une simplification à 200m) mais bien aux données présentes dans leurs bases. Une petite liste de grosses erreurs (plus de 200m donc) figure sur http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr#Des_erreurs_.3F Celles que j'ai indiqué ont été vérifiées sur le cadastre et sur le Géoportail avec la couche Limites administratives qui me semble sortir de la BD Topo. Pour ces écarts, la liste est disponible en csv et remise à jour toute les nuits : http://osm13.openstreetmap.fr/~cquest/openfla/ecarts-osm-route500.csv Il faudrait mettre ça en forme pour le donner à manger à osmose... -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
Suite du croisement avec le COG... sur les noms cette fois-ci Voici 30 communes qui portent un nom différent dans OSM et la COG: https://gist.github.com/cquest/d8cdec0a98022647f020 Vous verrez qu'il y a des histoires d' majuscules sans accent ou cédille, mais aussi des noms vraiment différents qui peuvent nécessiter une correction après contrôle car certains noms ont effectivement changé depuis le 1/1/2013 (exemple: Saint-Amant - Saint-Amant-de-Montmoreau confirmé par http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT28160629). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag layer et Osmose
rivière/rivière effectivement je demande un exemple ;) rivière/canal là oui ! Le 5 décembre 2013 10:33, Francescu GAROBY windu...@gmail.com a écrit : Dans ce cas, autant considérer les aqueducs comme des rivières aussi :-) Le 5 décembre 2013 10:29, cmi c...@f4-group.com a écrit : Francescu GAROBY wrote Le tag layer n'est utile que sur des lignes (ways) décrivant un élément physique se croisent sans avoir de noeuds en commun (route sur route, route sur rivière, *rivière sur rivière*, etc). Euh... Faudra m'expliquer, là ! ^_^ Francescu Croisement rivière/rivière : http://lh6.ggpht.com/__zoKJ77EvEc/TbKYwlFZOjI/NHg/yKkbfiQXqAk/magdeburg-water-bridge6%5B13%5D.jpg?imgmax=800 Bon c'est de la triche car en vrai l'une des rivières devrait être taggé bridge mais bon l'idée générale est valide pour illustrer ce cas. Les petits ruisseaux font les grandes rivières. Ovide Bonne journée, CmiF4 -- View this message in context: http://gis.19327.n5.nabble.com/Tag-layer-et-Osmose-tp5788559p5788597.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
Et dans le rendu des écarts sur les intersections ça indiquait quoi ? Il faut que je regarde dans quelle mesure le Route500 même simplifié peut aider à trouver des gros bugs de ce type... genre un buffer de X metres autour de la limite Route500 doit contenir la limite OSM ou un truc du genre. Le 5 décembre 2013 11:04, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Hello ! J'ai commencé à corriger les limites portant le tag Geofla qui sont recensées sur ce gâteau : http://mapcraft.nanodesu.ru/pie/332 Le petit problème que j'ai rencontré, c'est qu'en suivant certaines limites admin, je me suis rendu compte que certaines qui ne portent pas de tag source=Geofla mais source=cadastre sont pourtant franchement fausses lorsqu'on les compare à celles du cadastre actuel. Je parle de décalages de plus de 100 mètres. Exemple : http://www.openstreetmap.org/node/1722192948 Alors je lance mes questions : - Comment détecter facilement ces problèmes ? Je pense à une comparaison entre les limites de 2 communes voisine, extraites des serveurs du cadastre, ainsi que celle présente dans Osm. - Comment corriger facilement ces problèmes ? Oui, car manipuler plusieurs couches de cadastre vectoriel, ou plusieurs calques comportant les limites admin extraites depuis cadastre.openstreetmap.fr ; ce n'est pas pratique du tout, ni efficace. - Comment gérer les cadastres qui sont décalés, et éviter les mauvaises corrections ? StéphaneP ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
Le jeudi 5 décembre 2013 11:29:57, Christian Quest a écrit : Et dans le rendu des écarts sur les intersections ça indiquait quoi ? Je viens de regarder. L'écart n'est que de 25m sur la couche QA. J'ai déplacé l'intersection plus au Nord, ce qui donnera un écart d'environ 17m à la prochaine maj de la couche. Mais c'est un peu plus loin que la limite admin dérivait franchement par rapport à celle du cadastre. Il faut que je regarde dans quelle mesure le Route500 même simplifié peut aider à trouver des gros bugs de ce type... genre un buffer de X metres autour de la limite Route500 doit contenir la limite OSM ou un truc du genre. Ce n'est pas possible d'utiliser directement les limites du cadastre vectoriel ? Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] POI OSM extraits par OpenDataSoft...
Petit regret : il manque la fonction editer dans [nom de votre éditeur OSM préféré] afin que la boucle soit en quelque sorte bouclée. Sans celle-ci, on reste dans une logique certes talentueuse mais traditionnelle et à sens unique de dataviz - je montre, tu regardes mais surtout tu ne touches pas. Fionn Le 5 décembre 2013 10:09, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mercredi 4 décembre 2013 22:52:55 Christian Quest a écrit : OpenDatasoft propose des API et différents services de téléchargement pour publier des données opendata. Ils ont repris les POI OSM amenity=* et mis ça en forme sur leur plateforme qui permet de les explorer de différentes façons (tableaux, carte, analses, API, download, etc). Très amusant en effet :-) On peut voir le classement des contributeurs qui ont ajouté le plus d'amenity=restaurant et source=survey (il manque le source=taste_survey ;-) ) Je suis impatient de voir les utilisations et les évolutions de ce service :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
Le 05/12/2013 11:23, Christian Quest a écrit : Suite du croisement avec le COG... sur les noms cette fois-ci Voici 30 communes qui portent un nom différent dans OSM et la COG: https://gist.github.com/cquest/d8cdec0a98022647f020 Vous verrez qu'il y a des histoires d' majuscules sans accent ou cédille, mais aussi des noms vraiment différents qui peuvent nécessiter une correction après contrôle car certains noms ont effectivement changé depuis le 1/1/2013 (exemple: Saint-Amant - Saint-Amant-de-Montmoreau confirmé par http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT28160629). Pour les communes du 64 que faire ? Çaro Castillon (Canton d'Arthez-de-Béarn) Castillon (Canton de Lembeye) Respecter strictement la syntaxe officiel de l'INSEE ou utiliser le vrai nom avec la bonne orthographe et sans les parenthèses. Dans ces cas particulier on peut mettre le nom INSEE dans la balise official_name ou nat_name ? http://wiki.openstreetmap.org/wiki/Key:name Dans ce cas, les outils de traitement automatisées doivent prendre en compte cette particularité. Mais dans les outils de routage, si on cherche Castillon dans le 64, comment faire la distinction ? Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag layer et Osmose
Ha, c'est là que j'aime la logique mise en place par maperitive, logique, il me semble, et qui doit régler plus de 95% des cas : Au sein d'un même layer (ou absence de layer), on trace d'abord les tunnel=*, puis le reste, puis les bridge=*. Dans la plupart des croisement, il y a bien soit un tunnel=*, soit un bridge=*. Et il me semble que ca suffit (sauf enchevêtrements spéciaux). JB. Le 05.12.2013 11:25, Christian Quest a écrit : rivière/rivière effectivement je demande un exemple ;) rivière/canal là oui ! Le 5 décembre 2013 10:33, Francescu GAROBY windu...@gmail.com a écrit : Dans ce cas, autant considérer les aqueducs comme des rivières aussi :-) Le 5 décembre 2013 10:29, cmi c...@f4-group.coma écrit : Francescu GAROBY wrote Le tag layer n'est utile que sur des lignes (ways) décrivant un élément physique se croisent sans avoir de noeuds en commun (route sur route, route sur rivière, *rivière sur rivière*, etc). Euh... Faudra m'expliquer, là ! ^_^ Francescu Croisement rivière/rivière : http://lh6.ggpht.com/__zoKJ77EvEc/TbKYwlFZOjI/NHg/yKkbfiQXqAk/magdeburg-water-bridge6%5B13%5D.jpg?imgmax=800 [1] Bon c'est de la triche car en vrai l'une des rivières devrait être taggé bridge mais bon l'idée générale est valide pour illustrer ce cas. Les petits ruisseaux font les grandes rivières. Ovide Bonne journée, CmiF4 -- View this message in context: http://gis.19327.n5.nabble.com/Tag-layer-et-Osmose-tp5788559p5788597.html [2] Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr [3] -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr [3] -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ [4] ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr [3] Links: -- [1] http://lh6.ggpht.com/__zoKJ77EvEc/TbKYwlFZOjI/NHg/yKkbfiQXqAk/magdeburg-water-bridge6%5B13%5D.jpg?imgmax=800 [2] http://gis.19327.n5.nabble.com/Tag-layer-et-Osmose-tp5788559p5788597.html [3] https://lists.openstreetmap.org/listinfo/talk-fr [4] http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag layer et Osmose
Bonjour - Mail original - De: Philippe Verdy verd...@wanadoo.fr Il n'y a que pour les culverts (ponceaux) qui passent par des buses enterrées que je romps le petits cours d'eau dans sa section busée avec layer=-1 et tunnel=yes, Je suis dans la même position s'il y a effectivement un pont (rivière en layer=0 donc non ajouté et pont en layer=1) ou des buses (waterway en layer=-1 et la route reste à layer=0 donc rien). Par contre en cas de buses c'est tunnel=culvert que j'utilise. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] POI OSM extraits par OpenDataSoft...
On pourrait imaginer le coût kilométrique par utilisateur, mais il sera difficile d'établir le parcours suivi car bon nombre de modifs ne font pas suite à un déplacement réel, juste une connaissance locale, ou bien les modifs ne sont tout bonnement pas faites dans le même ordre que la visite. En revanche on peut avoir une carte des POIs pour voir la densité des points d'intérêt de l'utilisateur, et sans doûte de bonnes informatiosn sur son espace de vie privée et son activité si on fait des corrélations de dates (selon le jour de la semaine, le mois, on saura où il va en vacance ou bien où habite sa famille qu'il visite régulièrement. D'où l'intérêt de pouvoir contribuer sur OSM de façon anonyme, avec juste un pseudonyme pour son compte utilisateur et ne pas pouvoir contribuer avec une IP comme l'autorise encore Wikipédia et comme il le fait sans prévenir au cas où on perd sa connexion utilisateur et qu'on ne s'en est pas rendu compte; contribuer avec une IP rendue publique devrait être interdit pour laisser l'utilisateur révéler ce qu'il décide par ses propres mots). D'ailleurs ça me fait penser qu'OSM n'a toujours pas de page d'information ou de conseil sur la protection de la vie privée du contributeur (pour certaines modifications, il pourrait être utile d'avoir un compte pseudonyme, et discuter sur les listes maililing avec un compte lié à une adresse email anonymisée, en expliquant bien aux utilisateurs les conséquences de la révélation de son identité ou sa géolocalisation réelle quand il utilise son compte OSM ou publie son adresse email réelle, ou discute en ligne avec celle-ci et l'associe à son compte OSM). OSM accepte beaucoup de données qui seront utiles à beaucoup, mais peuvent être sensibles vis à vis de son contributeur si cela révèle son intérêt personnel pour certains sujets ou son activité privée. La page vie privée est un vrai manque d'OSM (elle existe chez Wikimedia), et elle devrait aussi donner certains engagements de la part de la Fondation avec une charte renforcée le plus possible (et là on sera alors mieux que Google Maps). Une telle charte devrait aussi concerner non seulement le site web et la base de données, mais aussi le serveur de tuiles. Le service de géolocalisation automatique à la connexion sur le site OSM devrait aussi être expliqué et le site devrait garantir qu'il restera totalement utilisable sans plus de restriction que celle de devoir naviguer soi-même sur la carte, même si on refuse dans son navigateur (ou son profil utilisateur) la géolocalisation instantanée (certains smartphnes ont une fonction qui permet de ne pas refuser la géolocalisation mais de publier une géolocalisation aléatoire ou présélectionnée par l'utilisateur; il ne reste alors que la géolocalisation imprécise de l'adresse IP, rassemblant tout un tas d'utilisateur possibles dans une même zone de couverture, en général assez large pour les réseaux fixes, mais parfois encore trop précise pour les réseaux mobiles ou points d'accès WiFi publics ou certains hôtels). Le 5 décembre 2013 10:09, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mercredi 4 décembre 2013 22:52:55 Christian Quest a écrit : OpenDatasoft propose des API et différents services de téléchargement pour publier des données opendata. Ils ont repris les POI OSM amenity=* et mis ça en forme sur leur plateforme qui permet de les explorer de différentes façons (tableaux, carte, analses, API, download, etc). Très amusant en effet :-) On peut voir le classement des contributeurs qui ont ajouté le plus d'amenity=restaurant et source=survey (il manque le source=taste_survey ;-) ) Je suis impatient de voir les utilisations et les évolutions de ce service :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
L'IGN peut largement se tromper, et cela n'est pas dû au processus de simplification (la doc indique une simplification à 200m) mais bien aux données présentes dans leurs bases. Une petite liste de grosses erreurs (plus de 200m donc) figure sur http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr#Des_erreurs_.3F Je ne comprends pas bien pourquoi on ne doit signaler sur la page du wiki que les erreurs de plus de 200m puisque tu dis que les points triples ne sont pas impactés par le processus de simplification. J'aurai bien envie d'y signaler aussi mon erreur de 115m. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
2013/12/5 Frédéric Rodrigo fred.rodr...@gmail.com: Absolument aucune source d'information disponible la dessus ? D'après ce site: http://www.mayotte.pref.gouv.fr/Les-Services-de-l-Etat/Services-de-l-Etat/DSF le plan cadastral de Mayotte est terminé depuis décembre 2004. Il faudrait juste pouvoir le récupérer sous un format électronique sans passer par cadastre.gouv.fr. A noter que ce territoire est un paradis pour géomètres qui ont parceller et borner à tour de bras. Ils ont aussi 14000 dossiers de régularisation foncière entre le conseil général et les occupants ancestraux. Sur cette page, on trouve une adresse email du responsable de la plateforme SIG foncière: http://www.asp-public.fr/etudedecas/la-plate-forme-sig-fonciere-de-mayotte A propos de maintenance et de suivi des changements, comment conserver les limites précédentes lorsqu'elles changent ? Peut-être dans un export hors OSM tout simplement ? +1 Je suis contre le maintien d'anciennes limites administratives, même avec un admin_level farfelu. On peut toujours récupérer d'anciennes données dans la base. Si ça n'est pas trivial, surtout pour des relations, le plus simple serait des dump à intervalle régulier (tient, ça me rappelle les fichiers planet). Je pense qu'un principe largement partagé autour d'OSM est que la base reflète la géographie actuelle. Ce qui fait par exemple qu'on pousse les données historiques (routes romaines, ancien bâti, etc) dans des projets parallèles. Si on conserve d'anciennes limites disparues depuis 5 ou 10 ans, pourquoi refuser celles qui auraient disparu depuis 100 ou 1000 ans ? Déjà que certains considèrent que les limites administratives ne devraient pas du tout être dans OSM, inutile d'en rajouter une couche versions multiples pour accéder à l'historique plus facilement. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
Le 5 décembre 2013 12:15, Pieren pier...@gmail.com a écrit : Je suis contre le maintien d'anciennes limites administratives, même avec un admin_level farfelu. On peut toujours récupérer d'anciennes données dans la base. Si ça n'est pas trivial, surtout pour des relations, le plus simple serait des dump à intervalle régulier (tient, ça me rappelle les fichiers planet). Je pense qu'un principe largement partagé autour d'OSM est que la base reflète la géographie actuelle. Ce qui fait par exemple qu'on pousse les données historiques (routes romaines, ancien bâti, etc) dans des projets parallèles. Si on conserve d'anciennes limites disparues depuis 5 ou 10 ans, pourquoi refuser celles qui auraient disparu depuis 100 ou 1000 ans ? Pas du tout d'accord avec toi, car vouloir refléter la géographie actuelle sera totalement illusoire et irréalisable. Je ne demande pas qu'on maintienne des historiques très longtemps mais juste d'assurer une transition permettant la compatibilité avec d'autres sources de références actuelles, avec un délai raisonnable pour la transition (2 ans me parait suffisant). Car même les administrations officielles françaises ne font pas les transitions toutes en même temps et de façon immédiate alors que ces modifs s'imposent. L'Insee d'ailleurs s'oblige elle-même à assurer cette transition pour permettre la continuité statistique. Sinon on ne peut plus rien comparer d'une année sur l'autre. Garder des relations administratives qui ont changé pendant 2 ans ne représentera presque rien dans la base car 2 ans reste assez court pour permettre le ménage presque partout. Et cela permet d'être prêt aussi le jour J lors d'un changement officiellement annoncé (comme ceux du 1er janvier 2014 : on peut être prêt le jour J à zéro heure sans avoir à envoyer tout un tas de modifs à minuit et donc faciliter le travail de suivi. Bref il vaut mieux une transition en douceur permettant à tout le monde de se synchroniser dans un délai raisonnable qui leur est déjà imposé (les changements du 1er janvier 2014 ont 6 mois pour s'imposer dans les administrations, même si légalement (au cas où cela irait en justice pour prendre une décision contraignante) la date de bascule s'impose à l'heure dite à tout le monde, il est irréaliste que tout le monde disposera des mises à jour des différentes bases de données utilisées. Je suis donc totalement contre ta stratégie de Big Bang qui ne marchera en fait JAMAIS sur OSM : on n'est tout bonnement pas capable de la réaliser avec nos bénévoles sur leur temps libre, même ceux les plus assidus. Si on le pouvait, on n'aurait pas non plus des pannes sur les serveurs qui peuvent durer des semaines, et OSM proposerait une garantie contractuelle de service (par exemple en 4h après incident, généralement c'est une option assez chère comme pour les abonnements internet pro d'OVH). On le sait, une telle garantie de service continu avec des délais très courts implique une grosse obligation de moyens, et a un coût non négligeable qu'il sera impossible de réaliser sans rendre OSM payant avec un abonnement, et aussi sans transformer OSM en un service propriétaire et fermé (pire que Google Maps alors, car lui au moins il est gratuit pour bon nombre d'usages, mais donc aussi sans garantie de service continu) ! Franchement, on se complique la vie sans obtenir aucun bénéfice (on n'a QUE des inconvénients) à ne vouloir accepter aucun historique minimum mais facilement utilisable (les historiques OSM sont inutilisables sauf pour faire du revert rapidement (des délais trop courts en fait, qui fragilisent la base de données : on sait les ressources de calcul que cela demande pour les analyser, on l'a vu lors du changement de licence qui a demandé des années de préparation et des mois de correction après tellement cela entraînait d'incohérences), alors que cela représentera une infime partie des données et que c'est facilement gérable (sur des objets séparés) pour expliquer et résoudre des différences entre dates de références de diverses bases de données utilisées comparativement pour les tests de qualité. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Réf.: Tracé des limites communales terminé
genial! l aboutissement de ce travail de titan ca montre bien la force de la communaute Mes dernieres limites communales remontent a pas mal de temps mais je suis fier d avoir apporte ma contribution a cette realisation Julien -- Le mer. 4 déc. 2013 14:29 HNEC, V de Chateau-Thierry a écrit : Bonjour, Tout est dans le titre :-) Avec la Somme, terminée aujourd'hui, nous venons de boucler le tracé des limites de _toutes_ les communes françaises (à l'exception des 17 de Mayotte, non répertoriées sur le site du Cadastre pour l'instant). C'est un chantier de presque 6 ans qui s'achève, depuis Paris ( http://www.openstreetmap.org/relation/7444 ) le 15 mars 2008, jusque Contoire ( http://www.openstreetmap.org/relation/3359872 ), aujourd'hui : un nom qui sonne bien à l'idée de trinquer pour arroser ça. On n'en serait pas là, bien évidemment, sans l'autorisation donnée par la DGFiP pour que le Cadastre serve comme fond de plan pour OSM. On n'en serait pas là non plus sans les outils qui ont fleuri à la même époque : le plugin Cadastre-fr porté par Pieren, et qui aura servi jusqu'au bout, ainsi que les outils de vectorisation initiés par Frédéric. On n'en serait pas là, pour l'époque récente, sans Mapcraft, qui a donné le boost final pour accélérer le tracé des derniers 10%. Et, last but not least, rien de tout ça n'aurait été possible sans le temps consacré par 279 contributeurs, au fil des années, pour créér ces fameuses relations administratives. Vous les trouverez ici (les contributeurs, et les relations) : http://vimeo.com/user22882814/osmfrenchboundaries La suite ? Les sujets ne manquent pas : un peu de maintenance au fil des relations cassées, un peu d'harmonisation de tags, le complément des couches soeurs (arrondissements, cantons, EPCIs), un peu de contrôle qualité dans la foulée de ce que Christian a initié. Mais surtout, la couche des communes devient diffusable à l'échelle France, ce qui en fait un bon prétexte à discussion avec de potentiels utilisateurs. Bref, bravo à (nous) tous, et à suivre ;-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
Le 05/12/2013 12:15, Pieren a écrit : 2013/12/5 Frédéric Rodrigo fred.rodr...@gmail.com: A propos de maintenance et de suivi des changements, comment conserver les limites précédentes lorsqu'elles changent ? Peut-être dans un export hors OSM tout simplement ? +1 Je suis contre le maintien d'anciennes limites administratives, même avec un admin_level farfelu. On peut toujours récupérer d'anciennes données dans la base. Si ça n'est pas trivial, surtout pour des relations, le plus simple serait des dump à intervalle régulier (tient, ça me rappelle les fichiers planet). +1, Avec des dumps périodiques (annuels, au 31 décembre ?). Ça veut dire aussi qu'on garantit dans les dumps qu'il n'y a pas de relation cassées, d'erreurs de code INSEE... Voi le problème de la coastline. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tag layer et Osmose
Bonjour, si je résume ce que j'ai compris : - Il faut mettre le tag layer sur les ponts ou empilement particuliers - La valeur 0 est par défaut donc ne pas la mettre dans ce cas l'erreur Osmose Manque le tag layer aux alentours du pont ne devrait-elle pas être revu ? ou expliqué différemment? Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rue à double nom
Bonjour, ma commune a eu besoin de dénommer une nouvelle rue pour de futures adresses (nouvelle construction) et apparemment la seule solution à été sur une portion de route de garder le nom actuelle du côté pair et de donner le nouveau nom sur le côté impair : http://www.openstreetmap.org/way/174297996 y a t'il une façon de taguer les voies avec un left:name et right:name ? Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue à double nom
2013/12/5 Simon Miniou simon.min...@gmail.com: y a t'il une façon de taguer les voies avec un left:name et right:name ? Suivant cette (vieille) proposition: http://wiki.openstreetmap.org/wiki/Proposed_features/right_left on utilise plutot name:left et name:right. taginfo nous donne 23.800 name:left ([1]) contre 77 left:name seulement ([2]) [1] http://taginfo.openstreetmap.org/search?q=name%3Aleft [2] http://taginfo.openstreetmap.org/search?q=left%3Aname ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag layer et Osmose
J'ai corrigé un certain nombre de ces erreurs, et depuis le message de quelqu'un sur cette liste expliquant la différence entre tunnel et pont, je pratique ainsi pour les croisement eau/highway : S'il y a un tablier au niveau de la route/chemin alors c'est un pont donc je ne touche pas au waterway, et j'ajoute bridge=yes + layer=1 au morceau de highway concerné S'il n'y a pas de tablier, alors c'est le waterway qui est modifié avec tunnel=yes (ou tunnel=culvert) + layer= -1 Stf Le jeudi 5 décembre 2013 14:08:57, Simon Miniou a écrit : Bonjour, si je résume ce que j'ai compris : * Il faut mettre le tag layer sur les ponts ou empilement particuliers * La valeur 0 est par défaut donc ne pas la mettre dans ce cas l'erreur Osmose Manque le tag layer aux alentours du pont ne devrait-elle pas être revu ? ou expliqué différemment? Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] SotM-EU 2014 à Karlsruhe, Allemagne
Hello, aujourd'hui j'ai la plaisir d'annoncer que la prochaine SotM-EU aura lieu à Karlsruhe de 13 à 15 Juin 2014. Nous avons lancés un site web à www.sotm-eu.org. Vous trouvez toutes nouvelles là-bas et sur Twitter chez @sotmeu les semaines prochaines. Nous aimerions bien imiter le succès de la conférence de Vienne 2011 et réunir tous ceux qui font quelque chose d'intéressant avec OpenStreetMap en Europe. Karlsruhe n'est pas loin de la France. On veux prendre cette occasion pour intensifier le contact avec notre voisins. On projete par example une matinée française et autres grandes et petites opportunités d'échange d'information. Le moment nous cherchons une ou deux personnes qui nous rendent assistance de trouver des contributions françaises à OpenStreetMap. Il n'est pas essentiel de parler allemand. Si vous êtes intéressé de participer prenez contact avec moi. Je me réjouis à vous voir à Karlsruhe l'année prochaine. Bonne journée, Christine Karch ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Communiqué de presse limites administratives
Voici le brouillon du communiqué de presse: https://hackpad.com/Mvv5yGm7htn Merci d'avance pour vos retours. 2 chiffres parlants... Un select sum(st_perimeter(geography(st_transform(way,4326/1000/2 from planet_osm_polygon where ref:INSEE is not null and admin_level='8' and boundary='administrative'; nous dit qu'il y a 377 326 km de limites communales et select count(distinct((dp).geom)) from (select ST_DumpPoints(way) as dp from planet_osm_polygon where ref:INSEE is not null and admin_level='8' and boundary='administrative') as comm; nous dit qu'il y a 9 552 465 nœuds pour définir ces limites ! Ca en fait des clics ? Combien de souris y sont restées ? -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
C'est sur ma todo list... regénérer toutes les limites des communes avec un cadastre vectoriel et comparer à l'existant dans OSM. Ça fera sûrement remonter des différences, je pense surtout aux communes qui n'étaient qu'en raster au moment où elles ont été tracées et qui ont été vectorisées depuis sur le cadastre. On n'a pas finit d'affiner ces limites ! Le 5 décembre 2013 11:46, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Le jeudi 5 décembre 2013 11:29:57, Christian Quest a écrit : Et dans le rendu des écarts sur les intersections ça indiquait quoi ? Je viens de regarder. L'écart n'est que de 25m sur la couche QA. J'ai déplacé l'intersection plus au Nord, ce qui donnera un écart d'environ 17m à la prochaine maj de la couche. Mais c'est un peu plus loin que la limite admin dérivait franchement par rapport à celle du cadastre. Il faut que je regarde dans quelle mesure le Route500 même simplifié peut aider à trouver des gros bugs de ce type... genre un buffer de X metres autour de la limite Route500 doit contenir la limite OSM ou un truc du genre. Ce n'est pas possible d'utiliser directement les limites du cadastre vectoriel ? Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
On n'a aucune garantie sur l'impact de la simplification sur les intersections. Il semble qu'elles ne soient que peu impactées en général, mais il peut y avoir des cas particuliers. Cette limite de 200m provient du descriptif de l'IGN... en gros jusqu'à 200m on ne peut pas dire que c'est une erreur dans leurs données, au delà ça sort de leurs spécifications et c'est donc bien une erreur. Le 5 décembre 2013 12:10, Nicolas Moyroud nmoyr...@free.fr a écrit : L'IGN peut largement se tromper, et cela n'est pas dû au processus de simplification (la doc indique une simplification à 200m) mais bien aux données présentes dans leurs bases. Une petite liste de grosses erreurs (plus de 200m donc) figure sur http://wiki.openstreetmap.org/wiki/FR:Servers/tile. openstreetmap.fr#Des_erreurs_.3F Je ne comprends pas bien pourquoi on ne doit signaler sur la page du wiki que les erreurs de plus de 200m puisque tu dis que les points triples ne sont pas impactés par le processus de simplification. J'aurai bien envie d'y signaler aussi mon erreur de 115m. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communiqué de presse limites administratives
nous dit qu'il y a 9 552 465 nœuds pour définir ces limites ! Ca en fait des clics ? Combien de souris y sont restées ? En fait tout n'a pas été clic-cliqué à la main : beaucoup de contours ont été extraits de http://cadastre.openstreetmap.fr quand le cadastre était vectorisé (couche city-limit). Mais c'est difficile d'évaluer quel pourcentage. Damouns ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Droit d'auteur
Bonjour, Je m'interroge sur une phrase que je trouve ambiguë dans la rubrique Droit d'auteur [1]. Dans la section Comment créditer OpenStreetMap il est mentionné : Pour une carte électronique navigable, le crédit devrait apparaître dans le coin de la carte. Je ne sais pas ce que navigable veut dire, si dans l'esprit du rédacteur ca veut dire slippy-map ou carte routable. La version de référence (UK) dit : For a browsable electronic map, the credit should appear in the corner of the map. Mais dans les 2 cas, ca me parait faux ou incomplet, ca exclurait de la contrainte tout ce qui n'est pas carte browsable donc poster, flyer, carte imprimée, PDF etc... A mon sens, la mention doit apparaitre sur tout support exploitant des données OSM. J'imagine que dans l'esprit du rédacteur, ca concernait plus l'obligaton d'avoir un renvoi sous forme de lien hypertexte (qui ne concerne par définition que les cartes online) mais en tous cas c'est confus je trouve. Eric [1] http://www.openstreetmap.org/copyright ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communiqué de presse limites administratives
Le jeudi 5 décembre 2013 15:50:16 Damouns a écrit : nous dit qu'il y a 9 552 465 nœuds pour définir ces limites ! Ca en fait des clics ? Combien de souris y sont restées ? En fait tout n'a pas été clic-cliqué à la main : beaucoup de contours ont été extraits de http://cadastre.openstreetmap.fr quand le cadastre était vectorisé (couche city-limit). Mais c'est difficile d'évaluer quel pourcentage. Si quelqu'un récupère toutes les limites du cadastre vecteur, on peut alors soustraire les points de ces limites extraites automatiquement aux points dans la base pour avoir (normalement) les points entrés au clic :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communiqué de presse limites administratives
Je vais devoir encore travailler pour expliquer que nous ne sommes pas des f[ou|olle]s mais des passionnés des données de nos territoires y compris quand ils se mesurent en souris décédées ;-) On Dec 5, 2013 3:55 PM, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net wrote: Le jeudi 5 décembre 2013 15:50:16 Damouns a écrit : nous dit qu'il y a 9 552 465 nœuds pour définir ces limites ! Ca en fait des clics ? Combien de souris y sont restées ? En fait tout n'a pas été clic-cliqué à la main : beaucoup de contours ont été extraits de http://cadastre.openstreetmap.fr quand le cadastre était vectorisé (couche city-limit). Mais c'est difficile d'évaluer quel pourcentage. Si quelqu'un récupère toutes les limites du cadastre vecteur, on peut alors soustraire les points de ces limites extraites automatiquement aux points dans la base pour avoir (normalement) les points entrés au clic :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communiqué de presse limites administratives
Héhé... pas bête ;) Y'a du script qadastre dans l'air... et aussi script V car les positions des nœuds sont légèrement différentes. Le 5 décembre 2013 15:54, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le jeudi 5 décembre 2013 15:50:16 Damouns a écrit : nous dit qu'il y a 9 552 465 nœuds pour définir ces limites ! Ca en fait des clics ? Combien de souris y sont restées ? En fait tout n'a pas été clic-cliqué à la main : beaucoup de contours ont été extraits de http://cadastre.openstreetmap.fr quand le cadastre était vectorisé (couche city-limit). Mais c'est difficile d'évaluer quel pourcentage. Si quelqu'un récupère toutes les limites du cadastre vecteur, on peut alors soustraire les points de ces limites extraites automatiquement aux points dans la base pour avoir (normalement) les points entrés au clic :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communiqué de presse limites administratives
Nous tenons à préciser qu'aucune vraie souris n'a été maltraitée. Merci de votre attention ! Francescu Le 5 décembre 2013 16:00, RatZilla$ ratzil...@gmail.com a écrit : Je vais devoir encore travailler pour expliquer que nous ne sommes pas des f[ou|olle]s mais des passionnés des données de nos territoires y compris quand ils se mesurent en souris décédées ;-) On Dec 5, 2013 3:55 PM, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net wrote: Le jeudi 5 décembre 2013 15:50:16 Damouns a écrit : nous dit qu'il y a 9 552 465 nœuds pour définir ces limites ! Ca en fait des clics ? Combien de souris y sont restées ? En fait tout n'a pas été clic-cliqué à la main : beaucoup de contours ont été extraits de http://cadastre.openstreetmap.fr quand le cadastre était vectorisé (couche city-limit). Mais c'est difficile d'évaluer quel pourcentage. Si quelqu'un récupère toutes les limites du cadastre vecteur, on peut alors soustraire les points de ces limites extraites automatiquement aux points dans la base pour avoir (normalement) les points entrés au clic :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communiqué de presse limites administratives
Le 05/12/2013 15:54, Nicolas Dumoulin a écrit : Le jeudi 5 décembre 2013 15:50:16 Damouns a écrit : nous dit qu'il y a 9 552 465 nœuds pour définir ces limites ! Ca en fait des clics ? Combien de souris y sont restées ? En fait tout n'a pas été clic-cliqué à la main : beaucoup de contours ont été extraits de http://cadastre.openstreetmap.fr quand le cadastre était vectorisé (couche city-limit). Mais c'est difficile d'évaluer quel pourcentage. Si quelqu'un récupère toutes les limites du cadastre vecteur, on peut alors soustraire les points de ces limites extraites automatiquement aux points dans la base pour avoir (normalement) les points entrés au clic :-) Oui et non. Les limites issues du cadastre vecto étant abusivement détaillées, j'applique une simplification à 1.0 m. On gagne souvent 30% de nœuds pour le même résultat ! Si on faisait le calcul sur la France, le gain serait plus que significatif. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Droit d'auteur
2013/12/5 Eric eric...@sfr.fr: Mais dans les 2 cas, ca me parait faux ou incomplet, ca exclurait de la contrainte tout ce qui n'est pas carte browsable donc poster, flyer, carte imprimée, PDF etc... A mon sens, la mention doit apparaitre sur tout support exploitant des données OSM. J'imagine que dans l'esprit du rédacteur, ca concernait plus l'obligaton d'avoir un renvoi sous forme de lien hypertexte (qui ne concerne par définition que les cartes online) mais en tous cas c'est confus je trouve. Je ne vois pas comment tu arrives à cette conclusion. La phrase ne parle que des slippy-map et ne dit rien pour les autres cas (qui vont au-delà des cartes dessinées; ça peut aussi être de la donnée pure ou une API). C'est une phrase tirée de la legal-FAQ du wiki. La version complète ici: http://wiki.openstreetmap.org/wiki/Legal_FAQ#3a._I_would_like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F A noter, l'usage du conditionnel présent. L'ODbL impose une obligation d'attribution mais ne précise pas où. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communiqué de presse limites administratives
2013/12/5 Christian Quest cqu...@openstreetmap.fr Merci d'avance pour vos retours. Faisant autant que possible abstraction du charabia habituel aux communiqués de presse : C'est ainsi que 380 000 km de frontières communales ont été patiemment tracées à partir des planches cadastrales de la DGFiP. En effet, la Direction Générale des Finances Publiques a autorisé les contributeurs OSM à produire des données à partir du cadastre, comme les limites administratives, des routes, les emprises des bâtiments mais aussi les adresses. - C'est ainsi que 380 000 km de LIMITES (je préfère) communales ont été patiemment tracées à partir des planches cadastrales. La DGFiP (Direction Générale des Finances Publiques), organisme responsable du cadastre, a autorisé les contributeurs OSM à l'exploiter pour enregistrer les limites (BIEN) administratives, Les (une énumération c'est les... les... les... ou des... des... des... mais pas les... des... les... des...) routes, les emprises des bâtiments et les adresses. Ce nouveau jeu de données cartographiques qui a été créé à partir de la source la plus exacte disponible. Il est donc désormais disponible sous licence libre ODbL (Open Database Licence) sur les serveurs d'OpenStreetMap-France. Elles sont donc librement réutilisables en mentionnant leur origine (les contributeurs OpenStreetMap) et tant qu'elles restent redistribuées sous les mêmes conditions. - je ne comprends pas ce passage : les données cadastrales en tant que telle restent-elles isolées dans OSM, et donc directement récupérables ? Ou bien sont elles intégrées à l'ensemble des données, et que il s'agirait seulement des limites communales en tant que données géographiques, mais pas estampillées cadastre ? J'ai l'impression qu'il faudrait juste mettre : les limites communales françaises sont donc librement disponibles pour tous, selon la licence ODbL (Open Datavase Licence) sur les serveurs d'OpenStreetMap-France (... pourquoi France ?... ils ne sont pas disponibles sur les autres serveurs OSM ? ) La précision géométrique s'approche le plus possible de celle du cadastre... je titille, mais je pense que je subodorre qu'il s'agit ici de la précision /géographique/. C'est tout pour cette fois ci :-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue à double nom
Pas sûr que ce cas soit si rare que ça (bon, comparé au nombre de rues, ça reste rare) : j'imagine bien des rues servant de limite administrative entre 2 communes (incapables de s'entendre parce que de bords politiques différents ou autre chose encore), où un trottoir est dans la commune A et a un nom et l'autre trottoir se trouve dans la commune B et a un autre nom. Avec bien évidemment (quitte à bien faire chier les gens autant aller jusqu'au bout), des numérotations différentes. J'ai pas d'exemple à vous citer, mais avec 36.000 communes, ça m'étonnerait que le cas n'existe pas ! Francescu Le 5 décembre 2013 16:30, Greg ewala...@gmail.com a écrit : C'est quand même une situation surprenante d'avoir un nom différent de chaque côté d'une potion de rue. Heureusement que le modèle de données d'OSM est assez flexible pour arriver à encoder ça, parce-que sinon, c'est un cas particulier qui serait probablement passé à la trappe d'un modèle plus rigide décidé unilatéralement. Greg 2013/12/5 Pieren pier...@gmail.com 2013/12/5 Simon Miniou simon.min...@gmail.com: y a t'il une façon de taguer les voies avec un left:name et right:name ? Suivant cette (vieille) proposition: http://wiki.openstreetmap.org/wiki/Proposed_features/right_left on utilise plutot name:left et name:right. taginfo nous donne 23.800 name:left ([1]) contre 77 left:name seulement ([2]) [1] http://taginfo.openstreetmap.org/search?q=name%3Aleft [2] http://taginfo.openstreetmap.org/search?q=left%3Aname ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue à double nom
C'est quand même une situation surprenante d'avoir un nom différent de chaque côté d'une potion de rue. Heureusement que le modèle de données d'OSM est assez flexible pour arriver à encoder ça, parce-que sinon, c'est un cas particulier qui serait probablement passé à la trappe d'un modèle plus rigide décidé unilatéralement. Greg 2013/12/5 Pieren pier...@gmail.com 2013/12/5 Simon Miniou simon.min...@gmail.com: y a t'il une façon de taguer les voies avec un left:name et right:name ? Suivant cette (vieille) proposition: http://wiki.openstreetmap.org/wiki/Proposed_features/right_left on utilise plutot name:left et name:right. taginfo nous donne 23.800 name:left ([1]) contre 77 left:name seulement ([2]) [1] http://taginfo.openstreetmap.org/search?q=name%3Aleft [2] http://taginfo.openstreetmap.org/search?q=left%3Aname ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communiqué de presse limites administratives
l'ensemble des limites .. de France disponible remplacer crowdsourcing (un anglicisme peu utilisé ici car difficile à prononcer) par participatif COG (Code Officiel Géographique) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue à double nom
Ca arrive en limite de commune, mais j'en ai mappé une au sein d'une commune: Auxerre http://www.openstreetmap.org/way/66892303 Le 5 décembre 2013 16:38, Francescu GAROBY windu...@gmail.com a écrit : Pas sûr que ce cas soit si rare que ça (bon, comparé au nombre de rues, ça reste rare) : j'imagine bien des rues servant de limite administrative entre 2 communes (incapables de s'entendre parce que de bords politiques différents ou autre chose encore), où un trottoir est dans la commune A et a un nom et l'autre trottoir se trouve dans la commune B et a un autre nom. Avec bien évidemment (quitte à bien faire chier les gens autant aller jusqu'au bout), des numérotations différentes. J'ai pas d'exemple à vous citer, mais avec 36.000 communes, ça m'étonnerait que le cas n'existe pas ! Francescu Le 5 décembre 2013 16:30, Greg ewala...@gmail.com a écrit : C'est quand même une situation surprenante d'avoir un nom différent de chaque côté d'une potion de rue. Heureusement que le modèle de données d'OSM est assez flexible pour arriver à encoder ça, parce-que sinon, c'est un cas particulier qui serait probablement passé à la trappe d'un modèle plus rigide décidé unilatéralement. Greg 2013/12/5 Pieren pier...@gmail.com 2013/12/5 Simon Miniou simon.min...@gmail.com: y a t'il une façon de taguer les voies avec un left:name et right:name ? Suivant cette (vieille) proposition: http://wiki.openstreetmap.org/wiki/Proposed_features/right_left on utilise plutot name:left et name:right. taginfo nous donne 23.800 name:left ([1]) contre 77 left:name seulement ([2]) [1] http://taginfo.openstreetmap.org/search?q=name%3Aleft [2] http://taginfo.openstreetmap.org/search?q=left%3Aname ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue à double nom
2013/12/5 Christian Quest cqu...@openstreetmap.fr: Ca arrive en limite de commune, mais j'en ai mappé une au sein d'une commune: Auxerre Rue du Docteur Labosse, ça ne s'invente pas ^^ Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
Le 05/12/2013 15:38, Christian Quest a écrit : C'est sur ma todo list... regénérer toutes les limites des communes avec un cadastre vectoriel et comparer à l'existant dans OSM. Ça fera sûrement remonter des différences, je pense surtout aux communes qui n'étaient qu'en raster au moment où elles ont été tracées et qui ont été vectorisées depuis sur le cadastre. On n'a pas finit d'affiner ces limites ! Je ne serais pas surpris qu'une bonne partie des limites dessinées depuis le cadastre raster soient meilleures que les vectorielles. En raster avec la transparence lorsqu'on charge les planches on peut facilement comparer les limites entre 2 communes, et avec l'imagerie si on est dans une zone sans trop de déformation. On peut aussi recaler les planches à volonté si on utilise Piclayer En vectoriel, c'est bien plus difficile à faire (je trouve), et devant l'apparente simplicité du processus d'intégration de ces limites vectorielles, je doute que beaucoup de personnes s'embêtent à charger manuellement le cadastre vectoriel pour vérifier tout le tracé. Sinon, dans l'esprit Opendata, mais inversé, le service du cadastre serait intéressé par ce qu'on découvre comme aberration, no man's land, zones à 2 taxes d'habitation, décalage, etc. ? Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue à double nom
J'ai ça en magasin à Lille : http://tile.openstreetmap.fr/?zoom=17lat=50.62351lon=3.09677layers=B000FF Limite entre Lille et sa commune associée Hellemmes le début de la rue, Rue Mattéotti, puis Rues Mattéotti/Chanzy, puis fin Rue Chanzy avec la particularité (je viens de la voir sur le cadastre, m'en vais la mapper dès ce soir...) que : les numéros sont impairs des 2 cotés de la route, là où on a les 2 noms... on passe donc du 82 Rue Mattéotti au 381 Rue de Chanzy Puis sur l'autre trottoir plus haut du 181 Rue Mattéotti au 160 Rue Chanzy... la classe^^ @drien Le 5 décembre 2013 17:26, Pieren pier...@gmail.com a écrit : 2013/12/5 Christian Quest cqu...@openstreetmap.fr: Ca arrive en limite de commune, mais j'en ai mappé une au sein d'une commune: Auxerre Rue du Docteur Labosse, ça ne s'invente pas ^^ Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- http://www.virage-energie-npdc.org/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
En lisant le brouillon du communiqué de presse, je rebondis sur un point : Chaque année des communes fusionnent ou se séparent, voire échangent une partie de leur territoire avec leurs voisines. J'imagine que l'échange de parcelles entre communes doit arriver de temps en temps. Mais on a aucun moyen de le détecter. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
Le 05/12/2013 17:38, Stéphane Péneau a écrit : Le 05/12/2013 15:38, Christian Quest a écrit : C'est sur ma todo list... regénérer toutes les limites des communes avec un cadastre vectoriel et comparer à l'existant dans OSM. Ça fera sûrement remonter des différences, je pense surtout aux communes qui n'étaient qu'en raster au moment où elles ont été tracées et qui ont été vectorisées depuis sur le cadastre. On n'a pas finit d'affiner ces limites ! Je ne serais pas surpris qu'une bonne partie des limites dessinées depuis le cadastre raster soient meilleures que les vectorielles. En raster avec la transparence lorsqu'on charge les planches on peut facilement comparer les limites entre 2 communes, et avec l'imagerie si on est dans une zone sans trop de déformation. On peut aussi recaler les planches à volonté si on utilise Piclayer En vectoriel, c'est bien plus difficile à faire (je trouve), et devant l'apparente simplicité du processus d'intégration de ces limites vectorielles, je doute que beaucoup de personnes s'embêtent à charger manuellement le cadastre vectoriel pour vérifier tout le tracé. Je pense que beaucoup de limites administratives ont été retouché depuis leur import initial en utilisant Bing et l'import du bâti... Les variations ne doivent guère excéder quelques mètres dans le pire des cas et dans tous les cas inférieures aux différences de cadastre entre 2 communes voisines. Sinon, dans l'esprit Opendata, mais inversé, le service du cadastre serait intéressé par ce qu'on découvre comme aberration, no man's land, zones à 2 taxes d'habitation, décalage, etc. ? Sans doute un jour, mais d'ici là j'imagine que leur service est overbooké par la vectorialisation des plans papier ! Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
Le 05/12/2013 15:41, Christian Quest a écrit : On n'a aucune garantie sur l'impact de la simplification sur les intersections. Il semble qu'elles ne soient que peu impactées en général, mais il peut y avoir des cas particuliers. Cette limite de 200m provient du descriptif de l'IGN... en gros jusqu'à 200m on ne peut pas dire que c'est une erreur dans leurs données, au delà ça sort de leurs spécifications et c'est donc bien une erreur. Oui hé hé OK je vois. Déjà que bon ça va pas leur faire plaisir à l'IGN si ils découvrent cette liste des erreurs de plus de 200m ! ;-) Serait-il possible sur cette page de faire une rubrique supplémentaire pour indiquer les points de ta couche qui ont été vérifiés et dont il ne faut plus tenir compte ? Ou alors intégrer chacun des points sur osmose pour pouvoir indiquer un état vérifié quand c'est fait ? Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
Re- Le 5 décembre 2013 17:47, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : J'imagine que l'échange de parcelles entre communes doit arriver de temps en temps. Mais on a aucun moyen de le détecter. Stf Plus que des échanges de parcelles, il s'agit plutôt de démembrements/remembrements qui font bouger les limites de parcelles... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
La lecture du JORF ;) Par contre, c'est peu exploitable car souvent la publication au JO fait référence à un plan joint, qui bien sûr n'est pas dispo sur légifrance... donc direction la préfecture ! Le 5 décembre 2013 17:47, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : En lisant le brouillon du communiqué de presse, je rebondis sur un point : Chaque année des communes fusionnent ou se séparent, voire échangent une partie de leur territoire avec leurs voisines. J'imagine que l'échange de parcelles entre communes doit arriver de temps en temps. Mais on a aucun moyen de le détecter. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue à double nom
On Thu, Dec 05, 2013 at 04:38:14PM +0100, Francescu GAROBY wrote: Pas sûr que ce cas soit si rare que ça (bon, comparé au nombre de rues, ça reste rare) : j'imagine bien des rues servant de limite administrative entre 2 communes (incapables de s'entendre parce que de bords politiques différents ou autre chose encore), où un trottoir est dans la commune A et a un nom et l'autre trottoir se trouve dans la commune B et a un autre nom. Avec bien évidemment (quitte à bien faire chier les gens autant aller jusqu'au bout), des numérotations différentes. J'ai pas d'exemple à vous citer, mais avec 36.000 communes, ça m'étonnerait que le cas n'existe pas ! Il y a même un exemple à Paris : La rue de la Grande Truanderie et la rue de la Petite Truanderie dans le quartier des Halles : http://fr.wikipedia.org/wiki/Rue_de_la_Grande-Truanderie actuellement réalisé en OSM avec deux rues différentes. En réalité il s'agit d'une place triangulaire. -Ralf. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] OSM 2 CSV : l'open data d'OSM pour tous publics ?
Bonjour à tous ! **Résumé du message** : comment diffuser et voir réutilisées les données d'OSM auprès d'un public plus large, qui, dans un cercle vertueux, pourra devenir contributeur. Souvent j'ai l'occasion de dire ici ou là que telle donnée est dispo dans OSM. Par ailleurs, je pousse depuis un certains temps les acteurs publics à référencer sur leurs portails les données d'OSM : ainsi de Montpellier, le CG de la Gironde, la Région PACA, etc. Mais aujourd'hui, les jeux de données ou les outils de consultation d'OSM ont du mal à répondre à plein de petits cas tout simples comme : je veux la liste des pharmacies de ma région. Et je veux pouvoir manipuler cette liste dans mon tableur favori parce que c'est l'outil que je connais bien. Je me suis donc interrogé : comment produit-on simplement des données d'OSM sous forme de fichiers CSV ? Je sais bien que tout n'est pas extractible en CSV mais il y a un champ d'usage immense sur les données comme : * les bâtiments publics * les médecins, hôpitaux, pharmacie... * les lieux/services de secours (casernes de pompier, défibrilateurs, pompes incendies, téléphones de secours) * les lieux de culture (Théâtres, Musées, etc.) * les lieux d'histoire et du patrimoine * les arrêts de transports en commun * les terrains/équipements sportifs * les lieux touristiques * les systèmes de surveillance (caméras de surveillance) * les commerces * les hameaux * les services relatifs aux déchets (bennes de recyclage, poubelles, déchetteries, composteurs publics, etc.) * etc. Je suis donc allé grenouiller dans les outils (je précise que je n'ai jamais installé QGIS, Postgis, etc., je n'ai jamais utilisé l'API OSM, je ne fais pas dev mais j'ai quelques années d'expérience sous Linux). Et le plus simple que j'ai trouvé c'est la combinaison de osmconvert e et osmfilter. http://wiki.openstreetmap.org/wiki/Osmconvert http://wiki.openstreetmap.org/wiki/Osmfilter Je peux obtenir le fichier CSV de toutes les pharmacies de PACA en 4 lignes de commande : $ wget http://download.geofabrik.de/europe/france/provence-alpes-cote-d-azur-latest.osm.pbf # télécharge le fichier OSM de la Région PACA $ ./osmconvert32 provence-alpes-cote-d-azur-latest.osm.pbf -o=provence-alpes-cote-d-azur-latest.o5m # conversion du dit fichier dans un format lisible pour osmfilter $ ./osmfilter32 provence-alpes-cote-d-azur-latest.o5m --keep=amenity=pharmacy PACA-pharmacies.o5m # filtrage proprement dit pour ne retenir que les pharmacies $ ./osmconvert32 PACA-pharmacies.o5m --all-to-nodes --csv=@id @lon @lat amenity shop name --csv-headline PACA-pharmacies.csv # conversion du fichier filtré en CSV (Peut-être qu'on peut faire encore plus simple et plus rapide mais cette méthode à l'avantage d'être scriptable et automatisable facilement pour publier ces fichiers sur un serveur web.) Résultat : 1220 pharmacies identifiées et géolocalisées. J'aurais pu ajouter les adresses, les téléphones, etc. quand ils sont renseignés (c'est rare). (Il y a cependant des petits problèmes dans ce fichier comme les distributeurs de préservatifs (n'est-ce pas utilisateur cquest http://www.openstreetmap.org/node/2368452297 :D .) Il faut compter environ 8-10 minutes pour l'ensemble du process sur ma machine (compris le téléchargement des 200+ Mo du fichier PACA). **Pourquoi je creuse ça ?** * OSM est une platforme déjà bien en place pour crowdsourcer énormément de données et s'enrichit à grande vitesse * OSM a une dimension nationale et internationale * Mais OSM a du mal à fournir ses données autrement que par la carte ou par des fichiers XML assez obscurs et difficiles à manipuler par le néophyte (je caricature un peu et je ne connais sans doute pas toutes les initiatives) * Produire régulièrement des extractions en CSV devrait permettre : 1. de fournir des données à des néophytes qui pourront la réutiliser de manière simple 2. de permettre à des tas de gens de découvrir et utiliser OSM comme plateforme de coproduction de données 3. de faciliter la coproduction de certains types de données : avec ces tableaux, je peux maintenant plus facilement organiser une cartopartie thématique sur les cinémas, les bibliothèques, les sex shop ou que sais-je encore... Aujourd'hui, un des problèmes des fichiers open data des acteurs publics est que le feedback (ajouts, correction) est une fonctionnalité très mal organisée (c'est un euphémisme). OSM permet d'aller au-delà. Ma question est la suivante : est-ce que ça ne vaudrait pas le coup de réserver un espace, par exemple sur http://openstreetmap.fr , où publier de l'information pré-mâchée en CSV ? L'idéal pourrait aller jusqu'à fournir une interface permettant de générer soit-même des fichiers en rendant public ces fichiers pour les autres. Je veux bien aider à la définition des catégories de données et je passerai aussi du temps à convaincre les acteurs publics de référencer ces données sur leurs portails open data.
Re: [OSM-talk-fr] OSM 2 CSV : l'open data d'OSM pour tous publics ?
Je partage tout à fait ton constat. Favoriser la réutilisation autre que le production de carte passe par des outils pour transformer les données OSM dans des formats moins géographiques. Il y a l'overpass-api qui permet déjà pas mal de choses, surtout des sorties en json en plus de l'XML habituel. On peut écrire des requêtes relativement compacte pour sélectionner des objets géographiquement et sémantiquement. Il manque juste des convertisseurs de formats à l'overpass pour sortir les résultats en: - geojson - csv - svg - kml ... Ca démultiplierai les réutilisations et donc l'adoption d'OSM. A chaque hackathon où je suis présent comme mentor, je montre l'overpass et les développeurs découvre (enfin ?) à quoi OSM peut leur servir autrement que comme fond de carte pour remplacer Google... Le 5 décembre 2013 19:13, Charles Nepote char...@nepote.org a écrit : Bonjour à tous ! **Résumé du message** : comment diffuser et voir réutilisées les données d'OSM auprès d'un public plus large, qui, dans un cercle vertueux, pourra devenir contributeur. Souvent j'ai l'occasion de dire ici ou là que telle donnée est dispo dans OSM. Par ailleurs, je pousse depuis un certains temps les acteurs publics à référencer sur leurs portails les données d'OSM : ainsi de Montpellier, le CG de la Gironde, la Région PACA, etc. Mais aujourd'hui, les jeux de données ou les outils de consultation d'OSM ont du mal à répondre à plein de petits cas tout simples comme : je veux la liste des pharmacies de ma région. Et je veux pouvoir manipuler cette liste dans mon tableur favori parce que c'est l'outil que je connais bien. Je me suis donc interrogé : comment produit-on simplement des données d'OSM sous forme de fichiers CSV ? Je sais bien que tout n'est pas extractible en CSV mais il y a un champ d'usage immense sur les données comme : * les bâtiments publics * les médecins, hôpitaux, pharmacie... * les lieux/services de secours (casernes de pompier, défibrilateurs, pompes incendies, téléphones de secours) * les lieux de culture (Théâtres, Musées, etc.) * les lieux d'histoire et du patrimoine * les arrêts de transports en commun * les terrains/équipements sportifs * les lieux touristiques * les systèmes de surveillance (caméras de surveillance) * les commerces * les hameaux * les services relatifs aux déchets (bennes de recyclage, poubelles, déchetteries, composteurs publics, etc.) * etc. Je suis donc allé grenouiller dans les outils (je précise que je n'ai jamais installé QGIS, Postgis, etc., je n'ai jamais utilisé l'API OSM, je ne fais pas dev mais j'ai quelques années d'expérience sous Linux). Et le plus simple que j'ai trouvé c'est la combinaison de osmconvert e et osmfilter. http://wiki.openstreetmap.org/wiki/Osmconvert http://wiki.openstreetmap.org/wiki/Osmfilter Je peux obtenir le fichier CSV de toutes les pharmacies de PACA en 4 lignes de commande : $ wget http://download.geofabrik.de/europe/france/provence-alpes- cote-d-azur-latest.osm.pbf # télécharge le fichier OSM de la Région PACA $ ./osmconvert32 provence-alpes-cote-d-azur-latest.osm.pbf -o=provence-alpes-cote-d-azur-latest.o5m # conversion du dit fichier dans un format lisible pour osmfilter $ ./osmfilter32 provence-alpes-cote-d-azur-latest.o5m --keep=amenity=pharmacy PACA-pharmacies.o5m # filtrage proprement dit pour ne retenir que les pharmacies $ ./osmconvert32 PACA-pharmacies.o5m --all-to-nodes --csv=@id @lon @lat amenity shop name --csv-headline PACA-pharmacies.csv # conversion du fichier filtré en CSV (Peut-être qu'on peut faire encore plus simple et plus rapide mais cette méthode à l'avantage d'être scriptable et automatisable facilement pour publier ces fichiers sur un serveur web.) Résultat : 1220 pharmacies identifiées et géolocalisées. J'aurais pu ajouter les adresses, les téléphones, etc. quand ils sont renseignés (c'est rare). (Il y a cependant des petits problèmes dans ce fichier comme les distributeurs de préservatifs (n'est-ce pas utilisateur cquest http://www.openstreetmap.org/node/2368452297 :D .) Il faut compter environ 8-10 minutes pour l'ensemble du process sur ma machine (compris le téléchargement des 200+ Mo du fichier PACA). **Pourquoi je creuse ça ?** * OSM est une platforme déjà bien en place pour crowdsourcer énormément de données et s'enrichit à grande vitesse * OSM a une dimension nationale et internationale * Mais OSM a du mal à fournir ses données autrement que par la carte ou par des fichiers XML assez obscurs et difficiles à manipuler par le néophyte (je caricature un peu et je ne connais sans doute pas toutes les initiatives) * Produire régulièrement des extractions en CSV devrait permettre : 1. de fournir des données à des néophytes qui pourront la réutiliser de manière simple 2. de permettre à des tas de gens de découvrir et utiliser OSM comme plateforme de coproduction de données 3. de faciliter la coproduction de certains types de
Re: [OSM-talk-fr] Rue à double nom
Le 5 décembre 2013 19:08, Ralf Treinen trei...@free.fr a écrit : Il y a même un exemple à Paris : La rue de la Grande Truanderie et la rue de la Petite Truanderie dans le quartier des Halles : http://fr.wikipedia.org/wiki/Rue_de_la_Grande-Truanderie actuellement réalisé en OSM avec deux rues différentes. En réalité il s'agit d'une place triangulaire. Quel truand a trucidé cette place pour la débiter en pièces puis en dérober le 3e côté ? Plus sérieusement il doit arriver souvent que deux anciennes rues parallèles proches, suite à des démolitions, deviennent une place où finalement on décide de réunir les deux rues en une seule (ou supprimer des contre-allées) pour augmenter l'espace piétonnier sur cette place. De même le long d'une rue assez large, on peut arriver à créer une contre-allée avec un nom spécifique sans que la rue aie changé ni leurs adresses. La représentation dans OSM des places (mot en français) ou squares (mot en anglais) reste un problème encore non résolu, alors que c'est une entité plus importante pour la géolocalisation quand on est piéton, que le nom officiel de la rue qui la traverse (et qui intéresse surtout les conducteurs de véhicules et les services municipaux gérant les plans de circulation sur la voirie, ou les limites administratives de quartiers). On favorise encore trop dans OSM la perception automobile de la cartographie, au détriment des piétons et de la perception économique et culturelle des lieux dans leur aire d'influence. C'est un vieux débat entre cartographie administrative, contre la cartographie économique et le zonage urbain, les deux n'évoluant pas dans les mêmes directions. NB: D'ailleurs on peut aussi dire que le zonage urbain dans OSM est un immense chantier à faire (par les fourmis) qui n'est qu'à peine survolé par nos landuse=* (encore de très mauvaise qualité et en réalité pas réalisé dans le but du zonage urbain), et qui ne sait même pas non plus prendre en compte ce zonage à l'échelle supérieure des communes (celui réalisé par l'Insee, et qu'aujourd'hui on pourrait compléter facilement grâce aux limites communales, ou un peu plus bas à l'échelle des IRIS avec plein de travail à faire par les fourmis). On a encore du travail à faire aussi pour le découpage postal (puisque ni La Poste, ni l'ARCEP ne fournit de données libres), comme le fait l'Allemagne avec ses boundary=postal_code. Ne nous réjouissons pas trop vite de ce premier succès des communes de France : c'est justement là où les données libres de bonne qualité manquent cruellement que le travail des fourmis d''OSM est le plus utile et le plus décisif pour assurer le succès et la pérennité du projet. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM 2 CSV : l'open data d'OSM pour tous publics ?
Bonsoir à tous, Pas directement lié à l'Overpass, mais à OSM c'est dans cette optique que j'ai développé l'application OSM2GIS: http://www.osm974.re/osm2gis/ Il y a encore des détails à régler, notamment l'envoi des mails, mais le principe est là. Je travaille à une nouvelle version qui sera publiée sur GitHub. Arnaud On 13-12-05 02:56 PM, Christian Quest wrote: Je partage tout à fait ton constat. Favoriser la réutilisation autre que le production de carte passe par des outils pour transformer les données OSM dans des formats moins géographiques. Il y a l'overpass-api qui permet déjà pas mal de choses, surtout des sorties en json en plus de l'XML habituel. On peut écrire des requêtes relativement compacte pour sélectionner des objets géographiquement et sémantiquement. Il manque juste des convertisseurs de formats à l'overpass pour sortir les résultats en: - geojson - csv - svg - kml ... Ca démultiplierai les réutilisations et donc l'adoption d'OSM. A chaque hackathon où je suis présent comme mentor, je montre l'overpass et les développeurs découvre (enfin ?) à quoi OSM peut leur servir autrement que comme fond de carte pour remplacer Google... Le 5 décembre 2013 19:13, Charles Nepote char...@nepote.org mailto:char...@nepote.org a écrit : Bonjour à tous ! **Résumé du message** : comment diffuser et voir réutilisées les données d'OSM auprès d'un public plus large, qui, dans un cercle vertueux, pourra devenir contributeur. Souvent j'ai l'occasion de dire ici ou là que telle donnée est dispo dans OSM. Par ailleurs, je pousse depuis un certains temps les acteurs publics à référencer sur leurs portails les données d'OSM : ainsi de Montpellier, le CG de la Gironde, la Région PACA, etc. Mais aujourd'hui, les jeux de données ou les outils de consultation d'OSM ont du mal à répondre à plein de petits cas tout simples comme : je veux la liste des pharmacies de ma région. Et je veux pouvoir manipuler cette liste dans mon tableur favori parce que c'est l'outil que je connais bien. Je me suis donc interrogé : comment produit-on simplement des données d'OSM sous forme de fichiers CSV ? Je sais bien que tout n'est pas extractible en CSV mais il y a un champ d'usage immense sur les données comme : * les bâtiments publics * les médecins, hôpitaux, pharmacie... * les lieux/services de secours (casernes de pompier, défibrilateurs, pompes incendies, téléphones de secours) * les lieux de culture (Théâtres, Musées, etc.) * les lieux d'histoire et du patrimoine * les arrêts de transports en commun * les terrains/équipements sportifs * les lieux touristiques * les systèmes de surveillance (caméras de surveillance) * les commerces * les hameaux * les services relatifs aux déchets (bennes de recyclage, poubelles, déchetteries, composteurs publics, etc.) * etc. Je suis donc allé grenouiller dans les outils (je précise que je n'ai jamais installé QGIS, Postgis, etc., je n'ai jamais utilisé l'API OSM, je ne fais pas dev mais j'ai quelques années d'expérience sous Linux). Et le plus simple que j'ai trouvé c'est la combinaison de osmconvert e et osmfilter. http://wiki.openstreetmap.org/wiki/Osmconvert http://wiki.openstreetmap.org/wiki/Osmfilter Je peux obtenir le fichier CSV de toutes les pharmacies de PACA en 4 lignes de commande : $ wget http://download.geofabrik.de/europe/france/provence-alpes-cote-d-azur-latest.osm.pbf # télécharge le fichier OSM de la Région PACA $ ./osmconvert32 provence-alpes-cote-d-azur-latest.osm.pbf -o=provence-alpes-cote-d-azur-latest.o5m # conversion du dit fichier dans un format lisible pour osmfilter $ ./osmfilter32 provence-alpes-cote-d-azur-latest.o5m --keep=amenity=pharmacy PACA-pharmacies.o5m # filtrage proprement dit pour ne retenir que les pharmacies $ ./osmconvert32 PACA-pharmacies.o5m --all-to-nodes --csv=@id @lon @lat amenity shop name --csv-headline PACA-pharmacies.csv # conversion du fichier filtré en CSV (Peut-être qu'on peut faire encore plus simple et plus rapide mais cette méthode à l'avantage d'être scriptable et automatisable facilement pour publier ces fichiers sur un serveur web.) Résultat : 1220 pharmacies identifiées et géolocalisées. J'aurais pu ajouter les adresses, les téléphones, etc. quand ils sont renseignés (c'est rare). (Il y a cependant des petits problèmes dans ce fichier comme les distributeurs de préservatifs (n'est-ce pas utilisateur cquest http://www.openstreetmap.org/node/2368452297 :D .) Il faut compter environ 8-10 minutes pour l'ensemble du process sur ma machine (compris le téléchargement des 200+ Mo du fichier PACA). **Pourquoi je creuse ça ?** * OSM est une platforme déjà bien en place pour crowdsourcer énormément de données et s'enrichit à
Re: [OSM-talk-fr] Controle qualité des limites administratives.
Le 05/12/2013 17:56, Christophe Merlet a écrit : Je pense que beaucoup de limites administratives ont été retouché depuis leur import initial en utilisant Bing et l'import du bâti... Les variations ne doivent guère excéder quelques mètres dans le pire des cas et dans tous les cas inférieures aux différences de cadastre entre 2 communes voisines. Hmmm, je suis sceptique. Je ne serais pas surpris qu'une majorité des points utilisé pour les limites en soient à la v1. En plus, il n'est pas rare de trouver des limites admins en v1 qui ne correspondent plus à ce qu'affiche le cadastre. Mais là, je ne sais pas d’où ça vient. Amélioration de la précision du cadastre ? Remembrement ? Autre chose ? Et je ne parle pas des limites admin qui utilisent un way qui fait office de highway ou waterway ou landuse ou autre. Ces limites on eu tout le loisir de bouger sans que le contributeur s'en soit rendu compte. Si j'étais le dictateur d'openstreetmap, les limites admins seraient sur une autre couche :-) Sinon, dans l'esprit Opendata, mais inversé, le service du cadastre serait intéressé par ce qu'on découvre comme aberration, no man's land, zones à 2 taxes d'habitation, décalage, etc. ? Sans doute un jour, mais d'ici là j'imagine que leur service est overbooké par la vectorialisation des plans papier ! Je suis toujours dans les yakafokon, mais après avoir mangé une grande quantité de planches en raster, je regrette qu'on ne puisse pas recaler facilement le cadastre vectoriel, et que ce recalage puisse se partager. J'imagine que c'est ingérable puisqu'il faudrait tenir compte des mises à jours des planches. Donc c'est à la source qu'il faudrait pouvoir intervenir. En attendant que ça soit faisable, il faudrait peut-être imaginer un moyen de les recenser. Mais peut-être que cet échange existe déjà entre la Dgfip et l'Ign. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM 2 CSV : l'open data d'OSM pour tous publics ?
OSM2Gis est très bien mais destiné essentiellement aux SIGistes... Là c'est pour des publics très différents qu'il y a besoin de s'adapter en terme de filtrage des objets (ce que permet l'overpass) et en terme de format (ce qui manque à l'overpass). Le 5 décembre 2013 19:33, Arnaud Vandecasteele arnaud@gmail.com a écrit : Bonsoir à tous, Pas directement lié à l'Overpass, mais à OSM c'est dans cette optique que j'ai développé l'application OSM2GIS: http://www.osm974.re/osm2gis/ Il y a encore des détails à régler, notamment l'envoi des mails, mais le principe est là. Je travaille à une nouvelle version qui sera publiée sur GitHub. Arnaud On 13-12-05 02:56 PM, Christian Quest wrote: Je partage tout à fait ton constat. Favoriser la réutilisation autre que le production de carte passe par des outils pour transformer les données OSM dans des formats moins géographiques. Il y a l'overpass-api qui permet déjà pas mal de choses, surtout des sorties en json en plus de l'XML habituel. On peut écrire des requêtes relativement compacte pour sélectionner des objets géographiquement et sémantiquement. Il manque juste des convertisseurs de formats à l'overpass pour sortir les résultats en: - geojson - csv - svg - kml ... Ca démultiplierai les réutilisations et donc l'adoption d'OSM. A chaque hackathon où je suis présent comme mentor, je montre l'overpass et les développeurs découvre (enfin ?) à quoi OSM peut leur servir autrement que comme fond de carte pour remplacer Google... Le 5 décembre 2013 19:13, Charles Nepote char...@nepote.org a écrit : Bonjour à tous ! **Résumé du message** : comment diffuser et voir réutilisées les données d'OSM auprès d'un public plus large, qui, dans un cercle vertueux, pourra devenir contributeur. Souvent j'ai l'occasion de dire ici ou là que telle donnée est dispo dans OSM. Par ailleurs, je pousse depuis un certains temps les acteurs publics à référencer sur leurs portails les données d'OSM : ainsi de Montpellier, le CG de la Gironde, la Région PACA, etc. Mais aujourd'hui, les jeux de données ou les outils de consultation d'OSM ont du mal à répondre à plein de petits cas tout simples comme : je veux la liste des pharmacies de ma région. Et je veux pouvoir manipuler cette liste dans mon tableur favori parce que c'est l'outil que je connais bien. Je me suis donc interrogé : comment produit-on simplement des données d'OSM sous forme de fichiers CSV ? Je sais bien que tout n'est pas extractible en CSV mais il y a un champ d'usage immense sur les données comme : * les bâtiments publics * les médecins, hôpitaux, pharmacie... * les lieux/services de secours (casernes de pompier, défibrilateurs, pompes incendies, téléphones de secours) * les lieux de culture (Théâtres, Musées, etc.) * les lieux d'histoire et du patrimoine * les arrêts de transports en commun * les terrains/équipements sportifs * les lieux touristiques * les systèmes de surveillance (caméras de surveillance) * les commerces * les hameaux * les services relatifs aux déchets (bennes de recyclage, poubelles, déchetteries, composteurs publics, etc.) * etc. Je suis donc allé grenouiller dans les outils (je précise que je n'ai jamais installé QGIS, Postgis, etc., je n'ai jamais utilisé l'API OSM, je ne fais pas dev mais j'ai quelques années d'expérience sous Linux). Et le plus simple que j'ai trouvé c'est la combinaison de osmconvert e et osmfilter. http://wiki.openstreetmap.org/wiki/Osmconvert http://wiki.openstreetmap.org/wiki/Osmfilter Je peux obtenir le fichier CSV de toutes les pharmacies de PACA en 4 lignes de commande : $ wget http://download.geofabrik.de/europe/france/provence-alpes-cote-d-azur-latest.osm.pbf# télécharge le fichier OSM de la Région PACA $ ./osmconvert32 provence-alpes-cote-d-azur-latest.osm.pbf -o=provence-alpes-cote-d-azur-latest.o5m # conversion du dit fichier dans un format lisible pour osmfilter $ ./osmfilter32 provence-alpes-cote-d-azur-latest.o5m --keep=amenity=pharmacy PACA-pharmacies.o5m # filtrage proprement dit pour ne retenir que les pharmacies $ ./osmconvert32 PACA-pharmacies.o5m --all-to-nodes --csv=@id @lon @lat amenity shop name --csv-headline PACA-pharmacies.csv # conversion du fichier filtré en CSV (Peut-être qu'on peut faire encore plus simple et plus rapide mais cette méthode à l'avantage d'être scriptable et automatisable facilement pour publier ces fichiers sur un serveur web.) Résultat : 1220 pharmacies identifiées et géolocalisées. J'aurais pu ajouter les adresses, les téléphones, etc. quand ils sont renseignés (c'est rare). (Il y a cependant des petits problèmes dans ce fichier comme les distributeurs de préservatifs (n'est-ce pas utilisateur cquest http://www.openstreetmap.org/node/2368452297 :D .) Il faut compter environ 8-10 minutes pour l'ensemble du process sur ma machine (compris le téléchargement des 200+ Mo du fichier PACA). **Pourquoi je creuse ça
Re: [OSM-talk-fr] Controle qualité des limites administratives.
Prendre en compte les noeuds en v1 ou pas et les noeuds communs à d'autres objets peut être une analyse intéressante à faire... c'est une piste (de plus) à explorer. Le 5 décembre 2013 19:38, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Le 05/12/2013 17:56, Christophe Merlet a écrit : Je pense que beaucoup de limites administratives ont été retouché depuis leur import initial en utilisant Bing et l'import du bâti... Les variations ne doivent guère excéder quelques mètres dans le pire des cas et dans tous les cas inférieures aux différences de cadastre entre 2 communes voisines. Hmmm, je suis sceptique. Je ne serais pas surpris qu'une majorité des points utilisé pour les limites en soient à la v1. En plus, il n'est pas rare de trouver des limites admins en v1 qui ne correspondent plus à ce qu'affiche le cadastre. Mais là, je ne sais pas d’où ça vient. Amélioration de la précision du cadastre ? Remembrement ? Autre chose ? Et je ne parle pas des limites admin qui utilisent un way qui fait office de highway ou waterway ou landuse ou autre. Ces limites on eu tout le loisir de bouger sans que le contributeur s'en soit rendu compte. Si j'étais le dictateur d'openstreetmap, les limites admins seraient sur une autre couche :-) Sinon, dans l'esprit Opendata, mais inversé, le service du cadastre serait intéressé par ce qu'on découvre comme aberration, no man's land, zones à 2 taxes d'habitation, décalage, etc. ? Sans doute un jour, mais d'ici là j'imagine que leur service est overbooké par la vectorialisation des plans papier ! Je suis toujours dans les yakafokon, mais après avoir mangé une grande quantité de planches en raster, je regrette qu'on ne puisse pas recaler facilement le cadastre vectoriel, et que ce recalage puisse se partager. J'imagine que c'est ingérable puisqu'il faudrait tenir compte des mises à jours des planches. Donc c'est à la source qu'il faudrait pouvoir intervenir. En attendant que ça soit faisable, il faudrait peut-être imaginer un moyen de les recenser. Mais peut-être que cet échange existe déjà entre la Dgfip et l'Ign. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Droit d'auteur
Le 5 décembre 2013 16:26, Pieren pier...@gmail.com a écrit : A noter, l'usage du conditionnel présent. L'ODbL impose une obligation d'attribution mais ne précise pas où. Tout à fait d'accord. L'optique est de rendre visible ces attributions d'une façon aussi claire que les crédits photographiques utilisés dans la presse : pas forcément sur la photo elle-même mais juste en dessous ou à côté, de façon claire et lisible, et pas planquée seulement dans une obscure page d'index des illustrations avec des renvois vers de notes vers d'autres pages pour les crédits. Si on applique ça à un site web, c'est bien d'avoir une page générale du site pour ses crédits et droits d'auteur, mais pas suffisant car pas assez spécifique pour créditer chaque utilisation comme il convient sans tout mélanger : on demande que ce qui est libre et réutilisable puisse l'être sans avoir à redemander au site si les autres crédits présents sur cette page générale imposent des restrictions supplémentaires (qui seraient incompatibles avec la licence ODbL). On veut une attribution non ambiguë (et c'est même dans l'intérêt du site quant à son propre contenu spécifique, s'il veut le protéger par son propre droit d'auteur et non étendre à lui la couverture de licence ODbL) ! Dans cette optique, les slippy-map offrent le meilleur placement possible pour ce lien dans un coin de la carte car c'est ce qui est le plus clair, et une slippy-map permet toujours de la glisser pour voir ce qui serait caché dans ce coin par l'attribution visible. Noter qu'un hyperlien est possible dans presque tous les formats électroniques, pas seulement pour le web, même si on ne peut pas cliquer dessus immédiatement. mais il n'est pas toujours possible de zoomer ou se déplacer sur la carte, le placement est alors préférable juste à côté pour ne pas gêner la vue de l'illustration. Par exemple dans un PDF (où les liens peuvent être suivis, par un clic), un SVG, un eBook, un document Word ou une feuille Excel, ou dans une base de données importée sur un assistant de navigation GPS (qui peut soit l'afficher dans un panneau d'informations parmi les métadonnées quand on sélectionne un objet, et parfois permet d'ouvrir un navigateur web mobile si l'appareil est connecté, ce qui est presque toujours possible avec les GPS d'aujourd'hui via au minimum leur liaison BlueTooth ou USB vers un smartphone, ou via son propre tuner réseau mobile et sa carte SIM, ou via une connexion Wifi locale partagée par un smartphone connecté au réseau mobile). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM 2 CSV : l'open data d'OSM pour tous publics ?
Filtrage des objets, une prochaine fonctionnalité de OSM2GIS :D Bon quand les journées feront 28 heures, j'arriverai peut être à finir ma dév :) A. On 13-12-05 03:10 PM, Christian Quest wrote: OSM2Gis est très bien mais destiné essentiellement aux SIGistes... Là c'est pour des publics très différents qu'il y a besoin de s'adapter en terme de filtrage des objets (ce que permet l'overpass) et en terme de format (ce qui manque à l'overpass). Le 5 décembre 2013 19:33, Arnaud Vandecasteele arnaud@gmail.com mailto:arnaud@gmail.com a écrit : Bonsoir à tous, Pas directement lié à l'Overpass, mais à OSM c'est dans cette optique que j'ai développé l'application OSM2GIS: http://www.osm974.re/osm2gis/ Il y a encore des détails à régler, notamment l'envoi des mails, mais le principe est là. Je travaille à une nouvelle version qui sera publiée sur GitHub. Arnaud On 13-12-05 02:56 PM, Christian Quest wrote: Je partage tout à fait ton constat. Favoriser la réutilisation autre que le production de carte passe par des outils pour transformer les données OSM dans des formats moins géographiques. Il y a l'overpass-api qui permet déjà pas mal de choses, surtout des sorties en json en plus de l'XML habituel. On peut écrire des requêtes relativement compacte pour sélectionner des objets géographiquement et sémantiquement. Il manque juste des convertisseurs de formats à l'overpass pour sortir les résultats en: - geojson - csv - svg - kml ... Ca démultiplierai les réutilisations et donc l'adoption d'OSM. A chaque hackathon où je suis présent comme mentor, je montre l'overpass et les développeurs découvre (enfin ?) à quoi OSM peut leur servir autrement que comme fond de carte pour remplacer Google... Le 5 décembre 2013 19:13, Charles Nepote char...@nepote.org mailto:char...@nepote.org a écrit : Bonjour à tous ! **Résumé du message** : comment diffuser et voir réutilisées les données d'OSM auprès d'un public plus large, qui, dans un cercle vertueux, pourra devenir contributeur. Souvent j'ai l'occasion de dire ici ou là que telle donnée est dispo dans OSM. Par ailleurs, je pousse depuis un certains temps les acteurs publics à référencer sur leurs portails les données d'OSM : ainsi de Montpellier, le CG de la Gironde, la Région PACA, etc. Mais aujourd'hui, les jeux de données ou les outils de consultation d'OSM ont du mal à répondre à plein de petits cas tout simples comme : je veux la liste des pharmacies de ma région. Et je veux pouvoir manipuler cette liste dans mon tableur favori parce que c'est l'outil que je connais bien. Je me suis donc interrogé : comment produit-on simplement des données d'OSM sous forme de fichiers CSV ? Je sais bien que tout n'est pas extractible en CSV mais il y a un champ d'usage immense sur les données comme : * les bâtiments publics * les médecins, hôpitaux, pharmacie... * les lieux/services de secours (casernes de pompier, défibrilateurs, pompes incendies, téléphones de secours) * les lieux de culture (Théâtres, Musées, etc.) * les lieux d'histoire et du patrimoine * les arrêts de transports en commun * les terrains/équipements sportifs * les lieux touristiques * les systèmes de surveillance (caméras de surveillance) * les commerces * les hameaux * les services relatifs aux déchets (bennes de recyclage, poubelles, déchetteries, composteurs publics, etc.) * etc. Je suis donc allé grenouiller dans les outils (je précise que je n'ai jamais installé QGIS, Postgis, etc., je n'ai jamais utilisé l'API OSM, je ne fais pas dev mais j'ai quelques années d'expérience sous Linux). Et le plus simple que j'ai trouvé c'est la combinaison de osmconvert e et osmfilter. http://wiki.openstreetmap.org/wiki/Osmconvert http://wiki.openstreetmap.org/wiki/Osmfilter Je peux obtenir le fichier CSV de toutes les pharmacies de PACA en 4 lignes de commande : $ wget http://download.geofabrik.de/europe/france/provence-alpes-cote-d-azur-latest.osm.pbf # télécharge le fichier OSM de la Région PACA $ ./osmconvert32 provence-alpes-cote-d-azur-latest.osm.pbf -o=provence-alpes-cote-d-azur-latest.o5m # conversion du dit fichier dans un format lisible pour osmfilter $ ./osmfilter32 provence-alpes-cote-d-azur-latest.o5m --keep=amenity=pharmacy PACA-pharmacies.o5m # filtrage proprement dit pour ne retenir que les pharmacies $ ./osmconvert32 PACA-pharmacies.o5m --all-to-nodes --csv=@id @lon @lat amenity shop name --csv-headline
Re: [OSM-talk-fr] OSM 2 CSV : l'open data d'OSM pour tous publics ?
De mon coté je suis peu réceptif aux idées style le XML (et maintenant le JSon, donc ! ) ( Arf ! Arf ! Arf ! ) c'est compliqué le reste (CSV, ici) c'est bien (je caricature / je plaisante précise toujours l'émetteur). S'il caricature, qu'il dise en quoi ? Établit-on un projet informatique avec des caricatures ? S'il est sérieux, qu'il assume et qu'il explique mieux. Avec Excel, on peut transformer n'importe quel XML en CSV. Donc, c'est bon, non ? (Je plaisante...) Le 5 décembre 2013 19:13, Charles Nepote char...@nepote.org a écrit : Bonjour à tous ! **Résumé du message** : comment diffuser et voir réutilisées les données d'OSM auprès d'un public plus large, qui, dans un cercle vertueux, pourra devenir contributeur. Souvent j'ai l'occasion de dire ici ou là que telle donnée est dispo dans OSM. Par ailleurs, je pousse depuis un certains temps les acteurs publics à référencer sur leurs portails les données d'OSM : ainsi de Montpellier, le CG de la Gironde, la Région PACA, etc. Mais aujourd'hui, les jeux de données ou les outils de consultation d'OSM ont du mal à répondre à plein de petits cas tout simples comme : je veux la liste des pharmacies de ma région. Et je veux pouvoir manipuler cette liste dans mon tableur favori parce que c'est l'outil que je connais bien. Je me suis donc interrogé : comment produit-on simplement des données d'OSM sous forme de fichiers CSV ? Je sais bien que tout n'est pas extractible en CSV mais il y a un champ d'usage immense sur les données comme : * les bâtiments publics * les médecins, hôpitaux, pharmacie... * les lieux/services de secours (casernes de pompier, défibrilateurs, pompes incendies, téléphones de secours) * les lieux de culture (Théâtres, Musées, etc.) * les lieux d'histoire et du patrimoine * les arrêts de transports en commun * les terrains/équipements sportifs * les lieux touristiques * les systèmes de surveillance (caméras de surveillance) * les commerces * les hameaux * les services relatifs aux déchets (bennes de recyclage, poubelles, déchetteries, composteurs publics, etc.) * etc. Je suis donc allé grenouiller dans les outils (je précise que je n'ai jamais installé QGIS, Postgis, etc., je n'ai jamais utilisé l'API OSM, je ne fais pas dev mais j'ai quelques années d'expérience sous Linux). Et le plus simple que j'ai trouvé c'est la combinaison de osmconvert e et osmfilter. http://wiki.openstreetmap.org/wiki/Osmconvert http://wiki.openstreetmap.org/wiki/Osmfilter Je peux obtenir le fichier CSV de toutes les pharmacies de PACA en 4 lignes de commande : $ wget http://download.geofabrik.de/europe/france/provence-alpes- cote-d-azur-latest.osm.pbf # télécharge le fichier OSM de la Région PACA $ ./osmconvert32 provence-alpes-cote-d-azur-latest.osm.pbf -o=provence-alpes-cote-d-azur-latest.o5m # conversion du dit fichier dans un format lisible pour osmfilter $ ./osmfilter32 provence-alpes-cote-d-azur-latest.o5m --keep=amenity=pharmacy PACA-pharmacies.o5m # filtrage proprement dit pour ne retenir que les pharmacies $ ./osmconvert32 PACA-pharmacies.o5m --all-to-nodes --csv=@id @lon @lat amenity shop name --csv-headline PACA-pharmacies.csv # conversion du fichier filtré en CSV (Peut-être qu'on peut faire encore plus simple et plus rapide mais cette méthode à l'avantage d'être scriptable et automatisable facilement pour publier ces fichiers sur un serveur web.) Résultat : 1220 pharmacies identifiées et géolocalisées. J'aurais pu ajouter les adresses, les téléphones, etc. quand ils sont renseignés (c'est rare). (Il y a cependant des petits problèmes dans ce fichier comme les distributeurs de préservatifs (n'est-ce pas utilisateur cquest http://www.openstreetmap.org/node/2368452297 :D .) Il faut compter environ 8-10 minutes pour l'ensemble du process sur ma machine (compris le téléchargement des 200+ Mo du fichier PACA). **Pourquoi je creuse ça ?** * OSM est une platforme déjà bien en place pour crowdsourcer énormément de données et s'enrichit à grande vitesse * OSM a une dimension nationale et internationale * Mais OSM a du mal à fournir ses données autrement que par la carte ou par des fichiers XML assez obscurs et difficiles à manipuler par le néophyte (je caricature un peu et je ne connais sans doute pas toutes les initiatives) * Produire régulièrement des extractions en CSV devrait permettre : 1. de fournir des données à des néophytes qui pourront la réutiliser de manière simple 2. de permettre à des tas de gens de découvrir et utiliser OSM comme plateforme de coproduction de données 3. de faciliter la coproduction de certains types de données : avec ces tableaux, je peux maintenant plus facilement organiser une cartopartie thématique sur les cinémas, les bibliothèques, les sex shop ou que sais-je encore... Aujourd'hui, un des problèmes des fichiers open data des acteurs publics est que le feedback (ajouts, correction) est une fonctionnalité très mal
Re: [OSM-talk-fr] OSM 2 CSV : l'open data d'OSM pour tous publics ?
Excel ne sait pas traiter n'importe quel XML ou fait n'importe quoi si on ne lui donne pas un schéma d'accompagnement. Pour les cas compliqués, il faut parfois utiliser une source type ODBC ou autre interface base de données pour XML. On pourrait imaginer le développement d'un plugin connecteur de base de données pour Excel qui facilite les requêtes. Oui je sais, yakafaucon... Pour ça il faut un développeur pour le réaliser et le maintenir. Mais ça existe peut-être déjà avec un connecteur GIS, sans doute préférable et plus facile à utiliser qu'un connecteur XML générique sans schéma. D'autant plus qu'OSM n'a pas de schéma stable, on doit s'appuyer sur une conversion OSM vers GIS maintenue à part; la solution avec Overpass ne fait guère que rapporter des données OSM sans réel schéma autre que les 3 types d'objets de base (noeud, chemin et relation) et oblige à chercher soi-même les correspondances ou équivalences de tags (le résultat est une requête Overpass assez compliquée à réaliser et lire, et qui oublie bien des tas de cas compliqués, pourtant résolus et maintenus à jour dans OSM2GIS). Bref si on veut faciliter la réutilisation des données, c'est moins les exports OSM bruts (y compris Overpass) qu'il faut promouvoir, que leur conversion dans un format GIS exploitable de différentes façons. Et pourquoi pas avoir une base GIS en ligne directement chargée et maintenue à jour avec les données OSM en live ? Avec une riche palette de features supportés et documentés ? (la base OSM native ne serait plus que la base de travail pour les éditeurs et importations de données). Et peut-être aussi à l'avenir la possibilité d'éditer des données en passant par la base GIS (laquelle relaiera les infos vers la base OSM native, en utilisant le compte OSM associé au compte GIS et en utilisant les meilleurs tags recommandés). Cela aurait aussi un avantage : ne pas noyer les nouveaux-venus sous des tas d'autres données, en lui permettant de sélectionner les couches GIS qui l'intéresse sans toucher au reste. Mais le problème est sans doute l'absence d'assez d'outils libres pour travailler en ligne sur une base GIS. Pourtant un tel développement permettrait à nos fournisseurs actuels de données libres de pouvoir contribuer à OSM directement avec leurs outils GIS (même propriétaires) et un connecteur simplifié (qui facilite le long travail manuel de fusion avant importation). Le 5 décembre 2013 20:03, Ista Pouss ista...@gmail.com a écrit : De mon coté je suis peu réceptif aux idées style le XML (et maintenant le JSon, donc ! ) ( Arf ! Arf ! Arf ! ) c'est compliqué le reste (CSV, ici) c'est bien (je caricature / je plaisante précise toujours l'émetteur). S'il caricature, qu'il dise en quoi ? Établit-on un projet informatique avec des caricatures ? S'il est sérieux, qu'il assume et qu'il explique mieux. Avec Excel, on peut transformer n'importe quel XML en CSV. Donc, c'est bon, non ? (Je plaisante...) Le 5 décembre 2013 19:13, Charles Nepote char...@nepote.org a écrit : Bonjour à tous ! **Résumé du message** : comment diffuser et voir réutilisées les données d'OSM auprès d'un public plus large, qui, dans un cercle vertueux, pourra devenir contributeur. Souvent j'ai l'occasion de dire ici ou là que telle donnée est dispo dans OSM. Par ailleurs, je pousse depuis un certains temps les acteurs publics à référencer sur leurs portails les données d'OSM : ainsi de Montpellier, le CG de la Gironde, la Région PACA, etc. Mais aujourd'hui, les jeux de données ou les outils de consultation d'OSM ont du mal à répondre à plein de petits cas tout simples comme : je veux la liste des pharmacies de ma région. Et je veux pouvoir manipuler cette liste dans mon tableur favori parce que c'est l'outil que je connais bien. Je me suis donc interrogé : comment produit-on simplement des données d'OSM sous forme de fichiers CSV ? Je sais bien que tout n'est pas extractible en CSV mais il y a un champ d'usage immense sur les données comme : * les bâtiments publics * les médecins, hôpitaux, pharmacie... * les lieux/services de secours (casernes de pompier, défibrilateurs, pompes incendies, téléphones de secours) * les lieux de culture (Théâtres, Musées, etc.) * les lieux d'histoire et du patrimoine * les arrêts de transports en commun * les terrains/équipements sportifs * les lieux touristiques * les systèmes de surveillance (caméras de surveillance) * les commerces * les hameaux * les services relatifs aux déchets (bennes de recyclage, poubelles, déchetteries, composteurs publics, etc.) * etc. Je suis donc allé grenouiller dans les outils (je précise que je n'ai jamais installé QGIS, Postgis, etc., je n'ai jamais utilisé l'API OSM, je ne fais pas dev mais j'ai quelques années d'expérience sous Linux). Et le plus simple que j'ai trouvé c'est la combinaison de osmconvert e et osmfilter. http://wiki.openstreetmap.org/wiki/Osmconvert http://wiki.openstreetmap.org/wiki/Osmfilter Je
Re: [OSM-talk-fr] Controle qualité des limites administratives.
Le jeudi 5 décembre 2013 19:38:03 Stéphane Péneau a écrit : Et je ne parle pas des limites admin qui utilisent un way qui fait office de highway ou waterway ou landuse ou autre. Ces limites on eu tout le loisir de bouger sans que le contributeur s'en soit rendu compte. Si j'étais le dictateur d'openstreetmap, les limites admins seraient sur une autre couche :-) Toutafé ! D'ailleurs il doit en rester des premiers tracé que j'ai fait près de chez moi :-/ Sans passer pour un dictateur, on pourrait ajouter un test osmose ;-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
Le 05/12/2013 21:27, Nicolas Dumoulin a écrit : Le jeudi 5 décembre 2013 19:38:03 Stéphane Péneau a écrit : Et je ne parle pas des limites admin qui utilisent un way qui fait office de highway ou waterway ou landuse ou autre. Ces limites on eu tout le loisir de bouger sans que le contributeur s'en soit rendu compte. Si j'étais le dictateur d'openstreetmap, les limites admins seraient sur une autre couche :-) Toutafé ! D'ailleurs il doit en rester des premiers tracé que j'ai fait près de chez moi :-/ Sans passer pour un dictateur, on pourrait ajouter un test osmose ;-) Il y a déjà eu un ticket pour ça pour osmose : http://trac.openstreetmap.fr/ticket/451 Il est même déjà fermé ! Frédéric (dictateur). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Controle qualité des limites administratives.
Le postulat de départ de mon analyse de qualité basé sur les nœuds d'intersection prend un peu l'eau... j'vous essplique de suite... L'IGN met à disposition un échantillon de ses données. La bonne idée, c'est que ces échantillons couvrent semble-t-il tous le même territoire, un petit bout de Sarthe. J'ai donc regardé ces échantillons en commençant par la BD Topo du RGE, donc la référence à grande échelle. Premier constat: les intersections du Route500 sont bien plus décalés que je ne le pensais. J'ai noté des écarts de 38m par rapport à la BDTopo. Voilà où mon analyse prend un peu l'eau. Deuxième constat: la BD Topo et OSM divergent parfois beaucoup dans les tracés avec des terrains entiers qui changent de commune. Mais dans les échantillons il y a aussi la BD Parcellaire, issue... du cadastre ! Là, on est beaucoup plus proche avec des écarts vraiment minimes et sans grosses différences sur des terrains entiers. Vu que ça m'étonnerai que le cadastre ne sache pas dans quelle commune se trouve un terrain pour collecter la taxe foncière et/ou d'habitation à reverser en partie à la commune, je pense que la BD Parcellaire est la référence la plus précise avec laquelle il faudrait comparer nos limites. J'avoue ne pas trop comprendre les tracés de la BD Topo et surtout pourquoi ils ne sont pas identiques à la BD Parcellaire. Comment peut-on avoir 2 références... différentes ? Ou alors il n'y a qu'une référence, mais contenant plus d'erreurs ? -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communiqué de presse limites administratives
Le 05/12/2013 16:47, Pieren a écrit : l'ensemble des limites .. de France disponible remplacer crowdsourcing (un anglicisme peu utilisé ici car difficile à prononcer) par participatif +1 ici, en Alsace, ça finit souvent en Kraut-sourcing (expérience vécue ;-) Du coup, ça fait moins sens (les contributeurs sont chous ?) Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création d'un projet réseau ferré
Effectivement, l'essentiel de ces discussions n'est pas restreint au cadre franco-français, et doit avoir lieu sur la liste dédiée. Je vais essayer de m'y atteler. Quelques remarques tout de même : Concernant public_transport=station : N'ajoutons pas de la confusion là où il n'y en avait pas encore : actuellement, le schéma public_transport est clairement et largement présenté comme un ensemble tags qui peuvent venir en complément des tags classiques [1], et donc généralement en doublon pour les platforms et les stations. Son usage n'est nulle part restreint aux cas où les tags classiques seraient insuffisants. On peut – avec force arguments rationnels – relancer le débat ; proposer que les tags public_transports soient limités à pallier d'éventuelles insuffisances des tags classiques ; les supprimer de toutes les stations / bus_stations /bus_stops / platforms /... où ils font doublon. Mais ce n'était pas l'objet du débat. Il s'agissait de savoir si (lorsque l'on utilisait le schéma public_transport tel qu'il est présenté aujourd'hui) on définissait un seul public_transport=station sur l'ensemble du pôle de transport, ou un pour chaque élément (gare ferroviaire, gare routière, etc.). La seconde solution a été préconisée dans les discussions. Je l'ai mise en œuvre sur la Gare du Nord. Point. Encore une fois, je me contrefous de ce schéma, je ne cherche aucunement à le promouvoir. Chacun de nous peut décider de ne l'utiliser que dans certains cas particuliers, puisqu'il n'est (encore heureux !) pas obligatoire. Mais, pour ceux qui inévitablement voudront utiliser plus largement ce schéma, autant présenter sur un exemple comment l'utiliser au mieux. Concernant les mentions (métro) (RER) (gare routière) rajoutées au nom « Gare du Nord »: Même si c'est moi qui les ai rajoutées, je ne les apprécie pas plus que Christian ! Mais j'avais posé la question de l'opportunité de ce changement, sans obtenir de réponse. Alors j'ai suivi l'exemple de la Gare de Lyon (qu'on avait évoqué, sans soulever ce point : j'en ai conclu bien hâtivement que c'était un exemple à suivre). Donc, on enlève toutes ces mentions superfétatoires aussi bien sur les stations « Gare du Nord » que sur les stations « Gare de Lyon » ? ↑ là il y a une question ; j'attendrai sagement les réponses avant toute modification Nœud ou surface pour railway=station ? Christian m'a permis de passer outre à mes réticences envers les approximations de tracé, je déplacerai donc les tags sur une surface autour de la gare. Mais je m'interroge sur les dons de télépathie de Christian... Le débat n'avait pas permis de dégager un consensus clair pour l'une ou l'autre des solutions. J'en déduis que Christian a réussi à lire dans mes pensées que je commençai à me laisser convaincre par la solution « surface », privilégiant la rigueur cartographique plutôt que l'intérêt supposé des utilisateurs. Zigeuner [1] notamment dans le lien envoyé par Christian ( http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Compatibility_with_well_known_tags ) : The proposed tags can and do coexist with the well known tags. The usage of the new tags is recommended but not mandatory. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales terminé
Pour le nom de commune différent entre OSM et la COG sur la commune de Bois-Guillaume-Bihorel, il s'agit d'une fusion entre Bois-Guillaume et Bihorel au 1er janvier 2012, mais le tribunal administratif de Rouen a annulé, au mois de juin, la fusion et ils ont/avaient (je sais pas si cela est déjà fait) jusqu'au 31 décembre 2013 pour recréer les deux communes. Ce qui peux expliquer la différence. Un beau gâchis... Le 5 décembre 2013 14:05, Vincent Pottier vpott...@gmail.com a écrit : Le 05/12/2013 12:15, Pieren a écrit : 2013/12/5 Frédéric Rodrigo fred.rodr...@gmail.com: A propos de maintenance et de suivi des changements, comment conserver les limites précédentes lorsqu'elles changent ? Peut-être dans un export hors OSM tout simplement ? +1 Je suis contre le maintien d'anciennes limites administratives, même avec un admin_level farfelu. On peut toujours récupérer d'anciennes données dans la base. Si ça n'est pas trivial, surtout pour des relations, le plus simple serait des dump à intervalle régulier (tient, ça me rappelle les fichiers planet). +1, Avec des dumps périodiques (annuels, au 31 décembre ?). Ça veut dire aussi qu'on garantit dans les dumps qu'il n'y a pas de relation cassées, d'erreurs de code INSEE... Voi le problème de la coastline. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM 2 CSV : l'open data d'OSM pour tous publics ?
Le 5 décembre 2013 19:26, Christian Quest cqu...@openstreetmap.fr a écrit : Je partage tout à fait ton constat. Favoriser la réutilisation autre que le production de carte passe par des outils pour transformer les données OSM dans des formats moins géographiques. Il y a l'overpass-api qui permet déjà pas mal de choses, surtout des sorties en json en plus de l'XML habituel. On peut écrire des requêtes relativement compacte pour sélectionner des objets géographiquement et sémantiquement. Il manque juste des convertisseurs de formats à l'overpass pour sortir les résultats en: - geojson - csv - svg - kml Ce serait une évolution intéressante et très utile de l'overpass API ! Je précise cependant que http://overpass-turbo.eu/ permet l'export des résultats d'interrogation de l'overpass en geojson, gpx, kml et directement en geojson dans un Gist github. ... Ca démultiplierai les réutilisations et donc l'adoption d'OSM. A chaque hackathon où je suis présent comme mentor, je montre l'overpass et les développeurs découvre (enfin ?) à quoi OSM peut leur servir autrement que comme fond de carte pour remplacer Google... Le 5 décembre 2013 19:13, Charles Nepote char...@nepote.org a écrit : Bonjour à tous ! **Résumé du message** : comment diffuser et voir réutilisées les données d'OSM auprès d'un public plus large, qui, dans un cercle vertueux, pourra devenir contributeur. Souvent j'ai l'occasion de dire ici ou là que telle donnée est dispo dans OSM. Par ailleurs, je pousse depuis un certains temps les acteurs publics à référencer sur leurs portails les données d'OSM : ainsi de Montpellier, le CG de la Gironde, la Région PACA, etc. Mais aujourd'hui, les jeux de données ou les outils de consultation d'OSM ont du mal à répondre à plein de petits cas tout simples comme : je veux la liste des pharmacies de ma région. Et je veux pouvoir manipuler cette liste dans mon tableur favori parce que c'est l'outil que je connais bien. Je me suis donc interrogé : comment produit-on simplement des données d'OSM sous forme de fichiers CSV ? Je sais bien que tout n'est pas extractible en CSV mais il y a un champ d'usage immense sur les données comme : * les bâtiments publics * les médecins, hôpitaux, pharmacie... * les lieux/services de secours (casernes de pompier, défibrilateurs, pompes incendies, téléphones de secours) * les lieux de culture (Théâtres, Musées, etc.) * les lieux d'histoire et du patrimoine * les arrêts de transports en commun * les terrains/équipements sportifs * les lieux touristiques * les systèmes de surveillance (caméras de surveillance) * les commerces * les hameaux * les services relatifs aux déchets (bennes de recyclage, poubelles, déchetteries, composteurs publics, etc.) * etc. Je suis donc allé grenouiller dans les outils (je précise que je n'ai jamais installé QGIS, Postgis, etc., je n'ai jamais utilisé l'API OSM, je ne fais pas dev mais j'ai quelques années d'expérience sous Linux). Et le plus simple que j'ai trouvé c'est la combinaison de osmconvert e et osmfilter. http://wiki.openstreetmap.org/wiki/Osmconvert http://wiki.openstreetmap.org/wiki/Osmfilter Je peux obtenir le fichier CSV de toutes les pharmacies de PACA en 4 lignes de commande : $ wget http://download.geofabrik.de/europe/france/provence-alpes- cote-d-azur-latest.osm.pbf # télécharge le fichier OSM de la Région PACA $ ./osmconvert32 provence-alpes-cote-d-azur-latest.osm.pbf -o=provence-alpes-cote-d-azur-latest.o5m # conversion du dit fichier dans un format lisible pour osmfilter $ ./osmfilter32 provence-alpes-cote-d-azur-latest.o5m --keep=amenity=pharmacy PACA-pharmacies.o5m # filtrage proprement dit pour ne retenir que les pharmacies $ ./osmconvert32 PACA-pharmacies.o5m --all-to-nodes --csv=@id @lon @lat amenity shop name --csv-headline PACA-pharmacies.csv # conversion du fichier filtré en CSV (Peut-être qu'on peut faire encore plus simple et plus rapide mais cette méthode à l'avantage d'être scriptable et automatisable facilement pour publier ces fichiers sur un serveur web.) Résultat : 1220 pharmacies identifiées et géolocalisées. J'aurais pu ajouter les adresses, les téléphones, etc. quand ils sont renseignés (c'est rare). (Il y a cependant des petits problèmes dans ce fichier comme les distributeurs de préservatifs (n'est-ce pas utilisateur cquest http://www.openstreetmap.org/node/2368452297 :D .) Il faut compter environ 8-10 minutes pour l'ensemble du process sur ma machine (compris le téléchargement des 200+ Mo du fichier PACA). **Pourquoi je creuse ça ?** * OSM est une platforme déjà bien en place pour crowdsourcer énormément de données et s'enrichit à grande vitesse * OSM a une dimension nationale et internationale * Mais OSM a du mal à fournir ses données autrement que par la carte ou par des fichiers XML assez obscurs et difficiles à manipuler par le néophyte (je caricature un peu et je ne connais sans doute pas toutes les
[OSM-talk-fr] Dans name, le nom de commune au COG ou le terrain ?
Bonjour, Suite au message de christian concernant une comparaison nom COG et nom de commune dans OSM ici : https://lists.openstreetmap.org/pipermail/talk-fr/2013-December/064960.html On pourrait être tenté d'écraser les nom d'OSM avec la base du COG puisque dans COG il y a le O de officiel. Comme on sait que des fusions ou modifications ont pu avoir lieu depuis, il est préférable de vérifier si c'est le cas ou pas. Mais que faire des rares cas ou le terrain est en désaccord avec l'Officiel ? Prenons un exemple concret : http://www.openstreetmap.org/relation/122334 http://www.openstreetmap.org/node/924622799 Ne parlons pas de official_name et alt_name ici, je sais ce qu'il faut y mettre, la question, c'est ce qu'il faut mettre dans name Les courageux pourrons aller vérifier sur closedstreetview que les panneaux l'indiquent sans le -. Que wikipedia, dont la page talk où je suis intervenu donne une certaine explication du choix avec - et le cadastre, j'm'en souviens plus. Le terrain et les spécificité locales ? ou la normalisation et l'uniformisation à des sources de référence ? -- sly -- View this message in context: http://gis.19327.n5.nabble.com/Dans-name-le-nom-de-commune-au-COG-ou-le-terrain-tp5788782.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dans name, le nom de commune au COG ou le terrain ?
Que le maire (actuel) soit d'accord ou pas, ce qui compte c'est la publication au JO de l'arrêté fixant le nom de la commune. Il n'est pas impossible qu'un maire ou un conseil municipal plus tard décide d'utiliser un nom non officiel. De plus je ne me fierais pas au panneau, car des cas d'erreurs typographiques se produisent régulièrement, et nombre de panneaux abrègent les noms officiels (ou en rajoute en accolant par exemple un nom local ou régional ou encore une dénomination promotionnelle touristique dans le genre de Nom de commune - Perle de la Côte d'Emeraude ou Xyz Ville d'Histoire qui correspond à un label, ou volontairement ajouter une précision absente du nom officiel, mais levant une ambiguïté d'homonymie dans la région). Si un nouveau nom choisi par la commune est voulu, il lui appartient de faire enregistrer la décision municipale à la préfecture, pour l'avaliser au plan du droit, puis transmettre la demande pour une publication au JO après avoir notifié le ministères concerné, le gouvernement pouvant émettre un veto à la décision municipale, ce qui ne l'empêchera pas d'utiliser le nouveau nom dans ses communications, mais pas dans ses documents officiels, lequel ministère informera l'Insee qui mettra à jour sa base après publication au JO de l'arrêté préfectoral une fois passée la date d'entrée en vigueur mentionnée dans l'arrêté Donc pas avant le début de l'année suivante, car la collectivité devra d'abord terminer son exercice comptable avant de changer d'identité (et ne voudra sans doute pas payer les frais et la surcharge de travail administratif qu'entrainerait une clôture en milieu d'exercice, sans compter les difficultés que cela pose pour les statistiques annuelles que d'avoir deux exercices incomplets la même année dans deux entités d'identité distincte meˆme si l'une succède totalement à l'autre et conserve son code Insee). Le 6 décembre 2013 00:08, sylvain letuffe lis...@letuffe.org a écrit : Bonjour, Suite au message de christian concernant une comparaison nom COG et nom de commune dans OSM ici : https://lists.openstreetmap.org/pipermail/talk-fr/2013-December/064960.html On pourrait être tenté d'écraser les nom d'OSM avec la base du COG puisque dans COG il y a le O de officiel. Comme on sait que des fusions ou modifications ont pu avoir lieu depuis, il est préférable de vérifier si c'est le cas ou pas. Mais que faire des rares cas ou le terrain est en désaccord avec l'Officiel ? Prenons un exemple concret : http://www.openstreetmap.org/relation/122334 http://www.openstreetmap.org/node/924622799 Ne parlons pas de official_name et alt_name ici, je sais ce qu'il faut y mettre, la question, c'est ce qu'il faut mettre dans name Les courageux pourrons aller vérifier sur closedstreetview que les panneaux l'indiquent sans le -. Que wikipedia, dont la page talk où je suis intervenu donne une certaine explication du choix avec - et le cadastre, j'm'en souviens plus. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue à double nom
Dans ma ville de Belgique, toutes les rues on un double nom. Le nom en français et le nom en walon. :-) Piwi Le 05/12/13 19:08, Ralf Treinen a écrit : On Thu, Dec 05, 2013 at 04:38:14PM +0100, Francescu GAROBY wrote: Pas sûr que ce cas soit si rare que ça (bon, comparé au nombre de rues, ça reste rare) : j'imagine bien des rues servant de limite administrative entre 2 communes (incapables de s'entendre parce que de bords politiques différents ou autre chose encore), où un trottoir est dans la commune A et a un nom et l'autre trottoir se trouve dans la commune B et a un autre nom. Avec bien évidemment (quitte à bien faire chier les gens autant aller jusqu'au bout), des numérotations différentes. J'ai pas d'exemple à vous citer, mais avec 36.000 communes, ça m'étonnerait que le cas n'existe pas ! Il y a même un exemple à Paris : La rue de la Grande Truanderie et la rue de la Petite Truanderie dans le quartier des Halles : http://fr.wikipedia.org/wiki/Rue_de_la_Grande-Truanderie actuellement réalisé en OSM avec deux rues différentes. En réalité il s'agit d'une place triangulaire. -Ralf. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rue à double nom
Ça, ça se gère sans problème avec les tags 'name:langue', donc pas de souci :-) Francescu Le 6 décembre 2013 05:51, [Famille] Pierre WILLOT pie...@willot-martin.bea écrit : Dans ma ville de Belgique, toutes les rues on un double nom. Le nom en français et le nom en walon. :-) Piwi Le 05/12/13 19:08, Ralf Treinen a écrit : On Thu, Dec 05, 2013 at 04:38:14PM +0100, Francescu GAROBY wrote: Pas sûr que ce cas soit si rare que ça (bon, comparé au nombre de rues, ça reste rare) : j'imagine bien des rues servant de limite administrative entre 2 communes (incapables de s'entendre parce que de bords politiques différents ou autre chose encore), où un trottoir est dans la commune A et a un nom et l'autre trottoir se trouve dans la commune B et a un autre nom. Avec bien évidemment (quitte à bien faire chier les gens autant aller jusqu'au bout), des numérotations différentes. J'ai pas d'exemple à vous citer, mais avec 36.000 communes, ça m'étonnerait que le cas n'existe pas ! Il y a même un exemple à Paris : La rue de la Grande Truanderie et la rue de la Petite Truanderie dans le quartier des Halles : http://fr.wikipedia.org/wiki/Rue_de_la_Grande-Truanderie actuellement réalisé en OSM avec deux rues différentes. En réalité il s'agit d'une place triangulaire. -Ralf. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
