[OSM-talk-fr] Prochaine réunion des contributeurs des Pyrénées-Orientales

[RainerU]

La prochaine réunion des contributeurs des P.O. aura lieu le mercredi 24 avril
2013 de 18h à 20h à la Cyber Bodega, 26 rue de l'Avenir, 66000 Perpignan.

Principales sujets :

- organisation d'une cartopartie en mai/juin.
- nos demandes de mise à disposition de données par la ville et l'agglo.





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

Re: [OSM-talk-fr] Source d'un label

[Philippe Verdy]

Le 20 avril 2013 22:41, Plop76  a écrit :

> Ah, c'est un peu de ma faute donc ;) C'est vrai que lorsque je touche à
> des waterway=riverbank, que ce soit relation ou polygone, j'ai tendance à
> utiliser le "New tagging" du wiki riverbank et à retirer le
> waterway=riverbank quand une partie n'est pas un vrai riverbank...
>

Pourquoi la boucle Nord de la Sein qui traverse le centre de Royen ne
serait pas un "vrai" riverbank ? En quoi tu veux lui appliquer une autre
politique par rapport au bras plus court et plus direct qui passe au Sud ?

Même si ce bras sud est canalisé, la bouche nord l'est aussi, la Seine n'a
dans cette zone cessé de faire des méandres avec des lits délaissés, puis
repris plus tard, et la canalisation a souvent tiré prodit des anciens lits
pour les remettre en eau et éviter des méandres qui ne sont pas toujours
vidés pour autant (pas comme le Bras de la Vilaine à l'Est de Reine, qui a
été comblé et est devenu une avenue, la Vilaine actuelle passant un peu
plus au Sud dans la "Plaine de Baud", via un bras auparavant plus mineur) ;

Il y a plein d'autres exemples où les lits de fleuves et rivières ont été
réaménagés, mais le creusement de canaux spécifiques là où il n'y avait
jamais eu de bras avant est assez rare, on a très souvent profité des
anciens bras morts, tout bonnement car c'était nettement moins coûteux et
plus facile à contrôler en cas de crue contre des inondations, les terrains
autour du bras mort formant déjà une cuvette limitant l'impact d'un
débordement. C'est dans le cas où il n'y a pas de restes de bras mort qu'on
creuse un canal de zéro mais ça coûte cher et cela crée des risques (et
pour les limiter on garde le lit naturel encore en eau même si le lit
naturel devient un bras mineur en terme de débit (ce ne sera pas un lit
mineur en cas de crue).

J'ai peut qu'on se retrouve aussi dana la base avec des (multi)polygones
"natural=water" et pas seulement "water=river" mais aussi avec
"water=stream", "water=canal"; "water=delta", "water=mouth",
"water=canalized_river", "water=waterfall", et d'autres qui n'apparaissent
pas encore ou que j'aurais oubliés (pour le drainage ou l'irrigation ou des
lits formés par l'assèchement et la surélévation de terrains dans des
marais), là où avant on avait un unique "waterway=riverbank" pour tous les
lits secondaires (qui forment souvent un fin maillage dans les zones de
marais ou les deltas, sans que tous les bras ne prennent un nom spécifique,
et sans forcément un sens unique de circulation naturelle de l'eau)
==> Dans ce cas il faudrait traiter tous les polygones
"naturel=water"+"water=*" comme équivalents aux "waterway=riverbank" (ce
qui inclut alors aussi les bassins et étangs de rétention ou de
débordement, en marge des fleuves et rivières, et les biefs qui les
alimentent ou les vident, la valeur donnée à "water)*" étant un détail de
spécilaistes, assez difficile en fait à évaluer et différencier.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/

[Jo.]

Pour les imports de --water je confirme pour y avoir passer de nombreuse
heure à les convertir en fossé ou ruisseau intermittent. D'ailleurs comment
utiliser ce genre de donnée efficacement ?


Le 20 avril 2013 23:35, Francescu GAROBY  a écrit :

> Pour les --water, il me semblait que ça avait été coupé parce que certains
> ne savaient pas les utiliser correctement et qu'il y avait de l'import
> foireux (appelons un chat un chat).
> Pour les--houses, je trouve que c'est pratique de les garder à part :
> perso, il m'arrive de ne vouloir que ça, pour vérifier/compléter le bâti
> d'une commune. Télécharger le tar.bz2  compliquerait les choses (c'est pas
> insurmontable, certes)...
>
> Francescu
>
>
> Le 20 avril 2013 23:30, Nicolas Dumoulin <
> nicolas_openstreetmap@dumoulin63.net> a écrit :
>
> Le vendredi 19 avril 2013 22:26:59 Francescu GAROBY a écrit :
>> > Bonsoir,
>> > Bonne nouvelle : cadastre refonctionne !
>> > Un  changement de plate-forme d'hébergement ayant eu lieu, vous pouvez
>> > rencontrer un problème d'accès, le temps que les DNS se mettent à jour
>> > (mais chez moi, ça fonctionne déjà).
>>
>> Youpi, merci !
>>
>> Par contre, on n'avait pas dit qu'on ne donnait plus les "*-water" ?
>> D'ailleurs, histoire de gagner en stockage, les "*-houses.osm" sont
>> superflus
>> vu qu'on a l'archive compressée en tar.bz2 … je dis ça, je dis rien.
>>
>> Merci encore
>>
>> --
>> Nicolas Dumoulin
>> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>>
>> ___
>> 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] Idée de projet du mois de Mai (ou plus tard)

[Jo.]

Honnêtement je ne sais pas et dans le doute je préfère indiquer chacune des
voies au cas par cas. Si les voies à 30 km/h ne sont pas indiqué en tant
que tel, elles risquent d'être indiqué automatiquement comme étant à 50
km/h tant que leur limitation réelle ne sera pas explicitement indiquée.

Et ça permet d'avoir un visuel sur l'avancement du travail déjà effectué,
par exemple sur Narbonne que je suis en train de quadrillé quartier par
quartier : http://www.itoworld.com/map/35?lon=2.99667&lat=43.18322&zoom=14


Le 19 avril 2013 16:34, Tetsuo Shima  a écrit :

> Pour les limitations de vitesse implicites ... on se base sur quoi?! les
> landuse résidentiel pour définir si la route est en agglomération ou pas?
> ou faut-il expliciter chaque voie? Parce que la position du panneau fin
> agglomération début d'agglomeration n'a rien d'implicite elle?
>
>
> Le 19 avril 2013 13:17, Jo.  a écrit :
>
>> Suite à l’intérêt porté sur ce projet j'ai mis à jour la page du projet
>> en déplaçant le rappel du code de la route vers la page maxspeed. J'ai
>> également ajouté deux lien vers des carte ITO et quelques idée de
>> contribution parallèle que l'on peut relevé sur place.
>>
>>
>> http://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/Limitation_de_vitesse
>> http://wiki.openstreetmap.org/wiki/FR:Key:maxspeed
>>
>> Les cartes ITO :
>> http://www.itoworld.com/map/42?lon=2.33948&lat=48.76664&zoom=8
>> http://www.itoworld.com/map/35?lon=2.36557&lat=48.82856&zoom=11
>>
>>
>> Le 19 avril 2013 13:05, Jo.  a écrit :
>>
>> Suggestion : afficher les panneaux de signalisation surcharge la carte
>>> quand on visionne de grande zone. Leur affichage est intéressant pour des
>>> zone fortement zoomée.
>>>
>>>
>>> Le 19 avril 2013 11:29, kimaidou  a écrit :
>>>
>>> Tony, les autres

 Comme j'ai ajouté le support de l'emprise dans le permalink de LizPoi,
 on peut maintenant se passer des URL de démonstration plus parlante.
 Par exemple les voies limitées à 30km/h dans le centre d'Orange :

 http://lizpoi.3liz.com/orange/index.php/lizpoi/map/?tree_id=7&selected=390&bbox=534076.178002,5486262.102976,536505.442306,5487657.078742&zoom=16




 Le 19 avril 2013 10:47, Jo.  a écrit :

 Même les gabarits… cool moi qui roule souvent en PL j'apprécie beaucoup
> ce genre d'information.
>
>
> 2013/4/18 Tony Emery 
>
>> Pour info, voilà où nous en sommes à  Orange
>>   .
>>
>> Vous pouvez vous balader et voir aussi les limitations de gabarit,
>> etc...
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://gis.19327.n5.nabble.com/Idee-de-projet-du-mois-de-Mai-ou-plus-tard-tp5757552p5757620.html
>> Sent from the France mailing list archive at Nabble.com.
>>
>> ___
>> 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
>
>

 ___
 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
>>
>>
>
> ___
> 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] http://cadastre.openstreetmap.fr/

[Francescu GAROBY]

Pour les --water, il me semblait que ça avait été coupé parce que certains
ne savaient pas les utiliser correctement et qu'il y avait de l'import
foireux (appelons un chat un chat).
Pour les--houses, je trouve que c'est pratique de les garder à part :
perso, il m'arrive de ne vouloir que ça, pour vérifier/compléter le bâti
d'une commune. Télécharger le tar.bz2  compliquerait les choses (c'est pas
insurmontable, certes)...

Francescu


Le 20 avril 2013 23:30, Nicolas Dumoulin <
nicolas_openstreetmap@dumoulin63.net> a écrit :

> Le vendredi 19 avril 2013 22:26:59 Francescu GAROBY a écrit :
> > Bonsoir,
> > Bonne nouvelle : cadastre refonctionne !
> > Un  changement de plate-forme d'hébergement ayant eu lieu, vous pouvez
> > rencontrer un problème d'accès, le temps que les DNS se mettent à jour
> > (mais chez moi, ça fonctionne déjà).
>
> Youpi, merci !
>
> Par contre, on n'avait pas dit qu'on ne donnait plus les "*-water" ?
> D'ailleurs, histoire de gagner en stockage, les "*-houses.osm" sont
> superflus
> vu qu'on a l'archive compressée en tar.bz2 … je dis ça, je dis rien.
>
> Merci encore
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> ___
> 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] http://cadastre.openstreetmap.fr/

[Nicolas Dumoulin]

Le vendredi 19 avril 2013 22:26:59 Francescu GAROBY a écrit :
> Bonsoir,
> Bonne nouvelle : cadastre refonctionne !
> Un  changement de plate-forme d'hébergement ayant eu lieu, vous pouvez
> rencontrer un problème d'accès, le temps que les DNS se mettent à jour
> (mais chez moi, ça fonctionne déjà).

Youpi, merci !

Par contre, on n'avait pas dit qu'on ne donnait plus les "*-water" ?
D'ailleurs, histoire de gagner en stockage, les "*-houses.osm" sont superflus 
vu qu'on a l'archive compressée en tar.bz2 … je dis ça, je dis rien.

Merci encore

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/

[Nicolas Dumoulin]

Le samedi 20 avril 2013 02:24:56 PhQ a écrit :
> Suite au redémarrage du service, j'ai le plaisir, l'honneur et l'avantage de
> vous signaler la fin de l'import du bâti du PDD (63) .
> A nous le plaisir des mis à jour et suivi :)

Heu, il semble en manquer encore un peu. Par exemple sur la commune d'Aydat, 
je n'avais importé que les villages d'Aydat et de Verneuge :
http://tile.openstreetmap.fr/?zoom=14&lat=45.66364&lon=3.00299&layers=B0F

Ce qui est sûr c'est qu'il y a déjà pas mal de boulot en mise à jour depuis 
les premiers imports de 2-3 ans !

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Source d'un label

[Plop76]

Dans son message précédent, Christian Quest a écrit :


Ces libellés pas trop contrôlés proviennent souvent du layer "area-text" du
projet tilemill, donc je passe la couleur de texte en rouge sur ce layer
pour avoir confirmation, puis au lieu d'afficher le name, j'affiche l'id de
l'objet OSM et là j'ai un beau -13820 en rouge. Il s'agit donc de la
relation 13820: http://www.openstreetmap.org/browse/relation/13820


J'avais bien trouvé plusieurs waterway=riverbank non fermés avec "La 
Seine" comme nom et j'étais sceptique sur leur culpabilité, mais la 
relation 13820 n'était pas du tout un suspect à mes yeux :)



Pas contre, le rendu affiche ce libellé indésirable car ce multipolygone
est taggué en natural=water + water=river, alors que d'habitude on a un
waterway=riverbank. Il y a 33 multipolygones de ce type sur un extrait
France.


Ah, c'est un peu de ma faute donc ;) C'est vrai que lorsque je touche à 
des waterway=riverbank, que ce soit relation ou polygone, j'ai tendance 
à utiliser le "New tagging" du wiki riverbank et à retirer le 
waterway=riverbank quand une partie n'est pas un vrai riverbank...


Merci.




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

Re: [OSM-talk-fr] Source d'un label

[Christian Quest]

Rien dans JOSM bien sûr à cet emplacement... ça serait beaucoup trop facile
;)

J'ai retrouvé l'objet à l'origine de ce libellé en bricolant le rendu FR.

Ces libellés pas trop contrôlés proviennent souvent du layer "area-text" du
projet tilemill, donc je passe la couleur de texte en rouge sur ce layer
pour avoir confirmation, puis au lieu d'afficher le name, j'affiche l'id de
l'objet OSM et là j'ai un beau -13820 en rouge. Il s'agit donc de la
relation 13820: http://www.openstreetmap.org/browse/relation/13820

C'est un multipolygone de la boucle de la Seine qui traverse Rouen plus au
sud... allez savoir comment postgis/mapnik arrivent à mettre le libellé à
cet endroit ! Y'a un bug quelque part, c'est sûr pour ce qui est de la
position du libellé.

Pas contre, le rendu affiche ce libellé indésirable car ce multipolygone
est taggué en natural=water + water=river, alors que d'habitude on a un
waterway=riverbank. Il y a 33 multipolygones de ce type sur un extrait
France.

J'ai modifié le rendu FR pour qu'il tienne compte des natural=water +
water=river de la même façon que pour les waterway=riverbank (pour la
prochaine mise à jour des tuiles).

-- 
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] Source d'un label

[Jean-Francois Nifenecker]

Bonjour,

Le 20/04/2013 19:56, Plop76 a écrit :


Un label "La Seine" se ballade en dehors de son lit habituel :
http://www.openstreetmap.org/?lat=49.47193&lon=1.13228&zoom=15&layers=M
(en plein milieu, à gauche de la rocade)

Comment savoir d'où vient ce label ?


un waterway=riverbank mal fermé ?

Le rendu n'étant pas un bon indice, voir dans JOSM pour avoir une idée 
plus précise.


--
Jean-Francois Nifenecker, Bordeaux

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

[OSM-talk-fr] Source d'un label

[Plop76]

Bonjour,

Un label "La Seine" se ballade en dehors de son lit habituel : 
http://www.openstreetmap.org/?lat=49.47193&lon=1.13228&zoom=15&layers=M 
(en plein milieu, à gauche de la rocade)


Comment savoir d'où vient ce label ?




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

Re: [OSM-talk-fr] Rendu OSM-FR : couleurs highway

[Pierre-Alain Dorange]

Christian Quest  wrote:

> J'ai fait le choix de ne pas trop m'écarter du style OSM actuel pour
> permettre d'identifier le rendu "FR" comme provenant d'OSM.
> 
> J'ai déjà modifié la couleur verte des trunks pour qu'elles soient
> plus contrastées sur les landuse de couleur proche mais ça peut
> sûrement encore s'affiner sans changer complètement le jeu de couleur.

Je comprend, mais a mon avis, les trunks ne sont toujours pas du tout
assez visible... Ils disparaissent litéralement, tout les autres axes
routiers sont beaucoup plus visible, c'est un soucis de hiérarchisation
amha.

Sur l'exemple cité, on voit bien que la structure routière la ville de
Saintes forme un arc sud clair, sur toutes les cartes... Sauf celle
d'OSM ou il "manque" un bout qui est un trunk.

Je dois être daltonien et le seul que cela gène... j'avais fait un
rapport il y a 3 ans, sans retour...


-- 
Pierre-Alain Dorange
OSM experiences : 


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

Re: [OSM-talk-fr] Compte bloqué : je fais quoi ?

[Philippe Verdy]

J'ai eu le problème temporairement, il s'est passé tout seul au redémarrage
du serveur.
Mais le problème peut arriver même sur un changeset très petit. Pour une
raison inconnue, le serveur cesse de répondre à la requête et tue la
session alors que du côté SQL la transaction n'est pas annulée ni
"revertée". On se retrouve alors avec un changeset vide toujours ouvert, et
bloquant tout le reste.
Une solution peut être de tenter de chercher les changesets encore ouverts
(même s'ils sont vides) pour les fermer avant de reprendre.
Et j'évite bien des problèmes en n'envoyant pas des lots de données trop
gros (j'envoie 5 objets maxi par requête, et autant de requêtes si
nécessaire dans le changeset. Cela évite bien des ruptures de session, le
serveur répond correctement.
Je voudrais bien mettre plus que 5 objets mais JOSM actuellement ne permet
pas de distinguer entre un envoi de neuds (on peut les envoyer par paquet
de 200 environs), et un envoi de chemins ou relations (en comptant le
nombre de leurs membres).
Mais avec le réglage à 5 objets maxi par requête, j'ai de bonnes
performances globales, pas réellement pires que si j'en envoyais plus, et
le serveur traite ces requêtes plus petites bien plus facilement et plus
vite, donc j'ai moins de chance de perdre la session... mais ça arrive
parfois quand même).
Si j'ai une rupture de session c'est aussi plus facile de corriger ce qu'il
y a ou pas dans la base (sinon on risque de renvoyer plein de doublons et
de laisser des centaines de noeuds orphelins, inutilisés ensuite par les
chemins ou relations).




Le 20 avril 2013 16:05, Vincent Pottier  a écrit :

> Bonjour,
> Je ne peux toujours pas uploader des modifications : création de changeset
> impossible sur mon compte, modification impossible des informations sur ma
> page user...
> J'ai déjà ré-ouvert deux fois le ticket 4540 :
> https://trac.openstreetmap.**org/ticket/4540
>
> Contrairement à ce que dit TomH :
>
>>
>> I think the problem is most likely just that the data you uploaded from
>> data2upload.osm is large, and touches a number of very large and
>> complicated relations, so processing it will take some time and your user
>> record is likely to be locked during that processing.
>>
>> You should really wait for a changeset upload to complete before trying
>> to do any more edits, or at least before trying to do any more uploads.
>>
>> In any case this is not related (and never really was) to this ticket, so
>> we should stop reopening this ticket now.
>>
>>  je suis convaincu que ça n'est pas une question de taille de changeset :
> il n'y a même pas eu de création de changeset par JOSM aujourd'hui.
> Et sa réponse fait un peu fin de non recevoir !
>
>  You should really wait for a changeset upload to complete
>>
> J'aimerai bien !
>
> Je ne voudrais pas le froisser, mais c'est frustrant et ça fait un moment
> que ça dure !
> Je ré-ouvre le ticket ? J'en crée un autre ? J'arrête de contribuer à OSM ?
> --
> FrViPofm
>
> __**_
> 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] Compte bloqué : je fais quoi ?

[Vincent Privat]

Tom a un surnom de "M. Wontfix" sur certains tickets à cause de sa
propension à les fermer plus vite que son ombre, souvent sans chercher à
comprendre.
Je pense que ce qui le gêne dans l'histoire, c'est que malgré les symptômes
identiques au problèmes de Christian, il ne s'agit pas en amont du même
problème.
Essaye de créer un nouveau ticket en restant le plus courtois possible, on
verra bien sa réaction...


Le 20 avril 2013 16:05, Vincent Pottier  a écrit :

> Bonjour,
> Je ne peux toujours pas uploader des modifications : création de changeset
> impossible sur mon compte, modification impossible des informations sur ma
> page user...
> J'ai déjà ré-ouvert deux fois le ticket 4540 :
> https://trac.openstreetmap.**org/ticket/4540
>
> Contrairement à ce que dit TomH :
>
>>
>> I think the problem is most likely just that the data you uploaded from
>> data2upload.osm is large, and touches a number of very large and
>> complicated relations, so processing it will take some time and your user
>> record is likely to be locked during that processing.
>>
>> You should really wait for a changeset upload to complete before trying
>> to do any more edits, or at least before trying to do any more uploads.
>>
>> In any case this is not related (and never really was) to this ticket, so
>> we should stop reopening this ticket now.
>>
>>  je suis convaincu que ça n'est pas une question de taille de changeset :
> il n'y a même pas eu de création de changeset par JOSM aujourd'hui.
> Et sa réponse fait un peu fin de non recevoir !
>
>  You should really wait for a changeset upload to complete
>>
> J'aimerai bien !
>
> Je ne voudrais pas le froisser, mais c'est frustrant et ça fait un moment
> que ça dure !
> Je ré-ouvre le ticket ? J'en crée un autre ? J'arrête de contribuer à OSM ?
> --
> FrViPofm
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Compte bloqué : je fais quoi ?

[Vincent Pottier]

Bonjour,
Je ne peux toujours pas uploader des modifications : création de 
changeset impossible sur mon compte, modification impossible des 
informations sur ma page user...

J'ai déjà ré-ouvert deux fois le ticket 4540 :
https://trac.openstreetmap.org/ticket/4540

Contrairement à ce que dit TomH :


I think the problem is most likely just that the data you uploaded 
from data2upload.osm is large, and touches a number of very large and 
complicated relations, so processing it will take some time and your 
user record is likely to be locked during that processing.


You should really wait for a changeset upload to complete before 
trying to do any more edits, or at least before trying to do any more 
uploads.


In any case this is not related (and never really was) to this ticket, 
so we should stop reopening this ticket now.


je suis convaincu que ça n'est pas une question de taille de changeset : 
il n'y a même pas eu de création de changeset par JOSM aujourd'hui.

Et sa réponse fait un peu fin de non recevoir !


You should really wait for a changeset upload to complete

J'aimerai bien !

Je ne voudrais pas le froisser, mais c'est frustrant et ça fait un 
moment que ça dure !

Je ré-ouvre le ticket ? J'en crée un autre ? J'arrête de contribuer à OSM ?
--
FrViPofm

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

Re: [OSM-talk-fr] Cartopartie au cimetière du Père-Lachaise

[Philippe Verdy]

Tout à fait approprié, pourtant sa tombe est une des plus visitées (ce qui
apporte aussi des subsides pour l'entretien du reste du cimetière) et les
plus abondamment et fréquemment fleuries. Il faut dire aussi qu'elle est
superbe par la gravure et sa représentation immortelle.

Il n'y en a pas autant pour la tombe d'André Citroen (je ne sais même pas
où elle est, peu importe), ni celle de Christian Dior pourtant mort très
récemment, ou encore celle de François Mitterrand ou Charles de Gaulle,
hormi à certaines dates de cérémonies officielles. Mais en fin de compte
est-ce si important ?

Les morts ont droit aussi à leur intimité et celle de leur famille qui
apportent des embellissements simples mais bien plus importants que ceux
apportés par des "fans" aussi nombreux soient-ils : comment une famille
pourrait identifier son propre apport modeste ou se recueillir face à des
nuées de fans toute l'année sur la tombe de leur défunt? Dalida n'a
cependant pas laissé de famille hors de son frère qui gère la marque
"Dalida" et ne s'est pas beaucoup occupé d'elle de son vivant.

La beauté d'un cimetière c'est celle des ornements simples de sépultures
très différentes. Elle est moins dans les monuments funéraires que dans les
petits apports minimes qui témoignent qu'on a aimé ces personnes, et dans
le recueillement des gens les plus simples qu'on ne doit pas déranger dans
leur hommage et leur souvenir, et même s'ils n'apportent rien (leur seule
présence suffit). Ceux qui ont perdu un être cher, un parent, un enfant, le
savent, respectent ces lieux et ceux qui viennent s'y recueillir même sur
les tombes les plus simples ou devant une simple plaque au pied d'un carré
de pelouse où on a dispersé les cendres.


2013/4/20 Christian Quest 

> Ci-git Dalida©®™
>
>
> ___
> 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] Rendu OSM-FR : couleurs highway

[Philippe Verdy]

En même temps OSM a fait des compromis pour s'adapter aux couleurs
habituellement utilisées dans certains pays : le Royaume-Uni par exemple a
ses motorways différents du reste de l'Europe.

Si on regarde dans le détail chaque pays, il y a des adaptations locales du
rendu du réseau routier, de la couleur des cartouches pour les numéros des
routes, pour la façon d'afficher des restrictions de circulation comme les
sens de circulation obligatoires et interdits.

La couleur habituelle des autoroutes en France est une ligne jaune tracée
au milieu sur une ligne rouge plus épaisse (le fin liseré rouge foncé ou
noir en bordure est optionnel mais s'obtient aussi facilement en traçant
d'abord la ligne plus foncée légèrement plus épaisse avant les lignes rouge
et jaune).

[note]
Pour tracer les tunnels c'est un peu plus compliqué car on ne peut pas
superposer des traits pleins si le coeur de la ligne doit rester
semi-transparent : les pointillés de bordure demandent de préparer d'abord
une géométrie de "buffers" : ce que fait de toute façon le tracé de
n'importe quelle ligne simple qui nécessite de transformer un trait sans
aucune épaisseur, en un polygone à remplir, avec en plus un éventuel rendu
anticrénelage utilisant des pixels semi-transparents tout autour...). Mais
là on entre dans la mécanique et les performances du moteur de rendu
vectoriel (ils sont aujourd'hui excellent pour le rendu SVG et profitent
des accélérations matérielles des cartes graphiques actuelles pour ne pas
avoir à utiliser les anciennes techniques plus lentes et plus couteuses en
temps de calcul, de type FSAA ; tout bon rendu travaille aujourd'hui dans
un colorspace de type RGBA et non plus RGB, même si l'image produite en
final est de type RGB seulement).
[/note]

Donc en France on peut tout à fait utiliser un rendu plus habituel à ce
qu'on trouve habituellement. Mais Google Maps lui ne le fait pas (en
revanche son schéma de couleurs est plus lisible et permet plus facilement
de positionner des bulles bien lisibles pour les POIs métiers, car les
couleurs de fond sont nettement plus pâles), et les libellés affichés en
couleurs foncées sont alors aussi plus lisibles.

On a de quoi s'en inspirer (sans chercher à copier le style, même si on est
habitué en France au style Michelin) en évitant justement de tracer des
traits noirs ou trop foncés un peu partout, et en éclaircissant nettement
le rendu des bâtiments notamment en zone urbaine dense où les couleurs
actuelles rendent les nombreux POIs et libellés peu lisibles.



Le 20 avril 2013 13:46, Christian Quest  a écrit :

> J'ai fait le choix de ne pas trop m'écarter du style OSM actuel pour
> permettre d'identifier le rendu "FR" comme provenant d'OSM.
>
> J'ai déjà modifié la couleur verte des trunks pour qu'elles soient
> plus contrastées sur les landuse de couleur proche mais ça peut
> sûrement encore s'affiner sans changer complètement le jeu de couleur.
>
>
> Le 20 avril 2013 12:47, Pierre-Alain Dorange  a écrit :
> > Je suis géné depuis longtemps par les couleurs utilisées par le rendu
> > par défaut de osm.org (mapnik) notamment concernant les routes et plus
> > particulièrements les highway qi sont rendus en vert... Ce qui ce
> > confond très largement avec les forêts et autres champs.
> > Rendant la lisibilité de ces axes importants plus faible que les routes
> > secondaires...
> >
> > D'autres rendus, comme OpenMapQuest utilisent des jeux de couleurs
> > différents qui permettent de bien rendre lisible tout les axes (en même
> > temps heureusement car c'est un rendu orienté routes).
> >
> > Mapnik est bien sur un rendu généraliste qui sert de base, et qui doit
> > essayé de tout rendre au mieux (pas simple), mais je trouve vraiment
> > dommageable ce manque flagrant de lisibilité pour les axes xxx qui sont
> > quand même très important et structurant.
> >
> > Comme la communauté française dispose désormais d'une base
> > d'expérimentation (merci Christian), je proposerai (à discuter bien sur)
> > d'utiliser d'autres jeux de couleurs et d'expérimenter, par exemple :
> >
> > motorway : Bleu foncé/violet
> > trunk : Bleu
> > primary, primary_link : Rouge
> > secondary, secondary_link : Orange
> > tertiary, tertiary_link : Jaune
> > unclassified, residential, road : Blanc
> > living_street, pedestrian : Gris clair
> > service :
> > track, path : pointillé noir ?
> >
> > J'y connais rien en rendu mais le plus souvent les axes autoroutes et
> > routes pour automobile sont rendus avec un style différent : couleur
> > interne et bordure d'une autre couleur et épaisse. C'est la cas de
> > openmapquest, Michelin, IGN... Je sais pas si c'est possible mais c'est
> > une piste à explorer pour rentrer dans les "standards"...
> >
> > Pour illustrer voici une image du même endroit avec plusieurs rendus
> > (dont des rendus commerciaux) :
> > 
> >
> > --
> > Pierre-Alain Dorange
> > OSM experiences : 

[OSM-talk-fr] tag pour un toit en terrasse

[Agnès Rambaud]

Bonjour,

Je m'attaque à spécifier les différents types de building=* (à la place 
des yes).


Comment peut-on indiquer un toit (de quelque chose, comme une habitation 
ou un garage) qui est aussi une terrasse ?

Je ne trouve pas d'info particulière nulle part à ce sujet.

Agnès

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

Re: [OSM-talk-fr] Rendu OSM-FR : couleurs highway

[Christian Quest]

J'ai fait le choix de ne pas trop m'écarter du style OSM actuel pour
permettre d'identifier le rendu "FR" comme provenant d'OSM.

J'ai déjà modifié la couleur verte des trunks pour qu'elles soient
plus contrastées sur les landuse de couleur proche mais ça peut
sûrement encore s'affiner sans changer complètement le jeu de couleur.


Le 20 avril 2013 12:47, Pierre-Alain Dorange  a écrit :
> Je suis géné depuis longtemps par les couleurs utilisées par le rendu
> par défaut de osm.org (mapnik) notamment concernant les routes et plus
> particulièrements les highway qi sont rendus en vert... Ce qui ce
> confond très largement avec les forêts et autres champs.
> Rendant la lisibilité de ces axes importants plus faible que les routes
> secondaires...
>
> D'autres rendus, comme OpenMapQuest utilisent des jeux de couleurs
> différents qui permettent de bien rendre lisible tout les axes (en même
> temps heureusement car c'est un rendu orienté routes).
>
> Mapnik est bien sur un rendu généraliste qui sert de base, et qui doit
> essayé de tout rendre au mieux (pas simple), mais je trouve vraiment
> dommageable ce manque flagrant de lisibilité pour les axes xxx qui sont
> quand même très important et structurant.
>
> Comme la communauté française dispose désormais d'une base
> d'expérimentation (merci Christian), je proposerai (à discuter bien sur)
> d'utiliser d'autres jeux de couleurs et d'expérimenter, par exemple :
>
> motorway : Bleu foncé/violet
> trunk : Bleu
> primary, primary_link : Rouge
> secondary, secondary_link : Orange
> tertiary, tertiary_link : Jaune
> unclassified, residential, road : Blanc
> living_street, pedestrian : Gris clair
> service :
> track, path : pointillé noir ?
>
> J'y connais rien en rendu mais le plus souvent les axes autoroutes et
> routes pour automobile sont rendus avec un style différent : couleur
> interne et bordure d'une autre couleur et épaisse. C'est la cas de
> openmapquest, Michelin, IGN... Je sais pas si c'est possible mais c'est
> une piste à explorer pour rentrer dans les "standards"...
>
> Pour illustrer voici une image du même endroit avec plusieurs rendus
> (dont des rendus commerciaux) :
> 
>
> --
> Pierre-Alain Dorange
> OSM experiences : 
>
>
> ___
> 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] Rendu OSM-FR : couleurs highway

[Pierre-Alain Dorange]

Je suis géné depuis longtemps par les couleurs utilisées par le rendu
par défaut de osm.org (mapnik) notamment concernant les routes et plus
particulièrements les highway qi sont rendus en vert... Ce qui ce
confond très largement avec les forêts et autres champs.
Rendant la lisibilité de ces axes importants plus faible que les routes
secondaires...

D'autres rendus, comme OpenMapQuest utilisent des jeux de couleurs
différents qui permettent de bien rendre lisible tout les axes (en même
temps heureusement car c'est un rendu orienté routes).

Mapnik est bien sur un rendu généraliste qui sert de base, et qui doit
essayé de tout rendre au mieux (pas simple), mais je trouve vraiment
dommageable ce manque flagrant de lisibilité pour les axes xxx qui sont
quand même très important et structurant.

Comme la communauté française dispose désormais d'une base
d'expérimentation (merci Christian), je proposerai (à discuter bien sur)
d'utiliser d'autres jeux de couleurs et d'expérimenter, par exemple :

motorway : Bleu foncé/violet
trunk : Bleu
primary, primary_link : Rouge
secondary, secondary_link : Orange
tertiary, tertiary_link : Jaune
unclassified, residential, road : Blanc
living_street, pedestrian : Gris clair
service : 
track, path : pointillé noir ?

J'y connais rien en rendu mais le plus souvent les axes autoroutes et
routes pour automobile sont rendus avec un style différent : couleur
interne et bordure d'une autre couleur et épaisse. C'est la cas de
openmapquest, Michelin, IGN... Je sais pas si c'est possible mais c'est
une piste à explorer pour rentrer dans les "standards"...

Pour illustrer voici une image du même endroit avec plusieurs rendus
(dont des rendus commerciaux) :


-- 
Pierre-Alain Dorange
OSM experiences : 


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

Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/

[PhQ]

Suite au redémarrage du service, j'ai le plaisir, l'honneur et l'avantage de
vous signaler la fin de l'import du bâti du PDD (63) .
A nous le plaisir des mis à jour et suivi :)



--
View this message in context: 
http://gis.19327.n5.nabble.com/http-cadastre-openstreetmap-fr-tp5757271p5757797.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Cartopartie au cimetière du Père-Lachaise

[Christian Quest]

Ci-git Dalida©®™
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cartopartie au cimetière du Père-Lachaise

[Philippe Verdy]

Concernant le fichier RNIPP de l'INSEE ou du CNAVTS (français nés à
l'étranger, dans les TOM ou Mayotte)

[citation]
Qui peut consulter ce fichier ?
Les organismes autorisés par la CNIL ou par des dispositions législatives
ou réglementaires prises après avis de la CNIL.
Le casier judiciaire reçoit chaque année un extrait du RNIPP conformément à
l’article 1er de la loi n°80-2 du 4 janvier 1980
[/citation]

Autrement dit il existe des restrictions à la consultation publique de ce
fichier.

L'autorisation donnée par la CNIL pourrait donc ne pas s'étendre d'une part
à d'autres personnes que celle autorisées ci-dessus, ni à leur mise en
place par d'autres que l'Insee et le CNAVTS.

Prudence donc concernant les noms de personnes physiques (dans une autre
proposition j'avais parlé de n'indiquer QUE les noms d'artistes et un lien
vers Wikipédia pour leur biographie, pas le reste ; même le lien vers
Wikipédia pourrait être un article sujet au respect des droits exclusifs de
la personnes, qui s'étendent 70 ans après leur mort, une durée étendue en
cas de "mort pour la France' ou de vie durant les périodes de guerre).

On peut considérer que la sépulture des personnes rentre aussi dans le
champ du droit d'auteur (la personne a eu le droit d'organiser ses
obsèques, son monument funéraire, et sa mémoire). Avant d'intégrer les noms
des personnes sur les tombes, un avis de la CNIL sera sans doute nécessaire
(déclaration en bonne et due forme de la base OSM : description des champs,
droit d'accès et de correction pour les héritiers représentants légaux des
défunts, description complète des usages très ouverts par l'inscription
dans OSM puisqu'il n'y aura aucune restriction, la CNIL doit le savoir et
pourrait opposer son veto complet à une telle inscription de données
personnelles).

En y réfléchissant je ne suis même pas sûr que les noms d'artistes puissent
même y figurer (ils font partie de la propriété intellectuelle couverte par
le droit d'auteur et dont sont titulaires les héritiers légaux qui peuvent
les exploiter comme des marques commerciales, par exemple "Picasso",
"Dalida", "Dior", "Citroen"... des marques qui par ailleurs pourraient déjà
avoir été cédées par les personnes de leur vivant sans les priver, de leur
droit personnel de continuer à porter ce nom pour elles et leurs conjoint
ou enfants ou le reste de leur famille, seul ce droit s'éteignant à leur
mort, mais pas leur droit moral).




Le 18 avril 2013 16:15, Pieren  a écrit :

> 2013/4/18 Christian Quest 
>
>> http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00886460
>
>
> Ca, c'est la définition d'une "personne physique" (par opposition à une
> "personne morale")
>
>>
>> cette notion juridique s'éteint avec la proclamation du décès (d'après
>> WP):
>
>
> Vi. Là, on dit juste que la personne ne peut plus être trainée en justice
> ou jugée après son décès (ne riez pas, ça s'est vu par le passé). On parle
> de sa personnalité juridique propre. Ce qui ne dit rien sur le respect de
> sa vie privée, qui ne s'éteint pas avec le décès. Cela n'a rien à voir avec
> la constitution d'un fichier nominatif de personnes physiques, qui est lié
> au droit au respect de la vie privée et qui peut aussi concerner celle de
> la famille.
>
> En googlant un peu, je tombe par exemple sur:
> http://www.comparavie.fr/fiches-pratiques/contrat-non-reclame-agira.php
> "A partir du fichier des personnes physiques décédées depuis 1978,
> communiqué et mis à jour mensuellement par l'Insee, la Cnil a autorisé
> l'Agira a organiser une base de données relative aux personnes décédées"
>
> On peut aussi parler du fichier RNIPP de l'INSEE qui contient les
> informations de 97 millions de personnes physiques, vivantes ou mortes:
>
> http://www.cnil.fr/en-savoir-plus/fichiers-en-fiche/fichier/article/rnipp-repertoire-national-didentification-des-personnes-physiques/
>
> Pieren
>
> ___
> 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