date:20130403

Ben non, il gère parfaitement les fils de discussion mais sait aussi
les casser en deux branches quand on change de sujet, même si
l'identifiant de référence de suivi est resté le même. Si quelqu'un
répond à cette branche, il fera référence à ce nouveau message, la
suite s'en déduit et rien n'est cassé.
Mais Pipermail lui ne tient compte que du numéro de référence et ne
sait pas détecter quand il y a une branche changeant de sujet.

Le 3 avril 2013 22:47, Jean-Claude Repetto  a écrit :
> On 03/04/2013 19:53, Philippe Verdy wrote:
>>
>> Le 3 avril 2013 19:22, Jean-Francois Nifenecker
>>  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

___
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  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] Rendu topo 25000ème (Bobo)

2013-04-03 Thread 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] Rendu topo 25000ème

Le mer. 03 avril 2013 à 21:25 +0200, Guilhem Bonnefille a écrit :
> Bonsoir,
> 
> Erreur 404 aussi de mon coté, avec un "Site en maintenance" quand je
> remonte dans l'URL.
> 
J'ai ajouté une redirection http : maintenant, les "mauvais" liens (osm101)
renvoient sur les bons.
(oui, je sais, j'aurais pu le faire plus tôt).



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

2013-04-03 Thread Jean-Claude Repetto


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

Le 3 avril 2013 19:22, Jean-Francois Nifenecker
 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] Rendu topo 25000ème

2013-04-03 Thread 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] Proposition pour le projet du mois de avril

2013-04-03 Thread 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 Thread 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] Rendu topo 25000ème

2013-04-03 Thread 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  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 tutor

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

2013-04-03 Thread 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

 

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

2013-04-03 Thread 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  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

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

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,

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

2013-04-03 Thread 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] Un p'tit bout de serveur ?

2013-04-03 Thread Jean-Francois Nifenecker


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

Le 3 avril 2013 19:22, Jean-Francois Nifenecker
 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 Thread THEVENON Julien

> De : JB 


> 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 Thread 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  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)
___
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 Thread clansco

On Wed, 3 Apr 2013 19:53:59 +0200
Philippe Verdy  wrote:

> Le 3 avril 2013 19:22, Jean-Francois Nifenecker
>  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 ; Wed,  3 Apr 2013 12:11:52 +0200 (CEST)
MIME-Version: 1.0
Date: Wed, 03 Apr 2013 12:11:52 +0200
From: JB 
To: Discussions sur OSM en français 
In-Reply-To: 

References: 
 
 
 
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 ?

Le 3 avril 2013 19:22, Jean-Francois Nifenecker
 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] 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  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] Soucis avec les tuiles de Bing dans JOSM

2013-04-03 Thread 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] 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] Un p'tit bout de serveur ?

2013-04-03 Thread 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 à 16:59 +0200, Pieren a écrit :
> 2013/4/3 Guillaume Allegre 
> 
> >
> > > 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] Soucis avec les tuiles de Bing dans JOSM

2013-04-03 Thread 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] Soucis avec les tuiles de Bing dans JOSM

2013-04-03 Thread 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  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 
>
>> 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
>>
>
>
>
> --
> 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] 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  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] 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  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] 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 :
> 2013/4/3 Guillaume Allegre 
>>
>>
>> > 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 ?)

2013/4/3 Romain MEHUT 

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

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

2013-04-03 Thread 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-04-03 Thread 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  a écrit :

> Le 3 avril 2013 16:15,   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

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,   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] landuse pour un champ captant ?

2013/4/3 Guillaume Allegre 

>
> > 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 10:47, Pieren  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 ?

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

2013-04-03 Thread f . dos . santos



- Mail original -
De: "Pieren" 
À: "Discussions sur OSM en français" 
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 ?

2013/4/3 Guillaume Allegre 

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] Proposition pour le projet du mois de avril

2013-04-03 Thread 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"  a écrit :

> - 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
>
___
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 Thread 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  a écrit :

> - 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
>
___
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 
> 
> 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] expérimentations à Orange

2013-04-03 Thread thevenon . julien

- Mail original -
> De: "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

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] Proposition pour le projet du mois de avril

2013-04-03 Thread 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] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

2013/4/3 Jo. 

> 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] Usage de relations pour les parcs urbains...

2013-04-03 Thread 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,  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 
> To: "OpenStreetMap | Talk-fr" 
> 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 
> To: "Discussions sur OSM en français" 
> 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.56382&lon=0.31454&zoom=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  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 
> To: "Discussions sur OSM en français" 
> 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 
>
>> 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'utilise

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

2013-04-03 Thread 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 

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



-- 
Cordialement,
Francescu GAROBY
___
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 

>
> 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] Licence IP et ODBL ( était : L'ON3V libère ses =?iso-8859-15?q?_donn=E9s=3F?=)

2013-04-03 Thread Christian Rogel



Le 3 avr. 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. 

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] landuse pour un champ captant ?

2013/4/3 Vincent Pottier 

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] expérimentations à Orange

2013-04-03 Thread 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  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.08722&lon=4.7789&zoom=17&layers=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-04-03 Thread 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  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 
"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] Soucis avec les tuiles de Bing dans JOSM

2013-04-03 Thread 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] 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

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

2013-04-03 Thread 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] landuse pour un champ captant ?

2013-04-03 Thread 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

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 ?

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

[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] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

Le 3 avril 2013 12:07, Christian Quest  a écrit :
> Le 3 avril 2013 11:26, Philippe Verdy  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

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

2013-04-03 Thread 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 11:26, Philippe Verdy  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] 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  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.56382&lon=0.31454&zoom=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  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

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

2013-04-03 Thread 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] Nouveau problème sur le serveur (heure d'été ? ou mauvaise installation après réparation ?)

Le 3 avril 2013 08:40, Jo.  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

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

Le 3 avril 2013 11:05, JB  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] Projet Wikipedia, résultats

Le 3 avril 2013 08:46, Jo.  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 "&" 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=C&A", 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...

 

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.56382&lon=0.31454&zoom=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  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.56382&lon=0.31454&zoom=17
___
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 Thread 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"  a écrit :

> Tu parle bien de ce parc ?
> http://www.openstreetmap.org/?lat=46.56382&lon=0.31454&zoom=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  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...

Tu parle bien de ce parc ?
http://www.openstreetmap.org/?lat=46.56382&lon=0.31454&zoom=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  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] Licence IP et ODBL ( était : L'ON3V libère ses =?iso-8859-15?q?_donn=E9s=3F?=)

2013/4/2 Brice Person 

> 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

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

2013-04-03 Thread 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] Projet Wikipedia, résultats