Re: [OSM-talk-fr] expérimentations à Orange
Désolé pour le retard de ma réponse. Je vais essayer de vous donner quelques éléments de réflexion. Après, je suis ouvert à toutes propositions. Guillaume Allegre wrote 1) la boundary est une frontière de canton, qui coïncide avec un bout de la frontière communale (Orange / Caderousse) http://www.openstreetmap.org/?way=171243851 mais qui n'est pas confondue (points distincts) Selon moi, elle devrait être confondue, en tant que limite communale ET limite de canton. J'ai demandé à Christian, dans le cadre d'une expérimentation pour l'intégration des bureaux de vote et de la carte électorale, d'importer les données issues de notre SIG. Il s'agit du découpage officiel et utilisé par les services pour leurs missions quotidiennes. On peut comparer ce travail au découpage des zones du document d'urbanisme (PLU), des Servitudes d'Utilité Publique ou des parcelles de la DGFiP (je dis bien de la DGFiP). Par conséquent, ces traçés, même si leur précision n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle alors qu'il ne le devrait pas, c'est quand même ce découpage qui est appliqué. Je pense donc, même si ce n'est pas juste, qu'il faut le laisser tel quel si l'on veut que les collectivités s'investissent dans OSM. Elles ne le feront pas si les limites officielles ne correspondent pas, à cette échelle, à ce qu'elles trouvent dans OSM. Guillaume Allegre wrote 2) le way polling_station a une résolution bien plus élevée (1 point par mètre dans les courbes), suivant les _anciens_ méandres de la Meyne, qui restent la limite communale comme ici : http://www.openstreetmap.org/?lat=44.08722lon=4.7789zoom=17layers=M A mon avis, c'est de la sur-résolution inutile, mais ça se discute. Cela n'enlève rien au point 1 : il faut choisir quelle limite on prend (171243851 ou 197278529), voire un intermédiaire en simplifiant la limite polling_station, mais il faut quand même à terme fusionner les deux. Même réponse qu'au-dessus Guillaume Allegre wrote 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus Effectivement, peut-être que le ref peut devenir le name Guillaume Allegre wrote 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs : highway = road addr:postcode = |84100 ref:orange = 84087V99 En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un code postal sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais tendance à le suivre sur ce point. J'ai pris le parti d'ajouter addr:postcode = 84100 sur les voies qui se trouvent dans la commune, en attendant d'avoir un outil qui me permette de sélectionner tous les objets présents à l'intérieur d'une frontière administrative. Le fait qu'elles aient |84100 veut dire qu'elles se trouvent en partie sur le territoire (pas forcément gauche et droite) et que je dois faire attention quand je les intègre. Guillaume Allegre wrote Ensuite : ref:orange : là, je pense qu'on a un problème à régler. orange n'est pas suffisamment distinctif. Si toutes les communes du monde se mettent à utiliser le même schéma, on va multiplier les conflits. Comment régler ça ? L'objectif est de pouvoir faire un lien systématique entre la voie dans OSM et celles dans la base communale. J'ai mis, à l'époque, ref:orange parce qu'il n'y avait rien de similaire et qu'il s'agit d'une réflexion que l'on mène sur plusieurs communes du Vaucluse. S'il faut changer de clé, cela ne me pose pas de problème mais il faut savoir que cela concernera d'abord les communes et non l'INSEE. On m'avait suggéré ref:84087, mais je trouvais cela redondant car dans mon identifiant,il y a déjà le code INSEE. De plus, c'est quelque chose qui peut se diffuser sur d'autres communes et nous aurions des tags ref:84087, ref:75001, ref:13205, etc... Il faudrait plutôt un tag du type ref:FR:commune= ou dans le genre. Guillaume Allegre wrote Je ne remets pas en cause l'utilisation d'OSM comme support de données métiers issues de SIG territoriaux, bien au contraire. Mais si, comme je le suppose, Orange tend à devenir une zone d'exemple et de démonstration pour cette convergence, il serait préférable que le schéma suivi soit aussi irréprochable que possible quant à l'intégration dans les conventions standard OSM. Alors, je pense qu'il faut sérieusement se pencher sur : - le schéma d'attributs et de références qui conviendrait à tout le monde - les conventions de fusion ou juxtaposition de données, et les précisions géométriques minimales/maximales acceptables. Je suis d'accord et je veux bien y participer -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755816.html Sent from the France mailing list archive at Nabble.com. ___
Re: [OSM-talk-fr] expérimentations à Orange
kimaidou wrote Bonjour, Sur l'idée de la base tierce, en effet je me suis un peu emballé. Je pensais à une application libre que chacun pourrait installer chez soi pour gérer les liens entre OSM et ses données métiers, si elles sont privées. Par contre, l'idée d'une base commune ferait encore sens pour les bases de données métiers libres (par exemple celles en ODBL libérées via l'opendata). Je ne pensais pas forcément à une super api qui gère les flux. Pourquoi pas à l'avenir. Mais dans un premier temps, une simple table qui stocke les liens entre objets osm et objets métiers suffit. On peut ensuite utiliser les outils comme osmWatch ou autre (à développer...) pour écouter les diffs, vérifier s'ils concernent des liens, puis lancer les actions (rss pour laisser manuellement, suppression automatique du lien, etc.). A noter qu'il n'est pas obligé d'avoir une vraie base de données métiers. Ce sytème fonctionnerait aussi bien sûr avec des fichiers de type CSV, tableau, etc. Tant que des objets métiers ont un identifiant, on peut créer un lien. Au sujet de la base tierce qui doit connaître les objets osm et les stocker chez elle, c'est vrai qu'il faut à un moment pouvoir lire les liens, par exemple pour comparer la donnée. Mais je ne vois pas de souci technique ici. On peut imaginer des outils * qui aident à créer les liens * qui aident à créer des données fusionnées via les liens (par exemple prend moi la géométrie OSM et colle y les colonnes A, B et C de ma table métier * qui alertent les personnes lorsqu'une donnée a été supprimée ou modifiée d'un côté ou de l'autre * qui montre les liens avec un système sympa de double panneau, etc. En fait, je dois quand même vous alerter sur un points : les collectivité sont de plus en plus consciente de l'intérêt de gérer en interne une base exhaustive de leur voirie. Or, cela sous-entend de pouvoir identifier chaque voie de manière unique dès la création de cette voie, d'où, l'identifiant. Qu'avons nous comme identifiant voirie : - Rivoli : c'est un code créé et géré par la DGFiP - l'ID de la BDAdresse : idem pour l'IGN Il faut donc créer un identifiant interne dans la commune car la commune est la source de cette information. Or, certaines communes ont déjà travaillé sur ce type de référentiel en interne, parfois même cartographié leur réseau. On ne peut pas leur demander de refaire le travail, d'où ma question : = OSM est-il capable de supporter un identifiant unique pour la voirie provenant directement des communes sans en avoir forcément la même structure (nous, on a pris CODE_INSEETYPENUMERO) ? Je pense que oui et que cela permettrait de faciliter les connexions entre les données de différentes bases (vous savez que je suis fan des passerelles entre bases de données). -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755819.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition pour le projet du mois de avril
Bonjour, alors quel projet a été choisi pour avril? il serait intéressant de le donner rapidement, quitte à laisser les débats sur l'ordre des suggestions pour les mois suivants, non? pour que l'on ne perde pas trop de temps au mois d'avril, et que l'on ait réellement l'ensemble des mois prochains pour les sujets suivants Merci en tout cas de cette initiative! @ bientôt adrien Le 4 avril 2013 20:33, Jo. perche...@gmail.com a écrit : Pour l'instant étant un peut seul dans mon coin, je fait mon micro mapping lors de mes déplacements en ville où je préfère marcher en laissant la voiture à l'autre bout de la ville pour éviter les embouteillages. Idem pour mes sessions course à pied où je mémorise de tête les éléments intéressant en attendant de rentrer à la maison. C'est même l'idéal pour contrôler une zone ajoutée depuis Bing. Le 4 avril 2013 20:21, PierreV belett...@hotmail.fr a écrit : Bonsoir, Je souhaite te féliciter pour la relance du projet! J'ai l'impression que mes propositions sur le wiki sont peut être passés inaperçues, mais pour moi je pense qu'il faudrait des projets qui permettent d'améliorer la qualité globale des données d'OSM. C'est pour cela que j'ai proposé que l'on fasse des projets du mois sur: Compléter/importer l'emplacement des mairies, églises, cimetières, offices de tourisme, bibliothèques, déchetteries, postes de police et pompiers, hôpitaux, maisons de retraite, pharmacies. Et aussi pour les établissements scolaires, et agences La poste pour lesquels ont a déja des outils de suivi. -- View this message in context: http://gis.19327.n5.nabble.com/Proposition-pour-le-projet-du-mois-de-avril-tp5755340p5755775.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- http://www.virage-energie-npdc.org/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap.org
Super merci ! Je cherchais récemment un démonstrateur pour les pistes de ski. Par contre, ça fait bizarre d'avoir les skieurs à l'envers sur le tire-fesses : http://www.opensnowmap.org/?zoom=16lat=45.913lon=6.58931layers=e=falsem=raster Fabien Le 4 avril 2013 21:33, yvecai yve...@gmail.com a écrit : Chers ami et béta-testeurs préférés, Je vous remerci d'avance de cliquer sur le lien ci-dessous et d'aller voir dans les coins si tout est comme il faut. C'est votre nouvelle carte pour les sports d'hivers : http://www.opensnowmap.org Au menu: * Serveur de tuiles Avec des données fraiches du jour, tout les matins * Infos sur les pistes d'un simple clic Plus de mode 'vecteur', beaucoup plus léger et meilleure compatibilité sur les navigateurs * Recherche des pistes par nom Les résultats Nominatim sont augmentés d'une sélection 'special ski' * Routage et dénivelés multi-modaux Montée en ski de descente, descente en remontée mécanique et raccourcis en raquettes, c'est possible ! * Forum Oui, un canal de plus, mais c'est essentiellement pour assurer la viabilité du site à long terme www.pistes-nordiques.org est ainsi voué à disparaitre au profit de ce nouveau site, dédié à l'ensemble des sports d'hiver. Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap.org
Le jeudi 4 avril 2013 21:33:46 yvecai a écrit : Chers ami et béta-testeurs préférés, Je vous remerci d'avance de cliquer sur le lien ci-dessous et d'aller voir dans les coins si tout est comme il faut. C'est votre nouvelle carte pour les sports d'hivers : http://www.opensnowmap.org Merci Yves pour ce site. J'ai découvert récemment qu'un foyer de ski de fond près de chez moi utilisait des fond de carte OSM pour son dépliant. Ça m'a motivé pour avancer la cartographie de leur petit domaine, et leur montrer ton site pour la prochaine saison. Avec ce nouveau rendu, c'est encore plus beau :-) Il me semble qu'avant les différentes pistes étaient superposées ? En tout cas, là c'est bien clair. * Infos sur les pistes d'un simple clic Plus de mode 'vecteur', beaucoup plus léger et meilleure compatibilité sur les navigateurs Là, par contre, je n'y arrive pas. Par ailleurs, une petite légende sur le bouton i qui est sur le cartouche serait pas mal. Suggestion : ajouter d'autres POI, comme les lieu de restauration, les foyers hors-sac, la billeterie, le départ des pistes, … Merci -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap.org
Le vendredi 5 avril 2013 09:05:20 Nicolas Dumoulin a écrit : * Infos sur les pistes d'un simple clic Plus de mode 'vecteur', beaucoup plus léger et meilleure compatibilité sur les navigateurs Là, par contre, je n'y arrive pas. Par ailleurs, une petite légende sur le bouton i qui est sur le cartouche serait pas mal. Bon, en fait, en cliquant sur ce i puis sur une piste, ça démarre le calcul d'itinéraire et affiche les pistes empruntées. Mais je n'arrive pas à obtenir des détails sur les pistes elles-mêmes. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples
Le jeudi 4 avril 2013 20:10:20 JB a écrit : C'est en train d'uploader, sous http://osm107.openstreetmap.fr/jbtopo/besancon25.png Ha oui, c'est assez joli comme rendu. J'aurai préféré du mapnik, mais là je dois avouer que j'oublie presque que c'est du maperitive ;-) Beau boulot ! -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples
Voici deux essais de diminution de la visibilité des tunnels ferroviaires. J'ai tendance à préférer le plus discret des deux. Et vous ? http://osm107.openstreetmap.fr/jbtopo/tunnel1.png http://osm107.openstreetmap.fr/jbtopo/tunnel.png , plus discret JB. (oui, je sais, la voie ferrée est encore au dessus. Les courbes de niveau aussi, d'ailleurs) Le 04.04.2013 21:02, Etienne Trimaille a écrit : Le 4 avril 2013 20:10, JB jb...@mailoo.org a écrit : C'est en train d'uploader, sous http://osm107.openstreetmap.fr/jbtopo/besancon25.png [1] Il y a un petit bug de rendu : le tunnel ferré de Morre : http://tile.openstreetmap.fr/?zoom=17lat=47.22244lon=6.07422layers=B0 [3] Sur ton rendu, il est dessiné par dessus les routes alors qu'il doit être en-dessous. Alors que sur la même extrait de ta carte, le tunnel de Chalezeule est dessiné sous les routes : http://tile.openstreetmap.fr/?zoom=17lat=47.25423lon=6.05837layers=B0 [4] N'est-il pas possible de réduire un peu la visibilité des tunnels en général ? A part les entrées et les tunnels, les tunnels ne sont pas visibles ;-) cquest, les bugs des tunnel est présent aussi sur osmfr, même si ce n'est pas très visible. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr [2] Links: -- [1] http://osm107.openstreetmap.fr/jbtopo/besancon25.png [2] http://lists.openstreetmap.org/listinfo/talk-fr [3] http://tile.openstreetmap.fr/?zoom=17amp;lat=47.22244amp;lon=6.07422amp;layers=B0 [4] http://tile.openstreetmap.fr/?zoom=17amp;lat=47.25423amp;lon=6.05837amp;layers=B0 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples
Le vendredi 5 avril 2013 09:18:35 JB a écrit : Voici deux essais de diminution de la visibilité des tunnels ferroviaires. J'ai tendance à préférer le plus discret des deux. Et vous ? http://osm107.openstreetmap.fr/jbtopo/tunnel1.png http://osm107.openstreetmap.fr/jbtopo/tunnel.png , plus discret Je suis d'accord, le second est plus joli -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Opensnowmap.org
Quel détails te manque t il ? Normalement, il s'affichent dans la boîte qui s'ouvre après un clic sur la piste. Yves - Reply message - De : Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net Pour : Discussions sur OSM enfrançais talk-fr@openstreetmap.org Objet : [OSM-talk-fr] Opensnowmap.org Date : ven., avr. 5, 2013 09:10 Le vendredi 5 avril 2013 09:05:20 Nicolas Dumoulin a écrit : * Infos sur les pistes d'un simple clic Plus de mode 'vecteur', beaucoup plus léger et meilleure compatibilité sur les navigateurs Là, par contre, je n'y arrive pas. Par ailleurs, une petite légende sur le bouton i qui est sur le cartouche serait pas mal. Bon, en fait, en cliquant sur ce i puis sur une piste, ça démarre le calcul d'itinéraire et affiche les pistes empruntées. Mais je n'arrive pas à obtenir des détails sur les pistes elles-mêmes. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème
Autre question: as-tu testé l'affichage des noms de rues pour les fort zoom? Romain Le 4 avril 2013 21:33, Romain MEHUT romain.me...@gmail.com a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples
Le 05/04/2013 09:18, JB a écrit : Voici deux essais de diminution de la visibilité des tunnels ferroviaires. J'ai tendance à préférer le plus discret des deux. Et vous ? http://osm107.openstreetmap.fr/jbtopo/tunnel1.png http://osm107.openstreetmap.fr/jbtopo/tunnel.png , plus discret JB. Désolé de renouveler ma demande, mais je pense que tu ne l'as pas lue la première fois. N'envoie pas tes messages au format HTML, utilise du texte simple. Merci d'avance. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème
Non… parce que je n'ai pas prévu les zooms forts. Ça pose beaucoup de nouvelles problématiques, dont certaines encore mal gérées par maperitive (voir le nombre de votes pour cette proposition : http://maperitive.idea.informer.com/proj/?ia=25923). Et je pense que si je veux le faire, il faut que je fasse un réel multi-zoom pour adapter la largeur des voies pour que le texte rendre dedans et ne déborde pas sur les bâtiments autour (c'est souvent la rue qui déborde dessus, et le texte sur la rue). Francetopo commence à faire apparaitre les noms de rue avec parcimonie au 5000ème, soit 25 fois plus d'espace qu'au 25000. JB. Le 05.04.2013 09:26, Romain MEHUT a écrit : Autre question: as-tu testé l'affichage des noms de rues pour les fort zoom? Romain Le 4 avril 2013 21:33, Romain MEHUT romain.me...@gmail.com a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr [1] Links: -- [1] http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Opensnowmap.org
Le vendredi 5 avril 2013 09:21:29 yve...@gmail.com a écrit : Quel détails te manque t il ? Normalement, il s'affichent dans la boîte qui s'ouvre après un clic sur la piste. Yves Ben moi, j'aimerai que cliquer une piste me mette en évidence la piste pour la distinguer des autres, car deux pistes peuvent avoir des tronçons en commun, par exemple ici : http://www.opensnowmap.org/?zoom=15lat=45.62994lon=2.87237layers=e=falsem=raster Si je clique sur la piste rouge qui part à l'ouest, ça me dit Chevalard, OK. Mais par où passe cette piste après avoir rejoint la bleu ? Quelle distance fait-elle ? Quel est son profil ? Je peux avoir les infos d'un itinéraire en ajoutant mes points, mais je peux aussi me dire « si je suis la piste machin, ça fait quoi ? » En passant, la liste des pistes empruntées ont une petite icône sur la gauche. Mais dans mon cas, l'URL est à undefined. Peut-être une histoire de tag nordic/skating … ? Merci -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Il me semble qu'un numéro de référence unique de la voirie doit effectivement se baser sur le code rivoli/fantoir et le code insee de la commune. Comme toujours, il faut regarder les cas particuliers... par exemple comment gérer une rue qui est la limite entre deux communes ? Ce simple cas particulier me laisse penser qu'il faudrait une référence combinée INSEE+FANTOIR et ça sera plus léger que d'avoir 2 tags. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Forum ESRI - Aix-en-Provence
Bonjour à tous, ESRI à organise chaque année une série de 9 forums décentralisés. Le premier d'entre-eux à eu lieu hier (le 4 avril) à Aix-en-Provence. ESRI m'a proposé d'intervenir comme témoin sur le thème Ouvrir son SIG : l'expérience de la Ville d'Orange http://www.esrifrance.fr/forumsSIG.aspx Pour ceux qui étaient présents au SOTM à Lyon en février, j'ai présenté le travail fait sur l'adressage. Du coup, j'ai eu des discutions intéressantes par la suite et je vous donne les grandes lignes : - Outre les collectivités qui veulent mettre en place la même démarche, des sociétés s'intéressent à OSM et souhaitent développer des solutions autour d'OSM. - ERSI France souhaite aller plus loin dans l'utilisation des données OSM et proposer des outils et des solutions à leur clients et, notamment développer ce marché sur le continent africain. - l'AITF, via Yves MEO, Animateur du groupe de travail Régional SIG/TOPO, souhaite organiser un séminaire en fin d'année et nous inviter pour présenter notre travail et que l'AITF se penche sérieusement sur l'utilisation des données OSM dans les collectivité. - Etant aussi le chef du service de l'Information Géographique de la CommunautéUrbaine Marseille Provence Métropole (MPM), Yves Méo a été intéressé par la démarche. - l'IGN confirme son intérêt pour OSM et j'ai proposé qu'on puisse travailler sur l'adressage. -- View this message in context: http://gis.19327.n5.nabble.com/Forum-ESRI-Aix-en-Provence-tp5755839.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
cquest wrote Il me semble qu'un numéro de référence unique de la voirie doit effectivement se baser sur le code rivoli/fantoir et le code insee de la commune. Comme toujours, il faut regarder les cas particuliers... par exemple comment gérer une rue qui est la limite entre deux communes ? Ce simple cas particulier me laisse penser qu'il faudrait une référence combinée INSEE+FANTOIR et ça sera plus léger que d'avoir 2 tags. Les collectivités ne pourront pas utiliser les codes fantoir de la DGFiP : - parce qu'ils sont créés par la DGFiP a posteriori, après que la commune ait transmis la délibération aux impôts, que ces derniers aient intégré ces infos dans leur base et que ces données aient été renvoyées aux communes. Il peut se passer plusieurs mois, voire plus. - il y a des doublons dans les fantoir, et des codes fantoir qui pointent sur des voies qui n'existent plus. Si les communes qui se sont penché sur le problème ont décidé de créer leur propre identifiant unique, c'est que c'était la seule solution. L'inconvénient étant que la très grande majorité des communes n'ont pas encore fait ce travail. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755840.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples
-Message d'origine- De : Nicolas Dumoulin [mailto:nicolas_openstreetmap@dumoulin63.net] Envoyé : vendredi 5 avril 2013 09:21 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples Le vendredi 5 avril 2013 09:18:35 JB a écrit : Voici deux essais de diminution de la visibilité des tunnels ferroviaires. J'ai tendance à préférer le plus discret des deux. Et vous ? http://osm107.openstreetmap.fr/jbtopo/tunnel1.png http://osm107.openstreetmap.fr/jbtopo/tunnel.png , plus discret Je suis d'accord, le second est plus joli Pareil. Pour ailleurs, je trouve le rendu des lignes ferrées perfectible (un peu pâté) quand celles-ci sont tracées à la voie. L'emprise de la voie (file de rails + intervoie) est d'environ 6 mètres soit 0,4 mm pour une carte au 1:25.000. A voir si tu ne peux pas affiner un peu le rendu. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Compteur électrique
Bonjour à tous, J'ai eu une bonne question de la part d'un de mes collègues. Peut-on localiser dans OSM les compteurs électriques (techniquement et légalement) ? Si oui, comment ? Si c'est possible, il nous faudra une petite application permettant de localiser le compteur, d'inscrire son numéro et de prendre une photo. Développeurs, à vos souris... -- View this message in context: http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Compteur électrique
Je ne comprends pas. Vous voulez situer tous les compteurs électriques de toutes les maisons ?? Le 5 avril 2013 09:51, Tony Emery tony.em...@yahoo.fr a écrit : Bonjour à tous, J'ai eu une bonne question de la part d'un de mes collègues. Peut-on localiser dans OSM les compteurs électriques (techniquement et légalement) ? Si oui, comment ? Si c'est possible, il nous faudra une petite application permettant de localiser le compteur, d'inscrire son numéro et de prendre une photo. Développeurs, à vos souris... -- View this message in context: http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Les dérives de rue : Le papillon d’hiver (le film)http://drivrsdu.fr/le-papillon-dhiver-le-film/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Compteur électrique
Ista Pouss wrote Je ne comprends pas. Vous voulez situer tous les compteurs électriques de toutes les maisons ?? Non, ouf!! ceux qui concernent des bâtiments municipaux -- View this message in context: http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755847.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Réunion des contributeurs ardéchois
Bonjour, Réunion des contributeurs ardéchois et des personnes interressés par le projet : le mercredi 10 avril 2013 de 18h à 20h à la salle de réunion des Inforoutes, ZI du Lac, InnoParc à Privas 07. Nouveau : une liste de diffusion spécifique à notre département : inscrivez vous sur http://listes.openstreetmap.fr/wws/subscribe/local-ardeche Détails sur http://wiki.openstreetmap.org/wiki/Mappeurs_Ardechois Contact : Henry-Pascal ELDIN, el...@inforoutes.fr , 06 84 11 70 35 04 75 30 79 15 http://www.openstreetmap.org/?lat=44.717213lon=4.609967zoom=18layers=M -- Cordialement, Henry-Pascal ELDIN Courayon, Route de St Bauzile 07210 CHOMERAC, FRANCE Tel 04 75 65 19 93 Orange 06 80 75 74 80 http://www.eldin.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples
Après affinage des voies ferrées : http://osm107.openstreetmap.fr/jbtopo/rail.png Je ne pense pas que j'irai plus loin. Il n'y a pas toujours un lien exact entre la largeur d'un élément sur la carte et dans la réalité (largeur des routes et les autoroutes ?). Les voies ferrées posent un problème supplémentaire : une voie ferrée seule, ça va. Deux voies ou plus, ça fait des dégâts. La superposition des dessins de l'une avec l'autre ne donne pas toujours des résultats très heureux. Les pointillés blanc-noir, je n'aime pas beaucoup, les traits en travers, c'est pas très heureux, d'où ce dessin « paté », qui permet de passer pour une voie seule, ou deux voies parallèles sans faire de rupture de style. JB. Le 05.04.2013 09:49, HELFER Denis a écrit : -Message d'origine- De : Nicolas Dumoulin [mailto:nicolas_openstreetmap@dumoulin63.net] Envoyé : vendredi 5 avril 2013 09:21 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples Le vendredi 5 avril 2013 09:18:35 JB a écrit : Voici deux essais de diminution de la visibilité des tunnels ferroviaires. J'ai tendance à préférer le plus discret des deux. Et vous ? http://osm107.openstreetmap.fr/jbtopo/tunnel1.png [1] http://osm107.openstreetmap.fr/jbtopo/tunnel.png [2] , plus discret Je suis d'accord, le second est plus joli Pareil. Pour ailleurs, je trouve le rendu des lignes ferrées perfectible (un peu pâté) quand celles-ci sont tracées à la voie. L'emprise de la voie (file de rails + intervoie) est d'environ 6 mètres soit 0,4 mm pour une carte au 1:25.000. A voir si tu ne peux pas affiner un peu le rendu. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr [3] Links: -- [1] http://osm107.openstreetmap.fr/jbtopo/tunnel1.png [2] http://osm107.openstreetmap.fr/jbtopo/tunnel.png [3] http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexion sur les sens uniques (ou pas) dans les ronds-points
Non le bug ne se situait pas dans le sens de traçage du rond-point car il m'a inversé le sens pendant que je faisais le tour du rond-point. Tu as peut-être raison Hendrik, je vais vérifier si je n'avais pas activé le mode piéton par mégarde. :-) Nicolas J'en pense que Osmand prend bien en charge le sens des rond points et qu'il ne faut pas mettre un oneway=yes en plus... Dans les pays en conduite à gauche on dessite les rond points en sens inverse et le oneway=yes reste implicite, exactement comme en France. Tu es peut-être en mode piéton et pas en mode voiture voiture? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples
-Message d'origine- De : JB [mailto:jb...@mailoo.org] Envoyé : vendredi 5 avril 2013 10:51 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples Après affinage des voies ferrées : http://osm107.openstreetmap.fr/jbtopo/rail.png Je ne pense pas que j'irai plus loin. Il n'y a pas toujours un lien exact entre la largeur d'un élément sur la carte et dans la réalité (largeur des routes et les autoroutes ?). Les voies ferrées posent un problème supplémentaire : une voie ferrée seule, ça va. Deux voies ou plus, ça fait des dégâts. La superposition des dessins de l'une avec l'autre ne donne pas toujours des résultats très heureux. Les pointillés blanc-noir, je n'aime pas beaucoup, les traits en travers, c'est pas très heureux, d'où ce dessin « paté », qui permet de passer pour une voie seule, ou deux voies parallèles sans faire de rupture de style. JB. Oui, les voies ferrées c'est compliqué, je ne dirais pas le contraire. Je me pencherai sur la question de manière plus approfondie dès que j'aurai un moment. On pourrait juste voir que cela donne sur un triage, genre Metz-Sablon (http://osm.org/go/0DF5G2aT--) ou Hausbergen (http://osm.org/go/0DMuuZku--) ? Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] cadastre.openstreetmap.fr HS
Des nouvelles concernant le retour de cadastre.openstreetmap.fr ? C'est pas que je suis en manque, mais presque... ;-) Nicolas Le 25/03/2013 23:23, Cyrille Giquello a écrit : Merci Jocelyn ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] cadastre.openstreetmap.fr HS
Le vendredi 5 avril 2013 11:14:12 Nicolas Moyroud a écrit : Des nouvelles concernant le retour de cadastre.openstreetmap.fr ? C'est pas que je suis en manque, mais presque... ;-) +1 J'ai la flemme de construire les fichiers moi-même, et j'aimerai mettre à jour mon coin. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/5 Tony Emery tony.em...@yahoo.fr Qu'avons nous comme identifiant voirie : - Rivoli : c'est un code créé et géré par la DGFiP - l'ID de la BDAdresse : idem pour l'IGN Il faut donc créer un identifiant interne dans la commune car la commune est la source de cette information. Donc chaque rue a trois identifiants uniques. Qui a parlé de simplification administrative ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples
Ha, la zone que je me suis interdit de faire, en pensant que ça donnerait un paté noir au 25000 : http://osm107.openstreetmap.fr/jbtopo/triage.png Ça ne gagnerait pas un concours de beauté, mais je pense que ça montre ce que c'est : plein de rails (euh, je retire, il ne faut surement pas dire ça à quelqu'un qui travaille sur les voies ferrées…), leur orientation, ce n'est pas encore un aplat noir. Il me semble que tu disais travailler sur un rendu rail, si tu as des suggestions pour rendre une voie ferrée qui évite tous les problèmes indiqués, je suis preneur. JB. (Tiens, ça me montre que j'avais une boulette sur area[turn_table]…) Le 05.04.2013 11:02, HELFER Denis a écrit : -Message d'origine- De : JB [mailto:jb...@mailoo.org] Envoyé : vendredi 5 avril 2013 10:51 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples Après affinage des voies ferrées : http://osm107.openstreetmap.fr/jbtopo/rail.png [1] Je ne pense pas que j'irai plus loin. Il n'y a pas toujours un lien exact entre la largeur d'un élément sur la carte et dans la réalité (largeur des routes et les autoroutes ?). Les voies ferrées posent un problème supplémentaire : une voie ferrée seule, ça va. Deux voies ou plus, ça fait des dégâts. La superposition des dessins de l'une avec l'autre ne donne pas toujours des résultats très heureux. Les pointillés blanc-noir, je n'aime pas beaucoup, les traits en travers, c'est pas très heureux, d'où ce dessin « paté », qui permet de passer pour une voie seule, ou deux voies parallèles sans faire de rupture de style. JB. Oui, les voies ferrées c'est compliqué, je ne dirais pas le contraire. Je me pencherai sur la question de manière plus approfondie dès que j'aurai un moment. On pourrait juste voir que cela donne sur un triage, genre Metz-Sablon (http://osm.org/go/0DF5G2aT-- [2]) ou Hausbergen (http://osm.org/go/0DMuuZku-- [3]) ? Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr [4] Links: -- [1] http://osm107.openstreetmap.fr/jbtopo/rail.png [2] http://osm.org/go/0DF5G2aT-- [3] http://osm.org/go/0DMuuZku-- [4] http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/5 Tony Emery tony.em...@yahoo.fr Par conséquent, ces traçés, même si leur précision n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle alors qu'il ne le devrait pas, c'est quand même ce découpage qui est appliqué. Je pense donc, même si ce n'est pas juste, qu'il faut le laisser tel quel si l'on veut que les collectivités s'investissent dans OSM. Ce point est capital avec OSM. C'est la violation d'un principe de base du projet : les données doivent pouvoir être améliorées par les contributeurs, sinon elles n'ont pas leur place dans la base. Aucune donnée ne doit pouvoir être bloquée dans OSM sous prétexte d'officialité, encore plus si elles sont mauvaises. Je renverrais la lecture d'un fil de discussion de référence sur ce thème (en anglais) : http://lists.openstreetmap.org/pipermail/talk/2009-March/034948.html Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Pieren wrote 2013/4/5 Tony Emery lt; tony.emery@ gt; Qu'avons nous comme identifiant voirie : - Rivoli : c'est un code créé et géré par la DGFiP - l'ID de la BDAdresse : idem pour l'IGN Il faut donc créer un identifiant interne dans la commune car la commune est la source de cette information. Donc chaque rue a trois identifiants uniques. Qui a parlé de simplification administrative ? Pieren Effectivement, sans parler de l'ID de la BDAdresse que je n'utilise pas, j'ai : - le RIVOLI de la DGFIP (en plus, j'ai 44 voies sur les 730 qui n'ont pas de rivoli) - l'identifiant interne géré par la mairie - l'identifiant OSM Après, on ne peut pas parler de simplification administrative puisqu'il ne s'agit pas de la même institution. Je pense que tu dois avoir la même chose à la poste, au niveau des conseil généraux, ... -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755862.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples
-Message d'origine- De : JB [mailto:jb...@mailoo.org] Envoyé : vendredi 5 avril 2013 11:31 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples Ha, la zone que je me suis interdit de faire, en pensant que ça donnerait un paté noir au 25000 : http://osm107.openstreetmap.fr/jbtopo/triage.png Ça ne gagnerait pas un concours de beauté, mais je pense que ça montre ce que c'est : plein de rails (euh, je retire, il ne faut surement pas dire ça à quelqu'un qui travaille sur les voies ferrées…), leur orientation, ce n'est pas encore un aplat noir. Il me semble que tu disais travailler sur un rendu rail, si tu as des suggestions pour rendre une voie ferrée qui évite tous les problèmes indiqués, je suis preneur. JB. (Tiens, ça me montre que j'avais une boulette sur area[turn_table]…) Franchement, c'est pas (trop) mal. J'ai dit que j'allais consacrer un peu de temps dès que j'en aurai de rab. S'il y a des choses intéressantes, je ne manquerai pas de les partager. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/5 Tony Emery tony.em...@yahoo.fr Après, on ne peut pas parler de simplification administrative puisqu'il ne s'agit pas de la même institution. Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour l'instant, chaque institution construit la sienne à grands frais (enfin, surtout aux frais des contribuables et des usagers). Mon rêve : une base adresse unifiée, publique, réutilisable librement et avec un code de voie vraiment unique adoptée par toutes les institutions. Vous avez dit trop simple ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition pour le projet du mois de avril
J'ai écrit une proposition godasse pour OpenStreeetBugs, n'hésitez pas à enrichir. - http://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/OpenStreetBugs A la fin il y a la possibilité de faire des statistiques, mais je ne sais pas extraire les statistiques française depuis les fichiers SQL quotidien, la ville la plus proche est systématiquement indiqué et le code [FR] est présent, cela devrait être facile. -- Jean-Baptiste Holcroft Le 5 avril 2013 08:52, adrien carpentier ad.carpent...@gmail.com a écrit : Bonjour, alors quel projet a été choisi pour avril? il serait intéressant de le donner rapidement, quitte à laisser les débats sur l'ordre des suggestions pour les mois suivants, non? pour que l'on ne perde pas trop de temps au mois d'avril, et que l'on ait réellement l'ensemble des mois prochains pour les sujets suivants Merci en tout cas de cette initiative! @ bientôt adrien Le 4 avril 2013 20:33, Jo. perche...@gmail.com a écrit : Pour l'instant étant un peut seul dans mon coin, je fait mon micro mapping lors de mes déplacements en ville où je préfère marcher en laissant la voiture à l'autre bout de la ville pour éviter les embouteillages. Idem pour mes sessions course à pied où je mémorise de tête les éléments intéressant en attendant de rentrer à la maison. C'est même l'idéal pour contrôler une zone ajoutée depuis Bing. Le 4 avril 2013 20:21, PierreV belett...@hotmail.fr a écrit : Bonsoir, Je souhaite te féliciter pour la relance du projet! J'ai l'impression que mes propositions sur le wiki sont peut être passés inaperçues, mais pour moi je pense qu'il faudrait des projets qui permettent d'améliorer la qualité globale des données d'OSM. C'est pour cela que j'ai proposé que l'on fasse des projets du mois sur: Compléter/importer l'emplacement des mairies, églises, cimetières, offices de tourisme, bibliothèques, déchetteries, postes de police et pompiers, hôpitaux, maisons de retraite, pharmacies. Et aussi pour les établissements scolaires, et agences La poste pour lesquels ont a déja des outils de suivi. -- View this message in context: http://gis.19327.n5.nabble.com/Proposition-pour-le-projet-du-mois-de-avril-tp5755340p5755775.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- http://www.virage-energie-npdc.org/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Pieren, Je plussoie ! On parle d'opendata, mais cette base unifiée dont tu parles, en ODBL, avec une api sympa pour y accéder, ce serait l'idéal ! Le 5 avril 2013 11:54, Pieren pier...@gmail.com a écrit : 2013/4/5 Tony Emery tony.em...@yahoo.fr Après, on ne peut pas parler de simplification administrative puisqu'il ne s'agit pas de la même institution. Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour l'instant, chaque institution construit la sienne à grands frais (enfin, surtout aux frais des contribuables et des usagers). Mon rêve : une base adresse unifiée, publique, réutilisable librement et avec un code de voie vraiment unique adoptée par toutes les institutions. Vous avez dit trop simple ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Opensnowmap.org
Le vendredi 5 avril 2013 12:19:15 yve...@gmail.com a écrit : Oui, un retour genre surbrillance au survol de la liste sera sûrement implanté, mais j'ai pas encore la solution. C'est sur quelle piste ce pb d'icône? Sur à peu près toutes les pistes du domaine de Pessade : http://www.opensnowmap.org/?zoom=15lat=45.62994lon=2.87237layers=e=falsem=raster -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition pour le projet du mois de avril
De: Jean-Baptiste Holcroft jb.holcr...@gmail.com J'ai écrit une proposition godasse pour OpenStreeetBugs, n'hésitez pas à enrichir. - http://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/OpenStreetBugs Salut, En cliquant sur le lien j obtiens une page wiki vide indiquant qu elle ne contient pas de texte A la fin il y a la possibilité de faire des statistiques, mais je ne sais pas extraire les statistiques française depuis les fichiers SQL quotidien, la ville la plus proche est systématiquement indiqué et le code [FR] est présent, cela devrait être facile. Si les personnes effectuant des corrections le font dans des changesets dedies et ajoutent un tag particulier ( a definir ) sur leurs changesets ou dans le commentaire du changesets je pourrais extraire des stats Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap.org
Bonjour Le 04/04/2013 21:33, yvecai a écrit : Chers ami et béta-testeurs préférés, Je vous remerci d'avance de cliquer sur le lien ci-dessous et d'aller voir dans les coins si tout est comme il faut. Est-ce un bug ou une mal interprétation des étiquettes : Super-Besse Les pistes de ski sont étiquetées de 2 façons (comme les cours d'eau) : le chemin qui définit la piste, mais une zone qui définit l'emplacement de surface que prend la piste. Or, Opensnowmap intégre les zones comme étant une piste. l'étiquette snow_park dessine bien une zone concernant l'emprise du parc. Il faudrait peut-être que les zones définies par les étiquettes area=yes associé à piste:type=donwhill désinnent une zone de couleur lié à l'étiquette piste:difficulty sur la carte et non un trait Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Compteur électrique
Bonjour, Il y a actuellement deux propositions en cours de construction sur le Wiki concernant ce genre d'item. Je vous invite à les consulter et à prendre part aux échanges si vous pensez pouvoir proposer un tel ajout dans l'une d'entre-elles. La 1ere concerne le transport de l'électricité, de la production au consommateur et donc sur des réseaux en partie basse tension munis de compteurs (pouvant symboliser la toute fin de la chaine). http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement La 2nde est orientée poste de transformation, dont le street-level avec les armoires de répartition pouvant contenir des compteurs. http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement Une petite question: qu'est-ce qui pourrait différencier le compteur d'un bâtiment municipal et celui d'une emprise privée? Bonne journée. Le 5 avril 2013 10:14, Tony Emery tony.em...@yahoo.fr a écrit : Ista Pouss wrote Je ne comprends pas. Vous voulez situer tous les compteurs électriques de toutes les maisons ?? Non, ouf!! ceux qui concernent des bâtiments municipaux -- View this message in context: http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755847.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 5 avril 2013 12:27, kimaidou kimai...@gmail.com a écrit : Pieren, Je plussoie ! On parle d'opendata, mais cette base unifiée dont tu parles, en ODBL, avec une api sympa pour y accéder, ce serait l'idéal ! Le 5 avril 2013 11:54, Pieren pier...@gmail.com a écrit : 2013/4/5 Tony Emery tony.em...@yahoo.fr Après, on ne peut pas parler de simplification administrative puisqu'il ne s'agit pas de la même institution. Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour l'instant, chaque institution construit la sienne à grands frais (enfin, surtout aux frais des contribuables et des usagers). Mon rêve : une base adresse unifiée, publique, réutilisable librement et avec un code de voie vraiment unique adoptée par toutes les institutions. Vous avez dit trop simple ? Je n'y crois pas du tout. Peut être est-ce bon pour l'Administration, mais il est sûr que c'est mauvais pour la géographie, et il n'est pas clair que ce soit bon pour la cartographie. Quand à savoir si c'est bon pour l'humain... Que l'Administration n'y arrive même pas, alors que ça parait si trop simple, devrait donner quelques doutes sur l'idée... mais pour les certitudes il est plus facile d'invoquer la lourdeur administrative, j'admets. Quelques éléments de doute ?... comment une adresse est-elle en rapport avec une voie ? comment se fait la synchronisation personne-adresse-voie ? et j'en passe. En informatique, si les identifiants uniques restent un outil majeur, les identifiants par rapport à un contexte, une identité, et quelques fois à un ordre, gagnent de plus en plus de terrain, c'est pas pour des prunes. XML Schéma, par exemple, les définit ainsi, contredisant (reculant, dirais-tu ? ) le système des DTD qui définissait les identifiants de façon absolue. C'est pas pour se faire plaisir, mais parce que dans un contexte hétérogène les identifiants uniques ça coince très vite. (à mais oui c'est vrai que XML c'est looouuud) OSM, je crois, est trop centré administration française. C'est pour ça qu'on croit voir sur le terrain tant de objets qui pourraient avoir un identifiant unique... et que, finalement, on ne sache même pas si une clairière est un trou ou un objet qui ferait ou non partie de la forêt. Que la collaboration avec l'administration aide à se valoriser, à travailler, à faire son mai 68 open data est une chose. Mais qu'on se mette à donner des leçons à cet administration en est une autre. Et que l'on comprenne comment est-ce que l'on peut rendre compte du terrain sur une carte, encore une autre. Pour ça les questions d'identités, non les numéros, sont The Good Way To Do May Be. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] cadastre.openstreetmap.fr HS
+ 1000 D'autant que j'ai une formation à Josm ce soir (à 19h) et que j'aurais aimé l'avoir, pour expliquer l'import cadastral. Francescu Le 5 avril 2013 11:17, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le vendredi 5 avril 2013 11:14:12 Nicolas Moyroud a écrit : Des nouvelles concernant le retour de cadastre.openstreetmap.fr ? C'est pas que je suis en manque, mais presque... ;-) +1 J'ai la flemme de construire les fichiers moi-même, et j'aimerai mettre à jour mon coin. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] cadastre.openstreetmap.fr HS
Le Fri, 5 Apr 2013 14:26:29 +0200, Francescu GAROBY windu...@gmail.com a écrit : + 1000 D'autant que j'ai une formation à Josm ce soir (à 19h) et que j'aurais aimé l'avoir, pour expliquer l'import cadastral. Francescu +1001 J'assiste à cette formation :) -- Emmanuel Lesouef http://ecozac.louvigny.free.fr signature.asc Description: PGP signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Compteur électrique
François Lacombe wrote Une petite question: qu'est-ce qui pourrait différencier le compteur d'un bâtiment municipal et celui d'une emprise privée? Si c'est l'angle de la saisie, l'idée que nous avons est de localiser tous les compteurs électriques des bâtiments publics municipaux et pour lesquels nous avons une liste. Si c'est l'angle du compteur lui-même, je n'ai aucune idée de la différence entre le compteur d'un bâtiment public et celui d'un particulier ou d'une entreprise. -- View this message in context: http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755891.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/5 Ista Pouss ista...@gmail.com Que la collaboration avec l'administration aide à se valoriser, à travailler, à faire son mai 68 open data est une chose. Mais qu'on se mette à donner des leçons à cet administration en est une autre. Quand je parle de serpent de mer, c'est au sein même de l'administration. Un peu de lecture s'impose: http://www.afigeo.asso.fr/documentation/category/12.html?download=463%3Aafigeo-gt-adresse-rapport-2011 Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu topo 25000ème - réponses multiples
Le 5 avril 2013 09:18, JB jb...@mailoo.org a écrit : Voici deux essais de diminution de la visibilité des tunnels ferroviaires. J'ai tendance à préférer le plus discret des deux. Et vous ? http://osm107.openstreetmap.fr/jbtopo/tunnel1.png http://osm107.openstreetmap.fr/jbtopo/tunnel.png , plus discret (oui, je sais, la voie ferrée est encore au dessus. Les courbes de niveau aussi, d'ailleurs) La trop grande discrétion pourrait rendre la distinction du tunnel moins visible au opint de faire croire que c'est encore une voie de surface (surtout quand elle traverse des zones multicolores. Ceci dit le rendu sous forme de barres alternées noires et blanches fait plutôt penser à une voie en construction ou qui n'est plus en état et fermée. Concernant les lignes de niveau ce n'est pas aberrant de les afficher par dessus puisque le tunnel passe justement sous la durface représentée par les lignes de niveau. Mais cela voudrait dire faire un rendu des tunnels (routiers ou ferroviaires) dans une couche séparée, après le remplissage des terrains et rivières dans tous les cas, mais avant les lignes de niveau pour les parties en tunnel, puis les lignes de niveau, puis les constructions, puis les routes et voies ferrées hors tunnel, puis les icônes et libellés. Le découpage et le tri des couches (y compris avec la combinaison du tag layer=* est une étape délicate d'autant plus que les lignes de niveau ne viennent pas d'OSM et n'ont pas de layer assignable et se mélangent au layer=0 avec les autres objets OSM sans layer=*). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le sujet des adresses est revenu à de très nombreuses fois durant les rencontres de l'Afigéo à Bordeaux (qui se terminent ce soir). Hier, l'IGN a signé à ce sujet un partenariat avec PIGMA, la plateforme d'échange d'infos géographiques d'Aquitaine. Il y a aussi beaucoup d'infos à récupérer de la DGFiP car les adresses figurent dans le cadastre vectoriel et de ce côté, il est bien possible qu'on ai accès à court terme à diverses données vectorielles du cadastre dans leur format d'origine (donc récupération de la voirie et des adresses, voire de quelques POI ou même des parcelles ce qui permet d'affiner les landuse). -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition pour le projet du mois de avril
ça doit être un bug de rafraichissement de cache ou une histoire de droits La page en question : http://wiki.openstreetmap.org/w/index.php?title=FR:Project_of_the_month/OpenStreetBugsoldid=888606 Une autre modification qui n'est pas passée en cache : http://wiki.openstreetmap.org/w/index.php?title=FR:Project_of_the_monthaction=history Ou alors faut-il des autorisations particulières pour modifier les pages ? Concernant les statistiques, on peu récupérer des fichiers SQL à cet adresse : http://openstreetbugs.schokokeks.org/dumps/ Dans cette export, il y a clairement indiqué la ville et le pays, les dates d'ouvertures et de fermeture. Est-ce que cela suffit ? -- Jean-Baptiste Holcroft Le 5 avril 2013 12:45, thevenon.jul...@free.fr a écrit : De: Jean-Baptiste Holcroft jb.holcr...@gmail.com J'ai écrit une proposition godasse pour OpenStreeetBugs, n'hésitez pas à enrichir. - http://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/OpenStreetBugs Salut, En cliquant sur le lien j obtiens une page wiki vide indiquant qu elle ne contient pas de texte A la fin il y a la possibilité de faire des statistiques, mais je ne sais pas extraire les statistiques française depuis les fichiers SQL quotidien, la ville la plus proche est systématiquement indiqué et le code [FR] est présent, cela devrait être facile. Si les personnes effectuant des corrections le font dans des changesets dedies et ajoutent un tag particulier ( a definir ) sur leurs changesets ou dans le commentaire du changesets je pourrais extraire des stats Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Pieren wrote Il y a aussi le serpent de mer de la base adresse unifiée. Parce que pour l'instant, chaque institution construit la sienne à grands frais (enfin, surtout aux frais des contribuables et des usagers). Mon rêve : une base adresse unifiée, publique, réutilisable librement et avec un code de voie vraiment unique adoptée par toutes les institutions. Vous avez dit trop simple ? Je vais essayer d'être concis... Effectivement, je ne suis pas d'accord avec ça et pour plusieurs raisons : - une commune n'est pas l'administration française mais est une *collectivité locale autonome*. A moins d'accord particulier, rien de permet de croire que 2 communes puissent travailler de la même manière, qu'elles soient voisines ou, pire encore, aux quatre coins de la France. - Les communes ont des *moyens financiers et humains* très différents. Si les grandes villes et les villes moyennes ont les compétences internes pour gérer la voirie en référentiel unique, ce n'est pas forcément le cas pour les petites villes et certainement pas le cas pour les 30.000 communes de moins de 1.000 habitants (à vue de nez). - Vous me direz, il y a les intercommunalités. Ce ne sont pas des collectivités locales et n'ont aucun contrôle sur les communes de son territoire. Elles n'ont pas forcément comme compétence la gestion de la voirie et, si c'est le cas, cela ne concerne en général que la voirie dite communautaire. La compétence voirie reste donc *essentiellement une compétence communale*. Là, je ne parle que de l'aspect création d'une base unique. Il reste le problème de la maintenance de cette base unique. Et, là encore, la commune est la source unique de l'information. C'est bien pour tout cela que je parle de *référencement interne à la commune de la voirie*. Croyez-moi, le sujet est loin d'être aussi simple. Il est complexe (pas compliqué) mais c'est pour cela qu'il est intéressant... -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755899.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
cquest wrote Il y a aussi beaucoup d'infos à récupérer de la DGFiP car les adresses figurent dans le cadastre vectoriel et de ce côté, il est bien possible qu'on ai accès à court terme à diverses données vectorielles du cadastre dans leur format d'origine (donc récupération de la voirie et des adresses, voire de quelques POI ou même des parcelles ce qui permet d'affiner les landuse). Attention, il n'existe pas de données graphiques concernant la voirie dans le cadastre de la DGFiP. Il s'agit, en fait, d'une couche d'étiquettes du nom des voies qui sont positionnées dans les espaces entre les parcelles. Au mieux, il y a une couche d'habillage qui correspond (pas toujours) aux bordures de trottoir... -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5755901.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition pour le projet du mois de avril
De: Jean-Baptiste Holcroft jb.holcr...@gmail.com ça doit être un bug de rafraichissement de cache ou une histoire de droits La page en question : http://wiki.openstreetmap.org/w/index.php?title=FR:Project_of_the_month/OpenStreetBugsoldid=888606 Avec ce lien c est bon j ai l acces Concernant les statistiques, on peu récupérer des fichiers SQL à cet adresse : http://openstreetbugs.schokokeks.org/dumps/ Dans cette export, il y a clairement indiqué la ville et le pays, les dates d'ouvertures et de fermeture. Est-ce que cela suffit ? En fait je pensais faire directement des stats par l analyse des diffs OSM comme pour le projet du mois Wikipedia Cela permet de savoir combien d utilisateurs se sont impliques dans le projet,faire un classement le nombre d objets OSM modifies, les modifs apportees etc Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Config tile.openstreetmap.fr [était Re: Rafraichissement des tuiles, sur tile.openstreetmap.fr]
Bonjour, Je squatte ce fil pour savoir comment est configuré cet ensemble. J'ai suivi la pres avec attention à SOTM-FR, mais je n'ai pas gardé souvenir d'info sur la config. Un howto récent quelque part ? A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] fiabilité des codes postaux sur Nominatim pour la géolocalisation inverse d'adresses
Pour l'instant en France on a privilégié la saisie dans OSM des codes postaux au niveau des noeuds, parfois des relations administratives (mais par pour les communes à codes postaux multiples). Mais on a un problème : la principale utilisation des codes postaux est pour servir de source à la géolocalisation des adresses dans Nominatim. Mais Nominatim a depuis longtemps des tonnes de problèmes avec la gestion des codes postaux : une fois qu'un codes postal y a été injecté, il ne disparaît plus jamais (Nominatim garde un noueud même s'il n'est plus attaché à **aucun** objet OSM, parce qu'il a été saisi par erreur et supprimé, ou parce que le code a depuis été corrigé (erreur sur un chiffre). [Il y a un problème annexe (mais pas insurmontable) concernant la recherche des adresses dans Nominatim contenant des codes postaux mais non reconnus comme tel (par exemple les adresses contenant un préfixe de pays comme F-35000 Rennes au lieu de 35000 Rennes, France, qui font échouer la recherche des adresses). Le solution n'est pas dans la base Nominatim elle-même mais dans la préparation des adresses à géolocaliser avant d'interroger Nominatim.] Mais le plus gênant reste que Nominatim est largement pollué dans sa **propre** base par des codes postaux faux jamais corrigé, car il garde tout. Quand on regarde les résultats d'une recherche Nominatim contenant un code postal faux, on se rend compte qu'il a garé et continue de référencer un de ses propres noeuds place qui n'est plus attaché à **aucun** objet OSM. Même si on a corrigé dans OSM avec une autre valeur ou avec des polygones englobants (dans une relation administrative par exemple, ou une relation multipolygone créée ad hoc pour les limites des zones postales), cette donnée n'est visiblement plus prise en compte par Nominatim qui continue de voir son ancien objet code postal en priorité sur tout ce qu'on a pu mettre ensuite. La seule solution actuelle consiste à ouvrir un ticket sur le Trac de Nominatim afin qu'un adminsitrateur fasse le nettoyage à la main dans la base Nominatim. Ce qui n'est pas viable, trop long, trop couteux. Bref tout le monde y renonce. Et petit à petit, la géolocalisation via Nominatim devient de moins en moins utilisable, des adresses qu'on pouvait géolocaliser dans le passé ne passent plus à cause de la survenance inattendue d'un code postal faux à proximité. Quelle stratégie adopter ? Si Nominatim ne peut plus être utilisé pour la géolocalisation des adresses, alors comment faire ? - créer une autre base pour les codes postaux ? - ne plus saisir les codes postaux dans OSM puisque Nominatim en est pratiquement le seul utilisateur réel et qu'il en fait absolument nimporte quoi en choisissant ses données à sa guise... Note : ce problème affecte avant tout les codes postaux enregistrés dans Nominatim sous forme de noeuds. Il est beaucoup moins critique pour les codes postaux sous forme de polygones, mais visiblement Nominatim fait une transformation des polygones posaux en créant *lui-même* un noeud place dans sa base, utilisé à la place du polugone réel dans OSM, qu'il n'enregistre pas ! Cela peut expliquer pourquoi Nominatim ajoute des tas de noeuds postaux qu'il ne sait ensuite plus jamais purger ou corriger pusique jamais attaché à l'objet OSM qui en était à l'origine (Nominatim est ensuite incpable de détecter les changements et corrections, que celles-ci étaient dans des noeuds ou des polygones OSM). Y a-t-il une réflexion menée pour que Nominatim soit corrigé et pour rendre les codes postaux enfin utilisables pour la géolocalisation inverse à partir d'une adresse ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Damned ! tu aurais des scoops avant la réunion du 9 ? Gaël, au fait, si tu as des précisions sur le lieu exact du rendez-vous, je suis preneur. Denis -Message d'origine- De : Christian Quest [mailto:cqu...@openstreetmap.fr] Envoyé : vendredi 5 avril 2013 14:52 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] expérimentations à Orange Le sujet des adresses est revenu à de très nombreuses fois durant les rencontres de l'Afigéo à Bordeaux (qui se terminent ce soir). Hier, l'IGN a signé à ce sujet un partenariat avec PIGMA, la plateforme d'échange d'infos géographiques d'Aquitaine. Il y a aussi beaucoup d'infos à récupérer de la DGFiP car les adresses figurent dans le cadastre vectoriel et de ce côté, il est bien possible qu'on ai accès à court terme à diverses données vectorielles du cadastre dans leur format d'origine (donc récupération de la voirie et des adresses, voire de quelques POI ou même des parcelles ce qui permet d'affiner les landuse). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 5 avril 2013 14:42, Pieren pier...@gmail.com a écrit : Quand je parle de serpent de mer, c'est au sein même de l'administration. Un peu de lecture s'impose: http://www.afigeo.asso.fr/documentation/category/12.html?download=463%3Aafigeo-gt-adresse-rapport-2011 Ouais enfin bon merci de ne me donner que 30 pages de lecture sur les serpents de mer dans l'administration, mais j'ai quelque mal à comprendre, à la lecture (rapide, excuse moi) de ce document, comment est-ce que l'on peut en conclure que l'adresse est un problème simple, quand bien même l'administration est mal foutue. ... et sur mon opinion que OSM est trop orienté administratif, qu'en penses-tu ? (sans me donner 30 pages de plus à lire). -- Les dérives de rue : Le papillon d’hiver (le film)http://drivrsdu.fr/le-papillon-dhiver-le-film/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition pour le projet du mois de avril
Le 5 avril 2013 14:55, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : ça doit être un bug de rafraichissement de cache ou une histoire de droits La page en question : http://wiki.openstreetmap.org/w/index.php?title=FR:Project_of_the_month/OpenStreetBugsoldid=888606 Une des propositions concerne les limites infracommunales des cantons dans les communes divisées en fractions cantonales. Le problème est que souvent on n'a pas de données publiée par la commune elle-même (ou son EPCI) à ce sujet et que la source est un texte réglementaire et que cette source est souvent totalement introuvable (la plupart des communes actuellement non découpées dans OSM ont eu leur fractionnement cantonal défini il y a fort longtemps dans d'anciens arrêtés, et que le texte de ces arrêtés n'est même pas disponible en ligne, on ne retrouve rien par exemple sur Legifrance si l'arrêté date de 1974 ou d'avant... bon nombre de fractionnement cantonaux ayant eu lieu lors de la réforme administrative au début de la 5e république, juste après l'indépendance de l'Algérie à partir de 1962 environ, bon nombre de ces fractionnement ayant eu lieu vers 1962-1968, si on regarde les références fréquemment trouvées aux noms de ces cantons dans le code Rural, lequel en revanche ne précise jamais comment ces cantons sont délimités). On n'a de détails dans LégiFrance (avec la liste exhaustives des rues, même si parfois elles ont pu changer de nom, ce qui n'est pas insoluble) que pour les arrêtés publiés après 1974, mais très rarement ceux publiés avant. Hors de Légifrance, toutes les recherches dans les archives du JORF échouent aussi avant 1974 (environ). Bref si on n'a pas d'info en ligne, malgré la demande pourtant effectuée officiellement il y a quelques mois par le Sénat qui voulait obtenir une liste exhaustive des cantons français, une liste qui est sans doute parue dans un obscur rapport parlementaire dont on sait qu'il a existé mais dont le ne parviens pas à trouver l'annexe contenant le tableau détaillé. Pourtant cette liste devrrait faire partie intégrante du Code électoral (lequel ne fait QUE lister les cantons, sans pratiquement jamais les détailler concernant les fractionnements de communes) L'Insee elle-même est visiblement incapable de fournir ces données (d'où pour les communes découpées en fractions cantonales, la représentation des cantons concernés en excluant la commune découpée de ces cantons, et en ajoutant un pseudo-canton-ou-ville pour la commune elle-même). Comment faire alors dans OSM ? Pourrait-on adopter la solution actuelle de l'Insee, en fermant au moins les cantons en incluant les parties de cantons hors des communes fractionnées, quitte à laisser un trou hors de tout canton OSM pour la commune découpée dont on n'a aucune idée du fractionnement cantonal ? Faudra-t-il une 'task force OSM pour aller consulter et scanner les anciennes archives préfectorales ? Doit-on plutôt interroger chaque commune une par une pour lui demander de retrouver copie du texte du/des arrêté(s) ayant conduit à leur découpage cantonal ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 5 avril 2013 14:58, Tony Emery tony.em...@yahoo.fr a écrit : problème de la maintenance de cette base unique. Et, là encore, la commune est la source unique de l'information. C'est peut-être vrai pour les communes de taille raisonnable (disons au moins 1500 habitants), mais aujourd'hui plus aucune des plus petites communes rurales n'a les moyens ni la compétence de maintenir seule ces données. Et que pour des raisons pratiques évidentes, elles ont fait gérer leur SIG depuis longtemps par des tiers (peut-être au départ via des prestataires privés intervenant sur de nombreuses autres communes), mais aujourd'hui plus souvent par l'EPCI dont elles sont membres (même si l'EPCI peut ausssi faire appel à des prestataires externes, au moins l'EPCI dispose de son SIG et a un accès directe et on contrôle des données qui sont dedans). Il me semble que de plus en plus la source des infos et leur maintenance a été transférée aux EPCI qui disposent de plus de moyens (et de personnels) avec au passage des économies d'échelle en terme de coût. Et qu'en fin de compte il ne reste que les communes de taille suffisante, avec des budgets suffisants (en hausse constante), à encore gérer elles-mêmes leur propre SIG : ces communes seront de moins en moins nombreuses et même si elles conservent encore un SIG, une bonne partie de leur données seront toute de même transférées pour être gérées par l'EPCI (même si la commune fournit de temps en temps des données et y a un accès continu en cas de besoin). C'est à l'occasion de ces transferts vers l'EPCI que des travaux d'uniformisation sont entrepris, et qu'au passage les EPCI se concertent aussi entre eux pour évaluer les solutions choisies (les EPXI aussi veulent faire des économies d'échelle et n'ont probablement pas envie de développer des solutions totalement propriétaires incompatibles avec ce que font les autres). Au delà de ça, il y a aussi les SIG des départements et régions qui eux aussi proposent leurs solutions d'intégration. Certes il n'y a pas encore d'uniformisation au plan national (avec des agences partenaires au plan national comme l'Insee ou l'IGN, ou interrégionales comme les agences de bassin, parfois aussi des agences européennes ou des structures de coopération transfrontalières, notamment pour les transports, l'environnement et le développement touristique ou économique), mais on doit constater tout de même une convergence progressive entre les différents modèles de représentation des données entre les différents niveaux territoriaux jusqu'à l'Etat lui-même, même si certaines agences ont des besoins spécifiques supplémentaires qui sortent du cadre actuel des tentatives d'uniformisation/normalisation, faute d'avoir d'autres acteurs intéressés pour maintenir ces données spécifiques. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition pour le projet du mois de avril
De toute façon, pour le découpage des cantons, je recommande vivement d'attendre ! Une loi, actuellement à l'étude au Parlement, envisage de revoir en profondeur le fonctionnement des conseils généraux (renommés conseils départementaux) et, c'est ce point qui concerne OSM, de diviser par 2 le nombre total de cantons. Et comme il y a fort à parier qu'il n'y aura pas simplement une fusion de cantons limitrophes pour arriver à cette division par 2, mais un redécoupage complet (entre autre pour des raisons démographiques), je réitère mon propos : il est urgent d'attendre, sous peine de se taper un gros boulot qui sera rendu inutile dans les prochains mois. De plus, ce redécoupage complet entrainera la publication (au JO) des nouvelles limites de cantons : nous aurons alors une source fiable, complète et récente. Francescu Le 5 avril 2013 15:34, Philippe Verdy verd...@wanadoo.fr a écrit : Le 5 avril 2013 14:55, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : ça doit être un bug de rafraichissement de cache ou une histoire de droits La page en question : http://wiki.openstreetmap.org/w/index.php?title=FR:Project_of_the_month/OpenStreetBugsoldid=888606 Une des propositions concerne les limites infracommunales des cantons dans les communes divisées en fractions cantonales. Le problème est que souvent on n'a pas de données publiée par la commune elle-même (ou son EPCI) à ce sujet et que la source est un texte réglementaire et que cette source est souvent totalement introuvable (la plupart des communes actuellement non découpées dans OSM ont eu leur fractionnement cantonal défini il y a fort longtemps dans d'anciens arrêtés, et que le texte de ces arrêtés n'est même pas disponible en ligne, on ne retrouve rien par exemple sur Legifrance si l'arrêté date de 1974 ou d'avant... bon nombre de fractionnement cantonaux ayant eu lieu lors de la réforme administrative au début de la 5e république, juste après l'indépendance de l'Algérie à partir de 1962 environ, bon nombre de ces fractionnement ayant eu lieu vers 1962-1968, si on regarde les références fréquemment trouvées aux noms de ces cantons dans le code Rural, lequel en revanche ne précise jamais comment ces cantons sont délimités). On n'a de détails dans LégiFrance (avec la liste exhaustives des rues, même si parfois elles ont pu changer de nom, ce qui n'est pas insoluble) que pour les arrêtés publiés après 1974, mais très rarement ceux publiés avant. Hors de Légifrance, toutes les recherches dans les archives du JORF échouent aussi avant 1974 (environ). Bref si on n'a pas d'info en ligne, malgré la demande pourtant effectuée officiellement il y a quelques mois par le Sénat qui voulait obtenir une liste exhaustive des cantons français, une liste qui est sans doute parue dans un obscur rapport parlementaire dont on sait qu'il a existé mais dont le ne parviens pas à trouver l'annexe contenant le tableau détaillé. Pourtant cette liste devrrait faire partie intégrante du Code électoral (lequel ne fait QUE lister les cantons, sans pratiquement jamais les détailler concernant les fractionnements de communes) L'Insee elle-même est visiblement incapable de fournir ces données (d'où pour les communes découpées en fractions cantonales, la représentation des cantons concernés en excluant la commune découpée de ces cantons, et en ajoutant un pseudo-canton-ou-ville pour la commune elle-même). Comment faire alors dans OSM ? Pourrait-on adopter la solution actuelle de l'Insee, en fermant au moins les cantons en incluant les parties de cantons hors des communes fractionnées, quitte à laisser un trou hors de tout canton OSM pour la commune découpée dont on n'a aucune idée du fractionnement cantonal ? Faudra-t-il une 'task force OSM pour aller consulter et scanner les anciennes archives préfectorales ? Doit-on plutôt interroger chaque commune une par une pour lui demander de retrouver copie du texte du/des arrêté(s) ayant conduit à leur découpage cantonal ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition pour le projet du mois de avril
Le 5 avril 2013 16:09, Francescu GAROBY windu...@gmail.com a écrit : De toute façon, pour le découpage des cantons, je recommande vivement d'attendre ! Une loi, actuellement à l'étude au Parlement, envisage de revoir en profondeur le fonctionnement des conseils généraux (renommés conseils départementaux) et, c'est ce point qui concerne OSM, de diviser par 2 le nombre total de cantons. Ce ne pourra pas être un changement radical, car les cantons ne servent pas qu'aux élections et sont **très** fréquemment référencés dans le Code rural. L'échelle de base utilisée est alors souvent celle utilisée par l'Insee (avec ses cantons-ou-villes) ce qui justifierait alors de saisir dans OSM ces cantons-ou-villes de façon exhaustive dans OSM, même si cela implqiue des ambiguités au plan purement électoral des conseils généraux. Déjà on commence à discuter des limites des bureaux de vote dans les communes (mais cela demandera baucoup d'efforts aussi, et on ne doit pas se contenter d'attendre). La loi dont tu parles est envoyées aux calendes grecques : les travaux initiés par Sarkozy avec la volonté de réformer les conseillers territoriaux ont été rejetés, et depuis longtemps (depuis le début de le Ve république en fait et même avant depuis l'Empire), les questions relatives au découpage électoral (révisé pratiquement à chaque législature ou changement de gouvernement, et toujours avec des protestations des groupes parmentaires d'opposition qui y voient des intentions de manipulations électoralistes) ont toujours été épineuses. Derrière cette réforme il y a aussi les questions relatives au mode de scrutin (plus ou moins de proportionnel par exemple). Mais que même dans ce cas, si les cantons sont mal connus et manipulés au plan électoral, leur omniprésence dans les textes réglementaires (notamment dans le code Rural et de l'environnement, par exemple dans les arrêtés de catastrophe naturelle, la prévention des risques, la protection de l'environnement) interdit des changements radicaux : même si les conseillers territoriaux sont réformés, les cantons persisteront (même si le fractionnement cantonal des communes disparaît pour aller davantage vers la solution actuelle de l'Insee avec ses villes-ou-cantons). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition pour le projet du mois de avril
Je parlais des conseillers départementaux (réforme Hollande), et non des conseilles territoriaux (réforme Sarkozy rejetée par l'actuelle majorité). Et non, la loi dont je parle n'a pas été rejetée aux calendes grecques. Je t'invite à consulter l'historique de ce projet de loi, clairement expliqué sur le site officiel du Sénat : http://www.senat.fr/dossier-legislatif/pjl12-166.html (mais il est cependant vrai que la commission mixte paritaire a tout récemment indiqué ne pouvoir parvenir à élaborer un texte commun. Ce qui ne signifie pas pour autant un rejet aux calendes grecques). Bref, en attendant d'en savoir plus, et parce que les limites officielles de cantons sont toujours introuvables, je maintiens ma proposition de ne pas retenir cela comme projet du mois : il y a bien d'autres sujets plus prêts à être traités. Francescu Le 5 avril 2013 16:23, Philippe Verdy verd...@wanadoo.fr a écrit : Le 5 avril 2013 16:09, Francescu GAROBY windu...@gmail.com a écrit : De toute façon, pour le découpage des cantons, je recommande vivement d'attendre ! Une loi, actuellement à l'étude au Parlement, envisage de revoir en profondeur le fonctionnement des conseils généraux (renommés conseils départementaux) et, c'est ce point qui concerne OSM, de diviser par 2 le nombre total de cantons. Ce ne pourra pas être un changement radical, car les cantons ne servent pas qu'aux élections et sont **très** fréquemment référencés dans le Code rural. L'échelle de base utilisée est alors souvent celle utilisée par l'Insee (avec ses cantons-ou-villes) ce qui justifierait alors de saisir dans OSM ces cantons-ou-villes de façon exhaustive dans OSM, même si cela implqiue des ambiguités au plan purement électoral des conseils généraux. Déjà on commence à discuter des limites des bureaux de vote dans les communes (mais cela demandera baucoup d'efforts aussi, et on ne doit pas se contenter d'attendre). La loi dont tu parles est envoyées aux calendes grecques : les travaux initiés par Sarkozy avec la volonté de réformer les conseillers territoriaux ont été rejetés, et depuis longtemps (depuis le début de le Ve république en fait et même avant depuis l'Empire), les questions relatives au découpage électoral (révisé pratiquement à chaque législature ou changement de gouvernement, et toujours avec des protestations des groupes parmentaires d'opposition qui y voient des intentions de manipulations électoralistes) ont toujours été épineuses. Derrière cette réforme il y a aussi les questions relatives au mode de scrutin (plus ou moins de proportionnel par exemple). Mais que même dans ce cas, si les cantons sont mal connus et manipulés au plan électoral, leur omniprésence dans les textes réglementaires (notamment dans le code Rural et de l'environnement, par exemple dans les arrêtés de catastrophe naturelle, la prévention des risques, la protection de l'environnement) interdit des changements radicaux : même si les conseillers territoriaux sont réformés, les cantons persisteront (même si le fractionnement cantonal des communes disparaît pour aller davantage vers la solution actuelle de l'Insee avec ses villes-ou-cantons). -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Compteur électrique
nous avons une listes Tu travailles pour une municipalité? tu souhaites faire une carte pour faciliter le travail des agent techniques de la municipalité? si oui il y a moyen d'éviter de rajouter des infos dans la base OSM tout en superposants sur un fond de carte OSM ... Le 5 avril 2013 14:36, Tony Emery tony.em...@yahoo.fr a écrit : François Lacombe wrote Une petite question: qu'est-ce qui pourrait différencier le compteur d'un bâtiment municipal et celui d'une emprise privée? Si c'est l'angle de la saisie, l'idée que nous avons est de localiser tous les compteurs électriques des bâtiments publics municipaux et pour lesquels nous avons une liste. Si c'est l'angle du compteur lui-même, je n'ai aucune idée de la différence entre le compteur d'un bâtiment public et celui d'un particulier ou d'une entreprise. -- View this message in context: http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755891.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition pour le projet du mois de avril
Je serais partant pour compléter les cantons selon la définition actuelel de l'Insee, étant donné la quantité impressionnante de textes légaux ou réglementaires qui y con t référence. Autrement dit : créer des cantons incomplets excluant les communes fractionnées, pour aller jusqu'au même niveau que la brique de base clairement définie par l'Insee, et stable. Les questions relatives au code électoral lui-même et son utilisation du découpage cantonal en revanche mérite qu'on ne s'attarde pas trop dessus (je suis donc plutôt défavorable à ce qu'on cartographie les bureaux de vote qui peuvent changer chaque année, après la mise à jour et la validation légale des listes électorales fermées l'année précédente, et conduisant à la carte électorale décidée alors pour être applicable pour les scrutins de l'année suivante). Dans les communes où on a le détail du fractionnement cantonal, on garde ce détail (on ne l'a pratiquement que dans les grandes villes justement parce que leur population électorale a beaucoup changé régulièrement au point que des cantons ont plus fréquemment été modifiés et qu'on dispose donc de textes récents, numérisés et accessibles facilement). L'échelon Insee canton-ou-ville ira très bien partout, et on n'aura pas besoin d'attendre des années pour faire correspondre alors l'énorme quantité de textes (surtout réglementaires d'origine préfectorale). Le jour où il y aura un nouveau texte (on peut attendre longtemps), on fera les changements nécessaires dans la base. Et cela permettra malgré tout de dessiner des cartes électorales, m^me si on ne peut pas détailler sur la carte les communes découpées (mais les résultats de scrutins sont aussi publiés à l'échelle de la commune). Pour compléter jusqu'au niveau canton-ou-ville, on a des données de référence stables, facilement accessibles, et cela peut marcher dans le cadre d'un projet du mois (note : je ne demande pas à ce qu'on supprime les fractions cantonales de communes, là où on les a ; tout le monde reste tagué comme un political_divsion=canton, même si on peut aussi boucher les trous laissés par les communes fractionnées en ajoutant le même tag political_division=canton à la relation de cette commune, et en laissant de côté le code pseudo-cantonal à 4 chiffres attribué par l'Insee à la commune entière). Avec cette idée, on a alors une couverture à 100% de la France, qui n'exclue pas de créer le fractionnement là où on en trouve (et là au moins on n'est pas obligé d'attendre une réforme de loi dont on n'a absolument aucune idée si elle aboutira à quelquechose avant l'échéance des prochaines élections cantonales et régionales qui ont déjà été repoussées de 2 ans, mais qu'il sera impossible de repousser une nouvelle fois par un nouvel allongement des mandats électoraux). Il est fort probable que cette réforme ne soit même pas passée à tant pour les prochaines élections, et que cela repoussera alors l'application effective de la réforme du découpage territorial de 6 années de plus. Sans compter qu'il n'y aura pas réécritue des milliers de pages d'arrêtés et décrets qui mentionnent ces cantons (pour que les nouveaux décrets n'y fassent plus référence, il faudrait qu'ils listent exhaustivement des listes bien plus longues de communes, avec tous les risques d'oublis, de communes classées deux fois dans des catégories contradictoires pour les même arrêtés et décrets); Alors oui les cantons n'ont plus une grande importance sur le terrain (ils ne sont pas des collectivités) mais leur importance reste encore très élevée dans une quantité énorme de textes, qu'il n'est pas question de réécrire et qui mettront des décennies avant d'être abrogés ou réécrits, et qui très largement utilisent déjà la brique canton-ou-ville de l'Insee, transcrite dans les textes réglementaires sous une forme telle que: - canton d'Amiens-Nord (sauf la commune d'Amiens) ; commune d'Amiens; etc. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Compteur électrique
Un PrintScreen et un stylo ou marqueur, c'est ça ? :) - Mail original - De: Tetsuo Shima tets...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Vendredi 5 Avril 2013 17:01:34 Objet: Re: [OSM-talk-fr] Compteur électrique nous avons une listes Tu travailles pour une municipalité? tu souhaites faire une carte pour faciliter le travail des agent techniques de la municipalité? si oui il y a moyen d'éviter de rajouter des infos dans la base OSM tout en superposants sur un fond de carte OSM ... Le 5 avril 2013 14:36, Tony Emery tony.em...@yahoo.fr a écrit : François Lacombe wrote Une petite question: qu'est-ce qui pourrait différencier le compteur d'un bâtiment municipal et celui d'une emprise privée? Si c'est l'angle de la saisie, l'idée que nous avons est de localiser tous les compteurs électriques des bâtiments publics municipaux et pour lesquels nous avons une liste. Si c'est l'angle du compteur lui-même, je n'ai aucune idée de la différence entre le compteur d'un bâtiment public et celui d'un particulier ou d'une entreprise. -- View this message in context: http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755891.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
2013/4/5 Ista Pouss ista...@gmail.com comment est-ce que l'on peut en conclure que l'adresse est un problème simple, quand bien même l'administration est mal foutue. Quand je parle de simple, c'est par rapport à la simplification administrative qui ferait qu'une seule autorité serait chargée de maintenir une base unique. Elle pourrait bien-sûr être abondée par les créateurs d'adresses (les communes) mais aussi pouvoir être corrigée et améliorée par les institutions utilisatrices (INSEE, DGFiP, police, la poste, etc). Seule la partie anonymisée serait publique et réutilisable. La partie nominative serait plus facilement entretenue si elle était couplée à une obligation légale de déclaration dominiliaire (se déclarer en mairie lors de l'installation) comme pratiquement partout ailleurs en Europe. ... et sur mon opinion que OSM est trop orienté administratif, qu'en penses-tu ? Je suis d'accord. Mes coups de gueule sur les références récurentes au code INSEE en témoignent. Ou les noms des cantons qui sont aussi les noms des villes et qu'on retrouve dans les résultas de recherche. Les contributeurs moyens d'OSM sont trop éloignés de ce vocabulaire. Il faut faire attention à ne pas se déconnecter du moteur du projet : le contributeur lambda. J'ai cru comprendre qu'au dernier SOTM-fr, il n'y en avait pratiquement aucun. C'est un danger qui gu (sans me donner 30 pages de plus à lire). J'ai bon ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Prochaine réunion des contributeurs de la région de Marseille le lundi 8 / 04 / 2013 // 20h00 à La Bo@te.
*Bonjour à toutes et à tous. Je rappel que les contributeurs d' Openstreetmap de la région de Marseille se réunissent le lundi 8 avril 2013, à partir de 20h00 à La Bo@te ( dates suivantes en fin de message ). * *Avant cette réunion, est proposé par Fabien, une Carto-partie sur le Cours Honoré d'Estienne d'Orves, rendez-vous dès 19h00 devant l'entrée de Boate. * *Détails et compléments d'informations, voir ce lien : http://listes.openstreetmap.fr/wws/arc/local-marseille/2013-03/msg1.html * * Pour ceux qui compterais participez à la réunion et qui viennent pour la première fois, nous avons pour habitude que chacun(e) amène quelque chose à boire et/ou à grignoter. Lien du plan de l'accès à La Bo@te : http://www.openstreetmap.org/?lat=43.29213amp;lon=5.3730645amp;zoom=18amp;layers=Mamp;mlat=43.29210amp;mlon=5.37297http://www.openstreetmap.org/?lat=43.29213lon=5.3730645zoom=18layers=Mmlat=43.29210mlon=5.37297 Lien de la page du Wiki d' Openstreetmap sur les réunions de Marseille : http://wiki.openstreetmap.org/wiki/Marseille/R%C3%A9unions_2013 Archives de l'année 2012 : http://wiki.openstreetmap.org/wiki/Marseille/R%C3%A9unions_2012 Pour confirmer votre présence éventuel, vous pouvez répondre à ce message, merci. Nota : Calendrier des réunions suivantes pour 2013, même lieu, même horaire. * ** * - lundi 6 mai 2013. * * - lundi 3 juin 2013. * * - lundi 1er juillet 2013. * * - lundi 5 aout 2013. * * - lundi 2 septembre 2013. * * - lundi 7 octobre 2013. * * - lundi 4 novembre 2013. * * - lundi 2 décembre 2013. * *** À bientôt... Amicales salutations.** Olivier Griffet http://griffet.net/ | Contributeur OpenStreetMap = http://www.openstreetmap.org/user/olivier_griffet_83660_carnoules | | Téléphone (Ligne ADSL) N° 09 61 23 65 40 Répondeur / messagerie | | Mobile GSM = 07 88 36 87 42 Répondeur / messagerie | | Habitant de 83660http://www.openstreetmap.org/export/embed.html?bbox=6.17628,43.29493,6.19694,43.30505layer=mapnikmarker=43.29837,6.18737- Carnoules http://carnoules.fr/ - Var | Adhérent de GULLIVAR et ToulonuX | Utilisateur de GNU/LINUX de Linux Mint 11 [ Gnome ] + (X)Ubuntu 12.04 [ XFCE ] ; Lives USB ASRI.EDU.2.1a ; Etc... Site web de GULLIVAR : http://gullivar.org/ Site web de ToulonuX : http://toulonux.tuxfamily.org/ * ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap.org
On 04/05/2013 09:01 AM, Fabien wrote: Par contre, ça fait bizarre d'avoir les skieurs à l'envers sur le tire-fesses : http://www.opensnowmap.org/?zoom=16lat=45.913lon=6.58931layers=e=falsem=raster Ah non, je laisse, je trouve ça rigolo :) Sans blague, je ne sais pas si j 'arriverai à gérer ça avec mapnik ou postgis, mais j'essaierai, c'est sûr. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap.org
On 04/05/2013 12:56 PM, David Crochet wrote: Est-ce un bug ou une mal interprétation des étiquettes : Super-Besse Les pistes de ski sont étiquetées de 2 façons (comme les cours d'eau) : le chemin qui définit la piste, mais une zone qui définit l'emplacement de surface que prend la piste. Alors, c'est pas un bug, ni une mauvaise interprétation, c'est une 'feature request'. Je vais regarder ça. Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Opensnowmap.org
On 04/05/2013 12:31 PM, Nicolas Dumoulin wrote: Le vendredi 5 avril 2013 12:19:15 yve...@gmail.com a écrit : Oui, un retour genre surbrillance au survol de la liste sera sûrement implanté, mais j'ai pas encore la solution. C'est sur quelle piste ce pb d'icône? Sur à peu près toutes les pistes du domaine de Pessade : http://www.opensnowmap.org/?zoom=15lat=45.62994lon=2.87237layers=e=falsem=raster Ben oui, piste:type=nordic n'est pas renseigné sur les *ways*, sur ce domaine. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 5 avr. 2013 à 17:36, Pieren a écrit : ... et sur mon opinion que OSM est trop orienté administratif, qu'en penses-tu ? Je suis d'accord. Mes coups de gueule sur les références récurentes au code INSEE en témoignent. Ou les noms des cantons qui sont aussi les noms des villes et qu'on retrouve dans les résultas de recherche. Les contributeurs moyens d'OSM sont trop éloignés de ce vocabulaire. Il faut faire attention à ne pas se déconnecter du moteur du projet : le contributeur lambda. J'ai cru comprendre qu'au dernier SOTM-fr, il n'y en avait pratiquement aucun. Je ne sais pas qui est trop orienté administratif, car, il me semble avoir parfois, contredit Pieren, sur des points marginaux qui tenaient à l'acceptation sans contrôle des données de l'administration, dont la réputation de cohérence et de logique est parfois usurpée. Tony faisait le distinguo entre collectivité publique autonome et administration de l'Etat. C'est sur l'anarchie admistrative français qu'il met le doigt : Les lois qui concernent l'environnement sont uniformes, malgré la diversité des climats et des écosystème, et, pourtant, t il semble admissible que les unités de base n'aient pas un minimum de référentiel commun pour des questions qui n'ont rien de politique, sinon, d'énormes efforts pour maintenir l'inertie et la désorganisation. Pour ce qui concerne, les références administratives, il est clair qu'il s'agit d'un débat qui ne concerne pas le supposé contributeur lambda. Il peut, éventuellement, être concerné par un alourdissement d ela BDD, mais, c'est tout. Ces références ou référentiels ne peuvent qu'être introduit que mécaniquement. Le lieu naturel pour trancher, sous la forme d'une recommandation qui deviendra vite une norme, est OSM- France, la liste étant un outil pour faire émerger les questions débroussailler les problèmes et indiquer les voies à suivre. J'ignore ce que Pieren désigne par contributeur lambda. Cela s'oppose à contributeur non-lambda. S'agit-il des codeurs, souvent appelés et inexactement geeks dans le langage courant? Il me semble que j'en ai rencontré quelques non-codeurs à SOTM-Fr, mais, moi qui ne code rien, j'étais content de discuter avec des gens qui me parlaient de codage, en termes généraux, bien sûr. Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le ven. 05 avril 2013 à 11:34 +0200, Pieren a écrit : 2013/4/5 Tony Emery tony.em...@yahoo.fr Par conséquent, ces traçés, même si leur précision n'est pas bonne, est règlementée. Pour info, dans un document d'urbanisme approuvé, si le dessin d'une zone à été mal fait, qu'il coupe une parcelle alors qu'il ne le devrait pas, c'est quand même ce découpage qui est appliqué. Je pense donc, même si ce n'est pas juste, qu'il faut le laisser tel quel si l'on veut que les collectivités s'investissent dans OSM. Ce point est capital avec OSM. C'est la violation d'un principe de base du projet : les données doivent pouvoir être améliorées par les contributeurs, sinon elles n'ont pas leur place dans la base. Aucune donnée ne doit pouvoir être bloquée dans OSM sous prétexte d'officialité, encore plus si elles sont mauvaises. Je renverrais la lecture d'un fil de discussion de référence sur ce thème (en anglais) : http://lists.openstreetmap.org/pipermail/talk/2009-March/034948.html Je plussoie entièrement Pieren sur ce point. OSM ne doit pas devenir un dépôt où les institutions accepteraient de verser leurs données à condition que personne n'y touche. OSM c'est du crowdsourcing avant tout ; l'open data est un complèment, bienvenu mais pas essentiel. Il faut qu'on travaille au maximum pour intégrer l'open data dans OSM, mais si on tombe sur un conflit entre les deux, OSM laissera tomber l'open data et privilégiera toujours le crowdsourcing. Ce point est très important pour les discussions avec les collectivités, et il est non négociable, comme la licence. En un mot : aucune donnée ne doit être verrouillée dans OSM. -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le jeu. 04 avril 2013 à 23:50 -0700, Tony Emery a écrit : En fait, je dois quand même vous alerter sur un points : les collectivité sont de plus en plus consciente de l'intérêt de gérer en interne une base exhaustive de leur voirie. Or, cela sous-entend de pouvoir identifier chaque voie de manière unique dès la création de cette voie, d'où, l'identifiant. Qu'avons nous comme identifiant voirie : - Rivoli : c'est un code créé et géré par la DGFiP - l'ID de la BDAdresse : idem pour l'IGN Il faut donc créer un identifiant interne dans la commune car la commune est la source de cette information. Pas la peine de partir dans les rêves de Grande Unification, je pense qu'on peut en déduire une chose : il faut que le schéma opendata utilisé accepte plusieurs identifiants provenant de plusieurs bases différentes. Donc, exit le ref:source=, et je ne vois pas d'autre solution que le ref:FR:idbase=id Je pense qu'on ne pourra pas se passer de l'identifiant DGFiP, puisque c'est déjà le référentiel pour les imports de cadastre (et qu'on peut espérer négocier une seule fois pour toute la France, et pas commune par commune). Bref, la DGFiP, c'est l'identifiant le plus utile à plus court terme. Ensuite, rien n'empêche d'ajouter un identifiant par commune participante. Et puis, dans dix ans, quand l'IGN aura vu la lumière (ou sera morte et enterrée) on pensera à mettre l'ID de la BDAdresse. -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] cadastre.openstreetmap.fr HS
Le 05/04/2013 14:54, Nicolas Moyroud a écrit : Ma question de ce matin n'était pas désintéressée parce que je vais moi aussi proposer une formation à JOSM avec ajout du bâti depuis le cadastre dans le cadre du groupe OSM local-herault. Mais bon c'est le 24 avril donc d'ici là j'ai bon espoir que ça remarche. :-) Puisque vous insistez, j'ai relancé cadastre.openstreetmap.fr temporairement :) On va espérer que ça tient plus de quelques jours. D'ici là, j'espère que les blades seront installés. -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Compteur électrique
Quoi qu'il en soit il faudra trouver une manière cohérente de documenter ces compteurs de puissance. La nature de ce qui est alimenté derrière importe peu, il y a des propriétés qui reviennent et qui doivent apparaitent dans un modèle global intégrable dans OSM. Si derrière vous voulez intégrer votre jeu de données qui ne concerne d'un ensemble partiel de compteurs ca n'est pas un problème en soi. Le 5 avril 2013 17:18, te...@free.fr a écrit : Un PrintScreen et un stylo ou marqueur, c'est ça ? :) - Mail original - De: Tetsuo Shima tets...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Vendredi 5 Avril 2013 17:01:34 Objet: Re: [OSM-talk-fr] Compteur électrique nous avons une listes Tu travailles pour une municipalité? tu souhaites faire une carte pour faciliter le travail des agent techniques de la municipalité? si oui il y a moyen d'éviter de rajouter des infos dans la base OSM tout en superposants sur un fond de carte OSM ... Le 5 avril 2013 14:36, Tony Emery tony.em...@yahoo.fr a écrit : François Lacombe wrote Une petite question: qu'est-ce qui pourrait différencier le compteur d'un bâtiment municipal et celui d'une emprise privée? Si c'est l'angle de la saisie, l'idée que nous avons est de localiser tous les compteurs électriques des bâtiments publics municipaux et pour lesquels nous avons une liste. Si c'est l'angle du compteur lui-même, je n'ai aucune idée de la différence entre le compteur d'un bâtiment public et celui d'un particulier ou d'une entreprise. -- View this message in context: http://gis.19327.n5.nabble.com/Compteur-electrique-tp5755843p5755891.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Opensnowmap.org
Alors voilà, c'est fait, je prends en compte area=yes pour piste:type=downhill. Forcément, ca fait un peu des gros patés quand on zoome beaucoup, mais c'est comme les forêts: faudra s'habituer à rajouter un point ou deux dans les angles trop pointus. Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Opensnowmap.org
Le vendredi 5 avril 2013 18:32:24 yvecai a écrit : On 04/05/2013 12:31 PM, Nicolas Dumoulin wrote: Le vendredi 5 avril 2013 12:19:15 yve...@gmail.com a écrit : Oui, un retour genre surbrillance au survol de la liste sera sûrement implanté, mais j'ai pas encore la solution. C'est sur quelle piste ce pb d'icône? Sur à peu près toutes les pistes du domaine de Pessade : http://www.opensnowmap.org/?zoom=15lat=45.62994lon=2.87237layers=e=fal sem=raster Ben oui, piste:type=nordic n'est pas renseigné sur les *ways*, sur ce domaine. Oui, ben il faudrait voir avec le wiki qui ne dit pas ça : http://wiki.openstreetmap.org/wiki/Tag:route%3Dpiste#Tags_in_Relation:route De ce que j'ai compris le piste:type va sur la relation, ce qui me semble un peu logique. La difficulté est inhérente au way, qui peut être partagé par plusieurs pistes et varier sur une même piste selon les portions de way. Le type de piste va sur la relation. Bon par contre ta doc est cohérente avec ce que tu dis :-) http://www.opensnowmap.org/iframes/how-to-fr.html Mais alors mettre un même tag sur la relation et les ways … Bon après, je peux le faire, mais je trouve ça bizarre. Merci d'ailleurs pour ta doc ;-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Opensnowmap.org
On 04/05/2013 09:57 PM, Nicolas Dumoulin wrote: Le vendredi 5 avril 2013 18:32:24 yvecai a écrit : On 04/05/2013 12:31 PM, Nicolas Dumoulin wrote: Le vendredi 5 avril 2013 12:19:15 yve...@gmail.com a écrit : Oui, un retour genre surbrillance au survol de la liste sera sûrement implanté, mais j'ai pas encore la solution. C'est sur quelle piste ce pb d'icône? Sur à peu près toutes les pistes du domaine de Pessade : http://www.opensnowmap.org/?zoom=15lat=45.62994lon=2.87237layers=e=fal sem=raster Ben oui, piste:type=nordic n'est pas renseigné sur les *ways*, sur ce domaine. Oui, ben il faudrait voir avec le wiki qui ne dit pas ça : http://wiki.openstreetmap.org/wiki/Tag:route%3Dpiste#Tags_in_Relation:route De ce que j'ai compris le piste:type va sur la relation, ce qui me semble un peu logique. La difficulté est inhérente au way, qui peut être partagé par plusieurs pistes et varier sur une même piste selon les portions de way. Le type de piste va sur la relation. Bon par contre ta doc est cohérente avec ce que tu dis :-) http://www.opensnowmap.org/iframes/how-to-fr.html Mais alors mettre un même tag sur la relation et les ways … Bon après, je peux le faire, mais je trouve ça bizarre. Merci d'ailleurs pour ta doc ;-) Bon après, le juge de paix, c'est aussi (et surtout): http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps En fait, la relation route décrit une *route*[1] de ski de fond. Mais surtout, au sol, il y a bien une voie (way, chemin, ) [2] qui est une piste de ski de fond. [1] http://wiki.openstreetmap.org/wiki/Route [2] http://wiki.openstreetmap.org/wiki/Way ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Opensnowmap.org
Le vendredi 5 avril 2013 22:10:41 yvecai a écrit : Bon après, le juge de paix, c'est aussi (et surtout): http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps Ok, merci, j'avais oublié cette page, il faudrait que ça se stabilise cette affaire. En fait, la relation route décrit une *route*[1] de ski de fond. Mais surtout, au sol, il y a bien une voie (way, chemin, ) [2] qui est une piste de ski de fond. Hmm soit. « il y a bien une voie qui est une piste de ski de fond », ça reste à discuter. Il y a des cas où c'est une voie qui est aménagée comme piste de ski de fond une petit partie de l'année et qui n'empêche pas d'autre activité d'ailleurs. Mais bon, je pinaille là, mais je trouve bizarre d'avoir besoin de l'étiquette sur le chemin et la relation. Mais OK, je te suis :-) Merci pour ton explication -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Opensnowmap.org
On 04/05/2013 10:22 PM, Nicolas Dumoulin wrote: Le vendredi 5 avril 2013 22:10:41 yvecai a écrit : Bon après, le juge de paix, c'est aussi (et surtout): http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps Ok, merci, j'avais oublié cette page, il faudrait que ça se stabilise cette affaire. En fait, la relation route décrit une *route*[1] de ski de fond. Mais surtout, au sol, il y a bien une voie (way, chemin, ) [2] qui est une piste de ski de fond. Hmm soit. « il y a bien une voie qui est une piste de ski de fond », ça reste à discuter. Il y a des cas où c'est une voie qui est aménagée comme piste de ski de fond une petit partie de l'année et qui n'empêche pas d'autre activité d'ailleurs. On doit pas être loin de 100% des cas, même. Y'a juste celle là [1] qui est démontée l'hiver :) Mais bon, je pinaille là, mais je trouve bizarre d'avoir besoin de l'étiquette sur le chemin et la relation. Et puis c'est aussi une question d'usage. Tu imagine bien que les contributeurs n'ont pas attendu route=ski ou route=piste pour mapper les pistes de fond, loin s'en faut. [1]http://www.opensnowmap.org/?zoom=15lat=-77.80979lon=166.82308layers=e=falsem=raster ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
