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
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
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=14lat=47.09695lon=-1.67263layers=B0F
On se demande bien
Même cas de figure dans la baie de l'Aiguillon :
http://tile.openstreetmap.fr/?zoom=13lat=46.27507lon=-1.15953layers=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).
L'avantage de rendre les données visibles... on voit mieux les défauts ;)
Le 10 juin 2013 15:22, Ab_fab gamma@gmail.com a écrit :
Même cas de figure dans la baie de l'Aiguillon :
http://tile.openstreetmap.fr/?zoom=13lat=46.27507lon=-1.15953layers=B0F
Pas d'explication, si ce n'est
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=13lat=47.29383lon=-2.44937layers=B0F
--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM...
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 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
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 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 à
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 cqu...@openstreetmap.fr a écrit :
Voilà la dernière évolution du rendu des
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
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 ;)
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
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
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=13lat=47.29383lon=-2.44937layers=B0F
J'aime beaucoup !
Merci !
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
http://tile.openstreetmap.fr/?zoom=11lat=47.61458lon=-3.39151layers=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
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
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
Même constat:
http://tile.openstreetmap.fr/?zoom=17lat=48.10082lon=-1.67405layers=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
Je ne pense pas que changer les épaisseurs ne soient viable. Il me semble
que c'est lalgo 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
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
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
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
Le 9 juin 2013 10:31, Christian Quest 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=13lat=47.29383lon=-2.44937layers=B0F
Le 9 juin 2013 17:14, Philippe Verdy verd...@wanadoo.fr 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
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
Le 9 juin 2013 18:26, Philippe Verdy verd...@wanadoo.fr 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
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
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
Nouvelle mouture:
http://tile.openstreetmap.fr/?zoom=11lat=47.42028lon=-2.41356layers=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
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
Le 6 juin 2013 à 10:49, Christian Quest 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
Des RN, mais moins denses... ça doit aller mieux non ?
Le 7 juin 2013 10:38, Yves Pratter yves.prat...@laposte.net a écrit :
Le 6 juin 2013 à 10:49, Christian Quest cqu...@openstreetmap.fr a écrit
:
Passer de NR à RN me semble le plus simple et efficace en attendant
éventuellement mieux…
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 yves.prat...@laposte.net
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
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
Le 7 juin 2013 12:52, Philippe Verdy verd...@wanadoo.fr 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
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 cqu...@openstreetmap.fr a écrit :
Le 7 juin 2013 12:52, Philippe Verdy verd...@wanadoo.fr
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
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
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…
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
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
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
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 trs souvent en zone RAMSAR
Christian tu propose donc qu' un certain niveau de zone de rendre
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
Le 7 juin 2013 17:06, Philippe Verdy verd...@wanadoo.fr 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
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
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
Le 7 juin 2013 18:40, Philippe Verdy verd...@wanadoo.fr 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
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
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 cqu...@openstreetmap.fr a écrit :
Le 7 juin 2013 18:40, Philippe Verdy
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
En particulier si cela peut clarifier l'affichage, comme par exemple pour
les zones de marais :
http://tile.openstreetmap.fr/?zoom=13lat=47.37647lon=-2.23916layers=B0F
Le 6 juin 2013 10:07, Damouns damo...@gmail.com a écrit :
Je suis en admiration complète du rendu OSM France qui est
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
Le 6 juin 2013 10:25, Jean-Marc Liotier j...@liotier.org 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
On 06/06/2013 10:38, Damouns wrote:
Le 6 juin 2013 10:25, Jean-Marc Liotier j...@liotier.org 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
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
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
59 matches
Mail list logo
