Re: [OSM-talk-fr] Éditer une carte
Le 19 novembre 2013 21:05, Vincent Pottier vpott...@gmail.com a écrit : Bonsoir, Le diocèse de Besançon veut refaire sa carte et cherche un éditeur pour ça. Coup de chance tout, ou presque (je crois) est dans OSM : diocèse, doyennés, unités pastorales... Le but c'est de faire une carte papier, un PDF ? Ou une carte glissante ? Je pose la question comme ça, car moi aussi j'ai peu de chance d'avoir du temps... c'est pour faire avancer le Schmilblick. Si ils ont un tableau donnant pour chaque commune son UP et son doyenné, ça serait plus simple que d'extraire ces infos de la base (ou ça permettra une vérification). Pour les communes appartenant à plusieurs UP il faudra raffiner un peu mais il n'y en a sûrement pas beaucoup ? Damouns ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
Le 19 nov. 2013 à 23:29, Jean-Marc Liotier j...@liotier.org a écrit : On 11/19/2013 05:43 PM, Maïeul wrote: Le 19.11.13 12:51, Jean-Marc Liotier a écrit : On 19/11/2013 12:45, Maïeul Rouquette wrote: il doit effectivement y avoir mécompréhension. Et là je ne comprend plus quoi est quoi. Ce que j'appelle fond de carte et ce que je veux c'est juste une délimitation des continents et des îles. Pas de route, pas de ville, rien (parce que je doute que les villes antiques qui m'intéresse soient dessus) Tu veux http://openstreetmapdata.com/data/coastlines - un magnifique shapefile t'y attend ! j'ai essayé, trop lourd pour qgis ... Avec quelle configuration matérielle ? mac dual core 2.7 Ghz, 8go de ram ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
Le 19.11.13 23:38, Jean-Marc Liotier a écrit : On 11/19/2013 06:03 PM, Maïeul Rouquette wrote: est-ce que avec les coastfiles je peux obtenir une carte où je placerais mes points en fonction de coordonnées que je connais ? Qu'est-ce que tu entends par 'carte' ? Une couche dans un logiciel tel que QGIS ? Un gros bitmap ? Couverture mondiale ? Notes que les lignes de côtes ne sont pas tout ce qu'on trouve généralement sur une carte muette - même pour des travaux historiques, tu souhaiteras peut-être avoir plans d'eau, fleuves (mais pas canaux), sommets et cols... Et tu te retrouves alors avec le problème initial: sélectionner, extraire et rendre des données d'Openstreetmap. Si tu veux un gros bitmap couvrant une zone modeste, l'idée de rainerU d'utiliser Maperitive est viable - et tu peux utiliser le bitmap comme fonds de carte pour les données historiques que tu gères dans QGIS. je ne sais pas ce que tu appelle couche. Pour moi une cartes ce serait une chose très simple (les données historiques de geographique que j'ai besoin sont limités). Des limites de côte, des villes, et des traits entre les villes, symbolisant les itinéraires des personnages que j'étudie (vu la précision de mes textes, les données de type fleuves, montagnes etc ne servent à rien …) -- Maïeul http://blog.maieul.net http://geekographie.maieul.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
On 20/11/2013 09:35, Maïeul Rouquette wrote: Le 19 nov. 2013 à 23:29, Jean-Marc Liotier j...@liotier.org a écrit : On 11/19/2013 05:43 PM, Maïeul wrote: Le 19.11.13 12:51, Jean-Marc Liotier a écrit : Tu veux http://openstreetmapdata.com/data/coastlines - un magnifique shapefile t'y attend ! j'ai essayé, trop lourd pour qgis ... Avec quelle configuration matérielle ? mac dual core 2.7 Ghz, 8go de ram Je n'ai pas la moindre idée de ce qui est nécessaire - quelqu'un ici peut-il nous dire si cette configuration devrait suffire ou s'il est normal qu'elle ne s'en sorte pas ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
On 20/11/2013 09:46, Maïeul wrote: je ne sais pas ce que tu appelle couche Couche : terme informatique et géomatique, une couche est constituée par le regroupement d’objets présentant une relation entre eux. C’est une structuration simple des données, au moment de leur acquisition, qui est effectuée par analogie à la superposition manuelle antérieure de calques et destinée à faciliter la gestion ultérieure de ces objets (Définition donnée par le groupe de travail « instrumentation géographique » du CNIG). Pour moi une cartes ce serait une chose très simple (les données historiques de geographique que j'ai besoin sont limités). Des limites de côte, des villes, et des traits entre les villes, symbolisant les itinéraires des personnages que j'étudie (vu la précision de mes textes, les données de type fleuves, montagnes etc ne servent à rien …) Ok - alors les lignes de côté suffisent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
Le 20 nov. 2013 à 10:18, Jean-Marc Liotier j...@liotier.org a écrit : On 20/11/2013 09:46, Maïeul wrote: je ne sais pas ce que tu appelle couche Couche : terme informatique et géomatique, une couche est constituée par le regroupement d’objets présentant une relation entre eux. C’est une structuration simple des données, au moment de leur acquisition, qui est effectuée par analogie à la superposition manuelle antérieure de calques et destinée à faciliter la gestion ultérieure de ces objets (Définition donnée par le groupe de travail « instrumentation géographique » du CNIG). Pour moi une cartes ce serait une chose très simple (les données historiques de geographique que j'ai besoin sont limités). Des limites de côte, des villes, et des traits entre les villes, symbolisant les itinéraires des personnages que j'étudie (vu la précision de mes textes, les données de type fleuves, montagnes etc ne servent à rien …) Ok - alors les lignes de côté suffisent. donc par exemple : mes villes seraient une couche, mes traits entre eux une couche, et les côtes la couche primaire ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil pour ajout de name:fr ?
Am 20.11.2013 02:06, schrieb Christian Rogel: Quand je mets (rarement) des name:br a des localités qui ont des noms en langue régionale, je procède de la même façon. Ex;emple de ce qui est ou pourrait être pratiqué name:br Marsilha (Marseille), name:br Perpinya, name:br Lemotges, name:br Strassburg Tu illustres bien quelques problèmes de la duplications des toponymes. Tu mets name:br=Perpinya car il y a déjà name:ca=Perpinya. Moi je m'aperçois de la faute d'orthographe et je corrige name:ca=Perpinyà sans toucher au name:br. Pareil pour Strassburg. Et pourquoi Straßburg et non pas Strossbüri? Cela suit une coutume littéraire et journalistique. Dans ce cas ne serait il pas mieux de spécifier une fois pour toute que le nom breton dans les territoires catalanophones est identique au nom catalan? Ce qu'il faut, c'est des multipolygones pour les territoires avec une culture linguistique homogène, avec des attributs du genre lang:offcial=fr, lang:spoken=ca, lang:br=lang_ca. Il suffirait alors de mettre en name le nom officiel écrit sur les panneaux, et en name:xx les noms dans les langues pour lesquelles il ne peut pas être déduit sur la base des infos sur le multipolygone englobant. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
Salut, je viens de télécharger le jeux de données coastlines et de tester, ça s'ouvre très bien avec une configuration à peu près similaire à la tienne (sous windows) ! peut-être qu'il y a un problème avec ton installation de QGIS ? Pour tout ce qui est des concepts de cartographie numérique, je ne peux que vivement te recommander d'aller jeter un coup d'oeil à la documentation de QGIS, elle reprend notamment les bases pour être sur que tout le monde utilise le même vocabulaire ... http://qgis.org/fr/docs/index.html Sylvain Le 20 novembre 2013 10:13, Jean-Marc Liotier j...@liotier.org a écrit : On 20/11/2013 09:35, Maïeul Rouquette wrote: Le 19 nov. 2013 à 23:29, Jean-Marc Liotier j...@liotier.org a écrit : On 11/19/2013 05:43 PM, Maïeul wrote: Le 19.11.13 12:51, Jean-Marc Liotier a écrit : Tu veux http://openstreetmapdata.com/data/coastlines - un magnifique shapefile t'y attend ! j'ai essayé, trop lourd pour qgis ... Avec quelle configuration matérielle ? mac dual core 2.7 Ghz, 8go de ram Je n'ai pas la moindre idée de ce qui est nécessaire - quelqu'un ici peut-il nous dire si cette configuration devrait suffire ou s'il est normal qu'elle ne s'en sorte pas ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil pour ajout de name:fr ?
Le 20 novembre 2013 10:28, rainerU ra...@sfr.fr a écrit : Am 20.11.2013 02:06, schrieb Christian Rogel: Quand je mets (rarement) des name:br a des localités qui ont des noms en langue régionale, je procède de la même façon. Ex;emple de ce qui est ou pourrait être pratiqué name:br Marsilha (Marseille), name:br Perpinya, name:br Lemotges, name:br Strassburg Tu illustres bien quelques problèmes de la duplications des toponymes. Tu mets name:br=Perpinya car il y a déjà name:ca=Perpinya. Moi je m'aperçois de la faute d'orthographe et je corrige name:ca=Perpinyà sans toucher au name:br. Pareil pour Strassburg. Et pourquoi Straßburg et non pas Strossbüri? Et pourquoi la modification ou correction de name:ca=Perpinyà doit impacter name:br=Perpinyà ? Chaque langue a ses règles de conservation ou non d'un nom. Bref totalement inutile (et même nuisible) de gérer des polygones pour chercher une langue applicable ! Le problème n'est strictement JAMAIS géométrique/géographique. Il est purement linguistique et ne concerne QUE l'objet qui porte ce nom et strictement aucun autre (pas la peine d'aller chercher ailleurs, c'est coûteux en plus, alors que TOUTE l'info est soit dans l'objet lui-même, noeud ou chemin, soit dans l'objet relation qui le référence directement sans jamais faire appel à la géométrie). Ce problème est exactement le même hors d'une base cartographique, par exemple pour traduire l'interface d'un logiciel ou le contenu d'un site web quelconque: - on a déjà identifié le sujet précisément (c'est l'objet de notre base et aucun autre) - on y apporte une donnée linguistique à traduire, le nom (ce pourrait être un message d'interface utilisateur cela ne change rien) - et c'est ces traductions de ce seul sujet qu'il faut gérer, SANS JAMAIS en changer (en allant voir d'autres objets de note base : si tu recherche un polygone, tu changes de sujet, le résultat sera alors complètement aléatoire, on ne peut absolument pas utiliser ça pour changer librement de langue). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
oui les coastlines s'ouvrent sans problème. Mais je n'arrive pas à en sélectionner un seul morceaux pour faire des coupures. L'outils de sélection ne sélectionne rien..Le 20 nov. 2013 à 10:23, Sylvain Maillard sylvain.maill...@gmail.com a écrit :Salut,je viens de télécharger le jeux de données coastlines et de tester, ça s'ouvre très bien avec une configuration à peu près similaire à la tienne (sous windows) !peut-être qu'il y a un problème avec ton installation de QGIS ?Pour tout ce qui est des concepts de "cartographie" numérique, je ne peux que vivement te recommander d'aller jeter un coup d'oeil à la documentation de QGIS, elle reprend notamment lesbases pour être sur que tout le monde utilise le même vocabulaire ...http://qgis.org/fr/docs/index.htmlSylvainLe 20 novembre 2013 10:13, Jean-Marc Liotierj...@liotier.orga écrit :On 20/11/2013 09:35, Maïeul Rouquette wrote:Le 19 nov. 2013 à 23:29, Jean-Marc Liotier j...@liotier.org a écrit :On 11/19/2013 05:43 PM, Maïeul wrote:Le 19.11.13 12:51, Jean-Marc Liotier a écrit :Tu veuxhttp://openstreetmapdata.com/data/coastlines- un magnifique shapefile t'y attend !j'ai essayé, trop lourd pour qgis ...Avec quelle configuration matérielle ?mac dual core 2.7 Ghz, 8go de ramJe n'ai pas la moindre idée de ce qui est nécessaire - quelqu'un ici peut-il nous dire si cette configuration devrait suffire ou s'il est normal qu'elle ne s'en sorte pas ?___Talk-fr mailing listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
On 20/11/2013 10:21, Maïeul Rouquette wrote: donc par exemple : mes villes seraient une couche, mes traits entre eux une couche, et les côtes la couche primaire ? Voilà - dans l'ordre d'empilement des calques de haut en bas: - Itinéraires des personnages (polylignes) - Villes (points) - Fonds de carte (image générée à partir des traîts de côte d'OSM) Une polyligne ou un point peuvent être chargés d'attributs - si tu es familier des bases de données tu peux considérer chaque objet comme un enregistrement (dans un tableau une ligne - dont les attributs sont les colonnes) En attendant de trouver ou de générer le fonds de carte muet de tes rêves, tu peux toujours commencer avec n'importe quel autre fonds de carte - tes couches Itinéraires et Villes seront indépendantes et tu peux donc changer le fonds de carte ou ajouter n'importe quelle autre couche sans que ça ait le moindre impact dessus. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
- Maïeul http://blog.maieul.net http://www.schtroumpfs.maieul.net/ Le 20 nov. 2013 à 10:41, Jean-Marc Liotier j...@liotier.org a écrit : On 20/11/2013 10:21, Maïeul Rouquette wrote: donc par exemple : mes villes seraient une couche, mes traits entre eux une couche, et les côtes la couche primaire ? Voilà - dans l'ordre d'empilement des calques de haut en bas: - Itinéraires des personnages (polylignes) - Villes (points) - Fonds de carte (image générée à partir des traîts de côte d'OSM) Une polyligne ou un point peuvent être chargés d'attributs - si tu es familier des bases de données tu peux considérer chaque objet comme un enregistrement (dans un tableau une ligne - dont les attributs sont les colonnes) En attendant de trouver ou de générer le fonds de carte muet de tes rêves, tu peux toujours commencer avec n'importe quel autre fonds de carte - tes couches Itinéraires et Villes seront indépendantes et tu peux donc changer le fonds de carte ou ajouter n'importe quelle autre couche sans que ça ait le moindre impact dessus. C'est là où j'ai un peu du mal à saisir : si je modifie l'emplacement de mes villes sur la couche ville, cela ne changera pas automatiquement les traits entre ces villes sur la couche itinéraire des personnages ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Centraux téléphoniques
Bonjour, En regardant d'un peu plus près le bâti dans certaines villes, de nombreux centraux téléphoniques France Telecom commencent à apparaître dans différentes villes. Même si des contributeurs, dont moi, se sont manifestés pour ne pas faire de cartographie détaillée des réseaux de communication, ne serait-il pas envisageable d'introduire un tag pour préciser le code de ces bâtiments ? Vu qu'on ne peut pas objectivement empêcher leur saisie, autant valoriser notre jeu de données et le rendre interopérable. Je propose ref:FT:42C (ou tout du moins ref:FT, 42C étant le référentiel) pour des codes comme 74010GLI : http://www.ariase.com/fr/haut-debit/haute-savoie/gli74-74010gli.html Des avis ? *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
Quelle la licence des données du site que tu cites ? Si incompatible avec OSM, j'imagine qu'on ne peut saisir que des centraux téléphoniques constatés de visu... Et quel code faut-il utiliser (code FT ou code court) ? Code FT, je suppose ? Francescu Le 20 novembre 2013 10:49, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Bonjour, En regardant d'un peu plus près le bâti dans certaines villes, de nombreux centraux téléphoniques France Telecom commencent à apparaître dans différentes villes. Même si des contributeurs, dont moi, se sont manifestés pour ne pas faire de cartographie détaillée des réseaux de communication, ne serait-il pas envisageable d'introduire un tag pour préciser le code de ces bâtiments ? Vu qu'on ne peut pas objectivement empêcher leur saisie, autant valoriser notre jeu de données et le rendre interopérable. Je propose ref:FT:42C (ou tout du moins ref:FT, 42C étant le référentiel) pour des codes comme 74010GLI : http://www.ariase.com/fr/haut-debit/haute-savoie/gli74-74010gli.html Des avis ? *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil pour ajout de name:fr ?
Am 20.11.2013 03:01, schrieb Philippe Verdy: Je ne suis ps d'accord sur le fait qu'on puisse déduire une information linguistique d'une donnée géographique. Donc chercher une langue applicable à partir d'un polygone est à la base une très mauvaise idée. On n'a même pas besoin de faire cette coûteuse recherche quand les données linguistiques sont déjà toutes dans un seul objet: Cette recherche ne coûte pas tant que ça, ça demande juste un peu de matière grise. Accéder aux tags de l'admin_centre pour faire le rendu de la limite administrative est probablement plus coûteux, pourtant personne propose de copier les tags de l'admin_centre sur la relation boundary. Par exemple si on ne trouve pas name:br=*, on cherche name:fr=*, puis name:en=*, puis name=*. Et sinon seulement dans ce cas-là, on va chercher une liste de langues par défaut pour une zone géographique contenant l'objet et voir si il y en une autre que celles déjà testées pour les name:xx précédents. La seule présence d'un champ name=* coupera court à TOUTES les recherches géographiques. J'ai déjà cité un cas où ce n'est pas si simple que ça: nominatim. Pour pouvoir afficher les noms français dans le résultat d'une recherche, ce logiciel doit tenir compte de la localisation. Sinon, avec fr, en comme langues préférees du navigateur, il afficherait le nom anglais pour les lieux en France qui ont un name:en mais pas de name:fr. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Bonjour Je pose une question toute simple j'ai pas lu tous les courriels de ce fil de discussion : - Faut-il (systématiquement|préférablement|particulièrement) ajouter l'étiquette name:fr=* si name=* existe ? Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil pour ajout de name:fr ?
Le 20 novembre 2013 11:30, rainerU ra...@sfr.fr a écrit : J'ai déjà cité un cas où ce n'est pas si simple que ça: nominatim. Pour pouvoir afficher les noms français dans le résultat d'une recherche, ce logiciel doit tenir compte de la localisation. Sinon, avec fr, en comme langues préférees du navigateur, il afficherait le nom anglais pour les lieux en France qui ont un name:en mais pas de name:fr. Justement c'est un bogue de Nominatim qui prend n'importe quelle langue au hasard, la première qu'il trouve s'il ne trouve pas la langue demandée par le client au lieu de prendre le fallback normal. Si un client web avec fr;en=0.5 en langues préférées de son navigateur consulte nominatim, Nominatim doit chercher dans l'ordre name:fr=* puis name:en=* puis name=* et non pas n'importe quel name:xx=* Si un objet n'a pas de nom en français défini, mais qu'il y en a un défini en anglais, c'est tout à fait normal qu'il affiche le nom anglais puisque cela répond effectivement aux préférences linguistiques de l'utilisateur. Mais si au lieu du français ou de l'anglais il affiche du catalan, alors il est en faute, le catalan ne figure pas dans les langues préférées de l'utilisateur. De même si un objet n'a aucun nom en français ou en anglais pour cet utilisateur, Nominatim doit retourner la valeur de name=* (le nom dans une langue indéfinie, même si celui-ci est en chinois ou en arabe) et non pas un nom éventuel qui serait défini en russe ou même en catalan ! Conclusion: jamais besoin de polygone. Je maintiens. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
Et non... un outil SIG n'est pas un outil de dessin et ne fonctionne pas selon le principe où tout est lié comme c'est le cas dans OSM. Les données de chaque couche y sont indépendantes et dans chaque couche tu es en plus limité à un type d'objet: point, polyligne, polygone. C'est très XXème siècle comme approche ;) Une autre approche pourrait être de travailler avec JOSM sans interragir avec les bases de données OSM. Tu y crée tes données (en plus de celles récupérer comme par exemple les lignes de côte), ensuite tu as un fichier XML/OSM ou du GeoJSON que tu peux reprendre directement par exemple avec TileMill (GeoJSON) ou Maperitive pour appliquer une belle feuille de style selon tes besoins et goûts. C'est en tout cas comme ça que je m'y prendrais vu ce que j'ai compris de tes besoins et de ton expérience. Pour les lignes de côte, si tu ne compte par produire une carte à grande échelle, tu peux aussi reprendre celles simplifiées à 300m : http://tile.openstreetmap.org/shoreline_300.tar.bz2 Le 20 novembre 2013 10:45, Maïeul Rouquette mai...@maieul.net a écrit : - Maïeul http://blog.maieul.net http://www.schtroumpfs.maieul.net/ Le 20 nov. 2013 à 10:41, Jean-Marc Liotier j...@liotier.org a écrit : On 20/11/2013 10:21, Maïeul Rouquette wrote: donc par exemple : mes villes seraient une couche, mes traits entre eux une couche, et les côtes la couche primaire ? Voilà - dans l'ordre d'empilement des calques de haut en bas: - Itinéraires des personnages (polylignes) - Villes (points) - Fonds de carte (image générée à partir des traîts de côte d'OSM) Une polyligne ou un point peuvent être chargés d'attributs - si tu es familier des bases de données tu peux considérer chaque objet comme un enregistrement (dans un tableau une ligne - dont les attributs sont les colonnes) En attendant de trouver ou de générer le fonds de carte muet de tes rêves, tu peux toujours commencer avec n'importe quel autre fonds de carte - tes couches Itinéraires et Villes seront indépendantes et tu peux donc changer le fonds de carte ou ajouter n'importe quelle autre couche sans que ça ait le moindre impact dessus. C'est là où j'ai un peu du mal à saisir : si je modifie l'emplacement de mes villes sur la couche ville, cela ne changera pas automatiquement les traits entre ces villes sur la couche itinéraire des personnages ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Non il n'y a aucune obligation si ce sont les mêmes noms. Attention car name=* est parfois multilingue (en Belgique par exemple, il contient bien un nom français mais ce n'est pas le seul, il y a aussi du néerlandais et de l'allemand) alors que name:fr ne l'est pas (il ne contient QUE le nom français) Le 20 novembre 2013 11:27, david.croc...@online.fr a écrit : Bonjour Je pose une question toute simple j'ai pas lu tous les courriels de ce fil de discussion : - Faut-il (systématiquement|préférablement|particulièrement) ajouter l'étiquette name:fr=* si name=* existe ? Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Am 20.11.2013 11:27, schrieb david.croc...@online.fr: Je pose une question toute simple j'ai pas lu tous les courriels de ce fil de discussion : - Faut-il (systématiquement|préférablement|particulièrement) ajouter l'étiquette name:fr=* si name=* existe ? Comme c'est moi qui ai lancé cette discussion, je résume ce que j'ai compris: Non, il ne faut pas le faire car c'est une information redondante. Avec une base de données géographiques on a d'autres moyens pour déterminer la langue de la valeur du tag name. J'ajouterais que aujourd'hui cela demande aux applis et rendus qui en ont besoin de se procurer ailleurs que dans OSM les informations sur la langue supposé du tag name dans un pays où une région. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Outil pour ajout de name:fr ?
Le 20 novembre 2013 11:30, rainerU ra...@sfr.fr a écrit : Cette recherche ne coûte pas tant que ça, ça demande juste un peu de matière grise. Accéder aux tags de l'admin_centre pour faire le rendu de la limite administrative est probablement plus coûteux, pourtant personne propose de copier les tags de l'admin_centre sur la relation boundary. Sur de grand polygones (et on parle de ça, c'est à dire des polygones avec un grand nombre de sommets), les recherches géographiques sont très coûteuses, bien plus qu'une recherche via un index relationnel entre 2 tables (cas de l'admin_centre et de sa relation). Par exemple si on ne trouve pas name:br=*, on cherche name:fr=*, puis name:en=*, puis name=*. Et sinon seulement dans ce cas-là, on va chercher une liste de langues par défaut pour une zone géographique contenant l'objet et voir si il y en une autre que celles déjà testées pour les name:xx précédents. La seule présence d'un champ name=* coupera court à TOUTES les recherches géographiques. J'ai déjà cité un cas où ce n'est pas si simple que ça: nominatim. Pour pouvoir afficher les noms français dans le résultat d'une recherche, ce logiciel doit tenir compte de la localisation. Sinon, avec fr, en comme langues préférees du navigateur, il afficherait le nom anglais pour les lieux en France qui ont un name:en mais pas de name:fr. Nominatim fait cet effort assez facilement, car il est obligé pour son fonctionnement essentiel de déterminer toute la hiérarchie des découpages. C'est tellement coûteux que l'indexation d'une base nominatim prends plusieurs jours... Il ne le fait pas pour la gestion des langues mais fait un peu d'une pierre deux coups, ça lui permet aussi de gérer les langues de cette façon. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Si il n'y a que name=* ça n'apporte pas grand chose Si il y a d'autres names:xx=* ça lève l'ambiguité de la langue de name=* Le 20 novembre 2013 11:27, david.croc...@online.fr a écrit : Bonjour Je pose une question toute simple j'ai pas lu tous les courriels de ce fil de discussion : - Faut-il (systématiquement|préférablement|particulièrement) ajouter l'étiquette name:fr=* si name=* existe ? Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Le 20/11/2013 11:37, Philippe Verdy a écrit : Non il n'y a aucune obligation si ce sont les mêmes noms. Attention car name=* est parfois multilingue (en Belgique par exemple, il contient bien un nom français mais ce n'est pas le seul, il y a aussi du néerlandais et de l'allemand) alors que name:fr ne l'est pas (il ne contient QUE le nom français) D'après Wikipedia, en Belgique, il n'y a que Bruxelles qui soit véritablement bilingue. Sinon c'est trois régions distinctes qui ont chacune leur langue officielle. https://fr.wikipedia.org/wiki/Langues_de_Belgique Donc à part sur Bruxelles, name est la balise principale a utiliser. Sur Bruxelles, dans le cas de double traduction, alors ils semble nécessaire d'utiliser name=fr ET name:nl name contenant alors les 2 traductions. Et lorsque l'on regarde la pratique sur Bruxelles, ben ils semble que ce soit ce qu'ils font déjà... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Le 20 novembre 2013 11:54, rainerU ra...@sfr.fr a écrit : Am 20.11.2013 11:27, schrieb david.croc...@online.fr: Je pose une question toute simple j'ai pas lu tous les courriels de ce fil de discussion : - Faut-il (systématiquement|préférablement|particulièrement) ajouter l'étiquette name:fr=* si name=* existe ? Comme c'est moi qui ai lancé cette discussion, je résume ce que j'ai compris: Non, il ne faut pas le faire car c'est une information redondante. Avec une base de données géographiques on a d'autres moyens pour déterminer la langue de la valeur du tag name. Encore une fois non ! la base géographique n'a rien à faire pour répondre à la question. Si un client demande du français il faut chercher name:fr; sinon si le client précise d'autres langues de fallback dans ses préférences, il faut chercher celles-là dans l'ordre indiqué par lui. Si on ne trouve toujours rien à ce meoment là seulement on peut fournir un fallback raisonnable: - le client ayant demandé du français, le fallback raisonnable du français est l'anglais, pas l'allemand, on peut chercher l'anglais - si le client avait mis en premier le breton, puis l'anglais en second, Nominatim aurait affiché en premier le breton puis l'anglais (pouir répondre aux préférences de l'utilisateur en premier), avant d'utiliser ses fallbacks raisonnables : le fallback du breton (première langue demandée par l'utilisateur) étant le français, le français sera la troisième langue cherchée, APRES l'anglais. - le name=* n'est que le DERNIER fallback par défaut, si on n'a pas trouvé parmi les langues demandées par l'utilisateurs, ni parmi les fallbacks de ces langues utilisateur ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
On 20/11/2013 10:49, François Lacombe wrote: Même si des contributeurs, dont moi, se sont manifestés pour ne pas faire de cartographie détaillée des réseaux de communication, ne serait-il pas envisageable d'introduire un tag pour préciser le code de ces bâtiments ? Pour le type, telecom=central_office me semble s'imposer: http://taginfo.openstreetmap.fr/tags/telecom=central_office#overview Pour donner une idée de l'ampleur du chantier, vu de mon bureau il y a 5003 NRA et URA (YMMV)... Mais leur position est loin d'être une donnée publique: certes une grande partie d'entre eux sont des centraux téléphoniques de notoriété publique (voire avec 'Central Téléphonique' en relief sur le fronton) mais d'autres peuvent être un local au troisième sous-sol d'un immeuble résidentiel. Dans le cadre de sa mission de cartographie du visible, Openstreetmap ne pourra donc jamais les référencer exhaustivement. Je crois que la cible pertinente pour Openstreetmap est donc de qualifier la fonction de bâtiments ou du sites visibles - la topologie des réseaux de télécommunication me semble être hors du scope. Lorsque les amateurs en auront terminé avec les centraux visibles, ils peuvent s'attaquer aux chambres... Je propose ref:FT:42C (ou tout du moins ref:FT, 42C étant le référentiel) pour des codes comme 74010GLI Ca me va bien. Néanmoins, dans les opérations courantes, on a l'habitude d'utiliser le code court - GLI74. Quel est l'intérêt du code long ? Dans tous les flux de production DSL (Club Internet et Neufcegetel) sur lesquels j'ai eu l'occasion de travailler, je ne l'ai quasiment jamais rencontré. Ceci dit on a déjà une poignée de ref:NRA:code avec le nom long: http://taginfo.openstreetmap.fr/keys/ref%3ANRA%3Acode#values - mais en nombre tellement faible qu'on peut considérer que le projet est une page blanche. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle source de données sur DataGouv
Salut à tous, Je viens de regarder rapidement le fichier des guichets publics. C'est vrai que ça a l'air pas mal, mais attention il y a quelques grosses erreurs dans les coordonnées géographiques. A Montpellier par exemple tous les centres pôle emploi sont positionnés au même point et ça correspond à la place de la comédie en plein centre ville ! Comme toujours, à prendre avec des pincettes et à vérifier avant import... :-) Nicolas (M) - Nicolas Moyroud Site web libre@vous : http://libreavous.teledetection.fr - Le 19/11/2013 16:01, Nicolas Dumoulin a écrit : Première étape : regarder ce qu'il y a dedans. Premier fichier, les cinémas : on a juste les cinémas par commune, sans adresses. Deuxième fichier, les organismes : on a les adresses et les coordonnées géographiques (avec un champ précision). J'ai pris un organisme au hasard, il est très bien positionné. Donc c'est potentiellement très intéressant :-) yapluka ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
On 20/11/2013 11:36, Christian Quest wrote: Le 20 nov. 2013 à 10:41, Jean-Marc Liotier j...@liotier.org mailto:j...@liotier.org a écrit : On 20/11/2013 10:21, Maïeul Rouquette wrote: donc par exemple : mes villes seraient une couche, mes traits entre eux une couche, et les côtes la couche primaire ? Voilà - dans l'ordre d'empilement des calques de haut en bas: - Itinéraires des personnages (polylignes) - Villes (points) - Fonds de carte (image générée à partir des traîts de côte d'OSM) Une polyligne ou un point peuvent être chargés d'attributs - si tu es familier des bases de données tu peux considérer chaque objet comme un enregistrement (dans un tableau une ligne - dont les attributs sont les colonnes) En attendant de trouver ou de générer le fonds de carte muet de tes rêves, tu peux toujours commencer avec n'importe quel autre fonds de carte - tes couches Itinéraires et Villes seront indépendantes et tu peux donc changer le fonds de carte ou ajouter n'importe quelle autre couche sans que ça ait le moindre impact dessus. C'est là où j'ai un peu du mal à saisir : si je modifie l'emplacement de mes villes sur la couche ville, cela ne changera pas automatiquement les traits entre ces villes sur la couche itinéraire des personnages ? Et non... un outil SIG n'est pas un outil de dessin et ne fonctionne pas selon le principe où tout est lié comme c'est le cas dans OSM. Les données de chaque couche y sont indépendantes et dans chaque couche tu es en plus limité à un type d'objet: point, polyligne, polygone. Ceci dit il existe des outils permettant la gestion des relations topologiques entre des objets de couches différentes - j'en ai un monstrueux exemple ouvert sur mon bureau, une extension ArcGIS dédiée à la gestion d'un réseau optique. Mais il s'agit de logique applicative intervenant au-dessus du SIG. Dans ton cas, où tu souhaites préserver la simplicité de ton outillage, tu devras de priver de ce luxe. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Pour éviter de refaire la même discussion avec juste un titre différent, je vais seulement ajouter ce petit lien vers une page intéressante du wiki (eh oui, il y en a): http://wiki.openstreetmap.org/wiki/Multilingual_names On voit que certains pays mettent plusieurs langues dans le tag name (les japonais par exemple). Mais je n'ai pas trouvé de pays qui recommande de dupliquer le tag name dans le suffixe local. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Récuperer fond de carte Openstreet map et compléter avec ses données
Désolé pour le formatage affreux - la commande 'rewrap' de Thunderbird semble avoir quelques difficultés... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
Le 20/11/2013 10:49, François Lacombe a écrit : Bonjour, En regardant d'un peu plus près le bâti dans certaines villes, de nombreux centraux téléphoniques France Telecom commencent à apparaître dans différentes villes. Même si des contributeurs, dont moi, se sont manifestés pour ne pas faire de cartographie détaillée des réseaux de communication, ne serait-il pas envisageable d'introduire un tag pour préciser le code de ces bâtiments ? Dans l'absolu, je ne vois pas trop de différence entre les centraux téléphoniques et les antennes de télécommunications. Pourtant ces dernières sont cartographié publiquement par l'ANFR sur le site http://www.cartoradio.fr Peut être est-ce du au fait qu'il est plus facile de remettre une antenne en service que de réparer des milliers de paires de cuivre qui auraient été vandalisés Vu qu'on ne peut pas objectivement empêcher leur saisie, autant valoriser notre jeu de données et le rendre interopérable. Je propose ref:FT:42C (ou tout du moins ref:FT, 42C étant le référentiel) pour des codes comme 74010GLI : http://www.ariase.com/fr/haut-debit/haute-savoie/gli74-74010gli.html Des avis ? Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Am 20.11.2013 11:53, schrieb Philippe Verdy: Si un client demande du français il faut chercher name:fr; sinon si le client précise d'autres langues de fallback dans ses préférences, il faut chercher celles-là dans l'ordre indiqué par lui. Ça fonctionne si on met systematiquement name:fr quand il y a au moins un name:xx. Donc je mets name:fr sur les quelques 1800 rues de Perpignan qui on un name:ca. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Le 20 novembre 2013 11:51, Christophe Merlet red...@redfoxcenter.org a écrit : Le 20/11/2013 11:37, Philippe Verdy a écrit : Non il n'y a aucune obligation si ce sont les mêmes noms. Attention car name=* est parfois multilingue (en Belgique par exemple, il contient bien un nom français mais ce n'est pas le seul, il y a aussi du néerlandais et de l'allemand) alors que name:fr ne l'est pas (il ne contient QUE le nom français) D'après Wikipedia, en Belgique, il n'y a que Bruxelles qui soit véritablement bilingue. Le pays lui-même est trilingue (néerlandais-français-allemand). La région wallonne est bilingue (français-allemand), de même que la province et l'arrondissement où se situe la région germanophone. Certaines autres communes sont aussi bilingues officiellement (et pas seulement avec une facilité linguistique donnant une langue principale et une langue secondaire). On a le même cas en Espagne, Suisse, Italie, Ecosse,... en fait dans la plupart des pays. Seule la France refuse de donner l'égalité linguistique aux autres langues (la Constitution impose que le français soit la seule langue principale ayant un caractère obligatoire), mais aussi un support minimum en tant que langue seconde (comme en Belgique ou les autres pays); la France ne reconnait pas les autres langues au niveau de l'Etat mais accepte seulement cela de la part de ses collectivités locales (mais uniquement en tant que seconde langue, non co-officielle, mais pouvant bénéficier d'un programme de soutien sans pouvoir imposer le support minimum de ces langues secondes). C'est pour ça que la France refuse depuis des décennies de signer la convention européenne des langues régionales et minoritaires, qui pourtant ne contredirait pas la Constitution : cette convention n'impose pas l'égalité de traitement linguistique, mais en revanche elle milite pour le multilinguisme (que la France est sensée défendre dans la Francophonie qu'elle a elle-même créée !!!) et la promotion de l'enseignement des langues régionales et étrangères. Là encore un vœux pieux de la France qu'elle refuse d'appliquer elle-même : comment voulez-vous que la France défende le français au plan international dans le cadre du multilinguisme, alors qu'elle refuse obstinément de le faire chez elle ? Résultat, la France est parmi les derniers dans les classements de connaissance des langues étrangères (il y a aussi d'autres raisons que celle-là, notamment la pauvreté vocalique et d'intonation du français qui rend difficile plus tard l'apprentissage d'autres langues auxquelles l'oreille française n'a pas été habituée très jeune, mais c'en est une bonne) et perd des parts de marché dans ses universités, ou dans le monde touristique à cause de son accueil déplorable des locuteurs parlant d'autres langues, ou dans les affaires et les publications scientifiques (L'Allemagne en comparaison a un fort support de l'allemand, même au plan international et scientifique : elle arrive à placer ses publications car elle accepte et soutient les traductions sans exclure l'allemand comme langue principale) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Le 20 novembre 2013 12:22, rainerU ra...@sfr.fr a écrit : Am 20.11.2013 11:53, schrieb Philippe Verdy: Si un client demande du français il faut chercher name:fr; sinon si le client précise d'autres langues de fallback dans ses préférences, il faut chercher celles-là dans l'ordre indiqué par lui. Ça fonctionne si on met systematiquement name:fr quand il y a au moins un name:xx. Donc je mets name:fr sur les quelques 1800 rues de Perpignan qui on un name:ca. Oui mais seulement si ces noms catalans de Perpignan sont aussi les noms français. Mais pas du tout besoin si les noms français sont les noms par défaut dans name=* puisqu'ils seront toujours trouvés APRES les langues demandées par l'utilisateur (si un utilisateur russe consulte nominatim, il voudra voir le nom russe dans name:ru avant de voir name=* qui est en français; si l'utilisateur russe a demandé dans l'ordre le russe et l'anglais (requête web avec ru;en=0.5) , il verra le name:ru=*, sinon le name:en=*, sinon en DERNIER le name=* (en français ou autre, peut importe la langue qui n'est pas précisée), mais jamais le catalan (dans name:ca=*) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
Le 20 novembre 2013 12:12, Christophe Merlet red...@redfoxcenter.org a écrit : Le 20/11/2013 10:49, François Lacombe a écrit : Bonjour, En regardant d'un peu plus près le bâti dans certaines villes, de nombreux centraux téléphoniques France Telecom commencent à apparaître dans différentes villes. Même si des contributeurs, dont moi, se sont manifestés pour ne pas faire de cartographie détaillée des réseaux de communication, ne serait-il pas envisageable d'introduire un tag pour préciser le code de ces bâtiments ? Dans l'absolu, je ne vois pas trop de différence entre les centraux téléphoniques et les antennes de télécommunications. Pourtant ces dernières sont cartographié publiquement par l'ANFR sur le site http://www.cartoradio.fr Les NRA sont-ils tous chez France Telecom ? Pas sûr du tout au plan local maintenant que d'autres réseaux optiques permettent de les raccorder. Et que dire alors des NRO ? une partie seulement chez FT, les autres sont plus souvent chez Numericable dans de nombreuses villes (où FT les a cédé à une époque où FT perdait de l'argent sur les réseaux câblés optiques, et FT s'en mord les doigts aujourd'hui car il doit reconstruire, cependant il peut utiliser des fibres plus modernes que celles monomode posées à l'époque et reprises telles quelles par NC, des fibres qui ne permettent pas la mutualisation des opérateurs ; de fait NC est en monopole dans les villes où il est présent, c'est à dire toutes celles équipées depuis les années 1980 par FT qui les a cédé à NC, et aucun autre opérateur ne veut se lancer à poser d'autres fibres dans ces villes où la concurrence s'imposera sur leur nouvelle infrastructure, alors que NC n'a pas d'obligation de le faire sur son équipement existant en FTTB, voire en FTTH comme à Rennes ou Pau depuis plusieurs décennies !) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Am 20.11.2013 12:24, schrieb Philippe Verdy: Le 20 novembre 2013 12:22, rainerU ra...@sfr.fr mailto:ra...@sfr.fr a écrit : Ça fonctionne si on met systematiquement name:fr quand il y a au moins un name:xx. Donc je mets name:fr sur les quelques 1800 rues de Perpignan qui on un name:ca. Oui mais seulement si ces noms catalans de Perpignan sont aussi les noms français. Cela donne: name=Perpignan name:ca=Perpinyà pas de name:fr Je mets dans les préférence de mon navigateur fr, ca, ce qui correspond à français si disponible, sinon catalan, sinon défaut. Un logiciel qui applique ton algorithme m'affichera Perpinyà. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
2013/11/20 rainerU ra...@sfr.fr: Je mets dans les préférence de mon navigateur fr, ca, ce qui correspond à français si disponible, sinon catalan, sinon défaut. Un logiciel qui applique ton algorithme m'affichera Perpinyà. Oui, mais en même temps, est-ce vraiment gênant ? A partir du moment où tu mets plusieurs langues dans ton navigateur, tu acceptes plus ou moins les deux versions. Si le catalan te gênes à ce point, tu peux aussi virer le ca dans tes préférences. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Le 20 novembre 2013 12:50, rainerU ra...@sfr.fr a écrit : Am 20.11.2013 12:24, schrieb Philippe Verdy: Le 20 novembre 2013 12:22, rainerU ra...@sfr.fr mailto:ra...@sfr.fr a écrit : Ça fonctionne si on met systematiquement name:fr quand il y a au moins un name:xx. Donc je mets name:fr sur les quelques 1800 rues de Perpignan qui on un name:ca. Oui mais seulement si ces noms catalans de Perpignan sont aussi les noms français. Cela donne: name=Perpignan name:ca=Perpinyà pas de name:fr Je mets dans les préférence de mon navigateur fr, ca, ce qui correspond à français si disponible, sinon catalan, sinon défaut. Un logiciel qui applique ton algorithme m'affichera Perpinyà. oui... Cependant on pourrait raffiner en précisant la langue de name:Perpignan sans créer de redondance: Il suffirait d'ajouter name:lang=fr (ou plusieurs langues séparées par un point-virgule si ce nom par défaut est multilingue comme name=Bruxelles - Brussels qui aurait name:lang=fr;nl). Ainsi Nominatim pourrait savoir que le nom français demandé en premier par l'utilisateur est bien celui indiqué par défaut Perpignan, avant d'aller afficher le nom catalan demandé en second. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Le 20 novembre 2013 12:49, Pieren pier...@gmail.com a écrit : 2013/11/20 rainerU ra...@sfr.fr: Oui, mais en même temps, est-ce vraiment gênant ? A partir du moment où tu mets plusieurs langues dans ton navigateur, tu acceptes plus ou moins les deux versions. Si le catalan te gênes à ce point, tu peux aussi virer le ca dans tes préférences. Je suis partiellement d'accord, sauf que les langues des préférences utilisateur ont quand même une priorité dont on doit tenir compte. Demander à l'utilisateur de virer une langue préférée c'est exagéré ! Effectivement name=* ne précise pas quelle est (quelles sont) les langues utilisées pour ce nom par défaut (c'est indéterminé) je ne suis pas contre le fait d'ajouter name:lang=fr pour préciser quelle est la langue (quelles sont les langues) de ce nom par défaut. Au moins ça évite la redondance des noms identiques au nom par défaut. Même si de ce point de vue on pourrait avoir un tag lang=fr dans la relation applies pointant sur la France (mais là c'est assez coûteux en requête) pour éviter d'ajouter dans plein d'objets des name:lang=fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Am 20.11.2013 12:49, schrieb Pieren: 2013/11/20 rainerU ra...@sfr.fr: Oui, mais en même temps, est-ce vraiment gênant ? A partir du moment où tu mets plusieurs langues dans ton navigateur, tu acceptes plus ou moins les deux versions. Si le catalan te gênes à ce point, tu peux aussi virer le ca dans tes préférences. Prenons un cas plus fréquent, je mets fr, en et name=Québec name:en=Quebec pas de name:fr L'algorithme de Philippe me sort Quebec. Ce qui n'est pas un argument en faveur du name:fr car nominatim affiche bien Québec dans ce cas. Il y a un bug qui fait qu'il sort Quebec quand on met fr-fr, en. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Quand on demande fr-fr;en=0.5, on demande en fait dans l'ordre : fr-fr, puis fr, puis en. (Consulter le standard BCP47 pour l'algo, c'est à dire la RFC qui décrit la méthode de résolution des langues, le standard BCP47 étant référencé par la norme HTTP des requêtes web) Comme la base n'a pas de name:fr-fr=*, on trouvera tout de même name:fr=* qui répond correctement à une requête web pour fr-fr Le 20 novembre 2013 13:20, rainerU ra...@sfr.fr a écrit : Am 20.11.2013 12:49, schrieb Pieren: 2013/11/20 rainerU ra...@sfr.fr: Oui, mais en même temps, est-ce vraiment gênant ? A partir du moment où tu mets plusieurs langues dans ton navigateur, tu acceptes plus ou moins les deux versions. Si le catalan te gênes à ce point, tu peux aussi virer le ca dans tes préférences. Prenons un cas plus fréquent, je mets fr, en et name=Québec name:en=Quebec pas de name:fr L'algorithme de Philippe me sort Quebec. Ce qui n'est pas un argument en faveur du name:fr car nominatim affiche bien Québec dans ce cas. Il y a un bug qui fait qu'il sort Quebec quand on met fr-fr, en. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] valeurs multiples
Bonjour Je reçois une erreur osmose 185 3070 0 2 3070 valeurs multiples E 1.38 43.66 r 3020075 (j) Valeurs multiples landuse=residential;commercial J'ai créé ce "landuse" http://www.openstreetmap.org/browse/relation/3020075 avec plusieurs valeurs : - car j'ai vu dans des discutions que le ";" permettait d'indiquer plusieurs valeurs - dans taginfo il y a 1 411 industrial;retail - je trouve que cela correspond bien à la mixité décrite dans la plaquette de la ville - "Toutes les fonctions de la ville sont présentes sur le quartier (commerces, tertiaires, habitat, loisirs) Andromède répond à la gamme de demandes la plus large possible en matière de logement et permet d’accueillir tous les types de population : individuel (25%), collectifs (75%), du T2 au T6, logements privés, en accession, locatif social ou privé coexistent dans un même îlot." En ce qui concerne les commerces : je n'ai pas ajouté "retail" dans le landuse, je pensais ajouter la supérette (future) sur le building et des points shop pour les commerces en pied d'immeuble. J'aurais donc tendance à considérer cette erreur comme un faux-positif ; mais je voulais savoir avant s'il y avait une raison pour signaler les valeurs multiples ! Merci d'avance Lenny ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
Bonjour, Quelques précisions ci-après. Je n'ai toujours pas trouvé de référence légale empêchant l'inventaire de ces installation *de manière citoyenne* (i.e. principalement du relevé terrain ou se basant sur des informations largement publiques). Le 20 novembre 2013 11:06, Francescu GAROBY windu...@gmail.com a écrit : Quelle la licence des données du site que tu cites ? Si incompatible avec OSM, j'imagine qu'on ne peut saisir que des centraux téléphoniques constatés de visu... Le site ne fait que s'appuyer sur une liste publiée par Orange. www.orange.com/fr/content/download/3259/28413/version/9/file/PODIoctobre2013.pdf Le fait est que les bâtiments sont repérés sur le terrains. Leur attribuer un code de cette liste par association géographique implicite consiste-t-il en sa recopie ? La réponse n'est pas facile. Le 20 novembre 2013 12:00, Jean-Marc Liotier j...@liotier.org a écrit : Pour le type, telecom=central_office me semble s'imposer: http://taginfo.openstreetmap.fr/tags/telecom=central_office#overview Ok. De toute façons la question n'est pas de raffiner le modèle. Pour donner une idée de l'ampleur du chantier, vu de mon bureau il y a 5003 NRA et URA (YMMV)... Mais leur position est loin d'être une donnée publique: certes une grande partie d'entre eux sont des centraux téléphoniques de notoriété publique (voire avec 'Central Téléphonique' en relief sur le fronton) mais d'autres peuvent être un local au troisième sous-sol d'un immeuble résidentiel. Dans le cadre de sa mission de cartographie du visible, Openstreetmap ne pourra donc jamais les référencer exhaustivement. Il y a ~13500 NRA actuellement (local contenant un répartiteur pour brasser des lignes boucle locale). C'est ce qu'il faudrait référencer avec telecom=central_office Pour la commutation c'est autre chose, mais on ne s’intéresse pas à ce niveau de détails, on est d'accord. Effectivement ils ne seront pas tous sur OSM. En France, l'opérateur d'infrastructure étant Orange, il convient de les tagguer avec operator=Orange (FT n'existe plus depuis juin 2013, à OSM de voir si il préfère FT ou Orange comme valeur). Ceci même si le propriétaire (owner=*) peut varier (les NRA-ZO, NRA-MeD appartiennent à ceux qui les ont financé : les collectivités. Les NRA-HD ont été financés par FT à l'époque). Lorsque les amateurs en auront terminé avec les centraux visibles, ils peuvent s'attaquer aux chambres... Pourquoi pas :) Ca promet. Ca me va bien. Néanmoins, dans les opérations courantes, on a l'habitude d'utiliser le code court - GLI74. Quel est l'intérêt du code long ? Dans tous les flux de production DSL (Club Internet et Neufcegetel) sur lesquels j'ai eu l'occasion de travailler, je ne l'ai quasiment jamais rencontré. Il y a des doublons sur les codes courts. Le code long garanti l'unicité avec le code INSEE de la commune. Concernant ref:FT:42C, mettre le nom du référentiel (42C a bien été établit par FT/PTT et pas par Orange qui n'existait pas à l'époque) dans le nom permet de distinguer plusieurs références qui se rapportent à la même chose. J'essayerai de documenter le tag dans la soirée, à l'image de ce que j'avais fait pour http://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo Bonne après-midi. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Le 20 nov. 2013 à 12:24, Philippe Verdy verd...@wanadoo.fr a écrit : Ça fonctionne si on met systematiquement name:fr quand il y a au moins un name:xx. Donc je mets name:fr sur les quelques 1800 rues de Perpignan qui on un name:ca. Oui mais seulement si ces noms catalans de Perpignan sont aussi les noms français. Tu voulais dire les noms officiels? Un nom catalan ne peut pas être un nom français. A RainerU, Il ne faut pas corriger les name:br ou autres, s'ils ne comportent pas des signes diacritiques ou des lettres spécifiques à la langue d'origine. Tu as raison pour Strassbüri (on aurait Strasburi), mais, c'est seulement que l'information n'est pas parvenue en Bretagne. Comme je l'ai dit, on est dans le régime de la coutume et non pas de la reproduction stricte des conventions orthographiques. Il s'agit, parfois d'une imitation phonétique, parfois d'une transcription orthographique et, parfois les deux dans le même item. Ainsi, Galway a pour name:br Gailiv, qui est la transcription de Gailimh (irlandais). Certains posent, à juste titre, la question du tri des toponymes par les logiciels, mais, il y a aussi le tri humain. Alimenter la BDD en nam:xx permet de savoir quelles sont sont les formes des toponymes admis dans l'usage écrit concerné. Ils ne peuvent pas être décalqués de l'usage local. L'usage a deux niveaux : l'oral et l'écrit qui peuvent avoir leur propre vie. Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
En gros ce que je propose c'est, pour éviter les redondances de noms, d'ajouter name:lang=fr. On pourrait aussi ajouter name:ca:lang=oc pour préciser que la valeur de name:ca=* est aussi utilisable en occitan sans créer un name:oc=* de même valeur que name:ca=*. Prenons par exemple - un utilisateur qui demande fr-fr;de;oc (j'omet les valeur comme =0.5 ajoutée après chaque code dans la requête HTTP pour les ordonner explicitement) - La base contient: name=Perpignan name:lang=fr;wa name=Perpignan name:ca=Perpinya name:ca:lang=oc (pas la peine de mentionner =ca;oc car ca est déjà inclus en tête de liste du fait du nom du tag) L'algo est le suivant: - regarder s'il y a un name:xx correspondant à chacune des langues dans l'ordre donné par l'utilisateur, donc name:fr-fr=* (non trouvé), name:fr=* (non trouvé), name:en=* (trouvé ! on s'arrête là) On voit que le nom anglais est pris avant le nom français par défaut. C'est normal le nom anglais est redondant (on aurait du mettre name:lang=fr:wa;en mais on peut éviter ça). Il faut raffiner : * regarder d'abord si on a name:lang=* c'est le cas ici on trouve fr;wa dedans, cela a pour effet de transformer name=Perpignan comme si c'était name:fr=Perpignan + name:wa=Perpignan * on fait la recherche comme précédemment, donc on recherchera dans l'ordre correspondant à la requête: - pour fr-fr, regarder name:fr-fr=*, sinon si fr-fr est présent dans name:lang=* (si oui prendre la valeur de name=*) - pour de, regarder name:de=*, sinon si de est présent dans name:lang=* (si oui prendre la valeur de name=*) - pour oc, regarder name:oc=*, sinon si oc est présent dans name:lang=* (si oui prendre la valeur de name=*) * Ensuite viennent les fallbacks raisonnables de l'utilisateur : fr-fr a un fallback imposé par le standard fr, et un autre raisonnable en; de n'a que en comme raisonnable, oc pourrait avoir fr, es, it, en comme raisonnables. la liste est donc fr, en, es, it : - pour fr, regarder name:fr=*, sinon si fr-fr est présent dans name:lang=* (si oui prendre la valeur de name=*) - pour en, regarder name:en=*, sinon si en est présent dans name:lang=* (si oui prendre la valeur de name=*) - pour es, regarder name:es=*, sinon si es est présent dans name:lang=* (si oui prendre la valeur de name=*) - pour it, regarder name:it=*, sinon si it est présent dans name:lang=* (si oui prendre la valeur de name=*) * Ensuite viennent les fallbacks des données elles-mêmes, à traiter en commençant par les langues de l'utilisateur: - pour fr-fr, regarder name:fr-fr:lang=* et voir si il contient une des langues de l'utilisateur (fr-fr; de; oc) si c'est le cas prendre la valeur de name:fr-fr=* - pour de, regarder name:de:lang=* et voir si il contient une des langues de l'utilisateur (fr-fr; de; oc) si c'est le cas prendre la valeur de name:de=* - pour oc, regarder name:oc:lang=* et voir si il contient une des langues de l'utilisateur (fr-fr; de; oc) si c'est le cas prendre la valeur de name:oc=* * Puis les langues de fallbacks des données imposés des langues de l'utilisateur: vous comprenez le principe. on va aboutir finalement à détecter name:ca:lang=oc avant même d'avoir trouvé le nom par défaut (mentionnant fr, et non précisément fr-fr), et donc aboutir à utiliser la valeur trouvée dans name:ca=* (donc le nom en catalan). Mais si l'utilisateur a demandé non pas fr-fr;de;oc mais fr;de;oc, il obtiendra bien le nom par défaut (mentionnant fr), donc le nom en français (français générique même si c'est le français canadien) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
On 20/11/2013 13:31, François Lacombe wrote: Je n'ai toujours pas trouvé de référence légale empêchant l'inventaire de ces installation *de manière citoyenne* (i.e. principalement du relevé terrain ou se basant sur des informations largement publiques). C'est aussi mon opinion. Le 20 novembre 2013 11:06, Francescu GAROBY windu...@gmail.com mailto:windu...@gmail.com a écrit : Quelle la licence des données du site que tu cites ? Si incompatible avec OSM, j'imagine qu'on ne peut saisir que des centraux téléphoniques constatés de visu... Le site ne fait que s'appuyer sur une liste publiée par Orange. www.orange.com/fr/content/download/3259/28413/version/9/file/PODIoctobre2013.pdf http://www.orange.com/fr/content/download/3259/28413/version/9/file/PODIoctobre2013.pdf Le fait est que les bâtiments sont repérés sur le terrains. Leur attribuer un code de cette liste par association géographique implicite consiste-t-il en sa recopie ? La réponse n'est pas facile. Le code de l'URA/NRA est l'identifiant unique qu'on retrouve dans les innombrables bavardages inter-opérateurs et chez tous les acteurs de près où de loin liés à la construction et à la maintenance de la boucle locale... Il me semble légitime de l'utiliser hors de FT vu que c'est déjà une pratique courante. Pour donner une idée de l'ampleur du chantier, vu de mon bureau il y a 5003 NRA et URA Il y a ~13500 NRA actuellement Grosse erreur de ma part: je n'ai sélectionné que les sites référencés chez moi - comme ton total le montre, il y a plein de sites FT où aucun opérateur tiers n'est présent... En France, l'opérateur d'infrastructure étant Orange, il convient de les tagguer avec operator=Orange (FT n'existe plus depuis juin 2013, à OSM de voir si il préfère FT ou Orange comme valeur) Les dinosaures dans mon genre passeront le reste de leur vie à continuer à dire 'FT' - mais que ça n'empêche pas d'utiliser le nom actuel... Il y a des doublons sur les codes courts. Moche. Comme quoi on en apprend tous les jours... Je connais un certain nombre de vieilles applications qui ont probablement silencieusement produit un paquet de résultats erronés. Le code long garanti l'unicité avec le code INSEE de la commune. Bon - va pour le nom long ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] valeurs multiples
2013/11/20 lenny lenny.li...@orange.fr J'aurais donc tendance à considérer cette erreur comme un faux-positif ; mais je voulais savoir avant s'il y avait une raison pour signaler les valeurs multiples ! Quelqu'un a posé la question des valeurs multiples il y a quelques mois sur la liste principale pour savoir si c'était finalement vraiment exploité ([1]). Celui qui a démarré la discussion en a fait un billet ([2]). J'adhère à sa conclusion qui est de dire qu'il n'y a aucune exploitation généralisée des valeurs multiples et que ça n'est vraiment utile que dans de rares cas. Il faudrait donc en général essayer de les éviter. Pour revenir à ton landuse, il faut aussi être un peu flexible et prendre la valeur comme l'usage principal mais pas exclusif d'une zone. Le wiki dit bien ([3]) : describe the primary use of land. On peut admettre qu'un landuse=residential contienne des petits commerces ou bureaux et qu'un landuse=retail contienne quelques maisons d'habitation. S'il n'y a pas de valeur prédominante, on peut affiner les landuse en plus petits morceaux ou créer un nouveau tag pour les zones mixtes (ou voir du côté de taginfo si quelque chose n'existe pas déjà) Pieren [1] https://lists.openstreetmap.org/pipermail/talk/2013-May/067229.html [2] http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html [3] http://wiki.openstreetmap.org/wiki/Key:landuse ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Un autre cas tordu sur lequel je suis tombé (en Allemagne) : les name:prefix=* et name:suffix=* En théorie ils sont liés directement à name=* (donc le nom par défaut). Pourtant si le nom par défaut (en allemand) est identique en français (par exemple Berlin), le préfixe associé lui ne l'est pas (Bundeland); la/les langue(s) par défaut ne sont pas nécessairement les mêmes entre les name=* et les name:prefix=* ou name:suffix=*. On devrait alors préciser ces langues des préfixes et suffixes par défaut ; mais comme ces préfixes et suffixes sont optionnels, il vaut mieux ne pas les indiquer dans la langue par défaut mais uniquement dans la langue qui les utilise, donc name:prefix:de=* ou name:suffix:de=*. Sinon il faudra name:prefix:lang=de ou name:suffix:lang=de, si jamais on a renseigne name:prefix=* ou name:suffix=* Ma proposition avec le suffixe :lang permettrait d'éviter des redondances pour certains toponymes qui ont parfois des centaines de traductions dont plein de copies identiques soit au nom par défaut, soit entre les autres traduction (français=anglais=allemand=italien=espagnol=etc., russe=bulgare=serbe=macédonien=etc., chinois=japonais, arabe=ourdou=etc.) L'ennui c'est que Nominatim n'est pas préparé à gérer ça, et que ça demande des discussions : doit-on éliminer ces redondances de noms identiques en utilisant ce schéma? On a pourtant besoin d'avoir des noms par défaut (même s'ils sont dans des langues précises qui ne sont pas celles demandées par l'utilisateur) parce qu'on ne pourra pas afficher autre chose faute de traduction enregistrée. Le 20 novembre 2013 13:39, Christian Rogel christian.ro...@club-internet.fr a écrit : Le 20 nov. 2013 à 12:24, Philippe Verdy verd...@wanadoo.fr a écrit : Ça fonctionne si on met systematiquement name:fr quand il y a au moins un name:xx. Donc je mets name:fr sur les quelques 1800 rues de Perpignan qui on un name:ca. Oui mais seulement si ces noms catalans de Perpignan sont aussi les noms français. Tu voulais dire les noms officiels? Un nom catalan ne peut pas être un nom français. A RainerU, Il ne faut pas corriger les name:br ou autres, s'ils ne comportent pas des signes diacritiques ou des lettres spécifiques à la langue d'origine. Tu as raison pour Strassbüri (on aurait Strasburi), mais, c'est seulement que l'information n'est pas parvenue en Bretagne. Comme je l'ai dit, on est dans le régime de la coutume et non pas de la reproduction stricte des conventions orthographiques. Il s'agit, parfois d'une imitation phonétique, parfois d'une transcription orthographique et, parfois les deux dans le même item. Ainsi, Galway a pour name:br Gailiv, qui est la transcription de Gailimh (irlandais). Certains posent, à juste titre, la question du tri des toponymes par les logiciels, mais, il y a aussi le tri humain. Alimenter la BDD en nam:xx permet de savoir quelles sont sont les formes des toponymes admis dans l'usage écrit concerné. Ils ne peuvent pas être décalqués de l'usage local. L'usage a deux niveaux : l'oral et l'écrit qui peuvent avoir leur propre vie. Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
2013/11/20 Philippe Verdy verd...@wanadoo.fr: En gros ce que je propose c'est, pour éviter les redondances de noms, d'ajouter name:lang=fr. Bravo Philippe. Tu arrives aux mêmes arguments et conclusions présents dans l'autres fil de discussion avec un jour de retard seulement :-) (ça serait bien que tu lises les messages des autres en entier) Bon, moi, je proposais hier d'ajouter un tag is_in=France par boutade. Mais on pourrait mettre à la place ton name:lang=fr avec un bot sur tous les éléments qui ont un name en France. Ben oui, tant qu'à faire, pourquoi attendre que quelqu'un ajoute un name:xx pour passer à l'action ? Autant anticiper. Ca fera juste quelques millions de tags (pourquoi s'arrêter à la France) redondants dans la base pour que nominatim n'ait pas à faire ce boulot lui-même Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Le 20 novembre 2013 14:23, Philippe Verdy verd...@wanadoo.fr a écrit : Un autre cas tordu sur lequel je suis tombé (en Allemagne) : les name:prefix=* et name:suffix=* En théorie ils sont liés directement à name=* (donc le nom par défaut). Pourtant si le nom par défaut (en allemand) est identique en français (par exemple Berlin), le préfixe associé lui ne l'est pas (Bundeland); la/les langue(s) par défaut ne sont pas nécessairement les mêmes entre les name=* et les name:prefix=* ou name:suffix=*. On devrait alors préciser ces langues des préfixes et suffixes par défaut ; mais comme ces préfixes et suffixes sont optionnels, il vaut mieux ne pas les indiquer dans la langue par défaut mais uniquement dans la langue qui les utilise, donc name:prefix:de=* ou name:suffix:de=*. Sinon il faudra name:prefix:lang=de ou name:suffix:lang=de, si jamais on a renseigne name:prefix=* ou name:suffix=* Ma proposition avec le suffixe :lang permettrait d'éviter des redondances pour certains toponymes qui ont parfois des centaines de traductions dont plein de copies identiques soit au nom par défaut, soit entre les autres traduction (français=anglais=allemand=italien=espagnol=etc., russe=bulgare=serbe=macédonien=etc., chinois=japonais, arabe=ourdou=etc.) L'ennui c'est que Nominatim n'est pas préparé à gérer ça, et que ça demande des discussions : doit-on éliminer ces redondances de noms identiques en utilisant ce schéma? On a pourtant besoin d'avoir des noms par défaut (même s'ils sont dans des langues précises qui ne sont pas celles demandées par l'utilisateur) parce qu'on ne pourra pas afficher autre chose faute de traduction enregistrée. Le 20 novembre 2013 13:39, Christian Rogel christian.ro...@club-internet.fr a écrit : Le 20 nov. 2013 à 12:24, Philippe Verdy verd...@wanadoo.fr a écrit : Ça fonctionne si on met systematiquement name:fr quand il y a au moins un name:xx. Donc je mets name:fr sur les quelques 1800 rues de Perpignan qui on un name:ca. Oui mais seulement si ces noms catalans de Perpignan sont aussi les noms français. Tu voulais dire les noms officiels? Un nom catalan ne peut pas être un nom français. Si ! Un nom catalan (ou corse, breton, occitan, alsacien, tahitien, kanak) peut être le nom officiel français si la collectivité l'a adopté. La francisation forcée des anciens typonymes d'usage n'a plus court depuis que les collectivités sont capables de délibérer elles mêmes (et non le seul législateur national) sur leur propre toponymie. En officialisant ces noms, ils deviennent aussitôt français (même si l'ancien nom français reste en usage, et qu'on pourra le garder dans un alt_name:fr ou un old_name:fr si cet ancien nom français a été officiel dans le passé). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Le 20 novembre 2013 14:38, Pieren pier...@gmail.com a écrit :
2013/11/20 Philippe Verdy verd...@wanadoo.fr:
En gros ce que je propose c'est, pour éviter les redondances de noms,
d'ajouter name:lang=fr.
Bravo Philippe. Tu arrives aux mêmes arguments et conclusions présents
dans l'autres fil de discussion avec un jour de retard seulement :-)
Je ne vois pas où est le retard, personne n'a évoqué ce que je propose.
(ça serait bien que tu lises les messages des autres en entier)
Bon, moi, je proposais hier d'ajouter un tag is_in=France par
boutade.
Boutade ? non ! tout le monde proposait d'utiliser des infos géographiques
(polygones ou toi avec ton is_in) ce qui n'a aucun sens et ne résoud pas
le problème linguistique ! Ce que je propose évite TOUTES les couteuses
requêtes géométriques en restant dans les données du même et seul objet à
nommer.
Mais on pourrait mettre à la place ton name:lang=fr avec un
bot sur tous les éléments qui ont un name en France. Ben oui, tant
qu'à faire, pourquoi attendre que quelqu'un ajoute un name:xx pour
passer à l'action ? Autant anticiper. Ca fera juste quelques millions
de tags (pourquoi s'arrêter à la France) redondants dans la base pour
que nominatim n'ait pas à faire ce boulot lui-même
Des millions de tags name:lang=* sans doute pas:
- on peut se contenter de ne les mettre que dans les objets qui ont déjà
plusieurs langues (donc des name:xx=* et pas uniquement des name=*)
- et au passage éliminer parfois dix fois plus de redondances parmi les
name:xx=* de valeurs identiques (on a juste à indiquer les codes langue
dans *:lang=*, le plus souvent 3 caractères à ajouter par langue dans ce
tag)
Note quand même
- { name:ca=* + name:ca:lang=oc } doit être totalement équivalent à {
name:oc=* + name:oc:lang=ca }. Une seule des langues pilote les autres
mais aucune n'a réellement de priorité en terme de tags, si on veut
normaliser les choses, on pourrait dire que c'est celle ayant le code le
plus petit qui pilote les autres (ou en prenant en comme pilote s'il est
présent dans la liste)
- les valeurs données dans *:lang=* sont uniquement des codes langues
(séparés par point-virgules sans aucun espace); il ne devrait y avoir aucun
doublon, leur ordre n'est pas significatif, on peut le normaliser en les
triant alphabétiquement
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] limite du nombre de sollicitations
Le 19 novembre 2013 23:17, Ab_fab gamma@gmail.com a écrit : Bonsoir, Sur cette question du stockage de tuiles, une idée intéressante de Geofabrik (plutôt pour le stockage en local) http://blog.geofabrik.de/?p=268 Excellente astuce ! Comme quoi ça sert de savoir ce qu'il y a sous le capot. Cyrille. Le 19 novembre 2013 01:19, Christian Quest cqu...@openstreetmap.fr a écrit : Et des MBtiles des tuiles FR sont dispo (expérimentalement) ici : http://osm13.openstreetmap.fr/~cquest/mbtile-osmfr/ zoom 1-9 sur le monde (750Mo), et 10-14 sur la métropole (6.2Go) Le 18 novembre 2013 23:48, Jean-Marc Liotier j...@liotier.org a écrit : On 11/18/2013 11:40 PM, Marc Sibert wrote: Côté sérieux, on peut aussi envisager le caching de tuiles quand on a pas besoin d'une grande fraicheur. C'est un service beaucoup plus simple à mettre en place que la génération temps-réel. Ça ne demande que du stockage. C'est ce que je suis en train de pousser chez un client pour y faire entrer Openstreetmap - c'est de l'infrastructure générique demandant zéro nouvelle compétence et ça permet de s'habituer à l'idée d'utiliser Openstreetmap comme fonds de carte en attendant de se rendre compte qu'on a des besoins particuliers qui diffèrent du style de démo. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Le 20/11/2013 14:38, Pieren a écrit : 2013/11/20 Philippe Verdy verd...@wanadoo.fr: En gros ce que je propose c'est, pour éviter les redondances de noms, d'ajouter name:lang=fr. Bravo Philippe. Tu arrives aux mêmes arguments et conclusions présents dans l'autres fil de discussion avec un jour de retard seulement :-) (ça serait bien que tu lises les messages des autres en entier) Bon, moi, je proposais hier d'ajouter un tag is_in=France par boutade. Mais on pourrait mettre à la place ton name:lang=fr avec un bot sur tous les éléments qui ont un name en France. Ben oui, tant qu'à faire, pourquoi attendre que quelqu'un ajoute un name:xx pour passer à l'action ? Autant anticiper. Ca fera juste quelques millions de tags (pourquoi s'arrêter à la France) redondants dans la base pour que nominatim n'ait pas à faire ce boulot lui-même Dans ce cas, autant utiliser la syntaxe de la balise wikipedia et utiliser name=fr:Impasse de la Capillotraction fr: indiquant la langue par défaut de la balise name... Mais je n'arrive toujours pas a en voir l'intérêt :/ Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
2013/11/20 Philippe Verdy verd...@wanadoo.fr: Je ne vois pas où est le retard, personne n'a évoqué ce que je propose. Bon, allez, parce que c'est toi et que je suis dans un bon jour: https://lists.openstreetmap.org/pipermail/talk-fr/2013-November/064388.html Peut être qu'un tag qui précise la langue de name=* serait moins choquant pour certains, Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Détection d'erreurs d'intersection de routes dans Osmose
Non, c'est keep right qui fait ça : http://keepright.ipax.at/report_map.php?ch=0%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198 Le 20 novembre 2013 15:46, Nicolas Moyroud nmoyr...@free.fr a écrit : Bonjour à tous, Il me semblait qu'il y avait dans Osmose une détection des erreurs d'intersection de routes, c'est à dire quand deux highways se croisent sans noeud d'intersection et qu'il n'y a pas de bridge ou de tunnel défini sur une des deux. Je n'arrive pas à retrouver à quel type d'erreur cela correspond dans Osmose. Ou alors j'ai peut-être eu des hallucinations et ça n'a jamais existé... ;-) Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] limite du nombre de sollicitations
L'idée d'origine est quand même de stocker sur clé USB pour un usage le plus universel possible et sans logiciel, d'où la contrainte imposée des fichiers stockés dans des répertoires. C'est pour les besoins de l'urgence du terrain au Philippines où il faut s'adapter à l'existant plutôt que d'imposer une solution sûrement plus élégante mais contraignante et moins universelle. La conclusion c'est qu'en ayant des tuiles de 1024x1024 au lieu de 256x256 et des clusters de 8Ko on peut limiter les dégâts. Sur un serveur où l'on se met les contrainte de son choix, c'est sûr que c'est pas la meilleure solution, mais ce n'était pas le sujet. Le 20 novembre 2013 15:15, Christophe Merlet red...@redfoxcenter.org a écrit : Le 20/11/2013 14:57, Cyrille Giquello a écrit : Le 19 novembre 2013 23:17, Ab_fab gamma@gmail.com a écrit : Bonsoir, Sur cette question du stockage de tuiles, une idée intéressante de Geofabrik (plutôt pour le stockage en local) http://blog.geofabrik.de/?p=268 Excellente astuce ! Comme quoi ça sert de savoir ce qu'il y a sous le capot. La plupart des applis que je connais qui stockent les tuiles hors ligne le font dans un fichier unique Berkeley DB, GDBM ou SQLite... C'est surement plus compact que leur solution quelque soit la taille des clusters du système de fichiers. Cependant leur graphique est intéressant. mais c'est sur du FAT, le plus pourri des FS. NTFS est plus performant que FAT, et ext4 est capable de stocker les petits fichiers directement dans l'inode. UFS2, reiserfs et btrfs supporte en plus la sous-allocation de blocks permettant de mettre plusieurs fichiers dans un cluster. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Le 20 nov. 2013 à 15:05, Pieren pier...@gmail.com a écrit : Peut être qu'un tag qui précise la langue de name=* serait moins choquant pour certains, Je ne comprend pas un propos si général. name peut se trouver avec un seul item ou être composé d'une expression non française Kerambellec, même s'il est officiel, n'est pas du français et ne le sera jamais. Rue de Kerambellec pourrait à la rigueur être qualifié avec un fr mais, quand on trouve dans la nomenclature officielle de Quimper Hent ar C'hazh Koad (chemin de l'écureuil, mais il s'agit d'une large rue goudronnée), faut-il déclarer que c'est du français? Dans ce cas, fr changerait de signification et signifierait expression agréée par la République française. Et si on proposait name:rf pour doublonner name? Là on serait dans le vrai. Christian Rogel ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
2013/11/20 François Lacombe francois.laco...@telecom-bretagne.eu: J'aimerais avoir plusieurs avis, sur l'aspect sémantique. Déjà, pensez aux non-spécialistes qui vont tomber sur ces tags. Evitez les abréviations à 2 ou 3 lettres trop ambigues (vu de l'extérieur). Si vous optez pour FT, remplacez-le par FranceTelecom. Et quel que soit le choix, documentez-le dans le wiki. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
C'est tout a fait compréhensible. Je présentait FT pour son apparente simplicité à la saisie au clavier. Si FranceTelecom devait le remplacer, je pense qu' Orange aurait alors plus d’avantages que d’inconvénients. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 20 novembre 2013 17:49, Pieren pier...@gmail.com a écrit : 2013/11/20 François Lacombe francois.laco...@telecom-bretagne.eu: J'aimerais avoir plusieurs avis, sur l'aspect sémantique. Déjà, pensez aux non-spécialistes qui vont tomber sur ces tags. Evitez les abréviations à 2 ou 3 lettres trop ambigues (vu de l'extérieur). Si vous optez pour FT, remplacez-le par FranceTelecom. Et quel que soit le choix, documentez-le dans le wiki. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Am 20.11.2013 15:02, schrieb Christophe Merlet: Dans ce cas, autant utiliser la syntaxe de la balise wikipedia et utiliser name=fr:Impasse de la Capillotraction fr: indiquant la langue par défaut de la balise name... Mais je n'arrive toujours pas a en voir l'intérêt :/ L'intérêt est de permettre à des applis de savoir si name est le nom français d'un objet sans être oblige pour cela de faire une requête spatiale. Autrement dit, sans name:fr, name:lang=fr ou name=fr: on est obligé de vérifier si l'objet se trouve à l'intérieur de la relation France, de la relation Québec, de la relation Suisse romande etc... Ce genre de requête est possible mais prend trop de temps pour des applis interactifs. La question s'il faut tagguer des données redondantes sur les objets pour éviter des requêtes spatiales, se pose pour d'autres types d'information. On taggue maxspeed=130 sur les autoroutes françaises. Si on mettait maxspeed:motorway=130 sur la relation France on aurait pas besoin de le faire. Pareil pour les zones 30, la maxspeed=50 en agglomeration... Tout ça c'est du tagging pour les appli. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
Et pourquoi pas: ref:42C=* ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
En effet ca peut le faire. Cependant indiquer l'entreprise en plus du nom du referentiel donne une indication de nationalité sans avoir a mettre fr explicitement. A voir si on peut s'en passer ici. Le 20 nov. 2013 19:56, Christian Quest cqu...@openstreetmap.fr a écrit : Et pourquoi pas: ref:42C=* ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] valeurs multiples
Le 20/11/2013 14:21, Pieren a écrit : Quelqu'un a posé la question des valeurs multiples il y a quelques mois sur la liste principale pour savoir si c'était finalement vraiment exploité ([1]). Celui qui a démarré la discussion en a fait un billet ([2]). Je comprends sa discussion (et le problème du sens : dans taginfo, il y a des residential;commercial et des commercial;residential). Puisque j’ai trouvé des valeurs identiques à celles que je souhaitais utiliser, je n'ai pas pensé qu'il ne fallait pas le faire. Pour revenir à ton landuse, il faut aussi être un peu flexible et prendre la valeur comme l'usage principal mais pas exclusif d'une zone. Le wiki dit bien ([3]) : describe the primary use of land. ne pratiquant pas l'anglais fluently, j'ai lu le wiki en français qui (il me semble) n'a pas reproduit cette phrase. On peut admettre qu'un landuse=residential contienne des petits commerces ou bureaux et qu'un landuse=retail contienne quelques maisons d'habitation. J'entends bien, puisque, comme je l'ai dit précédemment, je n'ai pas prévu de mettre ;retail dans le landuse, car je trouvais que leur importance était faible par rapport aux logements et aux bureaux (de même que les terrains de sport et le dépôt du trm), S'il n'y a pas de valeur prédominante, on peut affiner les landuse en plus petits morceaux Je vais essayer de le faire ; Je ne l'ai pas fait, au départ, pour ne pas multiplier le même name ZAC Andromède sur plusieurs morceaux ou créer un nouveau tag pour les zones mixtes (ou voir du côté de taginfo si quelque chose n'existe pas déjà) je n'ai rien trouvé, ou je n'ai pas su chercher Cordialement Lenny ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Et hop... http://openstreetmap.fr/blogs/cquest/controle-qualite-limites-administratives-osm Le 19 novembre 2013 21:09, DH dhel...@free.fr a écrit : Le 19/11/2013 18:58, Christian Quest a écrit : Non, c'est pas ça... ça serait osé et peu diplomatique ! Le 19 novembre 2013 18:34, Nicolas Moyroud nmoyr...@free.fr a écrit : Roooh tu ne vas quand même pas oser commettre ce crime de lèse-majesté Christian ? Attention le père Berteaud va encore nous faire une crise et sortir un billet bien énervé à l'encontre d'OSM ! Nicolas Le 19/11/2013 16:26, HELFER Denis a écrit : Peut-être ça ? http://concours-geoportail.ign.fr/presentation.html Damned, le mystère demeure alors ? Allez les bleus Christian ! Denis PS : tiens, je vais aller contribuer ; mon petit doigt me dit que ce devrait être calme jusqu'à 22h30 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
Bonsoir, Je pense également qu'il serait intéressant de se passer de citer Orange ou FTdans le nom de l'attribut. A savoir que dans les documentations Orange (http://www.orange.com/fr/innovation/reseaux/documentation Offre d'accès à la boucle locale d'Orangeliste des NRA d'Orange ) le code long est appelé CODE INSEE - NRA. Ma petite pierre... @+ ZZ29 Le 20 novembre 2013 19:53, Christian Quest cqu...@openstreetmap.fr a écrit : Et pourquoi pas: ref:42C=* ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] limite du nombre de sollicitations
Le 20/11/2013 16:16, Christian Quest a écrit : L'idée d'origine est quand même de stocker sur clé USB pour un usage le plus universel possible et sans logiciel, d'où la contrainte imposée des fichiers stockés dans des répertoires. C'est pour les besoins de l'urgence du terrain au Philippines où il faut s'adapter à l'existant plutôt que d'imposer une solution sûrement plus élégante mais contraignante et moins universelle. La conclusion c'est qu'en ayant des tuiles de 1024x1024 au lieu de 256x256 et des clusters de 8Ko on peut limiter les dégâts. Sur un serveur où l'on se met les contrainte de son choix, c'est sûr que c'est pas la meilleure solution, mais ce n'était pas le sujet. Oui l'enjeu, tel que je l'avais compris, c'est de fournir sur une clef usb un fichier html de base, un fichier bibliothèque javascript et une arborescence de dossiers. Et ça s'ouvre avec n'importe quel navigateur acceptant javascript. Et ça se recopie sur n'importe quelle clef. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20/11/2013 21:18, Christian Quest a écrit : Et hop... http://openstreetmap.fr/blogs/cquest/controle-qualite-limites-administratives-osm scientifique ! peut-être trop (mais c'est peut-être notre karma) Si l'IGN se donnait la peine de justifier autant la qualité de leurs données, autrement par indiquer que c'est basé sur la version x-n de leur propre référentiel, on pourrait avancer, ensemble. La co-construction du territoire se heurte encore à des cultures (soutenues en partie par le législateur) trop divergentes. A propos, c'en est où de la convergence cadastrale (troll inside ;-) Combien a pris ce chantier titanesque pour la saisie initiale ? quel en est le coût/bénéfice ? Mangez de ce pain labellisée et vous serez guéris de toute tentative d'aller changer de boulangerie. Robin, tu aurais cru cela possible ? si vite ? Si OSM se pose déjà la question de la maintenance de la qualité de ses propres données (avec l'appui de plus en plus fort des collectivités qui connaissent encore mieux le terrain que l'IGN), c'est qu'on est encore dans la course, non ? On ne lâche rien !! Denis, qui a lâché les limites communales pour un autre chantier aussi prégnant ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faut-il ajouter systématiquement name:fr ? Was:Outil pour ajout de name:fr ?
Sans chercher à apporter de réponse à la question, un petit point supplémentaire : 2013/11/20 Christian Quest cqu...@openstreetmap.fr Si il n'y a que name=* ça n'apporte pas grand chose Si il y a d'autres names:xx=* ça lève l'ambiguité de la langue de name=* Il y a au moins un cas d'usage pour lequel préciser, d'une manière ou d'une autre, la langue de name=* alors qu'il n'y a pas d'autre name:xx=* peut être utile. Pour rendre correctement les noms écrits en caractères chinois il faut préciser la langue dans laquelle le nom est écrit. Les styles sont légèrement différents entre les variantes du chinois, le japonais, le coréen. (Ce n'est pas uniquement lié aux caractères simplifiés utilisés en RPC.) [1] Ça n'empêche généralement pas la lecture et c'est plus une question de style, mais qui n'est pas négligeable non plus. (En me risquant de faire une analogie, ça serait un peu comme écrire les noms de lieux allemand sans les caractères utilisés habituellement, par exemple Muenchen, Koeln, Duesseldorf, Giessen. Pas fondamentalement gênant, mais pas l'écriture standard de tous les jours non plus.) Google Maps tient par exemple compte de ces différences. Mais quand à savoir quelle méthode ils utilisent, c'est une autre question ! [1] http://en.wikipedia.org/wiki/Han_Unification#Examples_of_language_dependent_characters ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20/11/2013 21:18, Christian Quest a écrit : Et hop... http://openstreetmap.fr/blogs/cquest/controle-qualite-limites-administratives-osm Le 19 novembre 2013 21:09, DH dhel...@free.fr mailto:dhel...@free.fr a écrit : Le 19/11/2013 18:58, Christian Quest a écrit : Non, c'est pas ça... ça serait osé et peu diplomatique ! Le 19 novembre 2013 18:34, Nicolas Moyroud nmoyr...@free.fr mailto:nmoyr...@free.fr a écrit : Roooh tu ne vas quand même pas oser commettre ce crime de lèse-majesté Christian ? Attention le père Berteaud va encore nous faire une crise et sortir un billet bien énervé à l'encontre d'OSM ! Nicolas Le 19/11/2013 16:26, HELFER Denis a écrit : Peut-être ça ? http://concours-geoportail.ign.fr/presentation.html Damned, le mystère demeure alors ? Allez les bleus Christian ! Denis PS : tiens, je vais aller contribuer ; mon petit doigt me dit que ce devrait être calme jusqu'à 22h30 ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr Bonsoir, C'est super-efficace : j'ai pris le premier node (avec l'erreur Maxi) et je tombe sur des tracés à la serpe sourcés GeoFLA2001. Alors qu'en plus le contour commune *est* vectorisé dans le cadastre. J'ai donc pris DB083-CHARRAY-city-limit.osm http://cadastre.openstreetmap.fr/data/028/DB083-CHARRAY-city-limit.osm que je refais. Si un courageux organisateur sait : 1. chercher tous les GeoFLA qui trainent, 2. les comparer ou pas à la liste des communes vectorisées, 3. en faire un MapCraft qu'on se jette dessus gouluement... A+ -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20/11/2013 21:52, Marc Sibert a écrit : Le 20/11/2013 21:18, Christian Quest a écrit : Et hop... http://openstreetmap.fr/blogs/cquest/controle-qualite-limites-administratives-osm Le 19 novembre 2013 21:09, DH dhel...@free.fr mailto:dhel...@free.fr a écrit : Le 19/11/2013 18:58, Christian Quest a écrit : Non, c'est pas ça... ça serait osé et peu diplomatique ! Le 19 novembre 2013 18:34, Nicolas Moyroud nmoyr...@free.fr mailto:nmoyr...@free.fr a écrit : Roooh tu ne vas quand même pas oser commettre ce crime de lèse-majesté Christian ? Attention le père Berteaud va encore nous faire une crise et sortir un billet bien énervé à l'encontre d'OSM ! Nicolas Le 19/11/2013 16:26, HELFER Denis a écrit : Peut-être ça ? http://concours-geoportail.ign.fr/presentation.html Damned, le mystère demeure alors ? Allez les bleus Christian ! Denis PS : tiens, je vais aller contribuer ; mon petit doigt me dit que ce devrait être calme jusqu'à 22h30 ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr Bonsoir, C'est super-efficace : j'ai pris le premier node (avec l'erreur Maxi) et je tombe sur des tracés à la serpe sourcés GeoFLA2001. Alors qu'en plus le contour commune *est* vectorisé dans le cadastre. J'ai donc pris DB083-CHARRAY-city-limit.osm http://cadastre.openstreetmap.fr/data/028/DB083-CHARRAY-city-limit.osm que je refais. Si un courageux organisateur sait : 1. chercher tous les GeoFLA qui trainent, 2. les comparer ou pas à la liste des communes vectorisées, 3. en faire un MapCraft qu'on se jette dessus gouluement... C'est effectivement des données à éradiquer ! http://taginfo.openstreetmap.fr/search?q=source%3DGeoFla Depuis la page de détail il y a un lien XAPI et JOSM turbo pour charger les données. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Hello, Est-ce qu'il serait d'ajouter un séparateur entre les code insee ? Genre : distance; insee1; insee2; etc Comment ajouter une couche Geofla ou Route500 dans Josm ? Car finalement, qui nous dit qu'ils sont plus précis que Osm. Il me semblait que la référence ce sont les communes, et comme elles ne sont pas toutes d'accord entre elle... qui croire ? Je viens de vérifier un point dans le 44. L'intersection était à peu prêt au même endroit pour les 3 cadastres. Le point Osm était éloigné de 7m, et le tableau m'indique 282m de décalage (communes 44018 44020 44024) Sinon, j'ai remarqué pas mal de grosse différence lorsque le point d'intersection se situe dans l'eau. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20 novembre 2013 22:05, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Je viens de vérifier un point dans le 44. L'intersection était à peu prêt au même endroit pour les 3 cadastres. Le point Osm était éloigné de 7m, et le tableau m'indique 282m de décalage (communes 44018 44020 44024) Sinon, j'ai remarqué pas mal de grosse différence lorsque le point d'intersection se situe dans l'eau. Idem au lac de Paladru, les limites cadastrales et OSM sont cohérentes entre les 3 communes, par contre GeoFla et la carte Ign suivent l'axe du lac ce qui semble être faux. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20/11/2013 22:05, Stéphane Péneau a écrit : Hello, Est-ce qu'il serait d'ajouter un séparateur entre les code insee ? Genre : distance; insee1; insee2; etc Comment ajouter une couche Geofla ou Route500 dans Josm ? Car finalement, qui nous dit qu'ils sont plus précis que Osm. Il me semblait que la référence ce sont les communes, et comme elles ne sont pas toutes d'accord entre elle... qui croire ? Je viens de vérifier un point dans le 44. L'intersection était à peu prêt au même endroit pour les 3 cadastres. Le point Osm était éloigné de 7m, et le tableau m'indique 282m de décalage (communes 44018 44020 44024) Intéressant ! Tu peux vérifier avec une ortho dans le cas ou ça colle au paysage (et que l'ortho est bien calé) ? Sinon, j'ai remarqué pas mal de grosse différence lorsque le point d'intersection se situe dans l'eau. Il n'y a pas de parcelles cadastrale dans l'eau. Donc on n'a pas de définition des limites. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [Retour présentation] OSM au Géopnr
Bonsoir, voici un petit retour sur les présentations OSM au GéoPNR (rencontre des SIGISTES et Observateurs du réseau des Parcs naturels régionaux) Le lien avec ces structures peut être intéressant dans la mesure où les Parc naturels régionaux sont des zones rurales, nos fameuses zones blanches. j'ai fais un stage de quelques mois là bas dans le PNR de Millevaches en Limousin. Donc osm avait les honneurs avec deux présentations, Christian pour une introduction générale et moi pour un retour d'expérience. Christian a porté sa désormais classique présentation Prezi sur OSM, Les questions ont porté sur le modèle de données ? Les réponses aux contributions mal-intentionnées ainsi que d'autres points qui m'ont servit de tremplin pour ma présentation : - Quid d'Osm en milieu rural - Comment utiliser en tan que Sigiste traditionnels Vous pouvez la retrouver par ici: http://bobo-romania.github.io/geopnr/ Quelques commentaires sont présents sur le document (via les notes: appuyez sur S) N'hésitez pas à faire des retours ou utiliser de cette base comme support. c'est accessible sur github et vous pouvez l'utiliser en local si vous voulez l'adapter. les docs sont sous licence CC-BY Bonne soirée ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20/11/2013 21:52, Marc Sibert a écrit : C'est super-efficace : j'ai pris le premier node (avec l'erreur Maxi) et je tombe sur des tracés à la serpe sourcés GeoFLA2001. Alors qu'en plus le contour commune *est* vectorisé dans le cadastre. J'ai donc pris DB083-CHARRAY-city-limit.osm http://cadastre.openstreetmap.fr/data/028/DB083-CHARRAY-city-limit.osm que je refais. Si un courageux organisateur sait : 1. chercher tous les GeoFLA qui trainent, C'est pas comme si on avait taginfo, hein ;-) http://taginfo.openstreetmap.org/search?q=geofla#values Il y a un petit gisement dans l'Indre entre autres (merci à didier2020 qui était tombé dessus). Il y a aussi des bouts de camps militaire dans le Var il me semble. 2. les comparer ou pas à la liste des communes vectorisées, La source vecteur économise des clics, c'est indéniable. Mais elle n'est pas un gage de qualité. Le fait que tout soit géoréférencé donne l'illusion et c'est bien le problème. Donc le travail de reprise ne doit pas se cantonner aux communes vectorisées. 3. en faire un MapCraft qu'on se jette dessus gouluement... ...ou pas (pas encore) : sur les 100 points des plus grands écarts, seuls 42 tombent dans une commune du FLA. Et beaucoup sur le littoral. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20 novembre 2013 22:05, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Hello, Est-ce qu'il serait d'ajouter un séparateur entre les code insee ? Genre : distance; insee1; insee2; etc Le séparateur c'est un espace ;) Comment ajouter une couche Geofla ou Route500 dans Josm ? Je suis en train de finaliser une couche en overlay avec le Route500 et les nœuds d'intersection avec leurs écarts indiqués et colorés (c'est l'image en bas de billet). Ca sera dispo (je pense ce soir) sur tile.openstreetmap.fr puisque c'est là que j'ai toutes les data et que ça se remet à jour quotidiennement vu que j'ai scripté tout le processus. Car finalement, qui nous dit qu'ils sont plus précis que Osm. Il me semblait que la référence ce sont les communes, et comme elles ne sont pas toutes d'accord entre elle... qui croire ? J'ai pour ma part trouvé un belle erreur de l'IGN dans l'Yonne, plus de 600m. J'ai revérifié le cadastre, y compris sur le Geoportail (comparaison BD Topo / cadastre) et c'est bien l'IGN qui se trompe. Il ne faut donc pas considérer que l'IGN est plus exacte qu'OSM, c'est à vérifier au cas par cas. Je viens de vérifier un point dans le 44. L'intersection était à peu prêt au même endroit pour les 3 cadastres. Le point Osm était éloigné de 7m, et le tableau m'indique 282m de décalage (communes 44018 44020 44024) Possible qu'il y ait une faille dans mes requêtes... à creuser ! Sinon, j'ai remarqué pas mal de grosse différence lorsque le point d'intersection se situe dans l'eau. Oui, c'est compréhensible surtout sur le littoral car nous n'avons sûrement pas la même définition de la limite de commune entre le cadastre (donc OSM) et l'IGN. Ailleurs (lac, rivières) si les cadastre des deux communes disent la même chose, je pense qu'il faut les considéré comme exact. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20 novembre 2013 21:50, DH dhel...@free.fr a écrit : Le 20/11/2013 21:18, Christian Quest a écrit : Et hop... http://openstreetmap.fr/blogs/cquest/controle-qualite- limites-administratives-osm scientifique ! peut-être trop (mais c'est peut-être notre karma) Au moins le processus de contrôle est décrit et reproductible (requêtes publiées + données sous licence libre) ;) Les thèses et autre trucs que j'ai pu lire provenant de chercheurs me laissent toujours sur ma faim de ce côté (sans parler de la propension à délayer). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20/11/2013 22:10, Frédéric Rodrigo a écrit : Intéressant ! Tu peux vérifier avec une ortho dans le cas ou ça colle au paysage (et que l'ortho est bien calé) ? Oui ça colle correctement avec l'ortho. C'est pour ça que j'aurais aimé voir où Route500/Geofla placent ce point. Je viens de vérifier sur Geoportail, et effectivement, leur intersection est à 300m au sud-est. Mais si on se base sur le cadastre, qui se cale bien entre les communes, c'est l'ign qui est à l'ouest. Heu pardon, au sud-est. Il n'y a pas de parcelles cadastrale dans l'eau. Donc on n'a pas de définition des limites. Tu veux dire que Brest a une frontière commune avec New-York ? ;-) Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20/11/2013 22:18, Christian Quest a écrit : Le séparateur c'est un espace ;) Heu oui, mais le séparateur avec l'écart, c'est une virgule. Je sais importer un cvs avec un séparateur, mais pas avec 2 différents. Je suis en train de finaliser une couche en overlay avec le Route500 et les noeuds d'intersection avec leurs écarts indiqués et colorés (c'est l'image en bas de billet). Ca sera dispo (je pense ce soir) sur tile.openstreetmap.fr http://tile.openstreetmap.fr puisque c'est là que j'ai toutes les data et que ça se remet à jour quotidiennement vu que j'ai scripté tout le processus. Super ! Car finalement, qui nous dit qu'ils sont plus précis que Osm. Il me semblait que la référence ce sont les communes, et comme elles ne sont pas toutes d'accord entre elle... qui croire ? Possible qu'il y ait une faille dans mes requêtes... à creuser ! A priori non (voir mon message précédent). J'ai plutôt l'impression qu'il faut prendre les données de l'Ign avec des pincettes. De plus, j'ai remarqué que la précision des limites d'une communes peut évoluer dans le temps. Ce n'est pas rare de tomber sur des imports de cadastre vectorisé qui ne ne correspondent plus tout à fait avec l'actuel cadastre. Sur ta couche, on va peut-être avoir besoin de signaler les faux positifs. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20/11/2013 21:18, Christian Quest a écrit : Et hop... http://openstreetmap.fr/blogs/cquest/controle-qualite-limites-administratives-osm Quitte à consommer de notre temps à comparer, il faudrait idéalement que ça s'appuie côté IGN sur la BD Topo. Dans le contexte actuel, où les contacts avec l'IGN sont fréquents, ce serait une belle avancée que de pouvoir disposer, _uniquement à des fins d'analyse_, de la couche de limites admin de la BD Topo. À charge pour nous de produire autant de croisements, stats, mesures, comparaisons et j'en passe, qui permettraient de ne pas s'épuiser sur un travail bancal à base de sources au 1/1.000.000 (GeoFLA) ou au 1/250.000 (Route500) quand on prétend voisiner avec le 1/10.000 (nous). Un accord de la part de l'IGN pour cette mise à dispo serait, inutile de le dire, perçu à sa juste valeur et un vrai signe de coopération. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20/11/2013 22:18, Christian Quest a écrit : Le 20 novembre 2013 22:05, Stéphane Péneau stephane.pen...@wanadoo.fr mailto:stephane.pen...@wanadoo.fr a écrit : Hello, Est-ce qu'il serait d'ajouter un séparateur entre les code insee ? Genre : distance; insee1; insee2; etc Le séparateur c'est un espace ;) il faudrait mettre la distance en premier car le combre de communes est variable. On peut bricoler dans LibreOffice Calc pour réordonner les données, Données Texte en colonnes pour scinder les communes Insee , et rajouter un auto filtre pour trouver son département, mais autant supprimer quelques manips à la source... ça semble être un bel outil, mais je ne suis toujours pas chaud pour jouer avec la cadastre bitmap, là où semble être les grosses erreurs... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] valeurs multiples
Bonsoir, Le mercredi 20 novembre 2013 14:21:34 Pieren a écrit : Quelqu'un a posé la question des valeurs multiples il y a quelques mois sur la liste principale pour savoir si c'était finalement vraiment exploité ([1]). Celui qui a démarré la discussion en a fait un billet ([2]). J'adhère à sa conclusion qui est de dire qu'il n'y a aucune exploitation généralisée des valeurs multiples et que ça n'est vraiment utile que dans de rares cas. Il faudrait donc en général essayer de les éviter. Il n'y a peut-être pas d'exploitation généralisée pour l'instant, mais ne peut-on pas envisager que ce le devienne. J'essaye d'éviter de l'utiliser, mais j'ai un cas où je n'ai pas trouvé mieux, c'est pour les vente directes de produits fermiers, exemples : http://www.openstreetmap.org/browse/node/1865786378 http://www.openstreetmap.org/browse/node/1864170543 Si quelqu'un a une autre solution, je suis preneur :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
ok, je vous remet ça avec la distance en premier.
Et la couche Limite admin FR est dispo:
http://tile.openstreetmap.fr/?zoom=7lat=46.88903lon=2.36297layers=000BFFFTF
Dans JOSM ajouter tms[20]:http://{switch:a,b,c}.
tile.openstreetmap.fr/fradm/{zoom}/{x}/{y}.png
Le 20 novembre 2013 22:39, Christophe Merlet red...@redfoxcenter.org a
écrit :
Le 20/11/2013 22:18, Christian Quest a écrit :
Le 20 novembre 2013 22:05, Stéphane Péneau stephane.pen...@wanadoo.fr
mailto:stephane.pen...@wanadoo.fr a écrit :
Hello,
Est-ce qu'il serait d'ajouter un séparateur entre les code insee ?
Genre :
distance; insee1; insee2; etc
Le séparateur c'est un espace ;)
il faudrait mettre la distance en premier car le combre de communes est
variable.
On peut bricoler dans LibreOffice Calc pour réordonner les données,
Données Texte en colonnes pour scinder les communes Insee , et rajouter
un auto filtre pour trouver son département, mais autant supprimer quelques
manips à la source...
ça semble être un bel outil, mais je ne suis toujours pas chaud pour jouer
avec la cadastre bitmap, là où semble être les grosses erreurs...
Librement,
--
Christophe Merlet (RedFox)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
Ce sont bien des codes longs étendus de 42C. Partons sur ref:42C, merci pour vos retours. Je créerai la page wiki demain. Une information qu'il serait utile d'ajouter, sans partir dans une modélisation détaillée : les types de média accueillis dans le bâtiment. Avec le développement de la fibre à domicile, des bâtiments n'hébergeant que des NRA (boucle locale cuivre) se sont vus accueillir des NRO (boucle locale optique) et ce tout opérateurs confondus. Des locaux ont aussi été créés de rien pour servir de NRO. Je ne sais pas si le terme central office convient pour parler d'un NRO. En espérant que si, pouvoir dire si on a un NRO, un NRA ou les deux dans une autre clé serait bien. Cela permet de rendre plus efficace la jointure avec des bases externes. Le reste des informations peut rester ensuite dans la base en question. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 20 novembre 2013 21:30, . ZZ29 zrozi...@gmail.com a écrit : Bonsoir, Je pense également qu'il serait intéressant de se passer de citer Orange ou FTdans le nom de l'attribut. A savoir que dans les documentations Orange (http://www.orange.com/fr/innovation/reseaux/documentation Offre d'accès à la boucle locale d'Orangeliste des NRA d'Orange ) le code long est appelé CODE INSEE - NRA. Ma petite pierre... @+ ZZ29 Le 20 novembre 2013 19:53, Christian Quest cqu...@openstreetmap.fr a écrit : Et pourquoi pas: ref:42C=* ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
On 11/21/2013 12:01 AM, François Lacombe wrote: Une information qu'il serait utile d'ajouter, sans partir dans une modélisation détaillée : les types de média accueillis dans le bâtiment. Avec le développement de la fibre à domicile, des bâtiments n'hébergeant que des NRA (boucle locale cuivre) se sont vus accueillir des NRO (boucle locale optique) et ce tout opérateurs confondus. Des locaux ont aussi été créés de rien pour servir de NRO. Tu peux envisager de sous-typer avec un central_office=* mais je doute que ce soit pertinent pour Openstreetmap car inobservable pour qui n'a pas accès à des informations provenant des opérateurs. Par contre - et de manière indépendante, on pourrait envisager un telecom=datacenter (ou man_made=datacenter - j'hésite) pour étiqueter des grosses installations industrielles comme celles d'OVH dans les champs de betteraves, facilement repérables dans l'imagerie orbitale. Je ne sais pas si le terme central office convient pour parler d'un NRO Central office (central en langue Françoise) est un vocable télécom hérité du RTC. Dans le monde cablo on parle plutôt de head end (tête de réseau) - un nouveau sous-type pour t'occuper. Les NRO s'appellent l'un ou l'autre suivant la culture de son propriétaire... Alors, un central_office=* pouvant contenir des valeurs multiples (copper;optical;coaxial) ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
Je crois en effet que l'appellation central office n'est pas très claire et qu'une discussion sur la liste internationale va s'imposer avant que telecom=central_office ne devienne trop populaire. Pour l'instant on peut encore cadrer l'expansion. cf cet échange qui s'est tenu à l'instant : https://twitter.com/InfosReseaux/status/403303386742661120 et en particulier cette page : http://books.google.fr/books?id=wBBt_sK0WHYCpg=PA109lpg=PA109dq=%22optical+connection+node%22source=blots=cJHuD4Qax9sig=kE-RhjA3wXq7jdn_O6kTgxECND0hl=frsa=Xei=nUCNUoa4MMqV0QWAuoD4Agved=0CF4Q6AEwBQ#v=onepageq=%22optical%20connection%20node%22f=false On aurait les correspondances suivantes : Noeud de Raccordement d'Abonnés = Subscriber Connection Node Noeud de Raccordement Optique = Optical Connection Node Répartiteur (optique comme cuivre) = Central Office et ceci est a l'intérieur d'un NRA ou NRO, donc à l'intérieur du bâtiment, *donc non concerné par OSM d'après nos précédents mails.* Le soucis avec ca c'est quand NRA et NRO sont dans le même bâtiment : on ne peut utiliser telecom=subscriber_connection_node et telecom=optical_connection_point sur le même objet. Ca va devenir un casse-tête supplémentaire j'ai l'impression. Avant que ca devienne trop tortueux, concentrons-nous vraiment sur les têtes de boucles locales avant toute entrée dans les détails (SR, chambres, PRM, ...). *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 21 novembre 2013 00:18, Jean-Marc Liotier j...@liotier.org a écrit : On 11/21/2013 12:01 AM, François Lacombe wrote: Une information qu'il serait utile d'ajouter, sans partir dans une modélisation détaillée : les types de média accueillis dans le bâtiment. Avec le développement de la fibre à domicile, des bâtiments n'hébergeant que des NRA (boucle locale cuivre) se sont vus accueillir des NRO (boucle locale optique) et ce tout opérateurs confondus. Des locaux ont aussi été créés de rien pour servir de NRO. Tu peux envisager de sous-typer avec un central_office=* mais je doute que ce soit pertinent pour Openstreetmap car inobservable pour qui n'a pas accès à des informations provenant des opérateurs. Par contre - et de manière indépendante, on pourrait envisager un telecom=datacenter (ou man_made=datacenter - j'hésite) pour étiqueter des grosses installations industrielles comme celles d'OVH dans les champs de betteraves, facilement repérables dans l'imagerie orbitale. Je ne sais pas si le terme central office convient pour parler d'un NRO Central office (central en langue Françoise) est un vocable télécom hérité du RTC. Dans le monde cablo on parle plutôt de head end (tête de réseau) - un nouveau sous-type pour t'occuper. Les NRO s'appellent l'un ou l'autre suivant la culture de son propriétaire... Alors, un central_office=* pouvant contenir des valeurs multiples (copper;optical;coaxial) ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
On 11/21/2013 12:41 AM, François Lacombe wrote: Noeud de Raccordement d'Abonnés = Subscriber Connection Node Noeud de Raccordement Optique = Optical Connection Node De nouveaux termes pour moi... Pas très populaire si j'en crois une brève recherche web. Méfiance. Répartiteur (optique comme cuivre) = Central Office et ceci est a l'intérieur d'un NRA ou NRO, donc à l'intérieur du bâtiment, *donc non concerné par OSM d'après nos précédents mails.* Stricto-sensu le répartiteur (main distribution frame) est l'énorme plat de spaghetti monté sur échafaud... Mais en jargon télécom, sa fonction étant la raison d'être originelle du lieu, le NRA est parfois abusivement appelé 'répartiteur' - appeler le NRA 'central office' est donc tout à fait correct et correspond d'après mon expérience nettement mieux à la pratique que 'Subscriber Connection Node' que je découvre aujourd'hui... Et l'appellation CO perdure même lorsque les technologies vont au-delà du cuivre. Avant que ca devienne trop tortueux, concentrons-nous vraiment sur les têtes de boucles locales avant toute entrée dans les détails (SR, chambres, PRM, ...) Armoires de rue aussi ! Hey - tout comme les chambres que je mentionnais précédemment, je dis ça en rigolant... Mais j'ai bien peur que certains s'y mettent. Pourquoi pas - c'est tout à fait possible et légal... J'étiquette bien les terrains de foot dans les villages Sénégalais... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le 20/11/2013 23:41, Christian Quest a écrit : Et la couche Limite admin FR est dispo: http://tile.openstreetmap.fr/?zoom=7lat=46.88903lon=2.36297layers=000BFFFTF Merci beaucoup. Petit exemple : Le nœud : http://www.openstreetmap.org/browse/node/365172724 est indiqué comme ayant un écart de 56m http://tile.openstreetmap.fr/?zoom=18lat=47.22638lon=5.95226layers=B000FFFTF Les cadastres des trois communes sont cohérents à moins d'un mètre sur ce point. Et OSM les suit. C'est donc IGN qui est fautif, il me semble. S'il y avait un petit retour à la osmose pour signaler les points vérifiés, corrigés, faux positifs... ce serait intéressant. Intéressant pour pouvoir affirmer la qualité d'OSM par rapport à... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
On 11/21/2013 01:15 AM, Jean-Marc Liotier wrote: Armoires de rue aussi ! Hey - tout comme les chambres que je mentionnais précédemment, je dis ça en rigolant... Mais j'ai bien peur que certains s'y mettent. Pourquoi pas - c'est tout à fait possible et légal... Pour les armoires de rue, je vois quand même une utilité: en milieu urbain dense je les trouve moches et encombrantes, surtout sur un trottoir étroit où passer à deux de front devient impossible lorsqu'il faut contourner ces machins qui accaparent un mètre carré de voie publique... Alors un outil pour les répertorier et faire prendre conscience de l'invasion serait le bienvenu. Hmmm - je sens les volontaires affluer ! Pour les amateurs, la traduction télécom consacrée de l'armoire de rue est 'pedestal' telecom=pedestal Qui ajoutera le premier ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
En attendant mieux, j'ai mis une liste sur la page du wiki... http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr#Couche_.22Limites_administratives_FR.22 J'ai aussi complété le rendu avec: - grisé sur les communes saisies, - nom et code INSEE sur le centroid - traits différents pour les limites de canton, d'arrondissements, de département, de région, de pays ou les limites côtières Cette couche est remise à jour quotidiennement vers minuit. Le 21 novembre 2013 01:16, Vincent Pottier vpott...@gmail.com a écrit : Le 20/11/2013 23:41, Christian Quest a écrit : Et la couche Limite admin FR est dispo: http://tile.openstreetmap.fr/? zoom=7lat=46.88903lon=2.36297layers=000BFFFTF Merci beaucoup. Petit exemple : Le nœud : http://www.openstreetmap.org/browse/node/365172724 est indiqué comme ayant un écart de 56m http://tile.openstreetmap.fr/?zoom=18lat=47.22638lon=5. 95226layers=B000FFFTF Les cadastres des trois communes sont cohérents à moins d'un mètre sur ce point. Et OSM les suit. C'est donc IGN qui est fautif, il me semble. S'il y avait un petit retour à la osmose pour signaler les points vérifiés, corrigés, faux positifs... ce serait intéressant. Intéressant pour pouvoir affirmer la qualité d'OSM par rapport à... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Vélo et OSM : GPX VTT vs GPX OSM
Bonjour, une visualisation intéressante à mon avis sur le sujet d'OSM et du vélo : Avec d'une part le site mapbox qui permet de visualiser les traces GPX importés dans OSM (ou une partie ?) http://www.mapbox.com/blog/openstreetmap-gps-layer/ et d'autre part le site vttrack.fr qui permet d'afficher les GPX importés par les utilisateurs de plusieurs sites très populaires de collectes de tracés de parcours VTT (ou vélo plus généralement ? ou une partie ? etc..) http://www.vttrack.fr/ On peut faire des comparatifs des survey GPS populaires dans OSM et des lieux populaires pour les VTTistes (cyclistes ?). Fatalement pour le premier point le cadastre brouille les pistes, etc, je me doute, mais le sujet est plutot la différence qu'on constate de visu : J'ai pris comme exemple l'est de Paris car Paris même et le rond d'Eurodisney m'a permis de faire un alignement rapide. Le site vttrack permet de mettre un fond OSM mais ici j'ai choisi le fond Google Physical qui est beaucoup moins contrasté, permettant de faire ressortir les tracés GPX plus nettement. http://gis.19327.n5.nabble.com/file/n5786580/osmvsvtt.jpg Et si l'insert ne marche pas : http://img15.hostingpics.net/pics/259317osmvsvtt.jpg http://img15.hostingpics.net/pics/259317osmvsvtt.jpg Si on parle en termes de lieux d'intérêts, on voit que ca se recouvre mal pour utiliser un euphémisme. En Ile de France en tout cas. A priori, j'en déduis que les GPX des cyclistes sont une bonne source potentielle de données complémentaires pour OSM. Et peut-être sous-estimée ? -- View this message in context: http://gis.19327.n5.nabble.com/Velo-et-OSM-GPX-VTT-vs-GPX-OSM-tp5786580.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
Avant d'utiliser des codes courts comme ref:42C qui sont susceptibles de rentrer en collision avec des codes internationaux issus d'une norme, on devrait être prudent et garder la convention fu préfixe ref:FR; car c'est une source purement franco-française qui ne doit pas gêner les autres. Donc ref:FR:42C si vous voulez, mais pas ref:42C (pour peu qu'une source ONU, Unesco, WTO, ITU, ou similaire) crée un document de référence 42C qui n'est pas du tout improbable). On limite les dégats en circonscrivant ce code à une région limitée du monde, la France. Le 21 novembre 2013 00:01, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Ce sont bien des codes longs étendus de 42C. Partons sur ref:42C, merci pour vos retours. Je créerai la page wiki demain. Une information qu'il serait utile d'ajouter, sans partir dans une modélisation détaillée : les types de média accueillis dans le bâtiment. Avec le développement de la fibre à domicile, des bâtiments n'hébergeant que des NRA (boucle locale cuivre) se sont vus accueillir des NRO (boucle locale optique) et ce tout opérateurs confondus. Des locaux ont aussi été créés de rien pour servir de NRO. Je ne sais pas si le terme central office convient pour parler d'un NRO. En espérant que si, pouvoir dire si on a un NRO, un NRA ou les deux dans une autre clé serait bien. Cela permet de rendre plus efficace la jointure avec des bases externes. Le reste des informations peut rester ensuite dans la base en question. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 20 novembre 2013 21:30, . ZZ29 zrozi...@gmail.com a écrit : Bonsoir, Je pense également qu'il serait intéressant de se passer de citer Orange ou FTdans le nom de l'attribut. A savoir que dans les documentations Orange ( http://www.orange.com/fr/innovation/reseaux/documentation Offre d'accès à la boucle locale d'Orangeliste des NRA d'Orange ) le code long est appelé CODE INSEE - NRA. Ma petite pierre... @+ ZZ29 Le 20 novembre 2013 19:53, Christian Quest cqu...@openstreetmap.fr a écrit : Et pourquoi pas: ref:42C=* ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] valeurs multiples
il y aurait bien la solution de: produce:1 = beef produce:2 = fowl je ne suis pas sûr que c'est mieux car on ne peut pas prédire le nom du tag à chercher parce qu'il n'y a pas d'ordre prédéfini. L'autre solution utilisée dans divers autres tags c'est produce:beef=yes produce:fowl=yes mais ça impose une charte de nommage des produits là où produce=* peut rester un champ libre admettant tout un tas de valeurs variantes (cas des produits alimentaires qui ont aussi de nombreuses dénominations de spécialités locales, certaines protégées), à moins qu'on mette dans la partie tag une catégorie de produit, et qu'on laisse alors leurs valeur libre (il n'y a qu'à convenir que le point-virgules les sépare, ce qui permet d'en adapter la présentation en liste). Les tags distincts c'est bien seulement si cela permet de faire des regroupements de catégories à peu près prédictibles et classables pour des filtres de requêtes efficaces (et pas non plus trop spécoifiques au point qu'on risque de ne rien trouver du tout en tout cas pas des produits qui ont des appellations locales spécifiques), pas pour des microcatégories quasiment spécifiques localement (bien que beef soit assez générique ici, j'en suis moins convaincu pour fowl). Le 20 novembre 2013 22:43, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Bonsoir, Le mercredi 20 novembre 2013 14:21:34 Pieren a écrit : Quelqu'un a posé la question des valeurs multiples il y a quelques mois sur la liste principale pour savoir si c'était finalement vraiment exploité ([1]). Celui qui a démarré la discussion en a fait un billet ([2]). J'adhère à sa conclusion qui est de dire qu'il n'y a aucune exploitation généralisée des valeurs multiples et que ça n'est vraiment utile que dans de rares cas. Il faudrait donc en général essayer de les éviter. Il n'y a peut-être pas d'exploitation généralisée pour l'instant, mais ne peut-on pas envisager que ce le devienne. J'essaye d'éviter de l'utiliser, mais j'ai un cas où je n'ai pas trouvé mieux, c'est pour les vente directes de produits fermiers, exemples : http://www.openstreetmap.org/browse/node/1865786378 http://www.openstreetmap.org/browse/node/1864170543 Si quelqu'un a une autre solution, je suis preneur :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vélo et OSM : GPX VTT vs GPX OSM
A priori, j'en déduis que les GPX des cyclistes sont une bonne source potentielle de données complémentaires pour OSM. Et peut-être sous-estimée ? On l'a déjà évoqué quelques fois. Et de mon expérience autour de Grenoble, je confirme que ça serait intéressant pour les sentiers entre autre. Néanmoins, il faudrait que ces données soient disponibles dans une licence compatible avec OSM. -- Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le jeudi 21 novembre 2013 01:26:54 Christian Quest a écrit : En attendant mieux, j'ai mis une liste sur la page du wiki... http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr#Couche_. 22Limites_administratives_FR.22 J'ai aussi complété le rendu avec: - grisé sur les communes saisies, - nom et code INSEE sur le centroid - traits différents pour les limites de canton, d'arrondissements, de département, de région, de pays ou les limites côtières Cette couche est remise à jour quotidiennement vers minuit. C'est de l'art mon cher ! :-) Franchement, c'est beau. Et en plus c'est pratique. Merci -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
Le jeudi 21 novembre 2013 01:26:54 Christian Quest a écrit : En attendant mieux, j'ai mis une liste sur la page du wiki... http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr#Couche_. 22Limites_administratives_FR.22 J'ai aussi complété le rendu avec: - grisé sur les communes saisies, - nom et code INSEE sur le centroid - traits différents pour les limites de canton, d'arrondissements, de département, de région, de pays ou les limites côtières Au fait, c'est quoi l'échelle de couleur ? Et pourquoi chez moi (Clermont-Ferrand), au zoom 11 tous points passent en violet ? -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé des limites communales normandes terminé
À vue de nez, je dirais : * vert : = 10m * jaune : = 20m * orange : =50m * rouge : 50m * bleu/violet : problème de jointure (différence entre les jointures selon OSM et selon route500) Le 21 novembre 2013 08:33, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le jeudi 21 novembre 2013 01:26:54 Christian Quest a écrit : En attendant mieux, j'ai mis une liste sur la page du wiki... http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr#Couche_ . 22Limites_administratives_FR.22 J'ai aussi complété le rendu avec: - grisé sur les communes saisies, - nom et code INSEE sur le centroid - traits différents pour les limites de canton, d'arrondissements, de département, de région, de pays ou les limites côtières Au fait, c'est quoi l'échelle de couleur ? Et pourquoi chez moi (Clermont-Ferrand), au zoom 11 tous points passent en violet ? -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Centraux téléphoniques
Le 21/11/2013 02:48, Philippe Verdy a écrit : Avant d'utiliser des codes courts comme ref:42C qui sont susceptibles de rentrer en collision avec des codes internationaux issus d'une norme, on devrait être prudent et garder la convention fu préfixe ref:FR; car c'est une source purement franco-française qui ne doit pas gêner les autres. Donc ref:FR:42C si vous voulez, mais pas ref:42C (pour peu qu'une source ONU, Unesco, WTO, ITU, ou similaire) crée un document de référence 42C qui n'est pas du tout improbable). On limite les dégats en circonscrivant ce code à une région limitée du monde, la France. +1 -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
