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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 Par sujet 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 ?


Le mer. 03 avril 2013 à 16:59 +0200, Pieren a écrit :
 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)
 

Tu es sûr que tu as lu mon message précédent, avant de répondre ?

  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).

S'il faut que j'explicite : le champ captant est plus restreint (inclus dans)
la zone de protection.
Le champ captant est une réalité de terrain, avec un changement de paysage.
La zone de protection est une limite réglementaire, plus vaste, qui n'induit
généralement pas de changement de paysage visible (forêt, champs, prairie...).

D'autre part, sémantiquement, un champ de captage correspond exactement
à un landuse, une utilisation du terrain.



-- 
 ° /\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 p'tit bout de serveur ?

2013-04-03 Par sujet Jean-Francois Nifenecker


Bonjour,

Le 03/04/2013 12:11, JB a écrit :


Quelqu'un aurait-il un petit bout de serveur pour héberger quelques


euh... que vient faire ce message au milieu de la forêt ?

Il serait plus efficace/pertinent de créer un *nouveau* fil plutôt que 
de se greffer/squatter un fil sans rapport.


A+
--
Jean-Francois Nifenecker, Bordeaux

___
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 à 18:34 +0200, Guillaume Allegre 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).
 
 S'il faut que j'explicite : le champ captant est plus restreint (inclus dans)
 la zone de protection.
 Le champ captant est une réalité de terrain, avec un changement de paysage.
 La zone de protection est une limite réglementaire, plus vaste, qui n'induit
 généralement pas de changement de paysage visible (forêt, champs, prairie...).
 
 D'autre part, sémantiquement, un champ de captage correspond exactement
 à un landuse, une utilisation du terrain.

J'essaie d'illustrer avec ce document, du SIERG (opérateur public de gestion
de l'eau sur la région grenobloise, à l'exclusion de Grenoble, parce que 
Carignon
est passé par là !)
http://www.sierg.org/uploads/Document/ff/WEB_CHEMIN_167_1217863223.pdf p.11
la carte indique 3 zones :
- Périmètre de protection immédiate (PPI)
- Périmètre de protection rapprochée (PPR)
- Périmètre de protection éloignée (PPE)
Les termes PPI, PPR, PPE sont standard ; je pense qu'ils sont réglementaires.
https://fr.wikipedia.org/wiki/Captage_d%27eau_potable

Le PPI est un terrain acquis par le SIERG, clôturée, qui exclut toutes
les autres activités.
Le PPR et le PPE sont des zones privées, n'appartenant pas au SIERG, avec
des réglementations sur les activités permises.

On retrouve la même distinction en de nombreux endroits en France.
Le PPI correspond à ce landuse (en grass pour l'instant) :
http://www.openstreetmap.org/browse/way/129671505

Ma proposition consiste en tagguer ce PPI en landuse=water_wellfield
et les zones PPR et PPE avec boundary=protected_area + protect_class=12.
(et il faudrait définir 2 niveaux de protection d'eau si on voulait coller 
au schéma national, mais je pense que ce serait aller trop loin).



-- 
 ° /\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] Soucis avec les tuiles de Bing dans JOSM

2013-04-03 Par sujet Jean-Francois Nifenecker


Le 03/04/2013 18:22, Nicolas Moyroud a écrit :


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



Oui. C'est la tuile.

Sinon, pareil ici. Les tuiles Bing qui font bong.
--
Jean-Francois Nifenecker, Bordeaux

___
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

Plus simple : clic droit et charger les tuiles avec des erreur. On
n'est pas obligé de cliquer sur chacune des tuiles.

Note que cela ne met pas à jour les tuiles déjà présentes dans le
cache qui pourraient être obsolètes. Pour ça, j'utilise le clic droit
: purger le cache, ce qui force toutes les tuiles à être rechargées
(et ensuite s'il y en a encore qui sont en erreur après la purge,
utiliser l'option précédente pour compléter ce qui manque).

Note: ces actions du clic droit sur la carte ne concernent QUE la
couche de tuile la plus haute en priorité (dans la liste des calques,
affichée dans un panel ancré en partie droite), et n'agissent pas sur
les autres couches en arrière-plan. Si tu as plusieurs couches de
tuiles superposées, il faut en masquer une (cliquer sur l'icône de
l'oeil pour masquer/démasquer) dans la liste des calques pour ne
conserver à l'écran que celle que tu veux mettre à jour.

Le 3 avril 2013 18:22, Nicolas Moyroud nmoyr...@free.fr a écrit :
 Merci pour l'astuce. Purée on risque la tendinite du doigt si il faut toutes
 se les faire à la main une par une ! ;-)

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

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

Le 3 avril 2013 19:22, Jean-Francois Nifenecker
jean-francois.nifenec...@laposte.net a écrit :
 Il serait plus efficace/pertinent de créer un *nouveau* fil plutôt que de se
 greffer/squatter un fil sans rapport.

Ce doit être ton client mail qui fait ça car moi je vois bien un
nouveau fil séparé, avec un titre séparé. Aucun squat de fil en vue.

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

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

2013-04-03 Par sujet clansco

On Wed, 3 Apr 2013 19:53:59 +0200
Philippe Verdy verd...@wanadoo.fr wrote:

 Le 3 avril 2013 19:22, Jean-Francois Nifenecker
 jean-francois.nifenec...@laposte.net a écrit :
  Il serait plus efficace/pertinent de créer un *nouveau* fil plutôt que de se
  greffer/squatter un fil sans rapport.
 
 Ce doit être ton client mail qui fait ça car moi je vois bien un
 nouveau fil séparé, avec un titre séparé. Aucun squat de fil en vue.
 


Received: from www.mailoo.org (localhost [127.0.0.1])
 by foxnic.zionetrix.net (Postfix) with ESMTPA id B060F179DE
 for talk-fr@openstreetmap.org; Wed,  3 Apr 2013 12:11:52 +0200 (CEST)
MIME-Version: 1.0
Date: Wed, 03 Apr 2013 12:11:52 +0200
From: JB jb...@mailoo.org
To: Discussions sur OSM en français talk-fr@openstreetmap.org
In-Reply-To: 
CAAXY6DMa=ExPHK2Yyz2z_X+n0BVdbdr5RfdoxVK5fx-_=zG=3...@mail.gmail.com
References: cajb_0xu1t45iqri-hyfxu-11wexs6kozaennauophh69fcp...@mail.gmail.com
 CAAXY6DPkpU=yEWPoux8Djd5zr3G-KaKS1=f7a-pto43r22f...@mail.gmail.com
 bebec53a8cd87904ae82e7b9c5033...@mailoo.org
 CAAXY6DMa=ExPHK2Yyz2z_X+n0BVdbdr5RfdoxVK5fx-_=zG=3...@mail.gmail.com
Message-ID: 85f5046a54cf1b04ba69fe2ee3f7f...@mailoo.org
X-Sender: jb...@mailoo.org
User-Agent: Roundcube Webmail/0.8.1
Subject: [OSM-talk-fr] Un p'tit bout de serveur ?
X-BeenThere: talk-fr@openstreetmap.org
X-Mailman-Version: 2.1.14


-- 
Frédéric Falsetti
http://clansco.org

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

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

2013-04-03 Par sujet Ista Pouss

À priori moi je pourrais. Contactez moi en privé si vous retenez ma piste
(pour des rendus topos ça devrait aller) - mais il faudra m'expliquer ce
qu'il faut faire.


Le 3 avril 2013 12:11, JB jb...@mailoo.org 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é…

 Merci,

 JB.


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




-- 
Les dérives de rue :
Le papillon d’hiver (le film)http://drivrsdu.fr/le-papillon-dhiver-le-film/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu topo 25000ème

2013-04-03 Par sujet THEVENON Julien

 De : JB jb...@mailoo.org


 Bonjour,
 Ça y est, après l'avoir sous-entendu au SOTM-FR, après l'avoir montré en 
 avant-première, sous forme incomplète en carto-partie et sur 
Grenoble, je
 suis prêt à vous le présenter.
 Pour les pressés, les images, c'est par ici (attention, certains fichiers 
 lourds, merci Guillaume pour le coup de main) :
 [...]


Hello,

J ai une erreur 404 pour tous les liens

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

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

2013-04-03 Par sujet Jean-Francois Nifenecker


Le 03/04/2013 19:53, Philippe Verdy a écrit :

Le 3 avril 2013 19:22, Jean-Francois Nifenecker
jean-francois.nifenec...@laposte.net a écrit :

Il serait plus efficace/pertinent de créer un *nouveau* fil plutôt que de se
greffer/squatter un fil sans rapport.


Ce doit être ton client mail qui fait ça car moi je vois bien un
nouveau fil séparé, avec un titre séparé. Aucun squat de fil en vue.



JB, Philippe,

le mail auquel j'ai répondu est apparu au milieu du fil Usage de 
relations pour les parcs urbains... (en réponse à CQuest).


En effet, un *autre* fil, sous le titre Un p'tit bout de serveur ? a 
aussi commencé sa vie par ailleurs, fil que j'ai repéré après avoir 
répondu. Bon affaire close quand même :)


--
Jean-Francois Nifenecker, Bordeaux

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

Re: [OSM-talk-fr] Rendu topo 25000ème

2013-04-03 Par sujet Sébastien Dinot

JB a écrit :

 La feuille de style est actuellement sous licence CC-by-nc-sa, du
 moins c'est ce qui est écrit partout ; mais je me suis déjà presque
 convaincu moi-même, il passe au CC-by-sa dès sa prochaine version
 (insistez juste un tout petit peu).

Bon, ben, dans ce cas, j'insiste un tout petit peu vu que la licence CC
By-NC-SA n'est pas une licence libre. :)

 On note que la donnée SRTM (courbes de niveau et ombrage) est parfois
 manquante, notamment dans les zones au relief accidenté.

Je ne connaissais pas ce défaut de SRTM que je n'avais notamment jamais
remarqué dans les Pyrénées. C'est étrange...


 le tutoriel niveau 0 est prêt, joint à ce mél.

Merci ! Je vais le lire de ce pas.

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] Rendu topo 25000ème

Désolé, suite à une erreur de ma part, JB a déposé ses fichiers au 
mauvais endroit.
Le bon site est http://osm107.openstreetmap.fr/jbtopo/

Remplacez donc osm101 par osm107...

Le mer. 03 avril 2013 à 20:12 +0200, JB a écrit :
  
 
 Bonjour, 
 
 Ça y est, après l'avoir sous-entendu au SOTM-FR, après
 l'avoir montré en avant-première, sous forme incomplète en carto-partie
 et sur Grenoble, je suis prêt à vous le présenter. 
 
 Pour les pressés,
 les images, c'est par ici (attention, certains fichiers lourds, merci
 Guillaume pour le coup de main) : 
 
 Sur les premiers kilomètres de la
 ViaAlpina, de notre coté 108Mo :
 http://osm101.openstreetmap.fr/jbtopo/ViaAlpina25.png 
 
 Sur le sud du
 Vercors 115Mo : http://osm101.openstreetmap.fr/jbtopo/Vercors25.png 
 
 En
 centre ville, au 15000, à Paris 8Mo :
 http://osm101.openstreetmap.fr/jbtopo/NotreDame15.png 
 
 À Strasbourg au
 15000 13Mo : http://osm101.openstreetmap.fr/jbtopo/Strasbourg15petit.png
 
 
 À Strasbourg au 25000 19Mo :
 http://osm101.openstreetmap.fr/jbtopo/Strasbourg25.png
 
 En périurbain, à
 Verrières-le-Buisson 8Mo :
 http://osm101.openstreetmap.fr/jbtopo/Verrieres25.png 
 
 Avec
 sur-impression d'une trace GPS, au-dessus de Grenoble 25Mo :
 http://osm101.openstreetmap.fr/jbtopo/LeSappeyGPS.png 
 
 Et bien sûr, la
 légende : http://osm101.openstreetmap.fr/jbtopo/legende4.png
 
 Si vous
 voulez d'autres démos, demandez, ou créez-les vous-même (le tuto est là,
 avec tout ce qu'il faut… continuez à lire). 
 
 La problématique : 
 
 J'ai
 participé à une formation à OSM à laquelle participaient plusieurs
 personnes d'office de tourisme. Un point essentiel est ressorti : la
 base de données, l'accès à la donnée brute, c'est bien beau, mais
 qu'est-ce qu'on en fait ? On ne sait peut-être pas trop ce que c'est
 qu'une base de données, ça ne nous fait pas rêver, par contre, une
 carte, on aime, on n'en a pas, et on en veut. 
 
 De mon coté, je suis
 intéressé de voir les capacités de la base OSM et des outils développés
 autour. J'ai aussi envie de développer un rendu topo/rando. 
 
 À partir
 de là, j'ai commencé à travailler sur ce rendu topo, avec au fond de la
 tête l'idée qu'il serait bien utile, entre-autre, aux offices de
 tourisme. Est-ce que ce type de rendu pourrait aussi intéresser de
 nouvelles personnes au projet ? 
 
 Les choix : 
 
 - Maperitive/Tilemill ?
 On connait maintenant leurs différences (simplicité, orientation web,
 …). Comme je vise une mise à disposition pour les moins bricoleurs en
 informatique, je me suis rapidement reporté sur Maperitive 
 
 -
 Mono-zoom/multi-échelle. Le travail sur un seul niveau de zoom me semble
 obliger à trancher plus nettement dans les données rendues, et ainsi
 espérer obtenir une carte plus claire. J'ai choisi de travailler à une
 échelle seule, pour une impression aux environs du 25000ème (15000 en
 milieu urbain). 
 
 - Impression écran/papier. La résolution de l'écran
 oblige à utiliser des tailles de texte et de symboles assez grandes, pas
 forcément adaptées à une impression papier. J'ai choisi de privilégier
 le support papier. 
 
 - Son nom, R25 pour l'instant, ouvert à toute
 proposition de modification.
 
 - Et bien sûr les choix de sélection, de
 représentation. Toujours critiquables, critiquez-les… 
 
 Le travail :
 
 
 Plus de 3900 lignes de feuille de style (pour un seul niveau de
 zoom…). Si je recommençais demain (non, je ne le ferai pas), la feuille
 aurait été organisée légèrement différemment, elle pourrait être
 également condensée (mais finalement pas tant que ça). Je n'ai pas
 commencé à compter mes heures passées sur le projet, je pense que c'est
 mieux ainsi. 
 
 La feuille de style est actuellement sous licence
 CC-by-nc-sa, du moins c'est ce qui est écrit partout ; mais je me suis
 déjà presque convaincu moi-même, il passe au CC-by-sa dès sa prochaine
 version (insistez juste un tout petit peu).
 
 Les défauts connus : 
 
 La
 carte se limite toujours à la donnée disponible. On note que la donnée
 SRTM (courbes de niveau et ombrage) est parfois manquante, notamment
 dans les zones au relief accidenté. 
 
 Le mono-échelle se casse les dents
 sur des zones à forte différence de densité de données. Le centre de
 Paris est bien plus lisible si imprimé au 15000ème, alors que le 25000
 en rando semble généralement bon. 
 
 La suite : 
 
 J'ai fini de travailler
 sur la feuille de style (c'est ce que je dis chaque matin depuis 10
 jours) ; le tutoriel niveau 0 est prêt, joint à ce mél. Au programme :
 un tutoriel de niveau plus élevé. 
 
 Au programme aussi, recevoir vos
 retours que j'espère (raisonnablement) nombreux. Je pense qu'une partie
 d'entre vous va regarder ce que ça donne à coté de chez vous. Si vous
 voyez des incohérences, des problèmes, des bugs, des améliorations
 possibles, merci de me les faire revenir (sur la feuille de style, les
 choix, le tuto…). Merci aussi de me dire si vous avez des remarques plus
 générales sur l'aspect du rendu.
 
 Les

Re: [OSM-talk-fr] Rendu topo 25000ème

Le mer. 03 avril 2013 à 20:08 +0100, THEVENON Julien a écrit :

 
 Hello,
 
 J ai une erreur 404 pour tous les liens


Désolé, suite à une erreur de ma part, JB a déposé ses fichiers au
mauvais endroit.
Le bon site est http://osm107.openstreetmap.fr/jbtopo/

Remplacez donc osm101 par osm107...



-- 
 ° /\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] Rendu topo 25000ème

2013-04-03 Par sujet Guilhem Bonnefille

Bonsoir,

Erreur 404 aussi de mon coté, avec un Site en maintenance quand je
remonte dans l'URL.


Sinon, génial de travailler sur ce type de sujet. Il est certain que la
donnée brute c'est pas terrible. Si je prend un exemple, MapOSMatic est une
initiative à répéter : permettre aux utilisateurs (finaux ou non, comme les
offices de tourisme) de créer un produit fini pour la zone qui les
intéresse.
Un rendu orienté rando c'est une très bonne chose. Suivant de loin la
liste, j'ai l'impression que c'est un sujet hot en ce moment. C'est
chouette.


Le 3 avril 2013 20:12, JB jb...@mailoo.org a écrit :

 **

 La feuille de style est actuellement sous licence CC-by-nc-sa, du moins
 c'est ce qui est écrit partout ; mais je me suis déjà presque convaincu
 moi-même, il passe au CC-by-sa dès sa prochaine version (insistez juste un
 tout petit peu).




Je ne sais pas où tu en es de ta réflexion, mais voici mon commentaire.
Je ne suis pas au fait du lien entre la licence de la feuille de style et
la licence du produit dérivé qu'on peut générer avec. M'est avis que c'est
probablement fortement couplé. Si c'est le cas, produire des cartes NC (non
commerciale) ça va pas servir ton projet de départ. Car, gratuit ou non,
diffuser des cartes papiers dans le cadre des activités d'un office de
tourisme... ça doit bien tomber sous le coup d'une activité commerciale.
D'autant que le dernier office de tourisme que j'ai fréquenté commençait à
faire payer les topoguides (une misère, mais c'est déjàa plus gratuit).

Bref, si tu es sûr de pouvoir choisir la licence que tu veux (licence de ce
que tu aurais pu réutiliser), fait tomber ce nc fâcheux.


Dans tous les cas, bravo (même si je n'ai pas encore pu apprécier le rendu).
-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu topo 25000ème

 

OK, pas de bol, tout a été déplacé… screugneugneu… j'avais tout bien
vérifié 15 fois avant d'envoyer… 

C'est maintenant sur osm107, soit :


Sur les premiers kilomètres de la ViaAlpina, de notre coté 108Mo :
http://osm107.openstreetmap.fr/jbtopo/ViaAlpina25.png 
 Sur le sud du
Vercors 115Mo : http://osm107.openstreetmap.fr/jbtopo/Vercors25.png
 En
centre ville, au 15000, à Paris 8Mo :
http://osm107.openstreetmap.fr/jbtopo/NotreDame15.png
 À Strasbourg au
15000 13Mo :
http://osm107.openstreetmap.fr/jbtopo/Strasbourg15petit.png
 À
Strasbourg au 25000 19Mo :
http://osm107.openstreetmap.fr/jbtopo/Strasbourg25.png
 En périurbain, à
Verrières-le-Buisson 8Mo :
http://osm107.openstreetmap.fr/jbtopo/Verrieres25.png
 Avec
sur-impression d'une trace GPS, au-dessus de Grenoble 25Mo :
http://osm107.openstreetmap.fr/jbtopo/LeSappeyGPS.png
 Et bien sûr, la
légende : http://osm107.openstreetmap.fr/jbtopo/legende4.png 

Désolé
pour le double envoi, 

JB 

(et promis, je ferais plus répondre en
changeant l'intitulé. Qu'est-ce j'en sais, que des données sont cachées
kekpart, moi…) 

Le 03.04.2013 21:08, THEVENON Julien a écrit : 


DE : JB jb...@mailoo.org
 
 Bonjour, 
 Ça y est, après l'avoir
sous-entendu au SOTM-FR, après l'avoir montré en avant-première, sous
forme incomplète en carto-partie et sur Grenoble, je 
 suis prêt à
vous le présenter. 
 Pour les pressés, les images, c'est par ici
(attention, certains fichiers lourds, merci Guillaume pour le coup de
main) : 
  [...]
 
 Hello, 
 
 J ai une erreur 404 pour tous les
liens 
 
 Julien 
 

___
 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
___
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 Par sujet DH


Le 03/04/2013 12:01, Christian Quest a écrit :

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.


Christian, ton histoire de mitage m'interpelle. Dans toutes les bdd 
d'occupation du sol que j'ai pu consulter ou manipuler, le cahier des 
charges (ou son avatar : les métadonnées ;-) indiquent des seuils de 
visibilité des objets (surfaces minimales comme critère déterminant). 
Quand je traduis Corinne Land Cover (100.000e) en quelque chose 
d'équivalent au 10.000e, je me fixe des seuils (perso, intuitifs) dans 
ma façon de simplifier, de faire apparaître tel ou étang de pêche, haie 
d'arbres fruitiers, etc. Ces seuils ne sont pas documentés ; c'est leur 
principal défaut, pour l'instant.


Selon moi, une couche d'occupation du sol (au sens d'une classe 
d'objets qui partage des attributs communs, une topologie commune) doit 
inclure l'ensemble des éléments censés composer cette classe. Donc dans 
landuse, nous avons farmland, meadow, orchard, winyard, construction 
etc. mais aussi cemetery (sinon faut changer la clé)


Dans la classe natural, nous avons les scrub, les wood, les wetland, 
waterway (plus exactement les riverbank des waterways importants -ref 
necessaire-)


Donc, j'essaie au maximum d'avoir une cohérence topologique entre les 
natural et les landuse en ne laissant le soin à personne (surtout pas 
aux rendus) de me dicter les règles de laisser-aller mais on supprimant 
sans vergogne des objets qui me paraissent anticiper un poil le niveau 
de précision maintenable dans la base (typiquement un riverbank d'un 
fossé d'irrigation, une seule rangée d'arbres taggable autrement). Donc 
un étang de taille suffisante est un trou dans mon polygone de prairie 
ou de forêt.
En 2 mots, cohérence et détail raisonnable (évalué à 1:10.000 en 
campagne peut-être 1:2.000 en milieu urbain).
J'ai commencé à m'attaquer à Corinne le long du chantier de la LGVEE et 
purée, c'est pas simple de passer de 1.0 à 2.0


Denis, en pleine expérimentation

PS : et pis les relations c'est pas si compliqué que cela, sauf si elles 
font 500 km² et sont traversées par 2 voies ferrés, une autoroute, un 
canal à grand gabarit, qu'elles datent de 2006 et ne correspondent plus 
à grand chose sur le terrain !!


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

Re: [OSM-talk-fr] Rendu topo 25000ème

2013-04-03 Par sujet Guilhem Bonnefille

Sans vouloir abuser, est-il possible que les url de la page jbtopo
soient... clicables ? ;-)


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

 Désolé, suite à une erreur de ma part, JB a déposé ses fichiers au
 mauvais endroit.
 Le bon site est http://osm107.openstreetmap.fr/jbtopo/

 Remplacez donc osm101 par osm107...

 Le mer. 03 avril 2013 à 20:12 +0200, JB a écrit :
 
 
  Bonjour,
 
  Ça y est, après l'avoir sous-entendu au SOTM-FR, après
  l'avoir montré en avant-première, sous forme incomplète en carto-partie
  et sur Grenoble, je suis prêt à vous le présenter.
 
  Pour les pressés,
  les images, c'est par ici (attention, certains fichiers lourds, merci
  Guillaume pour le coup de main) :
 
  Sur les premiers kilomètres de la
  ViaAlpina, de notre coté 108Mo :
  http://osm101.openstreetmap.fr/jbtopo/ViaAlpina25.png
 
  Sur le sud du
  Vercors 115Mo : http://osm101.openstreetmap.fr/jbtopo/Vercors25.png
 
  En
  centre ville, au 15000, à Paris 8Mo :
  http://osm101.openstreetmap.fr/jbtopo/NotreDame15.png
 
  À Strasbourg au
  15000 13Mo : http://osm101.openstreetmap.fr/jbtopo/Strasbourg15petit.png
 
 
  À Strasbourg au 25000 19Mo :
  http://osm101.openstreetmap.fr/jbtopo/Strasbourg25.png
 
  En périurbain, à
  Verrières-le-Buisson 8Mo :
  http://osm101.openstreetmap.fr/jbtopo/Verrieres25.png
 
  Avec
  sur-impression d'une trace GPS, au-dessus de Grenoble 25Mo :
  http://osm101.openstreetmap.fr/jbtopo/LeSappeyGPS.png
 
  Et bien sûr, la
  légende : http://osm101.openstreetmap.fr/jbtopo/legende4.png
 
  Si vous
  voulez d'autres démos, demandez, ou créez-les vous-même (le tuto est là,
  avec tout ce qu'il faut… continuez à lire).
 
  La problématique :
 
  J'ai
  participé à une formation à OSM à laquelle participaient plusieurs
  personnes d'office de tourisme. Un point essentiel est ressorti : la
  base de données, l'accès à la donnée brute, c'est bien beau, mais
  qu'est-ce qu'on en fait ? On ne sait peut-être pas trop ce que c'est
  qu'une base de données, ça ne nous fait pas rêver, par contre, une
  carte, on aime, on n'en a pas, et on en veut.
 
  De mon coté, je suis
  intéressé de voir les capacités de la base OSM et des outils développés
  autour. J'ai aussi envie de développer un rendu topo/rando.
 
  À partir
  de là, j'ai commencé à travailler sur ce rendu topo, avec au fond de la
  tête l'idée qu'il serait bien utile, entre-autre, aux offices de
  tourisme. Est-ce que ce type de rendu pourrait aussi intéresser de
  nouvelles personnes au projet ?
 
  Les choix :
 
  - Maperitive/Tilemill ?
  On connait maintenant leurs différences (simplicité, orientation web,
  …). Comme je vise une mise à disposition pour les moins bricoleurs en
  informatique, je me suis rapidement reporté sur Maperitive
 
  -
  Mono-zoom/multi-échelle. Le travail sur un seul niveau de zoom me semble
  obliger à trancher plus nettement dans les données rendues, et ainsi
  espérer obtenir une carte plus claire. J'ai choisi de travailler à une
  échelle seule, pour une impression aux environs du 25000ème (15000 en
  milieu urbain).
 
  - Impression écran/papier. La résolution de l'écran
  oblige à utiliser des tailles de texte et de symboles assez grandes, pas
  forcément adaptées à une impression papier. J'ai choisi de privilégier
  le support papier.
 
  - Son nom, R25 pour l'instant, ouvert à toute
  proposition de modification.
 
  - Et bien sûr les choix de sélection, de
  représentation. Toujours critiquables, critiquez-les…
 
  Le travail :
 
 
  Plus de 3900 lignes de feuille de style (pour un seul niveau de
  zoom…). Si je recommençais demain (non, je ne le ferai pas), la feuille
  aurait été organisée légèrement différemment, elle pourrait être
  également condensée (mais finalement pas tant que ça). Je n'ai pas
  commencé à compter mes heures passées sur le projet, je pense que c'est
  mieux ainsi.
 
  La feuille de style est actuellement sous licence
  CC-by-nc-sa, du moins c'est ce qui est écrit partout ; mais je me suis
  déjà presque convaincu moi-même, il passe au CC-by-sa dès sa prochaine
  version (insistez juste un tout petit peu).
 
  Les défauts connus :
 
  La
  carte se limite toujours à la donnée disponible. On note que la donnée
  SRTM (courbes de niveau et ombrage) est parfois manquante, notamment
  dans les zones au relief accidenté.
 
  Le mono-échelle se casse les dents
  sur des zones à forte différence de densité de données. Le centre de
  Paris est bien plus lisible si imprimé au 15000ème, alors que le 25000
  en rando semble généralement bon.
 
  La suite :
 
  J'ai fini de travailler
  sur la feuille de style (c'est ce que je dis chaque matin depuis 10
  jours) ; le tutoriel niveau 0 est prêt, joint à ce mél. Au programme :
  un tutoriel de niveau plus élevé.
 
  Au programme aussi, recevoir vos
  retours que j'espère (raisonnablement) nombreux. Je pense qu'une partie
  d'entre vous va regarder ce que ça donne à coté de chez vous. Si vous
  voyez des

Re: [OSM-talk-fr] Rendu topo 25000ème

2013-04-03 Par sujet Mickaël Guéret

Salut JB,

très intéressant ton tuto, je vais me pencher là dessus dès que j'ai un
peu de temps. J'ai promis une carte de ce genre à des amis ;-)
As-tu tenté d'imprimer sur du papier ces rendus ?

Il y a en effet pas mal de trous dans les courbes de niveau. Une idée de
l'origine de ce problème ? J'avais essayé de travailler avec les données
brutes de la NASA, sous QGIS. Mais leur qualité est assez médiocre, cela
donnait un résultat assez décevant. Je n'ai pas insisté, peut être que
Grass s'en tirerait mieux (courbes qui faisaient des boucles, des angles
très aigus,etc...) 

Petite remarque à ce propos : je trouve tes lignes de niveau un peu trop
épaisses, trop visibles... sans vouloir t'offenser !

Cordialement,
Mika_Gueret
Qui va essayer de faire fonctionner Maperitive sous Debian Squeeze...







___
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 Par sujet Eric SIBERT


Le 03/04/2013 15:43, Jo. a écrit :

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.


Les repères géodésiques sont à priori un bon indice et les erreurs 
rares. Vérifier dans l'historique qu'ils n'ont pas été déplacés depuis 
leur import.



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


Le problème, c'est que le calage ne vaut qu'à proximité des repères 
géodésiques. Surtout en montagne.



Éric

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

Re: [OSM-talk-fr] Rendu topo 25000ème

2013-04-03 Par sujet Jean-Claude Repetto


Salut JB,

Bravo pour ton initiative. Je suis moi-même randonneur dans le 06, et 
j'ai apprécié de voir de nombreux sentiers que j'ai tracés sur une carte 
dans le style IGN, auquel on est habitué. Il y a bien sûr quelques 
améliorations à effectuer, mais c'est déjà impressionnant.


D'autre part, pourrais-tu STP éviter d'envoyer tes messages en HTML ? 
C'est contraire à la nétiquette des listes de diffusion, et en plus les 
liens ne sont pas cliquables.


Voici la version avec liens cliquables :


C'est maintenant sur osm107, soit :

Sur les premiers kilomètres de la ViaAlpina, de notre coté 108Mo :
http://osm107.openstreetmap.fr/jbtopo/ViaAlpina25.png
Sur le sud du Vercors 115Mo :
http://osm107.openstreetmap.fr/jbtopo/Vercors25.png
En centre ville, au 15000, à Paris 8Mo :
http://osm107.openstreetmap.fr/jbtopo/NotreDame15.png
À Strasbourg au 15000 13Mo :
http://osm107.openstreetmap.fr/jbtopo/Strasbourg15petit.png
À Strasbourg au 25000 19Mo :
http://osm107.openstreetmap.fr/jbtopo/Strasbourg25.png
En périurbain, à Verrières-le-Buisson 8Mo :
http://osm107.openstreetmap.fr/jbtopo/Verrieres25.png
Avec sur-impression d'une trace GPS, au-dessus de Grenoble 25Mo :
http://osm107.openstreetmap.fr/jbtopo/LeSappeyGPS.png
Et bien sûr, la légende : http://osm107.openstreetmap.fr/jbtopo/legende4.png



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

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

2013-04-03 Par sujet Jean-Claude Repetto


On 03/04/2013 19:53, Philippe Verdy wrote:

Le 3 avril 2013 19:22, Jean-Francois Nifenecker
jean-francois.nifenec...@laposte.net a écrit :

Il serait plus efficace/pertinent de créer un *nouveau* fil plutôt que de se
greffer/squatter un fil sans rapport.


Ce doit être ton client mail qui fait ça car moi je vois bien un
nouveau fil séparé, avec un titre séparé. Aucun squat de fil en vue.



Alors, c'est que ton client mail ne sait pas gérer les fils. Utilise un 
client plus performant, ou regarde les archives de la liste 
(http://lists.openstreetmap.org/pipermail/talk-fr/2013-April/thread.html), 
et tu verras que c'est le même fil.



___
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 Par sujet Eric SIBERT


Le 03/04/2013 15:56, Jean-Baptiste Holcroft a écrit :

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.


C'est une bonne base.


Le cas qui me paraît le plus critique est le cadastre mal
positionné.


C'est le cas qui me fait peur. Quand je tombe dessus, je ne sais pas 
quoi faire. Alors, je laisse en espérant qu'un jour le cadastre sera 
corriger et qu'on pourra refaire le bâti/ Je crains qu'en voulant 
corriger les intersections, on introduise des erreurs au lieu d'en enlever.


Éric

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

Re: [OSM-talk-fr] Rendu topo 25000ème (Bobo)

2013-04-03 Par sujet Bobo

Bravo,
c'est un chouette travail !

Pour la licence, j'appuie sur le côté NC, faut bien voir auprès de qui
tu souhaite partager ces techniques.
Je vais essayer de te faire des retours les prochaines semaines (pas
trop le temps en ce moment).

Bon courage pour la suite,

___
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 21:32, DH dhel...@free.fr a écrit :
 PS : et pis les relations c'est pas si compliqué que cela, sauf si elles
 font 500 km² et sont traversées par 2 voies ferrés, une autoroute, un canal
 à grand gabarit, qu'elles datent de 2006 et ne correspondent plus à grand
 chose sur le terrain !!

Là je te rejoins totalement.

Mais en fait plus la surface est grande et plus les relations sont
utiles pour éviter de former un écheveau incompréhensible de traits
superposés qu'on ne sait plus reconnecter à la moindre tentative de
modification locale : avec une relation on manipule des ways plus
courts, entrant en intersection avec beaucoup moins de choses et plus
faciles à réparer : c'est bien pour ça qu'on les privilégie fortement
pour les frontières administratives qui ont tendance à couvrir des
territoires assez grands et très diversifiés.

Alors même si pour modifier une très grande forêt on doit passer par
une relation, c'est tout de même bien plus stable et plus facile à
manipuler sur la carte. Les superpositions d'objets sont une vraie
plaie quand ces objets sont assez grands pour en couper ou recouvrir
plein d'autres, car il devient difficile de faire le tri et en fin de
compte ils finissent toujours par recouvrir/masquer quelquechose à
l'intérieur dans n'importe quel rendu (impossible de fixer des
priorités simples comme ente les terres et l'eau, les rendus ayant
tous pour parti pris de toujours dessiner l'eau par dessus les terres
en les masquant (sauf la mer qui est toujours affichée en premier avec
le fichier externe des lignes de côtes avant de représenter quoi que
ce soit).

En gros les moteurs de rendu s'en tirent en traçant les choses dans
l'ordre suivant :

- 1. les mers avec le fichier externes des lignes de côte
(raffraichissement uniquement tous les 1 ou 2 mois, pas de
rafraichissement en continu depuis la base)
- 2. les landuse et les natural
- 3. tout ce qui est l'eau (fleuves/rivières, canaux, lacs...)
- 4. les marais semi-transparents pouvant couvrir de la terre ou de l'eau
- 5. les bâtiments et autres constructions (murs, clotures, digues, barrages...)
- 6. les rues/routes/chemins/sentiers et les voies ferrées (uniquement
leurs traits, sans les noms)
- 7. les frontières administratives ou de parcs naturels ou autre
entités virtuelles non directement manifestées sur le terrain.
- 8. les icônes de POI
- 9. les libellés (le long des frontières ou au milieu d'une surface
ou à côté d'un noeud)

Au sein de chacune des 9 catégories ci-dessus, il leur est impossible
de fixer un ordre d'affichage car selon les géométries il faudrait que
ce soit l'un des polygones ou l'autre sans règle définissable.

On doit les aider en résolvant les ambiguïtés : cela oblige à créer
des trous inner pour permettre la séparation correcte des éléments.
Et pour le faire il n'y a pas d'autre moyen que d'utiliser des
multipolygones.

Hors justement les forêts et les clairières sont dans la même
catégorie (n° 2 dans la liste ci-dessus approximative). Il n'y a pas
moyen de fixer une priorité entre les éléments, ce qui oblige à les
séparer physiquement. Même si l'ensemble porte un nom (par exemple le
nom d'un parc tout entier comprenant champs, jardins, bois, lacs...) :
le nom devra être porté sur un élément englobant le tout, et il sera
affiché soit sur sa frontière externe (au niveaux de zoom éléevés)
soit au milieu de la surface à une position du centroïde calculée ou à
la position indiquée par un membre label d'une relation.

On n'est pas toujours obligé de découper les surfaces mitoyennes en
multipolygones pour autant, tant que ces surfaces n'ont pas d'autre
intersection commune que leur ligne de séparation. Mais dès qu'on
commence à superposer 3 ou 4 tracés de polygones sur les mêmes noeuds,
cela devient interfal de démêmler les écheveaux et les erreurs de
manipulations deviennent de plus en plus nombreuses (beaucoup plus que
qu on a fusionné les segments communs dans un chemin découpé inclus
dans un multipolygone : on a moins d'objets à manipuler
géométriquement, et il est plus facile de reconstruire correctement
les relations.

L'effet des modifications devient plus local (et il est même alors
possible de manipuler ces objets depuis Potlatch, alors que celui-ci
est incapable de charger des zones étendues couvrant tout le polygone
et permettant de les modifier de façon cohérente.

En résumé : plus les objets sont grands et courent de nombreux autres
objets, plus les multipolygones sont nécessaires.

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

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