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

[Plop76]

Philippe Verdy avait énoncé :
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 ?


Parce que si on garde le riverbank en chemin fermé, il y a une partie 
de riverbank qui coupe la Seine, pour faire la jonction avec les autres 
morceaux de la Seine.


En quoi tu veux lui appliquer une autre politique par rapport au bras plus 
court et plus direct qui passe au Sud ?


Je ne veux pas lui appliquer une autre politique :)




___
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 21 avril 2013 09:44, Plop76  a écrit :

> Philippe Verdy avait énoncé :
>
>  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 ?
>>
>
> Parce que si on garde le riverbank en chemin fermé, il y a une partie de
> riverbank qui coupe la Seine, pour faire la jonction avec les autres
> morceaux de la Seine.


Et alors ? Ce cas est très fréquent sur de nombreux fleuves possédant des
bras secondaires qui parfois forment des îles, même si le statut d'île ne
te semble pas évident ici, à cause de la taille.

La Seine dans ses méandres a beaucoup bougé dans son histoire (avec
d'anciens lits aujourd'hui complètement disparus, naturellement ou comblés
et occupés par l'homme). D'anciens lits principaux de la Seine sont aussi
considérés aujourd'hui comme des lits principaux des affluents.

Cela ne change pas les choses. Il y a des lits multiples, cela n'empêche
pas que ce soit des "riverbanks" quand même, même si ce n'est pas évident
de définir un sens d'écoulement

(d'autant plus que la relative proximité de la Manche donne aussi une
influence des marées avec des hauteurs et débits d'eau changeant 2 fois par
jour, même si on ne voit pas d'eau de mer arriver jusque là ce sont les
eaux de la Seine qui s'accumulent à marée haute, et se purgent à marée
basse, plus ou moins sensiblement selon le régime total de la Seine en
amont et l'importance des indices de marée en aval, et selon la régulation
des débits créée par les écluses et barrages et le réglage des seuils et
vannes sur les affluents du bassin versant et les canaux navigables qui
traversent le tout en passant d'un bassin à l'autre).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Pieren]

2013/4/20 Agnès Rambaud 

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

On est au niveau du micro-mapping, peu courant dans OSM (surtout que la
plupart des contributions sur le bâti vient d'images aériennes en dehors de
la France). Dans l'import cadastral, ce genre de structure devrait porter
les tags "building=yes" + "wall=no". On pourrait les remplacer par
"building=roof":
http://wiki.openstreetmap.org/wiki/Key:building
Mais ce tag concerne des structures entières alors que je ne sais pas si tu
parles juste d'un appendice (apparement oui d'après la question).

Pour des appendices non fermés et rattachés à un bâtiment plus grand, il
n'existe pas encore de consensus clair au niveau international. On pourrait
imaginer un "building=patio" ou "building=yes" + "patio=yes" ou
"building:part=patio" avec "covered=yes" (très peu d'exemples dans taginfo).

Attention à ne pas utiliser le faux-ami "building=terrace" qui désigne les
rangées de maisons comme on en voit dans certains quartiers ouvriers:
http://wiki.openstreetmap.org/wiki/File:Terraced_housing.png

Pieren
___
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]

Je doute que les marées de la Manche expliquent pourquoi ce label se balade
totalement hors de la zone...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Pieren]

2013/4/20 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
>
>
>
Comme le suggère TomH à la fin, tu devrais ouvrir ton propre ticket, dire
que ça se passe avec josm ou potlach avec des petits edits et expliquer que
le problème ne date pas des dernières 24h (durée maximale d'ouverture d'un
changeset).

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

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

[Plop76]

Philippe Verdy a exposé le 21/04/2013 :
Le 21 avril 2013 09:44, Plop76  a 
écrit :



Philippe Verdy avait énoncé :

 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 ?



Parce que si on garde le riverbank en chemin fermé, il y a une partie de
riverbank qui coupe la Seine, pour faire la jonction avec les autres
morceaux de la Seine.


Et alors ? 


Et alors un riverbank là où dans la réalité il n'y a que de l'eau, je 
trouve pas ça logique. Je vois que dans le wiki qu'il y a une nouvelle 
façon de tagguer le lit des rivières sans utiliser waterway=riverbank 
en tant que surface : j'applique :)



Ce cas est très fréquent sur de nombreux fleuves possédant des
bras secondaires qui parfois forment des îles, même si le statut d'île ne
te semble pas évident ici, à cause de la taille.


On ne doit pas parler de la même chose, car "le cas" dont je parle est 
systématique lorsqu'il s'agit d'une étendue d'eau non fermée. À un 
moment il y a un bout de riverbank dans l'eau.


Je parle du cas du chemin 4 ici : 
http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank#River_junctions


Ça arrive à la jonction de rivières ou à la jonction de morceaux de 
rivières.
J'ai rien contre mettre waterway=riverbank sur les chemins 3, 5, 6, 7 
et 8, mais vu que le wiki dit de se méfier de l'utilisation de 
waterway=riverbank comme chemin non fermé, je ne rajoute pas ce tag sur 
les berges (et de toute façon ça n'aurait rien changé au bug :))





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

Re: [OSM-talk-fr] Réf.: Re: Réf.: Re: Réf.: Re: Liens de et vers OSM...

[Ista Pouss]

Bonjour,

Quelqu'un (pas moi) peut-il faire un résumé de la situation ? Qu'est-ce qui
est acté ou pas ou en débat ? Et par exemple (à vrai dire en toute
sincérité ce qui m'intéresse) si ça vaut le coup que je présente ma
proposition sur la page wiki ou si elle a été rejetée pour cause de trop
vague, incompréhensible, implémentée trop vite et propriétaire ?

Merci à elle/lui.



Le 19 avril 2013 22:31, Emilie Laffray  a écrit :

> Le problème des geohash est un problème de précision et d'acceptation des
> limites du geohash. Car les geohash tels qu'ils existent actuellement sont
> extrêmement limités par le franchissement de la limite de précision.
> Autrement dit tu pourrais déplacer un point d'un mètre avec un geohash
> d'une précision de 1km et passer à quelque chose de complètement différent.
> Les geohash tels qu'ils existent actuellement ne sont pas vraiment utiles
> à mes yeux. Ils peuvent être utiles dans certains cas mais c'est limité par
> l'incapacité de créer un 'gradient' utile.
> Je trouve l'approche que tu proposes comme un bon début mais extrêmement
> limité. L'approche uuid mentionnée par Pieren et auquel j'ai participé
> était intéressante mais limitée sur d'autres points notamment les éditeurs.
> Tony a de bons points sur le fait qu'il faudrait savoir quel paramètres
> qualifier ce futur osmhash (dibs sur le trademark :) ).
> Je l'ai évoqué initialement sur le déplacement d'une entreprise et
> certains ont évoqués le changement de propriétaire. Un osmhash doit tenir
> compte de ça.
> Commençons par qualifier l'unicité d'un poi et penser à une composante
> geospatiale plus flou.
> L'intervention de Gael montre bien l'intérêt commercial d'un tel système
> ainsi que l'intérêt de Tony. Moi même à mapquest j'ai travaillé sur cette
> problématique afin de travailler sur la réconciliation de plusieurs sources
> (voir le commentaire de Marc sur le sujet et son expérience).
> Je ne dis pas que c'est impossible au contraire même mais sans poser
> certaines bases d'accord et des use cases on va tourner en rond. La
> communauté a les moyens d'être créative mais structurons un peu le propos
> pour gagner en clarté et voir les solutions non orthodoxes gagnées car les
> bases auront été jetées
> D'un point de vue commercial si un tel système se mettait en place ça
> aurait une très grosse valeur.
>
> Émilie laffray
> On 17 Apr 2013 18:07, "Christian Quest"  wrote:
>
>> #a4u2k9 dans mon exemple est un geohash... il correspond à une bbox
>> qui est de plus en plus petite lorsque le geohash est long (et
>> inversement). C'est un truc existant qui est même supporté en interne
>> par postgis (ST_GeoHash).
>> Pour ceux qui ne connaissent pas voir:
>> http://fr.wikipedia.org/wiki/Geohash
>>
>> En y repensant avec un ID comme  Croustillette.bakery.shop@#a4u2k9
>> permet de facilement faire du matching partiel... bakery.shop@#a4u2k
>> une boulangerie dans une zone un peu plus grande, shop@#a4u2
>> correspond juste à une boutique dans une zone encore plus grande,
>> etc... et une simple recherche textuelle en "contient" fait l'affaire
>> ;)
>>
>> On peut aussi déterminer le niveau de similitude entre 2 ID assez
>> facilement (longueur de la partie commune gauche, droite ou combinée).
>> Tout ça se calcule facile sans faire appel à des API car le principe
>> est universel et pas spécifiquement liée à OSM.
>>
>> --
>> 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
>
>


-- 
Les dérives de rue :
Profession émotion 
___
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]

Je suis moi-même "daltonien" comme on dit, le terme plus exact étant
"deutéranope mineur"? Ce cas n'est pas exceptionnel puisque les différences
de vision des couleurs touchent 10 à 15% des hommes (plus d'ailleurs chez
les "Caucasiens" autrement dit les personnes d'origine européenne, et plus
les hommes que les femmes).

Contrairement à ce qui est écrit un peu partout, le "daltonisme" ne crée
que très rarement une vision bichromatique, et on conserve une palete de
vision trichromatique différente du modèle chromatique "standard" qui n'est
qu'une moyenne. La plupart du temps il n'y a pas absence d'un type de
pigment chromatique mais seulement des déficits et surplus de certains
types de pigments dans certains types de cônes ou battonets de a rétine,
avec des taux de concentration surfacique différents.

Bien des tests de daltonismes (les images de points colorés faisant
apparaître ou pas des chiffres) donnent des résultats faux si on les
interprète isolément.

Tout à pour dire que malgré mon "handicap" (qui n'en est pas un puisqu'en
revanche je dispose d'une différenciation chromatique plus importante pour
d'autres couleurs), la différence de rendu est tout de même bien visible
sur la carte notamment grâce à:
 - des différences de tonalité dans les couleurs de remplissage
 - des différences de contraste par le choix de la luminosité
 - une différenciation accentuée par le tracé de fins liserés plus sombres
de part et d'autre du trait

Là où c'est moins évident c'est quand les traits sont moins épais de sorte
qu'on ne voit plus les liserés (moins d'1 pixel, ils se fondent dans le
trait central en réduisant la différence de contraste. Malgré tout la
couleur principal du trait forme un contraste suffisant par rapport aux
forêts et vignes alentours. Certes il est difficile de savoir quelle est la
couleur du trait, mais on voit qu'il contraste avec le fond dont on
reconnait bien la couleur.

Plus un tracé est fin, moins on perçoit les différences de couleur et plus
on perçoit les différences de contraste. Cela veut dire que les fins
détails ne devraient utiliser que des couleurs très sombres ou noirs sur un
fond de couleur claire, ou très claires sur un fond sombre.

Un autre phénomène est que la différenciation des couleurs à luminosité
égale est plus accentuée entre deux couleurs claires qu'entre deux couleurs
sombres :

 - Cela voudrait dire que les fins détails où la couleur revêt une
importance, cas des routes, devraient être tracés en couleurs très claires,
nettement plus claires que les aplats de couleur des terres (comme le fait
Google Maps).

 - Là où la couleur a moins d'importance, cas des libellés, on prend le
choix inverse et on les trace en couleur sombre sur les fonds moyens comme
sur les tracés clairs des traits des routes, ce qui accentue leur
lisibilité. Si la couleur des fonds n'est pas assez différencié en
contraste avec celle du texte, on améliore la lisibilité du texte en
l'affichant dans un "halo" semi-transparent plus clair (qui n'a pas besoin
d'être lui-même plus important en épaisseur que la taille des détails des
caractères, sinon ce halo risque de masquer trop de chose de l'arrière-plan
: pour une taille de police de 9 à 12 points, un halo clair de 1 point
suffit à rendre ce texte sombre très lisible).

Si on respecte cette différenciation des contrastes par les méthodes de
tracés améliorées (y compris par l'utilisation de techniques
d'anticrénelage dans un modèle colorimétrique RGBA et non RGB seulement --
même sans utiliser le suréchantillonnage énormément plus coûteux en calcul
et espace mémoire, le passage de RGB à RGBA ne coûtant que 33% de plus en
espace et environ 50% de plus en complexité de calcul, contre 300% de plus
à la fois en espace et en calcul pour un simple suréchantillonnage 2x2 qui
ne parvient pourtant pas à des résultats aussi excellent !), on peut
ensuite ajuster plus finement les palettes de couleur pour les aplats de
fond. La tonalité des couleurs joue alors bien un rôle secondaire loin
derrière une bonne gestion des contrastes sur ce qui est important de
montrer dans une carte.


Le 20 avril 2013 18:07, Pierre-Alain Dorange  a écrit :

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

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

[PhQ]

Pour Aydat, c'est fait ! S'il reste des trous identifiés 



--
View this message in context: 
http://gis.19327.n5.nabble.com/http-cadastre-openstreetmap-fr-tp5757271p5757906.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] Source d'un label

[Philippe Verdy]

Oui mais ce n'est pas le propos de ma réponse. (la cause était qu'un
morceau de surface couverte d'eau n'était pas tracé, mais cela n'indique
pas comment taguer ce morceau de surface couverte d'eau et pourquoi on doit
ou pas le différencier).


Le 21 avril 2013 10:35, Christian Quest  a écrit :

> Je doute que les marées de la Manche expliquent pourquoi ce label se
> balade totalement hors de la zone...
> ___
> 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] Source d'un label

[Philippe Verdy]

Le 21 avril 2013 10:37, Plop76  a écrit :

> Ce cas est très fréquent sur de nombreux fleuves possédant des
>> bras secondaires qui parfois forment des îles, même si le statut d'île ne
>> te semble pas évident ici, à cause de la taille.
>>
>
> On ne doit pas parler de la même chose, car "le cas" dont je parle est
> systématique lorsqu'il s'agit d'une étendue d'eau non fermée. À un moment
> il y a un bout de riverbank dans l'eau.


Une "étendue" d'eau non fermée ça n'existe pas !

Même si pour le fermer il faut ajouter un segment virtuel (qui n'est pas
une "rive" en français, car les "riverbank" ne désignent pas les "rives"
mais seulement les limites d'une étendue d'eau, certaines étant des rives
et d'autre non), et même si ce segment virtuel sera repris dans la
définition d'une autre étendue d'eau mitoyenne pour la fermer elle aussi.


> Je parle du cas du chemin 4 ici : http://wiki.openstreetmap.org/**
> wiki/Tag:waterway%3Driverbank#**River_junctions
>
> Ça arrive à la jonction de rivières ou à la jonction de morceaux de
> rivières.
> J'ai rien contre mettre waterway=riverbank sur les chemins 3, 5, 6, 7 et
> 8, mais vu que le wiki dit de se méfier de l'utilisation de
> waterway=riverbank comme chemin non fermé, je ne rajoute pas ce tag sur les
> berges (et de toute façon ça n'aurait rien changé au bug :))


Effectivement mais cela ne change rien au fait que les "riverbank" dans la
base OSM ne désignent des "rives" (définition normale du mot français) et
qu'on ne doit les utiliser QUE pour désigner des surfaces fermées, donc:
- soit un chemin fermé tagué en "riverbank",
- soit une relation multipolygone dont les chemins membres ne DOIVENT PAS
eux-mêmes être des "riverbank"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Plop76]

Philippe Verdy a exposé le 21/04/2013 :

la cause était qu'un morceau de surface couverte d'eau n'était pas tracé


C'est pas ce que j'ai compris... Quel morceau ?




___
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 21 avril 2013 11:44, Plop76  a écrit :

> Philippe Verdy a exposé le 21/04/2013 :
>
>> la cause était qu'un morceau de surface couverte d'eau n'était pas tracé
>>
>
> C'est pas ce que j'ai compris... Quel morceau ?
>

Le morceau de "surface" qui était tagué en "natural=water"+"water=*" (ce
qui est totalement équivalent à un tag "natural=riverbank", le changement
de tag ne changeant strictement rien au problème et n'apportant strictement
aucune amélioration), et qui en plus ne formait pas un polygone ou
multipolygone fermé, ce qui ne permet effectivement pas de remplir la
surface en bleu.

Note qu'on a les même cas aux embouchures : la surface étendue d'eau
(douce) devient mitoyenne de la surface étendue d'eau de mer : là encore ce
n'est pas évident mais il existe bien un "multipolygone" pour la mer, même
si on ne définit pas de relation pour elle, mais qu'on se contente de
joindre les traits de "coastline" qui doivent avoir une orientation précise
(pour ne pas avoir à chercher le côté interne ou externe en parcourant tous
les chemins sur une bonne partie de la planète).

Le dernier (multi)polygone "natural=riverbank" (ou
"natural=water"+"water=*" ce qui ne change rien) de l'embouchure doit lui
aussi se fermer mais en utilisant un trait tagué en "coastline" alors que
ce trait n'est pas non plus une vraie ligne de côte !

Pour savoir si in a une vraie rive, il faut regarder quel type de polygone
il y a de l'autre côté du trait de délimitation, vers l'extérieur du
polygone. Ce n'est alors ni une rive ni une ligne de côte si de l'autre
côté on a un autre "natural=riverbank" (ou "natural=water"+"water=*"), ou
si on a de la mer (trait avec natural=coastline orienté dans le bon sens).

Mais pour le tagging dans OSM cela ne change rien : ce qu'on tague
réellement ce sont les surfaces qu'on DOIT fermer d'une façon ou d'une
autre.
___
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]

Ce qui n'a plus rien à voir avec la question d'origine de ce fil de
discussion...


Le 21 avril 2013 11:26, Philippe Verdy  a écrit :

> Oui mais ce n'est pas le propos de ma réponse. (la cause était qu'un
> morceau de surface couverte d'eau n'était pas tracé, mais cela n'indique
> pas comment taguer ce morceau de surface couverte d'eau et pourquoi on doit
> ou pas le différencier).
>
>
> Le 21 avril 2013 10:35, Christian Quest  a écrit
> :
>
>> Je doute que les marées de la Manche expliquent pourquoi ce label se
>> balade totalement hors de la zone...
>>
>

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

[Plop76]

Philippe Verdy avait énoncé :
Le 21 avril 2013 11:44, Plop76  a 
écrit :



Philippe Verdy a exposé le 21/04/2013 :


la cause était qu'un morceau de surface couverte d'eau n'était pas tracé



C'est pas ce que j'ai compris... Quel morceau ?



Le morceau de "surface" qui était tagué en "natural=water"+"water=*" (ce
qui est totalement équivalent à un tag "natural=riverbank", le changement
de tag ne changeant strictement rien au problème et n'apportant strictement
aucune amélioration), et qui en plus ne formait pas un polygone ou
multipolygone fermé, ce qui ne permet effectivement pas de remplir la
surface en bleu.


http://www.openstreetmap.org/browse/relation/13820 ? Elle est fermée.




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

Je ne suis pas convaincu que c'était cette relation. Vu la position du
libellé qui est bien plus au nord, je pense qu'il y a un autre objet (non
fermé lui donc invisible) dont le libellé apparaît là (position d'un
centroïde calculé très probablement). Cet objet ne semble pas avoir été
identifié.

La discussion a démarré avant moi en disant que c'était cet objet
uniquement parce qu'il utilisait un tagging comme "natural=water"+"water=*"
au lieu de "natural=riverbank", ce changement malgré tout n'est pas la
cause du problème et n'apportant rien de plus par lui-même en terme de
rendu attendu. Mais cet objet est trop loin de la position qui a été
mentionnée au début.

D'ailleurs je cherche toujours à voir où le libellé "La Seine" apparaît au
milieu de nulle part, car pour l'instant je ne l'ai pas vu ! S'il n'est
plus là, c'est qu'une correction a été faite (probablement sur un riverbank
non fermé d'un affluent)

Le 21 avril 2013 12:05, Plop76  a écrit :

> Le morceau de "surface" qui était tagué en "natural=water"+"water=*" (ce
>> qui est totalement équivalent à un tag "natural=riverbank", le changement
>> de tag ne changeant strictement rien au problème et n'apportant
>> strictement
>> aucune amélioration), et qui en plus ne formait pas un polygone ou
>> multipolygone fermé, ce qui ne permet effectivement pas de remplir la
>> surface en bleu.
>>
>
> http://www.openstreetmap.org/**browse/relation/13820?
>  Elle est fermée.
>
>
>
>
>
> __**_
> 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] Source d'un label

[Philippe Verdy]

Le 21 avril 2013 12:22, Philippe Verdy  a écrit :

> D'ailleurs je cherche toujours à voir où le libellé "La Seine" apparaît au
> milieu de nulle part, car pour l'instant je ne l'ai pas vu ! S'il n'est
> plus là, c'est qu'une correction a été faite (probablement sur un riverbank
> non fermé d'un affluent)
>

Autre cause possible : un segment de la Seine qui a été au début dupliqué
par erreur sans que son auteur s'en aperçoive tout de suite (utilisation
dans JOSM de CTRL+D au lieu de CTRL+ALT+D par exemple pour charger les
relations dépendantes d'un chemin sélectionné), mais qui a depuis été
supprimé.
___
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]

C'est sûr que passer autant de temps à écrire n'en laisse pas beaucoup pour
lire...

Le voici le label étrange:
http://www.openstreetmap.org/?mlat=49.4737&mlon=1.131&zoom=15&layers=M

Et tu peux douter qu'il provienne de la relation 13820 mais c'est un fait
établi, vérifié... besoin d'une copie d'écran du rendu où l'id OSM remplace
le name=* qui m'a servi à retrouver l'objet fautif ?

Quelle étonnante capacité à écrire en avançant autant d'hypothèses sans
rien vérifier.

Il y a 2 bugs dans le rendu:
- un bug dans la feuille de style OSM qui ne prend pas en compte les
natural=water+ water=* qui du coup font apparaitre des labels indésirables,
- un bug Mapnik sur le calcul de la position où placer le label dans le cas
de multipolygones biscornus comme celui-là.

En attendant la marée suivante...
-- 
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] http://cadastre.openstreetmap.fr/

[Jean-Baptiste Holcroft]

Il y a des endroits particuliers à faire pour aider ?
Ou alors c'est pour le plaisir d'indiquer les villes importées ? ;)
--
Jean-Baptiste Holcroft


2013/4/21 PhQ 

> Pour Aydat, c'est fait ! S'il reste des trous identifiés 
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/http-cadastre-openstreetmap-fr-tp5757271p5757906.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

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

[Pierre-Alain Dorange]

Philippe Verdy  wrote:

> Je suis moi-même "daltonien" comme on dit, le terme plus exact étant
> "deutéranope mineur" [...]

Je précise que ma remarque sur le "daltonisme" était une boutade, tout
ce que tu écris est fort intéressant mais sans rapport aucun avec le
sujet du forum, je zappe donc cette introduction...

> [...] Malgré tout la
> couleur principal du trait forme un contraste suffisant par rapport aux
> forêts et vignes alentours. Certes il est difficile de savoir quelle est la
> couleur du trait, mais on voit qu'il contraste avec le fond dont on
> reconnait bien la couleur.

OK, je suis donc bien pas normal car sur l'exemple ci-dessous je vois
par émerger "naturellement" et "facilement" la structure du réseau
routier qui forme un anneau au sud de la ville. Pour moi le vert du
trunk est tellement peu évident que je ne vois plus que (du premier
abord) que l'axe nord-sud.



Là par exemple : 
Je trouve pas du tout assez visible la N10 qui traverse du nord-est au
sud-ouest que les axes secondaires (D731, D674)

J'en conclus que je dois donc être une exception.

Désolé de tout ce bruit pour rien.

-- 
Pierre-Alain Dorange
OSM experiences : 


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

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

[Francescu GAROBY]

Je rejoins Pierre-Alain, tout particulièrement avec son dernier exemple :
les routes vertes ressortent beaucoup moins bien que les autres !
Même les oranges ressortent mieux, alors qu'elles sont moins importantes...

Francescu


Le 21 avril 2013 13:34, Pierre-Alain Dorange  a écrit :

> Philippe Verdy  wrote:
>
> > Je suis moi-même "daltonien" comme on dit, le terme plus exact étant
> > "deutéranope mineur" [...]
>
> Je précise que ma remarque sur le "daltonisme" était une boutade, tout
> ce que tu écris est fort intéressant mais sans rapport aucun avec le
> sujet du forum, je zappe donc cette introduction...
>
> > [...] Malgré tout la
> > couleur principal du trait forme un contraste suffisant par rapport aux
> > forêts et vignes alentours. Certes il est difficile de savoir quelle est
> la
> > couleur du trait, mais on voit qu'il contraste avec le fond dont on
> > reconnait bien la couleur.
>
> OK, je suis donc bien pas normal car sur l'exemple ci-dessous je vois
> par émerger "naturellement" et "facilement" la structure du réseau
> routier qui forme un anneau au sud de la ville. Pour moi le vert du
> trunk est tellement peu évident que je ne vois plus que (du premier
> abord) que l'axe nord-sud.
>
> 
>
> Là par exemple : 
> Je trouve pas du tout assez visible la N10 qui traverse du nord-est au
> sud-ouest que les axes secondaires (D731, D674)
>
> J'en conclus que je dois donc être une exception.
>
> Désolé de tout ce bruit pour rien.
>
> --
> Pierre-Alain Dorange
> OSM experiences : 
>
>
> ___
> 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] Source d'un label

[Philippe Verdy]

J'avais parfaitement lu mais je ne le voyais **pas du tout** à cet endroit.
Merci de montrer qu'il est bien encore là.

Quelle étonnante capacité à chercher la polémique sans d'abord expliquer ce
qui n'était pas clair.


Le 21 avril 2013 12:36, Christian Quest  a écrit :

> C'est sûr que passer autant de temps à écrire n'en laisse pas beaucoup
> pour lire...
>
> Le voici le label étrange:
> http://www.openstreetmap.org/?mlat=49.4737&mlon=1.131&zoom=15&layers=M
>
> Et tu peux douter qu'il provienne de la relation 13820 mais c'est un fait
> établi, vérifié... besoin d'une copie d'écran du rendu où l'id OSM remplace
> le name=* qui m'a servi à retrouver l'objet fautif ?
>
> Quelle étonnante capacité à écrire en avançant autant d'hypothèses sans
> rien vérifier.
>
> Il y a 2 bugs dans le rendu:
> - un bug dans la feuille de style OSM qui ne prend pas en compte les
> natural=water+ water=* qui du coup font apparaitre des labels indésirables,
> - un bug Mapnik sur le calcul de la position où placer le label dans le
> cas de multipolygones biscornus comme celui-là.
>
> En attendant la marée suivante...
> --
> 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] Source d'un label

[Philippe Verdy]

Et je sais pourquoi je ne le voyais pas, me^me en vérifiant: le label
n'apparait qu'à un seul niveau de zoom et il m'a fallu raffraichir le tuile
pour le voir, en vidant d'abord le cache de mon navigateur. Le label
n'apparait pas quand on zoom plus avant.
Alors je veux bien qu'il y ait un ou deux bogues mais il va falloir se
demander pourquoi cela affecte ce niveau de zoom précisément, et pas plus
avant car la position géographique calculée (avant projection dans les
coordonnées en pixels de la tuile) est normalement la même.

Aussi un niveau de zoom arrière, on voit le label mais dans une style
différent, qui n'est plus celui d'une rivière ou d'un fleuve mais celui
d'un lieu-dit. C'est ce qui me convint encore qu'il y a une autre anomalie
dans les tags ou dans leur traitement, que tu n'as pas vu.

Celle sur les natural=water+water=* au lieu de natural=riverbank n'a rien à
voir puisque les deux sont déjà rendus de façon identifique (au moins aux
niveaux de zoom élevés). L'anomalie semble spécifique de ces 2 niveaux de
zoom qui ont des styles appliqués différents et des méthodes de rendu
différentes pour les libellés.

De toute façon c'est sur le rendu des libellés (leur sélection, leur
positionnement optimal, leur dimensionnement, les styles de polices ou
d'interlettrage, leur graisse et leur transparence pour ceux apparaissant
en très gros, voire aussi le placement non nécessairement horizontal mais
sur des diagonales ou courbes) qu'OSM, dans ses rendus Mapnik ou autres,
doit faire encore beaucoup de progrès pour approcher un peu ce que savent
faire à la perfection Michelin ou l'IGN ou les instituts cartographiques
nationaux qui affinent les cartes patiemment à la main depuis des
décennies, ou même (moins bien mais toujours mieux qu'OSM) Google Map et
Bing Map. Souvent aussi MapQuest (et maintenant aussi uMap) fait mieux
qu'OSM avec son rendu Mapnik sur ce point, à partir pourtant des mêmes
données de base OSM.

Michelin vient aussi de démontrer aussi qu'il savait le faire avec des
données OSM; bref la compétence et le savoir-faire carto**graphique**, issu
de longues traditions et du travail réalisé par des humains (qu'on peut
qualifier d'artistes tellement les cartes obtenues sont "belles" tout en
restant précises à leur échelle) et pas seulement par des heuristiques
programmées encore balbutiantes, n'est pas du tout la même que la
compétence et le savoir-faire en terme de collecte, de codification, de
classement, de vérification et de mise à jour des données ; elle ne dépend
pas non plus du soin apporté par ceux qui passent du temps à patiemment
travailler le contenu de la base de données avec les outils d'édition ;
comme dans OSM on dit qu'on ne "tague pas pour le rendu", la tâche restant
à faire derrière est immense.

Un progrès significatif a été fait pour les libellés le long des frontières
en les plaçant du bon côté et non par dessus. Mais pas pour les libellés
des noeuds. Et pas plus dans la sélection des libellés à garder contre
d'autres à masquer (notamment les noms de villes, villages et lieux-dits).
L'essai en cours pour les libellés des noms de rue demande à être affiné,
c'est parfois trop ambigu.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[didier2020]

Le dimanche 21 avril 2013 à 13:05 +0200, Jean-Baptiste Holcroft a
écrit :
> Il y a des endroits particuliers à faire pour aider ?
peut etre les villes qui sont partiellement importées ? ou pas ? 
( comme nimes ou pessac de souvenir d'un post recent)
> Ou alors c'est pour le plaisir d'indiquer les villes importées ? ;)
L 1 n'empeche pas l'autre ;)

didier 
> --
> Jean-Baptiste Holcroft
> 
> 
> 2013/4/21 PhQ 
> Pour Aydat, c'est fait ! S'il reste des trous identifiés 
> 
> 
> 
> --
> View this message in context:
> 
> http://gis.19327.n5.nabble.com/http-cadastre-openstreetmap-fr-tp5757271p5757906.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

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

[djo_man]

  
  
bonjour, 

personnellement, j'ai toujours trouvé que c'était le plus gros
défaut du rendu mapnik
+1 donc

un bleu/vert ? (vert canard foncé)

djo_man


Le 21/04/2013 13:44, Francescu GAROBY a
  écrit :


  

  Je rejoins Pierre-Alain, tout particulièrement avec son
dernier exemple : les routes vertes ressortent beaucoup
moins bien que les autres !
  
  Même les oranges ressortent mieux, alors qu'elles sont moins
  importantes...
  

Francescu
  
  

Le 21 avril 2013 13:34, Pierre-Alain
  Dorange 
  a écrit :
  
Philippe Verdy 
  wrote:
  
  > Je suis moi-même "daltonien" comme on dit, le terme
  plus exact étant

> "deutéranope mineur" [...]

Je précise que ma remarque sur le "daltonisme" était une
boutade, tout
ce que tu écris est fort intéressant mais sans rapport aucun
avec le
sujet du forum, je zappe donc cette introduction...

> [...] Malgré tout la
> couleur principal du trait forme un
  contraste suffisant par rapport aux
  > forêts et vignes alentours. Certes il est difficile
  de savoir quelle est la
  > couleur du trait, mais on voit qu'il contraste avec
  le fond dont on
  > reconnait bien la couleur.
  

OK, je suis donc bien pas normal car sur l'exemple
ci-dessous je vois
par émerger "naturellement" et "facilement" la structure du
réseau
routier qui forme un anneau au sud de la ville. Pour moi le
vert du
trunk est tellement peu évident que je ne vois plus que (du
premier
abord) que l'axe nord-sud.



Là par exemple : 
Je trouve pas du tout assez visible la N10 qui traverse du
nord-est au
sud-ouest que les axes secondaires (D731, D674)

J'en conclus que je dois donc être une exception.

Désolé de tout ce bruit pour rien.

  
--
Pierre-Alain Dorange
OSM experiences : 


___
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] Rendu OSM-FR : couleurs highway

[Philippe Verdy]

Le 21 avril 2013 13:34, Pierre-Alain Dorange  a écrit :

> Philippe Verdy  wrote:
>
> > Je suis moi-même "daltonien" comme on dit, le terme plus exact étant
> > "deutéranope mineur" [...]
>
> Je précise que ma remarque sur le "daltonisme" était une boutade, tout
> ce que tu écris est fort intéressant mais sans rapport aucun avec le
> sujet du forum, je zappe donc cette introduction...
>

Elle est totalement en rapport avec ton sujet qui est le choix des couleurs
dans un rendu, lequel est TRES dépendant de la perception humaine des
couleurs, beaucoup plus compliquée que ce qu'on croit. Le "daltonisme" trop
souvent mal compris est pourtant très courant mais il ne se réduit pas aux
descriptions faites dans Wikipédia ou même dans de soit-disant tests
"scientifiques" qui donnent de faux résultats (si je prend l'article de
Wikipédia qui donne des exemples de planches avec les points de couleur,
ils sont TOUS faux dans leurs conclusion, même sur les planches d'origine.
De même que les prétendus rendus de simulation de ce que perçoivent les
"daltoniens" à partir d'une photo transformée.

Il n'y a qu'une seule planche qui soit correcte dans l'article Wikipédia.
Tout bonnement parce que les algorithmes de simulation pour tenter de
reproduire les couleurs sur ordinateur sont carrément... complètement faux
et ignorent aussi les bases de la colorimétrie ou les profils de
calibration, et que nos écrans (ou ceux utilisés par les auteurs de ces
"simulations") sont, pour la plupart, non calibrés.

(Et moi même je suis loin de tout savoir ou comprendre sur le sujet,
n'étant pas affecté par toutes ses diverses formes, même si j'en ai la
forme la plus commune. Ce qui n'est pas un handicap du tout mais me donne
une vision juste originale un peu différente, me permettant de voir
aussi des nuances bien réelles, confirmées par des tests, là où beaucoup
d'autres n'en voient aucune, notamment dans les noirs et d'une façon
générale en vision nocturne ou je perçois de mes yeux certains infrarouges
et les champs électriques assez forts)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Agnès Rambaud]

Le 21/04/2013 10:31, Pieren a écrit :
2013/4/20 Agnès Rambaud >


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.


On est au niveau du micro-mapping, peu courant dans OSM (surtout que 
la plupart des contributions sur le bâti vient d'images aériennes en 
dehors de la France). Dans l'import cadastral, ce genre de structure 
devrait porter les tags "building=yes" + "wall=no". On pourrait les 
remplacer par "building=roof":

http://wiki.openstreetmap.org/wiki/Key:building
Mais ce tag concerne des structures entières alors que je ne sais pas 
si tu parles juste d'un appendice (apparement oui d'après la question).
building=roof c'est pour les toits sans murs, donc une structure 
ouverte. Ce n'est pas le cas ici : typiquement, un garage d'habitation 
(qui lui est bien fermé), attenant au bâtiment, et dont le toit plat 
fait office de terrasse pour l'appartement à l'étage. Ou encore, un toit 
d'immeuble (donc avec appartement dessous) qui est plat et est utilisé 
comme terrasse. Le building=roof ne convient pas du tout.


Par contre j'ai trouvé 
roof:shape=flat ici : 
http://wiki.openstreetmap.org/wiki/Simple_3D_Buildingspour caractériser 
le type de toit.
D'après mon dico, on peut l'utiliser pour "un toit en terrasse". Mais 
est-ce le sens indiqué dans ce cas ? (ou plutôt le fait que ce soit plat ?)


Pour des appendices non fermés et rattachés à un bâtiment plus grand, 
il n'existe pas encore de consensus clair au niveau international. On 
pourrait imaginer un "building=patio" ou "building=yes" + "patio=yes" 
ou "building:part=patio" avec "covered=yes" (très peu d'exemples dans 
taginfo).


Attention à ne pas utiliser le faux-ami "building=terrace" qui désigne 
les rangées de maisons comme on en voit dans certains quartiers ouvriers:

http://wiki.openstreetmap.org/wiki/File:Terraced_housing.png

Ok, et il est bien explicité dans le wiki.


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

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

[Christian Quest]

Le 21 avril 2013 15:03, Philippe Verdy  a écrit :

> Et je sais pourquoi je ne le voyais pas, me^me en vérifiant: le label
> n'apparait qu'à un seul niveau de zoom et il m'a fallu raffraichir le tuile
> pour le voir, en vidant d'abord le cache de mon navigateur. Le label
> n'apparait pas quand on zoom plus avant.
> Alors je veux bien qu'il y ait un ou deux bogues mais il va falloir se
> demander pourquoi cela affecte ce niveau de zoom précisément, et pas plus
> avant car la position géographique calculée (avant projection dans les
> coordonnées en pixels de la tuile) est normalement la même.
>
>

Ce qui rentre en ligne de compte pour que cela affecte ou non un niveau de
zoom donné :

- la taille des metatuiles (8x8 tuiles, soit 2048x2048 pixels): est-ce que
l'objet intersecte ou pas cette metatuile, donc aux zooms supérieurs à 15
le polygone n'intersecte plus la bbox de la metatuile et donc le label
n'est plus là.

- la feuille de style et ses règles de rendu.. et là il suffit d'aller lui
rendre visite sur
https://trac.openstreetmap.org/browser/subversion/applications/rendering/mapnik/osm.xml


Que trouve-t-on ligne 4036 ? "and (waterway is null or waterway !=
'riverbank')" un test spécifique sur riverbank... pour éviter de dessiner
un label pour les riverbank, mais ce test ne tient pas compte des
natural=water + water=river qui sont un équivalent récent de
waterway=riverbank (voir le wiki:
http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank "new tagging").

C'est l'origine de l'apparition du label en zoom 14 sur le layer
"area-text"... qui en plus dépend de la taille du polygone et du niveau de
zoom (voir lignes 212-227)... sans oublier l'ordre de placement des textes
car si la place est déjà prise, le label n'est pas rendu. Voilà pourqu'oi
il n'apparait pas à tout plus de niveaux de zoom.

Ensuite zoom 15... là c'est le layer "text avec sa règle de rendu en bleu,
taille 10 qui est ligne 350... et qui s'appuie sur la requête postgis qui
est en ligne 4019 qui cherche entre autre des natural is not null...

zoom 16 et suivant on est hors de la metatuile...


C'est bon, assez détaillé comme explication du fonctionnement de la feuille
de style XML ? C'est vrai que c'est pas super facile à comprendre.

Il y a bien un problème avec la feuille de style OSM qui ne prend pas bien
en compte les natural=water + water=river, mais uniquement les
waterway=riverbank... qu'il est donc préférable de laisser en "doublon"
(mais ça n'éliminera qu'un des deux labels indésirables, celui du zoom 14).


Ca c'est pour le bug de la feuille de style OSM (et OSM-FR jusqu'à ce que
j'en corrige une partie, je vais faire la deuxième maintenant).

Le deuxième bug, je n'ai pas réussit à le cerner... c'est dans Mapnik que
ça se passe et que le centroid calculé par mapnik pour le multipolygone
retourné par postgis est complètement farfelu et que du coup ce label
apparait très loin du multipolygone dont il est issu.



> Aussi un niveau de zoom arrière, on voit le label mais dans une style
> différent, qui n'est plus celui d'une rivière ou d'un fleuve mais celui
> d'un lieu-dit. C'est ce qui me convint encore qu'il y a une autre anomalie
> dans les tags ou dans leur traitement, que tu n'as pas vu.
>
>
C'est le layer "area-text" ligne 214 + 4036 pour le zoom 14. Je l'ai bien
vu, merci.



> Celle sur les natural=water+water=* au lieu de natural=riverbank n'a rien
> à voir puisque les deux sont déjà rendus de façon identifique (au moins aux
> niveaux de zoom élevés). L'anomalie semble spécifique de ces 2 niveaux de
> zoom qui ont des styles appliqués différents et des méthodes de rendu
> différentes pour les libellés.
>
>
Rien compris.



> De toute façon c'est sur le rendu des libellés (leur sélection, leur
> positionnement optimal, leur dimensionnement, les styles de polices ou
> d'interlettrage, leur graisse et leur transparence pour ceux apparaissant
> en très gros, voire aussi le placement non nécessairement horizontal mais
> sur des diagonales ou courbes) qu'OSM, dans ses rendus Mapnik ou autres,
> doit faire encore beaucoup de progrès pour approcher un peu ce que savent
> faire à la perfection Michelin ou l'IGN ou les instituts cartographiques
> nationaux qui affinent les cartes patiemment à la main depuis des
> décennies, ou même (moins bien mais toujours mieux qu'OSM) Google Map et
> Bing Map. Souvent aussi MapQuest (et maintenant aussi uMap) fait mieux
> qu'OSM avec son rendu Mapnik sur ce point, à partir pourtant des mêmes
> données de base OSM.
>
>
Oh ? uMap a sont propre rendu maintenant ? Tu as un lien pour qu'on puisse
le voir ?

Tout ce travail c'est la "généralisation cartographique"... comment partant
d'une masse de données détaillées sélectionner les objets les plus utiles
et faire le choix graphique approprié pour une carte dense en info mais
lisible...



> Michelin vient aussi de démontrer aussi qu'il savait le faire avec des
> données OSM; bref la compétence et le savoir-faire carto**graphique**, issu
> de longu

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

[Vincent Privat]

Le 21 avril 2013 15:21, Philippe Verdy  a écrit :

> Ce qui n'est pas un handicap du tout mais me donne une vision juste
> originale un peu différente, me permettant de voir aussi des nuances bien
> réelles, confirmées par des tests, là où beaucoup d'autres n'en voient
> aucune, notamment dans les noirs et d'une façon générale en vision nocturne
> ou je perçois de mes yeux certains infrarouges et les champs électriques
> assez forts)
>
> C'est donc pour ça que tu vois tant de choses que le commun des mappeurs
ne voit pas. Tout s'explique.

Pour recentrer un peu le sujet, je suis d'accord avec Pierre-Alain, ce vert
terne n'est vraiment pas très lisible. Une autre couleur ou une teinte plus
"flashy" serait la bienvenue.
___
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]

Philippe Verdy  wrote:

> [...]
> Elle est totalement en rapport avec ton sujet [...]

Excuse moi mais non.
Je répète, ma remarque "daltonisme" était une boutade (une blague), en
aucun un sujet de discussion... Aussi intéressant soit-il.

>  [...]
> Il n'y a qu'une seule planche qui soit correcte dans l'article Wikipédia.

!?

-- 
Pierre-Alain Dorange
OSM experiences : 


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

[OSM-talk-fr] Cadastre dans l'Yonne

[Tony Emery]

Boujour à tous,

J'aimerais savoir où en est la communauté de l'import du cadastre dans
l'Yonne.

Il reste des communes pour lesquelles le bâti n'a pas été importer et
j'aimerais pouvoir contribuer dans le coin, notamment vers Vaudeurs.

Vu que je ne maîtrise pas le plug-in d'import, je préfère m'en remettre aux
spécialistes.

Merci de me tenir au courant dès que vous avez des nouvelles.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Cadastre-dans-l-Yonne-tp5757967.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] Cadastre dans l'Yonne

[Christian Quest]

Il y a relativement peu de communes avec un cadastre vectoriel dans l'Yonne
:(

J'en ai importé une partie en mappant le coin (c'est mon axe habituel... 94
-> 77 -> 89).

Je m'en occupe...


Le 21 avril 2013 18:05, Tony Emery  a écrit :

> Boujour à tous,
>
> J'aimerais savoir où en est la communauté de l'import du cadastre dans
> l'Yonne.
>
> Il reste des communes pour lesquelles le bâti n'a pas été importer et
> j'aimerais pouvoir contribuer dans le coin, notamment vers Vaudeurs.
>
> Vu que je ne maîtrise pas le plug-in d'import, je préfère m'en remettre aux
> spécialistes.
>
> Merci de me tenir au courant dès que vous avez des nouvelles.
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Cadastre-dans-l-Yonne-tp5757967.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
>



-- 
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] Prochaine réunion des contributeurs des Pyrénées-Orientales

[Jo.]

Malheureusement je travail sur Durban et je n'aurai pas pas de moyen de
locomotion, j'aurai aimé vous rencontrer mais ce n'est que partie remise.

Je serait sur Durban pendant 2 semaines, j'en ai déjà profité pour apporter
quelques amélioration sur la commune d'après ce que j'ai visuellement
constaté sur place et je compte profiter de mon séjour pour améliorer cette
zone rarement mise à jour. A défaut d'avoir un bâtit importable, je
dessinerai approximativement les bâtiments public, commerce de proximité
autre bâtiments recevant du public.




Le 21 avril 2013 08:36, RainerU  a écrit :

> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rendu tile.openstreetmap.fr et nom dans relation multipolygone

[Stéphane MARTIN]

Salut,

Le Centre hospitalier de Cayenne n'est pas marqué par un H sur fond bleu 
dans le rendu FR (comme dans Mapnik d'ailleurs) tandis que les cliniques 
apparaissent.


http://tile.openstreetmap.fr/?zoom=16&lat=4.92122&lon=-52.31659&layers=B0F

Mapquest affiche bien une image mais pas pour les cliniques.
2u affiche pour les deux.

En fait l'étiquette (amenity=hospital) est dans une relation 
mulipolygone : 2 669 321.


Bref, y aurait-il moyen de moyenner ?
Faut-il que je crée un ticket ?

@+

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

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

[Jean-Baptiste Holcroft]

J'ai commencé pessac, mais c'est particulièrement long. Je fini dans la
semaine.
Je n'arrive pas à faire Nîmes, le fichier est trop énorme (44mo) et je ne
sais pas le découper :( si quelqu;un me le découpe en 4 ou idéalement en 6,
je pourrais m'y attaquer.
Le 21 avr. 2013 15:05, "didier2020"  a écrit :

> Le dimanche 21 avril 2013 à 13:05 +0200, Jean-Baptiste Holcroft a
> écrit :
> > Il y a des endroits particuliers à faire pour aider ?
> peut etre les villes qui sont partiellement importées ? ou pas ?
> ( comme nimes ou pessac de souvenir d'un post recent)
> > Ou alors c'est pour le plaisir d'indiquer les villes importées ? ;)
> L 1 n'empeche pas l'autre ;)
>
> didier
> > --
> > Jean-Baptiste Holcroft
> >
> >
> > 2013/4/21 PhQ 
> > Pour Aydat, c'est fait ! S'il reste des trous identifiés 
> >
> >
> >
> > --
> > View this message in context:
> >
> http://gis.19327.n5.nabble.com/http-cadastre-openstreetmap-fr-tp5757271p5757906.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