Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Christian Quest]

L'avantage de rendre les données visibles... on voit mieux les défauts ;)


Le 10 juin 2013 15:22, Ab_fab  a écrit :
> Même cas de figure dans la baie de l'Aiguillon :
> http://tile.openstreetmap.fr/?zoom=13&lat=46.27507&lon=-1.15953&layers=B0F
>
> Pas d'explication, si ce n'est une supposition :
> la coupure suit (à peu près) une limite régionale (PdL / Poitou Charente) et
> départementale (Vendée et Charente Maritime). Ce n'est pas le cas pour le
> lac de Grand Lieu
>
>
>
> Le 10 juin 2013 15:13, Philippe Verdy  a écrit :
>
>> En tout cas ce rendu permet de voir facilement qu'une même réserve (même
>> nom) a été coupée bizarrement en deux parties quasi-jointives au milieu du
>> lac de Grand-Lieu (sud-ouest de Nantes vers Chalans):
>>
>> http://tile.openstreetmap.fr/?zoom=14&lat=47.09695&lon=-1.67263&layers=B0F
>> On se demande bien pourquoi cela n'en fait pas qu'une seule: un classement
>> qui s'est fait en deux temps? des règles locales spécifiques ou une
>> tolérance spéciale pour une moitié du lac (par exemple pour la pêche amateur
>> ou la chasse? ou une zone inaccessible aux bateaux pour protéger certaines
>> plantes?Ou alors une juste zone de comptage et des espèces migratrices ou de
>> nichage?
>>
>> Et pourquoi cette bande étroite en accent circonflexe au milieu, c'est
>> suspect...
>>
>> Moi qui connait un peu le coin où j'ai habité plusieurs années, je n'ai
>> jamais connu qu'une seule réserve, pas deux, et tout le lac est dans la
>> réserve (rien de différencié sur la signalisation du coin.
>>
>>
>>
>> Le 10 juin 2013 14:41, djoman  a écrit :
>>>
>>> bonjour Christian et à tous
>>>
>>> merci à toi pour tous tes efforts. La nouvelle version est top.
>>>
>>> Le rendu ce pose uniquement sur le tag leisure=nature_reserve ou aussi
>>> sur le boundary=protected area+protect_class=(x) ?
>>>
>>> si c'est oui alors la question c'est : faut-il s’appuyer uniquement sur
>>> le leisure=nature_reserve déclaré par le contributeur ou bien profiter de ce
>>> rendu pour l'étendre à tous les objets liés à une gamme de classe d'un
>>> protected_area ?
>>>
>>> natura 2000: protect_class=97
>>> site ramsar: =98
>>> pnr: =5
>>>
>>> mais
>>> Terrain du Conservatoire du Littoral  : protect_class=4
>>> pas forcement besoin d'un perimètre affiché sur la carte pour ça.
>>>
>>>
>>> http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN
>>>
>>> pour info
>>> le protect_class remplace recemment le protect_id
>>> le wiki n'est pas à jour et il reste beaucoup de ces protect_id (tous ?)
>>>
>>> http://wiki.openstreetmap.org/wiki/Key:protect_id
>>>
>>> djo_man
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> ab_fab
> "Il n'y a pas de pas perdus", Nadja
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Ab_fab]

Même cas de figure dans la baie de l'Aiguillon :
http://tile.openstreetmap.fr/?zoom=13&lat=46.27507&lon=-1.15953&layers=B0F

Pas d'explication, si ce n'est une supposition :
la coupure suit (à peu près) une limite régionale (PdL / Poitou Charente)
et départementale (Vendée et Charente Maritime). Ce n'est pas le cas pour
le lac de Grand Lieu



Le 10 juin 2013 15:13, Philippe Verdy  a écrit :

> En tout cas ce rendu permet de voir facilement qu'une même réserve (même
> nom) a été coupée bizarrement en deux parties quasi-jointives au milieu du
> lac de Grand-Lieu (sud-ouest de Nantes vers Chalans):
>
> http://tile.openstreetmap.fr/?zoom=14&lat=47.09695&lon=-1.67263&layers=B0F
> On se demande bien pourquoi cela n'en fait pas qu'une seule: un classement
> qui s'est fait en deux temps? des règles locales spécifiques ou une
> tolérance spéciale pour une moitié du lac (par exemple pour la pêche
> amateur ou la chasse? ou une zone inaccessible aux bateaux pour protéger
> certaines plantes?Ou alors une juste zone de comptage et des espèces
> migratrices ou de nichage?
>
> Et pourquoi cette bande étroite en accent circonflexe au milieu, c'est
> suspect...
>
> Moi qui connait un peu le coin où j'ai habité plusieurs années, je n'ai
> jamais connu qu'une seule réserve, pas deux, et tout le lac est dans la
> réserve (rien de différencié sur la signalisation du coin.
>
>
>
> Le 10 juin 2013 14:41, djoman  a écrit :
>
>>  bonjour Christian et à tous
>>
>> merci à toi pour tous tes efforts. La nouvelle version est top.
>>
>> Le rendu ce pose uniquement sur le tag leisure=nature_reserve ou aussi
>> sur le boundary=protected area+protect_class=(x) ?
>>
>> si c'est oui alors la question c'est : faut-il s’appuyer uniquement sur
>> le leisure=nature_reserve déclaré par le contributeur ou bien profiter de
>> ce rendu pour l'étendre à tous les objets liés à une gamme de classe d'un
>> protected_area ?
>>
>> natura 2000: protect_class=97
>> site ramsar: =98
>> pnr: =5
>>
>> *mais*
>> Terrain du Conservatoire du Littoral  : protect_class=4
>> pas forcement besoin d'un perimètre affiché sur la carte pour ça.
>>
>>
>> http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN
>>
>> *pour info*
>> le protect_class remplace recemment le protect_id
>> le wiki n'est pas à jour et il reste beaucoup de ces protect_id (tous ?)
>>
>> http://wiki.openstreetmap.org/wiki/Key:protect_id
>>
>> djo_man
>>
>> ___
>> 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
>
>


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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

En tout cas ce rendu permet de voir facilement qu'une même réserve (même
nom) a été coupée bizarrement en deux parties quasi-jointives au milieu du
lac de Grand-Lieu (sud-ouest de Nantes vers Chalans):
http://tile.openstreetmap.fr/?zoom=14&lat=47.09695&lon=-1.67263&layers=B0F
On se demande bien pourquoi cela n'en fait pas qu'une seule: un classement
qui s'est fait en deux temps? des règles locales spécifiques ou une
tolérance spéciale pour une moitié du lac (par exemple pour la pêche
amateur ou la chasse? ou une zone inaccessible aux bateaux pour protéger
certaines plantes?Ou alors une juste zone de comptage et des espèces
migratrices ou de nichage?

Et pourquoi cette bande étroite en accent circonflexe au milieu, c'est
suspect...

Moi qui connait un peu le coin où j'ai habité plusieurs années, je n'ai
jamais connu qu'une seule réserve, pas deux, et tout le lac est dans la
réserve (rien de différencié sur la signalisation du coin.



Le 10 juin 2013 14:41, djoman  a écrit :

>  bonjour Christian et à tous
>
> merci à toi pour tous tes efforts. La nouvelle version est top.
>
> Le rendu ce pose uniquement sur le tag leisure=nature_reserve ou aussi sur
> le boundary=protected area+protect_class=(x) ?
>
> si c'est oui alors la question c'est : faut-il s’appuyer uniquement sur le
> leisure=nature_reserve déclaré par le contributeur ou bien profiter de ce
> rendu pour l'étendre à tous les objets liés à une gamme de classe d'un
> protected_area ?
>
> natura 2000: protect_class=97
> site ramsar: =98
> pnr: =5
>
> *mais*
> Terrain du Conservatoire du Littoral  : protect_class=4
> pas forcement besoin d'un perimètre affiché sur la carte pour ça.
>
>
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN
>
> *pour info*
> le protect_class remplace recemment le protect_id
> le wiki n'est pas à jour et il reste beaucoup de ces protect_id (tous ?)
>
> http://wiki.openstreetmap.org/wiki/Key:protect_id
>
> djo_man
>
> ___
> 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 et réserves naturelles

[djoman]

bonjour Christian et à tous

merci à toi pour tous tes efforts. La nouvelle version est top.

Le rendu ce pose uniquement sur le tag leisure=nature_reserve ou aussi 
sur le boundary=protected area+protect_class=(x) ?


si c'est oui alors la question c'est : faut-il s'appuyer uniquement sur 
le leisure=nature_reserve déclaré par le contributeur ou bien profiter 
de ce rendu pour l'étendre à tous les objets liés à une gamme de classe 
d'un protected_area ?


natura 2000: protect_class=97
site ramsar: =98
pnr: =5

_mais_
Terrain du Conservatoire du Littoral : protect_class=4
pas forcement besoin d'un perimètre affiché sur la carte pour ça.

http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN

_pour info_
le protect_class remplace recemment le protect_id
le wiki n'est pas à jour et il reste beaucoup de ces protect_id (tous ?)

http://wiki.openstreetmap.org/wiki/Key:protect_id

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Nicolas Dumoulin]

Le lundi 10 juin 2013 05:29:29 Philippe Verdy a écrit :
> Cette fois ça marche, plus d'aberrations géométriques avec ces
> débordements. Je remarque que tu as réduit l'épaisseur notablement, l'effet
> d'opacité décroissante est moins visible, et parfois le tracé disparaît
> lorsque la réserve longe une route (la route recouvre tout le tracé).

Ouaip. Pour ma part, je dis : joli et beau travail Christian :-)
Par contre le découpage tortueux de cette RN en particulier n'aide pas la 
lisibilité.
Merci

-- 
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] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Cette fois ça marche, plus d'aberrations géométriques avec ces
débordements. Je remarque que tu as réduit l'épaisseur notablement, l'effet
d'opacité décroissante est moins visible, et parfois le tracé disparaît
lorsque la réserve longe une route (la route recouvre tout le tracé).


Le 10 juin 2013 00:07, Christian Quest  a écrit :

> Nouvelle mouture:
>
> http://tile.openstreetmap.fr/?zoom=11&lat=47.42028&lon=-2.41356&layers=B0F
>
> (tuiles regénérées dans le coin à coup de /dirty)
>
> C'est fait avec 4 lignes, décalées par line-offset et avec une opacité
> qui décroit.
>
> ___
> 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 et réserves naturelles

[Christian Quest]

Nouvelle mouture:
http://tile.openstreetmap.fr/?zoom=11&lat=47.42028&lon=-2.41356&layers=B0F

(tuiles regénérées dans le coin à coup de /dirty)

C'est fait avec 4 lignes, décalées par line-offset et avec une opacité
qui décroit.

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

A noter que ce serait pas mal que Mapnik supporte directement dans ses
feuilles de style XML la possibilité de préciser le côté de l'épaisseur de
ligne qu'on veut afficher (par défaut il affiche les deux côtés,
moitié-moitié à cheval sur le ligne virtuelle), on devrait pouvoir indiquer
une option "both" (valeur par défaut actuelle), "inner" ou "outer"  (pour
ne représenter que la moitié interne ou externe du polygone), ou "left" ou
"right" (en fonction du sens de parcours, sur les éléments linéaires non
surfaciques).

Le code ci-dessus (qui étend le clipping de la moitié de l'épaisseur de
ligne pourqu'elle reste visible en totalité) devrait être désactivé si on
ne représente que la partie interne, et dans ce cas il suffirait de mettre
clip=false dans l'attribut de style de ligne (mais cela a un effet de bord
car il n'est pas fait pour que pour ça).

Intérêt: pouvoir afficher aussi le long d'une route un coté "remarquable"
comme sur les cartes Michelin pour les routes touristiques, ou pour créer
des ombres autour de bâtiments à mettre en valeur (mais pas dedans). Ou
encore pour marquer les bons côtés où il y a une piste cyclable, une voie
de bus, ou du stationnement autorisé, ou le côté où il y a une barrière de
sécurité, ou un fossé.


Le 9 juin 2013 19:52, Philippe Verdy  a écrit :

> Et en pratique ce support est intégré dans le LineSymbolizer:
>
>
> if (sym.clip())
>
> {
>
> double padding = (double)(query_extent_.width()/width_);
>
> double half_stroke = stroke_.get_width()/2.0;
>
> if (half_stroke > 1)
>
> padding *= half_stroke;
>
> if (std::fabs(sym.offset()) > 0)
>
> padding *= std::fabs(sym.offset()) * 1.2;
>
> padding *= scale_factor_;
>
> clipping_extent.pad(padding);
>
> }
>
>
> voir https://github.com/mapnik/mapnik/blob/master/src/cairo_renderer.cpp
>
> Bref on fait le rendu avec les attributs offset et width donnés dans la
> feuille de style pour le LineSymbolizer, le reste c'est le rendu PNG de
> Cairo (ou le rendu en SVG) qui se débrouille pour calculer les buffers
> corrects (et je pense même que ce sera bien plus performant que tes
> symboles marqueurs en répétés en "pattern" sur une distance de 1 pixel le
> long d'une ligne, la technique qui ne sert en pratique qu'à dessiner les
> triangles le long des traits de falaises à distance régulière).
>
> Peut-être qu'il faut bidouiller le code C++ de Mapnik pour activer la
> bonne combinaison d'options, mais tout y est pour supporter ça, et ensuite
> pouvoir l'utiliser dans la feuille de style XML.
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Et en pratique ce support est intégré dans le LineSymbolizer:

if (sym.clip())
{
double padding = (double)(query_extent_.width()/width_);
double half_stroke = stroke_.get_width()/2.0;
if (half_stroke > 1)
padding *= half_stroke;
if (std::fabs(sym.offset()) > 0)
padding *= std::fabs(sym.offset()) * 1.2;
padding *= scale_factor_;
clipping_extent.pad(padding);
}


voir https://github.com/mapnik/mapnik/blob/master/src/cairo_renderer.cpp

Bref on fait le rendu avec les attributs offset et width donnés dans la
feuille de style pour le LineSymbolizer, le reste c'est le rendu PNG de
Cairo (ou le rendu en SVG) qui se débrouille pour calculer les buffers
corrects (et je pense même que ce sera bien plus performant que tes
symboles marqueurs en répétés en "pattern" sur une distance de 1 pixel le
long d'une ligne, la technique qui ne sert en pratique qu'à dessiner les
triangles le long des traits de falaises à distance régulière).

Peut-être qu'il faut bidouiller le code C++ de Mapnik pour activer la bonne
combinaison d'options, mais tout y est pour supporter ça, et ensuite
pouvoir l'utiliser dans la feuille de style XML.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Bruno Cortial]

Le 9 juin 2013 18:26, Philippe Verdy  a écrit :

>
> https://github.com/mapnik/mapnik/blob/master/deps/clipper/src/clipper.cpp
>
>
>
PolyOffsetBuilder, très bien , mais non exposé par mapnik. Essaies encore.


Sinon je propose l'utilisation des opérations de filtrages et composition
de mapnik. Ca doit résoudre les artefacts, mais c'est sans doute plus
délicat à intégrer dans les règles osm-fr.
J'ai bidouillé un peu, mais j'ai encore du mal avec la gestion des couches
lors de ces opérations!

Un premier exemple (en carto)
#limites[type = 'farm'] {
  ::outline {
line-width:10;
line-color: green;
image-filters: agg-stack-blur(5,5);
  }
  polygon-fill: black;
//  polygon-smooth : 0.2;
  comp-op: dst-in;
}


https://docs.google.com/file/d/0ByriFLbxzg_1ekcyV3FZRHFsNms/edit?usp=sharing




Second exemple :

#limites[type = 'residential'] {
  ::trait{line-width:0.5;}
  ::hach{
polygon-pattern-file: url('Diagonal_Pattern_clip_art_hight.png');
}
  line-width:10;
  line-color: black;
  image-filters: agg-stack-blur(10,10);
  comp-op: dst-in;
}

https://docs.google.com/file/d/0ByriFLbxzg_1M1hwQUJIZnN5QkE/edit?usp=sharing



Source infinie d'inspiration :
http://www.mapbox.com/tilemill/docs/guides/comp-op/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Non je ne parlais pas du code source ce la bibliothèque que tu utilises,
mais TON code dans ton moteur de rendu.
A mon avis au lieu des "LinePatternSymbolizer", cela marcherait mieux avec

PolyOffsetBuilder

dans

https://github.com/mapnik/mapnik/blob/master/deps/clipper/src/clipper.cpp

(Clipper contient tout un stock d'algorithmes de calcul et dérivation de
géométries)


Le 9 juin 2013 17:33, Christian Quest  a écrit :

> Le 9 juin 2013 17:14, Philippe Verdy  a écrit :
> > Mauvaise méthode donc.
> >
> > Tu fais comment pour dessiner les routes ? Tu utilises bien des lignes en
> > précisant une épaisseur de trait et le moteur de rendu vectoriel calcule
> un
> > polygone à remplir (ce qui se fait dans le moteur graphique un buffer,
> non
> > ?)
> >
> > Tout moteur graphique vectoriel (par exemple SVG ou Postscript) fait
> ainsi :
> > en fait il ne trace pas des lignes mais remplit un polygone. Même pour
> faire
> > des lignes avec un pattern (tirets, pointillés, ...), ce sont encore des
> > polygones qui sont créés avant d'être remplis.
> >
> > Je ne sais pas ce qu'est ton "line-pattern" (je n'ai pas le détail de ce
> que
> > fais ton code) mais ce que tu décris n'a rien à voir avec la terminologie
> > habituelle dans les moteurs vectoriels, où il ne s'agit pas du tout de
> > répéter une image le long d'un trait virtuel.
> >
>
> https://github.com/mapnik/mapnik/wiki/LinePatternSymbolizer
>
> Je croyais avoir déjà mis le lien.
>
> Et pour le code (qui n'est pas le mien):
>
> https://github.com/mapnik/mapnik/blob/master/src/line_pattern_symbolizer.cpp
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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 et réserves naturelles

[Christian Quest]

Le 9 juin 2013 17:14, Philippe Verdy  a écrit :
> Mauvaise méthode donc.
>
> Tu fais comment pour dessiner les routes ? Tu utilises bien des lignes en
> précisant une épaisseur de trait et le moteur de rendu vectoriel calcule un
> polygone à remplir (ce qui se fait dans le moteur graphique un buffer, non
> ?)
>
> Tout moteur graphique vectoriel (par exemple SVG ou Postscript) fait ainsi :
> en fait il ne trace pas des lignes mais remplit un polygone. Même pour faire
> des lignes avec un pattern (tirets, pointillés, ...), ce sont encore des
> polygones qui sont créés avant d'être remplis.
>
> Je ne sais pas ce qu'est ton "line-pattern" (je n'ai pas le détail de ce que
> fais ton code) mais ce que tu décris n'a rien à voir avec la terminologie
> habituelle dans les moteurs vectoriels, où il ne s'agit pas du tout de
> répéter une image le long d'un trait virtuel.
>

https://github.com/mapnik/mapnik/wiki/LinePatternSymbolizer

Je croyais avoir déjà mis le lien.

Et pour le code (qui n'est pas le mien):
https://github.com/mapnik/mapnik/blob/master/src/line_pattern_symbolizer.cpp

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Ista Pouss]

Le 9 juin 2013 10:31, Christian Quest  a écrit :

> Voilà la dernière évolution du rendu des réserves naturelles (les
> tuiles sont en cours de régénération car ça impacte à partir du zoom
> 10):
>
>
> http://tile.openstreetmap.fr/?zoom=13&lat=47.29383&lon=-2.44937&layers=B0F
>
>
Et avec cette limite verte comment fera-t-on le jour où nous voudrons
enregistrer une souris verte dans une réserve naturelle ? Nous ne le
pourrons pas !

Déjà avec une forêt verte ça fonctionne moyen la preuve :
http://tile.openstreetmap.fr/?zoom=15&lat=45.43078&lon=4.24989&layers=B0F

Je pense qu'il faudrait rendre en jaune, car il n'y a ni souris ni forêts
jaunes.

Et aussi le nom de la réserve a disparu dans le rendu fr, est-ce normal
?... la même dans le rendu osm indique "Réserve naturelle des gorges de la
Loire" -> http://osm.org/go/0ApBb0ik--


-- 
Les dérives de rue :
Le projet de théâtre de Saint-Étienne emporté par le
vent

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Mauvaise méthode donc.

Tu fais comment pour dessiner les routes ? Tu utilises bien des lignes en
précisant une épaisseur de trait et le moteur de rendu vectoriel calcule un
polygone à remplir (ce qui se fait dans le moteur graphique un buffer, non
?)

Tout moteur graphique vectoriel (par exemple SVG ou Postscript) fait ainsi
: en fait il ne trace pas des lignes mais remplit un polygone. Même pour
faire des lignes avec un pattern (tirets, pointillés, ...), ce sont encore
des polygones qui sont créés avant d'être remplis.

Je ne sais pas ce qu'est ton "line-pattern" (je n'ai pas le détail de ce
que fais ton code) mais ce que tu décris n'a rien à voir avec la
terminologie habituelle dans les moteurs vectoriels, où il ne s'agit pas du
tout de répéter une image le long d'un trait virtuel.

Quand une image est utilisée c'est uniquement pour appliquer une texture
pour le remplissage, ou pour des techniques dites de "screening" (en
Postscript par exemple "setscreen") destinée à produire des "patterns" pour
produire des demi-tons ("halftoning", en Postscript), très utilisés pour
l'impression (encre sur papier, que ce soit par lithographie, ou jet
d'encre dans les imprimantes, ou sur les lasers, avec des paramètres tenant
compte de la diffusion de l'encre sur le papier, de la qualité du papier,
de la nature des particules ou goutelettes d'encres, des techniques de
fixation, séchage ou cuisson de l'encre, ou de l'opacité des encres en cas
de superposition d'encres, etc.).



Le 9 juin 2013 16:54, Christian Quest  a écrit :

> Pour la troisième fois: je n'utilise aucun buffer mais un line-pattern.
>
> C'est un petit PNG qui est dessiné par Mapnik sur le pourtour du
> polygone et quand les angles sont trop aigus, ça bave un peu en
> dérapant dans le virage.
>
> ___
> 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 et réserves naturelles

[Christian Quest]

Pour la troisième fois: je n'utilise aucun buffer mais un line-pattern.

C'est un petit PNG qui est dessiné par Mapnik sur le pourtour du
polygone et quand les angles sont trop aigus, ça bave un peu en
dérapant dans le virage.

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Quelques pistes pour les algos de calculs de buffers de polygones:
http://stackoverflow.com/questions/1109536/an-algorithm-for-inflating-deflating-offsetting-buffering-polygons
Suivre les liens de cette discussion. La solution "naïve" que tu utilises
n'est pas correcte mais le problème est connu et a des solutions.
Plus de détails sur l'article suivant (avec un peu de code):
http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/Straight_skeleton_2/Chapter_main.html



Le 9 juin 2013 12:50, Philippe Verdy  a écrit :

> Je ne pense pas que changer les épaisseurs ne soient viable. Il me semble
> que c'est l"algo qui fait un calcul appromximatif des buffers dans le
> système de coordonnées en projection carto (pixels) qui est défaillant : on
> ne doit pas se contenter de calculer un segment parallèle et le joindre au
> segment suivant et précédent, il faut aussi clipper ces polygones pour
> qu'il ne sortent pas du polygone de base, et éliminer les parties interne
> en superposition multiples (c'est le principe compliqué de calcul
> géométrique des buffers, que réalise PostGIS dans le système de coordonées
> géographique, mais que tu n'utilises pas ici).
>
> Pour cela il existe des algos dans les bibliothèques graphiques, mais là
> je n'ai aucune idée de ce dont tu disposes dans ton code pour le faire, et
> si ta blibliothèque de rendu vectoriel le propose parmi ses utilitaires de
> transformation de géométries (ce n'est pas un algo proposé par défaut pour
> SVG ou Postscript par exemple) ; il y en a pour GDI+ ou Flash mais là je
> n'ai aucune idée des nterfaces que tu utilises pour convertir les
> géométries avant leur rendu vectoriel. Ces algos libres doivent pourtant
> exister car PostGIS a bien du les implémenter pour calculer ses propres
> buffers en coordonnées géographiques.
>
>
>
> Le 9 juin 2013 12:19, Christian Quest  a écrit :
>
> Toujours mieux avec un permalien !
>>
>> J'ai vu ces défauts sur les petits polygones.
>>
>> C'est lié à la technique utilisée (sans buffers postgis).
>>
>> Il va sûrement falloir changer l'épaisseur en fonction de la surface
>> du polygone ou un truc du genre...
>>
>>
>> Le 9 juin 2013 12:11, Philippe Verdy  a écrit :
>> >
>> http://tile.openstreetmap.fr/?zoom=11&lat=47.61458&lon=-3.39151&layers=B0F
>> >
>> > Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça
>> déborde
>> > (côté mer c'est plus facile à voir) par rapport au rendu du zoom 12. Les
>> > débordements sont encore plus accentués au zoom 10.
>> > Et ça explique pourquoi ces réserves semblent beaucoup plus étendues
>> > qu'elles ne sont, et trop visibles aussi. En fait cela affecte *toutes*
>> les
>> > petites réserves.
>> >
>>
>> --
>> Christian Quest - OpenStreetMap France
>> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>>
>> ___
>> 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 et réserves naturelles

[Philippe Verdy]

Je ne pense pas que changer les épaisseurs ne soient viable. Il me semble
que c'est l"algo qui fait un calcul appromximatif des buffers dans le
système de coordonnées en projection carto (pixels) qui est défaillant : on
ne doit pas se contenter de calculer un segment parallèle et le joindre au
segment suivant et précédent, il faut aussi clipper ces polygones pour
qu'il ne sortent pas du polygone de base, et éliminer les parties interne
en superposition multiples (c'est le principe compliqué de calcul
géométrique des buffers, que réalise PostGIS dans le système de coordonées
géographique, mais que tu n'utilises pas ici).

Pour cela il existe des algos dans les bibliothèques graphiques, mais là je
n'ai aucune idée de ce dont tu disposes dans ton code pour le faire, et si
ta blibliothèque de rendu vectoriel le propose parmi ses utilitaires de
transformation de géométries (ce n'est pas un algo proposé par défaut pour
SVG ou Postscript par exemple) ; il y en a pour GDI+ ou Flash mais là je
n'ai aucune idée des nterfaces que tu utilises pour convertir les
géométries avant leur rendu vectoriel. Ces algos libres doivent pourtant
exister car PostGIS a bien du les implémenter pour calculer ses propres
buffers en coordonnées géographiques.



Le 9 juin 2013 12:19, Christian Quest  a écrit :

> Toujours mieux avec un permalien !
>
> J'ai vu ces défauts sur les petits polygones.
>
> C'est lié à la technique utilisée (sans buffers postgis).
>
> Il va sûrement falloir changer l'épaisseur en fonction de la surface
> du polygone ou un truc du genre...
>
>
> Le 9 juin 2013 12:11, Philippe Verdy  a écrit :
> >
> http://tile.openstreetmap.fr/?zoom=11&lat=47.61458&lon=-3.39151&layers=B0F
> >
> > Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça
> déborde
> > (côté mer c'est plus facile à voir) par rapport au rendu du zoom 12. Les
> > débordements sont encore plus accentués au zoom 10.
> > Et ça explique pourquoi ces réserves semblent beaucoup plus étendues
> > qu'elles ne sont, et trop visibles aussi. En fait cela affecte *toutes*
> les
> > petites réserves.
> >
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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 et réserves naturelles

[Philippe Verdy]

Même constat:
http://tile.openstreetmap.fr/?zoom=17&lat=48.10082&lon=-1.67405&layers=B0F
Ici la prison des femmes à Rennes, visible avec les hachures rouges
miliaires au zoom 17+, mais rien de visible au niveau 16 ou moins, où on ne
voit que les bâtiments.

On voit aussi les icônes un peu "étranges" sur certains bâtiments au zoom
17+, aucune au niveau 16 ou moins. Ces icônes sont peu identifiables, et
pourraient être améliorées (plutôt qu'un corps et une tête symbolisés, ce
devrait être juste la tête et les mains tenant les barreaux, ou une icône
monochrome un peu dans le style de la case de Monopoly).

Une recherche Google fournit des collections d'icônes monochrome pour "jail
icon". exemples:

http://www.shutterstock.com/pic.mhtml?id=85496875
http://www.canstockphoto.com/illustration/jail.html#file_view.php?id=13599481
(celles
là ne sont pas libres, mais c'est l'idée générale)



Le 9 juin 2013 11:52, Vincent Pottier  a écrit :

> Le 09/06/2013 10:31, Christian Quest a écrit :
>
>  Voilà la dernière évolution du rendu des réserves naturelles (les
>> tuiles sont en cours de régénération car ça impacte à partir du zoom
>> 10):
>>
>> http://tile.openstreetmap.fr/?**zoom=13&lat=47.29383&lon=-2.**
>> 44937&layers=B0F
>>
>>  J'aime beaucoup !
> Merci !
>
> Mais là :
> La prison et le camp militaire apparaissent pareils.
> J'aime moins...
> --
> 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] rendu osm-fr et réserves naturelles

[Philippe Verdy]

En gros l'anomalie c'est qu'en calculant un polygone de buffer supposé à
l'intérieur du polygone de base, ce polygone calculé en partant d'un côté
peut sortir du polygone de base.

Pour l'éviter, il faut ensuite lui appliquer un clipping par le polygone de
base. Et c'est ce clipping qui manque et provoque l'anomalie (qu'on
constate aussi autour des "pointes" de toutes les réserves, même plus
grandes, partout là où il y a des angles de plus de 90 degrés mesurés sur
la distance de buffer et pas seulement entre deux segments immédiats
connectés au même sommet).

Techniquement je ne sais pas comment tu calcule les polygones, mais ce ne
sont pas des buffers dans le système de coordonnées géographique, mais dans
celui de la projection de rendu carto (coordonnées en pixels, donc à priori
pas dans le code SQL lui-même, qui n'a besoin de retourner que le polygone
externe de base avant la projection carto).


Le 9 juin 2013 12:11, Philippe Verdy  a écrit :

>
> http://tile.openstreetmap.fr/?zoom=11&lat=47.61458&lon=-3.39151&layers=B0F
>
> Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça
> déborde (côté mer c'est plus facile à voir) par rapport au rendu du zoom
> 12. Les débordements sont encore plus accentués au zoom 10.
> Et ça explique pourquoi ces réserves semblent beaucoup plus étendues
> qu'elles ne sont, et trop visibles aussi. En fait cela affecte *toutes* les
> petites réserves.
>
>
> Le 9 juin 2013 11:53, Vincent Pottier  a écrit :
>
> Le 09/06/2013 11:42, Philippe Verdy a écrit :
>>
>>  Il y a une anomalie de géométrie des buffers calculés, qui "débordent"
>>> quand ils partent d'un côté du polygone pour passer par dessus l'autre côté
>>> du polygone. Effet visible au sud de l'île de Groix (en mer).
>>>
>> Une url, ça aide...
>> --
>> 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] rendu osm-fr et réserves naturelles

[Christian Quest]

Toujours mieux avec un permalien !

J'ai vu ces défauts sur les petits polygones.

C'est lié à la technique utilisée (sans buffers postgis).

Il va sûrement falloir changer l'épaisseur en fonction de la surface
du polygone ou un truc du genre...


Le 9 juin 2013 12:11, Philippe Verdy  a écrit :
> http://tile.openstreetmap.fr/?zoom=11&lat=47.61458&lon=-3.39151&layers=B0F
>
> Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça déborde
> (côté mer c'est plus facile à voir) par rapport au rendu du zoom 12. Les
> débordements sont encore plus accentués au zoom 10.
> Et ça explique pourquoi ces réserves semblent beaucoup plus étendues
> qu'elles ne sont, et trop visibles aussi. En fait cela affecte *toutes* les
> petites réserves.
>

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

http://tile.openstreetmap.fr/?zoom=11&lat=47.61458&lon=-3.39151&layers=B0F

Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça
déborde (côté mer c'est plus facile à voir) par rapport au rendu du zoom
12. Les débordements sont encore plus accentués au zoom 10.
Et ça explique pourquoi ces réserves semblent beaucoup plus étendues
qu'elles ne sont, et trop visibles aussi. En fait cela affecte *toutes* les
petites réserves.


Le 9 juin 2013 11:53, Vincent Pottier  a écrit :

> Le 09/06/2013 11:42, Philippe Verdy a écrit :
>
>  Il y a une anomalie de géométrie des buffers calculés, qui "débordent"
>> quand ils partent d'un côté du polygone pour passer par dessus l'autre côté
>> du polygone. Effet visible au sud de l'île de Groix (en mer).
>>
> Une url, ça aide...
> --
> 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] rendu osm-fr et réserves naturelles

[Vincent Pottier]

Le 09/06/2013 11:42, Philippe Verdy a écrit :
Il y a une anomalie de géométrie des buffers calculés, qui "débordent" 
quand ils partent d'un côté du polygone pour passer par dessus l'autre 
côté du polygone. Effet visible au sud de l'île de Groix (en mer).

Une url, ça aide...
--
FrViPofm

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Vincent Pottier]

Le 09/06/2013 10:31, Christian Quest a écrit :

Voilà la dernière évolution du rendu des réserves naturelles (les
tuiles sont en cours de régénération car ça impacte à partir du zoom
10):

http://tile.openstreetmap.fr/?zoom=13&lat=47.29383&lon=-2.44937&layers=B0F


J'aime beaucoup !
Merci !

Mais là :
La prison et le camp militaire apparaissent pareils.
J'aime moins...
--
FrViPofm

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Il y a une anomalie de géométrie des buffers calculés, qui "débordent"
quand ils partent d'un côté du polygone pour passer par dessus l'autre côté
du polygone. Effet visible au sud de l'île de Groix (en mer).

Aussi le vert utilisé pour les contours "ombrés" semble être trop
contrasté, il devrait je pense être plus pâle, ou bien les niveaux de
transparence pas bien réglés (réduire les valeur alpha). Au faible niveau
de zoom, quand le parc naturel devient assez petit sur le rendu, on ne voit
plus qu'une tâche d'un vert assez foncé, pas assez transparente (effet
aggravé par le "débordement" apparent des ombres en dehors des polygones,
comme signalé au paragraphe précédent).


Le 9 juin 2013 11:20, Christian Quest  a écrit :

> Il faut lire aussi ce qui est entre parenthèses: les tuiles sont en
> cours de régénération car ça impacte à partir du zoom
> 10
>
> ...en ce moment c'est le zoom 8 qui est en régénération sur les zooms 3 à
> 11...
>
> Ca devrait être terminé pour le pousse café dominical ;)
>
> ___
> 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 et réserves naturelles

[Philippe Verdy]

J'attends encore de voir pour le parc marin de la Mer d'Iroise (car il
semble que l'intérieur et l'extérieur sont inversés (le parc marin n'inclue
pas les terres des îles elles mêmes, mais c'est ce qu'on voit sur les
premières tuiles générées.


Le 9 juin 2013 11:20, Christian Quest  a écrit :

> Il faut lire aussi ce qui est entre parenthèses: les tuiles sont en
> cours de régénération car ça impacte à partir du zoom
> 10
>
> ...en ce moment c'est le zoom 8 qui est en régénération sur les zooms 3 à
> 11...
>
> Ca devrait être terminé pour le pousse café dominical ;)
>
> ___
> 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 et réserves naturelles

[Christian Quest]

Il faut lire aussi ce qui est entre parenthèses: les tuiles sont en
cours de régénération car ça impacte à partir du zoom
10

...en ce moment c'est le zoom 8 qui est en régénération sur les zooms 3 à 11...

Ca devrait être terminé pour le pousse café dominical ;)

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Yohan Boniface]

Philippe:

> (les tuiles sont *en cours de régénération* car ça impacte à partir 
du zoom 10)


So, patience...

Yohan

On 06/09/2013 11:11 AM, Philippe Verdy wrote:

il y a un problème avec le Golfe du Morbihan (moitié est utilisant le
nouveau rendu, moitié ouest non, avec une limite verticale visible, au
niveau 11, mais pas au niveau 12)


Le 9 juin 2013 10:31, Christian Quest mailto:cqu...@openstreetmap.fr>> a écrit :

Voilà la dernière évolution du rendu des réserves naturelles (les
tuiles sont en cours de régénération car ça impacte à partir du zoom
10):


http://tile.openstreetmap.fr/?zoom=13&lat=47.29383&lon=-2.44937&layers=B0F

--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

___
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 et réserves naturelles

[Philippe Verdy]

il y a un problème avec le Golfe du Morbihan (moitié est utilisant le
nouveau rendu, moitié ouest non, avec une limite verticale visible, au
niveau 11, mais pas au niveau 12)


Le 9 juin 2013 10:31, Christian Quest  a écrit :

> Voilà la dernière évolution du rendu des réserves naturelles (les
> tuiles sont en cours de régénération car ça impacte à partir du zoom
> 10):
>
>
> http://tile.openstreetmap.fr/?zoom=13&lat=47.29383&lon=-2.44937&layers=B0F
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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 et réserves naturelles

[Philippe Verdy]

apparemment cela ne marche qu'à partir du niveau 12, au niveau 10 ou 11
c'est encore l'ancien rendu


Le 9 juin 2013 10:31, Christian Quest  a écrit :

> Voilà la dernière évolution du rendu des réserves naturelles (les
> tuiles sont en cours de régénération car ça impacte à partir du zoom
> 10):
>
>
> http://tile.openstreetmap.fr/?zoom=13&lat=47.29383&lon=-2.44937&layers=B0F
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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 et réserves naturelles

[Philippe Verdy]

Bravo pour avoir retenu mon idée. C'est superbe, très lisible, tous les
détails dans la réserve sont enfin visibles.


Le 9 juin 2013 10:31, Christian Quest  a écrit :

> Voilà la dernière évolution du rendu des réserves naturelles (les
> tuiles sont en cours de régénération car ça impacte à partir du zoom
> 10):
>
>
> http://tile.openstreetmap.fr/?zoom=13&lat=47.29383&lon=-2.44937&layers=B0F
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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 et réserves naturelles

[Christian Quest]

Voilà la dernière évolution du rendu des réserves naturelles (les
tuiles sont en cours de régénération car ça impacte à partir du zoom
10):

http://tile.openstreetmap.fr/?zoom=13&lat=47.29383&lon=-2.44937&layers=B0F

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Une description de cette G200:
http://www.hardware.fr/articles/35-1/matrox-millenium-g200.html

Bref il y avait déjà un rendu 3D matériel, et le remplissage de triangles
au moins.


Le 7 juin 2013 18:53, Christian Quest  a écrit :

> Le 7 juin 2013 18:40, Philippe Verdy  a écrit :
> > Tous les moteurs SVG savent utiliser le rendu matériel.
> >
>
> Vu qu'on a une carte graphique de folie sur osm13 (vous imaginez...
> "Integrated Matrox® G200, 8MB shared video memory") j'ai un très gros
> doute sur le rendu matériel qui y serait fait...
>
> Je poserai la question à Jean-Claude à l'occasion (et oui, je le connais).
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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 et réserves naturelles

[Philippe Verdy]

C'est quoi le moteur graphique ? Qt ? Même une carte graphique modeste
dispose d'une accélération pour le remplissage de polygones, même si'l n'y
a pas de nombreux "cores" parallèles.

Maintenant il faut voir ce qui est dessus, si la carte ne prend en charge
que le rendu FSAA, c'est du Bresenham simple et non du remplissage par
suivi de listes triées de bordures, mais Qt fournit un support pour ce tri
qui permet ensuite le remplissage matériel sans avoir à dessiner les pixels
de contour un par un par logiciel pour autant.
Les dernières cartes qui n'avaient pas ce support de suivi de contours
datent de 2006, il n'y en a plus aucune sur le marché qui ne sache pas au
moins remplir un triangle avec rendu antialias des pixels de bordure en
utilisant une colorimétrie interne RGBA (où les 4 composantes sont
multipliées par un facteur alpha correspondant au tau de couverture d'un
pixel, et où les coordonnées de pixels sont remplacées par des coordonnées
de sous-pixels  avec au moins 3 bits pour les fractions horizontales et
verticales).

Maintenant sur les serveurs aussi on a des cartes graphiques multicoeurs,
car ces cartes sont aussi des instruments de calcul utilisables pour plein
de choses et pas que le graphisme, avec d'importantes possibilités de
programmation parallèle. Des moteurs de bases de donnes les utilisent pour
le tri par exemple, des noyaux système peuvent les utiliser pour
l'ordonnancement des tâches et événements, ou la gestion de la mémoire et
des files I/O.
Le parallélisme devient une réalité qui se glisse même depuis plusieurs
années dans les CPU standards avec des instructions nouvelles. Et de plus
en plus on utilise les cartes graphiques pour autre chose que le seul
graphisme, ces cartes sont multiusage en traitement du signal, compression
de données, etc. Le tout est servi par des pilotes sui se branchent sur des
bibliothèques standards et one ne se rend même plus compte que la carte
graphie accélérée est utilisée par des API de base.




Le 7 juin 2013 18:53, Christian Quest  a écrit :

> Le 7 juin 2013 18:40, Philippe Verdy  a écrit :
> > Tous les moteurs SVG savent utiliser le rendu matériel.
> >
>
> Vu qu'on a une carte graphique de folie sur osm13 (vous imaginez...
> "Integrated Matrox® G200, 8MB shared video memory") j'ai un très gros
> doute sur le rendu matériel qui y serait fait...
>
> Je poserai la question à Jean-Claude à l'occasion (et oui, je le connais).
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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 et réserves naturelles

[Christian Quest]

Le 7 juin 2013 18:40, Philippe Verdy  a écrit :
> Tous les moteurs SVG savent utiliser le rendu matériel.
>

Vu qu'on a une carte graphique de folie sur osm13 (vous imaginez...
"Integrated Matrox® G200, 8MB shared video memory") j'ai un très gros
doute sur le rendu matériel qui y serait fait...

Je poserai la question à Jean-Claude à l'occasion (et oui, je le connais).

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

A ce sujet une lecture instructive!
http://perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf

(concerne autant la modélisation géographique que le rendu final en SVG
après projection).

On trouve tout un tas de techniques explosées sur la façon d'accélerer le
rendu vectoriel des lignes et polygones. En gros aujourd'hui on ne trace
plus les lignes avec les vieux algorithmes de Bresenham simples (on ne veut
plus des effets de crénelage) mais on remplit des surfaces polygonales, en
convertissant tout trait en polygone à remplir.

Les algos d erendus actuels sont pris en charge par le matériel de toute
carte graphique actuelle et sont une extension de Bresenham où on ne
calcule plus seulement les positions mais aussi les de façon incrémentale
la couverture de chaque pixel, d'après la géométrie du polygone (deux
traits de réference et non plus un seul). Seuls les rendus logiciels
utilisent encore le superéchantillonnage simple (de type FSAA 2x2, qui peut
utiliser le Bresenham simple à un trait, mais ça coûte cher en mémoire sans
donner un résultat formidable visuellement).

Tous les moteurs SVG savent utiliser le rendu matériel.



Le 7 juin 2013 18:26, Philippe Verdy  a écrit :

> Ah oui ? Comment crois-tu qu'on trace des traits épais ? Ou même n'importe
> quel trait d'ailleurs.
>
> Le logiciel calcule des "buffers" puis les remplit. Même si cela ne se
> fait pas dans la requête SQL (qui elle calcule des buffers en taille
> géolocalisée et non dans la taille du rendu final ; la différence c'est le
> système de coordonnées : le SQL travaille dans le système géographique,
> alors que le rendu des lignes travaille dans le système après projection).
>
> C'est nécessaire de faire comme ça pour obtenir des tracés lissés (cela
> nécessite de calculuer non pas des positions de pixel mais des taux de
> couverture des pixels carrés par la surface limitée par le buffer interne ;
> d'nacienne méthodes utilisait un rendu suréchantillonné mais c'était trop
> coûteux en mémoire, pas assez précis pour avoir plus de 4 niveaux de
> transparence pour l'anticrénelage, et c'est plus efficace ce calculer des
> taux de couverture pour en déduire un niveau de transparence à appliquer
> pour le rendu de la couleur effective des pixels qui dès lors peut avoir un
> lissage bien meilleur jusqu'à 256 niveaux ; visuellement le rendu est bien
> meilleur sans nécessiter aucun suréchantillonnage, et en calculant
> directement chaque pixel une seule fois).
>
>
>
> Le 7 juin 2013 18:15, Christian Quest  a écrit :
>
> Le 7 juin 2013 17:06, Philippe Verdy  a écrit :
>> > Une texture pour le trait ? Les textures n'ont pas d'orientation, ou
>> plutôt
>> > cette orientation est figée.
>>
>> C'est comme ça que sont tracés les falaises.
>>
>> Exemple: https://github.com/mapnik/mapnik/wiki/LinePatternSymbolizer
>>
>> > Tracer deux ou trois traits semi-transparents superposés de taille
>> > croissante vers l'intérieur du polygone demande deux ou trois calculs de
>> > buffers mais ça se fait déjà pour tracer les routes (même si elles ne
>> sont
>> > pas semi-transparentes, la couleur n'a pas d'influence sur les
>> performances
>> > ou la complexité du calcul.
>>
>> Et bien non... les routes ne sont pas tracées comme ça.
>> On a un premier trait épais, puis un second un peu plus fin... et
>> magie... ça fait une fine bordure.
>>
>> > Combien de buffers ? Tout dépend de la précision qu'on veut obtenir pour
>> > l'effet d'ombrage (comment est fait l'ombrage blanc des libellés ?)
>> >
>>
>> Les calculs de buffers sont long. J'en utilise un pour décaler les
>> noms sur les limites administratives, et c'est pas neutre du tout.
>>
>> --
>> Christian Quest - OpenStreetMap France
>> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>>
>> ___
>> 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 et réserves naturelles

[Christian Quest]

Ca avance, avec un line-pattern: http://cl.ly/image/34341i2r2J0z

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Ah oui ? Comment crois-tu qu'on trace des traits épais ? Ou même n'importe
quel trait d'ailleurs.

Le logiciel calcule des "buffers" puis les remplit. Même si cela ne se fait
pas dans la requête SQL (qui elle calcule des buffers en taille
géolocalisée et non dans la taille du rendu final ; la différence c'est le
système de coordonnées : le SQL travaille dans le système géographique,
alors que le rendu des lignes travaille dans le système après projection).

C'est nécessaire de faire comme ça pour obtenir des tracés lissés (cela
nécessite de calculuer non pas des positions de pixel mais des taux de
couverture des pixels carrés par la surface limitée par le buffer interne ;
d'nacienne méthodes utilisait un rendu suréchantillonné mais c'était trop
coûteux en mémoire, pas assez précis pour avoir plus de 4 niveaux de
transparence pour l'anticrénelage, et c'est plus efficace ce calculer des
taux de couverture pour en déduire un niveau de transparence à appliquer
pour le rendu de la couleur effective des pixels qui dès lors peut avoir un
lissage bien meilleur jusqu'à 256 niveaux ; visuellement le rendu est bien
meilleur sans nécessiter aucun suréchantillonnage, et en calculant
directement chaque pixel une seule fois).



Le 7 juin 2013 18:15, Christian Quest  a écrit :

> Le 7 juin 2013 17:06, Philippe Verdy  a écrit :
> > Une texture pour le trait ? Les textures n'ont pas d'orientation, ou
> plutôt
> > cette orientation est figée.
>
> C'est comme ça que sont tracés les falaises.
>
> Exemple: https://github.com/mapnik/mapnik/wiki/LinePatternSymbolizer
>
> > Tracer deux ou trois traits semi-transparents superposés de taille
> > croissante vers l'intérieur du polygone demande deux ou trois calculs de
> > buffers mais ça se fait déjà pour tracer les routes (même si elles ne
> sont
> > pas semi-transparentes, la couleur n'a pas d'influence sur les
> performances
> > ou la complexité du calcul.
>
> Et bien non... les routes ne sont pas tracées comme ça.
> On a un premier trait épais, puis un second un peu plus fin... et
> magie... ça fait une fine bordure.
>
> > Combien de buffers ? Tout dépend de la précision qu'on veut obtenir pour
> > l'effet d'ombrage (comment est fait l'ombrage blanc des libellés ?)
> >
>
> Les calculs de buffers sont long. J'en utilise un pour décaler les
> noms sur les limites administratives, et c'est pas neutre du tout.
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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 et réserves naturelles

[Christian Quest]

Le 7 juin 2013 17:06, Philippe Verdy  a écrit :
> Une texture pour le trait ? Les textures n'ont pas d'orientation, ou plutôt
> cette orientation est figée.

C'est comme ça que sont tracés les falaises.

Exemple: https://github.com/mapnik/mapnik/wiki/LinePatternSymbolizer

> Tracer deux ou trois traits semi-transparents superposés de taille
> croissante vers l'intérieur du polygone demande deux ou trois calculs de
> buffers mais ça se fait déjà pour tracer les routes (même si elles ne sont
> pas semi-transparentes, la couleur n'a pas d'influence sur les performances
> ou la complexité du calcul.

Et bien non... les routes ne sont pas tracées comme ça.
On a un premier trait épais, puis un second un peu plus fin... et
magie... ça fait une fine bordure.

> Combien de buffers ? Tout dépend de la précision qu'on veut obtenir pour
> l'effet d'ombrage (comment est fait l'ombrage blanc des libellés ?)
>

Les calculs de buffers sont long. J'en utilise un pour décaler les
noms sur les limites administratives, et c'est pas neutre du tout.

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Pourquoi 100 mètres ? Ce sera pas assez aux niveaux de zoom faibles, et
trop aux niveaux de zoom fort. A mon avis un rendu en bordure épaisse de
taille fixe (en pixels rendus) sera bien meilleur. Cette bordure ne cachera
partiellement des détails internes que pour les faibles niveaux de zoom où
de toute façon on ne voit pas grand chose de l'intérieur.

Une bordure épaisse verte dégradée 5-10 pixels suffira (cette bordure
devrait être semi-transparente partout, de 75% environ sur le bord (sauf le
plus fin liseré externe à 100%, d'un demi-pixel de large et qui pourrait
utiliser un vert plus sombre, le même que pour le libellé central) à 0% à
l'intérieur


Le 7 juin 2013 17:12, djo_man  a écrit :

>  bonjour,
>
> Je profite de ce fil pour parler du rendu proposé que l'on voit bien dans
> l'exemple
> il s'agit des marais salants qui sont presque toujours en zone NR car très
> souvent en zone RAMSAR
>
> Christian tu propose donc qu'à un certain niveau de zone de rendre les
> salines (landuse=salt_pond) comme des natural=mud
> (soit dit en passant le landuse=salt_pond est le seul landuse qui n'a pas
> rendu sur mapnik)
>
> Je trouverais plus judicieux qu'ils soient rendu comme les bassins.
> finalement ce qu'ils sont.
> comme là:
>
> http://tile.openstreetmap.fr/?zoom=14&lat=47.39542&lon=-2.48194&layers=B0
>
> En ce qui concerne le calage à 60° des RN : super, mais il est bien
> difficile de diserner le périmètre maintenant qu'ils sont moins nombreux
> le rendu 2u propose une surface legerement verte au zoom 14 sur l'ensemble
> du périmètre de la réserve. c'est plus parlant pour comprendre tout de
> suite que
> nous sommes dans la reserve mais gacherait à de plus fort zoom les
> couleurs des landuses
>
> oserais-je demander un degradé de vert à transparent sur le périmètre sur
> une épaisseur de 100m environ ?
>
> djoman
> (le fou qui a recopié les marais salants depuis bing)
>
>
>
> ___
> 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 et réserves naturelles

[djo_man]

  
  
bonjour,

Je profite de ce fil pour parler du rendu proposé que l'on voit bien
dans l'exemple
il s'agit des marais salants qui sont presque toujours en zone NR
car très souvent en zone RAMSAR

Christian tu propose donc qu'à un certain niveau de zone de rendre
les salines (landuse=salt_pond) comme des natural=mud
(soit dit en passant le landuse=salt_pond est le seul landuse qui
n'a pas rendu sur mapnik)

Je trouverais plus judicieux qu'ils soient rendu comme les bassins.
finalement ce qu'ils sont.
comme là: 
http://tile.openstreetmap.fr/?zoom=14&lat=47.39542&lon=-2.48194&layers=B0

En ce qui concerne le calage à 60° des RN : super, mais il est bien
difficile de diserner le périmètre maintenant qu'ils sont moins
nombreux
le rendu 2u propose une surface legerement verte au zoom 14 sur
l'ensemble du périmètre de la réserve. c'est plus parlant pour
comprendre tout de suite que
nous sommes dans la reserve mais gacherait à de plus fort zoom les
couleurs des landuses

oserais-je demander un degradé de vert à transparent sur le
périmètre sur une épaisseur de 100m environ ?

djoman
(le fou qui a recopié les marais salants depuis bing)


  


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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Une texture pour le trait ? Les textures n'ont pas d'orientation, ou plutôt
cette orientation est figée.
Tracer deux ou trois traits semi-transparents superposés de taille
croissante vers l'intérieur du polygone demande deux ou trois calculs de
buffers mais ça se fait déjà pour tracer les routes (même si elles ne sont
pas semi-transparentes, la couleur n'a pas d'influence sur les performances
ou la complexité du calcul.
Combien de buffers ? Tout dépend de la précision qu'on veut obtenir pour
l'effet d'ombrage (comment est fait l'ombrage blanc des libellés ?)



Le 7 juin 2013 16:57, Christian Quest  a écrit :

> Le problème c'est dans quelle couche traiter la frontière.
> Elle risque d'être masquée par pas mal de routes, d'où na nécessité de
> la texture des "RN".
>
> Un double trait (épais puis fin) ne pose pas de problème de perf de
> calcul si il s'appuie sur le polygone d'origine de la réserver.
> Pour un effet dégradé vers l'intérieur, ça doit être possible en
> utilisant une texture pour le trait... à tester.
>
> Par contre, ce qui manque c'est le nom de la réserve...
>
> Le 7 juin 2013 16:45, Philippe Verdy  a écrit :
> > Réflexion faite je pense que les pointillés ici sont de trop et qu'on
> > verrais bien malgré tout une ligne verte épaisse de bordure, même si elle
> > est semi-transparente. On peut le rendre assez discrète en rendant le
> bord
> > avec une ligne fine moins transparente, en la traçant par dessus une
> autre
> > ligne plus épaisse également semi-transparente (pour créer un effet
> d'ombre
> > verte qui s'atténue vers le centre de la zone, mais est plus contrasté
> sur
> > le bord le plus externe).
> >
> > Ceci permettrait même alors d'éviter de remplir la zone avec une texture
> > quelconque (donc suppression même du "RN") grâce à ce pourtour ombré
> épais
> > mais atténué progressivement vers l'intérieur. tout dépend alors de la
> > complexité du calcul des buffers multiples (problème de performance à
> voir
> > selon le nombre de polygones à créer pour les lignes vertes épaisses de
> > contour et de transparence croissante vers l'intérieur)
> >
> >
> >
> > 2013/6/7 Yves Pratter 
> >>
> >> > Par exemple comme ça ?
> >> > http://cl.ly/image/2s000O3W3Z0B
> >> Ah oui, c'est effectivement plus sobre :-)
> >> ___
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> >
>
>
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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 et réserves naturelles

[Philippe Verdy]

Je n'aime pas trop les hachures, on va retomber dans le même cas où cela
cache top de détails.

Les réserves naturelles sont souvent assez grandes pour que l'on n'ait
besoin que de bien voir leur contour.

C'est pour ça que je penche plutôt vers une contour vert continu
semi-transparent, mais assez épais pour qu'ont le voit, pas trop pour ne
pas remplir toute la zone, et utilisant un effet d'ombrage.

Même les petits points du texturage actuel sont de trop (mais s'il ne
restait qu'eux ça passerait peut-être). A mon avis les frontières suffisent.

Le libellé ajouté au milieu de la zone devra être aussi en vert de la même
couleur que la bordure, il remplacera totalement les "NR" de la texture
actuelle.

Attention aussi aux libellés qui apparaissent et disparaissent de façon
aléatoire (exemple aux îles Glénan, sud du Finistère, pour une toute petite
réserve naturelle au milieu d'une petite île, dont le long libellé apparait
à un niveau de zoom et disparait ensuite, mais recouvre en fain de compte
tout l'archipel et même au delà, nous privant du nom de l'archipel lui-même
ou des îles principales). Le nom de la réserve n'apparait plus ensuite du
tout quand on a zoomé sur la bonne île, bref on ne sait pas où est
réellement cette réserve biologique (créée pour protéger une plante).




Le 7 juin 2013 16:51, JB  a écrit :

> **
>
> Mouaif, je vais encore faire mon rabat-joie, en fin de discussion, en plus…
>
> Pour moi, RN en vert n'évoque pas grand chose, à part pour me dire que ça
> doit pas être une route nationale.
>
> Et avec ça, j'ai pas grand chose à proposer, en plus. Voilà comment c'est
> géré dans R25… faute de mieux… Pour de la carte web, je pense que
> j'essayerais plutôt un hachurage diagonal vert.
>
> JB.
>
> Le 07.06.2013 16:34, Philippe Verdy a écrit :
>
> OK la disposition en triangles plutôt qu'en carré convient bien. c'est
> assez léger et ne cache plus trop de détails. On voit encore assez de "RN"
> pour savoir où on est.
>
>
> Le 7 juin 2013 16:09, Christian Quest  a écrit :
>
>> Le 7 juin 2013 12:52, Philippe Verdy  a écrit :
>> > === 1. maillage pour les "RN" ===
>> >
>> > Avec une disposition à mailles carrées orientées à 30 ou 60 degrés on a
>> > encore des textures régulières disposables en pavés rectangulaires.
>> c'est
>> > souvent un angle pratique pour éviter cet aspect trop mécanique.
>> >
>>
>> Par exemple comme ça ?
>>
>> http://cl.ly/image/2s000O3W3Z0B
>>
>> RN au lien de NR, plus espacé et en quinconce, pourtour plus épais et
>> en pointillé...
>>
>> C'est quand même plus "light" que
>>
>> http://tile.openstreetmap.fr/?zoom=13&lat=47.2844&lon=-2.4595&layers=B0F
>>
>> --
>> Christian Quest - OpenStreetMap France
>> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttp://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 et réserves naturelles

[Christian Quest]

Le problème c'est dans quelle couche traiter la frontière.
Elle risque d'être masquée par pas mal de routes, d'où na nécessité de
la texture des "RN".

Un double trait (épais puis fin) ne pose pas de problème de perf de
calcul si il s'appuie sur le polygone d'origine de la réserver.
Pour un effet dégradé vers l'intérieur, ça doit être possible en
utilisant une texture pour le trait... à tester.

Par contre, ce qui manque c'est le nom de la réserve...

Le 7 juin 2013 16:45, Philippe Verdy  a écrit :
> Réflexion faite je pense que les pointillés ici sont de trop et qu'on
> verrais bien malgré tout une ligne verte épaisse de bordure, même si elle
> est semi-transparente. On peut le rendre assez discrète en rendant le bord
> avec une ligne fine moins transparente, en la traçant par dessus une autre
> ligne plus épaisse également semi-transparente (pour créer un effet d'ombre
> verte qui s'atténue vers le centre de la zone, mais est plus contrasté sur
> le bord le plus externe).
>
> Ceci permettrait même alors d'éviter de remplir la zone avec une texture
> quelconque (donc suppression même du "RN") grâce à ce pourtour ombré épais
> mais atténué progressivement vers l'intérieur. tout dépend alors de la
> complexité du calcul des buffers multiples (problème de performance à voir
> selon le nombre de polygones à créer pour les lignes vertes épaisses de
> contour et de transparence croissante vers l'intérieur)
>
>
>
> 2013/6/7 Yves Pratter 
>>
>> > Par exemple comme ça ?
>> > http://cl.ly/image/2s000O3W3Z0B
>> Ah oui, c'est effectivement plus sobre :-)
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[JB]

 

Mouaif, je vais encore faire mon rabat-joie, en fin de discussion,
en plus… 

Pour moi, RN en vert n'évoque pas grand chose, à part pour me
dire que ça doit pas être une route nationale. 

Et avec ça, j'ai pas
grand chose à proposer, en plus. Voilà comment c'est géré dans R25…
faute de mieux… Pour de la carte web, je pense que j'essayerais plutôt
un hachurage diagonal vert. 

JB. 

Le 07.06.2013 16:34, Philippe Verdy
a écrit : 

> OK la disposition en triangles plutôt qu'en carré convient
bien. c'est assez léger et ne cache plus trop de détails. On voit encore
assez de "RN" pour savoir où on est. 
> 
> Le 7 juin 2013 16:09,
Christian Quest  a écrit :
> 
>> Le 7 juin 2013
12:52, Philippe Verdy  a écrit :
>> 
>>> === 1.
maillage pour les "RN" ===
>> >
>> > Avec une disposition à mailles
carrées orientées à 30 ou 60 degrés on a
>> > encore des textures
régulières disposables en pavés rectangulaires. c'est
>> > souvent un
angle pratique pour éviter cet aspect trop mécanique.
>> >
>> 
>> Par
exemple comme ça ?
>> 
>> http://cl.ly/image/2s000O3W3Z0B [1]
>> 
>> RN
au lien de NR, plus espacé et en quinconce, pourtour plus épais et
>> en
pointillé...
>> 
>> C'est quand même plus "light" que
>>
http://tile.openstreetmap.fr/?zoom=13&lat=47.2844&lon=-2.4595&layers=B0F
[2]
>> 
>> --
>> Christian Quest - OpenStreetMap France
>> Un nouveau
serveur pour OSM... http://donate.osm.org/server2013/ [3]
> 
>
___
> Talk-fr mailing list
>
Talk-fr@openstreetmap.org
>
http://lists.openstreetmap.org/listinfo/talk-fr [4]




Links:
--
[1] http://cl.ly/image/2s000O3W3Z0B
[2]
http://tile.openstreetmap.fr/?zoom=13&lat=47.2844&lon=-2.4595&layers=B0F
[3]
http://donate.osm.org/server2013/
[4]
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 et réserves naturelles

[Philippe Verdy]

Réflexion faite je pense que les pointillés ici sont de trop et qu'on
verrais bien malgré tout une ligne verte épaisse de bordure, même si elle
est semi-transparente. On peut le rendre assez discrète en rendant le bord
avec une ligne fine moins transparente, en la traçant par dessus une autre
ligne plus épaisse également semi-transparente (pour créer un effet d'ombre
verte qui s'atténue vers le centre de la zone, mais est plus contrasté sur
le bord le plus externe).

Ceci permettrait même alors d'éviter de remplir la zone avec une texture
quelconque (donc suppression même du "RN") grâce à ce pourtour ombré épais
mais atténué progressivement vers l'intérieur. tout dépend alors de la
complexité du calcul des buffers multiples (problème de performance à voir
selon le nombre de polygones à créer pour les lignes vertes épaisses de
contour et de transparence croissante vers l'intérieur)



2013/6/7 Yves Pratter 

> > Par exemple comme ça ?
> > http://cl.ly/image/2s000O3W3Z0B
> Ah oui, c'est effectivement plus sobre :-)
> ___
> 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 et réserves naturelles

[Yves Pratter]

> Par exemple comme ça ?
> http://cl.ly/image/2s000O3W3Z0B
Ah oui, c'est effectivement plus sobre :-)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

OK la disposition en triangles plutôt qu'en carré convient bien. c'est
assez léger et ne cache plus trop de détails. On voit encore assez de "RN"
pour savoir où on est.


Le 7 juin 2013 16:09, Christian Quest  a écrit :

> Le 7 juin 2013 12:52, Philippe Verdy  a écrit :
> > === 1. maillage pour les "RN" ===
> >
> > Avec une disposition à mailles carrées orientées à 30 ou 60 degrés on a
> > encore des textures régulières disposables en pavés rectangulaires. c'est
> > souvent un angle pratique pour éviter cet aspect trop mécanique.
> >
>
> Par exemple comme ça ?
>
> http://cl.ly/image/2s000O3W3Z0B
>
> RN au lien de NR, plus espacé et en quinconce, pourtour plus épais et
> en pointillé...
>
> C'est quand même plus "light" que
>
> http://tile.openstreetmap.fr/?zoom=13&lat=47.2844&lon=-2.4595&layers=B0F
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Christian Quest]

Le 7 juin 2013 12:52, Philippe Verdy  a écrit :
> === 1. maillage pour les "RN" ===
>
> Avec une disposition à mailles carrées orientées à 30 ou 60 degrés on a
> encore des textures régulières disposables en pavés rectangulaires. c'est
> souvent un angle pratique pour éviter cet aspect trop mécanique.
>

Par exemple comme ça ?

http://cl.ly/image/2s000O3W3Z0B

RN au lien de NR, plus espacé et en quinconce, pourtour plus épais et
en pointillé...

C'est quand même plus "light" que
http://tile.openstreetmap.fr/?zoom=13&lat=47.2844&lon=-2.4595&layers=B0F

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

TL;DR (intéresse ceux qui travaillent sur un rendu) Plusieurs points :

=== 1. maillage pour les "RN" ===

Avec une disposition à mailles carrées orientées à 30 ou 60 degrés on a
encore des textures régulières disposables en pavés rectangulaires. c'est
souvent un angle pratique pour éviter cet aspect trop mécanique.

== 2. Polices de caractères ==

Autre reproche à faire dans le rendu fr : déjà les polices sont toutes
petites, mais en plus les libellés sont pour la plupart en italique. C'est
très peu lisible à la résolution utilisée, même avec un rendu anticrénelage
du texte, utilisant des pixels à niveau de transparence variable. Pour nos
yeux, ce serait bien de soit éviter les italiques (qui ont tendance à
condenser horizontalement les textes), soit agrandir un peu les libellés
qui sont pratiquement tous trop petits.

Ne réserver les italiques que pour les lieux-dits, ou les régions peu
géolocalisées (qui devraient s'afficher avec des lettres assez grandes mais
transparentes et plus dans des polices plus grasses), pas pour les libellés
de points. Pour les fleuves et rivières, les libellés en italique marchent
bien car on peut zoomer pour les voir en plus grand et sinon ils
disparaissent.

Mais pour les noms de communes (niveau 8), même si ils sont dans des
polices de taille variable en fonction du type (capitale/chef-lieu
administratif ou population ou classification
place=city/town/village/hamlet/locality, c'est le rendu qui adapte les
tailles), ce serait bien d'éviter les italiques totalement. Et n'utiliser
les italiques que pour le niveau 9 ou plus.

== 3. Densification des toponymes visibles et autoadaptation selon le zoom
==

Enfin il faudrait faire quelque chose pour densifier le nombre de libellés
de communes visibles dans les faibles niveaux de zoom. L'idée est de faire
une sélection de tous les libellés et classer ces noms dans une liste de
priorité à plusieurs critères :
- le premier niveau de tri de cette liste plus important est le niveau
administratif dont la commune est le chef-lieu/la capitale.
- le deuxième niveau est la classification
(city/tow/village/hamlet/locality)
- le troisième, optionnel, est la population indiquée

Ensuite le rendu affiche les libellés dans l'ordre de la liste, en les
sautant si cela génère des recouvrements ou si un critère de densité
maximal est atteint. Pour éviter des recouvrements, le rendu calcule des
bounding box pour chacun et les combine en vérifiant que le libellé suivant
ne vient pas empiéter dedans (l'algo pourra parfois chercher à les abréger
en cas de besoin pour les faire tenir s'ils y a des collisions en utilisant
le libellé non abrégé, comme il sait le faire pour des termes communs comme
"Rue" => "R.", "Boulevard" => "Bd").

Selon le niveau de zoom, ces libellés doivent aussi n'apparaître que le
long de la frontière (si la surface incluse dans la frontière est assez
grande, sinon uniquement au "centre" de la zone (qui est soit la position
du membre "label" de la relation, sinon la position de son membre
"admin_centre", si c'est un noeud, soit le centroïde calculé de son membre
"admin_centre" si c'est une surface (ce cas ne semble pas arriver encore en
France mais existe dans d'autre pays), sinon le centroïde calculé de la
surface. Selon la méthode ou l'autre (le long de la frontière ou uniquement
centré dans la zone), les tailles de polices doivent être adaptées (le cas
du rendu centré autorise le libellé à déborder largement de sa zone,
d'autant plus si le libellé est "important", c'est-à-dire mieux classé dans
la liste triée précédente, car il aura une police plus grande qu'un libellé
le long d'une frontière, qui doit malgré tout rester lisible aussi avec une
taille minimale suffisante).

Mais Mapnik permet-il d'inclure un tel algorithme (qui fonctionne pas à pas
et non de façon globale sur une liste d'objets présélectionnés et rendus en
totalité) ? En SQL on peut générer le tri (avec une requête certes
compliquée à faire pour aller chercher les infos sur les statuts de
chef-lieu/capitale car l'info est à chercher dans d'autres objets; au pire
si le premier niveau est difficile à calculer on peut en SQL le supprimer,
mais ce ne sera pas idéal), mais Mapnik peut-il sélectivement "sauter"
certains éléments de cette liste triée?

En attendant je me désespère de voir les cartes à faible niveaux de zoom
aussi vides d'informations utiles, particulièrement en France ou dans les
pays avec de larges espaces ruraux (c'est moins un problème pour
l'Allemagne, la Belgique ou le Royaume-Uni, ou même l'Espagne, qui sont
moins concernés que la France, le Canada, et bon nombre de pays africains).

L'algo (très sommaire, je ne code pas pour Mapnik) que je propose est
suffisamment adaptatif pour pouvoir avoir une densité suffisante mais pas
excessive, permettant de garder des cartes utilisables à tous les niveaux
de zoom, et pour rester aussi consistant (Un libellé visible au niveau de
zoom N le sera aux niveaux N+1, N+2, etc... au moins sur les frontières
s'il d

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Yves Pratter]

> Des RN, mais moins denses... ça doit aller mieux non ?
Ok, mais alors nettement moins dense, avec une teinte plus transparente, et 
disposé si possible en quinconce pour donner un aspect moins "mécanique".
Faire un essai avec un angle un peu différent au texte de la texture ??

Il n'y a pas des graphistes / designers sur cette liste ?

De plus il faudrait les écrire en bleu pour les zones d'eau.
Ok pour le vert pour les zones Verdy ;-)


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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Yohan Boniface]

Et un "Réserve naturelle" le long de son contour, comme tu as fait pour 
les limites administratives?



On 06/07/2013 10:42 AM, Christian Quest wrote:

Des RN, mais moins denses... ça doit aller mieux non ?


Le 7 juin 2013 10:38, Yves Pratter mailto:yves.prat...@laposte.net>> a écrit :


Le 6 juin 2013 à 10:49, Christian Quest mailto:cqu...@openstreetmap.fr>> a écrit :


Passer de NR à RN me semble le plus simple et efficace en attendant
éventuellement mieux…

Je trouve que ça rend vraiment la carte illisible…
Trop d'info tue l'info ?



Je pense qu'il ne faut rien mettre (ou alors une teinte un peu
différente).
D'autant plus qu'il est assez facile de faire apparaitre des infos
au-dessus du fond de carte, tels que le contour de la réserve.


L'IGN ne modifie pas sa texture. Seul un libellé "Réserve naturelle"
est affichée par dessus la zone.



--
Yves

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




--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/


___
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 et réserves naturelles

[Christian Quest]

Des RN, mais moins denses... ça doit aller mieux non ?


Le 7 juin 2013 10:38, Yves Pratter  a écrit :

>
> Le 6 juin 2013 à 10:49, Christian Quest  a écrit
> :
>
> Passer de NR à RN me semble le plus simple et efficace en attendant
> éventuellement mieux…
>
> Je trouve que ça rend vraiment la carte illisible…
> Trop d'info tue l'info ?
>
> 
>
> Je pense qu'il ne faut rien mettre (ou alors une teinte un peu différente).
> D'autant plus qu'il est assez facile de faire apparaitre des infos
> au-dessus du fond de carte, tels que le contour de la réserve.
>
>
> L'IGN ne modifie pas sa texture. Seul un libellé "Réserve naturelle" est
> affichée par dessus la zone.
>  
> 
>
> --
> Yves
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
<><>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Yves Pratter]

Le 6 juin 2013 à 10:49, Christian Quest  a écrit :Passer de NR à RN me semble le plus simple et efficace en attendantéventuellement mieux…Je trouve que ça rend vraiment la carte illisible…Trop d'info tue l'info ?Je pense qu'il ne faut rien mettre (ou alors une teinte un peu différente).D'autant plus qu'il est assez facile de faire apparaitre des infos au-dessus du fond de carte, tels que le contour de la réserve.L'IGN ne modifie pas sa texture. Seul un libellé "Réserve naturelle" est affichée par dessus la zone. --Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Philippe Verdy]

Est-on réellement obligé de remplir la zone de réserve naturelle, quand une
bordure verte peut suffire, avec à l'intérieur peut-être juste un fond
verdâtre semi-transparent, ou un très fin hachurage ou texturage vert assez
discret (et toujours semi-transparent avec beaucoup de vide totalement
transparent, ce texturage ne devait pas couvrir plus d'un cinquième des
pixels dans chacun des deux axes, donc moins de 5% en terme de surface non
totalement transparent) pour ne pas cacher les détails ?


Le 6 juin 2013 10:49, Christian Quest  a écrit :

> Mapnik fait ce qu'on lui dit ;)
>
> C'est effectivement avec le tag operator qu'il sera le plus simple
> d'appliquer un rendu différent que de prendre en compte des limites
> géographiques bien complexes à manier (et lentes).
>
> Pour ce symbole, c'est la première fois que je le vois et jamais je
> n'aurai imaginé qu'il représentait une réserve naturelle.
>
> Passer de NR à RN me semble le plus simple et efficace en attendant
> éventuellement mieux...
>
>
> Le 6 juin 2013 10:42, Jean-Marc Liotier  a écrit :
> > On 06/06/2013 10:38, Damouns wrote:
> >>
> >> Le 6 juin 2013 10:25, Jean-Marc Liotier  a écrit :
> >>>
> >>> Idéogramme d'identification des réserves naturelles en France, d'après
> >>> l'arrêté du 24 novembre 1967 modifié:
> >>>
> http://commons.wikimedia.org/wiki/File:ID15c_reserve_naturelle_France.svg
> >>
> >> Oui mais il y a le problème des autres pays qui se retrouveraient avec
> >> ce logo alors que ce n'est pas le leur !
> >
> >
> > Ce serait approprié pour le rendu osm-fr (évidemment dans les limites des
> > frontières de la République Française - le 'NR' continuerait à être
> utilisé
> > ailleurs... Mapnik sait faire ça ?)
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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 et réserves naturelles

[Christian Quest]

Mapnik fait ce qu'on lui dit ;)

C'est effectivement avec le tag operator qu'il sera le plus simple
d'appliquer un rendu différent que de prendre en compte des limites
géographiques bien complexes à manier (et lentes).

Pour ce symbole, c'est la première fois que je le vois et jamais je
n'aurai imaginé qu'il représentait une réserve naturelle.

Passer de NR à RN me semble le plus simple et efficace en attendant
éventuellement mieux...


Le 6 juin 2013 10:42, Jean-Marc Liotier  a écrit :
> On 06/06/2013 10:38, Damouns wrote:
>>
>> Le 6 juin 2013 10:25, Jean-Marc Liotier  a écrit :
>>>
>>> Idéogramme d'identification des réserves naturelles en France, d'après
>>> l'arrêté du 24 novembre 1967 modifié:
>>> http://commons.wikimedia.org/wiki/File:ID15c_reserve_naturelle_France.svg
>>
>> Oui mais il y a le problème des autres pays qui se retrouveraient avec
>> ce logo alors que ce n'est pas le leur !
>
>
> Ce serait approprié pour le rendu osm-fr (évidemment dans les limites des
> frontières de la République Française - le 'NR' continuerait à être utilisé
> ailleurs... Mapnik sait faire ça ?)
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Jean-Marc Liotier]

On 06/06/2013 10:38, Damouns wrote:

Le 6 juin 2013 10:25, Jean-Marc Liotier  a écrit :

Idéogramme d'identification des réserves naturelles en France, d'après l'arrêté 
du 24 novembre 1967 modifié:
http://commons.wikimedia.org/wiki/File:ID15c_reserve_naturelle_France.svg

Oui mais il y a le problème des autres pays qui se retrouveraient avec
ce logo alors que ce n'est pas le leur !


Ce serait approprié pour le rendu osm-fr (évidemment dans les limites 
des frontières de la République Française - le 'NR' continuerait à être 
utilisé ailleurs... Mapnik sait faire ça ?)


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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Damouns]

Le 6 juin 2013 10:25, Jean-Marc Liotier  a écrit :
> Idéogramme d'identification des réserves naturelles en France, d'après
> l'arrêté du 24 novembre 1967 modifié:
> http://commons.wikimedia.org/wiki/File:ID15c_reserve_naturelle_France.svg

Oui mais il y a le problème des autres pays qui se retrouveraient avec
ce logo alors que ce n'est pas le leur !

C'est plus un logo d'operator qu'un logo générique.

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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Jean-Marc Liotier]

On 06/06/2013 10:07, Damouns wrote:

Une question sur la "francisation" des symboles : les réserves
naturelles ont le symbole "NR" (pour nature reserve ?), ce serait bien
de mettre au moins RN pour réserve naturelle (mais risque de confusion
avec Repère de Nivellement qui est indiqué comme ça sur les cartes
IGN) ou alors encore mieux de réfléchir à une symbolisation française
différente.


Idéogramme d'identification des réserves naturelles en France, d'après 
l'arrêté du 24 novembre 1967 modifié: 
http://commons.wikimedia.org/wiki/File:ID15c_reserve_naturelle_France.svg


Reste à savoir si cet idéogramme est suffisamment reconnu par les 
utilisateurs pour que son utilisation cartographique soit appropriée.



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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[Ab_fab]

En particulier si cela peut clarifier l'affichage, comme par exemple pour
les zones de marais :
http://tile.openstreetmap.fr/?zoom=13&lat=47.37647&lon=-2.23916&layers=B0F


Le 6 juin 2013 10:07, Damouns  a écrit :

> Je suis en admiration complète du rendu OSM France qui est vraiment
> chouette !
>
> Une question sur la "francisation" des symboles : les réserves
> naturelles ont le symbole "NR" (pour nature reserve ?), ce serait bien
> de mettre au moins RN pour réserve naturelle (mais risque de confusion
> avec Repère de Nivellement qui est indiqué comme ça sur les cartes
> IGN) ou alors encore mieux de réfléchir à une symbolisation française
> différente.
>
> Voire un rendu qui prend en compte les tags boundary=protected_area et
> leurs classes, qui viennent en France de l'INPN :
>
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN
>
> Qu'en pensez-vous ?
>
> Damouns
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



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

[OSM-talk-fr] rendu osm-fr et réserves naturelles

[Damouns]

Je suis en admiration complète du rendu OSM France qui est vraiment chouette !

Une question sur la "francisation" des symboles : les réserves
naturelles ont le symbole "NR" (pour nature reserve ?), ce serait bien
de mettre au moins RN pour réserve naturelle (mais risque de confusion
avec Repère de Nivellement qui est indiqué comme ça sur les cartes
IGN) ou alors encore mieux de réfléchir à une symbolisation française
différente.

Voire un rendu qui prend en compte les tags boundary=protected_area et
leurs classes, qui viennent en France de l'INPN :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN

Qu'en pensez-vous ?

Damouns

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