Re: [OSM-talk-fr] Étiquetage padza

[Philippe Verdy]

Une forme de désertification où l'homme a joué un rôle initial, et la
nature a fait le reste en amplifiant le problème.

Comment traiter alors les zones en voie de désertification en Afrique et
ailleurs, même en Espagne, le sud de l'Italie et d'autres îles
méditerranéennes, ou encore en Australie centrale et an Amérique du Sud
dans d'anciennes riches vallées agricoles?

L'homme y jour un rôle mais souvent à une échelle bien plus grande que
locale (l'effet amplificateur d'échelle vient de la nature et n'est pas
directement celui de l'homme qui a cru son action aurait un effet seulement
purement local ou temporaire, une sorte "d'effet papillon").

L'agriculture n'est pas la seule en cause, il y a aussi un rôle majeur dans
l'utilisation urbaine des ressources en eau. Et parfois comme en Indonésie,
ou en Haïti, ou dans l'île de Pâques, au Mexique dans les civilisations
précolombiennes, ce n'était pas l'agriculture mais l'exploitation abusive
de ressources forestières non renouvelables, ces pratiques on les trouve
maintenant aussi en Amazonie (pas forcément pour l'agriculture, mais pour
l'orpaillage ou la construction de barrages).

En Afrique aussi pour la production de charbon (pas d'agriculture, on coupe
direct, on brûle sur place et on ramasse, et on ne gère pas du tout en
replantant...).

Dans les Antilles (hormi Haïti), oui on peut parler de l'impact direct par
l'agriculture. A Mayotte (ou dans les îles voisines) la situation est mixte
mais surtout influencé par des besoins urbains avec une pression
démographique massive où l'usage des coupes devient plus important que
l'usage réellement agricole qui a stagné ou régressé alors qu'il gérait
mieux les ressources, même si un temps cela s'est fait par la vieille
technique facile du brûlis qui a remplacé celle des anciennes plantations
basées sur le travail humain, notamment l'esclavage dans le passé, faute de
réel autre moyen de développer d'autres techniques agricoles demandant des
financements importants et un système de commercialisation efficace car on
ne leur proposait que le machinisme, les engrais et l'agriculture intensive
et ultra-sélective qui pourtant ont montré leurs limites et leur
inefficacité dès le court terme, donc conduit à raser des surfaces de plus
en plus vastes pour "remplacer" les terres infertilisées).

Mais on a un phénomène similaire aussi dans notre développement urbain qui
délaisse des terrains en friches polluées et économiquement plus
"rentables". L'aspect est différent (en terme de matériaux) mais la
latérite des "padzas" est finalement comparable aux montagnes de remblais
qui s'accumulent et créent un sol artificialisé qui n'évoluera plus en
terre fertile. On peut également parler des terrils, des montagnes de
déchets enterrés sous les anciennes décharges, juste couvert par une fine
couche naturellement infertile (et tout arrêt d'entretien, mais aussi la
dégradation par l'écoulement naturelle des eaux fait réapparaitre ces
matériaux quelque part), et des anciennes mines (même ferméees et
partiellement rebouchées, ou simplement laissées s'inonder pour former des
étangs, d'où remonteront plus tard des effluents).

Toutes les déforestations ne sont pas humaines, certaines proviennent
d'événements naturels depuis toujours (par exemple les incendies par la
foudre, les ouragans/cyclones, le volcanisme, les tsunamis, les glissements
de terrain et effondrements d'origine naturelle: tectonique ou érosive).

Les roches érodées sont des terrains "en transition" rapide, la nature y
reprendra elle-même ses droits mais sous une forme différente, pour peu
qu'on la laisse faire, et pour moi les "padzas" sont bien des éléments
naturels (à un stade précoce de cette transition), de la même façon que les
plages et haut-fonds de sables ou galets en bord de mer ou sur les cours
d'eau. Pour l'instant l'homme ne peut plus y faire grand chose même s'il a
pu en être une des causes ou un facteur déclenchant, catalyseur ou
accélérateur. Il est même fort probable que ce phénomène se serait produit
de toute façon (il aurait suffit d'un seul cyclone ou tsunami, ou éruption
volcanique comme deux qui ont dévasté nombre d'îles carribéennes, et
d'autres îles du Pacifique quasi inhabitées comme les Kouryles dans le
détroit de Bering et presque toute la Polynésie, ou encore les Andes, une
bonne partie de l'erg saharien, ou l'ancienne vallée fertile entre Ethiopie
et le haut Nil où est née l'humanité avant qu'elle soit obligée d'émigrer
et conquérir le monde). On peut encore citer des terres du centre-nord de
l'Amérique.


Le ven. 19 oct. 2018 à 18:09, Waxy  a écrit :

> Salut,
>
> Comment étiquetteriez-vous ceci…
> https://fr.wikipedia.org/wiki/Padza
>
> J'ai mis :
> natural=bare_rock
> surface=ground
>
> En fait ce n'est pas très naturel. C'est le résultat d'une pratique
> "agricole".
>
> @+
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

[OSM-talk-fr] Étiquetage padza

[Waxy]

Salut,

Comment étiquetteriez-vous ceci…
https://fr.wikipedia.org/wiki/Padza

J'ai mis :
natural=bare_rock
surface=ground

En fait ce n'est pas très naturel. C'est le résultat d'une pratique
"agricole".

@+


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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[marc marc]

résumé de la modif automatique proposée en France
en tenant compte de tous les suggestions :
7371 amenity=swimming_pool
- 71 qui ont déjà un tag leisure
- 272 avec un tag name
- 39 avec un tag building
- 18 avec une surface dams josm areasize > 2000m2

cela fait environ 7000 à modifier en leisure=swimming_pool.
pas d'objection ?

Pour le reste, je m’abstiens de le faire en automatique,
mais je donne volontiers un coup de main pour le faire
à la main, en regardant chaque objet.

Le 19. 10. 18 à 08:42, Paul Desgranges a écrit :

>      les "amenity=swimming_pool + name=*" 
>  en "leisure=sports_centre + 
> sport=swimming"

Je doute que tu puisses tirer une conclusion aussi binaire de
la présence d'un nom, j'ai déjà croisé souvent des name=piscine privée
Je pense que pour ceux là, soit on les inclus dans le groupe général 
(c'était supposé être un bassin, si c'est faux, cela reste faux)
soit c'est plus raisonnable de les charger dans josm et de faire
un contrôle humain pour mettre l'éventuel faux nom dans description
et tag d'accès plutôt que de changer le sens en centre sportif
car c'est une supposition hasardeuse.

> "amenity=swimming_pool + name!=*" 
>  en "leisure=swimming_pool"

critère "tag name" ajouté ci dessus pour l'édition de masse

> "amenity=swimming_pool + building=yes" 
>  en "leisure=sports_centre

- critère "pas de tag building" ajouté pour l'édition de masse.
- Mais convertir en centre sportir uniquement sur la base de la présence 
d'un tag building, c'est se tromper lorsqu'un bassin est couvert avec
un bâtiment en dur donc je passe mon tour pour faire cette modif là
en automatique (mais je ne suis pas vexé si quelqu'un veux faire 
autrement à ma place)
il y en a que 39 et un risque d'erreur trop élevé que pour justifier
de le faire à l'aveugle.

> Mais là, a-t-on la possibilité de faire une requête overpass turbo pour 
> les sélectionner sur ce critère de taille?

Je n'ai pas vu, Jérome parlait d'overpass
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Ces collectivités qui misent sur Openstreetmap et la cartographie participative

[Christian Quest]

Article paru sur un site du Ministère de l’Economie, de l’Industrie et du
Numérique...

https://labo.societenumerique.gouv.fr/2018/10/17/collectivites-misent-openstreetmap-cartographie-participative/

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

Re: [OSM-talk-fr] Voting Default Language Format

[Philippe Verdy]

Le "name:fr" est le nom **d'usage courant** en français, il n'est pas
forcément le nom **officiel** (quel que soit sa langue d'origine, française
ou régionale) qui lui figure dans "official_name=*"

Il peut y avoir plusieurs noms officialisés **localement** dans quelques
langues, dont le français, et pour les distinguer on peut ajouter
"official_name:fr=*" et "official_name:=*", mais on n'en
mettra pas d'autres et donc aucun autre nom dans une langue non
officialisée; au plan national le seul nom officiel est celui officialisé
en français donc nécessairement alors "official_name:fr=*" prévaut sur
"official_name=*" pour cette utilisation légale nationale franco-française.

En revanche les rendus affichent les noms officiels seulement comme
métadonnées, rarement sur les cartes. Les rendus OSM par défaut n'affichent
que les noms d'usage le plus courant "name=*" ou "name:lang=*". Mais il
n'est pas forcément le plus courant localement et pour ça on a "loc_name=*"
(éventuellement aussi avec "loc_name:=*" s'il y a plusieurs parlers
locaux) qui est lui aussi une métadonnée rarement utilisée dans le rendu
mais seulement visible si on demande les infos détaillées sur un objet
particulier.

Il faut se demander quel est le but d'un rendu "100% français" et quel
public est visé. Si on veut faire une carte "officielle" de la France selon
la législation française, on devra privilégier "official_name:fr=*" et
sinon "official_name=*", à "name:fr=*" en dernier recours avant "name=*"
qui n'est que le nom d'usage (supposé officiel s'il n'y a pas
"official_name:fr=*" indiqué explicitement) et on ignorera tous les
"loc_name=*" et "loc_name:=*".

OSM est assez souple pour permettre à un rendu de déterminer ses priorités
selon le public et l'usage qu'il vise.

Mais en général les rendus "standards" d'OSM utilisent les noms d'usage
courant (peu importe s'ils sont officiels ou pas) indiqués dans
"name:=*" (si l'utilisateur a une **préférence** pour une langue
donnée, ce qui n'est pas une obligation légale) ou sinon dans "name=*"
(quel que soit la langue).


Le ven. 19 oct. 2018 à 09:06, rainerU  a écrit :

> Bonjour,
>
> Je me pose des questions sur l'impact de cette proposition sur les objets
> qui
> ont un nom officiel en langue régionale :
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>
> Si j'ai bien compris la proposition, on mettrait default:language=fr sur
> la
> frontière de la France (ou des régions, départements,...) et les
> applications
> utiliseraient name=fr comme nom standard.
>
> A mon avis, cela pose un problème dans les cas où le nom officiel d'un
> objet est
> en langue régionale mais existe aussi un nom en français. Il y a eu un fil
> de
> discussion sur cette liste sur la manière de tagguer ces cas avec le
> schéma
> actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je taggue
> name= officiel>, name:ca=, name:fr=. Avec le schéma
> proposé, un rendu en langue standard afficherait le nom français et pas le
> nom
> officiel en catalan. Si par contre on mettait name:fr=, on ne
> pourrait plus créer un rendu 100% français.
>
> Est-ce que cette question a déjà été discuté ici ou ailleurs, si oui
> quelle
> était la conclusion ?
>
>
>
> ___
> 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] Relation de riviere, Le Rhone

[Philippe Verdy]

>
> Les choses seraient plus simples si OSM ne permettait plus de représenter
> une surface avec des chemins d'orientation quelconque et imposait la même
> restriction que le GIS standard. On n'aurait même pas besoin non plus des
> rôles "inner" et "outer" qui ne sont qu'indicatifs (pour les humains) mais
> même pas réellement distinctifs (pour tous les moteurs de rendus ou
> d'analyse, qui de toute façon doivent ignorer cette distinction apparente
> et les traiter de la même façon).
>
> Mais alors pourquoi OSM ne l'impose pas ? Simplement parce que les chemins
> dans OSM sont "partagés" et peuvent être réutilisés en tant que membres par
> plusieurs relations de surface (chacune définissant une "orientation GIS"
> différente au sens surfacique) et avoir en plus une orientation ne
> dépendant pas des relations de surface mais de ce qu'impose d'autres objets
> "filaires" (par exemple : orientation des cours d'eau waterway=*, ou sens
> unique des rues highway=*, ou voies ferrées railway=*).
>

J'ajoute en plus  que le fait qu'OSM n'impose pas l"orientation GIS des
chemins membres d'un "multipolygon" pose un problème non seulement dans les
rendus, mais aussi dans les éditeurs utilisés (à cause de limite mémoire,
que ce soit dans un éditeur web comme iD où la limite est imposée par le
navigateur utilisé ou un éditeur externe comme JOSM (par exemple la limite
mémoire des VMs Java) : on ne peut pas charger la totalité de la géométrie
d'un multipolygone san imposer une charge lourde au serveur OSM, et sans
saturer en plus la mémoire de l'éditeur.

On doit donc pouvoir travailler dans un éditeur avec une géométrie
partiellement téléchargée pour les relations. Le rendu dans l'éditeur du
coté "intérieur" ou "extérieur" n'est donc pas toujours exact et
l'utilisateur doit se guider sur les indications des rôles "inner" et
"outer" pour éviter de casser la géométrie de ces relations surfaciques
(mais c'est un guide partiel qui ne répond pas à toutes les questions, le
rendu dans l'éditeur peut rester malgré tout incorrect tant que la
géométrie de la relation n'est pas téléchargée en totalité en mémoire...)

C'est pour ça qu'on demande aux utilisateurs de limiter la géométrie des
multipoygones afin que le nombre total de points ne dépasse pas quelques
milliers de points. Sinon on leur demande de scinder les multipolygones en
plusieurs parties.

Ce sera à l'export GIS de préparer les géométries complètes de polygones
afin d'en faire un rendu exact (et pour cela il n'a absolument pas besoin
de la distinction des rôles "inner" et "outer"), en défusionnant les
ways OSM partagés (pour les importer dans des polygones surfaciques
complets et correctement orientés plaçant l'intérieur à gauche, quelque
soit l'orientation des chemins utilisés dans OSM).

Bref on a un compromis dans OSM favorisant plutôt les utilisateurs afin de
leur permettre d'éditer la carte sans avoir nécessairement une machine
puissante avec plein de mémoire (ou beaucoup de stockage dans une base
locale externe : c'est ce qu'a fait iD en ne chargeant plus tout en mémoire
dans le navigateur, mais en utilisant une fonctionnalité "base de données
locale" offerte par les navigateurs web récents, où des données peuvent
être stockées sur disque et pas gardées en mémoire, ce qui le rend
utilisable même dans des navigateurs limités en 32 bits mais disposant d'un
stockage local généralement plus confortable). En attendant les rôles
"inner" et "outer" restent utiles car on continue de l'utiliser sans avoir
forcément téléchargé la totalité de la géométrie des relations (même via
une "base de données externe" locale) et parce que le rendu local dans
l'éditeur ne s'en sert pas (cela imposerait trop de données en mémoire ou
nécessiterait que l'éditeur précalcule une "orientation GIS" et la mette en
cache dans sa base externe locale)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Relation de riviere, Le Rhone

[Philippe Verdy]

Dernière note importante : les surfaces "riberbank" peuvent être des
relations "multipolygon", mais leur complexité géométrique s'accroît vite
et peut poser des difficultés au rendu s'ils couvrent des surfaces très
étendus. En effet un rendu ne peut pas se contenter de chercher les ways
présents dans sa "bounding box" d'intérêt, pour détecter des chemins
membres d'une relation avec des rôles "inner" et "outer" même correctement
définis car il peut encore manquer des chemins pour savoir quel est le côté
intérieur ou extérieur.

En effet il pourrait trouver dans sa "bounding box" d'intérêt (celle qu'il
veut tracer) seulement deux chemins avec un rôle "outer" et ne peut PAS
conclure que la surface entre les deux (dans sa "bounding box") est
couverte en eau, car un cours d'eau peut faire des méandres et donc la
surface en eau pourrait s'étendre en fait de chaque côté des deux chemins
"outer" trouvés (jusqu'au moins les limites de la "bounding box") mais
justement pas entre les deux chemins. Un rendu doit alors charger les
relations au complet pour énumérer tous les chemins et déterminer
correctement le côté intérieur ou extérieure des chemins.

Cela pose des difficultés de performance justement pour les cours d'eau qui
formeraient une surface "riverbank" unique. Pour ces raisons, il est admis
que les surfaces "riverbank" d'un cours d'eau peuvent ne pas être uniques,
afin de rendre la complexité géométrique des surfaces moins grande.

De plus les relations "riverbank" ne suivent pas exactement les
restrictions des "multipolygon" car ils est admis que ces relations peuvent
inclure des polygones jointifs (partageant des chemins ou ayant des chemins
fermés partiellement superposés). Ces relations "riverbank" n'imposent donc
pas de déplacer les attributs "riverbank" de leurs way membres vers la
relation qui les collecte tous.

Les "riverbank" sont donc à traiter de la même façon que les surfaces de
"landuse=*" et "natural=*", qui ont les mêmes difficultés : il a été décidé
de limiter la complexité géométrique des multipolygones et de ne les
réserver qu'à des objets pas trop étendus, dont la géométrie global ne
totalise pas plus de quelques milliers de noeuds (quel que soit le nombre
de chemins qui les joignent et sont les membres des multipolygones).

Une telle complexité en revanche a été admise pour les relations "boundary"
qui ne posent pas de problème aux rendus (en vectoriel ou bitmap) : les
frontières ne sont jamais rendues comme surface (ou seulement un
prétraitement de "simplification géométrique" pour les niveaux de zoom
faibles) mais seulement en filaire (qui peut lui aussi avoir un
prétraitement de simplification géométrique).

La complexité géométrique des "coastlines" en revanche fait objet d'une
exception : on ne représente pas la mer comme une surface, mais pour
contourner le problème, on y impose l'orientation des chemins pour que le
côté "mer" soit à droite (cette conditions supplémentaire n'existe pas pour
les autres surfaces d'OSM, c'est tout le problème, contrairement aux
spécifications GIS standard qui imposent la même orientation à toute
surface délimitée par des contours fermés, avec le côté intérieur à gauche
et le côté extérieur à droite dans le sens du parcours du chemin).

De ce fait les coastlines font l'objet du côté d'OSM d'un prétraitement
spécifique qui les extrait dans une base à part destinée aux moteurs de
rendus, pour qu'ils n'utilisent pas les mêmes règles que les autres
surfaces OSM et conservent l'orientation indiquée dans cette base.

Alors que pour tous les autres objets OSM l'orientation des chemins reste à
déterminer par un algorithme coûteux devant prendre en compte la totalité
de la géométrie des objets (et qui ne peut pas se contenter des deux roles
"outer" et "inner" pour distinguer les cas, car ils ne suffisent pas à
déterminer comment réorienter des chemins en plaçant l'intérieur à gauche
et l'extérieur à droite, afin de pouvoir ensuite en faire un rendu
surfacique, ou à déterminer si un autre point quelconque est à l'intérieur
ou à l'extérieur de la surface).

Le coût de cet algorithme s'accroît vite quand les surfaces sont
représentées par des mulitpolygones dont les chemins membres comptent plus
de quelques milliers de points, et il impose d'utiliser des requêtes
lourdes en volume à la base de données (pour les mers cela représenteraient
à chaque fois des millions de points, et c'est pour ça qu'une exception a
été faite au "modèle OSM" pour les coastlines: le serveur de données ne
peut pas répondre "en ligne" à de telles demandes, cela doit être fait par
un export spécifique.

Les choses seraient plus simples si OSM ne permettait plus de représenter
une surface avec des chemins d'orientation quelconque et imposait la même
restriction que le GIS standard. On n'aurait même pas besoin non plus des
rôles "inner" et "outer" qui ne sont qu'indicatifs (pour les humains) mais
même pas réellement distinctifs (pour tous les moteurs de rendus ou
d'analyse, qui de toute 

Re: [OSM-talk-fr] Voting Default Language Format

[Christian Quest]

ça ajoute quand même une info :

name + name:ru sur un objet, mais avec des valeurs différents ne permet pas
de savoir la langue de ce name (cas bien courant)
avec le default:name=fr on sait que name est en français, sans avoir à
doubler avec un name:fr

Par contre, pour le rendu, la requête pour le retrouver va être assez
violente côté postgis vu la tête du mega-multi-polygone sur lequel on va
mettre ce tag... j'ai un doute sur son usage effectif dans la vraie vie.

La solution que j'ai adopté sur le rendu FR (utilisé pour les exemples)
s'en passe heureusement !

Le ven. 19 oct. 2018 à 15:00, marc marc  a
écrit :

> Je pense que le but de la propal est mal expliquée.
> S'il y a un name qui est égale au name:fr, on sait déjà déduire
> que le nom est en Français. et s'il y a un name=Viva Pizza name:it=Viva
> Pizza on sait déjà déduire que le nom du resto est en italien.
> On sait déjà faire un rendu "priorité fr" comme celui osm-fr
> ou dans une autre langage comme le montre ceux d'osm-be de bzh
> La propal ne change rien pour cela.
>
> Je trouve que le réel intérêt, c'est de dire de manière structurée :
> s'il a qu'un SEUL name, En France, le plus probable c'est que
> c'est du français tandis que c'est sans doute de l'allemand
> en Suisse mais à nouveau du Français dans le canton de Genève.
> tout en pouvoir surcharger cela si on le veux sur un poi.
> Le gros avantage que je vois c'est les routages vocaux.
> Il y aura un moyen d'encoder l'information nécessaire
> à une prononciation plus adaptée au contexte local.
>
> Le 19. 10. 18 à 12:52, Christian Quest a écrit :
> > Elle règle une partie des problèmes, mais ne permet pas de gérer du 100%.
> >
> > Ceci dit, on n'est pas obligé de l'utiliser cette info ou bien le faire
> > avec intelligence...
> >
> > Cas du rendu FR: si default:language=fr, je prends les name, sinon je
> > prends les name:fr
> >
> > Du coup, on aura bien le "name" sur le territoire français, même si il
> > n'est pas en français mais occitan ce qui est au final l'objectif
> > recherché, non ?
> >
> > Pour savoir véritablement dans quelle langue est name=*, il faut le
> > comparer aux différents name:xx=* , il n'y a finalement que ça de fiable
> > si c'est cette info qu'on veut obtenir.
> >
> >
> > Le ven. 19 oct. 2018 à 12:28, Rpnpif  > > a écrit :
> >
> > Le 19 octobre 2018, rainerU a écrit :
> >
> >  > Bonjour,
> >  >
> >  > Je me pose des questions sur l'impact de cette proposition sur
> > les objets qui
> >  > ont un nom officiel en langue régionale :
> >  >
> >  >
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
> >  >
> >  > Si j'ai bien compris la proposition, on mettrait
> > default:language=fr sur la
> >  > frontière de la France (ou des régions, départements,...) et les
> > applications
> >  > utiliseraient name=fr comme nom standard.
> >  >
> >  > A mon avis, cela pose un problème dans les cas où le nom officiel
> > d'un objet est
> >  > en langue régionale mais existe aussi un nom en français. Il y a
> > eu un fil de
> >  > discussion sur cette liste sur la manière de tagguer ces cas avec
> > le schéma
> >  > actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je
> > taggue name= >  > officiel>, name:ca=, name:fr=. Avec le
> > schéma
> >  > proposé, un rendu en langue standard afficherait le nom français
> > et pas le nom
> >  > officiel en catalan. Si par contre on mettait name:fr= > catalan>, on ne
> >  > pourrait plus créer un rendu 100% français.
> >  >
> >  > Est-ce que cette question a déjà été discuté ici ou ailleurs, si
> > oui quelle
> >  > était la conclusion ?
> >
> > Bonjour,
> > Oui je suis d'accord avec toi : ce n'est pas une proposition
> > pertinente.
> >
> > --
> > Alain Rpnpif
> >
> > ___
> > 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
> >
>
> ___
> 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

[OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.16.0

[marc marc]

Pour info (rendu osm.org, cela prendra du temps pour la maj des tuiles)

hasard de calendrier, icône en plus pour les centres sportif :)

 Message transféré 
Sujet : [OSM-dev] OpenStreetMap Carto release v4.16.0
Date :  Fri, 19 Oct 2018 05:44:45 +0200
De :Daniel Koć 
Pour :  osm-dev List 


Dear all,

Today, v4.16.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on the openstreetmap.org it will take couple of days before all
tiles show the new rendering.

Changes include
- Changing societal amenities color to less intensive
- Adding rendering for natural=strait
- Adding rendering for leisure=track on lines
- Adding icon for amenity=vehicle_inspection
- Adding icon for leisure=sports_centre + sport=swimming and 
leisure=swimming_area
- Adding icon for tourism=gallery
- Changing color for aeroway=apron in aerodromes
- Moving amenity=post_box to z19+
- Moving amenity=atm to z19+
- Replacing icon for information=tactile_model
- Ordering amenity_lines by layer
- Small documentation and code fixes

Thanks to all the contributors for this release including dryo, a new 
contributor|.|

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.15.0...v4.16.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

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

Re: [OSM-talk-fr] Voting Default Language Format

[marc marc]

Je pense que le but de la propal est mal expliquée.
S'il y a un name qui est égale au name:fr, on sait déjà déduire
que le nom est en Français. et s'il y a un name=Viva Pizza name:it=Viva 
Pizza on sait déjà déduire que le nom du resto est en italien.
On sait déjà faire un rendu "priorité fr" comme celui osm-fr
ou dans une autre langage comme le montre ceux d'osm-be de bzh
La propal ne change rien pour cela.

Je trouve que le réel intérêt, c'est de dire de manière structurée :
s'il a qu'un SEUL name, En France, le plus probable c'est que
c'est du français tandis que c'est sans doute de l'allemand
en Suisse mais à nouveau du Français dans le canton de Genève.
tout en pouvoir surcharger cela si on le veux sur un poi.
Le gros avantage que je vois c'est les routages vocaux.
Il y aura un moyen d'encoder l'information nécessaire
à une prononciation plus adaptée au contexte local.

Le 19. 10. 18 à 12:52, Christian Quest a écrit :
> Elle règle une partie des problèmes, mais ne permet pas de gérer du 100%.
> 
> Ceci dit, on n'est pas obligé de l'utiliser cette info ou bien le faire 
> avec intelligence...
> 
> Cas du rendu FR: si default:language=fr, je prends les name, sinon je 
> prends les name:fr
> 
> Du coup, on aura bien le "name" sur le territoire français, même si il 
> n'est pas en français mais occitan ce qui est au final l'objectif 
> recherché, non ?
> 
> Pour savoir véritablement dans quelle langue est name=*, il faut le 
> comparer aux différents name:xx=* , il n'y a finalement que ça de fiable 
> si c'est cette info qu'on veut obtenir.
> 
> 
> Le ven. 19 oct. 2018 à 12:28, Rpnpif  > a écrit :
> 
> Le 19 octobre 2018, rainerU a écrit :
> 
>  > Bonjour,
>  >
>  > Je me pose des questions sur l'impact de cette proposition sur
> les objets qui
>  > ont un nom officiel en langue régionale :
>  >
>  >
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>  >
>  > Si j'ai bien compris la proposition, on mettrait
> default:language=fr sur la
>  > frontière de la France (ou des régions, départements,...) et les
> applications
>  > utiliseraient name=fr comme nom standard.
>  >
>  > A mon avis, cela pose un problème dans les cas où le nom officiel
> d'un objet est
>  > en langue régionale mais existe aussi un nom en français. Il y a
> eu un fil de
>  > discussion sur cette liste sur la manière de tagguer ces cas avec
> le schéma
>  > actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je
> taggue name=  > officiel>, name:ca=, name:fr=. Avec le
> schéma
>  > proposé, un rendu en langue standard afficherait le nom français
> et pas le nom
>  > officiel en catalan. Si par contre on mettait name:fr= catalan>, on ne
>  > pourrait plus créer un rendu 100% français.
>  >
>  > Est-ce que cette question a déjà été discuté ici ou ailleurs, si
> oui quelle
>  > était la conclusion ?
> 
> Bonjour,
> Oui je suis d'accord avec toi : ce n'est pas une proposition
> pertinente.
> 
> -- 
> Alain Rpnpif
> 
> ___
> 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
> 

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

Re: [OSM-talk-fr] Relation de riviere, Le Rhone

[Philippe Verdy]

Note: Positron est le seul ici à ne pas accepter de faire un rendu des
multipolygon des surfaces de riverbank. C'est pourtant partie du schéma
standard : toute surface fermée représentée par un chemin fermé peut
librement devenir un multipolygon avec les mêmes attributs (juste le tag
"type=multipolygon" ajouté, les chemins membres devant comprendre au moins
un way avec un rôle "outer", et leurs attributs transférés vers la relation)
Ici il n'a pas prévu cette possibilité et donc ne trace que le filaire.
Les autres rendus tracent les deux : les surfaces, et par dessus (en plus)
le filaire qui comble les trous non couverts par les surfaces, dont
notamment les chemins souterrains (qui peuvent passer sous des surfaces qui
ne sont pas des riverbank comme des constructions de barrages, des parties
construites, ou de véritables tunnels naturels ou artificiels y compris les
"culvert" sous une voirie, ou des dérivations alimentant un canal ou
déviant une partie des eaux d'une agglomération pour limiter le risque
d'inondation, par des canaux intermittents).
Il semble donc que Positron lui ait fait le choix de ne faire le rendu que
du filaire, et des surfaces mais seulement si elles sont des polygones
fermés (ce qui n'est pas le cas partout, il a oublié qu'il pouvait y avoir
aussi des relations "multipolygon"). Bref c'est un bogue de Positron, pas
d'OSM.

Le jeu. 18 oct. 2018 à 23:57, François Lacombe 
a écrit :

> Bonsoir,
>
> Une petite question sur les deux relations qui qualifient Le Rhône :
> La 1ere pour sur le filaire river :
> https://www.openstreetmap.org/way/34907146
> La 2nd sur le riverbank, un multipolygon sur tout le court du fleuve :
> https://www.openstreetmap.org/relation/660056
>
> Je ne comprends pas l'intérêt de la deuxième.
> Ne faudrait-il pas mettre le wikidata sur la 1ere relation et supprimer la
> 2nde pour ne laisser que des polygones riverbanks continus sans relation ?
>
> On dirait que ça met le bazar sur des rendus comme Positron :
> https://www.maptiler.com/maps/#positron//vector/15.12/5.81699/46.054843
> (même si on ne tag pas pour le rendu)
>
> Merci par avance pour vos retours, bonne soirée
>
> François
> ___
> 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] Relation de riviere, Le Rhone

[Philippe Verdy]

Les multipolygons des riverbanks arrivent justement parce que tous les
riverbanks ne sont pas des polygones fermés et ont du à un moment être
découpés (à cause des difficultés liées aux superpositions des ways avec
divers autres polygons attenants, mais aussi parce qu'il y a assez souvent
aussi des iles à exclure au milieu).
Globalement les riverbanks doivent être tagués comme surfaces. Mais leur
géométrie cadre mal avec le filaire (qui en sont une version simplifiée) et
ont aussi des relations optionelles pour les grouper, et aussi les associer
entre eux (par des membres "tributary", spécifiques qux relations
waterway=*, mais non compatibles avec les relations multipolygon).
On ne peut pas mélanger les ways du filaire et les ways des multipolygon,
cela donne des anomalies entre plus critiques. Si on change le type de
relation waterway en multipolygon, ce multipolygon se retrouve avec des
ways "inner" et "outer" et souvent aussi d'autres sans role, pour les
riverbanks; mais en plus aussi pour le filaire des ways membres
"main_stream" et "secondary_stream", mais encore assez souvent des ways
sans rôle, sui du coup sont ambigus entre l'interprétation surfacique et
l'interprétation filaire.)
Enfin on trouve assez souvent des ways partagés entre le filaire
(waterway=*) et le surfacique (water=riverbank) dans des sections étroites.
C'est difficile de faire cohabiter les deux sans créer diverses anomalies
de géométrie.
Je pense que les relations séparées se justifient et c'est plutôt Poitron
qui a des problèmes à distinguer les deux types et tente de tout mélanger.
On voit ce que cela provoque chez lui.
Il vaut mieux avoir deux relations (d'autant plus que les surfaces des
"riverbank" ne sont pas toujours contigues, car il peut y avoir des parties
de cours d'eau souterraines ou parce que tout le cours d'eau n'a pas été
tagué avec des riverbanks : typiquement pas pour les parties en amont et
diverses sources)
Les relations filaires contiennent aussi d'autres membres optionnels : un
ou plusieurs noeuds de rôle "stream" pour la ou les sources, un membre
relation de rôle "riverbank" associant la relation "riverbank" collectant
toutes les surfaces).
Je pense que c'est une mauvaise idée de tout mélanger dans une seule
relation, cela posera encore plus de problèmes. Ton problème est plutôt une
anomalie spécifique du rendu Positron qui tente d'interpréter ou "réparer"
à sa façon.
Les relations "multipolygon" des surfaces riverbank sont plutôt à laisser
inchangés et entièrement compatibles avec les polygones fermés simples, la
transformation de l'un en l'autre étant possible à tout moment, mais ne
doivent avoir aucun membre supplémentaire (chemins "main_stream", noeuds
"stream", relation "tributary", qui sont pour les relations filaires, où
les chemins membres "*_stream" sont tous orientés, contrairement aux
chemins membres des relations multipolygon de surface).
La complétude du filaire est également bien plus avancée (que celle des
surfaces), elle forme un réseau (ce n'est pas le cas des surfaces riverbank
qui sont toutes parcellaires). La priorité est donnée encore au filaire des
relations "waterway" qui devrait être interconnecté en réseau orienté. les
surfaces c'est un "luxe" supplémentaire ajouté séparément pour représenter
autre chose (globalement l'utilisation du sol).

Le jeu. 18 oct. 2018 à 23:57, François Lacombe 
a écrit :

> Bonsoir,
>
> Une petite question sur les deux relations qui qualifient Le Rhône :
> La 1ere pour sur le filaire river :
> https://www.openstreetmap.org/way/34907146
> La 2nd sur le riverbank, un multipolygon sur tout le court du fleuve :
> https://www.openstreetmap.org/relation/660056
>
> Je ne comprends pas l'intérêt de la deuxième.
> Ne faudrait-il pas mettre le wikidata sur la 1ere relation et supprimer la
> 2nde pour ne laisser que des polygones riverbanks continus sans relation ?
>
> On dirait que ça met le bazar sur des rendus comme Positron :
> https://www.maptiler.com/maps/#positron//vector/15.12/5.81699/46.054843
> (même si on ne tag pas pour le rendu)
>
> Merci par avance pour vos retours, bonne soirée
>
> François
> ___
> 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] Voting Default Language Format

[Christian Quest]

Elle règle une partie des problèmes, mais ne permet pas de gérer du 100%.

Ceci dit, on n'est pas obligé de l'utiliser cette info ou bien le faire
avec intelligence...

Cas du rendu FR: si default:language=fr, je prends les name, sinon je
prends les name:fr

Du coup, on aura bien le "name" sur le territoire français, même si il
n'est pas en français mais occitan ce qui est au final l'objectif
recherché, non ?

Pour savoir véritablement dans quelle langue est name=*, il faut le
comparer aux différents name:xx=* , il n'y a finalement que ça de fiable si
c'est cette info qu'on veut obtenir.


Le ven. 19 oct. 2018 à 12:28, Rpnpif  a écrit :

> Le 19 octobre 2018, rainerU a écrit :
>
> > Bonjour,
> >
> > Je me pose des questions sur l'impact de cette proposition sur les
> objets qui
> > ont un nom officiel en langue régionale :
> >
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
> >
> > Si j'ai bien compris la proposition, on mettrait default:language=fr sur
> la
> > frontière de la France (ou des régions, départements,...) et les
> applications
> > utiliseraient name=fr comme nom standard.
> >
> > A mon avis, cela pose un problème dans les cas où le nom officiel d'un
> objet est
> > en langue régionale mais existe aussi un nom en français. Il y a eu un
> fil de
> > discussion sur cette liste sur la manière de tagguer ces cas avec le
> schéma
> > actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je taggue
> name= > officiel>, name:ca=, name:fr=. Avec le
> schéma
> > proposé, un rendu en langue standard afficherait le nom français et pas
> le nom
> > officiel en catalan. Si par contre on mettait name:fr=, on
> ne
> > pourrait plus créer un rendu 100% français.
> >
> > Est-ce que cette question a déjà été discuté ici ou ailleurs, si oui
> quelle
> > était la conclusion ?
>
> Bonjour,
> Oui je suis d'accord avec toi : ce n'est pas une proposition
> pertinente.
>
> --
> Alain Rpnpif
>
> ___
> 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] Voting Default Language Format

[Rpnpif]

Le 19 octobre 2018, rainerU a écrit :

> Bonjour,
> 
> Je me pose des questions sur l'impact de cette proposition sur les objets qui 
> ont un nom officiel en langue régionale :
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
> 
> Si j'ai bien compris la proposition, on mettrait default:language=fr sur la 
> frontière de la France (ou des régions, départements,...) et les applications 
> utiliseraient name=fr comme nom standard.
> 
> A mon avis, cela pose un problème dans les cas où le nom officiel d'un objet 
> est 
> en langue régionale mais existe aussi un nom en français. Il y a eu un fil de 
> discussion sur cette liste sur la manière de tagguer ces cas avec le schéma 
> actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je taggue 
> name= officiel>, name:ca=, name:fr=. Avec le schéma   
> proposé, un rendu en langue standard afficherait le nom français et pas le 
> nom 
> officiel en catalan. Si par contre on mettait name:fr=, on ne 
> pourrait plus créer un rendu 100% français.
> 
> Est-ce que cette question a déjà été discuté ici ou ailleurs, si oui quelle 
> était la conclusion ?

Bonjour,
Oui je suis d'accord avec toi : ce n'est pas une proposition
pertinente.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[Noémie Lehuby]

Salut Paul,

On est quasiment d'accord !

Mon plan était de commencer par la proposition de Marc de transformer
toutes les amenity=swimming_pool en leisure=swimming_pool comme première
étape.

Puis de faire ce que tu décris, mais sur les leisure=swimming_pool,
puisque comme tu l'as indiqué, il y a aussi des leisure=swimming_pool
qui devraient être leisure=sports_centre. 

Noémie 

Le 2018-10-19 08:42, Paul Desgranges a écrit :

> Bonjour,
> Je n'avais peut-être pas compris le sens du mail de Noémie, et je cherche 
> ci-dessous à le ré-exprimer, voir si on est d'accord :
> 
> L'idée principale consiste à transformer les  "amenity=swimming_pool" 
> soit en "leisure=sports_centre + sport=swimming", 
> soit en "leisure=swimming_pool" 
> 
> Et ceci suivant les heuristiques suivantes :
> 
> 1) Par exemple on peut transformer 
> les "amenity=swimming_pool + name=*" [1] en "leisure=sports_centre + 
> sport=swimming" 
> et les "amenity=swimming_pool + name!=*" [2] en "leisure=swimming_pool" 
> car effectivement quand il y a un nom, c'est un "sports_centre" et quand il 
> n'y a pas de nom, c'est un simple bassin.
> 
> 2) Autre exemple on peut transformer 
> les "amenity=swimming_pool + building=yes" [1] en "leisure=sports_centre + 
> sport=swimming + building=yes" 
> car quand il y a aussi un building, c'est un "sports_centre". A noter que 1) 
> et 2) vont se recouvrir en partie. 
> 
> 3) Il y a des heuristiques sur la taille aussi comme disait Jérôme:
> Quand c'est "petit", c'est plutôt un bassin.
> Quand c'est "grand", c'est plutôt  un sports_centre
> Mais là, a-t-on la possibilité de faire une requête overpass turbo pour les 
> sélectionner sur ce critère de taille? 
> 
> D'autre part, si les "amenity=swimming_pool" sont à éliminer, on peut aussi 
> transformer :
> les "leisure=swimming_pool + building=yes" [3] en "leisure=sports_centre + 
> sport=swimming + building=yes" 
> car les piscines qui sont aussi des buildings sont en fait des 
> "sports_centre". Les contributeurs ont taggué par erreur en "bassin" ce qui 
> plutôt des "sports_centre".  
> 
> Et les transformations ci-dessus seraient à faire avant de faire celles 
> relatives à "covered" (et qui qui sont discutées dans l'autre mail ?) 
> 
> Voilà, y-a-t-il des erreurs ? Est-ce plus clair ? 
> 
> Paul 
> 
> Le 15/10/2018 à 23:04, Paul Desgranges a écrit : 
> 
>> Bonsoir,
>> 
>>> Le 14. 10. 18 à 22:12, Paul Desgranges a écrit :
 Un truc en plus, le terme 'piscine' de manière générale peut signifier à 
 la fois le bassin, le bâtiment, mais aussi le complexe sportif :
 - "leisure=swimming_pool" seul, donc ça serait le bassin, mais 
 "leisure=swimming_pool" + "building=yes" là on parlerait du 'bâtiment 
 piscine'  (le bassin est alors parfois à l'extérieur)
>>> 
>>> cette interprétation me semble erronée.
>>> leisure=swimming_pool est selon moi clairement définit comme étant le 
>>> bassin.
>>> "leisure=swimming_pool" + "building=yes c'est donc un bassin "couvert" 
>>> par un bâtiment. c'est assez rare mais j'en connais un : je suis passé 
>>> plusieurs fois devant en me demandant si c'était un garage entière vitré 
>>> ou une serre en dur... avant d'un jour apercevoir que l'intérieur est 
>>> entièrement constitué d'un bassin d'eau (piscine privé).
>>> si le bassin n'est pas dans le bâtiment, il faut selon moi 2 objets.
>> 
>> Ce n'est pas rare du tout :-) il y en a des centaines, si je l'ai dit c'est 
>> que j'avais regardé avant.
>> Je ne suis pas passé devant ;-) j'ai regardé ici 
>> https://overpass-turbo.eu/s/CMB  
>> Les contributeurs ont assez largement utilisé cette façon pour mapper les 
>> piscines-bâtiments (bâtiments qui contiennent une piscine). 
>> C'est effectivement une interprétation erronée, mais certainement pas de 
>> moi, des contributeurs plutôt 
>> qui auraient dû mapper ça comme ça : "leisure=sports_centre" + 
>> "sport=swimming"
>> Ce que je voulais dire par => on a souvent le cas : "leisure=sports_centre" 
>> + "sport=swimming" = "leisure=swimming_pool" + "building=yes"
>> 
>>> Salut,
>>> 
>>> Du coup, je pense qu'on peut imaginer un plan d'action comme ça :
>>> - modification massive de amenity=swimming_pool vers 
>>> leisure=swimming_pool comme proposé par Marc
>>> - analyse Osmose qui vérifie la taille des leisure=swimming_pool et 
>>> remonte un signalement quand c'est vraiment trop grand (en utilisant la 
>>> formule de Jérôme)
>>> - mission maproulette pour identifier des leisure=swimming_pool qui 
>>> devraient en fait être des leisure=sports_centre
>>> 
>>> Pour le dernier point, j'ai l'impression qu'en cherchant les 
>>> leisure=swimming_pool qui ont un tag name, on tombe principalement sur 
>>> des éléments mal taggés qui devraient être des sports_centre, on doit 
>>> pouvoir broder autour de ça pour Maproulette, même si on aura quelques 
>>> faux positifs.
>> Oui, dans les trois cas ci-dessus on peut en trouver beaucoup déjà avec 
>> "leisure=swimming_pool" + "building=yes"
>> 
>>> 
>>> Qu'en 

Re: [OSM-talk-fr] Osmose - École non intégrée

[Christian Quest]

J'ai rencontré il y a peu la personne qui s'occupe de maintenir la première
base (établissements du 1er et 2nd degré) et on n'a absolument pas parlé du
reste qui doit être hors de son périmètre.

Donc, le plus probable c'est que chaque base est gérée séparément, pas
différents services, et que le site que tu indiques à la fin agrège tout ça
pour permettre une recherche.


Le jeu. 18 oct. 2018 à 19:33, deuzeffe  a écrit :

> On 10/18/18 9:56 AM, Christian Quest wrote:
> > Ces mentions sont normales (même si elles datent un peu) et
> correspondent à
> > la Licence Ouverte, c'est donc tout à fait réutilisable pour OSM.
>
> Merci pour la confirmation :)
>
> > Qu'est-ce qui est ventilé façon puzzle sur data.gouv ? Des liens seraient
> > utiles...
>
> Les bases "enseignement" qu'osmose utilise pour l'OD. Par exemple :
> - producteur MEN :
> -- enseignement primaire (écoles maternelles et élémentaire), ici :
>
> https://www.data.gouv.fr/fr/datasets/adresse-et-geolocalisation-des-etablissements-denseignement-du-premier-et-second-degres/
> -- enseignement secondaire (collèges et lycées) : même base
>
> Jusque là, tout va bien.
>
> - producteur : ONISEP
> -- Enseignement supérieur : "établissements" (entre quote parce qu'il y
> manque les établissements au sens administratif du terme, voir le
> descriptif du jeu de données) :
>
> https://www.data.gouv.fr/fr/datasets/etablissements-denseignement-superieur-2
> ()
>
> Ce que n'utilise pas osmose :
> - source MESRI
> -- les rectorats :
>
> https://www.data.gouv.fr/fr/datasets/les-rectorats-dacademies-et-vice-rectorats/
>
> -- les BU (2 jeux) :
>
> https://www.data.gouv.fr/fr/datasets/bibliotheques-de-lenseignement-superieur/
> et
>
> https://www.data.gouv.fr/fr/datasets/services-de-documentation-et-sieges-des-bibliotheques-de-lenseignement-superieur/
> -- les implantations des établissement publics d'ens. sup. avec les UFR
> (entre autres) :
>
> https://www.data.gouv.fr/fr/datasets/implantations-des-etablissements-denseignement-superieur-publics/
> -- les principaux établissements d'ens. sup. :
>
> https://www.data.gouv.fr/fr/datasets/principaux-etablissements-denseignement-superieur/
>
> Et plein d'autres bases que je n'ai pas eu le temps de chercher.
>
> Cependant, une rapide recherche sur acce
> (http://www.education.gouv.fr/acce_public/index.php ) montre que tout ça
> y est déjà plus plein d'autres services/établissements/UA du domaine
> éducation. Soit il n'y a qu'une seule base, soit une métabase, soit...
>
> Bref, dommage qu'on ne puisse pas intégrer (intégrer, j'ai dit !) plus
> de choses plus finement par manque d'interopérabilité (?). Même s'il
> faut de la découpe pour les fines analyses réalisées par osmose.
>
> --
> deuzeffe, archiviste ou bibliothécaire, suivant les heures.
>
> ___
> 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

[OSM-talk-fr] Voting Default Language Format

[rainerU]

Bonjour,

Je me pose des questions sur l'impact de cette proposition sur les objets qui 
ont un nom officiel en langue régionale :


https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format

Si j'ai bien compris la proposition, on mettrait default:language=fr sur la 
frontière de la France (ou des régions, départements,...) et les applications 
utiliseraient name=fr comme nom standard.


A mon avis, cela pose un problème dans les cas où le nom officiel d'un objet est 
en langue régionale mais existe aussi un nom en français. Il y a eu un fil de 
discussion sur cette liste sur la manière de tagguer ces cas avec le schéma 
actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je taggue name=officiel>, name:ca=, name:fr=. Avec le schéma 
proposé, un rendu en langue standard afficherait le nom français et pas le nom 
officiel en catalan. Si par contre on mettait name:fr=, on ne 
pourrait plus créer un rendu 100% français.


Est-ce que cette question a déjà été discuté ici ou ailleurs, si oui quelle 
était la conclusion ?




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

Re: [OSM-talk-fr] Changesets étranges

[Jean-Christophe Becquet]

Le 19/10/2018 08:48, Antoine Riche a écrit :
> Le 19/10/2018 à 07:25, Jean-Christophe Becquet a écrit :
>> Y a t-il un moyen de retrouver les changesets sur lesquels j'ai laissé
>> un message ?
> 
> Le site https://hdyc.neis-one.org/ de Pascal Neis inclut une rubrique
> "Changeset discussions", avec un lien qui liste les commentaires créés.

Merci Antoine !

Il s'agissait donc du changeset suivant, commentaire resté sans réponse
https://www.openstreetmap.org/changeset/55099941

JCB
-- 
Debian GNU-Linux
http://www.apitux.org/index.php?2006/07/10/15-debian-gnu-linux

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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

Re: [OSM-talk-fr] Changesets étranges

[Antoine Riche]

Le 19/10/2018 à 07:25, Jean-Christophe Becquet a écrit :

Y a t-il un moyen de retrouver les changesets sur lesquels j'ai laissé
un message ?


Le site https://hdyc.neis-one.org/ de Pascal Neis inclut une rubrique 
"Changeset discussions", avec un lien qui liste les commentaires créés.


Antoine.


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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[Paul Desgranges]

Oui, une façon de tagguer ces piscines tournesols ou à toits 
rétractables (qui sont ni location=indoor et ni location=outdoor) est en 
plus nécessaire, mais
 ceci ne doit pas nous empêcher de mapper la très grande majorité de 
piscines qui sont soit des piscines indoor, soit des piscines outdoor ...


Il faut voir si on arrive à se mettre d'accord sur le sens de "covered" 
pour les piscines ?
La proposition serait de réserver l'attribut "covered" aux bassins de 
piscines, et de lui faire signifier la présence ou pas d'un abri-piscine:
 c'est à dire qu'on réserverait ça aux piscines-bassins 
(leisure=swimming_pool),
  et donc que ça n'aurait pas lieu d'être sur les piscines-bâtiments 
(leisure=sports_centre + sport=swimming)

Dans cette logique, il faudrait transformer :
    les "leisure=sports_centre + sport=swimming + covered=yes" 
 en "leisure=sports_centre + 
sport=swimming + location=indoor"
et les "leisure=sports_centre + sport=swimming + covered=no" 
  en "leisure=sports_centre + 
sport=swimming + location=outdoor"



Mais ceci serait à faire après la transformation (discutée par Noémie, 
Marc, Jérôme, ...) qui consisterait à transformer les 
"amenity=swimming_pool" soit en "leisure=sports_centre + 
sport=swimming", soit en "leisure=swimming_pool" suivant quelques 
heuristiques, voir l'autre fil de discussion ...


Paul


Le 16/10/2018 à 13:50, Philippe Verdy a écrit :
C'est un modèle assez courant de piscine fermé à toit mobile. J'en 
avais déjà parlé avant


Le mar. 16 oct. 2018 à 09:35, Christian Quest > a écrit :


Désolé, je vais casser l'ambiance en sortant ma "piscine tournesol":


https://2.bp.blogspot.com/-mhCVrMV3K-8/UX2VXYXJUgI/A0g/fwvAWxZV4rI/s1600/Nangis_2.jpg

;)


Le mar. 16 oct. 2018 à 09:17, Paul Desgranges
mailto:desgranges.p...@laposte.net>>
a écrit :

Là-aussi je me suis mal fait comprendre peut-être alors je
vais essayer de faire mieux (puisqu'on est dans les piscines
)

A propos de indoor/outdoor et covered=yes/no, il y a aussi
plusieurs façons de faire actuellement. En tout cas si on
parle de "leisure=swimming_pool" (donc pour les piscines de
type "bassin")
    1. le bassin peut être à l'intérieur ou à l'extérieur, pas
trop de confusion possible
    - bassin intérieur => "location=indoor" : pas visible par
photo aérienne, on est dans un bâtiment, c'est du mapping
indoor, (mais il y en a des mappés comme ça )
    - bassin extérieur => "location=outdoor" : visible par
photo aérienne, ça pourrait être la valeur par défaut, mais
c'est plus explicite qd ça y est

   2. le bassin peut être "couvert" ou pas. De manière
générale, en dehors d'OSM, quand on dit "bassin couvert" on
veut dire "bassin intérieur" et "bassin découvert" on veut
dire bassin extérieur, donc il y a une confusion possible et
on peut la constater dans les faits.
    Actuellement "covered=yes" a été employé manifestement
dans différents cas :
    - Soit le contributeur a voulu signifier que la piscine
était "couverte" au sens bassin intérieur
    - Soit le contributeur a voulu signifier que la piscine
était "couverte" au sens la piscine dispose d'un "abri
piscine" (on distingue bien ces abris en photographie
aérienne), les piscines privées dans les jardins, avec un abri
pour : sécurité chute, déperdition d'énergie, feuilles mortes,
etc.
    Et "covered=no" est assez employé, mais dans quelle
intention a été utilisé ce tag, s'agit-il d'un bassin
extérieur, ou s'agit-il d'un bassin ne disposant pas d'abri ?
Pas forcément clair.

  Alors comment documenter ces 2 attributs
("location=indoor/outdoor" et "covered=yes/no") pour que
l'usage en soit clair ?

Bonne journée
Paul


-- 
Christian Quest - OpenStreetMap France

___
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] Piscine municipale vs piscine privée

[Paul Desgranges]

Bonjour,
Je n'avais peut-être pas compris le sens du mail de Noémie, et je 
cherche ci-dessous à le ré-exprimer, voir si on est d'accord :


L'idée principale consiste à transformer les "amenity=swimming_pool"
    soit en "leisure=sports_centre + sport=swimming",
    soit en "leisure=swimming_pool"

Et ceci suivant les heuristiques suivantes :

1) Par exemple on peut transformer
    les "amenity=swimming_pool + name=*" 
 en "leisure=sports_centre + 
sport=swimming"
et les "amenity=swimming_pool + name!=*" 
 en "leisure=swimming_pool"
car effectivement quand il y a un nom, c'est un "sports_centre" et quand 
il n'y a pas de nom, c'est un simple bassin.


2) Autre exemple on peut transformer
    les "amenity=swimming_pool + building=yes" 
 en "leisure=sports_centre + 
sport=swimming + building=yes"
car quand il y a aussi un building, c'est un "sports_centre". A noter 
que 1) et 2) vont se recouvrir en partie.


3) Il y a des heuristiques sur la taille aussi comme disait Jérôme:
 Quand c'est "petit", c'est plutôt un bassin.
 Quand c'est "grand", c'est plutôt  un sports_centre
Mais là, a-t-on la possibilité de faire une requête overpass turbo pour 
les sélectionner sur ce critère de taille?



D'autre part, si les "amenity=swimming_pool" sont à éliminer, on peut 
aussi transformer :
    les "leisure=swimming_pool + building=yes" 
 en "leisure=sports_centre + 
sport=swimming + building=yes"
 car les piscines qui sont aussi des buildings sont en fait des 
"sports_centre". Les contributeurs ont taggué par erreur en "bassin" ce 
qui plutôt des "sports_centre".



Et les transformations ci-dessus seraient à faire avant de faire celles 
relatives à "covered" (et qui qui sont discutées dans l'autre mail ?)


Voilà, y-a-t-il des erreurs ? Est-ce plus clair ?

Paul




Le 15/10/2018 à 23:04, Paul Desgranges a écrit :

Bonsoir,

>Le 14. 10. 18 à 22:12, Paul Desgranges a écrit :
>>/Un truc en plus, le terme 'piscine' de manière générale peut signifier à />>/la fois le bassin, le bâtiment, mais aussi le 
complexe sportif : />>/ - "leisure=swimming_pool" seul, donc ça serait le bassin, mais 
/>>/"leisure=swimming_pool" + "building=yes" là on parlerait du 'bâtiment />>/piscine'  (le bassin est alors 
parfois à l'extérieur) />
>cette interprétation me semble erronée.
>leisure=swimming_pool est selon moi clairement définit comme étant le bassin.
>"leisure=swimming_pool" + "building=yes c'est donc un bassin "couvert" 
>par un bâtiment. c'est assez rare mais j'en connais un : je suis passé 
>plusieurs fois devant en me demandant si c'était un garage entière vitré 
>ou une serre en dur... avant d'un jour apercevoir que l'intérieur est 
>entièrement constitué d'un bassin d'eau (piscine privé).

> si le bassin n'est pas dans le bâtiment, il faut selon moi 2 objets.

Ce n'est pas rare du tout :-) il y en a des centaines, si je l'ai dit c'est que 
j'avais regardé avant.
Je ne suis pas passé devant ;-) j'ai regardé icihttps://overpass-turbo.eu/s/CMB   
Les contributeurs ont assez largement utilisé cette façon pour mapper les piscines-bâtiments (bâtiments qui contiennent une piscine).

C'est effectivement une interprétation erronée, mais certainement pas de moi, 
des contributeurs plutôt
qui auraient dû mapper ça comme ça : "leisure=sports_centre" + "sport=swimming"
Ce que je voulais dire par => on a souvent le cas : "leisure=sports_centre" + "sport=swimming" = 
"leisure=swimming_pool" + "building=yes"


>Salut,
>
>Du coup, je pense qu'on peut imaginer un plan d'action comme ça :
>- modification massive de amenity=swimming_pool vers 
> leisure=swimming_pool comme proposé par Marc
>- analyse Osmose qui vérifie la taille des leisure=swimming_pool et 
>remonte un signalement quand c'est vraiment trop grand (en utilisant la 
>formule de Jérôme)
>- mission maproulette pour identifier des leisure=swimming_pool qui 
>devraient en fait être des leisure=sports_centre

>
>Pour le dernier point, j'ai l'impression qu'en cherchant les 
>leisure=swimming_pool qui ont un tag name, on tombe principalement sur 
>des éléments mal taggés qui devraient être des sports_centre, on doit 
>pouvoir broder autour de ça pour Maproulette, même si on aura quelques 
>faux positifs.

Oui, dans les trois cas ci-dessus on peut en trouver beaucoup déjà avec 
"leisure=swimming_pool" + "building=yes"

>
>Qu'en dites-vous ?

Bien d'accord !
  
  --

Noémie Lehuby
Donc l'idée




___
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