Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

Le 23 août 2017 à 00:12, marc marc  a écrit :

> Le 22. 08. 17 à 22:58, François Lacombe a écrit :
> > il est vrai que la proposition concerne aussi le tag flow_capacity
> > capacity:flow je trouve flow assez générique. vois-tu un autre tag
> avec
> > flow possible ? parce que sinon c'est un peu l'inverse de type, ce
> serra
> > un tag tellement précis qu'il n'existe qu'avec capacity et dans ce
> cas
> > flow_capacity serrait tout aussi bien.
> > Si t'as un exemple d'autre "flow", je me rangerai à ton avis.
> > Je suis ok pour dire que ce n'est que de la forme et je n'ai pas trouvé
> > d'autre clé qui puisse aller avec flow.
> j'ai trouvé ton sauveur :) il y a bien capacity:disabled alors qu'il n'y
> pas d'autre clef :disabled
>

Il y a aussi sur la page du wiki :parent qui selon taginfo est seul (il y a
des :parent mais dans le sens de l'ascendance et pas du rôle de
parent/enfants)

capacity:flow va aussi servir pour les pipelines (en remplacement du
"free-text" capacity pour l'instant) et des choses comme waterway=drain et
tunnel=culvert
Il y a les prises d'eau en rivière aussi, il y a vraiment plein de cas
d'utilisation.


> alors pourquoi pas capacity:flow si tu penses que c'est utile.
> cela m’embête un peu parce que je trouve ennuyeux qu'on casse l'unicité
> de l'unité par défaut de capacity (nombre sans unité).
> mais vas-y si tu penses que capacity:flow est bien mieux que flow_capacity
>

Je pense aussi que si la situation est celle-ci aujourd'hui, c'est que le
cas ne s'est pas présenté.
Connaitre le dimensionnement d'une infrastructure est pas si facile que ca
et en dehors des places de parking ou de lit d'hotel, ce n'est pas ce qui
intéresse en premier.
Et il y a bien une unité à toutes ces grandeurs. Elles n'ont par contre pas
de dimension (un detail ce dernier point, j'ai compris ce que tu voulais
dire).
Au niveau industriel, c'est hyper intéressant pourtant et ca place OSM loin
loin devant toute l'opendata que les acteurs intéressés peuvent aujourd'hui
produire.


> > pourquoi rajouter un nouveau tag à discuter ?
> > la proposition ne touche pas à ce tag
> > Parce que c'est dans le sujet traité et que le temps manque aussi.
> Je n'ai pas compris. niveau temps, il vaut mieux circonscrire la
> proposition au lieu de l'étendre chaque semaine, non ?
>

Non, c'est qu'en ce moment nous y consacrons tous du temps, autant en tirer
un maximum de profit (de tag, de cas décris et connus,...)
Plus tard, nous aurons peut-etre tous autre chose à faire, c'est dans ce
sens là que je l'entendais

J'ai ça à faire voter également bientôt quand j'aurais fini les dernier
réglages
https://wiki.openstreetmap.org/wiki/Proposed_features/Transformer_extension_proposal

François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[marc marc]

Le 22. 08. 17 à 22:58, François Lacombe a écrit :
> il est vrai que la proposition concerne aussi le tag flow_capacity
> capacity:flow je trouve flow assez générique. vois-tu un autre tag avec
> flow possible ? parce que sinon c'est un peu l'inverse de type, ce serra
> un tag tellement précis qu'il n'existe qu'avec capacity et dans ce cas
> flow_capacity serrait tout aussi bien.
> Si t'as un exemple d'autre "flow", je me rangerai à ton avis.
> Je suis ok pour dire que ce n'est que de la forme et je n'ai pas trouvé 
> d'autre clé qui puisse aller avec flow.
j'ai trouvé ton sauveur :) il y a bien capacity:disabled alors qu'il n'y 
pas d'autre clef :disabled
alors pourquoi pas capacity:flow si tu penses que c'est utile.
cela m’embête un peu parce que je trouve ennuyeux qu'on casse l'unicité 
de l'unité par défaut de capacity (nombre sans unité).
mais vas-y si tu penses que capacity:flow est bien mieux que flow_capacity

> pourquoi rajouter un nouveau tag à discuter ? 
> la proposition ne touche pas à ce tag
> Parce que c'est dans le sujet traité et que le temps manque aussi.
Je n'ai pas compris. niveau temps, il vaut mieux circonscrire la 
proposition au lieu de l'étendre chaque semaine, non ?
mais si tu penses qu'il faut rajouter les capacités de connexion pour 
faire passer par cohérence les capacités de débit, vas-y
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

[Christian Rogel]

> Le 2017 Eost 22 à 17:44, Jean-Marc Liotier  a écrit :
> 
> On Tue, 22 Aug 2017 14:21:00 +
> marc marc  wrote:
>> 
>> pour rebondir sur ton exemple, 16 ml locales, quasi + que d'actif.
>> un paquet n'a pas eu de message cette année, une partie est à 1/mois
>> n'est-on pas allez trop loin ? 5 ne serraient-ils pas suffisant ?
> 
> Une partie de ces listes sont en pratique plutôt des canaux de diffusion
> d'annonces et non des lieux de discussion - la spécificité nationale
> est donc peut-être importante, malgré l'apparence d'insignifiance.
> J'ignore si les abonnés en sont satisfaits.


Personnellement, je n’ai jamais compris pourquoi les mappeurs geeks français 
(ils se reconnaîtront) ont mis un point d’honneur à créer leurs micro-ML 
ultra-locales sur des protocoles improbables au lieu de les faire héberger par 
la Fondation et bénéficier de plus de visibilité.
En Bretagne, nous avons pensé que le plus simple et le plus évident était de ne 
pas se montrer séparatiste (;-) ) et, grâce à Émilie, Steven LR a créé, en 
2009, la ML OSM en Bretagne qui figure dans les tablettes de notre organisme de 
référence.
Son trafic est, en moyenne, autour du message/jour et c’est très bien ainsi.
Cela peut tenir à une bonne dimension géographique. Pourquoi une ML à Grenoble 
et une autre à Lyon ? N’a-t’on pas ,mis sur la touche Privas, Thonon et Nyons ? 
ou même, soyons hardis, Saint-Étienne ?  ;-)


Christian R.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSM à la plage;-) - rendu des côtes osm et osm-fr

[Philippe Verdy]

Le 22 août 2017 à 22:41,  a écrit :

> *Philippe, je parlait de la couleur de la Vilaine, au niveau du tuyau
> surmonté d'une surface gravillonnée, j'ai du mal à penser à de belles
> vallées à côté*.
>
Pas besoin de sortir de Rennes pour retrouver une couleur d'eau correcte.
L'Ille apporte une assez belle eau juste au confluent de la Place de
Bretagne et l'Ille (canalisée sur sa plus grande partie avale) est très
prisée par les balades. L'Ille et le canal sont l'objet d'une protection
reconnue depuis longtemps, et on y pratique les sports nautiques toute
l'année (avec un club connu avec pleins de champions à Saint-Grégoire : on
peut y aller aussi à pied depuis Rennes, j'y ai fait du kayak pendant deux
décennies, et c'était pourtant bien avant qu'on commence à mieux traiter
les eaux de la Vilaine à Rennes et éviter les rejets d'égouts directs dans
la Vilaine en notamment centre-ville et la ZI de Chantepie, à
Cesson-Sévigné et à Noyal-sur-Vilaine).

Et toujours dans Rennes les étangs d'Apigné en aval du confluent sont aussi
un lieu de balade qui renaissent (ces étangs, d'anciennes carrières, sont
un espace de décantation et filtrage rendant au cours un peu plus de
clarté). Des efforts sont faits aussi pour améliorer l'eau de la Vilaine en
amont, notamment par le traitement des eaux usées Il y a eu de gros travaux
vers Cesson-Sévigné et Noyal-sur-Vilaine, et d'autres bassins et étangs de
retenue et de décantation sont là (ils ne servent pas qu'à dépolluer mais
aussi à prévenir les inondations à Rennes.

L'eau de la Vilaine est claire dans la zone du Boël à Bruz (célèbre balade
dans la métropole rennaise). Lieu reconquis pour les pêcheurs à la ligne
qui avant devaient se contenter de l'Ille en amont de Rennes à
Saint-Grégoire et pas beaucoup plus bas.

D'autres travaux sont encore nécessaires pour prévenir plus au sud les
inondations dans le goulet de Redon, par la création d'autres bassins de
retenue en amont de Redon (et notamment sur l'Oust et dans la gestion des
eaux du canal de Nantes à Brest du côté de Glénac).

Ensuite sur la frontière entre Loire-Atlantique et Morbihan, pas grand
chose a été fait, le cours est assez large pour absorber la plupart des
crues, et il n'y a pas beaucoup d'activité humaine hormis près de
l'estuaire (mais c'est un fait que la vilaine a causé des problèmes à la
qualité de l'eau sur la grande plage de La Baule, mais la Vilaine n'était
pas seule en cause, la Loire aussi pouvant selon les marées apporter ses
propres pollutions). En entrant complètement dans le Morbihan la Vilaine
passe par une zone de marais très plane, avec un écoulement très lent
(c'est le problème justement qui provoque les inondations à Redon) ; quand
le cours atteint La Roche-Bernard, il est assagi avec peu de crues, et
beaucoup plus propre qu'il ne l'était (là la vilaine était sensible aux
marées et la salinification des marais avant le construction du barrage
d'Arzal qui protège et maintient en eau les ports d'Arzal, Camoël et la
Roche-Bernard, mais surtout évite l'amplification des crues en amont).

Mais la petite ville de la Roche-Bernard a aussi amélioré son traitement
des eaux  (ce qui a été bénéfique pour la propreté des eaux des plages de
Damgan dans le Morbihan, mais aussi des marais salants classés de
Guérande): cette baie de Vilaine est cernée de parcs naturels sur le
continent, et protégée des courants Atlantiques par Quiberon, Belle-Île et
le flux d'eau douce venant de la Loire, l'eau douce de la Vilaine et des se
répand en surface dans la baie et touche ses plages continentales plus que
ne le fait l'eau atlantique plus dense, et la marée remue plus l'eau douce
qu'elle ne ramène d'eaux atlantiques. Le vent d'ouest tend aussi à étaler
les eaux fluviales le long des côtes continentales au plus près des plages,
mais protège Belle-Île, Quiberon et le Golfe du Morbihan.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] ligne de bus : tag network

[marc marc]

Le 22/08/2017 à 21:47, Noémie Lehuby a écrit :
 > On veut indiquer que les lignes (relations route_master)
 > et les parcours (relation route) appartiennent à un réseau.
 > On peut donc :
 > 1) mettre le nom du réseau sur les relations : tag network =
 > TransHauteGaronne
 > 2) mettre un identifiant quelconque de réseau sur les relations :
 > tag network : fr_arc_en_ciel
 > 3) mettre un identifiant wikidata sur les relations :
 > tag network:wikidata = Q-whatever
 > 4) regrouper les relations dans une relation network TransHauteGaronne

 > Je n'ai rien contre 3 et 4 tant qu'on les combine avec 1.
 > La seule qui m'embête c'est la 2. Car elle crée une ambiguité sur ce
 >> qu'on trouve dans le tag network.
 >> A minima, mettons un tag network_id mais pas network.
très bon résumé

mais au lieu de créer un nouveau tag,
- ne pourrait-on pas utiliser network:wikidata s'il existe
- et pour ceux qui n'en ont pas, suivre la logique du tag ref avec 
quelque chose genre network:ref ou ref:FR:network:bus ?
Ou si c'est plus pratique une seule clef pour les 2 cas,
on crée une ref pour tout réseau, une sorte de wikidata version osm
une page wiki où on ajoute chaque nouvel identifiant et ca roule.

Le 22. 08. 17 à 22:52, Philippe Verdy a écrit :
 > les applications qui ont commencé à utiliser network=*
 > ont supposé que le nom indiqué derrière était unique
un exemple d'une app affectée ?
Si on a une clef unique pour identifier tout un réseau, où est le 
problème ? une sélection overpass et tous les noms sont unifiés.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSM à la plage;-) . Était : le festival de tout les highway :-)

[Christian Rogel]

> Le 2017 Eost 22 à 17:45, Philippe Verdy  a écrit :
> 
>> et jusqu'au début du XXe siècle c'était encore mutuellement intelligible 
>> avec le mannois de l'autre côté de la Manche)
> 
> Sûrement pas le mannois (Île de Man) qui est une langue Q-celtique apparenté 
> à l’irlandais et au gaéique écossais.
> 
> Justement si avec le mannois (à l'oral dans leurs forme vernaculaire). C'est 
> connu par les témoignages écrits (en français ou anglais) rapportés de 
> pêcheurs et des commerçants dans les ports, et des écrits paroissiaux, 
> notariés, des actes de justice, des voyageurs, et dans les armées, les 
> anciens pêcheurs du Guilvinec dans les années 1970 témoignaient encore 
> eux-mêmes de leur expérience ou celle de leurs parents, quand ils prenaient 
> abris dans les ports des uns et des autres en cas de gros temps, fréquent en 
> mer d'Irlande et mer d'Iroise, ou se portaient secours entre eux : c'était 
> alors très facile d'échanger en breton et mannois plutôt qu'en français ou 
> anglais dont ils ne comprenaient que des bribes.
> 

Réponse courte : ne pas parler d’intercomprèhension, quand il ne s’agit que 
d’échanges dans un registre limité : dans celui de la mer, beaucoup de mots 
très proches et interceltiques, mais, pas les articulations syntaxiques.
Un peu comme les occitanophones peuvent échanger avec les Piémontais.
Moi-aussi, Jean-Yvon je comprend parfois  le sens général d’un texte en 
gallois, et il me suffirait d’un peu de pratique orale ou écrite, mais, s'il y 
a beaucoup de mots communs entre breton et gallois, il y en a beaucoup moins 
avec les langues gaéliques.
Certains rêvent de bâtir une koinè celtique.

> 
> Même encore aujourd'hui l'orthographe bretonne a plusieurs écoles, avec le 
> vannetais qui se distingue des 3 autres principales formes dialectales, et 
> donc deux orthographes encore en compétition (il y en a eu plus dans le 
> passé), et il reste des désaccords sur l'emploi ou non des diacritiques pour 
> tenter d'unifier et reconnaître les formes dialectales (les vannetais ne sont 
> pas satisfaits du fait que la norme oublie de différencier des phonologies 
> qu'ils considèrent comme clairement distinctes et des auteurs vannetais 
> dévient volontairement de la norme développée par l'office de la langue 
> bretonne ou inisste pour qu'on y ajoute des termes vannetais qui leurs sont 
> propres pour enrichir le vocabulaire commun au lieu de le réduire à une forme 
> dominante).

L’Office public de la langue bretonne utilise l’orthographe normalisée de 
l’enseignement, car, il en faut bien une. Cependant, le breton avec des 
vannetismes est admis et encouragé par les revues littéraires et j’en vois 
souvent.
Les querelles orthographiques sont éteintes, faute de combattants. La seule 
maison d'édition « non-alignée » a déposé son bilan.

Tout ceci nous emmène loin d’OSM.


Christian R.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

Bonsoir à tous,


Le 21 août 2017 à 23:21, marc marc  a écrit :

> si tu les connais, préviens les qu'ils ne réagissent pas ici.
>

C'est fait ici : https://twitter.com/InfosReseaux/status/899711313781436420


>
> il est vrai que la proposition concerne aussi le tag flow_capacity
> ce n'est pas la même chose que si la proposition n'en parlait pas.
> Donc en effet autant voter sur quelque chose d'abouti.
> Mais voilà, je ne vois pas exactement le problème avec flow_capacity
> capacity:flow je trouve flow assez générique. vois-tu un autre tag avec
> flow possible ? parce que sinon c'est un peu l'inverse de type, ce serra
> un tag tellement précis qu'il n'existe qu'avec capacity et dans ce cas
> flow_capacity serrait tout aussi bien.
> Si t'as un exemple d'autre "flow", je me rangerai à ton avis.
>

Je suis ok pour dire que ce n'est que de la forme et je n'ai pas trouvé
d'autre clé qui puisse aller avec flow.
N'ajoutant dans OSM que des données statiques, il ne peut s'agir que d'une
capacité.

Le seul argument est que capacity existe, qu'on peut l'exploiter et il
était intéressant de regrouper la capacité en débit et en connexions sous
la même clé
Un peu comme ref=*, qui est un bon exemple : tout ce qu'il traite ne peut
être que des références, pourtant on l'a bien segmenté pour des raisons
évidentes de documentation et de collisions.
On a pas fait de INSEE_ref, mais ref:FR:INSEE ou de erdf_ref mais
ref:erdf:gdo, etc...


pourquoi rajouter un nouveau tag à discuter ? la proposition ne touche
> pas à ce tag, c'était mauvais, cela reste mauvais, cela reste à
> améliorer. sinon au final on se trouve avec une propal pour résoudre
> tous les défaut d'osm (je caricature volontairement fortement) mais qui
> reste non adoptée.
>
Parce que c'est dans le sujet traité et que le temps manque aussi.
Là on est quand même assez raisonnable je trouve :)
Et même en ajoutant deux tags, on est loin de tout avoir traité. Il restera
bien quelques propositions à faire avant d'avoir un modèle complet. Tout
l'aspect des connexions (hormis les clés coupling) n'est pas traité et là
je suis d'accord de ne pas le faire car c'est vaste.


> > Ne pas discuter des points pour accélérer ne m'attire pas trop.
> mon avis n'est pas dans ce sens.
> je voulais dire "diviser pour aboutir", un pas après l'autre
>
C'est quand même ce que nous faisons, la description est pas encore
complète et ne le sera pas à l'issue du vote de cette proposition
Meme en ajoutant les deux clés sous capacity.

Je te laisse le mot de la fin ayant donné toutes mes billes sur le sujet
pour voir ce qu'on fait remonter à Viking :)


François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[Philippe Verdy]

L'ennui c'et que toutes les applications qui ont commencé à utiliser
network=* ont supposé que le nom indiqué derrière était unique, ce qu'il
n'est pas. En fait ils voulaient que ce soit bien un identifiant.

Comme cet identifiant rendu unique ne correspond pas au nom qu'on voudrait
donner aux utilisateurs (lequel nom peut aussi avoir plusieurs traductions
co-officielles dans des pays multilingues) et qui n'est pas unique non plus.

Bref rendre unique network=* en utilisant des préfixes ou suffixes (et si
possible le préfixe "FR:" selon la convention des préfixes de pays, et non
"fr_" comme on le voit, mais cela peut ne pas suffire encore pour les
homonymies propres au même pays, et là on peut utiliser un autre préfixe ou
suffise après le "FR:").

Reste à savoir où mettre le(s) nom(s) du réseau et ses autres informations
: c'est là que la relation type=network est tout à fait appropriée pour ne
pas avoir à dupliquer ça dans tous les objets qui vont en devenir membre.
On y mettre les adresses de site web d'information, les adresses de
contact, numéros de téléphone, identifiant wikidata (et tout ce qui
semblera approprié, y compris les contacts de réseaux sociaux, ou des
identifiants spécialisés pour applications mobiles ou jeux de données
utilisables, ou encore une URL de logo).

De coup plus besoin d'aucun tag sur les objets membres

Mais par compatibilité on gardera encore un "network=" (le même que
celui dans la relation type=network, que toutes les applis n'utiliseront
pas) au minimum sur les relations "type=route" (cela concerne surtout les
applis basées sur l'ancienne v1 du schéma public transport, qui ne
connaissaient pas non plus les relations "route_master", les "super_route"
des lignes segmentées en plusieurs parties, les "stop_area", et ne
connaissaient pas autre chose que les noeuds "bus_stop" en fait utilisés
alors pour les plateformes soit pour les arrêts ou "railway=halt" et
"railway=station"). Mais on sait que ces applis auront des problèmes à
gérer les homonymies inattendues si "network=" n'est pas unique, et on
a intérêt à ce que cet  soit quand même relativement lisible par un
humain (même s'il est monolingue et a des affixes de désambiguisation) :
ces applications apprendront plus tard à afficher un meilleur nom
(éventuellement localisé pour plusieurs langues), soit à partir de la
relation "type=network" ayant le "même network=", soit à partir de la
liste des relations parentes.

Note: "network=" est parfois rendu unique en l'associant à "operator=*"
(c'est nécessaire sur certains réseaux ayant plusieurs opérateurs
exploitants des lignes homonymes avec la même "ref=*". Ce cas est rare et
ne devrait pas exister en France où chaque réseau dispose d'un opérateur
principal (les autres opérateurs sont des fournisseurs et peuvent mettre à
disposition des lignes ou tronçons de lignes, et c'est en fait le couple
"operator"+"ref" qui identifie la ligne sur le réseau "network=". Je
pense que cela concerne surtout l'Allemagne, peut-être aussi la Suisse ou
la Belgique.

Mais je vois des cas d'homonymies de "network=*" apparaître aux Etats-Unis
entre différents Etats, ou même avec des réseaux d'autres pays
(Philippines, Indonésie, Canada) et même avec des réseaux européens.
Jusqu'à présent on se souciait peu de ça car les réseaux de transport sont
largement à développer un peu partout. Je ne serais pas surpris de voir des
tas d'homonymies en Afrique.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[lenny.libre]

Le 22/08/2017 à 21:47, Noémie Lehuby a écrit :

Hello,

Si je peux me permettre un petit résumé intermédiaire :
On veut indiquer que les lignes (relations route_master) et les 
parcours (relation route) appartiennent à un réseau. Je laisse de côté 
pour le moment l'autre sujet sur le réseau sur d'autres objets.

Je reprends mon exemple fictif de Arc-En-Ciel renommé TransHauteGaronne.

On peut donc :
1) mettre le nom du réseau sur les relations : tag network = 
TransHauteGaronne
2) mettre un identifiant quelconque de réseau sur les relations : tag 
network : fr_arc_en_ciel
3) mettre un identifiant wikidata sur les relations : tag 
network:wikidata = Q-whatever

4) regrouper les relations dans une relation network TransHauteGaronne

Et bien sur, on peut combiner, puisqu'apparemment :
vers Toulouse, on fait 2 et 4
vers Tours et Nantes par exemple (pour reprendre des exemples cités 
ici), on fait 1 et 4


Personnellement, je m'en tiens à 1.
Et oui, il y a un travail de maintenance et d'uniformisation des tags 
network. Mais bon par rapport à la complexité de la maintenance 
globale des données de transport, uniformiser les noms des réseaux, ce 
n'est vraiment pas la partie qui est longue ou difficile, au contraire.


Je n'ai rien contre 3 et 4 tant qu'on les combine avec 1.
La seule qui m'embête c'est la 2. Car elle crée une ambiguité sur ce 
qu'on trouve dans le tag network.

A minima, mettons un tag network_id mais pas network.

Noémie
avec comme l'a dit Christian (si je n'interprète pas ce qu'il a dit) 
"Les name (pourquoi pas network:name) sont destinés à des humains... les 
deux se complètent et pour l'instant network=* fait (mal) un peu les deux. "


leni

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSM à la plage;-) - rendu des côtes osm et osm-fr

[osm . sanspourriel]

Aparté : /une personne achète un journal en Gallois, le patron lui fait 
remarquer qu'il n'a pas acheté un journal en anglais mais en gallois. 
Cette personne lui traduit donc un article et lui explique que 
bretonnant il lit mieux le gallois que l'anglais./


C'est plus bizarre que ça pour le rendu (qui n'a pas sa liste spéciale, 
même pas pour le rendu francophone ! :-D).


Le rendu français montre les noms des îles/ilots dès le niveau 12 
. Curieusement au 
niveau 14 
 
ils disparaissent.


Pour le rendu standard il faut attendre le niveau 14 
.
Les place 
=islet 
 comme 
Enez Vian 
 
le bien nommé (la "petite île" en breton) n'apparaissent jamais.
Testé 
 
dans pas mal de rendus et mauvais car on risque d'inciter à taguer pour 
le rendu.


Allez tant qu'à être dans le coin et parler de traduction : d'une 
manière générale je préfère les noms en langue locale (donc en breton 
ici) mais pour Ar Men Gast il vaut mieux prévenir les navigateurs que le 
coin est dangereux. Ces rochers ce sont Les Putains en français.

Christian, tu peux entrer ces toponymes dans OSM.

/Philippe, je parlait de la couleur de la Vilaine, au niveau du tuyau 
surmonté d'une surface gravillonnée, j'ai du mal à penser à de belles 
vallées à côté/.


Jean-Yvon

Le 22/08/2017 à 16:33, Christian Rogel - 
christian.ro...@club-internet.fr a écrit :


Le 2017 Eost 21 à 23:51, Philippe Verdy > a écrit :




 le breton est beaucoup plus ancien et se retrouve depuis plus de 13 
siècles un peu partour en Europe du Nord jusqu'au royaume de Suède



Vrai, on a un texte (lexique de médecin herboriste) qui daté du milieu 
du 9ème. Il est « armoricain » pour les fioritures de son écriture, 
mais, on écrivait la même langue des deux côtés de la Manche jusqu’au 
11ème.


et jusqu'au début du XXe siècle c'était encore mutuellement 
intelligible avec le mannois de l'autre côté de la Manche)


Sûrement pas le mannois (Île de Man) qui est une langue Q-celtique 
apparenté à l’irlandais et au gaéique écossais. Pas avec le gallois, 
non plus, depuis le Haut Moyen-Âge. L’intercompréhension a du être 
possible avec le cornique jusqu’à la Rennaissance, au cours de 
laquelle il s’éteint.
Me promenant en Cornouaille, je comprenais certains noms de lieu et 
les numéros donnés en lettres.


Ex : D. du Maurier a écrit « The House on the Strand », ce qui est la 
traduction du nom d’un village, Tywardreath 
  lequel existe encore au bord d’un 
ancien estuaire maintenant comblé. Un brittophone n’a pas besoin de 
traduction, car il écrirait  « Ti war draezh » (ou Tiwardraezh) et 
prononcerait « Ti war drêz » .


Ceci m’amène à traiter la question du tagging des rivages complexes, 
rocheux ou sableux.  On a édité une série de 12 livres en breton sur 
les noms des côtes du Nord-Finistère. Pour deux communes, 
Ploudalmézeau et Lampaul-Ploudalmézeau, ce n’est pas moins de 700 
toponymes qui ont été recueillis auprés des pêcheurs et ds goémoniers.
Tout avait un nom, rocher en mer et sur les dunes, passages entre 
rochers à marée, une île pouvait avoir chacun de ses faces nommées 
(Fri Karn et Skoaz Karn faisant allusion au « nez et à « l’épaule ») 
pour l’Ïle Carn.


Un constat : les caps et les rochers isolés ne sont pas dans le rendu 
OSM standard.



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] bus : lignes de transport en commun Haute-Garonne : réseau

[Noémie Lehuby]

Hello,

Si je peux me permettre un petit résumé intermédiaire :
On veut indiquer que les lignes (relations route_master) et les parcours 
(relation route) appartiennent à un réseau. Je laisse de côté pour le 
moment l'autre sujet sur le réseau sur d'autres objets.

Je reprends mon exemple fictif de Arc-En-Ciel renommé TransHauteGaronne.

On peut donc :
1) mettre le nom du réseau sur les relations : tag network = 
TransHauteGaronne
2) mettre un identifiant quelconque de réseau sur les relations : tag 
network : fr_arc_en_ciel
3) mettre un identifiant wikidata sur les relations : tag 
network:wikidata = Q-whatever

4) regrouper les relations dans une relation network TransHauteGaronne

Et bien sur, on peut combiner, puisqu'apparemment :
vers Toulouse, on fait 2 et 4
vers Tours et Nantes par exemple (pour reprendre des exemples cités 
ici), on fait 1 et 4


Personnellement, je m'en tiens à 1.
Et oui, il y a un travail de maintenance et d'uniformisation des tags 
network. Mais bon par rapport à la complexité de la maintenance globale 
des données de transport, uniformiser les noms des réseaux, ce n'est 
vraiment pas la partie qui est longue ou difficile, au contraire.


Je n'ai rien contre 3 et 4 tant qu'on les combine avec 1.
La seule qui m'embête c'est la 2. Car elle crée une ambiguité sur ce 
qu'on trouve dans le tag network.

A minima, mettons un tag network_id mais pas network.

Noémie


Le 21/08/2017 à 20:28, lenny.libre a écrit :
Entre les deux mon cœur balance, au fur et à mesure de ce que je lis, 
je change ... Je n'avais pas d'avis au départ, mais maintenant je n'en 
ai pas plus.


Le 21/08/2017 à 02:05, Jérôme Amagat a écrit :
Je rappelles que les relations network n'est sur le wiki qu'a l’état 
de proposition, que cette proposition date de 2008, que rien n'a 
bougé sur cette proposition depuis 2013 (et plus après 2009 ce n'est 
que pour ajouté des exemples). Il y a des ajouts sur la page de 
discutions un peu plus récent 2014 mais il sont négatif a l'ajout de 
ces relations.


Cette relation, ça serait juste, mettre tous les éléments qui ont le 
même tag network=* dans une même relation (ou que les 
type=route_master) donc c'est faire une liste, une catégorie ce qui 
ne se fait pas dans osm. Si l'on veux tous les élément d'un même 
réseau il y a d'autre moyen de les obtenir que de créer ce type de 
relation. Si c'est pour pouvoir mettre quelque part le vrai nom du 
réseau pourquoi ne pas le mettre directement dans le tag network=*.
Le principal avantage que je vois dans la relation c'est ce qu'il m'a 
semblé comprendre de ce disait Philippe : le tag "network", c'est 
uniquement un code donc au lieu de fr_tisseo on pourrait avoir 
FR:pt_tlse - dans la relation, on peut aussi y mettre wikidata pour 
avoir l'unicité) le jour ou le nom du réseau change, il suffirait de 
changer le name (et éventuellement le wikidata) dans la relation 
network ; il y a quelques temps à Bordeaux (où il n'y a pas de 
relation network), tous les tags "network" on été modifiés de "TBC" -> 
"TBM".


Le wikidata qui me plaisait (en permettant avec osmose de contrôler) 
m'a un peu refroidi depuis que je vois qu'il y a des manques de 
rigueur et que si le nom change, il faudra certainement changer le 
network et aussi le network:wikidata, j'y vois moins d'avantages, la 
marque du réseau de Bordeaux étant passé par le stade CGFTE 
(wikidata=Q2990197) je n'ai pas trouvé TBC, puis TBM 
(wikidata=Q377695)  et comment je fais pour le réseau du transport 
scolaire de Haut-Garonne qui n'a pas de wikidata ?


Si vous pensez que ces relation doivent exister, remettez un peu a 
jour la page de proposition avec des exemples qui existent encore et 
allez parler d'un vote de cette proposition sur la liste tagging (en 
anglais :) ) .


Sinon pourquoi ne pas créer des relations pour tous les objets qui 
ont le même operator comme par exemple EDF et vu que le même nom 
pourrait être utilisé ailleurs dans le monde il faudrait pour tout 
les tag operator=* ajouter "fr_" devant le nom comme par exemple 
operator=fr_EDF.
C'est que la relation ne serait pas utilisée pour faire la liste de 
tous les objets (bâtiment, parkings, agences, ...) ce qui serait une 
catégorie, mais uniquement les éléments constitutifs du réseau.
Après avoir beaucoup écouté, fr_ (qui est associé à la langue) ne 
devrait pas être utilisé, mais plutôt FR: (associé au pays)


Pareil pour les nom de rue addr:street=*, par exemple, il faudrait 
différencier l'"Avenue du général de Gaulle" des différentes villes, 
c'est pas les mêmes. On fait quoi on préfixe avec le nom des ville? 
De toute façon les noms on les mets que sur le tag name=* donc il n'a 
pas à être sur addr:street=* donc on peut y mettre quelque chose qui 
servira de référence pour chaque rue différente dans le monde. et on 
crée une relation pour chaque rue où on met dans name=* le vrai nom 
de la rue. A mer**, ça existe déjà, c'est les relation 
associatedStreet mais là on n'a pas modifié ce qu'on met dans 

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[marc marc]

Le 22. 08. 17 à 20:32, lenny.libre a écrit :
> Le 20/08/2017 à 12:02, marc marc a écrit :
>>> - _"public_transport=platform"_ il me semble que les tags "network"
>>> sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une
>>> relation "route" ou "public_transport=stop_area"
>> ce n'est pas "pas utile", c'est erroné que de dire qu'un trottoir ou un
>> abribus fait partir d'un réseau de transport en commun. c'est du
>> mobilier urbain. sinon à ce rythme là, on pourrait aussi ajouter les
>> routes, les carrefours, les lampes qui éclairent la route, la station
>> d'essence où le bus fait le plein, ...
> que veux-tu dire ?
>  - ce n'est pas "pas utile" : c'est-à-dire que c'est utile (double 
> négation) - ou - ce n'est pas "mais, alors vraiment pas utile" ?

Je reformule :
utile ou pas, mettre le tag operator et network du réseau de bus est erroné
sur les objets physiques (plateform, stop_position).
Pour preuve, les valeurs "operateur1;operateur2" qu'on rencontre alors 
qu'il n'y a qu'un opérateur en charge du mobilier urbain et de la route.

> parles-tu des éléments physiques ou du node qui représente l'arrêt ?
Je parle des éléments physique y compris le node de l'arrêt indiquant 
l'emplacement physique du plateform.

Les relation route_bus et master_route sont fait pour décrire 
l'utilisation de ces objets par les compagnies de bus.
C'est sur ces éléments qu'il faut mettre les tag du réseau de bus.
et aussi sur le stop_area vu que la schéma PT v2 a été voté ainsi.

 >>> lorsque l'objet n'est pas encore membre d'une
 >>> relation "route" ou "public_transport=stop_area"
on peux utilement mettre fixme=rajouter au stop_area
ou fixme=ajouter ligne de bus 42
ainsi c'est clairement visible ce qu'il reste à faire
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition tag voie verte

[marc marc]

Bonsoir,

je suis tout a fait d'accord avec les tags
Highway=path
foot=designated
bicycle=designated

Par contre je ne comprend pas l'utilité d'ajouter systématiquement 
motor_vehicle=no puisqu'un path est déjà interdit aux véhicules motorisé 
tel qu'indiqué sur sa page wiki et sur la page des valeurs par défaut
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France

Pour les voie verte où une barrière bloque l'accès physique aux 
véhicules d'urgences, par harmonie avec les autres voies, ne serrait-il 
pas préférable d'ajouter une noeud barrière avec motor_vehicle=no ?
cela n’empêche pas un véhicule d'urgence d'avoir éventuellement une 
autre entrée ailleurs. et surtout ce n'est qu'à faire s'il y une 
barrière, pas systématiquement sur toutes les voies vertes.

Cordialement,
Marc

Le 21. 07. 17 à 10:01, RAOULT Emmanuel a écrit :
> Bonjour,
> 
> 
> J'ai modifié le wiki de Montpellier en conséquence : 
> https://wiki.openstreetmap.org/wiki/Montpellier#Cyclabilité
> Si cela vous convient et que nous restons sur ce format, il pourra être 
> intéressant d'ici quelques semaines de le remonter dans le wiki national 
> pour les vélos, rubrique voie verte ...
> Bonne journée,
> 
> Emmanuel RAOULT
> 
> Chargé d’Opération Déplacements
> 
> Montpellier Med 
>   
> 
> /*Direction des Mobilités* - *Service Gestion Multimodale des 
> Déplacements***/
> 
> /*
> */
> 
> /1 place Georges Frêche - Montpellier/
> 
> /Téléphone : 04-67-34-72-43/
> 
> /e-mail : e.rao...@montpellier3m.fr /
> 
> 
> 
> *De: *"Romain MEHUT" 
> *À: *"Groupe OSM Montpellier local-herault" 
> 
> *Envoyé: *Jeudi 20 Juillet 2017 22:42:27
> *Objet: *Re: [local-herault] Proposition tag voie verte
> 
> Bonjour,
> 
> Les tags que tu proposes sont effectivement ceux qui sont indiqués dans 
> ce cas de figure.
> 
> Trois exemples de discussions sur le sujet 
> https://lists.openstreetmap.org/pipermail/talk-fr/2014-March/066953.html 
> et 
> http://talk-fr.openstreetmap.narkive.com/0hlF2Csi/osm-talk-fr-classement-national-regional-local-des-pistes-cyclables
>  
> et http://gis.19327.n8.nabble.com/path-cycleway-et-footway-td5876181.html
> 
> Romain
> 
> Le 20 juillet 2017 à 18:35, RAOULT Emmanuel  > a écrit :
> 
> Bonjour,
> 
> 
> Nous rencontrons des difficultés pour identifier facilement les
> voies vertes. En plus du tag highway=path suggéré par le wiki vélo
> d'OSM, je vous propose de rajouter bicycle=designated et
> foot=designated (horse=designated étant en option) ... en plus des
> tags optionnels surface=* et width=* ...
> Qu'en pensez-vous ?
> Est-ce que certains d'entre vous a vu passer des discussions sur les
> voies vertes pour OSM ?
> Bonne journée et merci d'avance pour vos contributions,
> 
> Emmanuel RAOULT
> 
> Chargé d’Opération Déplacements
> 
> Montpellier Med 
>   
> 
> /*Direction des Mobilités* - *Service Gestion Multimodale des
> Déplacements***/
> 
> /*
> */
> 
> /1 place Georges Frêche - Montpellier/
> 
> /Téléphone : 04-67-34-72-43/
> 
> /e-mail : e.rao...@montpellier3m.fr /
> 
> 
> 

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[lenny.libre]

Le 20/08/2017 à 12:02, marc marc a écrit :

  - _"public_transport=platform"_ il me semble que les tags "network"
sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une
relation "route" ou "public_transport=stop_area"

ce n'est pas "pas utile", c'est erroné que de dire qu'un trottoir ou un
abribus fait partir d'un réseau de transport en commun. c'est du
mobilier urbain. sinon à ce rythme là, on pourrait aussi ajouter les
routes, les carrefours, les lampes qui éclairent la route, la station
d'essence où le bus fait le plein, ...

que veux-tu dire ?
    - ce n'est pas "pas utile" : c'est-à-dire que c'est utile (double 
négation) - ou - ce n'est pas "mais, alors vraiment pas utile" ?


parles-tu des éléments physiques ou du node qui représente l'arrêt ?


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[lenny.libre]

ä la base,la discussion avait commencé parce que pour le réseau arc en
ciel, le nom même du réseau est très hétéroclite et de plus 2 réseaux
différents semblent exister en France avec ce nom.
il aurait été pratique d'avoir 2 relations pour permettre au moins de
classer les objets dans le bon groupe même si la typo exact du nom doit
être affinée (celui de leur site web, celui écrit sur les bus, ..)
le réseau Arc-en-Ciel de Haute-Garonne a une relation network 
https://www.openstreetmap.org/relation/1546978

Mais puisqu'il est mieux de faire sans relation network, le débat est
rouvert sur comment les séparer facilement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSM à la plage;-) . Était : le festival de tout les highway :-)

[Philippe Verdy]

Le 22 août 2017 à 16:33, Christian Rogel 
a écrit :

>
> Le 2017 Eost 21 à 23:51, Philippe Verdy  a écrit :
>
>
>  le breton est beaucoup plus ancien et se retrouve depuis plus de 13
> siècles un peu partour en Europe du Nord jusqu'au royaume de Suède
>
>
>
> Vrai, on a un texte (lexique de médecin herboriste) qui daté du milieu du
> 9ème. Il est « armoricain » pour les fioritures de son écriture, mais, on
> écrivait la même langue des deux côtés de la Manche jusqu’au 11ème.
>
> et jusqu'au début du XXe siècle c'était encore mutuellement intelligible
> avec le mannois de l'autre côté de la Manche)
>
>
> Sûrement pas le mannois (Île de Man) qui est une langue Q-celtique
> apparenté à l’irlandais et au gaéique écossais.
>

Justement si avec le mannois (à l'oral dans leurs forme vernaculaire).
C'est connu par les témoignages écrits (en français ou anglais) rapportés
de pêcheurs et des commerçants dans les ports, et des écrits paroissiaux,
notariés, des actes de justice, des voyageurs, et dans les armées, les
anciens pêcheurs du Guilvinec dans les années 1970 témoignaient encore
eux-mêmes de leur expérience ou celle de leurs parents, quand ils prenaient
abris dans les ports des uns et des autres en cas de gros temps, fréquent
en mer d'Irlande et mer d'Iroise, ou se portaient secours entre eux :
c'était alors très facile d'échanger en breton et mannois plutôt qu'en
français ou anglais dont ils ne comprenaient que des bribes.

Alors qu'il n'y avait plus d'intercompéhension avec l'irlandais ou le
gaélique écossais qui avaient beaucoup évolué (avec de nombreux emprunts à
l'anglais et une modification sensible des accents et une phonétique
altérée par les diphtongues, la rythmique et la tonalité).

Pour les formes écrites, je n'en sais rien, les pêcheurs pour la plupart ne
savaient pas lire aussi bien en Bretagne que dans les îles, l'orthographe
n'ayant pas été normalisée encore dans leurs langues contrairement au
français et l'anglais dominant.

Même encore aujourd'hui l'orthographe bretonne a plusieurs écoles, avec le
vannetais qui se distingue des 3 autres principales formes dialectales, et
donc deux orthographes encore en compétition (il y en a eu plus dans le
passé), et il reste des désaccords sur l'emploi ou non des diacritiques
pour tenter d'unifier et reconnaître les formes dialectales (les vannetais
ne sont pas satisfaits du fait que la norme oublie de différencier des
phonologies qu'ils considèrent comme clairement distinctes et des auteurs
vannetais dévient volontairement de la norme développée par l'office de la
langue bretonne ou inisste pour qu'on y ajoute des termes vannetais qui
leurs sont propres pour enrichir le vocabulaire commun au lieu de le
réduire à une forme dominante).

Les toponymes ont, eux, eu une conservation plus longue et là les
différentes langues celtiques se distinguent facilement, mais on n'a pas
d'intercompréhension à considérer à ce niveau puisqu'ils sont compris (à
l'oral) tels quels indépendamment des langues avec des différences
assimilées à des différences d'accent.


> Ceci m’amène à traiter la question du tagging des rivages complexes,
> rocheux ou sableux.  On a édité une série de 12 livres en breton sur les
> noms des côtes du Nord-Finistère. Pour deux communes, Ploudalmézeau et
> Lampaul-Ploudalmézeau, ce n’est pas moins de 700 toponymes qui ont été
> recueillis auprès des pêcheurs et des goémoniers.
> Tout avait un nom, rocher en mer et sur les dunes, passages entre rochers
> à marée, une île pouvait avoir chacun de ses faces nommées (Fri Karn et
> Skoaz Karn faisant allusion au « nez et à « l’épaule ») pour l’Ïle Carn.
>
> Un constat : les caps et les rochers isolés ne sont pas dans le rendu OSM
> standard.
>
>
> 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] Création de la liste OSM tagging-fr - communication - fragmentation

[Jean-Marc Liotier]

On Tue, 22 Aug 2017 14:21:00 +
marc marc  wrote:
>
> pour rebondir sur ton exemple, 16 ml locales, quasi + que d'actif.
> un paquet n'a pas eu de message cette année, une partie est à 1/mois
> n'est-on pas allez trop loin ? 5 ne serraient-ils pas suffisant ?

Une partie de ces listes sont en pratique plutôt des canaux de diffusion
d'annonces et non des lieux de discussion - la spécificité nationale
est donc peut-être importante, malgré l'apparence d'insignifiance.
J'ignore si les abonnés en sont satisfaits.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tag network sur les lignes de bus

[marc marc]

Le 22. 08. 17 à 16:32, lenny.libre a écrit :
> Le 20/08/2017 à 12:02, marc marc a écrit :
>> Le 20. 08. 17 à 11:20, lenny.libre a écrit :
>>> 4- Bien que le wiki l'indique sur chaque objet,
>> quelle page ?
> indiqué sur chaque objet, mais avec des degrés d'importance :
> https://wiki.openstreetmap.org/wiki/Public_transport "recommended"
Sur cette page, c'est bien les relations route et route_master sur 
lesquelles c'est recommandé de mettre le tag.
Cette même page wiki ne parle pas d'ajouter cela au mobilier urbain.

J'ai été rechercher la proposition d'origine soumise au vote.
Elle conseille de mettre le tag sur le stop_area au lieu du mobilier urbain.
Elle ne recommande de le mettre sur le node que si c'est la seule chose 
qui existe (donc en l'absence de stop_position et stop_area).
Même règle pour le tag operator dans la proposition votée.

J'espère que cela permettrait d'éviter les yop-yop actuels (dupliquer 
sur le mobilier urbain <> d'autres les retirent)
Qu'en pensez-vous ? particulièrement Jo ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Retour sur le State of the Map 2017 (Japon)

[PanierAvide]

Bonjour,

Les slides des présentations doivent être mises à disposition par 
l'équipe du SoTM si je me souviens bien. Je n'ai pas réussi à les 
trouver par ailleurs, peut-être contacter Frederik Ramm directement ?


Cordialement,

Adrien.


Le 22/08/2017 à 16:51, François Lacombe a écrit :

Bonjour Adrien et merci pour ce compte rendu.

Je serai très intéressé par le comparatif sur les outils de routage.
Est-ce qu'il y a de la documentation quelque part ou les slides sont 
visibles en ligne ?


Je ne connaissais pas bute de geofabrik par exemple

A+

François

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com 
@InfosReseaux 

Le 22 août 2017 à 16:02, PanierAvide > a écrit :


Bonjour à tous,

Cette année, trois contributeurs français se sont rendus à la
rencontre annuelle mondiale d'OpenStreetMap : le State of the Map,
qui se déroulait au Japon.

Un retour d'expérience (écrit collaborativement) est disponible
sur : http://openstreetmap.fr/sotm-japon-2017


Cordialement,

Adrien.


___
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] Retour sur le State of the Map 2017 (Japon)

[François Lacombe]

Bonjour Adrien et merci pour ce compte rendu.

Je serai très intéressé par le comparatif sur les outils de routage.
Est-ce qu'il y a de la documentation quelque part ou les slides sont
visibles en ligne ?

Je ne connaissais pas bute de geofabrik par exemple

A+

François

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 22 août 2017 à 16:02, PanierAvide  a écrit :

> Bonjour à tous,
>
> Cette année, trois contributeurs français se sont rendus à la rencontre
> annuelle mondiale d'OpenStreetMap : le State of the Map, qui se déroulait
> au Japon.
>
> Un retour d'expérience (écrit collaborativement) est disponible sur :
> http://openstreetmap.fr/sotm-japon-2017
>
> Cordialement,
>
> Adrien.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSM à la plage;-) . Était : le festival de tout les highway :-)

[Christian Rogel]

> Le 2017 Eost 21 à 23:51, Philippe Verdy  a écrit :
> 

>  le breton est beaucoup plus ancien et se retrouve depuis plus de 13 siècles 
> un peu partour en Europe du Nord jusqu'au royaume de Suède


Vrai, on a un texte (lexique de médecin herboriste) qui daté du milieu du 9ème. 
Il est « armoricain » pour les fioritures de son écriture, mais, on écrivait la 
même langue des deux côtés de la Manche jusqu’au 11ème.

> et jusqu'au début du XXe siècle c'était encore mutuellement intelligible avec 
> le mannois de l'autre côté de la Manche)

Sûrement pas le mannois (Île de Man) qui est une langue Q-celtique apparenté à 
l’irlandais et au gaéique écossais. Pas avec le gallois, non plus, depuis le 
Haut Moyen-Âge. L’intercompréhension a du être possible avec le cornique 
jusqu’à la Rennaissance, au cours de laquelle il s’éteint.
Me promenant en Cornouaille, je comprenais certains noms de lieu et les numéros 
donnés en lettres.

Ex : D. du Maurier a écrit « The House on the Strand », ce qui est la 
traduction du nom d’un village, Tywardreath   
lequel existe encore au bord d’un ancien estuaire maintenant comblé. Un 
brittophone n’a pas besoin de traduction, car il écrirait  « Ti war draezh » 
(ou Tiwardraezh) et prononcerait « Ti war drêz » .

Ceci m’amène à traiter la question du tagging des rivages complexes, rocheux ou 
sableux.  On a édité une série de 12 livres en breton sur les noms des côtes du 
Nord-Finistère. Pour deux communes, Ploudalmézeau et Lampaul-Ploudalmézeau, ce 
n’est pas moins de 700 toponymes qui ont été recueillis auprés des pêcheurs et 
ds goémoniers.
Tout avait un nom, rocher en mer et sur les dunes, passages entre rochers à 
marée, une île pouvait avoir chacun de ses faces nommées (Fri Karn et Skoaz 
Karn faisant allusion au « nez et à « l’épaule ») pour l’Ïle Carn.

Un constat : les caps et les rochers isolés ne sont pas dans le rendu OSM 
standard.


Christian R.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[lenny.libre]

Le 20/08/2017 à 12:02, marc marc a écrit :

Le 20. 08. 17 à 11:20, lenny.libre a écrit :

4- Bien que le wiki l'indique sur chaque objet,

quelle page ?

indiqué sur chaque objet, mais avec des degrés d'importance :
https://wiki.openstreetmap.org/wiki/Public_transport "recommended"
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_direction.2Fvariant 
"recommended if no route_master 
=* exists, else 
optional "
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_master 
" recommended if available "
https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dstop_position 
"recommended if no public_transport 
=stop_area 
 
exists, otherwise optional"
https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dplatform 
"recommended if no public_transport 
=stop_area 
 
exists, else optional "
https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dstation 
"Optional"
https://wiki.openstreetmap.org/wiki/Tag%3Apublic_transport%3Dstop_area 
"Important, if available "

https://wiki.openstreetmap.org/wiki/Public_transport/Quality_Assurance#Public_transport_objects_without_network.3D.2A

cordialement
leni
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

[marc marc]

Le 22. 08. 17 à 03:13, Vincent de Château-Thierry a écrit :
> Le 21/08/2017 à 12:51, marc marc a écrit :
>> De toute façon à mes yeux, le cas est limpide et caricatural.
>> Un inconnu arrive sans discussion pour présenter son "bébé" et ne dit
>> pas un mot aux réaction, c'est un projet purement personnel de son
>> auteur, y a qu'à cliquer. Pour caricaturer, c'est un spam :-)
> Attention aux caricatures... Que tu ne connaisses pas Séverin est une 
> chose. Le qualifier d'inconnu par ici, en revanche... non.
oui j'avais bien dit "caricatural"
1 message ici cette année, 1 message ici l'an passé.
bien sur ailleurs du monde le connaît, mais ICI, pour utiliser un terme 
plus juste, on ne peux vraiment parler d'un actif ni de communauté.
j'ai été voir un peu dans l'historique des 3 dernières années, il est 
actif dans hot, au point qu'il a décidé qu'il avait besoin de 
hot-francophone, déjà à l'époque la communauté concerné lui avait fait 
le reproche de se la faire perso sans concertation. sa réponse est assez 
limpide "you do not know well how the OSM lists work. Any group can 
<...> create one". est-cela qu'on souhaite comme fonctionnement ?
Cette nouvelle ml a entre 1 message par mois et 1 message par jour sur 
les 6 derniers mois. c'est comme pour le tagging-fr à mon avis largement 
supportable dans la ml d'origine avant la division.
d'ailleurs j'aurais pu participer à une partie des sujets si cela ne 
s'était pas passé sur "encore une ml supplémentaire où s'inscrire".
Niveau tag, sur 3 ans, j'ai pas trouvé de proposition de sa part,
pas trouvé de participation aux proposition de la collectivité,
juste quelques questions auquel il ne réagit généralement pas.
Bref, où est le besoin de fractionner talk-fr pour si peu ?

> Au fil des années ont émergé un paquet de canaux, pour ne parler que des 
> franco-français. On a des ML locales
pour rebondir sur ton exemple, 16 ml locales, quasi + que d'actif.
un paquet n'a pas eu de message cette année, une partie est à 1/mois
n'est-on pas allez trop loin ? 5 ne serraient-ils pas suffisant ?
genre idf-nord-ouest-est-sud ?
surtout qu'en survolant ces ml, la moitié des questions n'ont rien de local.
est-ce dérangeant si on a qlq annonce/mois d'une action locale sur 
talk-fr ? moi je trouverais cela positif, cela dynamiserait.

l'humain aime créer du nouveau c'est associé à l'idée d'utile.
l'humain n'aime pas fermer, c'est associé à l'idée d'échec.
pourtant parfois, le plus utile c'est de ne pas créer ou de fusionner

>> Ce qui me semblerait utile c'est d'abolir les barrières techniques entre
>> ces différentes canaux.
>> Par exemple la ml talk-fr a déjà une interface web.
>> il ne manque pas grand chose pour rendre la ml utilisable comme un forum
>> (on sait déjà s'identifier et lire, il manque juste la possibilité de
>> faire une réponse via page web au lieu de l'ouverture d'un client mail)
> Sauf erreur c'est déjà possible via Nabble :
> http://gis.19327.n8.nabble.com/France-f5380434.html

je vais faire un autre sujet avec ce point
Le 22. 08. 17 à 12:25, Christian Rogel a écrit :
 > On devrait y retrouver bientôt l'annonce de Tagging-fr.
quand je constate que la majorité exprimé trouve l'idée problématique, 
c'est dommage de promouvoir une fragmentation de la communauté.

Le 22. 08. 17 à 14:08, PanierAvide a écrit :
 > On a lancé le concept de l'agent conversationnel OSM communauté

Qui est "on" ? osm-fr ? la rédaction HebdoOSM-fr ?
Sacré terme mais très bonne idée !
Si souhaité, je pourrais faire un mot sur les harmonisations de tag.
Ton travail d'inventaire sur l'accessibilité et sa page wiki mériterait 
aussi un peu de visibilité (j'étais tombé dessus par hasard).

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Retour sur le State of the Map 2017 (Japon)

[PanierAvide]

Bonjour à tous,

Cette année, trois contributeurs français se sont rendus à la rencontre 
annuelle mondiale d'OpenStreetMap : le State of the Map, qui se 
déroulait au Japon.


Un retour d'expérience (écrit collaborativement) est disponible sur : 
http://openstreetmap.fr/sotm-japon-2017


Cordialement,

Adrien.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[lenny.libre]

Le 20/08/2017 à 00:12, marc marc a écrit :

Bonsoir,

Le 19. 08. 17 à 22:16, Severin Menard a écrit :

annoncer la création de la liste de discussion OSM tagging-fr

C'est en soi une très bonne idée que de fédérer la francophonie.

Mais quand je vois que pour la discussion de certains tag, on n'est
parfois pas nombreux à en discuter sur talk-fr, je me demande si diviser
avec une ml supplémentaire n'est pas contre productif,
Je me souviens même pas de t'y avoir lu ce mois-ci ni d'y lu l'idée.
Cordialement,
Marc

+1

lorsque j'ai commencé le fil "bus : lignes de transport en commun 
Haute-Garonne : réseau" que j'aurais dû appeler "network / bus : lignes 
de transport en commun Haute-Garonne" je me suis demandé si je le 
faisais sur la liste transport ou la liste talk , puis je me suis dit 
que network avait un impact au-delà de la seule vue transport, je l'ai 
donc mis sur talk (et on y a parlé des tags "**:wikidata")


et comme on parle de tag sur les 2 listes + le forum , rajouter une 3ème 
liste ...


leni

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[Christian Quest]

Les ref stables et id wikidata permettent à des scripts d'accéder sans 
équivoque aux infos.


Les name (pourquoi pas network:name) sont destinés à des humains... les 
deux se complètent et pour l'instant network=* fait (mal) un peu les deux.


Dans beaucoup de scripts, j'utilise les ref:INSEE pour identifier une 
commune là où un humain utilisera plutôt le nom (name) de la commune, et 
c'est bien normal.




Le 22/08/2017 à 14:35, marc marc a écrit :

Le 21. 08. 17 à 23:20, osm.sanspourr...@spamgourmet.com a écrit :
  >> MM> puisqu'il est mieux de faire sans relation network,
  >> MM> le débat est rouvert sur comment les séparer facilement.
J>>> network:wikidata  ...
MM>> cela implique de dépendre de wikipedia pour afficher/trouver le nom
MM>> d'une réseau de bus...
  > Non, tu intègres l'objet wikidata dans OSM ,il a donc son existence
  > propres, tu t'y réfères pour mettre à jour les noms.
oui, quand tu connais le code wikidata, tu peux facilement retrouver
tout les objets. c'est donc pratique pour la maintenance une fois un
travail préalable d'harmonisation de l'existant.
c'est dans cette phase qu'il y a cette "dépendance"

Le 21. 08. 17 à 20:28, lenny.libre a écrit :

Le principal avantage que je vois dans la relation c'est ce qu'il m'a
semblé comprendre de ce disait Philippe : le tag "network", c'est
uniquement un code

Je pense avoir lu Noémie qui disait que cela servait à afficher le nom
(au sens commercial) du réseau à l'utilisateur et qu'en ce sens, il
devrait correspondre au nom connu de l'utilisateur.


on peut aussi y mettre wikidata pour avoir l'unicité)
le jour ou le nom du réseau change, il suffirait de changer le name

avec ou sans relation network, je pense que c'est ainsi qu'il serrait le
plus utile : utiliser network:wikidata comme une référence (on aurait pu
mettre ref=123) permettant de sélectionner toutes les master_route d'un
réseau.
Un query overpass dans josm suffit à sélectionner toute le réseau pour
uniformiser ou changer le nom
qu'en pensez-vous de ce compromis ?

il resterait alors à se mettre d'accord sur quoi faire lorsqu'un petit
réseau de bus n'a pas la notoriété suffisante que pour être dans
wikipedia. wikidata a les même règles de notoriété que wikipedia ?
ou sinon simplement on fait une page wiki qui liste des
ref:FR:network:bus et on attribue 1 au premier cas qui se présente, puis
2, 3 etc la page wiki servant de remplacement "wikidata"
on peux bien évidement mettre une ref plus simple genre ref:FR:osmdata
qui pourrait servir à tout les objets n'ayant de référence wikidata mais
qui aurait utilement besoin d'une ref unique.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] le festival de tout les highway :-)

[marc marc]

Le 21. 08. 17 à 21:35, djakk djakk a écrit :
> une route primaire en même temps living_street c'est simple, tu 
> mets ce panneau carré bleu avec des piétons et une "limitation à 20 
> km/h" incrusté sur un des axes les plus importants d'une ville
Si rien d'autre n'a été fait, c'est 0/20 pour le responsable de 
l'aménagement mais niveau osm c'est à mon avis limpide :

La route/zone couverte par le panneau living_street est uniquement 
living_street car la priorité est le piéton, il peux circuler sur cet 
espace comme bon lui semble, jouer au ballon, faire son lacet où bon lui 
semble, même sans aménagement agréable, cet espace a perdu sa vocation 
prioritaire au transit.

Le bout de route avant et après cette zone à mes yeux devrait lui aussi 
être rétrogradé de primaire à au maximum tertiaire voir résidentiel au 
moins jusqu'au gros carrefour précédent et suivant.

Après que le routage ou les habitués décident de passer avec un 40T 
parce qu'il gagne 2 min ou simplement parce que "c'était comme cela 
avant", à mon avis ce n'est pas cela qui change la situation.
Si le trafic de transit utilise réellement toujours ce trajet, je pense 
qu'il y aussi un 0/20 pour la signalisation au carrefour précédent et 
pour la non-maj des gps éventuellement utilisé par les non-locaux.

Ce n'est bien sur que mon avis et je sais que les gens détestent les 
changements administratifs si cela ne leur conviennent pas.
Mais l'unique autre solution c'est de tager dans osm selon son envie 
subjective de à quoi devrait servir la route en ignorant les panneaux,
Cela me semble conduire vers des données moins utilisable puisque le 
routage va envoyer un 40T en transit sur une route inadaptée.
Si la communauté locale ne veux pas de la maj, ce n'est pas moi qui irai 
la faire, je suis pour les compromis autant que possible :-)
Je pense cependant que cela mérite réflexion "locale" pour faire la part 
entre nostalgie et situation réelle.
Cela mérite aussi un message à l'administration s'il y a des problèmes 
de qualité (aménagement, signalisation)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] bus : lignes de transport en commun Haute-Garonne : réseau

[marc marc]

Le 21. 08. 17 à 23:20, osm.sanspourr...@spamgourmet.com a écrit :
 >> MM> puisqu'il est mieux de faire sans relation network,
 >> MM> le débat est rouvert sur comment les séparer facilement.
J>>> network:wikidata  ...
MM>> cela implique de dépendre de wikipedia pour afficher/trouver le nom
MM>> d'une réseau de bus...
 > Non, tu intègres l'objet wikidata dans OSM ,il a donc son existence
 > propres, tu t'y réfères pour mettre à jour les noms.
oui, quand tu connais le code wikidata, tu peux facilement retrouver 
tout les objets. c'est donc pratique pour la maintenance une fois un 
travail préalable d'harmonisation de l'existant.
c'est dans cette phase qu'il y a cette "dépendance"

Le 21. 08. 17 à 20:28, lenny.libre a écrit :
> Le principal avantage que je vois dans la relation c'est ce qu'il m'a 
> semblé comprendre de ce disait Philippe : le tag "network", c'est 
> uniquement un code
Je pense avoir lu Noémie qui disait que cela servait à afficher le nom 
(au sens commercial) du réseau à l'utilisateur et qu'en ce sens, il 
devrait correspondre au nom connu de l'utilisateur.

> on peut aussi y mettre wikidata pour avoir l'unicité)  
> le jour ou le nom du réseau change, il suffirait de changer le name
avec ou sans relation network, je pense que c'est ainsi qu'il serrait le 
plus utile : utiliser network:wikidata comme une référence (on aurait pu 
mettre ref=123) permettant de sélectionner toutes les master_route d'un 
réseau.
Un query overpass dans josm suffit à sélectionner toute le réseau pour 
uniformiser ou changer le nom
qu'en pensez-vous de ce compromis ?

il resterait alors à se mettre d'accord sur quoi faire lorsqu'un petit 
réseau de bus n'a pas la notoriété suffisante que pour être dans 
wikipedia. wikidata a les même règles de notoriété que wikipedia ?
ou sinon simplement on fait une page wiki qui liste des 
ref:FR:network:bus et on attribue 1 au premier cas qui se présente, puis 
2, 3 etc la page wiki servant de remplacement "wikidata"
on peux bien évidement mettre une ref plus simple genre ref:FR:osmdata 
qui pourrait servir à tout les objets n'ayant de référence wikidata mais 
qui aurait utilement besoin d'une ref unique.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[PanierAvide]

C'est un sujet que l'on a évoqué de manière informelle avec Florian, le 
fait d'avoir une communication plus régulière et plus visible sur ce qui 
se passe au niveau national et local. L'équilibre est à trouver entre le 
temps nécessaire pour rédiger des articles/nouvelles (tâche plutôt 
chronophage) et la nécessité de rendre visible nos projets et actions 
(sans quoi la communauté n'apparaît pas exister). On a lancé le concept 
de l'agent conversationnel OSM communauté :


- L'agent obtient des infos en contactant des membres, par exemple ceux 
ayant réalisés beaucoup de contributions sur une même zone, ou les 
développeurs de projets pour lesquels on n'a pas eu d'infos depuis 
quelques temps. Le robot demande ainsi à la personne d'expliquer sa 
démarche et ses actions en cours. Le tout en ayant au final peu de temps 
à y consacrer (une brève pouvant être écrite en quelques minutes).


- L'agent peut également envoyer à sa liste d'abonnés des condensés 
d'informations réguliers, générés à partir des infos remontées 
précédemment. Cela permet aux abonnés de se tenir au courant sans avoir 
à aller chercher l'info. Le format court des infos remontées assure 
également une régularité de la diffusion.


- Enfin, ces mêmes infos peuvent apparaître sous la forme d'un flux de 
nouvelles sur une page web, accessible depuis le site osm.fr, donnant 
une visibilité aux actions de la communauté.


Au-delà de cet exemple de solution, il y a un vrai enjeu sur la 
communication, à la fois pour consolider la communauté et pour augmenter 
sa visibilité, et donc potentiellement attirer de nouveaux participants. 
À méditer donc ;-)


Adrien.


Le 22/08/2017 à 12:25, Christian Rogel a écrit :

Salut, Adrien,
On attend le CR et, donc, un petit résumé ici sera bienvenu, comme je 
le disais.

Ma remarque concernait l'avant SotM 2017.
Ceux qui ne sont pas dans la partie organisée de la communauté 
n'avaient aucun moyen de savoir qu'il allait avoir lieu, à moins de 
s'abonner à HebdoOSM 
http://www.weeklyosm.eu/fr/archives/9374 S'abonner via col. de droite 
"Suscribe to OSM".

On devrait y retrouver bientôt l'annonce de Tagging-fr.




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[Christian Rogel]

> Le 22 août 2017 à 11:46, PanierAvide  a écrit :
> +1, le Japon c'est pas la porte à côté ;-) On va sortir d'ici peu (fin de 
> semaine au plus tard) un billet sur le site openstreetmap.fr pour faire un 
> retour sur ce qui s'y est passé. En attendant, un certain nombre de photos 
> sont sur Twitter [1] et Flickr [2].
> 
> Adrien.
> 
> [1] https://twitter.com/hashtag/sotm?f=tweets=default=hash
> [2] https://www.flickr.com/photos/tags/sotm2017
> 
> Le 21/08/2017 à 00:59, Vincent de Château-Thierry a écrit :
>>> On attend les retours de ceux qui ont été au State of the Map qui est en 
>>> cours au Japon, mais, personne n’a pensé en en parler.
>> 
>> Il y aura ! Laisse leur le temps de rentrer ;)

Salut, Adrien,
On attend le CR et, donc, un petit résumé ici sera bienvenu, comme je le disais.
Ma remarque concernait l'avant SotM 2017.
Ceux qui ne sont pas dans la partie organisée de la communauté n'avaient aucun 
moyen de savoir qu'il allait avoir lieu, à moins de s'abonner à HebdoOSM 
http://www.weeklyosm.eu/fr/archives/9374 S'abonner via col. de droite "Suscribe 
to OSM".
On devrait y retrouver bientôt l'annonce de Tagging-fr.


Christian R.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] [ortho] serveur scratch osm.tetaneutral.net

[Laurent GUERBY]

Bonjour,

Le serveur "scratch" orthophoto pour faire des tests de dimensionnement
est en place et les cles ssh root aussi (manque celle de Christian, pas
reçue ?).

https://pad.tetaneutral.net/p/osm
<<
* Debian 9 stretch amd64
* Ryzen 1700 8C/16T 3 GHz
* 64G de RAM  (swap desactivé)
* Disques 5 SSD

root@h9:~# df -h
Filesystem  Size  Used Avail Use% Mounted on
/dev/sde2   165G  1.1G  164G   1% /
/dev/sda962G   77M  962G   1% /scratch/t1
/dev/sdd962G   77M  962G   1% /scratch/t2
/dev/sdb110G   61M  110G   1% /scratch/s1
/dev/sdc110G   61M  110G   1% /scratch/s2

Usage des disques SSD :

/ => uniquement pour package et config
/scratch/t1 et t2 => disques 1 TB mais avec endurance write
relativement faible = 320 TBW, a utiliser pour données qui ne vont pas
beaucoup bouger ou qui ne rentrent pas ailleurs
/scratch/s1 et s2 => disques 120GB mais avec tres grande endurance
write = 690 TBW a utiliser pour les (petites) BDD, calculs
intermediaires et transformations de fichiers
>>

Pour le moment c'est en 1 Gbit/s donc ~ 90-100 Mo/s wget sur online et
OVH, la carte 10G est dans la machine mais pas encore configurée.

Sincèrement,

Laurent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

[PanierAvide]

+1, le Japon c'est pas la porte à côté ;-) On va sortir d'ici peu (fin 
de semaine au plus tard) un billet sur le site openstreetmap.fr pour 
faire un retour sur ce qui s'y est passé. En attendant, un certain 
nombre de photos sont sur Twitter [1] et Flickr [2].


Adrien.

[1] https://twitter.com/hashtag/sotm?f=tweets=default=hash
[2] https://www.flickr.com/photos/tags/sotm2017


Le 21/08/2017 à 00:59, Vincent de Château-Thierry a écrit :
On attend les retours de ceux qui ont été au State of the Map qui est 
en cours au Japon, mais, personne n’a pensé en en parler.


Il y aura ! Laisse leur le temps de rentrer ;)



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr