date:20130403

Pour les wikipedia=fr=* le problème est surtout de les identifier,
c'est à dire de retrouver les objets correspondants... et visiblement
XAPI se mélange les crayons lorsqu'on a un '=' dans la clé.

Je les ai retrouvé via une base postgis/osm2pgsql et les fautifs sont
maintenant corrigés.


Pour ce projet du mois, on peut aussi dire merci à Osmose et ses
soutiers qui sont au charbon quotidiennement.

-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

[OSM-talk-fr] Usage de relations pour les parcs urbains...

2013-04-03 Per discussione Thomas Williamson

Bonjour,

Je souhaiterais affiner la cartographie d'un parc urbain situé proche de
chez moi et j'hésite toujours à avoir recours aux relations, de peur de
faire des bêtises... Plusieurs types de polygones sont présents dans ce
parc : bâtiments, zones boisées, pelouses, aires de jeux, etc. Quelle est
la meilleure approche ? Un polygone global (type = multipolygon et name =
Parc des Prés Mignons, avec des polygones intérieurs role = inner) ? Merci
pour vos conseils !

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

Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses =?iso-8859-15?q?_donn=E9s=3F?=)

2013/4/2 Brice Person brice.per...@zenordi.fr

 Pour éviter toutes ambiguïtés, il faut que les acteurs soient ok pour que
 les données soient redistribuées sous les conditions de l'ODbL. Donc pour
 la France il vaut mieux que les acteurs utilisent directement l'ODbL ou une
 licence reconnue pour être compatible comme la LO d'Etalab (plus
 permissive). Je sais ça ne fait pas des masses de choix mais c'est tant
 mieux :-)


A ce compte là, il faut tout de suite arrêter d'utiliser le cadastre. En
effet, la condition la plus restrictive du cadastre est que le produit
final soit un produit composite. Hors, on ne peut garantir que localement
le cadastre soit l'unique source d'information cartographique.
Il ne faut pas perdre de vue l'objectif d'une licence. Cette clause de non
altération sert avant tout à protéger le fournisseur de tous recours en cas
de litiges (si la donnée est fausse parce que modifiée, c'est pas ma
faute). Mais si ce genre de clause va à l'encontre de l'opendata, je ne
sais pas si elle est prise en compte dans les textes actuels (directive
inspire). Les restrictions sur la libération des données doivent avoir une
réelle justification. L'avis d'un spécialiste serait bienvenue ici.


 L'ODbL n'était pas encore traduite en droit Français et Etalab n'existait
 pas.


Je ne sais pas trop ce que veut dire traduite en droit français. Si c'est
pour dire, elle est validée par un texte de loi ou fait référence à des
textes de lois français, ça n'est pas le cas. Si c'est pour dire, elle
est validée par un juge, ça n'est pas le cas non plus. Tout ce qu'on peut
dire, c'est qu'elle a été validée par des experts juridiques au niveau de
certaines administrations qui ont décidé d'adopter cette licence pour leurs
données.
Quant à la licence LO/OL d'Etalab, elle peut aussi poser problème dans OSM
si on veut couper les cheveux en quatre (puisqu'on en arrive là). En effet,
elle contient, comme ODbL, une obligation de mentionner la source. Hors,
cette mention est souvent attachée aux objets eux-mêmes (tag source) et
rien ne garantit leur pérennité dans la bdd.

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

Re: [OSM-talk-fr] Usage de relations pour les parcs urbains...

Tu parle bien de ce parc ?
http://www.openstreetmap.org/?lat=46.56382lon=0.31454zoom=17

Pourquoi faire compliqué quand on peut faire simple ?

Le parc c'est quoi ? Un grand polygone avec dedans différentes choses
(bâtiments, aires de jeu, bassin, etc) ?

Dans ce cas, pourquoi ne pas simplement avoir un polygone englobant
avec leisure=park name=Parc des Prés Mignons

Quelle serait l'apport d'une relation ?

Elle sont utiles lorsque qu'il n'y a pas de lien géographique
implicite entre les objets, là le lien géographique est déjà là.

Le bassin, les pelouse, les aires de jeu dans le parc ne fait pas
partie de celui-ci ? Pourquoi vouloir les mettre en inner ?

Bien sûr, si le parc était coupé en deux par une voie ferrée ou une
autoroute ou une rivière ou autre, ce polygone pourrait devenir un
multipolygone via une relation multipolygon.

Eventuellement... le bassin est en inner d'un multipolygone qui décrit
les pelouses... et encore, ça se discute.


Le 3 avril 2013 09:31, Thomas Williamson wilt...@gmail.com a écrit :
 Bonjour,

 Je souhaiterais affiner la cartographie d'un parc urbain situé proche de
 chez moi et j'hésite toujours à avoir recours aux relations, de peur de
 faire des bêtises... Plusieurs types de polygones sont présents dans ce parc
 : bâtiments, zones boisées, pelouses, aires de jeux, etc. Quelle est la
 meilleure approche ? Un polygone global (type = multipolygon et name = Parc
 des Prés Mignons, avec des polygones intérieurs role = inner) ? Merci pour
 vos conseils !

 Thomas

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




-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] Usage de relations pour les parcs urbains...

2013-04-03 Per discussione Jean-Baptiste Holcroft

Je crois que cette question illustre bien la nécessité de developer les
pages du wiki sur la question.
Actuellement il y a une explication basique et une longue contre les
catégories Wikipedia ;)
Peut-être qu'il faudrait ajouter un paragraphe pour les nuls avec des
illustrations de cas d'école de quand les utiliser de façon pertinente.
As tu trouvé ces pages Thomas ?
Le 3 avr. 2013 10:34, Christian Quest cqu...@openstreetmap.fr a écrit :

 Tu parle bien de ce parc ?
 http://www.openstreetmap.org/?lat=46.56382lon=0.31454zoom=17

 Pourquoi faire compliqué quand on peut faire simple ?

 Le parc c'est quoi ? Un grand polygone avec dedans différentes choses
 (bâtiments, aires de jeu, bassin, etc) ?

 Dans ce cas, pourquoi ne pas simplement avoir un polygone englobant
 avec leisure=park name=Parc des Prés Mignons

 Quelle serait l'apport d'une relation ?

 Elle sont utiles lorsque qu'il n'y a pas de lien géographique
 implicite entre les objets, là le lien géographique est déjà là.

 Le bassin, les pelouse, les aires de jeu dans le parc ne fait pas
 partie de celui-ci ? Pourquoi vouloir les mettre en inner ?

 Bien sûr, si le parc était coupé en deux par une voie ferrée ou une
 autoroute ou une rivière ou autre, ce polygone pourrait devenir un
 multipolygone via une relation multipolygon.

 Eventuellement... le bassin est en inner d'un multipolygone qui décrit
 les pelouses... et encore, ça se discute.


 Le 3 avril 2013 09:31, Thomas Williamson wilt...@gmail.com a écrit :
  Bonjour,
 
  Je souhaiterais affiner la cartographie d'un parc urbain situé proche de
  chez moi et j'hésite toujours à avoir recours aux relations, de peur de
  faire des bêtises... Plusieurs types de polygones sont présents dans ce
 parc
  : bâtiments, zones boisées, pelouses, aires de jeux, etc. Quelle est la
  meilleure approche ? Un polygone global (type = multipolygon et name =
 Parc
  des Prés Mignons, avec des polygones intérieurs role = inner) ? Merci
 pour
  vos conseils !
 
  Thomas
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-fr
 



 --
 Christian Quest - OpenStreetMap France
 Synthèse du Week-end SOTM-FR à Lyon :
 http://openstreetmap.fr/synthese-sotmfr

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

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

Re: [OSM-talk-fr] Usage de relations pour les parcs urbains...

 

J'en profite pour une question qui me taraude : un lac au milieu
d'un landuse=forest, faut-il l'exclure du landuse (multipolygon), ou
peuvent-ils se superposer ? 

JB.

Le 03.04.2013 10:02, Christian Quest
a écrit : 

 Tu parle bien de ce parc ?

http://www.openstreetmap.org/?lat=46.56382lon=0.31454zoom=17 [2]
 

Pourquoi faire compliqué quand on peut faire simple ?
 
 Le parc c'est
quoi ? Un grand polygone avec dedans différentes choses
 (bâtiments,
aires de jeu, bassin, etc) ?
 
 Dans ce cas, pourquoi ne pas
simplement avoir un polygone englobant
 avec leisure=park name=Parc des
Prés Mignons
 
 Quelle serait l'apport d'une relation ?
 
 Elle sont
utiles lorsque qu'il n'y a pas de lien géographique
 implicite entre
les objets, là le lien géographique est déjà là.
 
 Le bassin, les
pelouse, les aires de jeu dans le parc ne fait pas
 partie de celui-ci
? Pourquoi vouloir les mettre en inner ?
 
 Bien sûr, si le parc était
coupé en deux par une voie ferrée ou une
 autoroute ou une rivière ou
autre, ce polygone pourrait devenir un
 multipolygone via une relation
multipolygon.
 
 Eventuellement... le bassin est en inner d'un
multipolygone qui décrit
 les pelouses... et encore, ça se discute.


 Le 3 avril 2013 09:31, Thomas Williamson wilt...@gmail.com a écrit
:
 
 Bonjour, Je souhaiterais affiner la cartographie d'un parc
urbain situé proche de chez moi et j'hésite toujours à avoir recours aux
relations, de peur de faire des bêtises... Plusieurs types de polygones
sont présents dans ce parc : bâtiments, zones boisées, pelouses, aires
de jeux, etc. Quelle est la meilleure approche ? Un polygone global
(type = multipolygon et name = Parc des Prés Mignons, avec des polygones
intérieurs role = inner) ? Merci pour vos conseils ! Thomas
___ Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr [1]




Links:
--
[1] http://lists.openstreetmap.org/listinfo/talk-fr
[2]
http://www.openstreetmap.org/?lat=46.56382amp;lon=0.31454amp;zoom=17
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet Wikipedia, résultats

Le 3 avril 2013 08:46, Jo. perche...@gmail.com a écrit :
 Ps : est ce qu'une édition avec rawedit permet d'éditer ces 2 tags
 wikipedia=fr ?

Bien sûr, et c'est même plus rapide et facile à faire par là. Il faut
cependant savoir lire du XML

Rawedit ne devrait pas être utilisé pour éditer autre chose que les
lignes de tags présents.

Note: Parfois pour valider il faut remplacer certains caractères qui
sont envoyés à l'éditeur par rawedit sous une forme qui n'est pas du
XML valide (notamment les  présents parfois dans les autres tags
doivent être remplacés sous la forme amp; car sinon l'envoi des
données ne marche pas. Rawedit a ce bogue depuis longtemps, déjà
signalé, mais non corrigé. On trouve le plus souvent les  dans des
noms de magasins comme name=CA, et dans des tags 'source=*,
url=* ou source= contenant une URL avec une querystring.

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

Re: [OSM-talk-fr] Usage de relations pour les parcs urbains...

Le 3 avril 2013 11:05, JB jb...@mailoo.org a écrit :
 J'en profite pour une question qui me taraude : un lac au milieu d'un
 landuse=forest, faut-il l'exclure du landuse (multipolygon), ou peuvent-ils
 se superposer ?

Assez souvent les moteurs de rendu se débrouillent bien malgré la
superposition mais effectivement dans certains cas il faut fairedes
exclusions avec des polygones inner car sémantiquement cela pose un
problème d'interprétation des données si la polygone externe est un
landuse=* et que le polygone interne est aussi un landuse=*.

Dans ce cas il y a conflit entre les valeurs, et on n'a pas le choix
pour le résoudre que de créer un multipolygone pour le polygone
externe (on déplace alors tous les attributs du polygone externe vers
la relation type=multipolygon, le polygone externe devenant un
membre de rôle outer, tandis que les tags du polygone interne n'a
pas besoin d'être modifié mais peut être référencé en membre inner.

Osmose signale ces cas où il y a conflit entre les valeurs de tags en
contradiction entre polygones qui ont une intersection non vide et
ayant des tags en contradiction.

En principe si on est rigoureux, cela devrait aussi être fait pour les
tags name=* qui eux aussi peuvent être en conflits : quel est le nom
effectivement utilisé pour désigner ce qui est dans le polygone
interne ?

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

Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

Le 3 avril 2013 08:40, Jo. perche...@gmail.com a écrit :
 De toute façon le changset dont tu parlait ne c'est pas fermé une heure
 après mais 20 min de plus qu'indiqué :
 http://www.openstreetmap.org/browse/changeset/15569811

 En gros il n'y avait pas de problème dû à l'heure d'été sur celui que tu
 citait. Ou sinon les anglais sont sur un autre fuseau horaire :-D

Non tu te trompes là encore, c'est moi qui ait fermé cette relation
modifiée sous JOSM, explicitement depuis JOSM (CTRL+ALT+Q), après
avoir envoyé les modifs objet par objet. Et bel et bien une heure
avant celle indiquée. L'heure de fermeture réelle affiché est bien
décalée avec une heure de retard sur la réalité.

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

[OSM-talk-fr] Parcs urbains : pelouses et boisements

2013-04-03 Per discussione Thomas Williamson

Re-bonjour,

Toujour à propos de parcs urbains. Si j'ai un polygone englobant (contour
du parc) avec leisure = park, et que je distingue les pelouses des
boisements, je vais avoir un polygone sur lequel vont venir se superposer
des polygones (par exemple, des landuse = grass et landuse = forest).
Dois-je mettre les polygones jointifs ou la superposition est-elle possible
?

Merci encore !

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

Re: [OSM-talk-fr] Usage de relations pour les parcs urbains...

Je ne vois pas l'utilité de faire un tel mitage.

Le lac fait partie de la forêt et si on regarde les différentes
ré-utilisation des données ça donne:
- le rendu: s'en sort bien (en dessinant les grandes surface avant les
petites et aussi en dessinant aussi la couche hydro par dessus
l'occupation des sols)
- pour des stats, la surface de la forêt correspond bien au polygone y
compris le lac... et si on veut connaitre le détail des différents
types de surfaces (boisée, plan d'eau, clairière) on peut faire le
calcul facilement.

Et pourquoi exclure le lac mais pas les différents riverbank des cours
d'eau ? il faut pousser la logique à l'extrême pour voir si c'est bien
logique ;)

Pour moi même une clairière dans la forêt je ne la met pas en inner,
car même si elle n'est pas plantée d'arbre, elle fait bien partie de
la forêt.

De plus maintenir les relations bien à jour n'est pas donné à tout le
monde et donc même si sur un plan conceptuel c'est parfois plus
clean, ça complique beaucoup trop l'édition pour le contributeur peu
expérimenté... d'où souvent le problème de maintenance des relations.


Le 3 avril 2013 11:05, JB jb...@mailoo.org a écrit :
 J'en profite pour une question qui me taraude : un lac au milieu d'un
 landuse=forest, faut-il l'exclure du landuse (multipolygon), ou peuvent-ils
 se superposer ?

 JB.



 Le 03.04.2013 10:02, Christian Quest a écrit :

 Tu parle bien de ce parc ?
 http://www.openstreetmap.org/?lat=46.56382lon=0.31454zoom=17

 Pourquoi faire compliqué quand on peut faire simple ?

 Le parc c'est quoi ? Un grand polygone avec dedans différentes choses
 (bâtiments, aires de jeu, bassin, etc) ?

 Dans ce cas, pourquoi ne pas simplement avoir un polygone englobant
 avec leisure=park name=Parc des Prés Mignons

 Quelle serait l'apport d'une relation ?

 Elle sont utiles lorsque qu'il n'y a pas de lien géographique
 implicite entre les objets, là le lien géographique est déjà là.

 Le bassin, les pelouse, les aires de jeu dans le parc ne fait pas
 partie de celui-ci ? Pourquoi vouloir les mettre en inner ?

 Bien sûr, si le parc était coupé en deux par une voie ferrée ou une
 autoroute ou une rivière ou autre, ce polygone pourrait devenir un
 multipolygone via une relation multipolygon.

 Eventuellement... le bassin est en inner d'un multipolygone qui décrit
 les pelouses... et encore, ça se discute.


 Le 3 avril 2013 09:31, Thomas Williamson wilt...@gmail.com a écrit :

 Bonjour, Je souhaiterais affiner la cartographie d'un parc urbain situé
 proche de chez moi et j'hésite toujours à avoir recours aux relations, de
 peur de faire des bêtises... Plusieurs types de polygones sont présents dans
 ce parc : bâtiments, zones boisées, pelouses, aires de jeux, etc. Quelle est
 la meilleure approche ? Un polygone global (type = multipolygon et name =
 Parc des Prés Mignons, avec des polygones intérieurs role = inner) ? Merci
 pour vos conseils ! Thomas ___
 Talk-fr mailing list Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr



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




-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

Le 3 avril 2013 11:26, Philippe Verdy verd...@wanadoo.fr a écrit :
 Non tu te trompes là encore, c'est moi qui ait fermé cette relation
 modifiée sous JOSM, explicitement depuis JOSM (CTRL+ALT+Q), après
 avoir envoyé les modifs objet par objet. Et bel et bien une heure
 avant celle indiquée. L'heure de fermeture réelle affiché est bien
 décalée avec une heure de retard sur la réalité.


Gros doute quand même sur cette explication car les changesets
suivants d'autre contributeurs sont en général refermés quelques
secondes après leur création. Si il y avait eu un tel problème avec
les heures de fermeture des changeset sur l'API ça aurait été général
et pas sur certains changesets et pas tous.

Exemple: http://www.openstreetmap.org/browse/changeset/15569812

-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses =?iso-8859-15?q?_donn=E9s=3F?=)

2013-04-03 Per discussione Brice Person

Le 03/04/2013 10:23, Pieren a écrit :
A ce compte là, il faut tout de suite arrêter d'utiliser le cadastre.
En effet, la condition la plus restrictive du cadastre est que le
produit final soit un produit composite. Hors, on ne peut garantir
que localement le cadastre soit l'unique source d'information
cartographique.

Le cadastre est concerné par Inspire mais je trouve que l'interprétation
de cette directive par l'IGN (qui publie un tms limité et pas les
données vecteur) laisse à désirer... (pour être poli)

Il faudrait plutôt arrêter les arrangements avec les fournisseurs et
leur pointer les bonnes pratiques. J'estime qu'OSM joue un rôle très
important de ce côté là.

Il ne faut pas perdre de vue l'objectif d'une licence. Cette clause de
non altération sert avant tout à protéger le fournisseur de tous
recours en cas de litiges (si la donnée est fausse parce que
modifiée, c'est pas ma faute).

Je dirais que ce qu'il ne faut pas perdre de vue c'est la volonté de
l'acteur qui libère ses données, celui ci a plutôt envie de faire les
choses bien à la base. Il faut donc faire de la pédagogie. Cette clause
on la retrouve dès que l'APIE est consultée... ou son site qui contient
toujours tout ce qu'il faut pour perdre un néophyte.

Mais si ce genre de clause va à l'encontre de l'opendata, je ne sais
pas si elle est prise en compte dans les textes actuels (directive
inspire). Les restrictions sur la libération des données doivent avoir
une réelle justification. L'avis d'un spécialiste serait bienvenue ici.

Je cite La directive n'impose pas de ne publier que des données
parfaites : elle demande seulement que le niveau de qualité des données
soit indiqué de façon sincère et précise dans les métadonnées.

Le problème avec cette directive c'est plutôt que la redistribution à
l'identique (share alike) peut être vue comme une restriction
injustifiée de la part d'un acteur (ce qui me parait une erreur
monumentale, mais à l'époque les enjeux n'avaient peut-être pas été
identifiés).

Ce qui permet le discours de l'IGN :
http://www.ign.fr/publications-de-l-ign/Institut/Publications/IGN_Magazine/68/IGNmag68.pdf
Qui fait comme si l'ODbL n'existait pas et n'était donc pas une solution
aux problèmes qu'ils relèvent.

L'ODbL n'était pas encore traduite en droit Français et Etalab
n'existait pas.

Je ne sais pas trop ce que veut dire traduite en droit français. Si
c'est pour dire, elle est validée par un texte de loi ou fait
référence à des textes de lois français, ça n'est pas le cas. Si
c'est pour dire, elle est validée par un juge, ça n'est pas le cas
non plus. Tout ce qu'on peut dire, c'est qu'elle a été validée par des
experts juridiques au niveau de certaines administrations qui ont
décidé d'adopter cette licence pour leurs données.

C'était à interpréter au sens propre :
http://vvlibri.org/fr/licence/odbl/10/fr

Quant à la licence LO/OL d'Etalab, elle peut aussi poser problème dans
OSM si on veut couper les cheveux en quatre (puisqu'on en arrive là).
En effet, elle contient, comme ODbL, une obligation de mentionner la
source. Hors, cette mention est souvent attachée aux objets eux-mêmes
(tag source) et rien ne garantit leur pérennité dans la bdd.

Là c'est couper les cheveux en quatre oui ;-)

Brice

Pieren

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

Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

Le 3 avril 2013 12:07, Christian Quest cqu...@openstreetmap.fr a écrit :
 Le 3 avril 2013 11:26, Philippe Verdy verd...@wanadoo.fr a écrit :
 Non tu te trompes là encore, c'est moi qui ait fermé cette relation
 modifiée sous JOSM, explicitement depuis JOSM (CTRL+ALT+Q), après
 avoir envoyé les modifs objet par objet. Et bel et bien une heure
 avant celle indiquée. L'heure de fermeture réelle affiché est bien
 décalée avec une heure de retard sur la réalité.


 Gros doute quand même sur cette explication car les changesets
 suivants d'autre contributeurs sont en général refermés quelques
 secondes après leur création. Si il y avait eu un tel problème avec
 les heures de fermeture des changeset sur l'API ça aurait été général
 et pas sur certains changesets et pas tous.

 Exemple: http://www.openstreetmap.org/browse/changeset/15569812

Tu peux en douter mais c'est pourtant bien le cas que dans la journée
du 1er avril, on a eu droit à ces décalages d'une heure (et pas que
moi d'ailleurs). Les fermetures de changeset ont une heure assez
aléatoire, et je pense que dans la plupart des cas cela venait
justement de ces changeset bloqués pour lesquels le serveur cessait
de répondre au front-end de l'API, qui elle non plus pouvait ne rien
répondre non plus et fermer la session HTTP brutalement après 2 ou 3
minutes.

On ne peut plus détecter le problème aujourd'hui mais il a bien été
présent après le redémarrage du serveur (sur un serveur de secours?)
suite à la panne sérieuse du 30 sur ramoth.

Un bloquage qui a conduit justement à ce que plusieurs autres
changesets de ma part sont restés vides (peu importe d'ailleurs
l'heure affichée, le fait est que rien ne passait dedans à cause de
l'anomalie de non réponse du serveur lors de la soumission d'un
objet). Exemple:

http://www.openstreetmap.org/browse/changeset/15571074
(resté ouvert sans rien dedans, une erreur HTTP venant du serveur)
http://www.openstreetmap.org/browse/changeset/15571095
(nouvelle tentative, certaines données sont passées, d'autres se sont bloquées)

Ces deux là ont été fermés manuellement par moi avec CTRL+ALT+Q dans
JOSM. A partir de 17 heures, cependant, on ne constate plus de
décalage d'1 heure. Peut-être que le changement d'heure a été corrigé
sur le serveur (ce qui a pu aussi causer des problèmes de synchro et
de non-réponse du serveur).

J'avais écrit pour signaler le problème au moment où il avait lieu,
mais maintenant le problème ne se produit plus et il ne faut pas
conclure sur ce qu'on voit maintenant, surtout quand on n'a aucune
idée de ce qui a été fait sur les serveurs pour les remettre en
service après la panne et la réparation d'urgence.

De même j'ai pu constater qu'une partie des modifs envoyées et
validées avec succès dans la journée du 1er avril ont été oubliées
par le serveur (n notamment des erreurs signalées par Osmose et bel et
bien corrigées le 1er avril, mais réapparu non corrigées du tout, sans
aucun revert, le 2 avril : dans le nord de l'Allemagne notamment,
ainsi que des nouveaux POIs ajoutés juste après le redémarrage, des
fautes d'orthographe dans les noms corrigées le 1er mais réapparues le
2, là encore sans aucune trace de la correction qui n'apparait plus
dans les changesets qui les avaient effectués).

Autrement dit le serveur a été instable pendant une bonne partie de la
journée du 1er avril, des modifs validées ayant pu être perdues et
d'autres ayant pu rester bloquées sans aucune erreur rapportée au
client hors de la fermeture de session HTTP sans réponse.

La réparation des serveurs a semble-t-il été faite avec un redémarrage
en mode dégradé mais avec aussi visiblement un processus effectuant en
parallèle des vérifications d'intégrité, ce qui causait une charge
importante sur le serveur et a pu conduire en cas de doute ou conflit
à supprimer des modifs plus récentes pour revalider une modif plus
ancienne datant de jute avant la panne.

Pour l'instant je n'ai aucune explication concernant ces bloquages
intempestifs sans réponse, et ces changesets créés avec succès mais
restés désespérément vides de tout changement, ni pour les changeset
bien effectuées et refermés correctement mais dont une partie des
modifs a disparu sans plus aucune trace.

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

[OSM-talk-fr] Un petit bout de serveur.

 

Bonjour, 

Quelqu'un aurait-il un petit bout de serveur pour
héberger quelques jours (ou plus si affinités) des démonstrations de
rendu topo 25000 ? Au programme, environ 300Mo de données au total, et
supposer qu'une partie de la liste de diffusion va essayer de voir à
quoi ressemble au moins une partie. Je n'ai pas ce qu'il faut dans des
proportions suffisantes de mon coté… 

Merci, 

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

Re: [OSM-talk-fr] landuse pour un champ captant ?

Le mar. 02 avril 2013 à 20:25 +0200, Pierre-Alain Dorange a écrit :

 man_made=water_works c'est pour l'usine de traitement (potabilisation)
 qui se trouve entre les puits (champs captants) et le réseau de
 distribution.
 
 Ayant étudié un peu le sujet ily a quelques temps j'ai rien trouvé pour
 les champs captants eux-même. Par contre il existe des tags pour :
 
 La zone de protection rapprochée (cloturé selon la loi) :
 
 boundary=water_protection_area
 
 Les puits eux-même :
 
 man_made=water_well

Du coup, que penses-tu de ma proposition initiale de landuse=water_catchment ?

Qui serait forcément inclus dans la boundary=water_protection_area si elle 
existe
et qui à son tour contiendrait les  man_made=water_well et 
éventuellement le man_made=water_works ?


-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] Un petit bout de serveur.

Le mer. 03 avril 2013 à 13:39 +0200, JB a écrit :
  
 
 Bonjour, 
 
 Quelqu'un aurait-il un petit bout de serveur pour
 héberger quelques jours (ou plus si affinités) des démonstrations de
 rendu topo 25000 ? Au programme, environ 300Mo de données au total, et
 supposer qu'une partie de la liste de diffusion va essayer de voir à
 quoi ressemble au moins une partie. Je n'ai pas ce qu'il faut dans des
 proportions suffisantes de mon coté… 


Je pense qu'on va te trouver ça ;-)

Tes données, c'est toujours des grandes images, ou des tuiles ?

Et quel type d'hébergement tu veux ? Juste un dépôt de fichiers bruts 
(sftp) dans une espace accessible par le web, ou plus évolué ?



-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] landuse pour un champ captant ?

2013-04-03 Per discussione Vincent Pottier


Le 03/04/2013 13:57, Guillaume Allegre a écrit :


Du coup, que penses-tu de ma proposition initiale de landuse=water_catchment ?

Qui serait forcément inclus dans la boundary=water_protection_area si elle 
existe
et qui à son tour contiendrait les  man_made=water_well et
éventuellement le man_made=water_works ?



Landuse, moi, ça me plaît. Ça dit bien ce que ça veut dire...
--
FrViPofm

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

[OSM-talk-fr] Soucis avec les tuiles de Bing dans JOSM

2013-04-03 Per discussione Samy


Bonjour,

Je suis le seul à ne pas pouvoir afficher toutes les tuiles de Bing dans 
JOSM ? Certaines sont récalcitrantes malgré mes tentatives à grands 
coups de clic droit.


Ça me fait le coup tous les jours en ce moment avec des messages sur 
chaque tuile comme :

- Erreur : Attribution is not loaded
- Erreur : Read timed out
- Erreur : ecn.t0.tiles.virtualearth.net

Du coup, pas simple de tracer ou corriger des highways, bâtiments, etc.

Encore une erreur de serveur ? On nous cache des choses ! On nous spolie 
! ;-)


Samy

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

Re: [OSM-talk-fr] Un petit bout de serveur.

 

Salut Guillaume, 

C'est juste des grandes images (entre 10 et
100Mo), posées quelque part, récupérables à partir d'un lien quelconque…


JB. 

Le 03.04.2013 14:02, Guillaume Allegre a écrit : 

 Le mer. 03
avril 2013 à 13:39 +0200, JB a écrit :
 
 Bonjour, Quelqu'un
aurait-il un petit bout de serveur pour héberger quelques jours (ou plus
si affinités) des démonstrations de rendu topo 25000 ? Au programme,
environ 300Mo de données au total, et supposer qu'une partie de la liste
de diffusion va essayer de voir à quoi ressemble au moins une partie. Je
n'ai pas ce qu'il faut dans des proportions suffisantes de mon coté…


 Je pense qu'on va te trouver ça ;-)
 
 Tes données, c'est toujours
des grandes images, ou des tuiles ?
 
 Et quel type d'hébergement tu
veux ? Juste un dépôt de fichiers bruts 
 (sftp) dans une espace
accessible par le web, ou plus évolué ?

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

Re: [OSM-talk-fr] Soucis avec les tuiles de Bing dans JOSM

2013-04-03 Per discussione Nicolas Moyroud

Je rencontre le même problème énervant depuis quelques jours. Le serveur 
Bing joue avec nos nerfs ! :-)


Nicolas


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

Re: [OSM-talk-fr] landuse pour un champ captant ?

2013-04-03 Per discussione Ab_fab

Je me dis que Water catchment s'apparente plus au bassin versant, qui est
à coup sûr beaucoup plus vaste que ton périmètre clôturé, sans parler de la
difficulté d'en trouver des limites claires.
J'ai trouvé cette page wikipedia [1] relative aux bassins versants, qui
donne justement catchment comme synonyme possible.

[1] http://en.wikipedia.org/wiki/Drainage_basin


Le 3 avril 2013 13:57, Guillaume Allegre allegre.guilla...@free.fr a
écrit :

 Le mar. 02 avril 2013 à 20:25 +0200, Pierre-Alain Dorange a écrit :

  man_made=water_works c'est pour l'usine de traitement (potabilisation)
  qui se trouve entre les puits (champs captants) et le réseau de
  distribution.
 
  Ayant étudié un peu le sujet ily a quelques temps j'ai rien trouvé pour
  les champs captants eux-même. Par contre il existe des tags pour :
 
  La zone de protection rapprochée (cloturé selon la loi) :
 
  boundary=water_protection_area
 
  Les puits eux-même :
 
  man_made=water_well

 Du coup, que penses-tu de ma proposition initiale de
 landuse=water_catchment ?

 Qui serait forcément inclus dans la boundary=water_protection_area si elle
 existe
 et qui à son tour contiendrait les  man_made=water_well et
 éventuellement le man_made=water_works ?


 --
  ° /\Guillaume AllègreOpenStreetMap France
   /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
  /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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




-- 
ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab
Il n'y a pas de pas perdus, Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] expérimentations à Orange

2013-04-03 Per discussione kimaidou

Bonjour,

Sur l'idée de la base tierce, en effet je me suis un peu emballé. Je
pensais à une application libre que chacun pourrait installer chez soi pour
gérer les liens entre OSM et ses données métiers, si elles sont privées.
Par contre, l'idée d'une base commune ferait encore sens pour les bases de
données métiers libres (par exemple celles en ODBL libérées via
l'opendata).

Je ne pensais pas forcément à une super api qui gère les flux. Pourquoi pas
à l'avenir. Mais dans un premier temps, une simple table qui stocke les
liens entre objets osm et objets métiers suffit. On peut ensuite utiliser
les outils comme osmWatch ou autre (à développer...) pour écouter les
diffs, vérifier s'ils concernent des liens, puis lancer les actions (rss
pour laisser manuellement, suppression automatique du lien, etc.). A noter
qu'il n'est pas obligé d'avoir une vraie base de données métiers. Ce
sytème fonctionnerait aussi bien sûr avec des fichiers de type CSV,
tableau, etc. Tant que des objets métiers ont un identifiant, on peut
créer un lien.

Au sujet de la base tierce qui doit connaître les objets osm et les
stocker chez elle, c'est vrai qu'il faut à un moment pouvoir lire les
liens, par exemple pour comparer la donnée. Mais je ne vois pas de souci
technique ici. On peut imaginer des outils
* qui aident à créer les liens
* qui aident à créer des données fusionnées via les liens (par exemple
prend moi la géométrie OSM et colle y les colonnes A, B et C de ma table
métier
* qui alertent les personnes lorsqu'une donnée a été supprimée ou modifiée
d'un côté ou de l'autre
* qui montre les liens avec un système sympa de double panneau, etc.

Bref c'est pas l'envie qui me manque, mais le temps en ce moment (je fais
du Lizmap à fond).

Bonne journée
Michael


Le 2 avril 2013 21:18, Guillaume Allegre allegre.guilla...@free.fr a
écrit :

 Le sam. 30 mars 2013 à 20:37 +0100, Guillaume Allegre a écrit :

 
  1) la boundary est une frontière de canton, qui coïncide avec un bout de
 la frontière communale
  (Orange / Caderousse)
  http://www.openstreetmap.org/?way=171243851 mais qui n'est pas
 confondue (points distincts)
  Selon moi, elle devrait être confondue, en tant que limite communale ET
 limite de canton.

 Sur ce premier point, tout le monde est d'accord pour la fusion ?

 À terme, si ce schéma se généralise, ça veut dire que les limites de
 communes seront également
 découpées selon les limites de bureaux de vote.
 Pas d'opposition ?


 
  2) le way polling_station a une résolution bien plus élevée (1 point par
 mètre dans les courbes),
  suivant les _anciens_ méandres de la Meyne, qui restent la limite
 communale comme ici :
  http://www.openstreetmap.org/?lat=44.08722lon=4.7789zoom=17layers=M
  A mon avis, c'est de la sur-résolution inutile,  mais ça se discute.

 Pas d'autre avis sur ce point ?


 --
  ° /\Guillaume AllègreOpenStreetMap France
   /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
  /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

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

Re: [OSM-talk-fr] landuse pour un champ captant ?

2013/4/3 Vincent Pottier vpott...@gmail.com

Landuse, moi, ça me plaît. Ça dit bien ce que ça veut dire...


-1
Ca risque d'entrer en conflit avec d'autres landuses (grass, meadow,
forest) alors qu'on essaie d'éviter les erreurs du passé comme avec
landuse=military par exemple.

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

Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses =?iso-8859-15?q?_donn=E9s=3F?=)

2013-04-03 Per discussione Christian Rogel



Le 3 avr. 2013 à 10:23, Pieren pier...@gmail.com a écrit :

 A ce compte là, il faut tout de suite arrêter d'utiliser le cadastre. En 
 effet, la condition la plus restrictive du cadastre est que le produit final 
 soit un produit composite. Hors, on ne peut garantir que localement le 
 cadastre soit l'unique source d'information cartographique. 

Oui et non : la voirie est, par définition, hors du cadastre. Donc, elle rend 
l'objet composite.
S'il n'y a que les bâtiments, que le cadastre recense pour des raisons 
fiscales, qualifier d'ouvrage géographique une zone où le tracé du bâti est le 
seul élément visible est une limite que l'Etat n'a  aucun intérêt à franchir.
Il faut parfois examiner, s'il y aura jamais un intérêt à agir.

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

Re: [OSM-talk-fr] Usage de relations pour les parcs urbains...

2013/4/3 Christian Quest cqu...@openstreetmap.fr


 Et pourquoi exclure le lac mais pas les différents riverbank des cours
 d'eau ? il faut pousser la logique à l'extrême pour voir si c'est bien
 logique ;)


La traversée d'une rivière est souvent l'occasion de sectionner le polygone
forêt en deux.


 Pour moi même une clairière dans la forêt je ne la met pas en inner,
 car même si elle n'est pas plantée d'arbre, elle fait bien partie de
 la forêt.


Euh, là, ça se discute. Si mes souvenirs sont bons, les clairières de
forêts ont été les premières applications concrètes des multipolygones avec
enclaves, exclaves à l'époque. Quand on rentre dans une clairière, on
quittte la zone boisée. Au niveau du calcul de surface, c'est bien un trou
qu'il faut modéliser (et ne pas penser uniquement appellation). Ce qu'on
représente, c'est bien la surface boisée.

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

Re: [OSM-talk-fr] Soucis avec les tuiles de Bing dans JOSM

2013-04-03 Per discussione Francescu GAROBY

Même problème depuis quelques jours et, surtout, absence de tuiles pour des
niveaux de zooms élevés : ça complique grandement le micro-mapping
(passages piétons, poubelles, bancs, ...)

Francescu


2013/4/3 Nicolas Moyroud nmoyr...@free.fr

 Je rencontre le même problème énervant depuis quelques jours. Le serveur
 Bing joue avec nos nerfs ! :-)

 Nicolas



 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr




-- 
Cordialement,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Un p'tit bout de serveur ?

 

Bonjour, 

Quelqu'un aurait-il un petit bout de serveur pour
héberger quelques jours (ou plus si affinités) des démonstrations de
rendu topo 25000 ? Au programme, environ 300Mo de données au total, et
supposer qu'une partie de la liste de diffusion va essayer de voir à
quoi ressemble au moins une partie. Je n'ai pas ce qu'il faut dans des
proportions suffisantes de mon coté… 

Merci, 

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

Re: [OSM-talk-fr] Usage de relations pour les parcs urbains...

2013-04-03 Per discussione Thomas Williamson

Bonjour,

Merci pour vos réponses ! Je vais donc faire simple ;-)... Pour répondre à
Jean-Baptiste : oui, j'ai trouvé les pages du Wiki mais je n'ai jamais
trouvé quelque chose de très explicite (pour moi) concernant les relations.
Je n'avais pas compris qu'il ne fallait pas y avoir recours quand le lien
géographique était implicite entre les objets.

Bonne journée !

Thomas




Le 3 avril 2013 11:06, talk-fr-requ...@openstreetmap.org a écrit :

 Envoyez vos messages pour la liste Talk-fr à
 talk-fr@openstreetmap.org

 Pour vous (dés)abonner par le web, consultez
 http://lists.openstreetmap.org/listinfo/talk-fr

 ou, par email, envoyez un message avec 'help' dans le corps ou dans le
 sujet à
 talk-fr-requ...@openstreetmap.org

 Vous pouvez contacter l'administrateur de la liste à l'adresse
 talk-fr-ow...@openstreetmap.org

 Si vous répondez, n'oubliez pas de changer l'objet du message afin
 qu'il soit plus spécifique que Re: Contenu du digest de Talk-fr...

 Thèmes du jour :

1. Usage de relations pour les parcs urbains... (Thomas Williamson)
2. Re: Usage de relations pour les parcs urbains... (Christian Quest)
3. Re: Licence IP et ODBL ( était : L'ON3V libère ses
   =?iso-8859-15?q?_donn=E9s=3F?=) (Pieren)
4. Re: Usage de relations pour les parcs urbains...
   (Jean-Baptiste Holcroft)
5. Re: Usage de relations pour les parcs urbains... (JB)


 -- Message transféré --
 From: Thomas Williamson wilt...@gmail.com
 To: OpenStreetMap | Talk-fr talk-fr@openstreetmap.org
 Cc:
 Date: Wed, 3 Apr 2013 09:31:35 +0200
 Subject: [OSM-talk-fr] Usage de relations pour les parcs urbains...
 Bonjour,

 Je souhaiterais affiner la cartographie d'un parc urbain situé proche de
 chez moi et j'hésite toujours à avoir recours aux relations, de peur de
 faire des bêtises... Plusieurs types de polygones sont présents dans ce
 parc : bâtiments, zones boisées, pelouses, aires de jeux, etc. Quelle est
 la meilleure approche ? Un polygone global (type = multipolygon et name =
 Parc des Prés Mignons, avec des polygones intérieurs role = inner) ? Merci
 pour vos conseils !

 Thomas


 -- Message transféré --
 From: Christian Quest cqu...@openstreetmap.fr
 To: Discussions sur OSM en français talk-fr@openstreetmap.org
 Cc:
 Date: Wed, 3 Apr 2013 10:02:21 +0200
 Subject: Re: [OSM-talk-fr] Usage de relations pour les parcs urbains...
 Tu parle bien de ce parc ?
 http://www.openstreetmap.org/?lat=46.56382lon=0.31454zoom=17

 Pourquoi faire compliqué quand on peut faire simple ?

 Le parc c'est quoi ? Un grand polygone avec dedans différentes choses
 (bâtiments, aires de jeu, bassin, etc) ?

 Dans ce cas, pourquoi ne pas simplement avoir un polygone englobant
 avec leisure=park name=Parc des Prés Mignons

 Quelle serait l'apport d'une relation ?

 Elle sont utiles lorsque qu'il n'y a pas de lien géographique
 implicite entre les objets, là le lien géographique est déjà là.

 Le bassin, les pelouse, les aires de jeu dans le parc ne fait pas
 partie de celui-ci ? Pourquoi vouloir les mettre en inner ?

 Bien sûr, si le parc était coupé en deux par une voie ferrée ou une
 autoroute ou une rivière ou autre, ce polygone pourrait devenir un
 multipolygone via une relation multipolygon.

 Eventuellement... le bassin est en inner d'un multipolygone qui décrit
 les pelouses... et encore, ça se discute.


 Le 3 avril 2013 09:31, Thomas Williamson wilt...@gmail.com a écrit :
  Bonjour,
 
  Je souhaiterais affiner la cartographie d'un parc urbain situé proche de
  chez moi et j'hésite toujours à avoir recours aux relations, de peur de
  faire des bêtises... Plusieurs types de polygones sont présents dans ce
 parc
  : bâtiments, zones boisées, pelouses, aires de jeux, etc. Quelle est la
  meilleure approche ? Un polygone global (type = multipolygon et name =
 Parc
  des Prés Mignons, avec des polygones intérieurs role = inner) ? Merci
 pour
  vos conseils !
 
  Thomas
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-fr
 



 --
 Christian Quest - OpenStreetMap France
 Synthèse du Week-end SOTM-FR à Lyon :
 http://openstreetmap.fr/synthese-sotmfr




 -- Message transféré --
 From: Pieren pier...@gmail.com
 To: Discussions sur OSM en français talk-fr@openstreetmap.org
 Cc:
 Date: Wed, 3 Apr 2013 10:23:19 +0200
 Subject: Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses
 =?iso-8859-15?q?_donn=E9s=3F?=)
 2013/4/2 Brice Person brice.per...@zenordi.fr

 Pour éviter toutes ambiguïtés, il faut que les acteurs soient ok pour que
 les données soient redistribuées sous les conditions de l'ODbL. Donc pour
 la France il vaut mieux que les acteurs utilisent directement l'ODbL ou une
 licence reconnue pour être compatible comme la LO d'Etalab (plus
 permissive). Je sais ça ne fait pas des masses de choix mais c'est tant
 mieux :-)


 A ce compte

Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

2013/4/3 Jo. perche...@gmail.com

 De toute façon le changset dont tu parlait ne c'est pas fermé une heure
 après mais 20 min de plus qu'indiqué :
 http://www.openstreetmap.org/browse/changeset/15569811


Ca n'est pas 20mn mais 1h 20mn sur ce changeset (qui n'était pas indiqué
dans le premier mais le 3e message). C'est effectivement très long. Mais
avec JOSM, on peut travailler dans le même changeset pendant des heures
suivant sa configuration. Ensuite, comme le serveur était tombé la veille,
il n'y a rien de surprenant à ce qu'il y ait des délais importants dans les
heures qui suivent (outre le cumule des uploads des contributeurs, il y a
aussi les fichiers planet (export) à rattraper). De plus, il avait un autre
changeset créé un quart d'heure auparavant qui avait des délais plus
normaux:
http://www.openstreetmap.org/browse/changeset/15569620
S'il y avait eu un bug sur le passage à l'heure d'été, il aurait dû d'abord
se demander pourquoi certains changesets ne prennaient que quelques
secondes ou minutes avant de se plaindre ici.

Concernant rawedit, je vais citer la première phrase du premier message de
Philippe sur ce fil de discussion:
 Je constate que le serveur crée un nouveau groupe de modification avec
 une heure de début correcte mais exactement en même temps une date de
 fin une heure exactement après.
Seuls ses changesets ouverts par rawedit ont exactement une date de fin une
heure exactement après le début.

Pieren
PS: je n'ai aucun accès privilégié aux données ou serveurs. Si j'ai répondu
aux messages de Philippe, c'est surtout pour les nouveaux inscrits sur
cette liste qui ne connaissent pas l'historique du personnage qui a, à de
nombreuses reprises, dit des bêtises sur cette liste.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

2013-04-03 Per discussione Eric Sibert


- Correction des 10 000 erreurs de collision routes/batiments :
http://osmose.openstreetmap.fr/fr/errors/?country=fr*item=1070


Très bon sujet


Non, je ne pense pas. Pour corriger ce genre de problème, il faudrait  
savoir qui est mal placé, de la route ou du bâtiment. Ca n'a rien  
d'évident, aucune source (Bing, cadastre, GPS...) n'étant assez  
fiable, surtout à ce niveau de précision, pour départager les erreurs.


Eric


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

Re: [OSM-talk-fr] expérimentations à Orange

2013-04-03 Per discussione thevenon . julien

- Mail original -
 De: kimaidou kimai...@gmail.com

 Bonjour, 

 Sur l'idée de la base tierce, en effet je me suis un peu emballé. Je pensais 
 à une application libre que chacun pourrait installer chez soi pour gérer les 
 liens entre OSM et ses données 
 métiers, si elles sont privées. Par contre, l'idée d'une base commune ferait 
 encore sens pour les bases de données métiers libres (par exemple celles en 
 ODBL libérées via l'opendata). 

 Je ne pensais pas forcément à une super api qui gère les flux. Pourquoi pas à 
 l'avenir. Mais dans un premier temps, une simple table qui stocke les liens 
 entre objets osm et objets
 métiers suffit. On peut ensuite utiliser les outils comme osmWatch ou autre 
 (à développer...) pour écouter les diffs, vérifier s'ils concernent des 
 liens, puis lancer les actions (rss
 pour laisser manuellement, suppression automatique du lien, etc.). A noter 
 qu'il n'est pas obligé d'avoir une vraie base de données métiers

Bonjour,

Pour ce qui est d ecouter les diffs SODA fournit une infrastructure. La 
verification par rapport aux liens et les actions a prendre pourraient etre 
faites dans un plugin dedie

Julien

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

Re: [OSM-talk-fr] landuse pour un champ captant ?

Le mer. 03 avril 2013 à 14:39 +0200, Pieren a écrit :
 2013/4/3 Vincent Pottier vpott...@gmail.com
 
 Landuse, moi, ça me plaît. Ça dit bien ce que ça veut dire...
 
 
 -1
 Ca risque d'entrer en conflit avec d'autres landuses (grass, meadow,
 forest) alors qu'on essaie d'éviter les erreurs du passé comme avec
 landuse=military par exemple.

Si j'ai bien compris, c'est pour ce que tu décris (grass...) qu'a été créé le 
tag landcover.

 Landcover is used to describe the physical material at the surface of the 
earth. Land covers include grass, asphalt, trees, bare ground, water, etc. This 
is distinct from Landuse which is describes the human use of land such as 
landuse=farm, landuse=retail or landuse=quarry.

Donc, d'après moi, le risque de conflit a été résolu, et 
landuse=water_catchment est cohérent avec le reste.
Il pourra être associé avec surface= ou landcover= (je ne rentre pas dans le 
débat).


-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

2013-04-03 Per discussione Jo.

Est ce que l'utilisation des points géodésique peut être possible ? Par
exemple sur ma commune je constate que le cadastre est décalé d'environ 1
gros mètre sur chaque axe (X et Y) par rapport aux points géodésique
correspondant.

Je pose cette question pour les communes de montagne ayant de fort décalage
entre le cadastre et l'imagerie Bing


Le 3 avril 2013 09:44, Eric Sibert courr...@eric.sibert.fr a écrit :

 - Correction des 10 000 erreurs de collision routes/batiments :
 http://osmose.openstreetmap.**fr/fr/errors/?country=fr***item=1070http://osmose.openstreetmap.fr/fr/errors/?country=fr*item=1070

  Très bon sujet


 Non, je ne pense pas. Pour corriger ce genre de problème, il faudrait
 savoir qui est mal placé, de la route ou du bâtiment. Ca n'a rien
 d'évident, aucune source (Bing, cadastre, GPS...) n'étant assez fiable,
 surtout à ce niveau de précision, pour départager les erreurs.

 Eric


 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] landuse pour un champ captant ?

Le mer. 03 avril 2013 à 14:46 +0200, Ab_fab a écrit :
 Je me dis que Water catchment s'apparente plus au bassin versant, qui est
 à coup sûr beaucoup plus vaste que ton périmètre clôturé, sans parler de la
 difficulté d'en trouver des limites claires.
 J'ai trouvé cette page wikipedia [1] relative aux bassins versants, qui
 donne justement catchment comme synonyme possible.
 
 [1] http://en.wikipedia.org/wiki/Drainage_basin

En effet, c'est un terme ambigu (on le trouve dans les 2 contextes).

Alors, en poussant les recherches, il semblerait que wellfield corresponde
http://www.linguee.fr/francais-anglais/traduction/champ++de+captage++d%27eau.html
http://www.linguee.fr/francais-anglais/traduction/champ++de+captage.html

mais c'est aussi utilisé pour un champ de puits de pétrole !
donc je transforme ma proposition en landuse=water_wellfield




-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] Proposition pour le projet du mois de avril

2013-04-03 Per discussione Jean-Baptiste Holcroft

En ayant déjà corrigé de nombreuses, je fais avec cadastre + bing + traces
GPS avoisinantes.
Il y a toujours au moins deux sources qui sont d'accord sinon les trois.
Parfois seuls les chemins semblent manquer de detail car rien n'était
présent avant. Le cas qui me paraît le plus critique est le cadastre mal
positionné. Il faudrait des mesures fiables sur place pour les détecter.
Il y a bien des cas particuliers mais ça ne dépasse pas quelques pourcents
des 1.
Mais je suis tout jeune sur osm, je suis peut être passé à côté ?
Le 3 avr. 2013 15:13, Eric Sibert courr...@eric.sibert.fr a écrit :

 - Correction des 10 000 erreurs de collision routes/batiments :
 http://osmose.openstreetmap.**fr/fr/errors/?country=fr***item=1070http://osmose.openstreetmap.fr/fr/errors/?country=fr*item=1070

  Très bon sujet


 Non, je ne pense pas. Pour corriger ce genre de problème, il faudrait
 savoir qui est mal placé, de la route ou du bâtiment. Ca n'a rien
 d'évident, aucune source (Bing, cadastre, GPS...) n'étant assez fiable,
 surtout à ce niveau de précision, pour départager les erreurs.

 Eric


 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] landuse pour un champ captant ?

2013/4/3 Guillaume Allegre allegre.guilla...@free.fr

Si j'ai bien compris, c'est pour ce que tu décris (grass...) qu'a été créé
 le tag landcover.

 landcover est une belle idée importée par les sigistes mais un échec de
mon point de vue dans OSM. Il est encore à l'état de proposition 2 ans et
demi après sa formulation dans le wiki et avec seulement 10.000 éléments
dans la base créés par 280 utilisateurs différents (ce qui est très peu sur
une période aussi longue dans OSM et pour quelque chose d'aussi générique).
Il est aussi absent des applications, éditeurs et logiciels de rendu. Les
valeurs que j'ai citées, meadow, grass, forest, sont toutes des
valeurs de landuse mais aussi parfois des natural, ce qui complique
encore d'avantage les choses.

Pourquoi pas le déjà existant boundary=protected_area +
protect_class=12:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area

qui a remplacé le déjà erroné landuse=nature_reserve en 2009 pour éviter
justement ces superpositions de landuse.

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

Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

2013-04-03 Per discussione f . dos . santos



- Mail original -
De: Pieren pier...@gmail.com
À: Discussions sur OSM en français talk-fr@openstreetmap.org
Envoyé: Mercredi 3 Avril 2013 10:47:50
Objet: Re: [OSM-talk-fr]Nouveau problème sur le serveur (heure d'été ? 
ou mauvaise installation après réparation ?)


2013/4/3 Jo.  perche...@gmail.com  

De toute façon le changset dont tu parlait ne c'est pas fermé une heure après 
mais 20 min de plus qu'indiqué : 
http://www.openstreetmap.org/browse/changeset/15569811 

Ca n'est pas 20mn mais 1h 20mn sur ce changeset (qui n'était pas indiqué dans 
le premier mais le 3e message). C'est effectivement très long. Mais avec 
JOSM, on peut travailler dans le même changeset pendant des heures suivant sa 
configuration. Ensuite, comme le serveur était tombé la veille, il n'y a rien 
de surprenant à ce qu'il y ait des délais importants dans les heures qui 
suivent (outre le cumule des uploads des contributeurs, il y a aussi les 
fichiers planet (export) à rattraper). De plus, il avait un autre changeset 
créé un quart d'heure auparavant qui avait des délais plus normaux: 
http://www.openstreetmap.org/browse/changeset/15569620 

S'il y avait eu un bug sur le passage à l'heure d'été, il aurait dû d'abord se 
demander pourquoi certains changesets ne prennaient que quelques secondes ou 
minutes avant de se plaindre ici. 

Concernant rawedit, je vais citer la première phrase du premier message de 
Philippe sur ce fil de discussion: 
 Je constate que le serveur crée un nouveau groupe de modification avec 
 une heure de début correcte mais exactement en même temps une date de 
 fin une heure exactement après. 

Seuls ses changesets ouverts par rawedit ont exactement une date de fin une 
heure exactement après le début. 

La fermeture automatique a lieu après 1h d'inactivité, la dernière action sur 
le changeset a donc eu lieu 20min après son ouverture. On peut donc considérer 
que son changeset (son upload ?) a duré 20 minutes.

Francisco

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

Re: [OSM-talk-fr] landuse pour un champ captant ?

Le mer. 03 avril 2013 à 16:13 +0200, Pieren a écrit :

 Pourquoi pas le déjà existant boundary=protected_area +
 protect_class=12:
 http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area

Parce qu'à mon avis, c'est vraiment un landuse (clôture, accès réservé 
à l'opérateur), qu'il faut différencier d'une protected area, qui peut 
être plus vaste (incluant des champs agricoles, mais uniquement en bio,
ou avec un contrôle des intrants).

Si landuse est sémantiquement juste et landcover est une belle idée, il 
faut pousser
l'usage des deux, et arrêter de chercher des contournements, à mon avis.


-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

Le 3 avril 2013 10:47, Pieren pier...@gmail.com a écrit :
 Ca n'est pas 20mn mais 1h 20mn sur ce changeset (qui n'était pas indiqué
 dans le premier mais le 3e message). C'est effectivement très long.

Et dans les faits ce changeset n'a duré que 20 minutes.

 Je constate que le serveur crée un nouveau groupe de modification avec
 une heure de début correcte mais exactement en même temps une date de
 fin une heure exactement après.
 Seuls ses changesets ouverts par rawedit ont exactement une date de fin une
 heure exactement après le début.

Non ! C'est faux. Puisque je te dis que les changesets dont je parlais
étaient bien créés sous JOSM. Pourquoi ne me crois(tu pas ? C'est
pourtant marqué dans le changeset lui-même.

De toute fa_on tu es en train de pinailler sur un faux problème qui
n'était qy'une remarque annexe au problème pour lequel j'avais écrit
et qui concernait le blocage des envois, avec une fermeture de session
HTTP par le serveur, sans réponse, ou bien avec une erreur HTTP 500.
Et même pour l'envoi depuis JOSM (je ne parlais QUE de JOSM et rien
d'autre, c'est toi qui as introduit RawEdit dans la discussion qui
n'avait RIEN à voir!) d'un seul et unique objet à la fois jusqu'à ce
que je trouve l'unique objet qui provoquait le blocage et la
non-réponse du serveur (pour pouvoir envoyer le reste et ne pas me
retrouver avec un des données orphelines).

Et c'était le SEUL objet du premier message. J'ai essayé de chercher
diverses causes à ces blocages mais je n'ai pas trouvé pourquoi un
seul objet bloquait tout. Cela m'a conduit à en supprimer un existant,
référencé par une relation, pour le recréer à l'identique (mais avec
un autre id) et c'est passé, plus rien ne bloquait et j'ai pu terminer
les envois (mais après avoir cherché des heures, et sans jamais aucune
réponse de personne pendant ce temps-là). Quand tu as commencé à
répondre plus de 24 heures après, le problème était déjà réglé sur
cette partie des données.

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

Re: [OSM-talk-fr] landuse pour un champ captant ?

2013/4/3 Guillaume Allegre allegre.guilla...@free.fr


  http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area

 class 12 :  *water:* water protection area, fresh water, drinking water,
springs, ...

Je ne vois pas de contournement à vouloir utiliser un tag aussi clair
(comme de l'eau de source)

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

Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

Le 3 avril 2013 16:15,  f.dos.san...@free.fr a écrit :
 La fermeture automatique a lieu après 1h d'inactivité, la dernière action sur 
 le changeset a donc eu lieu 20min après son ouverture. On peut donc 
 considérer que son changeset (son upload ?) a duré 20 minutes.

Oui. 20 minutes effectives pour envoyer 9 objets, plus un 10e qui
n'est pas passé et pour lequel le serveur a mis 20 minutes avant de
fermer la session sans retourner aucune erreur.

Ce 10e objet n'est pas mieux passé dans le changeset suivant qui est
resté vide (le serveur a mis là aussi plusieurs minutes avant de
fermer la session sans rien répondre. C'est alors que j'ai fermé les 2
changesets depuis JOSM.

Nulle part dans ces deux changesets il n'y avait la moindre modif
depuis rawedit (j'en ai fait séparément mais avant ou après et il
n'avaient pas de blocage de cette sorte), cela ne devait donc pas
rentrer dans cette discussion.

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

Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

2013-04-03 Per discussione Romain MEHUT

Bonjour,

C'est bon maintenant, on a compris!

Stop svp. On peut passer à autre chose?

Romain

Le 3 avril 2013 16:55, Philippe Verdy verd...@wanadoo.fr a écrit :

 Le 3 avril 2013 16:15,  f.dos.san...@free.fr a écrit :
  La fermeture automatique a lieu après 1h d'inactivité, la dernière
 action sur le changeset a donc eu lieu 20min après son ouverture. On peut
 donc considérer que son changeset (son upload ?) a duré 20 minutes.

 Oui. 20 minutes effectives pour envoyer 9 objets, plus un 10e qui
 n'est pas passé et pour lequel le serveur a mis 20 minutes avant de
 fermer la session sans retourner aucune erreur.

 Ce 10e objet n'est pas mieux passé dans le changeset suivant qui est
 resté vide (le serveur a mis là aussi plusieurs minutes avant de
 fermer la session sans rien répondre. C'est alors que j'ai fermé les 2
 changesets depuis JOSM.

 Nulle part dans ces deux changesets il n'y avait la moindre modif
 depuis rawedit (j'en ai fait séparément mais avant ou après et il
 n'avaient pas de blocage de cette sorte), cela ne devait donc pas
 rentrer dans cette discussion.

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

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

[OSM-talk-fr] Opération Libre à Brocas-les-Forges ce week-end

2013-04-03 Per discussione Sébastien Dinot

Salut,

Je serai ce week-end à Brocas-les-Forges pour participer à l'événement
Opération Libre :

http://operation-libre.org/

Par curiosité, d'autres mappeurs inscrits sur cette listes ont-ils prévu
d'y aller ?

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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

Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

2013/4/3 Romain MEHUT romain.me...@gmail.com


 Stop svp. On peut passer à autre chose?


Dommage. J'aurais bien voulu que Philippe admette que son affirmation sur
un bug d'heure d'été, heure d'hiver qu'il profère dans deux messages, était
n'importe quoi. Mais bon, on va arrêter d'alimenter le troll qui voudra de
toute façon avoir le dernier mot ici.

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

Re: [OSM-talk-fr] landuse pour un champ captant ?

Moi non plus, j'aime bien cette proposition claire.

Ce n'est pas l'existence d'une cloture ou d'une propriété qui change
les limites d'un landuse. La zone reste une zone protégée, et n'exclut
pas pour autant qu'elle puisse contenir des champs, des bois, des
batiments. Assez souvenet on trouve des zones de capatage d'eau au
milieu des forêts. La présence de cette zone de captage n'approte pas
de discontinuité à cette forêt (même si le puit de captage se situe
dans une petite clairière au bout d'un chemin.

De même bien des forêts sont découpées en différentes propriétés
privées d'une ou plusieurs parcelles, ces limites de propriétés n'ont
pas d'influence sur les landuse=forest (une bonne partie de la forêt
française est privée, même si les propriétaires s'associent dans une
coopérative ou avec une collectivité qui en possède des portions
domaniales, pour l'exploitation et l'entretien de leurs parcelles). Et
ces limites de forets élargies n'empêcheront pas de taguer en plus
séparément les clôtures éventuelles.

Les zones de protection des captages cependant peuvent être assez
étendues (et ont plutôt tendance à s'étendre au delà de leurs limites
initiales), appuyées par une législation régionale ou locale, pour
couvrir aussi des exploitations agricoles (interdiction des épandages
de lisiers par exemple, limitation de certaines cultures ou des
méthodes de traitement), et des zones habitées (interdiction de
l'implantation de certaines industries polluantes, régulation des
autres puits privés dans la zone et obligation donnée aux
propriétaires de faire analyser des prélèvements des eaux qu'ils
captent, obligations donnés aux propriétaires concernant leur
assainissement, contrôle des fosses septiques, obligation de se
raccorder au réseau public d'eaux usées, fermeture des installations
non conformes, etc.). C'est souvent fait en concertation avec l'agence
de bassin et les collectivités concernées.

Ces zones protégées pour le captage sont liées à l'étendue des nappes
en sous-sol et des rivières souterraines qui les alimentent, ainsi
qu'à la nature des sols filtrants les eaux des précipitations, ce qui
n'a souvent rien à voir avec ce qui est présent en surface (les
différents landuse).

2013/4/3 Pieren pier...@gmail.com:
 2013/4/3 Guillaume Allegre allegre.guilla...@free.fr


  http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area

 class 12 :  water: water protection area, fresh water, drinking water,
 springs, ...

 Je ne vois pas de contournement à vouloir utiliser un tag aussi clair (comme
 de l'eau de source)

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

Re: [OSM-talk-fr] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

C'est toi qui a lancé le troll, mon message initial parlait d'autre
chose bien plus important et toujours inexpliqué. De plus concernant
les heures je n'affirmais rien du tout je posais une question. Je t'ai
démenti seulement que des affirmations fausses quand tu as mélé
rawedit à l'histoire et quand tu as prétendu que c'en était la cause.

Du coup, à cause de TON troll (publiquement dénigrant, même si tu
considères qu'il n'était pas insultant), personne n'a répondu au
problème initial.

Le 3 avril 2013 17:09, Pieren pier...@gmail.com a écrit :
 Dommage. J'aurais bien voulu que Philippe admette que son affirmation sur un
 bug d'heure d'été, heure d'hiver qu'il profère dans deux messages, était
 n'importe quoi. Mais bon, on va arrêter d'alimenter le troll qui voudra de
 toute façon avoir le dernier mot ici.

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

Re: [OSM-talk-fr] Parcs urbains : pelouses et boisements

Aucun conflit possible entre les leisure=* d'une part et les landuse=*
ou natural=* d'autre part. Les polygones n'ont pas besoin d'être
surdécoupés et peuvent rester des polygones différents superposés,
partiellement ou entièrement.

Le 3 avril 2013 11:58, Thomas Williamson wilt...@gmail.com a écrit :
 Re-bonjour,

 Toujour à propos de parcs urbains. Si j'ai un polygone englobant (contour du
 parc) avec leisure = park, et que je distingue les pelouses des boisements,
 je vais avoir un polygone sur lequel vont venir se superposer des polygones
 (par exemple, des landuse = grass et landuse = forest). Dois-je mettre les
 polygones jointifs ou la superposition est-elle possible ?

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

Re: [OSM-talk-fr] Soucis avec les tuiles de Bing dans JOSM

2013-04-03 Per discussione claude marani

bonjour

même problème.
Une solution que j'ai trouvé, clic droit à l'emplacement de la tuile non
chargée et Charger la tuile.
Répéter l'opération si besoin

cordialement
Claude


Le 3 avril 2013 15:07, Francescu GAROBY windu...@gmail.com a écrit :

 Même problème depuis quelques jours et, surtout, absence de tuiles pour
 des niveaux de zooms élevés : ça complique grandement le micro-mapping
 (passages piétons, poubelles, bancs, ...)

 Francescu


 2013/4/3 Nicolas Moyroud nmoyr...@free.fr

 Je rencontre le même problème énervant depuis quelques jours. Le serveur
 Bing joue avec nos nerfs ! :-)

 Nicolas



 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr




 --
 Cordialement,
 Francescu GAROBY

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


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

Re: [OSM-talk-fr] Soucis avec les tuiles de Bing dans JOSM

2013-04-03 Per discussione Nicolas Moyroud



Le 03/04/2013 18:08, claude marani a écrit :

bonjour

même problème.
Une solution que j'ai trouvé, clic droit à l'emplacement de la tuile 
non chargée et Charger la tuile.

Répéter l'opération si besoin

cordialement
Claude



Merci pour l'astuce. Purée on risque la tendinite du doigt si il faut 
toutes se les faire à la main une par une ! ;-)


Nicolas


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

Re: [OSM-talk-fr] landuse pour un champ captant ?