Re: [OSM-talk-fr] pourquoi un hébergementséparé?
c'était une réponse à http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.fr/53000 (je ne connais pas encore le maniement de gmane! ce n'est que mon 2d msg) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hébergement d'une carte glissante
voir http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.fr/56620 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses donnés?)
Salut, je confirme que c'est parfois n'importe quoi (au sud-est de Parthenay, le tronçon d'identifiant 6940 ne correspond à rien sur le terrain, on dirait que ça vient d'une carte au 1/1 000 000 ;-) ) Bref, pas utilisable en l'état à mon avis, faut que les fourmis reprennent les tracés... Cordialement, Mika_Gueret Le dimanche 31 mars 2013 à 14:55 -0700, PierreV a écrit : impossible que ce soit la projection, car a la grande majorité l'écart est d'une dizaine de metres en moyennes, mais par certains endroits cela peut monter a plus d'une centaine de metres! Peut être que les informations collectées en Deux-Sevres n'ont pas été faites sérieusement? mais je suis sur a 100% que c'est pas a cause de la projection! Par contre pour la licence, pourquoi en discutant on nous dit que c'est compatible avec ODBL ou LO/OL mais avoir pris une autre type de licence en ayant changé un paragraphe litigieux? il y a un loup quelque part? ce qui me fait dire que c'est pas compatible odbl? Dernièrement l'avantage de pouvoir etre importé dans OSM c'est que ON3V pourrait améliorer grandement la précision de leurs données! C'est dommage de ne pas vouloir faciliter notre travail d'importation, qui pourrait leur servir a enrichir leur propre base de donnée en extrayant les trajets plus précis depuis OSM! -- View this message in context: http://gis.19327.n5.nabble.com/L-ON3V-libere-ses-donnees-tp5709492p5755371.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses donnés?)
2013/3/31 Romain MEHUT romain.me...@gmail.com Selon lui, la clause de non altération n'est pas incompatible avec une intégration dans OSM puisque celle-ci aura pour objectif d'améliorer la donnée initiale. Ca, ça pourrait entrer dans les FR:Fortunes: http://wiki.openstreetmap.org/wiki/FR:Fortunes Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] chemins pour vtt mais pas vélos tradi
Salut Je reporte des chemins de campagne assez coriaces en ce moment ;-) Sur le terrain, je les parcours à vtt. Dans josm : - Attributs - Routes - Chemins - chemin - et là je note « piétons » et « cavalier », j'ajoute un niveau vtt (0 à 2 par chez moi) mais je n'ose pas mettre « vélo » car pour un vélo classique c'est impraticable, impossible. Certains chemins ont de l'eau presqu'au niveau des moyeux des roues en ce cette période. Comment procédez-vous ? nono -- C'est en voyant Chuck Norris que les parents d'E.T se sont barrés en vitesse de la terre ! signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] landuse pour un champ captant ?
Le dim. 31 mars 2013 à 17:10 +0200, Guillaume Allegre a écrit : Salut, je me demande quel tag utiliser pour définir un champ captant (captage d'eau potable). Généralement, c'est une zone cloturée, avec de l'herbe, plus ou moins bien entretenue (souvent plus), où sont disséminés des forages et installations de pompage (bâtiments techniques, pompes, transfos électriques...) http://fr.wikipedia.org/wiki/Champ_captant http://fr.wikipedia.org/wiki/Captage_d%27eau_potable Je suppose que landuse s'impose, mais quoi mettre derrière ? water_catchment semble parfois utilisé mais je n'ai pas trouvé de terme anglais vraiment convaincant pour l'instant. En cherchant mieux, j'ai trouvé le tag man_made=water_works http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_works La description semble convenir (Place where drinking water is found and applied to the local waterpipes network.) Mais la photo et le tag man_made semblent plus adaptés à des installations compactes : assez petite surface, installations denses. Du coup, est-ce que vous l'utiliseriez pour un champ captant, qui peut être très étendu, comparable à un grand champ agricole ? -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] landuse pour un champ captant ?
Salut, je me demande quel tag utiliser pour définir un champ captant (captage d'eau potable). Généralement, c'est une zone cloturée, avec de l'herbe, plus ou moins bien entretenue (souvent plus), où sont disséminés des forages et installations de pompage (bâtiments techniques, pompes, transfos électriques...) http://fr.wikipedia.org/wiki/Champ_captant http://fr.wikipedia.org/wiki/Captage_d%27eau_potable Je suppose que landuse s'impose, mais quoi mettre derrière ? water_catchment semble parfois utilisé mais je n'ai pas trouvé de terme anglais vraiment convaincant pour l'instant. http://www.openstreetmap.org/?lat=51.21092lon=6.60191zoom=17 et voir aussi sous W, les mots qui commencent par Wasser: http://wiki.openstreetmap.org/wiki/DE:How_to_map_a#W Guillaume Allegre allegre.guillaume@... writes: ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Osm, wikivoyage et license
Bonjour la foule! Je contribue à Wikivoyage (vous savez, le fork de Wikitravel) en traduisant des articles d'anglais à français. Et je voudrais en profiter pour enrichir les points d’intérêt avec des coordonnées. Et c'est là que ce pose la question toujours délicate de la compatibilité des licences. Dans ce cas, je me demande si c'est possible d'utiliser des coordonnées OSM dans des projets Mediawiki (sous CC-by-sa). Je sais que l'inverse n'est pas possible. Dans mon cas, ce serait de manière répétée mais pas automatisée (je pensais prendre manuellement les coordonnées approximatives sur osm.org). Avez-vous une idée là-dessus? Fabien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses donnés?)
Le 31/03/2013 12:15, Pieren a écrit : 2013/3/30 Brice Person brice.per...@zenordi.fr mailto:brice.per...@zenordi.fr C'est la conclusion que nous avions eu à l'époque de sa sortie. De plus, il ne faut pas confondre la licence de l'APIE avec celle du ministère de la justice (bravo l'APIE) voir : http://www.regardscitoyens.org/licences-opendata-lapie-grille-la-priorite-a-etalab-et-invente-le-pseudo-libre/ Tout cela est bien dommage car il semble que DRC soit de très bonne volonté. A noter que Corine Land Cover de l'ifen était disponible dans une license similaire avec une clause de non-altération. Il suffit de s'adresser à eux en leur demandant si on peut importer leurs données dans OSM en les informant clairement qu'on ne pourra pas garantir la non-altération. On peut aller au delà de cette clause si on reçoit une autorisation spécifique (qu'il faut rendre publique et archivée, évidemment). Pieren Je regrette mais le cas du Corine Land Cover serait plutôt emblématique de ce qu'il ne faut pas faire. Si on suit la logique jusqu'au bout il n'aurait pas du être importé... (heureusement sa dernière version est désormais disponible en by [1]). Si le projet OSM ne faisait que réutiliser les données ça irait mais il redistribue aussi les données. Demander des autorisations spécifiques, d'une manière générale, me parait inapproprié lorsqu'on est pas de simples ré-utilisateurs finaux. Les données convoitées ne peuvent qu'être sous une licence compatible ou dans le domaine public sinon on fait reposer le risque sur le ré-utilisateur d'OSM. D'ailleurs si on fait reposer le risque sur le ré-utilisateur d'OSM, qu'est ce qui empêche celui ci à son tour de se retourner contre OSM si lui même a eu des ennuis ? A part la mauvaise pub ;-) Bref je ne sais pas vous mais pour moi ça fait un peu trop d'incertitudes. Pour revenir à DRC, si quelqu'un veut battre le fer tant qu'il est chaud, il vaudrait mieux leur pointer que les administrations ayant choisi cette licence avaient été mal conseillées à l'époque et ont du corriger le tir par la suite [2] (l'OpenData c'est encore nouveau pour plein de gens, juristes compris). Brice [1] http://www.eea.europa.eu/data-and-maps/data/clc-2006-vector-data-version-2 [2] http://www.lagazettedescommunes.com/151375/open-data-la-cu-de-bordeaux-change-de-licence-esperant-ainsi-generer-des-emplois/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)
Je constate que le serveur crée un nouveau groupe de modification avec une heure de début correcte mais exactement en même temps une date de fin une heure exactement après. Conséquence: le groupe de modifications s'ouvre mais ensuite plus aucune réponse du serveur qui ne prends pas en compte les données qu'on veut envoyer. On se retrouve avec un groupe de modifications vide (mais en fait pas fermé dans le serveur (CTRL+ALT+Q liste le roupe de modifs comme ouvert). Impossible de mettre un nouveau noeud, un chemin ou la moindre modif dedans. Cela ressemble à un problème de passage à l'heure d'été depuis ce week-end avec un des serveurs concernés qui provoque une incohérence dans les modifications... Ou un mauvais paramétrage du serveur qui vient d'être réparé hier après une panne de près d'une journée. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)
Apparemment le problème est dans la base de données SQL elle-même : les envois de noeuds ou de chemins fonctionnent, mais pas les modifs de listes de membres de certaines relations. (le serveur SQL semble ne plus répondre ni pouvoir accéder à une partie de sa table SQL interne). Bref une panne à nouveau à prévoir assez vite, et un nouvel arrêt en perspective pour réparer. Note: l'ouverture d'un groupe de modifs indique l'heure d'hiver alors que la date de dernières données envoyées dans un groupe de modifs ou de fermeture de ce groupe affiche l'heure d'été. Cela semble n'être qu'un bogue de conversion des dates du côté affichage sur le front-end du web, sans autre conséquence. Le 1 avril 2013 17:33, Philippe Verdy verd...@wanadoo.fr a écrit : Je constate que le serveur crée un nouveau groupe de modification avec une heure de début correcte mais exactement en même temps une date de fin une heure exactement après. Conséquence: le groupe de modifications s'ouvre mais ensuite plus aucune réponse du serveur qui ne prends pas en compte les données qu'on veut envoyer. On se retrouve avec un groupe de modifications vide (mais en fait pas fermé dans le serveur (CTRL+ALT+Q liste le roupe de modifs comme ouvert). Impossible de mettre un nouveau noeud, un chemin ou la moindre modif dedans. Cela ressemble à un problème de passage à l'heure d'été depuis ce week-end avec un des serveurs concernés qui provoque une incohérence dans les modifications... Ou un mauvais paramétrage du serveur qui vient d'être réparé hier après une panne de près d'une journée. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)
Et ça continue: POST http://api.openstreetmap.fr/api/0.6/changeset/15569811/upload... Internal Server Error org.openstreetmap.josm.io.OsmTransferCanceledException Le 1 avril 2013 18:05, Philippe Verdy verd...@wanadoo.fr a écrit : Apparemment le problème est dans la base de données SQL elle-même : les envois de noeuds ou de chemins fonctionnent, mais pas les modifs de listes de membres de certaines relations. (le serveur SQL semble ne plus répondre ni pouvoir accéder à une partie de sa table SQL interne). Bref une panne à nouveau à prévoir assez vite, et un nouvel arrêt en perspective pour réparer. Note: l'ouverture d'un groupe de modifs indique l'heure d'hiver alors que la date de dernières données envoyées dans un groupe de modifs ou de fermeture de ce groupe affiche l'heure d'été. Cela semble n'être qu'un bogue de conversion des dates du côté affichage sur le front-end du web, sans autre conséquence. Le 1 avril 2013 17:33, Philippe Verdy verd...@wanadoo.fr a écrit : Je constate que le serveur crée un nouveau groupe de modification avec une heure de début correcte mais exactement en même temps une date de fin une heure exactement après. Conséquence: le groupe de modifications s'ouvre mais ensuite plus aucune réponse du serveur qui ne prends pas en compte les données qu'on veut envoyer. On se retrouve avec un groupe de modifications vide (mais en fait pas fermé dans le serveur (CTRL+ALT+Q liste le roupe de modifs comme ouvert). Impossible de mettre un nouveau noeud, un chemin ou la moindre modif dedans. Cela ressemble à un problème de passage à l'heure d'été depuis ce week-end avec un des serveurs concernés qui provoque une incohérence dans les modifications... Ou un mauvais paramétrage du serveur qui vient d'être réparé hier après une panne de près d'une journée. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)
On a aussi un lag brutalement important du côté des services NTP (bon brutal de +25 minutes). Et des exceptions MSR en pagaille, un CPU usage qui est maintenant saturé à quasiment 100% en continu. Un fork rate a un débit très élevé aussi depuis près d'une heure et des milliers de recréation de nouveaux threads. Une anomalie aussi avec un pic de surtension sur une des alims 5 volts d'un des serveurs (pic à près de 11 volts). On dirait que c'est une alim qui lâche. Le 1 avril 2013 18:07, Philippe Verdy verd...@wanadoo.fr a écrit : Et ça continue: POST http://api.openstreetmap.fr/api/0.6/changeset/15569811/upload... Internal Server Error org.openstreetmap.josm.io.OsmTransferCanceledException Le 1 avril 2013 18:05, Philippe Verdy verd...@wanadoo.fr a écrit : Apparemment le problème est dans la base de données SQL elle-même : les envois de noeuds ou de chemins fonctionnent, mais pas les modifs de listes de membres de certaines relations. (le serveur SQL semble ne plus répondre ni pouvoir accéder à une partie de sa table SQL interne). Bref une panne à nouveau à prévoir assez vite, et un nouvel arrêt en perspective pour réparer. Note: l'ouverture d'un groupe de modifs indique l'heure d'hiver alors que la date de dernières données envoyées dans un groupe de modifs ou de fermeture de ce groupe affiche l'heure d'été. Cela semble n'être qu'un bogue de conversion des dates du côté affichage sur le front-end du web, sans autre conséquence. Le 1 avril 2013 17:33, Philippe Verdy verd...@wanadoo.fr a écrit : Je constate que le serveur crée un nouveau groupe de modification avec une heure de début correcte mais exactement en même temps une date de fin une heure exactement après. Conséquence: le groupe de modifications s'ouvre mais ensuite plus aucune réponse du serveur qui ne prends pas en compte les données qu'on veut envoyer. On se retrouve avec un groupe de modifications vide (mais en fait pas fermé dans le serveur (CTRL+ALT+Q liste le roupe de modifs comme ouvert). Impossible de mettre un nouveau noeud, un chemin ou la moindre modif dedans. Cela ressemble à un problème de passage à l'heure d'été depuis ce week-end avec un des serveurs concernés qui provoque une incohérence dans les modifications... Ou un mauvais paramétrage du serveur qui vient d'être réparé hier après une panne de près d'une journée. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Bonjour à tous On en avait déjà parlé avec Tony dès ses premières expérimentations. Pour tous ces cas là, je préférerais largement qu'une base de données externe s'occupe de gérer les liens entre identifiants. J'imagine un outil, qu'on pourrait appeler OsmLink (ou mieux), qui centraliserait l'ensemble de tous les liens entre identifiants, avec un schéma assez classique en base de donnée : Objet OSM (osm_id) --- OsmLink (osm_id, osm_type, id_table_externe, id_objet_externe ) - Table externe ( id_objet_externe) L'idée est de stocker le lien entre identifiants dans la table de lien, et ni dans OSM ni dans notre table métier. Ainsi on ne pollue ni notre table métier, ni notre table de lien, et cela permet * de gérer autant de liens qu'on veut. * de gérer les problèmes levés par Tony : on peut lier plusieurs osm_id à un objet métier et non faire comme fait actuellement Je prends l'osm_id le plus petit de la route * de gérer autant de tables externes que souhaité : la base de donnée OsmLink serait alors un immense creuset de lien, qui serait administrée (et pourquoi pas versionnée aussi) comme la bdd OSM, avec une union des forces Bien sûr il faut créer/inventer/adapter des outils pour répondre aux questions du type Que se passe-t-il si on supprime un objet d'OSM ?, Comment créer le lien, etc.. Mais je pense qu'avec ce système, c'est beaucoup plus simple de lister les liens qui sont orphelins d'un côté ou de l'autre, et de créer ou adapter des applications (OsmWatch, etc.) Bref, c'est un projet pas trop compliqué au niveau technique, il suffit de se poser les bonnes questions et de mettre un premier prototype sur Github. Je vois bien une interface graphique comme OsmFlickr, avec une carte, pour créer facilement le lien entre mon tableau métier et des objets OSM. Ce projet me tient à coeur depuis qu'on en a parlé avec Tony, mais je n'ai toujours pas trouvé le temps ou les moyens de m'y mettre... Michael ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
N'est-ce pas la même chose que les tags ref:*=* actuels ? Sauf qu'il suffirait de définiir une convention de nommage plus strict pour ces ref:*=* (et éviter l'utilisation d'autres tags ne commençant pas par ref: tels que les CLC_ID).. Même dans une table séparée (ou une base séparée, ce qui ne change pas grand chose topologiquement parlant, sauf que l'intégrité référentielle n'est plus assurée entre les identifiants OSM et la base séparée), on n'évitera pas une convention de nommage identique pour les clés (à ceci près qu'il n'y a plus besoin alors de mettre le préfixe ref: dans le nom de la clé : le problème est donc identique. Si on utilise une table séparée de celle des tags, il faut alors modifier le schéma XML des objets : c'est vaile pour les ways et relations, mais cela va surcharger beaucoup pour référencer les noeuds. L'intérêt toutefois serait de pouvoir télécharger les données OSM sans avoir besoin de charger toutes les ref:* externes en tant que tags. Cela peut se faire par un filtre de téléchargement précisant les types de clés ref:* qu'on veut voir ou mettre à jour. Mais je ne suis pas convaincu que cela apporte beaucoup de choses. Plus utile toutefois serait de pouvoir ajuoter des métadonnées suppélementaires pour certaines applications. Mais là encore c'est soluble par une convention de classification entre les tags pouvant être supporté par une convention de nommage des préfixes de clés. Mais c'est là que cela devient intéressant : les préfixes à force de se cumuler partout vont s'allonger et il faut les répéter pour tous les tags de l'application métier, là où il suffirait d'avoir un seul objet regroupant divers attributs et ayant leur propre id pour les regrouper, et les référencer depuis un objet géographique. Mais là on parle alors de développer une véritable topologie de types d'objets avec des classes et sous-classes, les objets étant alors un peu similaires aux objets javascript dans leur extensibilité et leur flexibilité (mais avec sans doute un contrôle de typage plus strict : qui voudra développer un système permettant de décrire un schéma d'objets typés sous forme de hiérarchie de classes et sous-classes et avec un contrôle des valeurs autorisées ou obligatoirement renseignées ? Et pourra-t-on créer un même objet qui référencera d'autres objets (pas seulement le sous-classement hoérarchique des types, mais aussi l'inclusion, les listes ordonnées ou ensembles non ordonnés, bornés en taille ou pas ??? Est-ce qu'on ne s'éloigne pas trop d'une base géographique ? Il me semble plus urgent de renforcer les conventions de nommage des clés de tags et leur documentation pour les listes de valeurs permises, et les outils automatiques pour des contrôles et des corrections plus aisées et plus rapides. Si le problème est la multiplication du nombre de tags par objet OSM, des filtres pour le téléchargement pourraient être développés pour éviter d'avoir à tous les charger. Cela peut se faire en ajoutant dans la base une table de description et de classification des clés de tags sous forme de collections de clés organisées de façon hiérarchique : on télécharge alors les clés d'une collection donnée, plus celles de la collection par défaut (pour compatibiité avec les clés existantes qui ne sont pas encore décrites dans une collection). Le 1 avril 2013 20:08, kimaidou kimai...@gmail.com a écrit : Bonjour à tous On en avait déjà parlé avec Tony dès ses premières expérimentations. Pour tous ces cas là, je préférerais largement qu'une base de données externe s'occupe de gérer les liens entre identifiants. J'imagine un outil, qu'on pourrait appeler OsmLink (ou mieux), qui centraliserait l'ensemble de tous les liens entre identifiants, avec un schéma assez classique en base de donnée : Objet OSM (osm_id) --- OsmLink (osm_id, osm_type, id_table_externe, id_objet_externe ) - Table externe ( id_objet_externe) L'idée est de stocker le lien entre identifiants dans la table de lien, et ni dans OSM ni dans notre table métier. Ainsi on ne pollue ni notre table métier, ni notre table de lien, et cela permet * de gérer autant de liens qu'on veut. * de gérer les problèmes levés par Tony : on peut lier plusieurs osm_id à un objet métier et non faire comme fait actuellement Je prends l'osm_id le plus petit de la route * de gérer autant de tables externes que souhaité : la base de donnée OsmLink serait alors un immense creuset de lien, qui serait administrée (et pourquoi pas versionnée aussi) comme la bdd OSM, avec une union des forces Bien sûr il faut créer/inventer/adapter des outils pour répondre aux questions du type Que se passe-t-il si on supprime un objet d'OSM ?, Comment créer le lien, etc.. Mais je pense qu'avec ce système, c'est beaucoup plus simple de lister les liens qui sont orphelins d'un côté ou de l'autre, et de créer ou adapter des applications (OsmWatch, etc.) Bref, c'est un projet pas trop compliqué au niveau technique, il suffit de se poser les
Re: [OSM-talk-fr] landuse pour un champ captant ?
Dans cette proposition http://wiki.openstreetmap.org/wiki/Proposed_features/water_network , on trouve boundary=water_protection_area . Dans boundary on voit aussi que protected_area peut s'appliquer au zone de captage. Reste a voir si ces propositions sont utilisé ou pas. Le 1 avril 2013 15:58, oui o...@mailoo.org a écrit : Salut, je me demande quel tag utiliser pour définir un champ captant (captage d'eau potable). Généralement, c'est une zone cloturée, avec de l'herbe, plus ou moins bien entretenue (souvent plus), où sont disséminés des forages et installations de pompage (bâtiments techniques, pompes, transfos électriques...) http://fr.wikipedia.org/wiki/Champ_captant http://fr.wikipedia.org/wiki/Captage_d%27eau_potable Je suppose que landuse s'impose, mais quoi mettre derrière ? water_catchment semble parfois utilisé mais je n'ai pas trouvé de terme anglais vraiment convaincant pour l'instant. http://www.openstreetmap.org/?lat=51.21092lon=6.60191zoom=17 et voir aussi sous W, les mots qui commencent par Wasser: http://wiki.openstreetmap.org/wiki/DE:How_to_map_a#W Guillaume Allegre allegre.guillaume@... writes: ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] pourquoi un hébergementséparé?
Am 01.04.2013 01:12, schrieb oui: Pourquoi un hébergement séparé alors qu'OSM est un hébergement satisfaisant? voir ici un exemple: http://www.wanderreitkarte.de/index.php?lon=2.8845lat=42.6954zoom=16 1) cela EST un hébergement séparé 2) sur cette carte il n'y a ni les bandes cyclables (séparés par un simple trait blanc sur la chaussée), ni les double-sens cyclistes, ni les parkings à vélo, ni les stations de location de vélo. http://velocarte66.fr/ Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
