Re: [OSM-talk-fr] Quelques statistiques sur notre liste de diffusion talk-fr
Bonjour, Le 02/05/2013 20:30, Pieren a écrit : Bonjour, talk-fr est notre principal vecteur de communication au sein de la communauté OSM française. Comme on a pu constater quelques dysfonctionnements et non respect des règles habituelles avec ce genre d'outil, j'ai écris un petit programme pour extraire quelques statistiques d'usage (programme que je tiens à disposition de ceux qui le souhaiteraient). Il relève le nombre de messages et la taille des textes envoyés par intervenant sur une période d'un mois à partir des archives de talk-fr ([1]). La taille des contributions est estimée en comptant le nombre de mots. Le programme est assez basique. Il filtre les citations d'autres messages s'ils sont correctement identifiés par le marqueur (ce qui est le cas dans la grande majorité des cas mais cela laisse une petite marge d'erreur). J'aurais pu faire un billet de blog avec de jolis graphiques mais j'estime que ces informations ont d'avantage leur place sur cette liste et le résultat est donc présenté sous la forme de texte simple (quitte à exploser mes propres statistiques ;-) Pour mars 2013: 1192 messages et un total de 188115 mots envoyés par 141 auteurs différents. Moyenne: 8.4 messages de 1334 mots par auteur. Classement des 10 premiers auteurs par nombre de messages envoyés: 163Philippe Verdy 120Christian Quest 73Francescu GAROBY 58Pieren 51Jo. 39forum at letuffe.org 39Romain MEHUT 28sly (sylvain letuffe) 27Vincent de Chateau-Thierry 20Vincent Pottier Classement des 10 premiers auteurs par nombre de mots envoyés (et en pourcentage du total des contributions): 25%47479Philippe Verdy 8%14828Christian Quest 6%10679forum at letuffe.org 5%9042Francescu GAROBY 4%6855Jo. 3%6490Pieren 2%4222sly (sylvain letuffe) 2%3729Vincent de Chateau-Thierry 2%3381Romain MEHUT 2%3241Vincent Pottier Pour avril 2013: 1200 messages et un total de 200416 mots envoyés par 129 auteurs différents. Moyenne: 9.3 messages de 1553 mots par auteur. Classement des 10 premiers auteurs par nombre de messages envoyés: 172 Philippe Verdy 114 Christian Quest 78 Pieren 39 Guillaume Allegre 39 Tony Emery 36 Romain MEHUT 30 JB 29 Nicolas Dumoulin 26 Jo. 26 Vincent de Chateau-Thierry Classement des 10 premiers auteurs par nombre de mots envoyés (et en pourcentage du total des contributions): 25% 50473 Philippe Verdy 9% 17334 Christian Quest 5% 9456Pieren 4% 8044JB 3% 6041Ista Pouss 3% 5681Tony Emery 3% 5183Guillaume Allegre 2% 3793Jo. 2% 3739Vincent de Chateau-Thierry 2% 3649Nicolas Dumoulin J'espère que cette petite analyse contribuera à la prise de conscience de certain débordement. Un débordement...singulier :-) Merci pour ces stats, les dernières sur le même sujet ne sont plus toutes jeunes [1]. vincent [1] : http://lists.openstreetmap.org/pipermail/talk-fr/2009-September/013348.html ps. sujet pour le prochain bac philo : les mails au sujet des stats rentreront-ils dans les stats au sujet des mails ?. Vous avez 4h. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] way ferme sans tag
Salut Didier, Le 25/04/2013 19:44, didier2020 a écrit : bonsoir tt le monde, je voudrais selectionner des ways - fermés - qui n'ont aucun tags - avec josm type:way inview et ... type:way untagged closed a l'air de le faire. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] highway=turning_circle ou highway=* + area=yes?
Bonjour, De : Christian Quest C'est bien au nœud d'extremité que ce tag est le plus utile du côté réutilisation par les outils de contrôle qualité, les principaux (les seuls ?) à trouver une utilité à ce tag. Ce tag est aussi utile pour les moteurs de calcul d'itinéraire. Il permet simplement, en éliminant les _ways_ taggués noexit=yes, de construire un graphe de transit, allégé des voies strictement de destination. Maintenant, au vu des stats, il est nécessaire d'envisager les 2 configurations (sur le node de fin et sur le way) si on ne veut pas perdre une masse d'info au moment de l'exploiter. La relation entre un way et les nodes qui le constituent est connue, au moins via les schémas d'import classique (Osmosis, osm2pgsql). Donc pas besoin de se battre sur la meilleure modélisation, à mon avis, les deux se défendent, et aucune ne mène à une impasse (hum). vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartopartie au cimetière du Père-Lachaise
Bonjour, De : Philippe Verdy Il peut aussi comprendre d'autres mesures que celles générales aux cimentières parisiens (le PDF le dit aussi). Un cimentière : un cimetière en béton ? c'est un peu dangereux je trouve. Je pense qu'on a bien compris que si cette initiative se concrétise, ce sera sans toi. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] highway=turning_circle ou highway=* + area=yes?
De : Jean-Marc Liotier Si une zone de retournement existe, alors highway=turning_circle Sinon, la voie sans issue se suffit à elle même. J'ai parfois vu noexit=yes là où on souhaite expliciter que la voie est sans issue, mais cet étiquette est redondante avec l'évidence topologique d'absence d'issue - parfois renforcée par un access= ou un barrier= Je crois au contraire qu'il n'y a rien d'évident. Du coup je fais partie de ceux qui ajoutent un noexit=yes aux ways en impasse pour expliciter (par un tag) la configuration géométrique. Une manière de dire : ce way se termine en impasse ET ça n'est pas une erreur. Sinon comment distinguer un noeud de fin de way volontairement connecté à rien, d'un noeud de fin de way connecté à rien par erreur / étourderie / ignorance / mauvais usage d'un éditeur / etc, et qui ressemble en tout point au précédent, visuellement. Je trouve le coût de ce tag bien mineur comparé au bénéfice qu'il apporte. Je n'y vois pas de redondance. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu FR...
Bonjour, De : Christian Quest Je vais rajouter le oneway dans le group by, pour ne pas fusionner les tronçons avec un oneway différent. Ca reste très délicat de trouver l'équilibre. Là on voit les noms qui disparaissent, mais il faut aussi penser à tout ceux qui apparaissent par la place ainsi libérée et ceux des tronçons trop petits pour placer le nom si on ne les rassemble pas. Tout à fait d'accord, d'autant qu'on ne maîtrise pas tous les paramètres. Sans fusion, un réseau où à chaque intersection démarre un nouveau way, par le choix du contributeur ou du fait de changement d'attributs, et c'est un paquet de noms qui n'apparaîtront pas, faute de place, Mapnik ne décidant pas seul de fusionner. L'équilibre est très influençable par les exemples qu'on choisit. Quid d'un test qui marche aussi bien ici : http://tile.openstreetmap.fr/?zoom=17lat=43.94758lon=4.80566layers=B0F que là : http://tile.openstreetmap.fr/?zoom=16lat=46.67232lon=-1.42775layers=B0F ...? Des tests que j'ai pu faire, je reste pour la fusion, mais non corrélée aux valeurs de oneway. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu FR...
De : Pieren 2013/4/17 Christian Quest La modif prend en compte la population pour en afficher un peu plus (ville de 1000 habitants et +), et j'en ai profité pour gérer les tags short_name=* ainsi que quelques abbréviations automatiques pour mieux gérer l'agglomération parisienne (en haut à gauche sur les exemples ci-dessus). Heu. Chennevières-sur-M., Ivry-sur-S., Sucy-en-B. M? B? S? Tout le monde n'habite pas la région parisienne et il ne faudrait pas que ce rendu soit réservé à un public qui connait déjà les noms de ces villes... Ça n'est pas ça qui fera de ce rendu un rendu pour parisiens. Car dans ce cas, que dire du terrain ?? En banlieue : http://goo.gl/maps/hgLly http://goo.gl/maps/qOog0 mais pas que : http://goo.gl/maps/23Trs vincent de Ch.-Th. Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu FR...
De : Pieren Je ne retrouve ces abréviations que sur les cartes Michelin. Coïncidence ? Peut-être parce que tu n'as pas cherché ailleurs ? Moi je les vois tout autant sur Geoportail (autour du 1/60.000) : Villiers-S.-M., Nogent-S.-M., Bry-S.-M., etc. Mais surtout, comme dit précédemment, ces abréviations je les retrouve aussi sur le terrain. Ce que je voulais souligner au final, c'est bien que Christian n'a pas pondu dans son coin une convention ésotérique ou parisiano-parisienne. L'Île-de-France est un casse-tête à représenter à moyenne échelle, la plupart des réglages qui conviennent là fabriquent une carte vide ailleurs. Donc il faut ruser, et les abréviations font partie de l'arsenal. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM-FR à SIG La Lettre... besoin de troupes !
De : Marc SIBERT J'ai regarder les rencontres, et j'ai trouvé une inscription à 150 € TTC/j. Heu c'est nécessaire pour être au Stand OSM et trainer un peu ou pour participer aux conf ? Je n'ai pas bien lu peut être, mais ce n'est pas clair pour moi. L'accès aux stands est gratuit. C'est l'accès aux conférences qui est payant, en gros ce qui figure ici : http://www.rencontres-sig-la-lettre.fr/le-programme-2013-en-un-coup-doeil/ vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM-FR à SIG La Lettre... besoin de troupes !
Bonjour, De : rldhont Je serais au FROG puis au Code Sprint OSGEO-fr donc aux Rencontres SIG-la-lettre! Je pense en fait passez plus de temps sur l'OpenData Bar qu'au Code Sprint ;-) Donc compte sur moi René-Luc P.S: j'essayerais d're à la réunion IRC de demain soir. Je serai présent 1 des 3 jours (jour à définir selon les besoins sur le stand). vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réunion parisienne OSM d'Avril... le vendredi 26 avril ?
Bonsoir, Le 15/04/2013 17:30, Christian Quest a écrit : Vu qu'on est toujours plus nombreux pour le vendredi soir, je vous propose de nous réunir le vendredi 26 avril à partir de 19h au Père Fouettard... à moins que ça ne convienne à personne ;) Pas possible de mon côté :-( (ce vendredi sonne le début des vacances scolaires de Paris+RP) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Bonjour, Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin_level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 12:20, Philippe Verdy a écrit : Et ce n'est pas suffisant, les objets pouvant être à cheval sur plusieurs communes (une voirie, un parc, etc... ou être administré par une autre commune qui est locataire les lieux sités sur le territoire d'une autre (par exemple une déchetterie) Le 14 avril 2013 12:14, Vincent de Chateau-Thierry v...@laposte.net Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin___level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. J'entends ton argument. Ma proposition n'est pas robuste, et donc il en faut une autre. Je n'ai rien sous le coude, mais là où j'insiste, c'est sur le fait de ne pas arriver à un nouveau tag _par commune_. Il faut parvenir à un schéma avec des tags identiques pour toutes les communes. cf. en début de ce fil : http://lists.openstreetmap.org/pipermail/talk-fr/2013-March/056812.html vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 12:58, Philippe Verdy a écrit : Pourquoi FAUT-il- parvernir à ça ? Je ne vois aucune justification au fait d'avoir des tags identiques pour toutes les communes, car ce ne sont pas des éléments consitutifs d'un feature géographique. Le il faut n'est pas à prendre comme un ordre. En revanche ça me semble la cible à atteindre. Et ça n'est pas parce que ces IDs externes sont en effet, plutôt une meta-donnée qu'une donnée, qu'il faut les modéliser n'importe comment. Le feature c'est plutôt porté par les autres tags. Ici on ne parle que d'un simple identifiant qui n'indique strictement rien d'autre qu'une base externe pouvant contenir des tas d'objets géographiques ou non et même pas dans OSM non plus pour la plupart, et aussi contenant des attributs supplémentaires pour les objets OSM mais des attributs qu'on ne stockera pas. Bref, si ce qui te gène c'est de ne pas pouvoir convertir tous les attributs ref;* dans des colonnes séparées d'un tableau, tu pars mal : aucune application n'a besoin de le faire, J'adore ce genre de vérité définitive : aucune application n'a besoin de le faire. Pour affirmer ça, il faudrait connaître toutes les utilisations de la base, et le détail de chacune. C'est bien prétentieux ! Philippe, dis-toi bien que tu ne connais (et moi non plus et personne d'autre ici) pas le 1/4 du 1/3 du périmètre des applications qui s'appuient sur la base OSM. Et c'est tant mieux, au passage. Mais donc ce genre d'argument n'en est pas un. Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8=code INSEE de la commune source:identifiant de l'objet tel que géré par cette commune Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:identifiant de la maison selon la Ville de Paris vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 14:21, Guillaume Allegre a écrit : Le dim. 14 avril 2013 à 12:14 +0200, Vincent de Chateau-Thierry a écrit : Et doncon est revenu au point de départ de la discussion :-) Oui, et tant mieux, les digressions sur la meilleure réforme possible des administrations, ce n'est pas tellement ce qui va faire avancer la cause. Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Pourquoi ? Ça gêne qui ? Tout le monde à terme : contributeurs (c'est indocummentable, anti intuitif au possible) et consommateurs. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8 Et si une voie est à la limite de deux communes ayant toutes deux versé leur SIG, ça ne marche plus. Dans le cas d'une voie communale en frontière, on suffixe ref:FR:admin_level8 avec :left et :right. Cette convention est assez répandue dans les tags. avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page Qui va faire un schéma de BD contenant toutes les clés possibles ? Ça existe _en pratique_ ? ça me paraît tordu. On n'en sait _rien_ , cf. ce que je viens de répondre à Philippe. Mais justement, ne sachant pas, notre responsabilité c'est de ne pas fabriquer une usine à gaz. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 15:25, Christian Quest a écrit : Le 14 avril 2013 14:32, Vincent de Chateau-Thierry v...@laposte.net mailto:v...@laposte.net a écrit : Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8=code INSEE de la commune source:identifiant de l'objet tel que géré par cette commune Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:__identifiant de la maison selon la Ville de Paris Et ça ne marchera pas si 2 communes veulent identifier le même objet... comme tout les objets en limite de commune et plein de cas particuliers comme celui de la Maison de Victor Hugo. 2 jeux de données différents = 2 ref:xxx différents, je ne vois pas d'autre solution qui puisse tenir, désolé. Donc mettons nous dans le cas où n communes gèrent, chacune dans son coin, un seul et même objet (ex. : la déchetterie citée par Philippe). Toutes ces communes libèrent leurs données. Mince ! Nous sommes donc confrontés à une bataille (dantesque !) de sources :-) Qu'est-ce qui, dans ce type de cas, nous empêche d'utiliser, là encore, une convention de tagguage (au même titre que :left et :right), à savoir le ';' comme séparateur de valeurs ? Je n'en suis pas fan, mais ça me semble une fois de plus largement plus gérable que le mode où chaque source provoquerait l'ajout d'un tag distinct. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 16:52, Tony Emery a écrit : Vincent de Château-Thierry wrote Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8= code INSEE de la commune source : identifiant de l'objet tel que géré par cette commune Le code INSEE de la commune est presque toujours déjà présent dans l'identifiant. Chez nous, l'identifiant est du type 84087V123456. Donc, pas besoin du code INSEE de la commune source:, surtout que les : se gèrent très mal dans les Bases de données des SIG. Mais on ne peut pas établir une règle en considérant que ce qui se fait à Orange se fait partout. Il faut toujours penser au pire quand tu réfléchis à un modèle, et là, le pire, c'est une commune qui dans son SIG aurait, par exemple, des IDs qui commencent à 1 et s'incrémentent. Si 2 communes font la même chose, on n'aura pas d'unicité des identifiants. Or ce scenario est gérable si le code INSEE de la commune est imposé en début de valeur, avant un séparateur, qui peut être ':' ou autre chose. Au passage, qu'un SIG gère mal ce caractère dans un nom de champ je peux le concevoir, mais dans une valeur de champ typé en caractère, ça me semble plus improbable. Vincent de Château-Thierry wrote Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:lt;identifiant de la maison selon la Ville de Parisgt; Là, je vois pas le rapport. L'idée n'est pas de savoir qui est le propriétaire ou le gestionnaire de la voie (ça, à la rigueur, c'est le tag operator, mais dans quelle commune elle se trouve. L'idée est de savoir quel organisme a affecté l'identifiant qu'on est en train de lire. La réponse à dans quelle commune se trouve l'objet n'a pas du tout besoin de tout ça, l'inclusion spatiale dans la limite de commune suffit. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Liens de et vers OSM...
Le 14/04/2013 17:04, Tony Emery a écrit : cquest wrote Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps) serait un truc du genre bakery#u09v8z39 où bakery indique le type d'objet cherché et #u09v8z39 est le geohash de sa position approximative. C'est assez facile à mettre en œuvre pour des objets ponctuels ou surfaciques, par contre pour du linéaire je pense qu'il faudra 2 geohash (début/fin). Ça peut être encore plus complexe vue qu'une rue peut être coupée en deux et être renommée dans ces 2 parties. Mais on n'est pas obligé de commencer par le plus difficile. cquest wrote Ca inspire quelqu'un ? Qui m'accompagne sur ce projet ? Moi, carrément. Je suis ton homme !!! Je veux bien participer. Une page de wiki ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] stations service Elf remplacées par Total Access
Bonsoir, Le 12/04/2013 19:47, ar...@netcourrier.com a écrit : je commence à voir de plus en plus de stations Elf renommées en Total Access. Or d'après Taginfo, on a dans osm 13 tags Operator = Total Access pour 176 Operator = Elf. Entre autres, je viens d'en renommer une manuellement à Caen, après vérification sur le terrain. Ce qui m'amène à poser 2 questions : - Est-ce que vous confirmez que chez vous aussi le renommage est réalisé ? Par chez moi j'ai une station renommée il y a bientôt 1 an (un peu moins dans OSM [1]) et une autre qui change d'enseigne en ce moment même [2]. Donc pas de changement massif sur un temps court. - Si c'est effectivement général, y a-t-il possibilité de faire un remplacement automatique de Operator=Elf par Operator=Total Access dans OSM ? Personnellement je préfère un changement au rythme des constats terrain, à l'image de ce que tu as fait à Caen. C'était la même problématique pour l'enseigne Etap Hotel dans ce fil : http://gis.19327.n5.nabble.com/Changement-de-nom-d-une-chaine-d-hotels-tc5728761.html vincent [1] : http://www.openstreetmap.org/browse/way/82250343/history [2] : http://www.openstreetmap.org/browse/way/49946425/history ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Changeset impossible
Bonjour, De : Vincent Pottier Bonsoir, C'est moi ou... Impossible de créer un changeset ni avec JOSM, ni avec Potlatch2. Ça a l'air d'être moi, à voir les changesets qui se créent par ailleurs. But what's wrong ? Impossible d'uploader quelques modifications. Je ne sais pas si ça peux avoir un lien : https://trac.openstreetmap.org/ticket/4540 cf.: http://lists.openstreetmap.org/pipermail/talk-fr/2012-August/046681.html vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Recherche programme utile
Bonsoir, Le 07/04/2013 19:35, David Crochet a écrit : Oui, je sais le titre est con, car vouloir un programme inutile, c'est plus idiot que cela en à l'air, mais pas facile de trouver un sujet à ce courriel. Voila ce que je cherche : Le GPS Garmin journalise les données de navigation en format .gpx. Nickel JOSM arrive à les lire. Pas mieux JOSM peut télécharger la zone correspondant au données de navigation. Humf, costaud quand on fait 400 bornes en 1 journée. 98 % des chemin parcourus par le GPS sont déjà existant : donc ca sert à rien 2 % reste à faire (hum, très utile) Se taper 98% de zieutage inutile, çà gave Donc ce que je cherche est un programme qui : - Charge .gpx du GPS - définir point précédent = 1er point de départ des données .gpx - ici point de chute programme n°1 - Chargement sur 500 mètres linéaire maxi de données OSM le long du chemin défini par .gpx (distance de part et d'autre le long du chemin défini par l'utilisateur, 10 m par défaut). - définir point précédent = point de fin de la dernière données .gpx inclus dans les données OSM - Si highway existant dans zone téléchargé alors : - si angle en section chemin OSM de type highway et section chemin GPX inférieur à 3 degré, alors supprimer données (cela veut dire que le chemin est déjà existant dans OSM) - fin si - Fin si - Attendre - Si utilisateur demande suite, retourner à point de chute programme n°1 tant que point de fin différent du dernier point du .gpx sinon terminer programme Il ne devrait rester que les zones dont le highway n'est pas existant qu'il ne reste plus qu'à ajouter à OSM. c'est possible ce truc ? ou un existant existe-t'il déjà ? Je vais peut-être répondre à côté de la plaque (mais au moins t'es prévenu :-) ). Du côté d'OSRM (http://map.project-osrm.org/) tu peux procéder au calcul d'un itinéraire en spécifiant départ, arrivée, et surtout, étapes. Je ne connais pas la complexité de tes trajets, mais en cherchant à les reconstituer via ce site, ça te permettrait éventuellement de détecter les passages que tu as parcouru et que le calculateur refuse d'emprunter, que ce soit par absence d'un tracé, ou mauvaise connexion, ou sens interdit, etc. OSRM permet l'export en gpx. Une fois ton itinéraire défini au mieux, tu pourrais l'exporter et le visualiser dans JOSM en superposition à tes traces. La comparaison visuelle te permettrait peut-être de détecter tes fameux 2% à l'oeil, qui sait. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Admin_level au Sénégal
Bonjour, Le 06/04/2013 13:31, seyeize ize a écrit : On travaille dans la commune d'arrondissement de Grand Dakar, on intéresse des limites administratives et on s'est basé sur la classification française pour admin_level: http://wiki.openstreetmap.org/wiki/Key:admin_level#10_admin_level_values_for_specific_countries pour la commune d'arrondissement de Grand Dakar on a pris le niveau 9 pour délimiter le contour communal: http://www.openstreetmap.org/?lat=14.7051lon=-17.45361zoom=15layers=M et le niveau 10 pour les quartiers, maintenant on aimerai savoir s'il y a possibilité de mettre le niveau 11 pour les sous quartiers en le documentant dans le wiki project Sénégal: http://wiki.openstreetmap.org/wiki/FR:WikiProject_Senegal#Actualit.C3.A9_de_la_Communaut.C3.A9? Grand Dakar en niveau 9, l'analogie avec les choix qu'on a fait en France fonctionne en effet. Mais je n'ai pas vu de définition de la Ville de Dakar en niveau 8 (ou alors j'ai mal cherché). Peut-être reste-t-elle à tracer ? Comment sont définis les quartiers de niveau 10 ? Je n'en ai pas vu dans le périmètre du Grand Dakar. Si ce sont des zones à la délimitation définie, il serait pertinent de les tracer comme cela a été fait pour Grand Dakar, via des relations. À moins qu'il s'agisse des points tels que 'Zone A' : http://www.openstreetmap.org/browse/node/564627438 ? Après, le recours au niveau 11 dépend du niveau de détail que vous voulez atteindre, et des informations disponibles pour le définir. S'il s'agit de zones à la limite floue, approximative, il est plus simple de les positionner via un point (comme Zone A). Dans tous les cas, il serait intéressant d'inaugurer une ligne Sénégal dans le grand tableau de cette page : http://wiki.openstreetmap.org/wiki/Key:admin_level#10_admin_level_values_for_specific_countries vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Carte /rendu /question
Le 19/03/2013 10:26, Vincent de Chateau-Thierry a écrit : De : Pieren D'accord pour la cohérence. Je pense avoir été le premier à parler du tour de France sur cette liste en 2008 ([1]). Mais à l'époque, je ne parlais que de cartographier les routes, pas des itinéraires. Il y a d'ailleurs un problème éventuel de droit d'auteur, comme pour les GR. Mais surtout, un problème d'intérêt à conserver quelque chose d'inexistant sur le terrain et d'obsolète. Je vote pour la suppression de cette relation. Itou. Une autre est dans le même cas : http://www.openstreetmap.org/browse/relation/38904 Pour éviter un malentendu récurrent sur les GR : il s'agit bien de supprimer uniquement la/les relations, en aucun cas les ways (les tracés des routes) inclus dedans. Pour info je supprimerai les deux relations en question demain soir : http://www.openstreetmap.org/browse/relation/38904 http://www.openstreetmap.org/browse/relation/38907 Aucune géométrie (nodes, ways) ne sera affectée, cf les échanges ci-dessus. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Admin_level au Sénégal
Le 06/04/2013 19:45, Philippe Verdy a écrit : Si la ville de Dakar est en niveau 8 et le Grand Dakar inclut la ville toute entière (et quelques autres), le Grand Dakar devrait alors être en niveau 7 et non 9 si on retient la définition hiérarchique. Flagrant délit d'excès de vitesse, là. ...analogie avec la France... ...les arrondissements, en France c'est Paris... ...donc le Grand Dakar de là-bas c'est le Grand Paris d'ici. Mais c'est bien sûr ! Ben non. Je ne vois donc pas du tout l'analogie avec les choix faits en France ou ailleurs en Europe, ou même dans d'autres pays africains si vous inversez la hiérarchie administrative. Normal que tu ne voie pas d'analogie vu que tu n'as pas cherché à comprendre ce qu'était le Grand Dakar en question : c'est une commune d'arrondissement (donc une subdivision) de la ville de Dakar, c'était dit dès le premier message, et via le lien donné sur le WikiProjet, tu pouvais en 1 clic arriver ici : http://mairiegrandakar.com/index.php?option=com_contentview=articleid=51Itemid=58 avec au passage une carto bien connue. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Admin_level au Sénégal
Le 06/04/2013 22:18, Philippe Verdy a écrit : J'avais PARFAITEMENT compris que c'était une commune d'arrondissement, C'est donc pourquoi tu disais : Si la ville de Dakar est en niveau 8 et le Grand Dakar inclut la ville toute entière (et quelques autres), le Grand Dakar devrait alors être en niveau 7 et non 9 si on retient la définition hiérarchique. Passons. Relis bien la classification que je met, elle convient parfaitement. La perfectionça se discute. - 4 : les 14 régions - 6 : les 45 départements - 7 : les arrondissements - 8 : les 113 villes moyennes érigées en communes, ainsi que les grandes agglomérations urbaines subdivisées en communes d'arrondissement - 9: les communes d'arrondissement (uniquement dans les grandes agglomérations urbaines) - 10 : les quartiers des villes (dans les communes d'arrondissement de niveau 9) ou les villages érigés en communautés rurales (dans les autres communes de niveau 8) En parcourant cette page : http://fr.wikipedia.org/wiki/Communaut%C3%A9s_rurales_du_S%C3%A9n%C3%A9gal les Communautés rurales auraient leur place au niveau 8, j'ai l'impression qu'elles forment une partition du territoire avec les villes que tu proposes déjà au niveau 8. Et dans ce cas, les villages qui les composent pourraient être définis au niveau 9, laissant le 10 disponible pour les quartiers ou hameaux à l'intérieur de ces villages, cf. : http://fr.wikipedia.org/wiki/Villages_du_S%C3%A9n%C3%A9gal vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Admin_level au Sénégal
Le 06/04/2013 23:03, Philippe Verdy a écrit : Concernant le niveau à attribuer aux communautés rurales, je n'en suis pas sûr, ce n'est pas clair qu'elles sont au même niveau 8 que les communes (pour les villes décrites comme moyennes) ou les grandes agglomérations urbaines (divisées en communes d'arrondissement). Il faudrait une confirmation sénégalise confirmant qu'une communauté rurale ne fait partie d'aucune commune (ni commune d'arrondissement dans les 5 grandes communes urbaines ou métropoles divisées en communes d'arrondiseement). Un début de confirmation pourrait bien venir du Code des Collectivités Locales [1], où on peut lire dès le début de l'exposé des motifs : l’ensemble du Sénégal est couvert par 48 communes et 320 communautés rurales, soit au total 368 collectivités locales. (Même si les chiffres datent de 1996 et ne sont donc plus valables). Pour moi cette formulation évoque une partition, ce qui justifierait de placer sur un même admin_level, en l'occurrence le 8, les communes et les communautés rurales. Maintenant bien évidemment, si une personne ayant en 2013 une connaissance concrète de l'organisation du pays au niveau local pouvait confirmer / infirmer, on ne pourrait pas s'en plaindre. vincent [1] : http://www.gouv.sn/Code-des-Collectivites-locales.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Admin_level au Sénégal
Le 06/04/2013 23:09, Philippe Verdy a écrit : (.) Et de compléter la page Wikiproject Senegal (désolé je l'avais lu et n'ai trouvé aucun lien vers le site officiel de Grand Dakar qui n'a été fourni qu'après, et n'était pas visible d'1 clic) Comment dire... C'est le deuxième lien de cette rubrique (et non dans une quelconque sous-page) : http://wiki.openstreetmap.org/wiki/FR:WikiProject_Senegal#Actualit.C3.A9_de_la_Communaut.C3.A9 1ère ligne du tableau Évènements : Dakar - 05 avril 2013 - La Commune d’arrondissement de Grand Dakar a mis une carte OpenStreetMap : [ http://mairiegrandakar.com/index.php?option=com_contentview=articleid=51Itemid=58 son site web] J'arrête là. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Bonsoir, Le 30/03/2013 20:37, Guillaume Allegre a écrit : 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. oui, fusionner la portion commune 3) La relation 2649371 a des attributs bizarres : - pas de nom - un CANTON=Ouest pas documenté - un ref=22 pas documenté non plus S'agissant de l'extension géographique d'un bureau de vote, on peut concevoir qu'il n'ait pas de nom mais juste un n° (le tag ref). 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. Pas sûr que ce soit une typo, ça peut être la moitié d'une modélisation sur un seul champ (dans un SIG) : code_postal à gauche | code postal à droite Pas forcément heureux là où nous sommes plus habitués à des suffixes :left et :right, et donc à deux attributs au lieu d'un. Mais la modélisation directement sur les ways est banale, quasi conventionnelle, chez les fournisseurs de BD de géocodage (IGN, TomTom co). Elle n'est pas documentée dans OSM, soit. Ça ne la rend pas invalide pour autant, et rien qu'en France, dans les quelques communes a CP multiples, ça se conçoit. 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 ? Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), je verrais plutôt un schéma générique sur 2 tags : source=* (rien de nouveau ici) ref:source=* ou source:internal_id ou toute autre formulation pour dire la même chose : mentionner l'identifiant unique utilisé par le fournisseur. Dans l'exemple du way : source=Mairie d'Orange 2012 ref:source=84087V99 Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe que parce qu'une certaine source a été utilisée pour l'objet. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 30/03/2013 22:35, Guillaume Allegre a écrit : Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit : 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 ? Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), je verrais plutôt un schéma générique sur 2 tags : source=* (rien de nouveau ici) ref:source=* ou source:internal_id ou toute autre formulation pour dire la même chose : mentionner l'identifiant unique utilisé par le fournisseur. Dans l'exemple du way : source=Mairie d'Orange 2012 ref:source=84087V99 Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe que parce qu'une certaine source a été utilisée pour l'objet. Oui, mais cette façon de faire limite les possibilités d'édition ultérieures : - un objet pourrait avoir plusieurs ref (par exemple un ref:insee et un ref:FR:code-commune) - un objet peut avoir plusieurs sources : un SIG territorial à l'origine, puis une retouche par Bing ou par le cadastre et le source=Mairie d'Orange irait mieux sur le changeset Du coup, ref:source me semble trop fragile. Je pense que ref:FR:code insee commune comme proposé par Philippe Verdy est le plus sûr. Avec le schéma ref:FR:code insee commune on pourrait se retrouver avec autant de clés que de communes, toutes signifiant grosso-modo la même chose : cette clé a pour valeur une référence interne à la commune XXX. À l'extrême, 36.000 communes, 36.000 clés ? Je sais bien qu'on n'en arrivera pas là, je pousse juste la logique au bout. Et côté modélisation, autant de clés distinctes qui disent toutes la même chose, je trouve que ça fait beaucoup. Et dans ce scenario catastrophe, imagine le schéma de réutilisation, dans un modèle mis à plat comme le schéma standard d'osm2pgsql : 36.000 colonnes rien que pour la source... Et c'est aussi, à sa manière, fragile. Quid de plusieurs sources issues de la même ville (on a facilement le cas sur les grandes villes) : la source des espaces verts, celle de la voirie, etc. Pour peu que les plages de valeurs se recoupent, le tag ref:FR:insee n'a plus de valeurs uniques dans la même ville, le bénéfice de tracer la source est perdu. Ma proposition sur 2 tags a pour objectif, au moins, d'éviter la multiplicité des clés signifiant toutes la même chose. Je suis d'accord sur le fait que ça ne gère pas le multi-sources. Mais en même temps, est-ce que sur ces objets on n'est pas, quasi par principe, face à du mono-source ? Des objets issus d'un SIG communal, tracés comme tels, sont potentiellement maintenus côté OSM grâce au lien avec la base source, justement. Et si besoin, rien n'empêche d'aller un cran plus fin dans le détail, en sourçant chaque clé plutôt que l'objet dans sa globalité. On a déjà des paquets de source:addr:postcode et des source:ref:INSEE, sur le même principe. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses donnés?)
Bonsoir, Le 29/03/2013 19:54, sly (sylvain letuffe) a écrit : On vendredi 29 mars 2013, Romain MEHUT wrote: Par contre quelqu'un d'autre a indiqué que la licence IP serait incompatible avec l'Open Data étant donné la clause de non altération. Est-ce vraiment un élément qui rend incompatible ces données pour une réutilisation dans OSM? Et j'emmétrais moi même un fort doute. En effet, si la licence IP oblige une non altération des données, cela n'en fait plus une licence libre, et donc, elle n'est plus compatible avec ODBL. Mais l'interprétation du texte de la licence peut être sujette à plusieurs manière de la lire (elle est pas clair pour moi en tout cas) L'article wikipedia indique que c'est une licence libre, mais aucune citation (à part un article de presse dont l'auteur me semble avoir confondue licence du texte de la licence et licence elle même), ce que je me suis permis de compléter/corriger/mettre en doute sur WP Sur le wiki Openstreetmap VDB semble avoir conclu que c'était bon : http://wiki.openstreetmap.org/wiki/WikiProject_France/G%C3%A9oLittoral Mais la licence IP oblige une étape d'enrichissement des données pour pouvoir relicencier le travail dérivé sous une autre licence (et en l'occurrence, c'est ce travail qui nous permet de faire le passage IP - CC BY-SA / ODbL à terme) Sauf que si je lis la licence : http://www.rip.justice.fr/information_publique_librement_reutilisable La présente licence précise les conditions juridiques de réutilisation des informations publiques conformément à l’article 12 de la loi n°78-753 du 17 juillet 1978 qui impose que les données ne soient pas altérées, que leur sens ne soit pas dénaturé et que leurs sources et leur date de mise à jour soient mentionnées. J'en arrive pas tout à fait à la même interprétation que lui. Mais cette IP ressemble un peu à celle du cadastre, c'est à dire qu'elle semble avoir pour but d'éviter que quelqu'un prenne, modifie et prétende que les nouvelles données sont la responsabilité de l'organisme qui les a libérées. Genre : modifier si vous voulez, mais dites bien que c'est une version dérivée de chez nous, pas la notre Mais ça mériterait quand même un bon éclaircissement, de ce que je lis, dans une posture de prudence, c'est non, on peut pas Sur la page de téléchargement je lis : Les données peuvent faire l’objet de traitements, notamment lorsqu’ils sont nécessaires à la réalisation d’une nouvelle application ou d’un nouveau produit ou service. On entend notamment par traitement, le regroupement d’informations, le renseignement de métadonnées, l‘enrichissement, les modifications nécessaires pour permettre l’interopérabilité des données avec d’autres données. Ça ouvre quand même l'usage, en permettant d'envisager dès le départ que la donnée va être modifiée, par les traitements. Modification et altération sont deux choses bien distinctes, la première n'implique pas qu'on va dégrader la source. Concrètement si on envisage une intégration dans OSM, en rapprochant les tracés fournis des tracés highway=* existant dans notre base, que va-t-on faire ? - découper ou agréger l'information pour la faire correspondre à la granularité des données OSM, - déplacer l'information pour l'associer à des objets +/- distants, si le calage ou la précision géométrique de la source sont moindres que les tracés OSM correspondants. Rien que par ces deux exemples, on rentre dans le cadre prévu par la licence : on regroupe, on enrichit (en combinant les infos à celles des highway=* par ex.), on modifie (au moins la géométrie), pour autant on ne dénature ni n'altère les données, et au final on les rend interopérables avec le reste des données OSM. ...mais je ne suis pas juriste. vincent (qui voit le verre à moitié plein) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rues sans nom dans les lotissements et adressage
Bonjour, De : Christian Quest Ca vaudrait une analyse osmose : - place=locality trop proche de bâtiments - place=hamlet avec trop peu de bâtiments proches. - place=isolated_dwelling avec trop de bâtiments autour. La seconde aurait du sens si on partait du principe que tous les bâtiments sur le terrain sont en base. Mais pour l'instant (et pour un bout de temps), ne pas trouver de bâtiments proches en base ne veut rien dire, tant on peut avancer d'explications contradictoires : - il y a des bâtiments sur le terrain mais non tracés (= analyse ko) ou - il y a peu voire pas de bâtiments sur le terrain (= analyse ok, valeur du tag place à réviser) vincent Laposte.net, messager officiel du Rallye des Gazelles en 2013 ! Pour suivre le Rallye Aïcha des Gazelles et soutenir les participantes, cliquez sur www.laposte.net/thematique/rallye-des-gazelles ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Par des communes avec bâti (était : Rues sans nom dans les lotissements et adressage)
De : Christian Quest A coupler à un contrôle de la disponibilité du cadastre vectoriel pour la commune et/ou à la présence d'autres bâtiments sur la commune... c'est vrai que c'est moins simple, mais bon, plus les analyseurs sont pertinents mieux c'est ! Sûr. Ça m'amène une question HS : est-ce qu'on a une idée du nombre de communes pour lesquelles on peut estimer que leurs bâtiments sont, majoritairement, en base ? Je ne parle pas de la manière (import ou saisie) ni de la qualité du résultat, mais juste de la quantité, rapportée aux 36.000 communes. Si quelqu'un a déjà trituré une base pour creuser la question, je veux bien la réponse :- ) vincent Laposte.net, messager officiel du Rallye des Gazelles en 2013 ! Pour suivre le Rallye Aïcha des Gazelles et soutenir les participantes, cliquez sur www.laposte.net/thematique/rallye-des-gazelles ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Part des communes avec bâti (était : Rues sans nom dans les lotissements et adressage)
De : Francescu GAROBY La question est : à quoi doit-on comparer le nombre de bâtiments trouvés, pour une commune ? À ce que donne la moulinette du cadastre, pour les communes vectorisées ? Mais comment faire pour les autres communes ? (10% encore manquantes, mais combien ont pu être insérées sans leurs contours provenant du cadastre ?) Je n'ai pas de base de comparaison, le calcul a une part (avec un T !!) d'arbitraire, donc le résultat serait à manipuler avec précaution. Je pense qu'au moins une corrélation avec la population permettrait de ne pas dire trop de bêtises : * 50 bâtiments pour une commune en hamlet, on peut peut-être considérer que tous les bâtiments sont là * les mêmes 50 bâtiments pour un village de 500 h., ça devient improbable (en gros, le centre-bourg est peut-être mappé bâtiment par bâtiment, mais pas l'intégralité du village) * etc... vincent Laposte.net, messager officiel du Rallye des Gazelles en 2013 ! Pour suivre le Rallye Aïcha des Gazelles et soutenir les participantes, cliquez sur www.laposte.net/thematique/rallye-des-gazelles ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Part des communes avec bâti (était : Rues sans nom dans les lotissements et adressage)
De : Christian Quest didier2020 a fait un listing de ce type, il en a parlé à la réunion parisienne de mars Arf. Donc ma mémoire me joue des tours :-) vincent Laposte.net, messager officiel du Rallye des Gazelles en 2013 ! Pour suivre le Rallye Aïcha des Gazelles et soutenir les participantes, cliquez sur www.laposte.net/thematique/rallye-des-gazelles ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Part des communes avec bâti (était : Rues sans nom dans les lotissements et adressage)
Le 26/03/2013 19:10, didier2020 a écrit : Le mardi 26 mars 2013 à 16:35 +0100, Christian Quest a écrit : didier2020 a fait un listing de ce type, il en a parlé à la réunion parisienne de mars j'ai fait un croisement des données geofla / batiments dans openstreetmap avec une base osm2pgsql et associé les communes cadastre au format vecteur/image ainsi que les données de population insee voila les 2 fichiers upload.csv2 (commune au format image avec/sans batiments) verif.csv2 (commune au format vecteur avec/sans batiments) Pile ce qu'il faut :-) Pour être sûr : quand on trouve 'building' comme valeur, ça signifie qu'il n'y a aucun building tracé sur la commune ? le rapport entre la population et le nombre de batiment est tres variable et peut eventuellement servir a chercher des communes avec un import incomplete bonnes analyses, statistiques ;) Va falloir faire parler les chiffres maintenant :-) merci ! vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pont de Ponte-Novu détruit
Bonsoir, Le 23/03/2013 21:06, Francescu GAROBY a écrit : Merci à tous pour les remarques constructives et les propositions de tags. J'éviterais bridge=*, je vois plutôt 2 culs de sacs (à confirmer avec noexit=yes). En revanche ce tag me semble intéressant dans le contexte : http://wiki.openstreetmap.org/wiki/Tag:historic%3Dbattlefield Quitte à combiner avec tourism=attraction (voire tourism=viewpoint ?) si ça s'y prête. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Avis aux golfeurs...
Bonjour, Le 21/03/2013 20:58, Etienne Trimaille a écrit : Whaou ! Franchement pas mal ! :) J'aime bien ! Pas mieux ! Christian, c'est excellent :-) Mais pas sûr en revanche que Roland Garros garde un agrément pour son tournoi, y'a un terrain qui a la bougeotte : http://tile.openstreetmap.fr/?lon=2.2488lat=48.84717zoom=18layers=B0 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] récupération lignes et polygones sur Qgis
Bonjour, De : Stephane_geom j'ai déjà essayé avec d'autres dataset et cela fonctionne, cela ne vient pas du plugin je pense mais peut être du lot de données...?. j'ai essayé aussi en shp, notamment par OSM2GIS mais rien n'y fait, toujours des points... Je n'ai pas essayé, mais peut-être peux-tu tenter ta chance avec ogr : http://www.gdal.org/ogr/drv_osm.html vincent Laposte.net, messager officiel du Rallye des Gazelles en 2013 ! Pour suivre le Rallye Aïcha des Gazelles et soutenir les participantes, cliquez sur www.laposte.net/thematique/rallye-des-gazelles ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Carte /rendu /question
Bonjour, De : Pieren D'accord pour la cohérence. Je pense avoir été le premier à parler du tour de France sur cette liste en 2008 ([1]). Mais à l'époque, je ne parlais que de cartographier les routes, pas des itinéraires. Il y a d'ailleurs un problème éventuel de droit d'auteur, comme pour les GR. Mais surtout, un problème d'intérêt à conserver quelque chose d'inexistant sur le terrain et d'obsolète. Je vote pour la suppression de cette relation. Itou. Une autre est dans le même cas : http://www.openstreetmap.org/browse/relation/38904 Pour éviter un malentendu récurrent sur les GR : il s'agit bien de supprimer uniquement la/les relations, en aucun cas les ways (les tracés des routes) inclus dedans. vincent Laposte.net, messager officiel du Rallye des Gazelles en 2013 ! Pour suivre le Rallye Aïcha des Gazelles et soutenir les participantes, cliquez sur www.laposte.net/thematique/rallye-des-gazelles ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Nominatim] résultats non classés selon leur pertinence
Le 19/03/2013 20:43, Christian Quest a écrit : Le 19 mars 2013 20:03, Francescu GAROBY windu...@gmail.com a écrit : Oui, mais une rue (comme celle que je cherchais) qui se trouve dans la commune de Caen, se trouve forcément dans l'arrondissement de Caen, alors que les autres solutions proposées ne sont que dans l'arrondissement de Caen. On pourrait alors penser qu'en tapant rue Eugène Boudin, Caen, il vaudrait mieux privilégier le cas où Caen désigne commune et arrondissement, car il remplit plus de conditions que les autres résultats. Entièrement d'accord sur ce point, le résultat a des chances d'être plus pertinent si il y a cumul. Autre raison : on cherche plus souvent une adresse dans une commune qu'une adresse dans un arrondissement (qui connait vraiment les limites des arrondissements ?). Le sous-préfet ? :-) Il ne faut pas oublier non plus que les admin_level sont différents d'un pays à l'autre et les conventions d'adressage aussi... et que Nominatim essaye de gérer tout ça de façon globale. En effet, et ce dernier point reste à mon avis un des noeuds du problème. Chaque pays a sa propre logique d'imbrication des zones, d'ailleurs pas forcément administratives (penser aux zones postales aux USA par ex.). En observant les tableaux de cette page : http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative on peut constater que chaque pays fait son marché parmi les 10 voire 11 niveaux conventionnels. Aucun niveau (= aucune colonne) n'est utilisé à 100% hormis le 2 (frontières de pays). Par suite, traiter uniformément (à quelques hacks près) tous les pays donne nécessairement des résultats discutables, selon le pays. L'importance donnée chez nous aux arrondissements (de part leur admin_level) par le moteur en est une illustration : le focus est mis sur la valeur d'admin_level, et non sur l'usage, qui en France occulte ce niveau, encadré qu'il est par deux niveaux très discriminants et utilisés en permanence : commune et département. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Nominatim] résultats non classés selon leur pertinence
Bonjour, De : Christian Quest Ca vaut le coup d'un rapport de bug à mon avis en indiquant les liens ci-dessus... D'accord avec ça. C'est (indirectement) ce qu'on évoquait en février au sujet, déjà, des arrondissements [1]. Ce niveau admin (niveau 7) devrait être occulté par Nominatim sur la France compte tenu de l'homonymie entre les noms d'arrondissements et des noms de ville, et surtout de l'usage français qui combine les niveaux département et ville dans la manière de désigner un endroit. vincent [1] : http://lists.openstreetmap.org/pipermail/talk-fr/2013-February/054457.html Laposte.net, messager officiel du Rallye des Gazelles en 2013 ! Pour suivre le Rallye Aïcha des Gazelles et soutenir les participantes, cliquez sur www.laposte.net/thematique/rallye-des-gazelles ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi importer du bâtit wall=no ?
De : Jo. Petite question pendant qu'on y ai. Comme tague t'on les serres de culture vivrière ? (tomate, poireau et autre légume). J'utilise landuse=greenhouse_horticulture mais est ce que je doit associer un bâtit ? Si oui de quel type ? Tu l'avais au bout de la langue :-) : http://wiki.openstreetmap.org/wiki/Tag%3Abuilding%3Dgreenhouse vincent Laposte.net, messager officiel du Rallye des Gazelles en 2013 ! Pour suivre le Rallye Aïcha des Gazelles et soutenir les participantes, cliquez sur www.laposte.net/thematique/rallye-des-gazelles ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prochaine réunion OSM Paris... le vendredi 15 mars
Bonjour, Le 16/03/2013 06:44, Philippe Verdy a écrit : Eu Auteurs: collectifs, parution février 2013. Cela n'indique pas du tout le droit de copier. Juste que c'est une oeuvre collective dont les droits de copyright existent mais ne sont pas liés à un seul auteur vivant mais à la date de parution par son éditeur : les droits appartiennent à Michelin, entité collective. Qu'est-ce qui te fait dire qu'on a le droit de la copier ? Le 16 mars 2013 01:28, Christian Quest cqu...@openstreetmap.fr a écrit : Vous avez raté un truc majeur... la première carte Michelin qu'on aurait le droit de recopier dans OSM ! Je vais reformuler avant qu'il ne soit trop tard :-) : les informations géographiques qui ont permis de fabriquer ce plan sont intégralement issues d'une célèbre base de données collaborative sous licence ODbL 1.0 initiée en 2004 à Londres J'aurai peu de temps ce week-end pour en parler mais je vais essayer, ensuite, de publier quelques visuels rapidement. vincent ps. pour clarifier au cas où : je travaille chez Michelin, même si mes interventions ici sont toujours à titre personnel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Bonjour,
Le 11/03/2013 13:10, Christian Quest a écrit :
Le style est en place:
http://tile.openstreetmap.fr/?zoom=19lat=44.13525lon=4.8059layers=B0
Vous pouvez voir ce que ça donne sur des cas tordus et signaler les
problèmes via TRAC.
Comment ça marche ?
Requête SQL:
(select osm_id, ST_GeometryN(st_union(way),1) as way,
max(angle)-min(angle) as angle_diff, avg(angle) as angle from (select
p.osm_id, p.way as way,
cast(90+degrees(ST_Azimuth(st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),0),st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),1))) as integer) % 180 as angle from planet_osm_point p join
planet_osm_line h on (st_intersects(p.way,h.way) and h.highway is not
null and h.highway not in
('footway','cycleway','path','pedestrian','steps','service')) where
p.highway='crossing' and p.way !bbox!) as crossing group by osm_id
) as highway_crossings
Petit retour à hier : j'ai déposé par ici [1] ma manière de faire de
points orientés pour supporter un symbole avec rotation. Tu as du tout
spatial en une requête, j'ai du tout relationnel en plusieurs requêtes,
comme quoi :-)
Une question sur ta requête : comment gères-tu (ou pas) les mises à jour
en continu ? Est-ce que le zoom 19 permet, en opérant sur un volume de
données minuscule, de jouer la requête à chaque demande de tuile ?
J'avais éludé le problème de mon côté, fabriquant en une fois pour un
territoire assez large (Clermont-Fd), ce qui permet de s'asseoir sur les
performances :-(
vincent
[1] : https://github.com/vdct/Passages_pietons/blob/master/crossing.sql
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Bonjour, De : Christian Quest Première tentative de rendu des passages piétons en zoom 19... https://twitter.com/cq94/status/311052215412461568/photo/1 Qu'en pensez-vous ? Du bien :-) Et le z19 est vraiment pertinent pour ce genre d'info. C'est pas trivial... pour l'instant un seul cas de géré, le noeud highway_crossing sur un highway, mais pas à ses extrémités... y'a encore du boulot ! Que le passage piéton soit en extrémité ou pas ne change rien, si ? Ce qui compte en revanche c'est le nombre de ways convergeant sur le node : au delà de 2 il est compliqué de déterminer un angle pour le picto. J'avais fait une tentative en json [1] avec rendu par OpenLayers, mais ça n'était pas satisfaisant. En tout cas sans faire du rendu fr un inventaire à la Prevert, je trouve tout à fait sympathique de pouvoir illustrer ce niveau de détail, dans lequel figurent aussi par exemple les bornes à incendie, les bancs publics, etc. À ce niveau de zoom, on a de la place pour ça :-) vincent http://osm.vdct.free.fr/pp/index.html (limité à Clermont-Ferrand, avec des données assez anciennes) Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel maintenance serveurs OSM
Bonjour, Le 08/03/2013 13:30, te...@free.fr a écrit : C'est d'un ennui cette journée !!! ;) Alors un peu de lecture ? http://fr.slideshare.net/chippy/you-know-when-you-are-addicted-to-osm-when :-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Passerelle liste - forum (était : Activation au Mali : Video sur la progression)
Le 08/03/2013 17:32, Pierre Béland a écrit : Eh, vous avez détourné le sujet sur l'Activation au Mali. En effet, maintenant c'est Desactivation du Mail *De :* Pieren pier...@gmail.com *À :* Discussions sur OSM en français talk-fr@openstreetmap.org *Envoyé le :* Vendredi 8 mars 2013 11h19 *Objet :* Re: [OSM-talk-fr] [forum-osm-fr] Activation au Mali : Video sur la progression 2013/3/8 sly (sylvain letuffe) li...@letuffe.org mailto:li...@letuffe.org: Le précédent débat concernant la passerelle n'ayant rien donné comme conclusion, je vais ouvrir un sujet sur ce thème pour qu'on règle cette question de manière démocratique Il me semblait que des solutions se dégageaient de la dernière discussion : soit s'inscrire pour une notification directement sur le forum, soit renvoyer les messages sur une autre liste dédiée à cet usage. J'ai le même souvenir, cf. le message de Christian : http://lists.openstreetmap.org/pipermail/talk-fr/2013-February/055615.html vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Bonjour, De : Philippe Verdy Justement, des rivières, routes, voies ferrées sont parfois aussi des limites administratives. Et c'est là qu'on trouve le plus des source=inconnue ! Et ça commence à se propager ailleurs sur d'autres objets. Pas de panique. À te lire la base est en train d'être envahie par ce tag. Concrètement, on trouve d'après taginfo 8 ways avec le tag source=inconnue. Oui, 8, pas 800 ou 8000. Il proviennent tous d'un groupe de modification pas tout jeune (2010) : http://www.openstreetmap.org/browse/changeset/5210200 de sly. Et donc non ça [ne] commence [pas] à se propager. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Taguer les zones de sismicité françaises
Bonjour, De : Pieren Moi, je pense comme d'autres ici que ça n'a pas sa place dans OSM. Il existe des dizaines, voir centaines, de classements administratifs au niveau des communes, cantons, départements, sur les risques sismiques, chimiques, bruits, pollutions, qualité de l'air, de l'eau, inondations, avalanches, géologiques, miniers, lutte incendie, etc, etc. Chaque administration ou comité théodule veut sa carte des risques, son plan d'urbanisme, son analyse des disparités de revenus ou niveaux de loyers, ses zones franches. Chaque mois, des centaines de cartes sont générées par les administrations au niveau local, régional, national ou européen. OSM n'a pas vocation à rassembler tous ces résultats dans un seul endroit, même s'ils sont en opendata, au risque de rendre les données illisibles ou impossibles à éditer. Ne tombons pas dans le piège de wikipedia qui est devenu une affaire de spécialistes. D'accord avec ça, sur la problématique des découpages multiples. Je préfère voir la base comme un hub, une passerelle pour rendre géographiques des informations, plutôt qu'un grand fourre-tout où la promesse serait : tout est dans la base, pas besoin de piocher ailleurs. Quand je dis hub, ça signifie : grâce à OSM, vous pouvez associer des données _qui ne sont pas dans OSM_ avec les géométries qui sont dans la base, et la combinaison donne une nouvelle information. Un cas très concret et à portée de main : les données de l'INSEE à l'échelle des communes. Il y en a des tonnes. Si OSM doit être autonome, alors il nous faudrait intégrer, dans une ribambelle de tags longs comme le bras, les données de recensement, dont un aperçu consiste en ce type de liste : http://insee.fr/fr/bases-de-donnees/esl/comparateur.asp?codgeo=COM-18279codgeo=DEP-18 Cauchemardesque. Dans la vision hub, on se contente de stocker dans OSM (et maintenir !) le code INSEE de la commune, qui est la clé de rattachement des infos externes. À charge pour les consommateurs de la donnée OSM de procéder à la soudure des infos géographiques et des infos attributaires. Plutôt qu'une réflexion sur la liste (infinie) des données qu'on pourrait rattacher aux communes en les stockant dans la base, je souhaiterais plutôt une réflexion sur le choix des clés externes (telles le ref:INSEE) qui donnent un énorme potentiel à notre base sans l'alourdir d'une masse de contenu énorme. La question de la maintenance (maintenabilité ?) du contenu est essentielle, si on veut proposer un référentiel. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Taguer les zones de sismicité françaises
De : Christian Quest Si le découpage en question suit le découpage INSEE c'est la voie préférable, mais quand cela ne suit pas de découpage de ce type ? On a déjà les cantons dans ce cas hors maille communale : dans toutes les communes où le découpage est infra-communal, on n'a pas d'autre choix que de saisir explicitement la limite et de lui donner sa référence propre. Ce serait pareil avec les IRIS INSEE (qui divisent les grandes communes) ou avec un zonage postal, à cause des communes pluri- distribuées. Mais pour les régions militaires, les académies de l'éducation nationale, ou... les zones de sismicité (on peut facilement allonger la liste) je pense qu'on gagnera, sur le long terme, à résister (façon de parler) à la tentation de les intégrer. Et ce sans forcément frustrer les consommateurs de données OSM : je pense qu'il revient à l'eco-système des services autour de la base d'assumer, si besoin, la marche technique requise pour réparer une base des limites de régions militaires, ou des zones de sismicité, etc. Il y a sans aucun doute un créneau pour des prestations autour de la base. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un noeud pour un tableau...
De : Ab_fab Vincent, Ton panneau se trouve sur la place de la mairie (que l'on distingue en arrière plan). Oops oui en effet, mon lien est à côté de la plaque ! Panoramio n'est pas Street View, je me suis laissé avoir en parcourant les photos depuis approximativement le point indiqué par Black Myst. Désolé pour la confusion. vincent (dans le panneau) Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un noeud pour un tableau...
Bonjour, Le 04/03/2013 01:09, Jo a écrit : si je comprends bien c'est un panneau d'info, disant que cette peinture à été peint à cet endroit? 2013/3/4 Black Myst black.m...@free.fr mailto:black.m...@free.fr En corrigeant des tags wikipedia, je suis tombé sur ce point: http://www.openstreetmap.org/browse/node/1359955172 D'après ce que j'en comprends, il désigne un tableau de Van Gogh ! Je ne trouve pas particulièrement utile d'avoir un noeud pour une oeuvre dans un musée... J'imagine mal le nombre de point qu'il faudrait pour le Louvre par exemple. C'est bien un noeud pour un panneau, et un panneau pour un tableau :-) Cette photo confirme : http://goo.gl/maps/JyqUF (Et à la rigueur, il lui manque un ref=23) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé de projets
Le 01/03/2013 20:12, Christian Quest a écrit :
Cet unique way pour le Grand Paris Express, sans name et avec 2 tags
invisibles, n'est qu'un premier jet, un brouillon qui sera affiné,
je n'ai pas créé de relation pour la ligne, etc.
Vous n'êtes peut être pas concerné par ce projet, mais ça passe juste
à côté de chez moi et va avoir un impact local très important sur
beaucoup de choses. Transport bien sûr, mais aussi immobilier.
Voulant partager cette information, j'ai pensé qu'elle avait sa place
dans OSM car je ne suis sûrement pas le seul qui en aura besoin.
Allez lire l'article wikipédia: http://fr.wikipedia.org/wiki/Grand_Paris_Express
Vous verrez que c'est bien avancé, que par exemple la liste définitive
des stations a été fixée il y a presque 2 ans, le schéma a été validé
par décret en Août 2011, etc.
Mais si c'est si gênant, je ne pleurerai pas la disparition de ce way,
mais serait quand même étonné et déçu.
Je pense qu'il ne faut pas se tromper de débat. En ouvrant cette
discussion à aucun moment je ne voulais parler de l'intérêt de
l'information que tu as mis dans la base. Savoir par où passe(ra) le GPE
est en soi intéressant, qu'on soit simple curieux, futur usager de ce
réseau, voire comme toi futur riverain. Pour moi définitivement le débat
n'est pas là, il est sur la pertinence d'OSM comme réceptacle de cette
info. C'est là que je coince. Comme relevé par d'autres, on est face à
une info qui ne concerne pas le présent (le tracé n'existe pas encore)
et les travaux associés n'ont pas, sur le terrain, de réalité.
Du coup j'ai repris la suggestion de Nicolas, à savoir : et pourquoi pas
u{Map} pour montrer cette info et la partager ?
En 2mn ça donne ça :
http://umap.fluv.io/m/410/
avec un GPX issu de la géométrie que tu as mis dans la base, exporté via
JOSM. Je n'ai pas modifié le picto de chaque gare, mais sinon, l'info
est là, non ? Et je la préfère là que dans la base, vu l'avancement du
projet.
En résumé pour le besoin que tu décris (partager l'information) je
pense qu'on est à une bien meilleure place dans u{Map}.
vincent
ps. bravo Yohan :-)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr] Acheter Des Passeport / Diplome / Permis de conduire Françai
Bonjour, De : Christian Quest Je regarde avec sly ce qu'on peut faire: - soit un MOD pour phpBB qui permet de surveiller tout les forums d'un coup (ça évite le TMS dû aux vingt clics) - soit une liste de diffusion dédiée sur listes.openstreetmap.fr vers laquelle on enverrai les notifications de nouveaux sujet au lieu de les envoyer sur talk-fr. Si vous avez une autre suggestion, n'hésitez pas, mais... peace and 3 Est-ce que la 2e proposition (liste dédiée) n'est pas le meilleur compromis entre le temps que ça vous prendra et le résultat attendu ? En tout cas moi j'y souscris. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr] Acheter Des Passeport / Diplome / Permis de conduire Françai
De : Jean-Marc Liotier On 28/02/2013 14:00, Vincent de Chateau-Thierry wrote: Est-ce que la 2e proposition (liste dédiée) n'est pas le meilleur compromis entre le temps que ça vous prendra et le résultat attendu ? En tout cas moi j'y souscris. J'y souscris aussi (à l'option - pas à la liste...) Ceci dit, pour ceux qui veulent surveiller l'activité d'un forum, la génération d'un flux RSS/Atom par phpBB est une solution native efficace et triviale à mettre en œuvre. L'intérêt d'une liste ici, c'est que ça permet exactement le même usage qu'aujourd'hui, la nuance étant juste dans l'expéditeur du mail : la nouvelle liste se substitue à talk-fr, point. Alors qu'un flux RSS nécessite un client adhoc. Par exemple, le webmail de laposte.net (via lequel j'écris à l'instant) ne sait pas manger de RSS (contrairement à Thunderbird que j'utilise une autre partie de la journée). vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tracé de projets
Je tombe à l'instant sur cet objet : http://www.openstreetmap.org/browse/way/206187950 Je trouve que ça n'a pas sa place dans la base, en l'état. Outre l'absence de tags exploitables, on a surtout affaire à une entité qui n'a, et pour cause, aucune réalité sur le terrain, puisqu'il s'agit d'un projet. Il ne faudrait pas qu'OSM (la base) se substitue au travail qu'on peut produire _à partir de_ la base. Dans le cas présent, le matériau de base (des gares RATP/SNCF) a toute sa place dans OSM, en revanche la visualisation du tracé en projet, ça relève d'une exploitation des données en dehors de la base. C'est, par exemple, une composition carto dans un SIG. Voyez-vous a contrario des raisons pour garder ça en base ? (Je parle de vraies raisons, pas de ben ça ne gêne pas, alors laissons-le.) merci pour vos avis, vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Premier pas
Le 01/03/2013 06:32, Philippe Verdy a écrit : Le 28 février 2013 14:54, Vincent de Chateau-Thierry Comme souvent, ce serait tellement plus convaincant si tu pointais vers un exemple. Dans le cas présent, en Grèce, on a 2 nodes place homonymes à quelques centaines de mètres d'écart : http://www.openstreetmap.org/?lat=35.5091lon=24.0315zoom=13layers=M qui parlent manifestement de la même place. Je n'ai pas dit non plus que ces noeuds noeuds étaient homonymes (c'est même plutôt le contraire). Ils sont aussié assez éloigné et correspondent en fait à des dénominations anciennes avant une fusion (qui n'a que pour but de partager certaines compétences et budgets, mais continuer à offir le même service local aux résidents). Ce n'est pas lre cas en France je disais, mais cela existe en Espagne, en Belgique, en Allemagne et sans doûte bien ailleurs. Tu ne dois pas avoir beaucoup cherché(...) Encore heureux, Philippe. Si en plus il faut vérifier à ta place ce que tu avances, on n'a pas fini. C'est bien à toi d'étayer ce que tu dis. Et ce que j'appelle un exemple, c'est souvent, dans notre contexte, l'URL d'un objet de la base, pas un nom de pays lâché comme ça. Bref. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ouverture du portail OpenData de l'Agglomération Pau-Pyrénées
Bonjour, De : Christophe Merlet http://5stardata.info/ https://fr.wikipedia.org/wiki/Donn%C3%A9es_ouvertes https://en.wikipedia.org/wiki/Linked_data Je ne sais pas si la classification accepte les décimales :-) , mais le format Shapefile ne rentre pas dans les cases, vu qu'il est propriétaire (ESRI). Ça ne l'empêche pas d'être documenté [1] d'où son intérêt dans les échanges. vincent [1] : http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags 'postal_code' versus 'addr:postcode'
De : Francescu GAROBY Je trouve encore assez souvent la tag 'postal_code', au lieu de 'addr:postcode'. Y a-t-il une raison à garder cela ou bien peut-on envisager de basculer de l'ancien vers le nouveau tag, au moins pour la France ? On a en base 400.000 occurrences de postal_code et 9.600.000 addr:postcode. De mon côté je bascule systématiquement les tags postal_code en addr:postcode lorsque j'en rencontre. Si dans ta question tu parles d'une bascule de type bot, il faudra traiter les cas (à la marge) où on trouve les 2 tags sur un même objet. Taginfo en voit 7000 sur le monde. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags 'postal_code' versus 'addr:postcode'
De : Francescu GAROBY Une première tentative sur la Basse-Normandie et la Bretagne (plus de 1100 résultats trouvés) me font penser que ce sera un poil plus long qu'un seul rechercher/remplacer : en plus du tag 'postal_code', il y a aussi le tag 'address', qui contient toute l'adresse, et doit donc être éclaté vers les 'addr:*'. Et, tant qu'à faire, supprimer aussi le 'is_in' Apparemment, le cas est fréquent et semble avoir été fait surtout (seulement ?) sur les stations essence. Je pense qu'il faut séparer la gestion des différents cas que tu listes (même si le is_in n'est pas mon tag favori :-) ) Donc à mon avis si tu veux massivment passer de postal_code à addr:postcode il faut se concentrer là-dessus et rien que là-dessus. Quitte une fois cette étape franchie avec succès à passer à un autre traitement massif, mais tout aussi ciblé. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Conserver ou pas une relation de limite administrative?
Bonjour, De : Philippe Verdy Concernant les communes il semble y avoir consensus de garer les anciens tracés (en modifiant le nom du tag ref:INSEE), mais pour les communautés de communes, cela ne semble pas présenter d'intérêt si leur composition change du fait des fusions ou scissions de communes (ce ne sont pas réellement des limites administratives au sens premier). D'accord avec ça. Concrètement on trouve 3 relations dans la base avec comme tags : old_ref:INSEE=* et admin_level=10 Correctement documenté, c'est un usage qui me paraît valide. Autant je ne suis pas pour le stockage en base d'objets obsolètes, autant je plaide pour la conservation, spécifique, de ces entités. La nuance que j'y vois est que le matériel qu'on est susceptible de combiner à ces données (données de recensement par ex.), ayant comme clé de rattachement le code INSEE, donne une légitimité à ces objets. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Référence INSEE des communes et points admin_centre : chantiers terminés
Bonjour, De : thevenon.jul...@free.fr Je vois pouvoir m en charger avec SODA. Je n ai suivi le projet que de loin, qu est ce qu il faut verifier exactement ? Pour la partie admin_centre : une relation décrite au moins par les tags boundary=administrative et admin_level=8 doit avoir un membre avec comme rôle 'admin_centre'. Pour le sujet ref:INSEE : il s'agit de contrôler qu'aucune référence INSEE des communes actuelles ne manque dans OSM, dans le tag ref:INSEE. Pour ce sujet il y a un point à établir : avoir une liste des codes INSEE à jour, d'étendue France. Sur le site de l'INSEE, les mises à jour se terminent au 01/01/2012, donc pas de trace des fusions ou rétablissements opérées depuis. OSM peut donc se retrouver en avance localement... vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Référence INSEE des communes et points admin_centre : chantiers terminés
De : Francescu GAROBY Il faudrait aussi vérifier que le 'ref:INSEE' du node 'admin_centre' est équivalent à celui de la relation, pour détecter les fautes de frappe, erreurs d'inattention ou fusion de communes (si le node date d'avant la fusion et que la relation date d'après). Oui. Je pense que pour ça Osmose est déjà équipé : si l'analyse n'existe pas déjà, elle est à portée de main. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Référence INSEE des communes et points admin_centre : chantiers terminés
Bonjour, C'en est termin des deux chantiers PlaceMaker autour du rle admin_centre dans les relations administratives communales [1] et de l'ajout du code INSEE pour les communes en tant dpourvues [2]. Dans le premier cas, a signifie que notre manire de reprsenter une commune l'aide d'une relation est ( ce jour) homogne sur les 32.000 et quelques communes dj couvertes. Dans le second, cela aboutit normalement ce que toutes les communes rfrences par l'INSEE aient leur identifiant prsent dans OSM, soit sur la relation, soit sur un node, soit (souvent) sur les deux. Merci aux contributeurs qui y sont all de leurs clics et de leur temps ! vincent [1] : http://osm.vdct.free.fr/admin_centre/index.html [2] : http://osm.vdct.free.fr/ref_insee/index.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag canal souterrain
Bonsoir, Le 22/02/2013 22:31, Mides a écrit : J'ai bien mis layer:-1 et tunnel:culvert mais celui ci apparait quand même sur la carto, et rien ne laisse supposer qu'il n'est donc pas visible. Ajouter layer=-1 pour un tunnel, ou layer=1 pour un pont n'a d'intérêt que si d'autres objets à proximité immédiate sont, respectivement, en dessous du tunnel ou au dessus du pont. Dit autrement, si aucun objet n'a besoin d'un tag layer=-2, alors ce qui est taggué en tunnel n'a pas besoin d'être surchargé par layer=-1. Idem pour un pont : si aucun objet n'a a être placé au dessus du pont avec layer=2 (par exemple une ligne électrique), alors ajouter layer=1 est redondant avec le tag bridge=yes. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques
De : Bruno Cortial Le 20 février 2013 13:11, Christian Quest a écrit Est-il possible de faire un rendu avec les différentes intégrations combinées ? Je pense à la poste, aux écoles, etc... bref visualiser l'apport des intégrations opendata. Tout est possible, dés l'instant qu'on ne manipule pas des relations multi polygone, car l'outil d'import d'historique ne les gère pas. Ca m'embête car je voulais faire une vidéo sur les limites communales, on doit pouvoir faire ca sur une base statique en allant chercher les timestamp avec des requêtes Overpass META. Je plussois pour le rendu des limites communales (j'osais pas te le demander :-) ). Il faudra qu'il fonctionne une fois la France au complet (lire : il reste quelques mois pour mettre ça au point, tranquille). Et intéressé aussi par les rendus des thématiques opendata. merci ! vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagguer les escaliers de secours ?
Bonjour, De : Francescu GAROBY Je ne vois pas dans le wiki comment tagguer les escaliers de secours d'un immeuble. J'hésite entre déclarer ça comme un escalier (highway=steps) avec en plus un tag emergency=??? d'une part, ou déclarer ça comme étant d'abord et avant tout un élément d'urgence (et donc à ne pas utiliser en temps normal), en créant le tag emergency=steps, par exemple. Il existe un access=emergency, mais sur le wiki les seuls exemples sont orientés véhicules, pas piétons. Néanmoins, et merci XAPI, il existe (royalement !) 5 occurences de la combinaison : highway=steps + access=emergency (ils sont tous en Allemagne): http://www.overpass-api.de/api/xapi?*[access=emergency][highway=steps][@meta] Pourquoi pas ? vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osm13 est opérationnel !
Le 20/02/2013 01:27, Philippe Verdy a écrit : Je m'étonne de trouver encore un lecteur DVDROM sur un serveur, à l'heure où on installe à partir d'images virtuelles (et les lecteurs DVD restent encore sur quelques desktops mais vont aussi disparaître, à l'heure du tout en téléchargement et du cloud). Les lecteurs DVD ont la facheuse habitude de tomber rapidement en panne et ensuite d'envoyer n'importe quoi sur les connecteurs SATA ou de provoquer divers timeouts (facheux si on l'a connecté sur un slot lié à un contrôleur RAID). Ne vaut-il pas mieux l'enlever carrément et éviter une panne future à cause de lui? En plus ça gagnera de l'espace interne et ce sera aussi bien pour le refroidisssement. Le 19 février 2013 22:07, Christian Quest cqu...@openstreetmap.fr a écrit : Avec quelques photos en bonus : http://openstreetmap.fr/blogs/cquest/installation-osm13 C'est vrai Christian, tu devrais enlever le lecteur DVD et l'installer dans ta voiture pour les passagers arrières. Quoique dans une Smart... :-) Sinon, est-ce que cette machine a une destination particulière ? Tuiles au zoom 19, french rendu, instance OSRM, que sais-je...? Et au passage merci pour le temps que tu consacres à tout ça. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
Bonsoir, Le 18/02/2013 19:19, f.dos.san...@free.fr a écrit : Ah mais après on ne verra plus les tirets cadratin ;-) - Mail original - De: Christian Quest cqu...@openstreetmap.fr De mon point de vue: - ils sont artificiels : une limite administrative n'a pas en soit de nom, déjà qu'elle n'a aucune réalité sur le terrain ! - ils sont arbitraires: c'est un choix arbitraire que de mettre un nom correspondant à tel ou tel niveau, dans tel ou tel ordre: pourquoi 'Picardie - Bourgogne' et pas 'Picardie / Aube - Bourgogne / Yonne' ou 'Picardie / Bourgogne - Aube / Yonne' ? - ils ne servent qu'à un confort dans un éditeur (JOSM): il suffirait que JOSM reconnaisse le tag description ou note pour faire apparaitre cette aide appréciée par certains contributeurs (dont moi même, mais ce n'est pas suffisant au regard des problèmes causés pour que je crée des name) Toujours d'accord avec ça. Est-il possible/souhaitable: 1) de faire une modif dans JOSM pour utiliser note ou description si name est absent dans les listes de relations et de membres de relations ? Peut-être ? 2) remplacer ces name par note ou description ? Sûrement Dans quel ordre ? opère-t-on ? Je proposerais bien le 2) dès à présent avec transfert du name=* sur un tag note=*. Pour le 1), je trouve que JOSM est déjà pas mal pourvu, avec l'appartenance des objets indiquée en bas du panneau des propriétés. Encore faut-il y jeter un oeil. Je trouve qu'une action sur la visibilité des relations dans Potlatch aurait sûrement plus d'impact sur la robustesse de ces objets : il est vraiment trop facile de les supprimer / altérer sans s'en rendre compte. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Le 18/02/2013 20:54, Christian Quest a écrit : Et si on évitait de radicaliser nos points de vue respectifs ? Romain a relancé la FFRP... mais encore faudrait-il se poser la bonne question car là je pense qu'on n'est pas tous sur la même longueur d'onde. Première question: la présence de ces données dans la base OSM Deuxième question: l'utilisation de ces données Si l'une ou l'autre voit une réponse négative à une demande claire faite à la FFRP (si besoin par LRAR), oui, je pense qu'il faudra retirer les données. Mais il faudra aussi sans arrêt aller à leur chasse et faire le ménage car avant que tout les contributeur (y compris les nouveaux) saisissent le problème il pourra circuler beaucoup de peta-octets dans les fibres optiques. Il y a dans ce sujet un point qui m'échappe. Depuis la dernière grosse discussion (juin 2012) sur le quasi-même sujet, on a quand même eu du nouveau sur la thématique de violation de copyright avec la suppression des données autour de Valenciennes, données issues de Google. Quand il s'est agit de faire le ménage des données de Cedric007, il n'y avait (dites moi si je me trompe) a peu près aucune voix discordante sur le coeur du débat, à savoir : on fait le ménage des données litigieuses. Ça faisait mal à tout le monde de supprimer un travail manuel assez colossal, mais dès lors que la source était identifiée et avérée (Google), malgré la bonne foi du contributeur en cause, l'issue ne faisait pas de doute. Je ne comprends pas en quoi, sur le sujet des relations décrivant des itinéraires GR dont la propriété intellectuelle revient à la FFRP, on est dans une situation différente. C'est protégé, c'est dans la base, ça n'a en l'état pas à y être faute d'une autorisation formelle. En sauvegardant le contenu en cause dans un fichier, puis en le supprimant de la base, on est réglo, et le jour où la FFRP nous donne le go pour saisir les itinéraires des GR dans OSM (si ce jour arrive...), on se fera un plaisir de ressortir notre fichier. Mais on n'en est pas là. vincent ps. je donne mon avis ici faute d'être à Lyon en fin de semaine ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Le 18/02/2013 22:19, Jean-Claude Repetto a écrit : On 18/02/2013 21:45, Vincent de Chateau-Thierry wrote: J'y vois une différence : - dans le cas des données de Cedric007, il y avait recopie d'informations à partir de la carte Google. - dans le cas des GR et du balisage rouge/blanc, on ne fait que cartographier ce qu'on voit sur le terrain (on ne recopie pas les topo-guides FFRP). Ça fait une différence sur la manière, ok, mais pas sur le bilan : on a d'un côté des infos propriétaires, non autorisées, dans la base. Et de l'autre aussi. Non ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name sur boundary=administrative (le retour de la vengeance III)
Le 18/02/2013 23:36, Pieren a écrit : La question est de savoir si un nom doit aller dans le tag name ou note. Non. La question est de savoir si ce qui n'a pas de nom en propre doit porter un tag name. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Référence INSEE pour quelques communes (était : Mise à jour pour l'intégration des bureaux de poste)
Bonjour, De : Black Myst Le 14 février 2013 21:52, Vincent de Chateau-Thierry a écrit : En refaisant les comptes (avec des données à jour !) ce ne sont pas 930 candidats mais seulement 121, et tous dans le même département : la Dordogne. Ils sont présentés ici : http://osm.vdct.free.fr/ref_insee/index.html avec quelques explications en bas de page sur comment procéder. Je viens d'en compléter une dizaine. Merci Il est un peu surprenant de ne pas être centré dans JOSM sur le nouvel élément. Sinon, l'option Marquer comme traité n'efface pas immédiatement le message, du coup je pense que j'ai cliqué 20x sur le premier que j'ai corrigé avant de me rendre compte qu'un changement de zoom le faisait disparaître. Merci pour ton retour. Je vais essayer d'améliorer ces 2 points mais le temps presse car la liste des candidats fond :-). vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Référence INSEE pour quelques communes (était : Mise à jour pour l'intégration des bureaux de poste)
De : Vincent de Chateau-Thierry De : Black Myst Il est un peu surprenant de ne pas être centré dans JOSM sur le nouvel élément. Ça devrait mieux se passer désormais. Un petit périmètre de données autour du nouveau node est chargé depuis OSM. Sinon, l'option Marquer comme traité n'efface pas immédiatement le message, du coup je pense que j'ai cliqué 20x sur le premier que j'ai corrigé avant de me rendre compte qu'un changement de zoom le faisait disparaître. Oui, changement de zoom ou bien recliquer sur le n° de département en ayant décoché : Activer le cadrage par département. Désolé, j'ai pas mieux à l'instant. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pas japonais
De : Stéphane MARTIN Comment taggeriez-vous des pas japonais ? http://fr.wiktionary.org/wiki/pas_japonais Sauf qu'ils ne sont pas en pierre mais en bois et sur un sentier de randonnée. http://tuxdomain.dyndns.org/osm-garmin/view.php?file=Guyane/DSC00212.jpgdl=1 Une sorte de bridge avec un complément ? Si c'est sur un sentier, pourquoi ajouter bridge ? Sur ton lien, la traduction anglaise est stepping stone. Google Images semble confirmer. Dans taginfo, on trouve quelques stepping_stones comme valeur des tags highway ou surface. De mon côté je verrais plutôt ça comme valeur de surface (sur la foi de ta photo), quitte à ajouter une ligne ici : http://wiki.openstreetmap.org/wiki/Key:surface vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Référence INSEE pour quelques communes (était : Mise à jour pour l'intégration des bureaux de poste)
Bonsoir, Le 12/02/2013 16:51, sly (sylvain letuffe) a écrit : On mardi 12 février 2013, Vincent de Chateau-Thierry wrote: Ça, c'est si on décide que toutes les communes doivent avoir un ref:INSEE sans attendre le tracé de leurs limites. Je croyais que c'était le cas : si les limites sont là, ce sont elles qui portent le ref:INSEE Si elles ne sont pas là, c'est pour l'instant un noeud simple qui le porte. Modèle classique pour les shop par exemple où on recommande d'ajouter les tags à l'emprise du bâtiment si possible, mais sinon, un noeud reste tout à fait acceptable pointant approximativement le centre du magasin alors pourquoi pas. Mais il y a un côté fastidieux + jetable à considérer. Fastidieux, oui, mais jetable, pas tant : le boulot n'est pas tant dans la recherche du ref:INSEE mais plutôt de savoir où se trouve la mairie de la commune pour pointer le admin_centre, qui lui, restera, même après. Seule la ref:INSEE pourra en être retiré (ou pas, on est plus à un doublon prêt) Je compte à l'instant 930 communes candidates : sans ref:INSEE ni sur la relation ni sur un node. 930, c'est pas énorme, un joli projet de la semaine en perspective ;-) En refaisant les comptes (avec des données à jour !) ce ne sont pas 930 candidats mais seulement 121, et tous dans le même département : la Dordogne. Ils sont présentés ici : http://osm.vdct.free.fr/ref_insee/index.html avec quelques explications en bas de page sur comment procéder. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aide Xapi Viewer
Bonjour, De : Romain MEHUT Je cherche à extraire les arrêts de bus portant le tag ref:STAN= Sur Xapi Viewer http://osm.dumoulin63.net/xapiviewer/? zoom=13lat=48.66202lon=6.1726layers=B0Trequest=ref%3ASTAN%3D*icon=icons%2Ftransport_ bus_stop.n.32.pngj'arrive bien à les visualiser. J'arrive aussi à extraire les données *via* le bouton Xapi en un fichier xml. Mais impossible d'ouvrir le fichier obtenu dans JOSM. J'ai le message suivant: *Impossible de lire le fichier 'xapi.xml'. Erreur : Attribut 'version' manquant pour l’objet OSM avec l’identifiant 1645474617. (à la ligne 6, colonne 59* Tu récupères l'URL du lien 'XAPI', tu la colles dans un navigateur et tu lui ajoutes à la fin [@meta] = la réponse contiendra les métadonnées attendues par JOSM (version, auteur) : http://www.overpass-api.de/api/xapi?*[ref:STAN=*] [bbox=6.069174020385751,48.61522811794773,6.2760259796142295,48.708768482779895][@meta] vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour pour l'intégration des bureaux de poste
De : Nicolas Dumoulin Au passage, qu'en est-il du placemaker GeoFla ? http://osm.vdct.free.fr/geofla/index.html Ouh là, c'est vieux, ça :-) En fait il a eu une première vie jusque fin mai 2012, puis : http://lists.openstreetmap.org/pipermail/talk-fr/2012-June/043921.html Et il a resservi le temps d'un grand week-end après le passage du bot de Redaction : http://lists.openstreetmap.org/pipermail/talk-fr/2012-August/046511.html Mais depuis a priori il n'a plus de raison d'être. En revanche il a un petit frère ! Et qui n'a pas beaucoup de visites : http://osm.vdct.free.fr/admin_centre/index.html = il reste quelques départements (27, 30, 33, 34, 39 88) fort dépourvus en rôle 'admin_centre'. Pas de quoi faire un projet du mois, mais bien un projet de ce qui reste de la semaine :-) vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour pour l'intégration des bureaux de poste
De : Nicolas Dumoulin Donc, ça veut bien dire que toutes les communes de france (qui sont dans GéoFla) ont leur chef-lieu de référencé dans OSM (à défaut de limite de commune) ? Cool, je n'en étais pas sûr. Presque. Les communes ciblées par ce PlaceMaker étaient celles sans aucun node place=*. Celles-ci ont récupéré un node place portant le nom de la commune, avec population et code INSEE. Le nom sera très souvent le même que celui du chef-lieu, mais ça n'est pas une généralité. Les communes qui avaient déjà ne serait-ce qu'un seul node place=*, qu'il soit village, hamlet voire isolated_dwelling, n'ont pas été candidates au traitement via PlaceMaker. Donc sur le principe, rien n'empêche qu'un village n'ait aujourd'hui ni son chef-lieu, ni le nom administratif de sa commune porté par un node place=*. Il y a peut-être matière, du coup, à identifier les localités sans limite administrative, et : - n'ayant que des place=hamlet ou place=isolated_dwelling ET une population GeoFLA 100 ou - n'ayant que des place=isolated_dwelling = Peut-être leur manque-t-il un node place du côté de leur chef-lieu. Pas idée du nombre d'élues, ça méritera un test. S'il y a du monde en sortie, on en rediscute ici :-) vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour pour l'intégration des bureaux de poste
De : Nicolas Dumoulin Le mardi 12 février 2013 16:27:02 sly a écrit : Ou encore plus robuste : tester les communes du géofla qui n'ont ni limite admin avec le bon ref:INSEE, ni un place=* avec le ref:INSEE +1 J'allais le dire cher ami Ça, c'est si on décide que toutes les communes doivent avoir un ref:INSEE sans attendre le tracé de leurs limites. Dans PlaceMaker, le ref:INSEE était inclus, c'est vrai, mais le premier propos c'était de nommer les patelins jusque là en no man's land, sans aucune place ni nom. S'il y a consensus pour étendre le tag ref:INSEE à toutes les communes dès maintenant, alors pourquoi pas. Mais il y a un côté fastidieux + jetable à considérer. Je compte à l'instant 930 communes candidates : sans ref:INSEE ni sur la relation ni sur un node. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour pour l'intégration des bureaux de poste
De : sly (sylvain letuffe) On mardi 12 février 2013, Vincent de Chateau-Thierry wrote: Ça, c'est si on décide que toutes les communes doivent avoir un ref:INSEE sans attendre le tracé de leurs limites. Je croyais que c'était le cas : si les limites sont là, ce sont elles qui portent le ref:INSEE Si elles ne sont pas là, c'est pour l'instant un noeud simple qui le porte. Modèle classique pour les shop par exemple où on recommande d'ajouter les tags à l'emprise du bâtiment si possible, mais sinon, un noeud reste tout à fait acceptable pointant approximativement le centre du magasin Oui on est bien d'accord sur le modèle. Mais PlaceMaker n'a pas cherché à combler tous les trous de ref:INSEE, d'où l'incomplétude actuelle et les 930 candidats. alors pourquoi pas. Mais il y a un côté fastidieux + jetable à considérer. Fastidieux, oui, mais jetable, pas tant : le boulot n'est pas tant dans la recherche du ref:INSEE mais plutôt de savoir où se trouve la mairie de la commune pour pointer le admin_centre, qui lui, restera, même après. Seule la ref:INSEE pourra en être retiré (ou pas, on est plus à un doublon prêt) Je compte à l'instant 930 communes candidates : sans ref:INSEE ni sur la relation ni sur un node. 930, c'est pas énorme, un joli projet de la semaine en perspective ;-) Allez, vendu :-) vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Mise à jour pour l'intégration des bureaux de poste
Bonjour, J'ai mis à jour vendredi la page d'intégration des bureaux de poste [1] avec les données publiées par La Poste fin janvier 2013. Ce chantier d'intégration est ouvert depuis maintenant 9 mois, avec quelques chiffres : - 3 mises à jour fournies par La Poste, chaque trimestre comme annoncé, - 3 modèles de données successifs par La Poste (ajout des horaires, ajout des caractéristiques d'accès, retrait des infos monnaie de Paris, retrait puis retour des infos moneo,...) - environ 4900 points de contact intégrés (4200 sur cette page, 700 via Osmose), soit un petit tiers de la source. À ce sujet, voir en pj un graphique du rythme d'intégration, qui sans surprise s'essouffle sur la durée, le nombre de contributeurs distincts s'amenuisant avec le temps. Ceci pour faire echo aux récentes discussions sur les projets de la semaine / du mois : ce genre de chantier (j'associe celui d'intégration des écoles) est de longue haleine, alors n'hésitez pas à y faire un tour. Par ailleurs on commence, au fil des mises à jour, à voir apparaître des références de bureaux de poste présentes dans OSM (car intégrées) mais absentes de la source : a priori des bureaux fermés. Je compte mettre en valeur ces objets sur la page d'intégration, qu'on puisse les contrôler / supprimer. Ceci rejoint la problématique de la synchronisation, évoquée pour les arbres du CG92, et plus généralement celle de la maintenance des données de source externe. Les outils d'intégration fleurissent, mais les outils de maintenance restent à imaginer. vincent [1] : http://osm.vdct.free.fr/postes/index.html Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net attachment: rythme_integration_bureaux_de_poste.png___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour pour l'intégration des bureaux de poste
De : thevenon.jul...@free.fr De: Vincent de Chateau-Thierry Ceci rejoint la problématique de la synchronisation, évoquée pour les arbres du CG92, et plus généralement celle de la maintenance des données de source externe. Les outils d'intégration fleurissent, mais les outils de maintenance restent à imaginer. Dans le cas des bureaux de poste le besoin est plutot d une synchro base externe - OSM ou OSM - base externe ? Quelle est la problematique a resoudre ? et idealement qu est ce qu il faudrait comme fonctionnalite ? La synchro OSM = base externe a l'intérêt de boucler la boucle : on restitue au fournisseur un positionnement de ses objets plutôt plus précis que ce qu'il a fourni. Pour les bureaux de poste, c'est flagrant aussi bien en ville (quand le géocodage est au centre de la rue ou à l'îlot) qu'en rural si le positionnement est au centre de la commune. Mais ce circuit reste à construire, en commençant par porter à la connaissance des fournisseurs l'existence même d'une intégration dans OSM. Ensuite techniquement, pas de problématique particulière, dès lors qu'on sait extraire d'OSM un (x,y) et l'identifiant (ici ref:FR:LaPoste). C'est plus la synchro base externe = OSM qui me pose question. Est-ce qu'on est prêt à effacer purement et simplement un objet dans la base OSM sur la foi d'une absence de référence dans une base externe ? Comment un changement de précision de géocodage dans la source, voire un changement de (x,y) tout court, remet en question le positionnement produit dans OSM lors de l'intégration ? Fonctionnellement, ça pourrait faire émerger un outil de détection des changements dans la source, d'une release sur l'autre, pour mettre en évidence certains objets qui méritent de l'attention même une fois intégrés, sur le mode : 1- tel objet de la source millésime 1 avec la référence xxx a été intégré dans OSM 2- depuis, dans le millésime 2 (plus récent) ses caractéristiques ont changé (x,y ou attributs) 3- = il faudrait vérifier / corriger l'intégration dans OSM et garder une trace de cette vérification puis faire du millésime 2 la nouvelle référence de comparaison. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import SIG-AEV
Bonsoir, Le 09/02/2013 22:29, Christian Quest a écrit : Pas d'objection pour moi. J'ai les shapefiles d'origine pour regarde si ça vaut le coup et comment intégrer ça à l'existant... Le 9 février 2013 22:05, Vincent de Chateau-Thierry v...@laposte.net a écrit : J'ai reconstitué le jeu de données issu des 2 changesets. Je procèderai au revert (donc à l'effacement des données) demain soir, si pas d'objection. Les données ont été effacées : http://www.openstreetmap.org/browse/changeset/14986567 http://www.openstreetmap.org/browse/changeset/14986799 http://www.openstreetmap.org/browse/changeset/14987004 http://www.openstreetmap.org/browse/changeset/14987207 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Munin sur le cadastre et les communes KO
Bonjour, Cette page ne rpond plus aujourd'hui (elle fonctionnait dans la semaine) : http://osm2.crans.org/stats.db/departement/index.html = erreur 404 Si quelqu'un a les moyens d'y jeter un il ? merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Munin sur le cadastre et les communes KO
Le 09/02/2013 15:03, Jocelyn Jaubert a écrit : Le 09/02/2013 14:45, Vincent de Chateau-Thierry a écrit : Bonjour, Cette page ne répond plus aujourd'hui (elle fonctionnait dans la semaine) : http://osm2.crans.org/stats.db/departement/index.html = erreur 404 Si quelqu'un a les moyens d'y jeter un œil ? Tu es sûr que ce n'est pas la page suivante à laquelle tu penses ? http://munin.openstreetmap.fr/stats.db/departement/index.html (qui marche correctement) Oops. Oui je suis sûr...que tu as raison :-) merci Jocelyn. vincent (pas à jour dans ses bookmarks) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import SIG-AEV
Le 08/02/2013 22:13, Vincent de Chateau-Thierry a écrit : Bonsoir, Le 07/02/2013 18:48, Christian Quest a écrit : Des données ont été importées par le SIG de l'Agence des Espaces Verts d'Ile de France un petit peu par erreur: http://www.openstreetmap.org/user/SIG%20-%20AEV/edits J'ai contacté la personne et l'ai eu au téléphone. Après discussion, il s'avère qu'il s'agit d'une erreur de manip, elle pensait créer une surcouche sur le fond de carte OSM. Par contre, ces données sont libres (à confirmer formellement toutefois) et peuvent rester dans OSM... sauf que seuls les polygones ont été envoyés sans aucun tag. Je vais recevoir les fichiers shapefile d'origine pour réconcilier tout ça. Donc en attendant, il vaut mieux laisser ces polygones orphelins en l'état, plutôt que de les effacer pour éventuellement les recréer si ils sont utiles (à voir en fonction des attributs). Je serais plutôt d'avis, tant que c'est encore frais, de reverter ces 2 changesets. J'ai reconstitué le jeu de données issu des 2 changesets. Je procèderai au revert (donc à l'effacement des données) demain soir, si pas d'objection. [1] : http://www.openstreetmap.org/browse/changeset/14933121 et http://www.openstreetmap.org/browse/changeset/14934231 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import SIG-AEV
Bonsoir, Le 07/02/2013 18:48, Christian Quest a écrit : Des données ont été importées par le SIG de l'Agence des Espaces Verts d'Ile de France un petit peu par erreur: http://www.openstreetmap.org/user/SIG%20-%20AEV/edits J'ai contacté la personne et l'ai eu au téléphone. Après discussion, il s'avère qu'il s'agit d'une erreur de manip, elle pensait créer une surcouche sur le fond de carte OSM. Par contre, ces données sont libres (à confirmer formellement toutefois) et peuvent rester dans OSM... sauf que seuls les polygones ont été envoyés sans aucun tag. Je vais recevoir les fichiers shapefile d'origine pour réconcilier tout ça. Donc en attendant, il vaut mieux laisser ces polygones orphelins en l'état, plutôt que de les effacer pour éventuellement les recréer si ils sont utiles (à voir en fonction des attributs). J'ai regardé quelques polygones : c'est assez détaillé, et à première vue plutôt bien calé avec le reste des données. Mais l'upload, outre qu'il n'a pas amené d'attributs (sauf sur les multipolygons) n'a pas non plus été géométriquement réconcilié avec les géométries existantes. Je serais plutôt d'avis, tant que c'est encore frais, de reverter ces 2 changesets. Vu que l'upload était involontaire et que rien n'a été remanié lors de l'import, il n'y a pas de question sur la valeur ajoutée d'une contribution qui serait annulée par ce revert. Le moment venu, si les données sont en effet formellement libérées, on pourra sans pression se poser la question de leur pertinence dans OSM, et du moyen de les y amener. Est-ce qu'on voudra tout prendre ? Est-ce qu'on procèdera manuellement ? On n'en sait rien. Dans ce cas, partir dans une discussion avec comme préalable : de toute façon les géométries sont déjà là, alors il faut y aller, je ne trouve pas ça souhaitable. Et l'hypothèse d'une réconciliation d'attributs ne me semble pas moins fastidieuse qu'un import de contenu proprement modélisé pour OSM en amont. vincent [1] : http://www.openstreetmap.org/browse/changeset/14933121 et http://www.openstreetmap.org/browse/changeset/14934231 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Polygones/Relations
Bonjour, De : Michel Descouens Pas de problème, je tague type:multipolygon pour les berges, par contre j'ai peut être mal formulé ma question qui aurait dû être : Quel est le rôle d'une relation ? Quelques premiers éléments de réponse sur cette page : http://wiki.openstreetmap.org/wiki/FR:Relations vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Polygones/Relations
De : Vincent Pottier Le 06/02/2013 11:40, Michel Descouens a écrit : Je m'explique : je suppose que la Garonne n'est pas un tracé unique mais comporte divers segments reliés au travers d'un relation déjà existante, où puis voir dans JOSM les éléments permettant d'apprécier l'existant, ou pas ? En téléchargeant la zone (ou une partie...) dans JOSM, on voit ce qui existe. Dans JOSM, quand tu sélectionnes un objet, le panneau des attributs (à droite) indique aussi les appartenances : il s'agit de la liste des relations dont l'objet en cours de sélection fait partie. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Choix d'un tag ref
Bonsoir, Le 05/02/2013 22:17, Romain MEHUT a écrit : Vendredi soir, j'anime une formation pour des agents de collectivité. Pour être concret, je prendrai notamment pour exemple des bornes à déchets semi-enterrées récemment installées et qu'il faut donc intégrer dans OSM. Ce sera donc des amenity=recycling et amenity=waste_disposal En complément, des attributs complémentaires existants sur le wiki, je souhaiterai ajouter un tag ref à ces bornes. J'ai pensé à ref:FR:code insee de la collectivité:waste = * Qu'en pensez-vous? Pour bien comprendre : il y a un identifiant sur chaque borne (une plaque, un marquage quelconque) ? Je coince un peu sur le schema ref:Fr:code INSEE dans la mesure où ça va concerner des objets inclus dans le périmètre de la commune, et donc pour lesquels le code INSEE est connu (par inclusion spatiale). On est un peu (trop) redondant, là. Et potentiellement, c'est un schema avec à terme 36.000 noms de tags distincts :-(. Pourquoi par ref=* tout court ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Arbres du cadastre vert du CG92 [was: Ouverture de la plateforme Open Data des Hauts-de-Seine]
Le 05/02/2013 22:48, Christian Quest a écrit : Je pense que oui... ça m'étonnerai que des arbres aient plusieurs ref, non ? Le 5 février 2013 22:38, Romain MEHUT romain.me...@gmail.com mailto:romain.me...@gmail.com a écrit : Le 5 février 2013 22:04, Romain MEHUT romain.me...@gmail.com mailto:romain.me...@gmail.com a écrit : J'aurais une remarque sur les tags ref. ref:FR:CG92, CG92 ça va être intelligible pour tout le monde? aussi, celui-ci ref:FR:CG92:Arbres = IDELEMENT_ me semble juste mais ref:FR:CG92:Arbres_alignement_voirie : et ref:FR:CG92:Arbres_alignement_voirie : devraient être respectivement ref:FR:CG92:Arbres = ID_ARBRE et ref:FR:CG92:Arbres = MATRICULE non? Suite à ma question sur le choix d'un tag ref, est-ce que juste ref=* pourrait aussi tout simplement convenir? La différence c'est qu'ici la source est une source open data, et non un simple relevé terrain (comme pour les bornes). Pour d'autres jeux de données open data, on a plusieurs fois appliqué une convention pour le tag ref, à savoir : ref:FR:source=* On trouve donc des ref:FR:RATP ou des ref:FR:LaPoste qui suivent ce schéma (cf http://taginfo.openstreetmap.org/search?q=ref%3Afr ). Du coup dans le cas des arbres du CG92, pour lesquels on n'a pas relevé de ref soi-même sur place mais récupéré cette ref dans un jeu de données, ça ne me choque pas de garder comme tag ref:FR:CG92. Même si en effet il y a peu de chances que ces arbres aient plusieurs ref. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Arbres du cadastre vert du CG92 [was: Ouverture de la plateforme Open Data des Hauts-de-Seine]
Le 05/02/2013 23:47, Jean-Marc Liotier a écrit : Bon... Maintenant je doute. Les deux me vont... Comme je suis novice en matière de spécification d'imports, je m'en remet à votre jugement. Aïe, ça va pas être facile :-) ref:FR:CG92 est peut-être plus autonome (si le tag source bouge pour une raison quelconque). Et du coup ça peut libérer le tag source pour y mettre l'url du site, à savoir : http://opendata.hauts-de-seine.net/ plutôt qu'une référence au wiki OSM. Cette proposition est plus une histoire de convention adoptée pour de précédents jeux de données qu'autre chose. Ça n'invalide pas pour autant la combinaison : - ref=* - source=CG92 mais c'est moins robuste, à l'heure où on fait fleurir des espaces de nommage en FR:* pour nos fournisseurs opendata. Bref... bonne nuit :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] data.shom.fr
Bonjour, De : François Lacombe Pour avoir également un tracé de toute la cablasse maritime. Il faut néanmoins un accès nominatif pour avoir accès aux données attributaires donc impossible de savoir si ce sont des câbles électriques, télégraphiques ou optiques. Le 4 février 2013 13:50, Art Penteur a écrit : Pas vu passer l'annonce ici, alors je relaie. Peut-être intéressant pour un trait de côte officiel ? Art. Le portail données publiques du SHOM est accessible au public depuis le 28 janvier 2013. Il permet à tous les usagers (services de l’État, collectivités territoriales, entreprises, citoyens…) de rechercher, de visualiser et d'accéder aux données de référence du SHOM, décrivant l’environnement physique maritime, côtier et océanique, et son évolution. Cette plate-forme de diffusion de données géographiques est conformes aux exigences de la directive Inspire. Les aspects de licence sont moyennement accesibles. Il en ressort que tout ce qui est disponible sur ce site n'est pas sous une seule licence. J'ai trouvé ça : http://www.shom.fr/les-services-en-ligne/portail-datashomfr/ où la liste des couches opendata est bien courte. Et sur le trait de côte, la licence bloque, j'ai l'impression : Le fichier Trait de Côte Histolitt est librement réutilisable dans des bases de données ou services intégrés dans les conditions suivantes : - mention explicite de la source des données TCH par la mention © IGN-SHOM 2007 lors de leur visualisation, - indication claire à l'utilisateur des limites d'usage de cette donnée. - représentation sur site internet accompagnée obligatoirement des logos de l'IGN et du SHOM, munis d'un lien vers les url www.ign.fr et www.shom.fr Tout autre mode de réutilisation, en particulier dans le cadre de services commerciaux, doit être l'objet de la délivrance d'une licence particulière par l'IGN ou le SHOM. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vider le cache des tuiles Bing Mapnik
Le 04/02/2013 23:21, Philippe Verdy a écrit : Il y a des utilitaires divers de nettoyage automatique de Windows, tu peux les paramétrer pour qu'ils allent faire le ménage plus souvent en ajoutant ce dossier. Sinon le dossier peut rester dans le dossier temporaire de l'utilisateur. Mais je suis d'accord sur le fait que le cache de JOSM est mal fichu : si le nettoyage prend autant de temps c'est parce que TOUS les fichiers sont dans le même dossier et que leur suppression un par un oblige Windows à sans arrêt retrier les index. Solution pour accélérer ça : déplacer ce dossier non pas sur un volume NTFS (où les dossiers sont maintennus triés) mais sur un volume FAT. Et là la suppression dans un même dossier contenant des milliers de fichiers va beaucoup plus vite, même si FAT a tendance à se fragmenter énormément. Le cache de JOSM n'est en plus pas conforme à HTTP (il ne tient pas compte des dates de péremption, ni même d'un comptage de volume maximum, et JOSM n'a aucun thread nettoyeur pour virer les fichiers obsolètes ou en excès par rapport au colume maximum indiqué, sans compter aussi que le nombre de fichier est doublé car il stocke un fichier pour la tyuile et un autre fichier pour n'y mettre que les ETag de transaction HTTP, dont la conservation est pourtant totalement inutile dès que la transaction est terminée). Ce cache (en fait c'est le module JTiles) n'a aucune structure comparable à ce que réalisent tout bon navigateur web pour faire des purges efficaces. Le 4 février 2013 22:44, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Sous Windows, JOSM stocke dans un répertoire de cache les tuiles Bing Mapnik. Je cherche un moyen de supprimer régulièrement ces fichiers. Auriez-vous une idée? Windows est à la ramasse pour supprimer près de 6 .png En version rustique, tu peux arriver à tes fins avec une fenêtre DOS et 3 lignes de commande : cd c:\users\login\appdata\local\temp\JMapViewerTiles_login del Bing Aerial Maps\*.png del Bing Aerial Maps\*.tags En fonction du nombre de fichiers ça peut être long (20 bonnes minutes à l'instant pour 18 pngs, misère !) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [2ème round] Proposition(s) pour un petit coup de balais dans les tags access/oneway
Le 04/02/2013 23:14, sly (sylvain letuffe) a écrit : Re, Suite aux avis exprimés sur : http://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053869.html Je propose une version allégée pour mon premier coup de balais : * Retrait des tags fixme=name uniquement lorsqu'il n'y a pas de nom à l'objet (pas de changement si l'objet à les deux tags name=xx + fixme=name car on considère que le sens est ambiguë) Le 2ème reste inchangé : * Retrait des fixme=set better denotation sur tous les arbres Ok pour moi. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vider le cache des tuiles Bing Mapnik
Le 04/02/2013 23:37, Philippe Verdy a écrit : Merci mais je connaissais déjà la solution C'est bien à ton mail que je répondais, mais c'était surtout une réponse à la question de Romain. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] La corée du nord sur gmaps
Bonjour, Le 03/02/2013 10:04, Philippe Verdy a écrit : Vous pouviez déjà réagir dans les commentaires directement sous l'article. Pas forcément. Sur lemonde.fr, les commentaires ne sont pas ouvert à tous. Pour réagir, il faut être abonné. Le 31 janvier 2013 02:41, Severin MENARD severin.men...@gmail.com a écrit : Et tous les médias suivent, Le Monde pompant allègrement les mêmes andouilleries : http://www.lemonde.fr/technologies/article/2013/01/29/google-rend-la-coree-du-nord-plus-transparente_1823754_651865.html On devrait peut-être contacter le journaliste ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème de localisation de Rennes
Le 03/02/2013 13:36, Pieren a écrit : 2013/2/2 Vincent de Chateau-Thierry v...@laposte.net: Et surtout, la règle que tu énonces (homonymie avec l'admin_centre) n'en est pas une. Euh, pour Rennes, un peu quand même, non ? Pour Rennes si tu veux. Je te laisse l'appliquer à Strasbourg (bon courage) : http://layers.openstreetmap.fr/?layers=BFFFTzoom=10lat=48.61899lon=7.2 JOSM indique [7] en face de ces relations, comme indicateur du niveau administratif. Il ne faut pas voir les données qu'à travers la lorgnette de JOSM. Je parlais de JOSM tout simplement en réponse à la remarque de Mickaël : pour l'édition, on voit tout de suite à quel genre de relation on a faire dans JOSM Concernant Nominatim, tu mets le doigt sur le fond du problème, à mon avis. Nominatim fait des choix, et c'est en fait eux qui sont le sujet. En dehors de nominatim qui peut sans doute être amélioré, il faut surtout appeler un canard un canard. Je dis ça par ce qu'il faut parfois revenir à des notions simples comme énoncé sur ce wiki: http://wiki.openstreetmap.org/wiki/Duck_tagging If it looks like a duck and quacks like a duck, tag it as a duck si ça ressemble à un canard et que ça cancane comme un canard, tag le comme un canard. Si on te montre une carte qui souligne les coutours de l'arrondissement de Rennes, tu ne vas pas dire hé, mais c'est Rennes mais plutôt hé ben, ça, c'est l'arrondissement de la sous-préfecture de Rennes ? Non. Si c'est sur une carte des arrondissements, on va dire : hé, mais c'est Rennes. Bref, on peut continuer longtemps comme ça, hein :-) Autre choix : faire tout rentrer dans un même moule. Par simplicité, la structure des données de Nominatim range nos régions dans un niveau state, les arrondissements dans county comme tu le soulignes. En France ça ne veux rien dire, mais j'imagine que ça facilite la gestion des réponses de Mouais. 1er exemple pris au hasard, le comté de Los Angeles, USA: http://www.openstreetmap.org/browse/relation/396479 avec le tag name=Los Angeles County En prenant un exemple aux US pour argumenter sur une situation française on ne risque pas d'aller bien loin. Je te rappelle ce que je mentionnais vendredi, issu du COG : http://insee.fr/fr/methodes/nomenclatures/cog/arrdep.asp?codedep=35 = on n'a pas arrondissement de devant chaque nom d'arrondissement, pas plus pas moins qu'on a commune de dans cet autre tableau : http://insee.fr/fr/methodes/nomenclatures/cog/comcan.asp?codedep=35codecan=47 issu du même. Et il ne faut pas mélanger le nom des tags de Nominatim (county,country) et le nom du niveau de découpage qui y est rangé (arrondissement,Bezirk,district, etc.). C'est ce dernier qui doit être adapté selon le pays. Le 03/02/2013 13:43, Pieren a écrit : Si on part du principe que tout se déduit de la combinaison des tags, alors plus besoin de mettre Mairie de Rennes sur un amenity=townhall mais seulement Rennes (puisque la mairie se déduit du amenity). Ou École de Triffouilly-les-oies puisqu'il y a un amenity=school. etc Pour les écoles on a la chance d'avoir le terrain pour constater les noms. Pour les limites admins c'est déjà moins facile, surtout pour des niveaux peu utilisés au quotidien comme les arrondissements. Mais il ne s'agit pas de faire de ce qu'on discute pour les arrondissements (et plus généralement les découpages admins) un principe pour les écoles ou les jardins publics. À tout amalgamer on ne ressort rien de bon. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème de localisation de Rennes
Le 03/02/2013 12:16, Mickaël Guéret a écrit : Si je résume, Nominatim devrait : - Compléter le nom des relations de limites administratives de niveau 7 en Arrondissement de %name% dans le contexte français. S'il tient à les montrer dans ses résultats, oui. Ou en plus simple : %name% (Arrondissement). - de même, il faudrait compléter le nom des relations de limites politiques de type canton par Canton de %name% Idem. - Ne pas retourner ce niveau (7) dans le résultat détaillé. ex : [1] , countyArrondissement de Rennes/county), en France on attendrait plutôt countyIlle-et-Vilaine/county, soit le niveau 6. Le niveau 6 devrait être une constante des réponses en France. Aujourd'hui il est masqué par le 7 quand le 7 existe. Pour une réponse détaillée, pourquoi pas ajouter le 7. Mais pour une réponse synthétique, présentable au grand public et sans ambiguïté, le 7 est superflu. - Et pour être encore plus précis (je ne sais pas ce que cela implique ??) : department au lieu de county et pendant qu'on y est region à la place de state, pour mieux coller au contexte français... Le nom des balises importe peu, dès lors qu'on comprend bien ce qui est mis dedans. Et là, c'est pays par pays que le sens diffère. J'ai du mal à imaginer qu'un xml change de noms de balises pays par pays. En revanche, ajouter dans la réponse une balise telle que : county_level_nameDépartement/county_level_name apporterait un vrai plus, pour adapter le vocabulaire au contexte du pays. J'ai bien résumé ? yep :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
