Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[osm . sanspourriel]

En dézoomant l'exemple de ligne droite abusivement arrondie je suis 
tombé sur :


http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#15/47.8461/-3.5068

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#16/47.8461/-3.5068

Curieusement c'est au zoom 15 que l'icône indiquant un accès privé est 
plus grand.


Aux niveaux 16 à 20 
 
c'est de l'ordre de la patte de mouche.


S'il faut mettre une patte de mouche c'est plutôt à mon avis aux bas 
niveaux de zoom.


Au niveau 15 on peut aussi voir des accès interdits à des routes trop 
mineures pour être affichées (en osm.org les accès ne sont pas affichés 
au niveau 15 donc le cas des voies de service ne se pose pas).


Je pense qu'il ne faut pas afficher de symboles relatifs à des objets 
que l'on n'affiche pas à ce niveau de zoom.
Je sais, sans doute plus facile à dire qu'à faire sauf à n'afficher les 
restriction qu'au niveau 16.

Jean-Yvon

Le 06/11/2016 à 20:12, David Crochet - david.croc...@free.fr a écrit :

Bonjour


Le 06/11/2016 à 19:51, Stéphane Péneau a écrit :

Ah bon ? Pourtant je ne les vois pas :
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#17/47.06739/-1.37014 



Il ne sont pas rendu comme le rendu traditionnel. Logique puisque 
natural=tree_row ne doit être que chemin, pas noeud, ni surface.


Cordialement



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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Stéphane Péneau]

Bien vu !

Et effectivement, sur des ways c'est bien rendu.

Étant donné la description de tree_row, que j'avais un peu oubliée, je 
vais revoir ma façon de tagger ces zones.


Stf

Le 06/11/2016 à 20:12, David Crochet a écrit :

Bonjour


Le 06/11/2016 à 19:51, Stéphane Péneau a écrit :

Ah bon ? Pourtant je ne les vois pas :
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#17/47.06739/-1.37014 



Il ne sont pas rendu comme le rendu traditionnel. Logique puisque 
natural=tree_row ne doit être que chemin, pas noeud, ni surface.


Cordialement




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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[David Crochet]

Bonjour


Le 06/11/2016 à 19:51, Stéphane Péneau a écrit :

Ah bon ? Pourtant je ne les vois pas :
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#17/47.06739/-1.37014


Il ne sont pas rendu comme le rendu traditionnel. Logique puisque 
natural=tree_row ne doit être que chemin, pas noeud, ni surface.


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Stéphane Péneau]

Ah bon ? Pourtant je ne les vois pas :
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#17/47.06739/-1.37014


Le 06/11/2016 à 18:47, Christian Quest a écrit :

Bizarre ça... je l'avais ajouté avec les natural=tree


Le 05/11/2016 à 20:29, Stéphane Péneau a écrit :

Ah tiens ! natural=tree_row n'est pas rendu.
Je pense que ça serait pas mal, et je ne dis pas ça parce que j'en ai 
ajouté dernièrement :-)
Je crois que reprendre le rendu de natural=wood, pourrait tout à fait 
convenir dans un premier temps.


Stf





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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Quest]

Bizarre ça... je l'avais ajouté avec les natural=tree


Le 05/11/2016 à 20:29, Stéphane Péneau a écrit :

Ah tiens ! natural=tree_row n'est pas rendu.
Je pense que ça serait pas mal, et je ne dis pas ça parce que j'en ai 
ajouté dernièrement :-)
Je crois que reprendre le rendu de natural=wood, pourrait tout à fait 
convenir dans un premier temps.


Stf


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Stéphane Péneau]

Ah tiens ! natural=tree_row n'est pas rendu.
Je pense que ça serait pas mal, et je ne dis pas ça parce que j'en ai 
ajouté dernièrement :-)
Je crois que reprendre le rendu de natural=wood, pourrait tout à fait 
convenir dans un premier temps.


Stf

Le 03/11/2016 à 09:34, Christian Quest a écrit :
A améliorer, mais bon, il n'y a pas de régression, c'est plutôt à ça 
que je pense.


Si il n'y a pas de régression je peux passer le nouveau style en prod 
en remplacement de l'actuel... et ensuite on refait un cycle 
d'amélioration sur les réserves et sur les track.


Le 2 novembre 2016 à 23:47, > a écrit :



http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#10/47.4926/-2.9025




http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/47.6076/-2.7153




http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#10/48.3713/-4.8827



Je suis d'accord ça fait assez chargé.
Ici on voit un parc à trous (hameaux) jouxtant un autre.
Moins épais ? Ça risque d'être difficile de différencier les
intérieurs et les extérieurs.
Colorier le tout avec une transparence ? 20 % vert ? Pas terrible
avec la forêt à ne pas confondre.
Peut-être ne mettre qu'un symbole sur les petites zones ?

Au niveau 10, peut-être ne devrait-on mettre que le polygone
inscrit (ou une ellipse ?) pour simplifier le tracé.

Effectivement le style actuel de la fondation me fait, on peut
avoir des marques nautiques dessus tout en restant lisible :

http://map.openseamap.org/?zoom=12=BFTFFFTFFTF0FF=47.62805=-3.418


De même quand une forêt est partiellement protégée, ça se voit bien.

Jean-Yvon


Le 02/11/2016 à 16:53, althio - althio.fo...@gmail.com
 a écrit :

Salut,

Je ne trouve pas très esthétique le rendu pour les contours des
réserves naturelles à partir de zoom 10, pour les zooms 10-12.
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#10/45.5972/6.0500


http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#11/48.3834/2.7092



Suggestions ?
- un trait moins épais ?
- ne pas afficher les éléments trop petits ?
- simplifier le tracé ?

Benoît - althio

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


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


--
Christian Quest - OpenStreetMap France

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


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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Quest]

A améliorer, mais bon, il n'y a pas de régression, c'est plutôt à ça que je
pense.

Si il n'y a pas de régression je peux passer le nouveau style en prod en
remplacement de l'actuel... et ensuite on refait un cycle d'amélioration
sur les réserves et sur les track.

Le 2 novembre 2016 à 23:47,  a écrit :

> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 10/47.4926/-2.9025
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 13/47.6076/-2.7153
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 10/48.3713/-4.8827
>
> Je suis d'accord ça fait assez chargé.
> Ici on voit un parc à trous (hameaux) jouxtant un autre.
> Moins épais ? Ça risque d'être difficile de différencier les intérieurs et
> les extérieurs.
> Colorier le tout avec une transparence ? 20 % vert ? Pas terrible avec la
> forêt à ne pas confondre.
> Peut-être ne mettre qu'un symbole sur les petites zones ?
>
> Au niveau 10, peut-être ne devrait-on mettre que le polygone inscrit (ou
> une ellipse ?) pour simplifier le tracé.
>
> Effectivement le style actuel de la fondation me fait, on peut avoir des
> marques nautiques dessus tout en restant lisible :
> http://map.openseamap.org/?zoom=12=BFTFFFTFFTF0FF=47.
> 62805=-3.418
> De même quand une forêt est partiellement protégée, ça se voit bien.
>
> Jean-Yvon
>
>
> Le 02/11/2016 à 16:53, althio - althio.fo...@gmail.com a écrit :
>
> Salut,
>
> Je ne trouve pas très esthétique le rendu pour les contours des
> réserves naturelles à partir de zoom 10, pour les zooms 
> 10-12.http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#10/45.5972/6.0500http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#11/48.3834/2.7092
>
> Suggestions ?
> - un trait moins épais ?
> - ne pas afficher les éléments trop petits ?
> - simplifier le tracé ?
>
> Benoît - althio
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[osm . sanspourriel]

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#10/47.4926/-2.9025

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/47.6076/-2.7153

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#10/48.3713/-4.8827

Je suis d'accord ça fait assez chargé.
Ici on voit un parc à trous (hameaux) jouxtant un autre.
Moins épais ? Ça risque d'être difficile de différencier les intérieurs 
et les extérieurs.
Colorier le tout avec une transparence ? 20 % vert ? Pas terrible avec 
la forêt à ne pas confondre.

Peut-être ne mettre qu'un symbole sur les petites zones ?

Au niveau 10, peut-être ne devrait-on mettre que le polygone inscrit (ou 
une ellipse ?) pour simplifier le tracé.


Effectivement le style actuel de la fondation me fait, on peut avoir des 
marques nautiques dessus tout en restant lisible :

http://map.openseamap.org/?zoom=12=BFTFFFTFFTF0FF=47.62805=-3.418
De même quand une forêt est partiellement protégée, ça se voit bien.

Jean-Yvon

Le 02/11/2016 à 16:53, althio - althio.fo...@gmail.com a écrit :

Salut,

Je ne trouve pas très esthétique le rendu pour les contours des
réserves naturelles à partir de zoom 10, pour les zooms 10-12.
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#10/45.5972/6.0500
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#11/48.3834/2.7092

Suggestions ?
- un trait moins épais ?
- ne pas afficher les éléments trop petits ?
- simplifier le tracé ?

Benoît - althio

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


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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Je pense que pour les faibles zooms (10-11), il est surtout trop contrasté
et qu'un vert moins soutenu (plus transparent) serait préférable. Pour le
niveau 12 et plus (faisant apparaitre des parcs dont la taille est au moins
d'1 kilomètre sur une quarantaine de pixels au moins), ça marche
correctement.

Le 2 novembre 2016 à 16:53, althio  a écrit :

> Salut,
>
> Je ne trouve pas très esthétique le rendu pour les contours des
> réserves naturelles à partir de zoom 10, pour les zooms 10-12.
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 10/45.5972/6.0500
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 11/48.3834/2.7092
>
> Suggestions ?
> - un trait moins épais ?
> - ne pas afficher les éléments trop petits ?
> - simplifier le tracé ?
>
> Benoît - althio
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[althio]

Salut,

Je ne trouve pas très esthétique le rendu pour les contours des
réserves naturelles à partir de zoom 10, pour les zooms 10-12.
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#10/45.5972/6.0500
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#11/48.3834/2.7092

Suggestions ?
- un trait moins épais ?
- ne pas afficher les éléments trop petits ?
- simplifier le tracé ?

Benoît - althio

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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[JB]

J'en profite aussi : en milieu rural, la gradation des tracktypes sur 
highway=track est maintenant beaucoup plus cohérent sur osm.org que sur 
l'ancienne version que tu as utilisée comme base.

JB.

Le 02/11/2016 à 16:38, Stéphane Péneau a écrit :

Hello Christian,

Je rebondis sur ton message 
https://lists.openstreetmap.org/pipermail/talk-fr/2016-November/082467.html


A l'OPL de Montreuil, il était question de rendre le nom des communes 
nouvelles sans avoir besoin de node place. Tu as ajouté ce rendu ?


A+

Stéphane

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



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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Stéphane Péneau]

Hello Christian,

Je rebondis sur ton message 
https://lists.openstreetmap.org/pipermail/talk-fr/2016-November/082467.html


A l'OPL de Montreuil, il était question de rendre le nom des communes 
nouvelles sans avoir besoin de node place. Tu as ajouté ce rendu ?


A+

Stéphane

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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

A voir aussi les numéros de références des rues résidentielles : les
étiquettes sont affichées comme les noms de rue (le long de la rue et non
horizontalement et pas dans un cartouche), mais en plus gros caractères et
en gras. C'est tellement gros qu'on ne voit même plus les noms des rues,
quand il y en a, et que ça masque même tout le reste.

Exemple criant ici (à Lomé, Togo) :
http://osmose.openstreetmap.fr/fr/map/#zoom=14=6.17029=1.24857=Mapnik=T=6060=1%2C2%2C3==

(Notes : officiellement, toutes les rues n'ont pas de noms, mais toutes ont
des numéros de référence, utilisés aussi par défaut comme nom de rue après
le mot "Rue" ou "Impasse"; noter aussi que la rue sous le même nom peut
changer de numéro de référence selon le quartier codé en suffixe. Les
numéros de référence ne sont pas tous saisis dans OSM)

Certes ce n'est pas en France, mais en France cela survient aussi avec des
voies communales et chemins ruraux, qui là-aussi sont beaucoup mis en avant.

Peut-on suggérer pour les numéros de référence :
- la suppression du gras (à mon avis inutile : même pour les numéros des
autroutes/primaires/secondaires en cartouche, il n'y a pas de gras non plus)
- l'utilisation de la même taille de police que les noms (et non une plus
grande taille)
- avec juste une mise entre parenthèses et concaténation après le nom ?
Exemple "Rue d'Aheno (87AGK)". Si la place manque pour afficher le libellé
(selon le niveau de zoom), afficher le nom seul sinon la référence seule.

Pour les chemins carossables ou pas (track) on a des pointillés et les noms
sont affichés mais plus de numéro de référence du tout.

Pour les routes "motorway/trunk/primary/secondary" le numéro est affiché en
cartouche mais à des intervalles beaucoup moins fréquents que les rues
résidentielles.

Noter que dans cette ville toutes les rues peuvent avoir des sections
carrossables et d'autres non (sans pour autant changer de numéro de
référence). Ce cas existe aussi en France en périphérie de villages ruraux
(voies communales, chemins ruraux, chemins forestiers, voies sur berges ou
chemins de halage) ou dans des sections en chantier ou transformées en
espaces piétonniers. De nombreuses rues ne sont pas goudronnées, c'est du
sable ou de la terre compactée, parfois avec des arbustes qui poussent au
milieu et souvent des nids de poule.

Egalement une rue peut être discontinue, coupée en travers par des
constructions plus récentes ou une autre voie urbaine plus importante, et
pourtant conserver son numéro de référence et son nom.


Le 1 septembre 2016 à 09:14, Christian Quest  a
écrit :

> Pas mal de petites modifications sur le rendu FR sont en test.
>
> Vous pouvez voir où j'en suis sur http://umap.openstreetmap.fr/f
> r/map/test-rendu-osmfr_99740
>
> Quoi de neuf ?
>
> - de nouvelles icônes pour les commerces
>
> - des labels de taille et de couleur variant avec la taille du polygone
> qu'ils décrivent (texte en vert pour une forêt, plus gros si la forêt est
> grande, etc)
>
> - amélioration des frontières... les pointillés ne devraient plus se
> mélanger comme avant, les noms ne devraient plus être coupés en bord de
> metatile
>
> - harmonisation des largeurs de routes et réorganisation du tracé des
> layers 1-5
>
>
> Au delà de ces modifications visibles, il y a pas mal de nettoyage des
> fichiers de la feuille de style pour faciliter sa mise à jour. Quelques
> améliorations aussi sur les requêtes SQL (une bonne dizaine de requêtes de
> moins par exemple sur le tracé des 5 niveaux de layer).
>
> Bref, beaucoup de changements (le détail est sur
> https://github.com/cquest/osmfr-cartocss/commits/master) qui ont pu
> casser ici ou là des choses que je n'ai pas pu voir, donc si il y a des
> anomalies merci de les signaler avec l'URL sur cette carte umap (qui
> contient le zoom et les coordonnées).
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

le node label a un usage très limité: il est surtout là pour proposer un
positionnement mieux adapté dans une zone pas trop dense et éviter de
collisions ou débordements de longueur sur les entités voisines, afin de
laisser visible d'autres infos importantes (si les rendus ont de meilleures
solutions à proposer pour positionner les labels et éviter trop de
collisions, ils peuvent ignorer totalement ces labels). Cependant sur des
territoires à peu près convexes, il est souvent superflu de vouleur
s'éloigner de son centre géométrique par défaut.

C'est plus utile quand il y a de fortes concavités ou des exclaves
éloignées et que la plus grande n'est pas la plus communément référencée
(car nettement moins peuplée): cas des archipels.

Au delà de ça, le label ne sert pas à grand chose (même pas pour le nom qui
devrait rester pris en priorité depuis la relation qui l'inclue. ce label
reste malgré tout positionné de façon arbitraire "quelque part" dans la
zone, à vue de nez.

Et ce "label" ne doit pas être un noeud "place" (qui porte en général un
autre nom plus local, partagé par plusieurs relations qui l'utilisent comme
"admin_centre" représentatif, et qui joue aussi un rôle de substitut à la
surface décrite par la relation quand celle-ci n'est pas représentable à
une échelle donnée car trop petite pour permettre d'afficher les libellés
le long des frontières, et en principe on ne devrait pas avoir les deux
représetnation simultanées: noeuds label ou admin_centre et nom le long des
frontière, à un même niveau d'échelle, il faut choisir l'un ou l'autre)

Le 12 septembre 2016 à 20:32,  a écrit :

> Et pourquoi pas le meilleur des deux mondes ?
>
> Ajouter le node comme role=label dans la relation ?
>
> Le 12/09/2016 à 04:07, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> Les quartiers ( suburb, neighbourhood ) ne sont rendu que si ce sont des
> nodes et pas si le tag est sur une surface. Dans certains cas, ces
> quartiers sont bien délimités soit par la mairie soit dans la tête des
> habitants donc je pense que c'est une bonne chose les quartiers sur une
> surface.
>
> En lien avec ça, on a les arrondissements de paris et lyon qui sont
> représenter comme place=suburb sur un point et comme
> boundary=administrative sur une surface alors que c'est la même chose. ça
> serait logique de placer le tag place=suburb sur la relation boundary et de
> supprimer le node. Mais comme c'est pas rendu ça ne plaira pas à tout le
> monde :)
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Jérôme Amagat]

Mettre dans la relation le node avec le tag place=suburb comme role=label
pourquoi pas mais il y aura toujours 2 éléments pour définir la même chose.
et ce sera le label du boundary=administrative.
L'autre possibilité c'est de rajouté place=suburb sur la relation, de
supprimé tout les tags du node et mettre ce node comme role=label. Là il
n'y aura bien qu'1 élément pour l'arrondissement et 1 élément qui sert
juste pour placé le nom sur un rendu. Mais pour que ça servent à quelque
chose il faut que le rendu en est quelque chose a faire de ce place label.

Le 12 septembre 2016 à 20:32,  a écrit :

> Et pourquoi pas le meilleur des deux mondes ?
>
> Ajouter le node comme role=label dans la relation ?
>
> Le 12/09/2016 à 04:07, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> Les quartiers ( suburb, neighbourhood ) ne sont rendu que si ce sont des
> nodes et pas si le tag est sur une surface. Dans certains cas, ces
> quartiers sont bien délimités soit par la mairie soit dans la tête des
> habitants donc je pense que c'est une bonne chose les quartiers sur une
> surface.
>
> En lien avec ça, on a les arrondissements de paris et lyon qui sont
> représenter comme place=suburb sur un point et comme
> boundary=administrative sur une surface alors que c'est la même chose. ça
> serait logique de placer le tag place=suburb sur la relation boundary et de
> supprimer le node. Mais comme c'est pas rendu ça ne plaira pas à tout le
> monde :)
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[osm . sanspourriel]

Et pourquoi pas le meilleur des deux mondes ?

Ajouter le node comme role=label dans la relation ?


Le 12/09/2016 à 04:07, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
Les quartiers ( suburb, neighbourhood ) ne sont rendu que si ce sont 
des nodes et pas si le tag est sur une surface. Dans certains cas, ces 
quartiers sont bien délimités soit par la mairie soit dans la tête des 
habitants donc je pense que c'est une bonne chose les quartiers sur 
une surface.


En lien avec ça, on a les arrondissements de paris et lyon qui sont 
représenter comme place=suburb sur un point et comme 
boundary=administrative sur une surface alors que c'est la même chose. 
ça serait logique de placer le tag place=suburb sur la relation 
boundary et de supprimer le node. Mais comme c'est pas rendu ça ne 
plaira pas à tout le monde :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Jérôme Amagat]

Les quartiers ( suburb, neighbourhood ) ne sont rendu que si ce sont des
nodes et pas si le tag est sur une surface. Dans certains cas, ces
quartiers sont bien délimités soit par la mairie soit dans la tête des
habitants donc je pense que c'est une bonne chose les quartiers sur une
surface.

En lien avec ça, on a les arrondissements de paris et lyon qui sont
représenter comme place=suburb sur un point et comme
boundary=administrative sur une surface alors que c'est la même chose. ça
serait logique de placer le tag place=suburb sur la relation boundary et de
supprimer le node. Mais comme c'est pas rendu ça ne plaira pas à tout le
monde :)

Le 8 septembre 2016 à 11:02, lenny.libre  a écrit :

>
> Le 08/09/2016 à 09:45, Christian Quest a écrit :
>
>
> natural=cliff est rendu depuis toujours,
>
> En effet ; je suis désolé, je pensais avoir bien regardé tous les tags ...
>
> barrier=retaining_wall ou city_wall sont aussi rendus depuis longtemps:
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#19/48.55936/
> 2.71516
>
> La représentation graphique pourrait évoluer, peut etre par une sorte
> d'ombre sur le cote en bas ?
>
> Je m'étais peut-être mal exprimé, ce qui ne me semblait pas rendu, c'était
> la différence de niveau ; comme indiqué dans le wiki
> http://wiki.openstreetmap.org/wiki/FR:Tag:barrier%3Dcity_wall
>
>
> Pour les embankment là aussi il faut faire un choix graphique... si vous
> avez des idées ou propositions, je suis preneur !
>
> Je ne suis pas un bon dessinateur, ce qui est dans le wiki me convient
>
> léni
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[lenny.libre]

Le 08/09/2016 à 09:45, Christian Quest a écrit :


natural=cliff est rendu depuis toujours,

En effet ; je suis désolé, je pensais avoir bien regardé tous les tags ...

barrier=retaining_wall ou city_wall sont aussi rendus depuis 
longtemps: 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#19/48.55936/2.71516


La représentation graphique pourrait évoluer, peut etre par une sorte 
d'ombre sur le cote en bas ?
Je m'étais peut-être mal exprimé, ce qui ne me semblait pas rendu, 
c'était la différence de niveau ; comme indiqué dans le wiki 
http://wiki.openstreetmap.org/wiki/FR:Tag:barrier%3Dcity_wall


Pour les embankment là aussi il faut faire un choix graphique... si 
vous avez des idées ou propositions, je suis preneur !

Je ne suis pas un bon dessinateur, ce qui est dans le wiki me convient

léni

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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Autre anomalie, les plus grandes villes aux niveau 11 à 14 s'affichent avec
une police plus grande que les autres, voisines mais en style italique, qui
laisse plutôt penser au nom d'une autre entité (notamment des noms de
grands quartiers qui ont le même style et qu'on commence à voir au niveau
14).

Exemple (à Rennes et ses grands quartiers) :

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#14/48.1041/-1.6799

Je pense que cet italique sur les grandes villes aux niveau 11 à 14 n'est
pas nécessaire et que la police agrandie suffit pour mettre en avant ces
noms. Il crée une confusion visuelle inutile.

Aux niveaux inférieurs, il n'y a pas d'italique, seule la taille de police
joue (éventuellement) et on n'a que le gras pour les capitales nationales
(avec en plus une icône de point noir pour les grandes villes aux niveaux 7
et inférieurs). Ce gras est utile car on élimine pas mal de noms de ville
(je comprends pourquoi dans certains cas on n'a que l'icône du point noir
et pas le nom de ville au dessus quand il y a plusieurs villes candidates
ou un autre libellé plus prioritaire comme le nom du pays ou des grandes
régions)



Le 7 septembre 2016 à 21:33, Florian_G  a écrit :

> Bonsoir,
>
> Le 07/09/2016 à 08:44, Christian Quest a écrit :
> >
> > Zoom 8 à 10 en cours de recalcul...
> >
> >
> > Est-il possible de placer ensuite selon la population (en fonction
> > de la place) ?
> >
> >
> > C'est déjà le cas, tri sur le niveau admin, puis par population
> >
>
>
> Je ne sais pas si le rendu du niveau 6 est totalement à jour, mais on
> voit toujours à tort Jarny à la place de Metz :
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/48.203/5.219
>
> Ça fait un peu bizarre du coup. :-P
>
> --
> Florian_G
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[JB]

Le 08/09/2016 à 09:45, Christian Quest a écrit :
Pour les embankment là aussi il faut faire un choix graphique... si 
vous avez des idées ou propositions, je suis preneur !
Pour R25, je me suis inspiré du rendu de course d'orientation, qui est 
proche de ce qu'utilise l'IGN : 
http://jb.isonoe.net/CR/demo/l%C3%A9gende8.png quelque part au milieu. 
C'est décliné en levée de terre seule, cutting/embankment pour les 
routes, etc. (de mémoire assez laborieux pour aller bien pour chaque 
largeur de route, voie ferrée…)

JB.

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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Quest]

Le 7 septembre 2016 à 21:33, Florian_G  a écrit :

>
>
> Je ne sais pas si le rendu du niveau 6 est totalement à jour, mais on
> voit toujours à tort Jarny à la place de Metz :
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/48.203/5.219
>
> Ça fait un peu bizarre du coup. :-P
>
>
Sarrebruck a surement pris la place avant Metz...  qui a son petit point
noir, mais pas le nom, du coup il reste de la place pour Jarny...

Je vais essayer de rendre un peu flottants les noms.


natural=cliff est rendu depuis toujours, barrier=retaining_wall ou
city_wall sont aussi rendus depuis longtemps:
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#19/48.55936/2.71516

La représentation graphique pourrait évoluer, peut etre par une sorte
d'ombre sur le cote en bas ?

Pour les embankment là aussi il faut faire un choix graphique... si vous
avez des idées ou propositions, je suis preneur !

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Nicolas Dumoulin]

Bonjour,

Le Wed, 7 Sep 2016 19:18:27 +0200,
"lenny.libre"  a écrit :
>   * natural=cliff comme ce qui est décrit dans
> http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff#Rendering

Ça me semble déjà en place :
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#19/45.73734/3.04540

-- 
Nicolas Dumoulin


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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Florian_G]

Bonsoir,

Le 07/09/2016 à 08:44, Christian Quest a écrit :
> 
> Zoom 8 à 10 en cours de recalcul...
>  
> 
> Est-il possible de placer ensuite selon la population (en fonction
> de la place) ?
> 
> 
> C'est déjà le cas, tri sur le niveau admin, puis par population
> 


Je ne sais pas si le rendu du niveau 6 est totalement à jour, mais on
voit toujours à tort Jarny à la place de Metz :

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/48.203/5.219

Ça fait un peu bizarre du coup. :-P

-- 
Florian_G

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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[lenny.libre]

Bonsoir et merci pour toutes ces modifications.

Je voudrais bien en suggérer d’autres, concernant des éléments qui sont 
plus haut d'un côté que de l'autre :


 * le tag barrier=city_wall comme ce qui est décrit dans
   http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcity_wall
 * les talus : tag embankment=yes comme ce qui est décrit dans
   http://wiki.openstreetmap.org/wiki/Key:embankment ; c’est déjà fait
   pour man_made=embankment).
 * barrier=retaining_wall comme ce qui est décrit dans
   http://wiki.openstreetmap.org/wiki/FR:Tag:barrier%3Dretaining_wall
 * natural=cliff comme ce qui est décrit dans
   http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff#Rendering

Cordialement

léni

Le 03/09/2016 à 22:38, Christian Quest a écrit :

Les nouveautés du samedi...

- bug corrigé sur les ponts, et j'en ai profité pour ajouter le rendu 
des man_made=bridge ce qui permet de voir l'emprise des ponts, 
exemple: 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#18/48.85716/2.34108 



- l'ordre de priorité pour placer les noms dans les petites échelles 
(zoom 6 par exemple) est revu, et Vannes est bien au rendez-vous: 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/46.958/2.615 



- des icônes de commerces avaient disparu, elles sont de retour 
(contrôle technique, lavage auto, glaces, etc)


- icône pour les bornes de recharge de véhicules électriques: 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#17/47.85187/3.54325


ainsi que plein de petites bricoles...

Pour les côtes, je vais voir ce que je peux faire, en fait les limites 
administratives n'ont pas besoin d'être mises sur les côtes, mais 
encore faut-il pouvoir faire le tri ;)


--
Christian Quest - OpenStreetMap France


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


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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Ben non justement car on a deux arrondissements differents avec la sous
prefecture et la prefecture au meme endroit. On ne 0eut donc 0as dire
arrondissement de Cergy-Pontoise tant qu'ils n3 sont pas fusionnes. Et on
toujours deux communes non fusionnnées. L'ancienne agglomération nouvelle
(SAN) de Cergy-Pontoise n'existe plus non plus, remplacée par un autre EPCI
plus grand où chacune des deux communes est en fait plus a égalité. Ca
s'est compliqué avec en plus la création du Grand Paris et ses propres
subdivisions territoriales. Là on a un gros mille feuille administratif
fait de statuts transitoires et des nouveaux remplacant des anciens on ne
sait pas trop pourquoi et une organisation préfectorale en parallèle qui ne
suit plus et est plus ou moins obsolète u sein de l'État.

Le 7 sept. 2016 12:38, "Christian Rogel" 
a écrit :

>
>
> > Le 7 sept. 2016 à 02:43, Philippe Verdy  a écrit :
> >
> > Tu me sembles plutôt réécrire toi-même l'histoire pour l'interpréter. Tu
> parle de l'agglomération nouvelle qui n'est pas non plus une commune.
> >
> > La préfecture (située maintenant à Cergy) s'appelle officiellement
> "Préfecture du Val-d'Oise" (et non pas "Préfecture de Cercy-Pontoise" : je
> ne sais pas où tu as été chercher ça, c'est une invention).
>
> Tu as raison sur le côté officiel, mais, je voulais souligner que Pontoise
> n'est plus perçu comme sous-préfecture et que l'Agglomération nouvelle sous
> le nom de Cergy-Pontoise a été le moyen de "légitimer" la rétrogradation de
> Pontoise, lieu historique du pouvoir et longtemps bien plus peuplée que
> Cergy.
> Pendant plus de 30 ans, il n'était pas usuel de parler du lieu du pouvoir
> en séparant les deux noms.
> Depuis que Cergy a gagné en population, ce nom émerge seul et la
> sous-préfecture de Pontoise est une relique et les habitants ne le savent
> pas.
> Pour ce qui nous concerne, faire apparaître l'arrondissement sous le nom
> de Cergy-Pontoise concilierait l'Histoire et la réalité.
>
> Christian R.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Rogel]

> Le 7 sept. 2016 à 02:43, Philippe Verdy  a écrit :
> 
> Tu me sembles plutôt réécrire toi-même l'histoire pour l'interpréter. Tu 
> parle de l'agglomération nouvelle qui n'est pas non plus une commune.
> 
> La préfecture (située maintenant à Cergy) s'appelle officiellement 
> "Préfecture du Val-d'Oise" (et non pas "Préfecture de Cercy-Pontoise" : je ne 
> sais pas où tu as été chercher ça, c'est une invention). 

Tu as raison sur le côté officiel, mais, je voulais souligner que Pontoise 
n'est plus perçu comme sous-préfecture et que l'Agglomération nouvelle sous le 
nom de Cergy-Pontoise a été le moyen de "légitimer" la rétrogradation de 
Pontoise, lieu historique du pouvoir et longtemps bien plus peuplée que Cergy.
Pendant plus de 30 ans, il n'était pas usuel de parler du lieu du pouvoir en 
séparant les deux noms.
Depuis que Cergy a gagné en population, ce nom émerge seul et la 
sous-préfecture de Pontoise est une relique et les habitants ne le savent pas.
Pour ce qui nous concerne, faire apparaître l'arrondissement sous le nom de 
Cergy-Pontoise concilierait l'Histoire et la réalité.

Christian R.

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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Quest]

Le 7 septembre 2016 à 00:16,  a écrit :

> Je ne sais combien tu as galéré mais le résultat est nettement mieux.
>
> Pour le niveau capital=7 (sous-préfectures), peux-tu regénérer le zoom 9 :
> Châteaulin n'apparaît pas or la relation et le nœud ont bien capital=7:
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 9/48.2265/-4.3025
>

Zoom 8 à 10 en cours de recalcul...


> Est-il possible de placer ensuite selon la population (en fonction de la
> place) ?
>

C'est déjà le cas, tri sur le niveau admin, puis par population


> En effet sur cette page actuellement on voit le hameau de St-Hernot mais
> pas Crozon qui a donné son nom à la presqu'île.
>
> J'en entends certains qui disent qu'il faut faire apparaître
> Camaret-sur-Mer car la ville est célèbre pour son curé. Non, ce qui se
> mappe sur OSM, à Camaret, c'est la tour Vauban (patrimoine Unesco).
>

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Tu me sembles plutôt réécrire toi-même l'histoire pour l'interpréter. Tu
parle de l'agglomération nouvelle qui n'est pas non plus une commune.

Le chef-lieu est toujours, de jure dans les textes, à Pontoise même s'il
n'y a plus ni conseil général/départemental, ni préfecture et où il y a
maintenant la sous-préfecture de Pontoise (là où était l'ancienne
préfecture du département). Mais on y trouve toujours la plupart des
services départementaux (dont le Palais de justice et plusieurs annexes, la
Direction des affaires sociales). Pontoise (presque entièrement urbanisée)
reste plus peuplée que Cergy, compte de plus nombreux établissements
scolaires et lycées. L'habitat y est nettement plus dense. Son hôtel de
ville est bien plus imposant que celui de "Cergy-Village". L'hôtel de
police a déménagé plus au sud mais est resté à Pontoise, en bordure des
deux communes.

La préfecture (située maintenant à Cergy)
s'appelle officiellement "Préfecture du Val-d'Oise" (et non pas "Préfecture
de Cercy-Pontoise" : je ne sais pas où tu as été chercher ça, c'est une
invention). La gare SNCF de Cergy (à côté) s'appelle "Cergy Préfecture"
(aucune de mention de Pontoise qui a une autre gare nommée seulement
"Pontoise"). Le conseil général, devenu conseil départemental (aussi à
Cergy dans le même secteur semi-urbain où a été construit aussi
l'université), ne porte pas non plus le nom de la commune ou de
l'agglomération nouvelle, mais celui du département. Cergy est encore
largement une zone peu bâtie avec des parcs et des étangs dans la boucle de
la Seine, avec plusieurs petits villages séparés par une large "bande
verte" et une petite frange urbaine au nord.

On parle du "préfet du Val-d'Oise" (pas du "préfet de Cergy" ni de
"Cergy-Pontoise"), du président du conseil général/départemental du
Val-d'Oise, etc. Les documents d'identité émis par la préfecture indiquent
"préfecture du Val-d'Oise" (pas "Cergy-Pontoise", ni "Cergy", ni
"Pontoise"). Il y a bien un sous-préfet de Cergy (logé dans les mêmes
bâtiments de la nouvelle préfecture à Cergy, juste un service différent ;
l'accueil du public pour les démarches administratives est le même pour les
deux arrondissements, mais les adresses postales peuvent être différentes
pour certaines démarches intéressant le plus souvent non pas le public,
mais les collectivités locales et autres administrations).

Avant la création du département (issu de la scission du département de la
Seine), il n'y avait que la sous-préfecture de Pontoise; et Cergy encore
plus rurale qu'elle ne l'est aujourd'hui était dans le même arrondissement,
elle a été promue en chef-lieu du nouveau département et les
arrondissements ont été séparés. Plus tard ensuite la préfecture a
déménagé, la préfecture et la sous-préfecture cohabitent à Cergy, et le
conseil général aussi (et avec lui le centre des finances publiques).

Les deux autres sous-préfectures (Argenteuil et Sarcelles) sont bien dans
la commune homonyme, chef-lieu de leur arrondissement.

Ce qui fait que pour l'arrondissement de Pontoise, le chef-lieu ne loge pas
le siège de sa préfecture ou sous-préfecture (on a le cas aussi en Alsace
entre deux paires d'arrondisssements "Ville" et "Campagne", issu des
divisions administratives durant l'occupation allemande), ni le conseil
départemental (c'est aussi le seul cas en France où il n'est pas situé au
chef-lieu officiel du département).


Le 7 septembre 2016 à 01:37, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> > Le 7 sept. 2016 à 00:06, Philippe Verdy  a écrit :
> >
> > Au fait pour le 95, quel est le chef-lieu ? Cergy ou Pontoise ?
> >
> > Ne vous fiez pas au siège de la préfecture ou du conseil départemental,
> car le chef-lieu **officiel** (de jure) du département n'est que le siège
> d'une sous-préfecture !
> >
> > Si on doit choisir, laquelle des deux communes afficher comme elles sont
> limitrophes ? ou afficher "Cergy-Pontoise" su un noeud fictif chef-lieu du
> département (capital=6) ? Et placer alors la préfecture d'une part et la
> sous-préfecture de l'autre, mais les deux avec capital=7 ???
>
> C’est une réécriture de l’Histoire : lors de l’éclatement de la
> Seine-et-Oise, Cergy était une zone agricole. La préf. a été logée
> provisoirement à Pontoise, ancienne sous-préfecture, puis transférée d
> l’autre côté de l’A 15, toute seule au milieu d’une zone encore cultivée de
> Cergy. Le nom officiel de la préfecture est Cergy-Pontoise qui est aussi le
> nom de l’agglomération noouvelle, constituée d’une dizaine de communes.
>
>
> Chrsistian R.
> Ancien Seine-et-Oisien, ancien Valdoisien, ancien fonctionnaire de la
> préfecture de Cergy-Pntoise
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Rogel]

> Le 7 sept. 2016 à 00:06, Philippe Verdy  a écrit :
> 
> Au fait pour le 95, quel est le chef-lieu ? Cergy ou Pontoise ?
> 
> Ne vous fiez pas au siège de la préfecture ou du conseil départemental, car 
> le chef-lieu **officiel** (de jure) du département n'est que le siège d'une 
> sous-préfecture !
> 
> Si on doit choisir, laquelle des deux communes afficher comme elles sont 
> limitrophes ? ou afficher "Cergy-Pontoise" su un noeud fictif chef-lieu du 
> département (capital=6) ? Et placer alors la préfecture d'une part et la 
> sous-préfecture de l'autre, mais les deux avec capital=7 ???

C’est une réécriture de l’Histoire : lors de l’éclatement de la Seine-et-Oise, 
Cergy était une zone agricole. La préf. a été logée provisoirement à Pontoise, 
ancienne sous-préfecture, puis transférée d l’autre côté de l’A 15, toute seule 
au milieu d’une zone encore cultivée de Cergy. Le nom officiel de la préfecture 
est Cergy-Pontoise qui est aussi le nom de l’agglomération noouvelle, 
constituée d’une dizaine de communes.


Chrsistian R.
Ancien Seine-et-Oisien, ancien Valdoisien, ancien fonctionnaire de la 
préfecture de Cergy-Pntoise
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[osm . sanspourriel]

Je ne sais combien tu as galéré mais le résultat est nettement mieux.

Pour le niveau capital=7 (sous-préfectures), peux-tu regénérer le zoom 9 
: Châteaulin n'apparaît pas or la relation et le nœud ont bien capital=7:

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#9/48.2265/-4.3025

Est-il possible de placer ensuite selon la population (en fonction de la 
place) ?


En effet sur cette page actuellement on voit le hameau de St-Hernot mais 
pas Crozon qui a donné son nom à la presqu'île.


J'en entends certains qui disent qu'il faut faire apparaître 
Camaret-sur-Mer car la ville est célèbre pour son curé. Non, ce qui se 
mappe sur OSM, à Camaret, c'est la tour Vauban (patrimoine Unesco).


Jean-Yvon

Le 06/09/2016 à 23:43, Christian Quest - cqu...@openstreetmap.fr a écrit :

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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Rien ne s'affiche pour l'instant (carte toute grise).

De plus on dirait que le zoom avant ou arrière saute maintenant par pas de
2 niveaux de zoom avec un seul cran molette, donc si on part au niveau 6,
on ne peut pas voir les 5 ou 7 ni aucun niveau impair et de toute façon je
ne vois qu'une "carte" toute grise quel que soit le niveau, aucune tuile ne
se charge)


Le 6 septembre 2016 à 23:43, Christian Quest  a
écrit :

> Le 6 septembre 2016 à 19:53, Tetsuo Shima  a écrit :
>
>> A propos des limites administratives ... il n'y a pas une probleme avec
>> la nouvelle région Auvergnes-Rhone-Alpes? Le libellé n'apparait pas au
>> niveau 7 ... et au niveau 8 on a un libellé double.
>>
>
> Pour le zoom 7, c'est un problème de place déjà prise par des noms de
> villes voisines... je vais retenter de faire varier la position du libellé
> de la région pour qu'il trouve un coin libre... le problème est un choix de
> priorité entre le nom de la région et le nom des villes. Je pense qu'au
> zoom 8 c'est plutôt les villes qui sont prioritaires.
>
> Pour le zoom 8, les tuiles n'ont pas été recalculées, je relance un
> calcul. Les anciennes régions ne devraient plus être visibles si c'est bien
> à ça que tu faisais référence.
>
> Sur les limites côtières, j'ai galéré, mais ça semble ok maintenant...
> plus de pointillés sauf à partir du zoom 12 pour les limites de communes:
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 11/47.6020/-2.7909
>
> Bonne nouvelle pour Saint-Brieuc (entre autre), le tag capital est
> maintenant pris en compte jusqu'à capital=7 donc les sous-préfecture pour
> donner la priorité de rendu: http://umap.openstreetmap.fr/
> fr/map/test-rendu-osmfr_99740#6/46.649/1.835
>
> Le réseau routier avait disparu des zoom 10/11, il est revenu mais en
> version plus light qu'avant.
>
> Le détail est dans les commit sur github: https://github.com/cquest/
> osmfr-cartocss/commits/master
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Au fait pour le 95, quel est le chef-lieu ? Cergy ou Pontoise ?

Ne vous fiez pas au siège de la préfecture ou du conseil départemental, car
le chef-lieu **officiel** (de jure) du département n'est que le siège d'une
sous-préfecture !

Si on doit choisir, laquelle des deux communes afficher comme elles sont
limitrophes ? ou afficher "Cergy-Pontoise" su un noeud fictif chef-lieu du
département (capital=6) ? Et placer alors la préfecture d'une part et la
sous-préfecture de l'autre, mais les deux avec capital=7 ???


Le 6 septembre 2016 à 23:43, Christian Quest  a
écrit :

> Le 6 septembre 2016 à 19:53, Tetsuo Shima  a écrit :
>
>> A propos des limites administratives ... il n'y a pas une probleme avec
>> la nouvelle région Auvergnes-Rhone-Alpes? Le libellé n'apparait pas au
>> niveau 7 ... et au niveau 8 on a un libellé double.
>>
>
> Pour le zoom 7, c'est un problème de place déjà prise par des noms de
> villes voisines... je vais retenter de faire varier la position du libellé
> de la région pour qu'il trouve un coin libre... le problème est un choix de
> priorité entre le nom de la région et le nom des villes. Je pense qu'au
> zoom 8 c'est plutôt les villes qui sont prioritaires.
>
> Pour le zoom 8, les tuiles n'ont pas été recalculées, je relance un
> calcul. Les anciennes régions ne devraient plus être visibles si c'est bien
> à ça que tu faisais référence.
>
> Sur les limites côtières, j'ai galéré, mais ça semble ok maintenant...
> plus de pointillés sauf à partir du zoom 12 pour les limites de communes:
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 11/47.6020/-2.7909
>
> Bonne nouvelle pour Saint-Brieuc (entre autre), le tag capital est
> maintenant pris en compte jusqu'à capital=7 donc les sous-préfecture pour
> donner la priorité de rendu: http://umap.openstreetmap.fr/
> fr/map/test-rendu-osmfr_99740#6/46.649/1.835
>
> Le réseau routier avait disparu des zoom 10/11, il est revenu mais en
> version plus light qu'avant.
>
> Le détail est dans les commit sur github: https://github.com/cquest/
> osmfr-cartocss/commits/master
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Quest]

Le 6 septembre 2016 à 19:53, Tetsuo Shima  a écrit :

> A propos des limites administratives ... il n'y a pas une probleme avec la
> nouvelle région Auvergnes-Rhone-Alpes? Le libellé n'apparait pas au niveau
> 7 ... et au niveau 8 on a un libellé double.
>

Pour le zoom 7, c'est un problème de place déjà prise par des noms de
villes voisines... je vais retenter de faire varier la position du libellé
de la région pour qu'il trouve un coin libre... le problème est un choix de
priorité entre le nom de la région et le nom des villes. Je pense qu'au
zoom 8 c'est plutôt les villes qui sont prioritaires.

Pour le zoom 8, les tuiles n'ont pas été recalculées, je relance un calcul.
Les anciennes régions ne devraient plus être visibles si c'est bien à ça
que tu faisais référence.

Sur les limites côtières, j'ai galéré, mais ça semble ok maintenant... plus
de pointillés sauf à partir du zoom 12 pour les limites de communes:
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#11/47.6020/-2.7909

Bonne nouvelle pour Saint-Brieuc (entre autre), le tag capital est
maintenant pris en compte jusqu'à capital=7 donc les sous-préfecture pour
donner la priorité de rendu:
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/46.649/1.835

Le réseau routier avait disparu des zoom 10/11, il est revenu mais en
version plus light qu'avant.

Le détail est dans les commit sur github:
https://github.com/cquest/osmfr-cartocss/commits/master

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Tetsuo Shima]

A propos des limites administratives ... il n'y a pas une probleme avec la
nouvelle région Auvergnes-Rhone-Alpes? Le libellé n'apparait pas au niveau
7 ... et au niveau 8 on a un libellé double.

Le 1 septembre 2016 à 09:14, Christian Quest  a
écrit :

> Pas mal de petites modifications sur le rendu FR sont en test.
>
> Vous pouvez voir où j'en suis sur http://umap.openstreetmap.fr/f
> r/map/test-rendu-osmfr_99740
>
> Quoi de neuf ?
>
> - de nouvelles icônes pour les commerces
>
> - des labels de taille et de couleur variant avec la taille du polygone
> qu'ils décrivent (texte en vert pour une forêt, plus gros si la forêt est
> grande, etc)
>
> - amélioration des frontières... les pointillés ne devraient plus se
> mélanger comme avant, les noms ne devraient plus être coupés en bord de
> metatile
>
> - harmonisation des largeurs de routes et réorganisation du tracé des
> layers 1-5
>
>
> Au delà de ces modifications visibles, il y a pas mal de nettoyage des
> fichiers de la feuille de style pour faciliter sa mise à jour. Quelques
> améliorations aussi sur les requêtes SQL (une bonne dizaine de requêtes de
> moins par exemple sur le tracé des 5 niveaux de layer).
>
> Bref, beaucoup de changements (le détail est sur
> https://github.com/cquest/osmfr-cartocss/commits/master) qui ont pu
> casser ici ou là des choses que je n'ai pas pu voir, donc si il y a des
> anomalies merci de les signaler avec l'URL sur cette carte umap (qui
> contient le zoom et les coordonnées).
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

En fait les limites administratives ne sont pas taguées explicitement sur
les lignes de côtes (natural=coastline) car elle ne sont même pas
réellement adminsitratives (on n'a pas tracé la "ligne de base" réelle.
Mais les pointillés apparaissent du fait qu'elles font partie des relations
administratives.

Il reste encore quelques segments non fusionnés de lignes adminsitratives
en Vendée, en Haute Normandie et sur la côte méditerranéenne, tracées en
mer à partir des polygones arbitraires de zonage du cadastre, alors qu'il
n'y a pourtant aucune "parcelle" cadastrale dans le domaine maritime (sauf
concernant les concessions piscicoles, mytilicoles ou ostréicoles, et les
installations légales sur le littoral, régulièrement approuvées par les
autorités préfectorales, pour des exploitants privés ou les installations
portuaires demandées par les autorités portuaires légales et concertées
publiquement par des marchés publics, ou des constructions qui sont restées
en place pour des raisons historiques datant d'avant les lois de protection
du littoral ou parfois protégées ou classées comme monuments historiques,
ou des installations nécessaires à la sécurité publique comme les phares et
balises et les digues de protection du littoral).

Ne devrait-on pas finir la suppression de ces segments de frontières
communales/départementales/régionales tracés le long de la côte et qui ne
dont pas là pour fermer les ports ou estuaires (ceux-là sont seulement
tagués comme frontières régionales), et les fusionner sur la ligne de côte ?

Et aussi nettoyer la ligne de côte de façon correcte le long des plages (en
coupant les plages en deux sur la ligne de haute mer et non pas en mettant
toute la plage côté terre ou entièrement côté mer, les plages étant plus
réalistes si on inclue dedans côté mer les zones découvertes en basse-mer
et les parties hautes non découvertes) ? Le fait de mettre toute la plage
côté mer semble oublier aussi que les communes ont une compétence (et des
obligations) limitée sur ces plages (en terme de sécurité, surveillance et
salubrité).

De plus la ligne de base légale semble bien inclure les parties découvertes
en basse mer: placer la ligne administrative au milieu de la plage (sur la
laisse de mer en gros) est plus réaliste (à mon humble avis) et va dans le
sens qu'on a donné aussi dans OSM en incluant les eaux portuaires et les
estuaires sur le dernier pont ou barrage par un trait de coupe dans l'eau,
hors de la ligne "naturelle" de côte qui remonte en revanche dans les ports
et estuaires (et aussi se prolonge le long des digues fermant les ports,
même si ce n'est pas réellement une côte "naturelle" comme le suggère le
tag natural=coastline; il n'y a de toute façon pratiquement plus de côte
totalement naturelle en France avec les nombreux aménagements de
protection, et la ligne naturelle est compliqué à définir, et elle est
évolutive et difficile à définir quand ce sont des zones rocheuses avec de
nombreux écueils joints à la côte).

Cela n'exclue pas non plus de taguer aussi les zones soumises à la marée
(mais les "tidal" dans OSM sont vraiment très approximatifs, trop même et
devrient être améliorée pour suivre plus précisément les données du SHOM et
données sur les zones inondables/submersibles (même si c'est exceptionnel
lors de tempêtes), ces zones submersibles ayant aussi des contraintes
légales allant au delà du seul domaine public littoral protégé (on l'a tous
vu suite à Xynthia en Vendée et Charente-Maritime, mais c'est "compliqué"
quand ça touche aussi le milieu urbain dense comme le port de la Rochelle:
les zones submersibles avec réglementation spéciale de prévention
pourraient être taguées différemment des zones "tidal" d'OSM qui alors ne
concerneraient que des marées normales et régulières, prévisibles au moins
plusieurs mois avant et constatées comme submergées sur plusieurs années à
marée haute pendant quelques jours, rien à voir donc avec les submersions
liées aux tempêtes qui sont plutôt dans les plans de prévention des risques
et d'évacuation mais qui n'imposent pas les expulsions permanentes et
démolitions).

 Cas des zones de danger:
érosion/submersions/inondations/avalanches/chutes de roches/effondrements

Il y a aussi des éléments du littoral soumis à l'érosion et des
effondrements mais qu'on ne peut pas taguer comme ligne de côte, ni comme
zone submersible mais qui entrent dans la bande littorale et peuvent
conduire à des expulsions et démolitions préventives s'il n'y a pas les
moyens de construire des protections ou si le sol devient instable. Les
zones de danger de submersion ou d'effondrement devraient être taguées dans
OSM, mais elles sont dans les limites administratives des collectivités
locales et à l'intérieur des lignes de côte (haute mer normale) et des
limites zones de marée (tidal).

La bande du littoral protégé devrait aussi être définie précisément (là le
cadastre devrait être précis sur les parcelles des communes concernées),
elle inclue normalement tout ça 

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Le 3 septembre 2016 à 22:38, Christian Quest  a
écrit :

> Les nouveautés du samedi...
>
> - bug corrigé sur les ponts, et j'en ai profité pour ajouter le rendu des
> man_made=bridge ce qui permet de voir l'emprise des ponts, exemple:
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#1
> 8/48.85716/2.34108
>
> - l'ordre de priorité pour placer les noms dans les petites échelles (zoom
> 6 par exemple) est revu, et Vannes est bien au rendez-vous:
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/46.958/2.615
>

Arf! "Plérin" visible à la place de "Saint-Brieuc" (pourtant chef-lieu de
département et nettement plus peuplé).

Même chose pour :
- Cherbourg-en-Contentin (on voit Digosville),
- Saint-Malo (on voit le Petit Bé, une petite île devant Saint-Malo, dans
population quelques rochers et de la lande, et au moins une cinquantaine de
fois plus petit que la commune ou 15 fois celle des quartiers d'Intra-Muros
ou Paramé),
- Le Havre et Caen (on voit Villainville)
- Landerneau (on voit le village de Loudiry)
- Île-deBréhat (on voit Barafot)
- Avignon (on voit Alès)
- Limoges (on voir Roumazières)
- Metz (on voit Jamy)
- Thionville (on voit Longuyon)

ces plus petits villages ou ilets disparaissent au niveau 7 pour afciher
les plus grosses communes (non affichées au niveau 6), et ne reviennent
qu'à des niveaux plus élevés

Et toujours les arrondissements de Paris au niveau admin 9 dont on a du mal
à voir les limites (qui devraient commencer à être visible vers le niveau
13 qui affiche la capitale sur presque tout l'écran en Full HD).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Quest]

 Les nouveautés du samedi...

- bug corrigé sur les ponts, et j'en ai profité pour ajouter le rendu des
man_made=bridge ce qui permet de voir l'emprise des ponts, exemple:
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
18/48.85716/2.34108

- l'ordre de priorité pour placer les noms dans les petites échelles (zoom
6 par exemple) est revu, et Vannes est bien au rendez-vous:
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/46.958/2.615

- des icônes de commerces avaient disparu, elles sont de retour (contrôle
technique, lavage auto, glaces, etc)

- icône pour les bornes de recharge de véhicules électriques:
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#17/47.85187/3.54325

ainsi que plein de petites bricoles...

Pour les côtes, je vais voir ce que je peux faire, en fait les limites
administratives n'ont pas besoin d'être mises sur les côtes, mais encore
faut-il pouvoir faire le tri ;)

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Le 3 septembre 2016 à 10:03,  a écrit :

> - golfe du Morbihan (côte + RN http://www.openstreetmap.org/r
> elation/1255492).
>
À ce niveau de rendu les contours me semblent trop marqués pour des formes
> complexes.
>

On a tenu compte dans le golfe du Mobihan des zones exclues des limites
communales car faisant partie du domaine maritime national, cependant on a
aussi les limites des zones protégées du parc naturel.

En revanche tu noteras qu'il y a une différence entre les limites
communales et la limite régionale qui inclut totalement le Golfe du
Morbihan, par un trait coupant la passe (et qui n'est pas la ligne de côte.

Normalement on aurait du faire le même détail dans le Ria d'Etel (les
limites communales sont trop arbitraires, sans doute issues du cadastre qui
est tout aussi grossier et arbitraire). Ca demande à être plus détaillé car
les communes sont trop étendues sur le domaine maritime, même si le ria est
entièrement inclus dans les limites régionales (le département n'a pas de
compétence sur ce domaine naturel contrairement à la région, le département
devrait suivre les limites communales (comme aussi les EPCI, et même les
arrondissements départementaux qui n'ont aucune compétence autre que celles
de l'Etat dans son administration préfectorale).

Je ne vois aucune anomalie flagrante dans le Golfe du Morbihan (je ne
trouve pas du tout le rendu "trop complexe", il traduit assez bien ce
découpage complexe).

Le 3 septembre 2016 à 10:03,  a écrit :

> Je complète par un exemple plus flagrant :
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 11/47.6302/-3.0590 
>
> http://www.openstreetmap.org/#map=11/47.6300/-3.0590
>
> Et oui, les côtes bretonnes étant échancrées, augmenter le trait de côte
> ou les zones protégées rend la carte assez confuse.
>
> En fait je disais trait de côte mail il s'agit des limites administratives.
> Ici on voit 4 rendus très différents pour des zones assez similaires (de
> l'ouest à l'est) :
> - Rade de Lorient, côte + limite administrative
> - Ria d'Etel (je suis obligé de décrire, manque sans doute le nom sur la
> Ria et Magouër empêche l'affichage de la commune d'Etel : Magouër, St
> Hélène Nostang, Locoal-Mendon, Belz), natural=water mais soumise à la marée.
> - golfe du Morbihan (côte + RN http://www.openstreetmap.org/
> relation/1255492).
> À ce niveau de rendu les contours me semblent trop marqués pour des formes
> complexes.
>
> Soit à ce niveau on fait des traits plus légers, soit partout soit pour
> les intérieurs des polygones.
> Soit encore on tient compte du rapport surface/périmètre pour déterminer
> le style (largeur, couleur, dégradé).
>
> Ici les différences de rendu sont impressionnantes :
> http://www.openstreetmap.org/#map=12/47.5938/-2.7761
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 12/47.5939/-2.7765
> À mon avis, c'est bien de rendre le nom des îlots (pourquoi l'
> Île-aux-Moines  n'apparaît pas
> ? Doit on comme pour le caillou Île du Charles
>  ajouter un place=island, ça
> me semble logique, je le fait de ce pas), avec les traits à l'ancienne
> sinon c'est trop chargé.
>
> Et si l'expression publicitaire, Bretagne terre de contraste" venait des
> travaux cartographiques de Christian ?
>
>
> Le 02/09/2016 à 22:28, osm.sanspourr...@spamgourmet.com a écrit :
>
> * C'est plus du détail mais les polders se distinguent moins bien de la
> mer :
>
> http://www.openstreetmap.org/#map=13/48.3901/-4.4734
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 13/48.3901/-4.4734
>
> * Au niveau 11, le trait de côte est très visible et le trait des rives
> des fleuves absent alors qu'au niveau 12 c'est plus propre :
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 11/48.3901/-4.4734
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 12/48.3613/-4.5499
>
> 
>
> Comme cette limite n'est pas la limite des marée mais un trait arbitraire
> dans les estuaires, ça fait drôle en Bretagne (1/3 des fleuves bretons sont
> maritimes, ci l'Elorn de Landerneau au pont de Plougastel).
>
> Soit limiter l'épaisseur en niveau 11 soit ajouter le tracé des rives des
> fleuves .
>
> Le 02/09/2016 à 21:48, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Vu, ainsi que http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 13/48.8575/2.3462
>
> Le 2 septembre 2016 à 20:02, Marc Sibert  a écrit :
>
>> Bonjour à tous,
>>
>> Un bug sur les ponts ?
>>
>> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#1
>> 3/48.7317/2.3672
>>
>> ce qui particulièrement criant sur le point de l'orly val à Orly.
>>
>> A+
>>
>> Marc Sibert
>> mailto:m...@sibert.fr
>>
>> Le 01/09/2016 à 09:14, Christian 

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Le 3 septembre 2016 à 10:03,  a écrit :

> - golfe du Morbihan (côte + RN http://www.openstreetmap.org/
> relation/1255492).
>
À ce niveau de rendu les contours me semblent trop marqués pour des formes
> complexes.
>

On a tenu compte dans le golfe du Mobihan des zones exclues des limites
communales car faisant partie du domaine maritime national, cependant on a
aussi les limites des zones protégées du parc naturel.

En revanche tu noteras qu'il y a une différence entre les limites
communales et la limite régionale qui inclut totalement le Golfe du
Morbihan, par un trait coupant la passe (et qui n'est pas la ligne de côte.

Normalement on aurait du faire le même détail dans le Ria d'Etel (les
limites communales sont trop arbitraires, sans doute issues du cadastre qui
est tout aussi grossier et arbitraire). Ca demande à être plus détaillé car
les communes sont trop étendues sur le domaine maritime, même si le ria est
entièrement inclus dans les limites régionales (le département n'a pas de
compétence sur ce domaine naturel contrairement à la région, le département
devrait suivre les limites communales (comme aussi les EPCI, et même les
arrondissements départementaux qui n'ont aucune compétence autre que celles
de l'Etat dans son administration préfectorale).

Je ne vois aucune anomalie flagrante dans le Golfe du Morbihan (je ne
trouve pas du tout le rendu "trop complexe", il traduit assez bien ce
découpage complexe).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Note: une exception à cette "règle" a été faite dans l'estuaire de la Rance
(pourtant fermé par un barrage avec même une importante route permanente
dessus entre Dinard et Saint-Malo (qui cependant possède une petite section
levante au niveau de l'écluse): l'esturaire est tellement large que les
lignes administratives remontent très loin;

L'estuaire fait aussi l'objet d'une protection et d'une surveillance de
l'écosystème marin. la "ligne de côte" d'OSM remonte donc au delà du
barrage de la Rance jusqu'au port de Dinan. en amont du port, il y a encore
des zones inondables mais elles restent souvent découvertes même à marée
haute et sont de vrais marais avec des herbes hautes (ce ne sont pas des
"polders" non plus) avec son chenal naturel étroit mais permanent, maintenu
en eaux par l'écluse du port, et avec des eaux essentiellement fluviales
même si de l'eau de mer vient s'y mêler à marée haute quand l'écluse du
port de Dinan est ouverte avec une salinité relativement faible du fait de
la faible proportion d'eau de mer et du flux d'eau douce appporté par la
Rance.

Concernant les abers au sud de la rade de Brest, on peut se poser la
question s'il faut utiliser le pont ou remonter plus haut la frontière
administrative sur la partie maritime du fleuve (d'autant que la loi
Littoral concerne des communes plus en amont), comme on l'a fait sur la
Rance. La question se pose aussi dans des zones de marais côtiers avec une
passe marine étroite le long du sud de la Bretagne.

La question se pose aussi pour le Golfe du Morbihan: coupé par la frontière
administrative régionale (car c'est un parc naturel régional) mais les
communes, elles, ont leur frontière excluant les zones marines du golfe (et
d'ailleurs nombre des iles émergées sont dans le domaine maritime). Mais la
limite régionale coupe arbitrairement l'entrée du golfe (sans être taguée
elle-même comme "ligne de côte": les lignes de côte font bien le tour du
golfe et délimitent chacune des îles)

On peut aussi analyser et discuter les côtes du golfe du Roussilon.

Tout cela n'est pas un problème de rendu, mais il s'agit juste de rendre
compte assez fidèlement les réalités de terrain:

* il est difficile d'établir les limites communales (car le cadastre n'aide
pas du tout, le littoral étant de toute façon non compétent puisqu'il n'y a
normalement pas de "propriété" privée et que le littoral est un domaine
public national, où les communes ont cependant une compétence limitée aux
installations portuaires et à l'accessibilité, la sécurité et la salubrité
des plages et ne peuvent pas délivrer de permis de construire sans aval de
l'Etat (avec recours possible devant les tribunaux administratifs et le
conseil d'Etat: les assos de riverains et de protection d'environnement et
les agences portuaires font souvent des recours, mais le préfet local
représentant l'Etat y fait appel assez souvent pour obtenir des expulsions
et la destruction d'installations privées et annuler des décisions
municipales accordant des autorisations sur les plages).
* les limites régionales sont un peu plus faciles et incluent généralement
aussi les parcs régionaux, et tous les ponts et barrages et routes
nationales et départementales qui les traversent.
* entre les deux c'est une estimation de ce qu'on appelle les "eaux
intérieures".

Le SHOM a founit des données un peu plus détaillées mais d'un point de vue
environnemental. Son tracé ne tient pas compte des réalités administratives
locales et du fait qu'on a choisit dans OSM d'inclure les zones portuaires
et zones d'ancrage dans les estuaires dans les limites communales (ce qui
traduit bien les nombreuses arrêts en conseil d'Etat ou en cassation qui
vont dans le même sens, soit pour protéger le littoral contre les riverains
et collectivités locales, soit pour établir la responsabilité limitée des
communes).

Dans OSM on distingue donc clairement ce qui est les frontières
administratives et les frontières naturelles. mais hors des estuaires et
ports, on a choisi de les confondre et cela donne aussi une carte plus
réaliste et moins "fouillie", plus facile à traiter (il reste le cas
particulier des plages souvent tracées entièrement côté mer (la ligne de
côte exclut totalement la plage au lieu de la couper sur la laisse de mer,
ce trait de côte étant alors à réutiliser quand même comme ligne
administrative).

Le 3 septembre 2016 à 10:01, Philippe Verdy  a écrit :

> Ce n'est pas le trait de côte en tant que tel qu'on voit, c'est la ligne
> administratitive (qui il est vrai est un peu arbitraire au travers des
> estuaires, mais suit généralement la coupure au dernier pont, barrage (ou
> barrière de sel), même si la mer peut remonter plus loin et l'effet des
> marées peut encore se faire sentir notamment dans les abers bretons
> Ce qui donne de larges zones découvertes à marée basse, où les bateaux
> dans l'estuaire sont posés sur le fond, mélange de sable marin, de vase,
> d'alluvions fluvieux, d'algues et habitat de nombreux 

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[osm . sanspourriel]

Je complète par un exemple plus flagrant :

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#11/47.6302/-3.0590 



http://www.openstreetmap.org/#map=11/47.6300/-3.0590

Et oui, les côtes bretonnes étant échancrées, augmenter le trait de côte 
ou les zones protégées rend la carte assez confuse.


En fait je disais trait de côte mail il s'agit des limites administratives.

Ici on voit 4 rendus très différents pour des zones assez similaires (de 
l'ouest à l'est) :

- Rade de Lorient, côte + limite administrative
- Ria d'Etel (je suis obligé de décrire, manque sans doute le nom sur la 
Ria et Magouër empêche l'affichage de la commune d'Etel : Magouër, St 
Hélène Nostang, Locoal-Mendon, Belz), natural=water mais soumise à la marée.
- golfe du Morbihan (côte + RN 
http://www.openstreetmap.org/relation/1255492).
À ce niveau de rendu les contours me semblent trop marqués pour des 
formes complexes.


Soit à ce niveau on fait des traits plus légers, soit partout soit pour 
les intérieurs des polygones.
Soit encore on tient compte du rapport surface/périmètre pour déterminer 
le style (largeur, couleur, dégradé).


Ici les différences de rendu sont impressionnantes :
http://www.openstreetmap.org/#map=12/47.5938/-2.7761
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#12/47.5939/-2.7765
À mon avis, c'est bien de rendre le nom des îlots (pourquoi 
l'Île-aux-Moines  n'apparaît 
pas ? Doit on comme pour le caillou Île du Charles 
 ajouter un place=island, ça 
me semble logique, je le fait de ce pas), avec les traits à l'ancienne 
sinon c'est trop chargé.


Et si l'expression publicitaire, Bretagne terre de contraste" venait des 
travaux cartographiques de Christian ?


Le 02/09/2016 à 22:28, osm.sanspourr...@spamgourmet.com a écrit :


* C'est plus du détail mais les polders se distinguent moins bien de 
la mer :


http://www.openstreetmap.org/#map=13/48.3901/-4.4734

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/48.3901/-4.4734

* Au niveau 11, le trait de côte est très visible et le trait des 
rives des fleuves absent alors qu'au niveau 12 c'est plus propre :


http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#11/48.3901/-4.4734

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#12/48.3613/-4.5499


Comme cette limite n'est pas la limite des marée mais un trait 
arbitraire dans les estuaires, ça fait drôle en Bretagne (1/3 des 
fleuves bretons sont maritimes, ci l'Elorn de Landerneau au pont de 
Plougastel).


Soit limiter l'épaisseur en niveau 11 soit ajouter le tracé des rives 
des fleuves .



Le 02/09/2016 à 21:48, Christian Quest - cqu...@openstreetmap.fr a écrit :
Vu, ainsi que 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/48.8575/2.3462


Le 2 septembre 2016 à 20:02, Marc Sibert > a écrit :


Bonjour à tous,

Un bug sur les ponts ?

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/48.7317/2.3672



ce qui particulièrement criant sur le point de l'orly val à Orly.

A+

Marc Sibert
mailto:m...@sibert.fr 

Le 01/09/2016 à 09:14, Christian Quest a écrit :

Pas mal de petites modifications sur le rendu FR sont en test.

Vous pouvez voir où j'en suis sur
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740


Quoi de neuf ?

- de nouvelles icônes pour les commerces

- des labels de taille et de couleur variant avec la taille
du polygone qu'ils décrivent (texte en vert pour une forêt,
plus gros si la forêt est grande, etc)

- amélioration des frontières... les pointillés ne devraient
plus se mélanger comme avant, les noms ne devraient plus être
coupés en bord de metatile

- harmonisation des largeurs de routes et réorganisation du
tracé des layers 1-5


Au delà de ces modifications visibles, il y a pas mal de
nettoyage des fichiers de la feuille de style pour faciliter
sa mise à jour. Quelques améliorations aussi sur les requêtes
SQL (une bonne dizaine de requêtes de moins par exemple sur
le tracé des 5 niveaux de layer).

Bref, beaucoup de changements (le détail est sur
https://github.com/cquest/osmfr-cartocss/commits/master
)
qui ont pu casser ici ou là des choses que je n'ai pas pu
voir, donc si il y a des anomalies merci de les signaler avec
l'URL sur cette carte umap (qui contient le zoom et les
coordonnées).



   

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Ce n'est pas le trait de côte en tant que tel qu'on voit, c'est la ligne
administratitive (qui il est vrai est un peu arbitraire au travers des
estuaires, mais suit généralement la coupure au dernier pont, barrage (ou
barrière de sel), même si la mer peut remonter plus loin et l'effet des
marées peut encore se faire sentir notamment dans les abers bretons
Ce qui donne de larges zones découvertes à marée basse, où les bateaux dans
l'estuaire sont posés sur le fond, mélange de sable marin, de vase,
d'alluvions fluvieux, d'algues et habitat de nombreux crustacés et refuge
et garde-manger pour de nombreux oiseaux marins qui viennent y picorer; ces
zones sont parfois poldérisées mais pas toujours (ne fait rarement) sauf
pour aménager un port accessible par un chenal entretenu et des quais ou
zones de services, dans des zones protégées par des digues (et parfois
maintenues avec un niveau d'eau suffisant par des écluses marines ou par
des portes qu'on relève quand la mer baisse.

Comme ce sont aussi des zones portuaires ou d'ancrage (surtout maintenant
pour les voiliers de loisir, mais aussi des bateaux de pêche côtière ou de
caséieurs à fond plat ou à quille relevable), il est normal de les inclure
dans les limites administratives.

Le chenal résiduel à marée basse dans les abers est trop étroit (souvent
moins de 50 mètres) pour en faire une vraie ligne de côte, mais à marée
haute l'aber est très large et la ligne de côte entre dans les terres et
suit à peu près les recommandations pour OSM. Normalement on devrait tracer
encore dans ces abers une zone de "terres humides" représentant les zones
découvertes à marée basse (fonds sableux ou vaseux, ou roches plus ou moins
colonisées par les coquillages, crustacés et algues et où persiste de
nombreuses flaques). Ces zones humides se porusivent hors de la zone
intérieure de la limite administrative un peu arbitraire coupant
l'estuaire. Dans OSM on peut aussi taguer simplement les zones soumises à
marée ("tidal") mais le rendu OSM par défaut ne les affiche pas (au
contraire des "terres humides" quand elles s'étendent aussi côté "mer" au
delà de la ligne de côte "coastline" d'OSM tracée à hautes eaux plus ou
moins le long de la laisse de mer ou le long des digues et des derniers
ponts et barrages)

Cette frontière visible n'est pas la frontière internationale (placée à 12
miles environ) mais régionale/départementale/communale, on la voit donc
comme régionale. Je ne vois pas où est donc l'anomalie.

Le 2 septembre 2016 à 22:28,  a écrit :

> * C'est plus du détail mais les polders se distinguent moins bien de la
> mer :
>
> http://www.openstreetmap.org/#map=13/48.3901/-4.4734
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 13/48.3901/-4.4734
>
> * Au niveau 11, le trait de côte est très visible et le trait des rives
> des fleuves absent alors qu'au niveau 12 c'est plus propre :
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 11/48.3901/-4.4734
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 12/48.3613/-4.5499
>
> 
>
> Comme cette limite n'est pas la limite des marée mais un trait arbitraire
> dans les estuaires, ça fait drôle en Bretagne (1/3 des fleuves bretons sont
> maritimes, ci l'Elorn de Landerneau au pont de Plougastel).
>
> Soit limiter l'épaisseur en niveau 11 soit ajouter le tracé des rives des
> fleuves .
>
> Le 02/09/2016 à 21:48, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Vu, ainsi que http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 13/48.8575/2.3462
>
> Le 2 septembre 2016 à 20:02, Marc Sibert  a écrit :
>
>> Bonjour à tous,
>>
>> Un bug sur les ponts ?
>>
>> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#1
>> 3/48.7317/2.3672
>>
>> ce qui particulièrement criant sur le point de l'orly val à Orly.
>>
>> A+
>>
>> Marc Sibert
>> mailto:m...@sibert.fr
>>
>> Le 01/09/2016 à 09:14, Christian Quest a écrit :
>>
>>> Pas mal de petites modifications sur le rendu FR sont en test.
>>>
>>> Vous pouvez voir où j'en suis sur http://umap.openstreetmap.fr/f
>>> r/map/test-rendu-osmfr_99740
>>>
>>> Quoi de neuf ?
>>>
>>> - de nouvelles icônes pour les commerces
>>>
>>> - des labels de taille et de couleur variant avec la taille du polygone
>>> qu'ils décrivent (texte en vert pour une forêt, plus gros si la forêt est
>>> grande, etc)
>>>
>>> - amélioration des frontières... les pointillés ne devraient plus se
>>> mélanger comme avant, les noms ne devraient plus être coupés en bord de
>>> metatile
>>>
>>> - harmonisation des largeurs de routes et réorganisation du tracé des
>>> layers 1-5
>>>
>>>
>>> Au delà de ces modifications visibles, il y a pas mal de nettoyage des
>>> fichiers de la feuille de style pour faciliter sa mise à jour. Quelques
>>> améliorations aussi sur les requêtes SQL (une bonne dizaine de requêtes de
>>> moins par exemple sur le tracé 

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[osm . sanspourriel]

* C'est plus du détail mais les polders se distinguent moins bien de la 
mer :


http://www.openstreetmap.org/#map=13/48.3901/-4.4734

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/48.3901/-4.4734

* Au niveau 11, le trait de côte est très visible et le trait des rives 
des fleuves absent alors qu'au niveau 12 c'est plus propre :


http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#11/48.3901/-4.4734

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#12/48.3613/-4.5499


Comme cette limite n'est pas la limite des marée mais un trait 
arbitraire dans les estuaires, ça fait drôle en Bretagne (1/3 des 
fleuves bretons sont maritimes, ci l'Elorn de Landerneau au pont de 
Plougastel).


Soit limiter l'épaisseur en niveau 11 soit ajouter le tracé des rives 
des fleuves .



Le 02/09/2016 à 21:48, Christian Quest - cqu...@openstreetmap.fr a écrit :
Vu, ainsi que 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/48.8575/2.3462


Le 2 septembre 2016 à 20:02, Marc Sibert > a écrit :


Bonjour à tous,

Un bug sur les ponts ?

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/48.7317/2.3672



ce qui particulièrement criant sur le point de l'orly val à Orly.

A+

Marc Sibert
mailto:m...@sibert.fr 

Le 01/09/2016 à 09:14, Christian Quest a écrit :

Pas mal de petites modifications sur le rendu FR sont en test.

Vous pouvez voir où j'en suis sur
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740


Quoi de neuf ?

- de nouvelles icônes pour les commerces

- des labels de taille et de couleur variant avec la taille du
polygone qu'ils décrivent (texte en vert pour une forêt, plus
gros si la forêt est grande, etc)

- amélioration des frontières... les pointillés ne devraient
plus se mélanger comme avant, les noms ne devraient plus être
coupés en bord de metatile

- harmonisation des largeurs de routes et réorganisation du
tracé des layers 1-5


Au delà de ces modifications visibles, il y a pas mal de
nettoyage des fichiers de la feuille de style pour faciliter
sa mise à jour. Quelques améliorations aussi sur les requêtes
SQL (une bonne dizaine de requêtes de moins par exemple sur le
tracé des 5 niveaux de layer).

Bref, beaucoup de changements (le détail est sur
https://github.com/cquest/osmfr-cartocss/commits/master
) qui
ont pu casser ici ou là des choses que je n'ai pas pu voir,
donc si il y a des anomalies merci de les signaler avec l'URL
sur cette carte umap (qui contient le zoom et les coordonnées).



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





--
Christian Quest - OpenStreetMap France


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


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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Quest]

Vu, ainsi que
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/48.8575/2.3462

Le 2 septembre 2016 à 20:02, Marc Sibert  a écrit :

> Bonjour à tous,
>
> Un bug sur les ponts ?
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#1
> 3/48.7317/2.3672
>
> ce qui particulièrement criant sur le point de l'orly val à Orly.
>
> A+
>
> Marc Sibert
> mailto:m...@sibert.fr
>
> Le 01/09/2016 à 09:14, Christian Quest a écrit :
>
>> Pas mal de petites modifications sur le rendu FR sont en test.
>>
>> Vous pouvez voir où j'en suis sur http://umap.openstreetmap.fr/f
>> r/map/test-rendu-osmfr_99740
>>
>> Quoi de neuf ?
>>
>> - de nouvelles icônes pour les commerces
>>
>> - des labels de taille et de couleur variant avec la taille du polygone
>> qu'ils décrivent (texte en vert pour une forêt, plus gros si la forêt est
>> grande, etc)
>>
>> - amélioration des frontières... les pointillés ne devraient plus se
>> mélanger comme avant, les noms ne devraient plus être coupés en bord de
>> metatile
>>
>> - harmonisation des largeurs de routes et réorganisation du tracé des
>> layers 1-5
>>
>>
>> Au delà de ces modifications visibles, il y a pas mal de nettoyage des
>> fichiers de la feuille de style pour faciliter sa mise à jour. Quelques
>> améliorations aussi sur les requêtes SQL (une bonne dizaine de requêtes de
>> moins par exemple sur le tracé des 5 niveaux de layer).
>>
>> Bref, beaucoup de changements (le détail est sur
>> https://github.com/cquest/osmfr-cartocss/commits/master) qui ont pu
>> casser ici ou là des choses que je n'ai pas pu voir, donc si il y a des
>> anomalies merci de les signaler avec l'URL sur cette carte umap (qui
>> contient le zoom et les coordonnées).
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Marc Sibert]

Bonjour à tous,

Un bug sur les ponts ?

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/48.7317/2.3672

ce qui particulièrement criant sur le point de l'orly val à Orly.

A+

Marc Sibert
mailto:m...@sibert.fr

Le 01/09/2016 à 09:14, Christian Quest a écrit :

Pas mal de petites modifications sur le rendu FR sont en test.

Vous pouvez voir où j'en suis sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740


Quoi de neuf ?

- de nouvelles icônes pour les commerces

- des labels de taille et de couleur variant avec la taille du 
polygone qu'ils décrivent (texte en vert pour une forêt, plus gros si 
la forêt est grande, etc)


- amélioration des frontières... les pointillés ne devraient plus se 
mélanger comme avant, les noms ne devraient plus être coupés en bord 
de metatile


- harmonisation des largeurs de routes et réorganisation du tracé des 
layers 1-5



Au delà de ces modifications visibles, il y a pas mal de nettoyage des 
fichiers de la feuille de style pour faciliter sa mise à jour. 
Quelques améliorations aussi sur les requêtes SQL (une bonne dizaine 
de requêtes de moins par exemple sur le tracé des 5 niveaux de layer).


Bref, beaucoup de changements (le détail est sur 
https://github.com/cquest/osmfr-cartocss/commits/master) qui ont pu 
casser ici ou là des choses que je n'ai pas pu voir, donc si il y a 
des anomalies merci de les signaler avec l'URL sur cette carte umap 
(qui contient le zoom et les coordonnées).





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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Quest]

J'ai pas vraiment touché à ces niveaux de zooms... je vais regarder ce que
je peux faire pour ces cas.

La généralisation automatique est bien complexe à ces niveaux ! ;)

Le 1 septembre 2016 à 23:07,  a écrit :

> Bonjour, il faudrait tenir compte des admin_level avant la population
> (dans une certaine limite) car on a toujours Saint-Avé (commune de l'agglo
> de Vannes) qui prend le dessus sur Vannes (préfecture) dans le rendu
> français.
>
> C'est bon au niveau 6, pas au niveau 7 et les admin_level sont bien
> renseignés.
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/51.000/2.000
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#7/46.935/-1.165
> Au niveau 5, deux problèmes sur les régions :
> - pas de repliement de ligne
> - on voit les anciennes régions
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#5/47.606/-1.560
> enfin quoique (Nouvelle Aquitaine, au fait sans trait d'union ?)
>
> Jean-Yvon
>
>
> Le 01/09/2016 à 22:43, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Le 1 septembre 2016 à 10:28, Stéphane Péneau 
> a écrit :
>
> A priori c'était déjà présent sur la version précédente mais je reste
>> parfois surpris par les localités qui ressortent sur les faibles niveau de
>> zoom.
>> Exemple : http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#9
>> /46.9306/-1.1687
>> On aperçoit Saint-Symphorien à l'ouest de Cholet alors que Montaigu,
>> situé pas très loin n'apparait pas.
>>
>> Montaigu est un bourg et une commune, et est la plus importante de cette
>> zone du Nord-Vendé. Le node est donc admin_center de la relation
>> admin_level=8. Il porte le tag place=village
>>
>> Saint-Symphorien n'est qu'un gros hameau d'une commune voisine. Sa
>> classification est un peu sur la ligne qui sépare hamlet de village, mais
>> j'avais choisi "village" car il y a divers services qu'on ne trouve pas en
>> général dans un "hamlet" (cimetière, école, etc..)
>>
>>
> Ces noms sont ajoutés en "remplissage". Il sont placés dans l'ordre de
> population décroissante, mais limités par l'espace environnant.
>
> Dans le cas que tu cites, je pense que les noms alentours empêchent de
> placer "Montaigu", mais qu'il reste assez de place pour ce minuscule St
> Symphorien... même si on essaye de placer ce nom après. Il faudrait qu'à ce
> niveau de zoom le rendu ne descende pas en dessous de "village" ou alors
> augmenter l'espace libre nécessaire pour placer les hamlet en tout dernier
> remplissage... à tester.
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[osm . sanspourriel]

Bonjour, il faudrait tenir compte des admin_level avant la population 
(dans une certaine limite) car on a toujours Saint-Avé (commune de 
l'agglo de Vannes) qui prend le dessus sur Vannes (préfecture) dans le 
rendu français.


C'est bon au niveau 6, pas au niveau 7 et les admin_level sont bien 
renseignés.


http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/51.000/2.000

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#7/46.935/-1.165

Au niveau 5, deux problèmes sur les régions :
- pas de repliement de ligne
- on voit les anciennes régions
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#5/47.606/-1.560
enfin quoique (Nouvelle Aquitaine, au fait sans trait d'union ?)

Jean-Yvon

Le 01/09/2016 à 22:43, Christian Quest - cqu...@openstreetmap.fr a écrit :
Le 1 septembre 2016 à 10:28, Stéphane Péneau 
> a écrit :


A priori c'était déjà présent sur la version précédente mais je
reste parfois surpris par les localités qui ressortent sur les
faibles niveau de zoom.
Exemple :
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#9/46.9306/-1.1687


On aperçoit Saint-Symphorien à l'ouest de Cholet alors que
Montaigu, situé pas très loin n'apparait pas.

Montaigu est un bourg et une commune, et est la plus importante de
cette zone du Nord-Vendé. Le node est donc admin_center de la
relation admin_level=8. Il porte le tag place=village

Saint-Symphorien n'est qu'un gros hameau d'une commune voisine. Sa
classification est un peu sur la ligne qui sépare hamlet de
village, mais j'avais choisi "village" car il y a divers services
qu'on ne trouve pas en général dans un "hamlet" (cimetière, école,
etc..)


Ces noms sont ajoutés en "remplissage". Il sont placés dans l'ordre de 
population décroissante, mais limités par l'espace environnant.


Dans le cas que tu cites, je pense que les noms alentours empêchent de 
placer "Montaigu", mais qu'il reste assez de place pour ce minuscule 
St Symphorien... même si on essaye de placer ce nom après. Il faudrait 
qu'à ce niveau de zoom le rendu ne descende pas en dessous de 
"village" ou alors augmenter l'espace libre nécessaire pour placer les 
hamlet en tout dernier remplissage... à tester.


--
Christian Quest - OpenStreetMap France


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


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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Quest]

Un bug sûrement car ils étaient là avant. J'ai aussi repéré que l'icone des
controle techniques auto manquait aussi.
Une nouvelle mal rendue est celle des bornes de recharge de véhicules
électriques.

Le 1 septembre 2016 à 14:18, Landry Breuil  a
écrit :

> On voulait pas faire apparaitre les emergency=defibrillator a un moment ?
>
> Landry
>
> 2016-09-01 9:14 GMT+02:00 Christian Quest :
> > Pas mal de petites modifications sur le rendu FR sont en test.
> >
> > Vous pouvez voir où j'en suis sur
> > http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740
> >
> > Quoi de neuf ?
> >
> > - de nouvelles icônes pour les commerces
> >
> > - des labels de taille et de couleur variant avec la taille du polygone
> > qu'ils décrivent (texte en vert pour une forêt, plus gros si la forêt est
> > grande, etc)
> >
> > - amélioration des frontières... les pointillés ne devraient plus se
> > mélanger comme avant, les noms ne devraient plus être coupés en bord de
> > metatile
> >
> > - harmonisation des largeurs de routes et réorganisation du tracé des
> layers
> > 1-5
> >
> >
> > Au delà de ces modifications visibles, il y a pas mal de nettoyage des
> > fichiers de la feuille de style pour faciliter sa mise à jour. Quelques
> > améliorations aussi sur les requêtes SQL (une bonne dizaine de requêtes
> de
> > moins par exemple sur le tracé des 5 niveaux de layer).
> >
> > Bref, beaucoup de changements (le détail est sur
> > https://github.com/cquest/osmfr-cartocss/commits/master) qui ont pu
> casser
> > ici ou là des choses que je n'ai pas pu voir, donc si il y a des
> anomalies
> > merci de les signaler avec l'URL sur cette carte umap (qui contient le
> zoom
> > et les coordonnées).
> >
> > --
> > Christian Quest - OpenStreetMap France
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Quest]

Oui, les zoom 0 à 12 sont précalculés, pour le reste j'ai vidé le cache
pour avoir des tuiles utilisant la nouvelle version de la feuille de style.
Elle ne sont pas non plus mises à jour si les données OSM changent, c'est
vraiment pour tester la feuille de style.

A chaque fois que je la met à jour, je vide le cache à partir du zoom 13.

Le 1 septembre 2016 à 10:36, Jérôme Seigneuret 
a écrit :

> Bonjour,
>
> Pour le moment j'ai l'impression que les tuiles ne sont pas générées à
> tous les niveaux en cache.
> Le serveur est en surcharge?. J'ai rien au delà du niveau 12.
>
> Cordialement,
> jérôme
>
> Le 1 septembre 2016 à 09:14, Christian Quest  a
> écrit :
>
>> Pas mal de petites modifications sur le rendu FR sont en test.
>>
>> Vous pouvez voir où j'en suis sur http://umap.openstreetmap.fr/f
>> r/map/test-rendu-osmfr_99740
>>
>> Quoi de neuf ?
>>
>> - de nouvelles icônes pour les commerces
>>
>> - des labels de taille et de couleur variant avec la taille du polygone
>> qu'ils décrivent (texte en vert pour une forêt, plus gros si la forêt est
>> grande, etc)
>>
>> - amélioration des frontières... les pointillés ne devraient plus se
>> mélanger comme avant, les noms ne devraient plus être coupés en bord de
>> metatile
>>
>> - harmonisation des largeurs de routes et réorganisation du tracé des
>> layers 1-5
>>
>>
>> Au delà de ces modifications visibles, il y a pas mal de nettoyage des
>> fichiers de la feuille de style pour faciliter sa mise à jour. Quelques
>> améliorations aussi sur les requêtes SQL (une bonne dizaine de requêtes de
>> moins par exemple sur le tracé des 5 niveaux de layer).
>>
>> Bref, beaucoup de changements (le détail est sur
>> https://github.com/cquest/osmfr-cartocss/commits/master) qui ont pu
>> casser ici ou là des choses que je n'ai pas pu voir, donc si il y a des
>> anomalies merci de les signaler avec l'URL sur cette carte umap (qui
>> contient le zoom et les coordonnées).
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Christian Quest]

Le 1 septembre 2016 à 10:28, Stéphane Péneau  a
écrit :

A priori c'était déjà présent sur la version précédente mais je reste
> parfois surpris par les localités qui ressortent sur les faibles niveau de
> zoom.
> Exemple : http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#9
> /46.9306/-1.1687
> On aperçoit Saint-Symphorien à l'ouest de Cholet alors que Montaigu, situé
> pas très loin n'apparait pas.
>
> Montaigu est un bourg et une commune, et est la plus importante de cette
> zone du Nord-Vendé. Le node est donc admin_center de la relation
> admin_level=8. Il porte le tag place=village
>
> Saint-Symphorien n'est qu'un gros hameau d'une commune voisine. Sa
> classification est un peu sur la ligne qui sépare hamlet de village, mais
> j'avais choisi "village" car il y a divers services qu'on ne trouve pas en
> général dans un "hamlet" (cimetière, école, etc..)
>
>
Ces noms sont ajoutés en "remplissage". Il sont placés dans l'ordre de
population décroissante, mais limités par l'espace environnant.

Dans le cas que tu cites, je pense que les noms alentours empêchent de
placer "Montaigu", mais qu'il reste assez de place pour ce minuscule St
Symphorien... même si on essaye de placer ce nom après. Il faudrait qu'à ce
niveau de zoom le rendu ne descende pas en dessous de "village" ou alors
augmenter l'espace libre nécessaire pour placer les hamlet en tout dernier
remplissage... à tester.

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Landry Breuil]

On voulait pas faire apparaitre les emergency=defibrillator a un moment ?

Landry

2016-09-01 9:14 GMT+02:00 Christian Quest :
> Pas mal de petites modifications sur le rendu FR sont en test.
>
> Vous pouvez voir où j'en suis sur
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740
>
> Quoi de neuf ?
>
> - de nouvelles icônes pour les commerces
>
> - des labels de taille et de couleur variant avec la taille du polygone
> qu'ils décrivent (texte en vert pour une forêt, plus gros si la forêt est
> grande, etc)
>
> - amélioration des frontières... les pointillés ne devraient plus se
> mélanger comme avant, les noms ne devraient plus être coupés en bord de
> metatile
>
> - harmonisation des largeurs de routes et réorganisation du tracé des layers
> 1-5
>
>
> Au delà de ces modifications visibles, il y a pas mal de nettoyage des
> fichiers de la feuille de style pour faciliter sa mise à jour. Quelques
> améliorations aussi sur les requêtes SQL (une bonne dizaine de requêtes de
> moins par exemple sur le tracé des 5 niveaux de layer).
>
> Bref, beaucoup de changements (le détail est sur
> https://github.com/cquest/osmfr-cartocss/commits/master) qui ont pu casser
> ici ou là des choses que je n'ai pas pu voir, donc si il y a des anomalies
> merci de les signaler avec l'URL sur cette carte umap (qui contient le zoom
> et les coordonnées).
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

Sinon dommage qu'on ne voit toujours pas les limites des départements avant
le niveau 11 (où on ne peut pas voir un seule département en entier). Au
niveau 10 on ne voit que les limites des régions (mais aucune région
entière; on les voit dès le niveau 5 avec leur limites).

Je suggère de mettre les limites de département (admin_level 6) visibles
dès le niveau 9 (au moins en France)

A voir aussi pour d'autres pays dont les provinces de Belgique, en
regardant leur étendue moyenne: la couche layers admin_level=6 permet de
voir les tailles moyennes des entités pays par pays (et sur un affichage de
taille VGA où une entité occupe plus de la moitié de la largeur ou la
hauteur de l'écran, ces limites devraient être visibles).

Revoir aussi à partir de quel niveau de zoom les libellés affichés au
centre d'une zone cèdent la place aux libellés le long de la frontière
(pour ne plus masquer les noms des principales localités ou noms de
quartiers aux zoom plus élevés): cela concerne les régions, départements,
voire aussi les arrondissements municipaux de Paris/Lyon/Marseille qui
prendront la place du nom de la commune (transféré le long de la frontière).



Le 1 septembre 2016 à 12:42, Philippe Verdy  a écrit :

> moi non plus, et même pas pour les faibles niveaux de zoom (pas de réponse
> du serveur)
> difficile de voir donc les nouvelles icones.
> En revanche la correction des pointillés (qui se superposent en les
> traçant dans les 2 sens en fusionnant les points et tirets) est un vieux
> bogue qui aurait pu être résolu depuis longtemps en fixant l'ordre du tracé
> selon la position relative du point de départ et d'arrivée, par exemple en
> commençant le découpage des pointillés toujours depuis le point le plus
> haut/nord sinon le plus à gauche/ouest), ou en détectant les traits déjà
> tracés pour les tracer une seule fois.
>
> Le 1 septembre 2016 à 10:36, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> Bonjour,
>>
>> Pour le moment j'ai l'impression que les tuiles ne sont pas générées à
>> tous les niveaux en cache.
>> Le serveur est en surcharge?. J'ai rien au delà du niveau 12.
>>
>> Cordialement,
>> jérôme
>>
>> Le 1 septembre 2016 à 09:14, Christian Quest  a
>> écrit :
>>
>>> Pas mal de petites modifications sur le rendu FR sont en test.
>>>
>>> Vous pouvez voir où j'en suis sur http://umap.openstreetmap.fr/f
>>> r/map/test-rendu-osmfr_99740
>>>
>>> Quoi de neuf ?
>>>
>>> - de nouvelles icônes pour les commerces
>>>
>>> - des labels de taille et de couleur variant avec la taille du polygone
>>> qu'ils décrivent (texte en vert pour une forêt, plus gros si la forêt est
>>> grande, etc)
>>>
>>> - amélioration des frontières... les pointillés ne devraient plus se
>>> mélanger comme avant, les noms ne devraient plus être coupés en bord de
>>> metatile
>>>
>>> - harmonisation des largeurs de routes et réorganisation du tracé des
>>> layers 1-5
>>>
>>>
>>> Au delà de ces modifications visibles, il y a pas mal de nettoyage des
>>> fichiers de la feuille de style pour faciliter sa mise à jour. Quelques
>>> améliorations aussi sur les requêtes SQL (une bonne dizaine de requêtes de
>>> moins par exemple sur le tracé des 5 niveaux de layer).
>>>
>>> Bref, beaucoup de changements (le détail est sur
>>> https://github.com/cquest/osmfr-cartocss/commits/master) qui ont pu
>>> casser ici ou là des choses que je n'ai pas pu voir, donc si il y a des
>>> anomalies merci de les signaler avec l'URL sur cette carte umap (qui
>>> contient le zoom et les coordonnées).
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>>
>> --
>> Cordialement,
>> Jérôme Seigneuret
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Philippe Verdy]

moi non plus, et même pas pour les faibles niveaux de zoom (pas de réponse
du serveur)
difficile de voir donc les nouvelles icones.
En revanche la correction des pointillés (qui se superposent en les traçant
dans les 2 sens en fusionnant les points et tirets) est un vieux bogue qui
aurait pu être résolu depuis longtemps en fixant l'ordre du tracé selon la
position relative du point de départ et d'arrivée, par exemple en
commençant le découpage des pointillés toujours depuis le point le plus
haut/nord sinon le plus à gauche/ouest), ou en détectant les traits déjà
tracés pour les tracer une seule fois.

Le 1 septembre 2016 à 10:36, Jérôme Seigneuret 
a écrit :

> Bonjour,
>
> Pour le moment j'ai l'impression que les tuiles ne sont pas générées à
> tous les niveaux en cache.
> Le serveur est en surcharge?. J'ai rien au delà du niveau 12.
>
> Cordialement,
> jérôme
>
> Le 1 septembre 2016 à 09:14, Christian Quest  a
> écrit :
>
>> Pas mal de petites modifications sur le rendu FR sont en test.
>>
>> Vous pouvez voir où j'en suis sur http://umap.openstreetmap.fr/f
>> r/map/test-rendu-osmfr_99740
>>
>> Quoi de neuf ?
>>
>> - de nouvelles icônes pour les commerces
>>
>> - des labels de taille et de couleur variant avec la taille du polygone
>> qu'ils décrivent (texte en vert pour une forêt, plus gros si la forêt est
>> grande, etc)
>>
>> - amélioration des frontières... les pointillés ne devraient plus se
>> mélanger comme avant, les noms ne devraient plus être coupés en bord de
>> metatile
>>
>> - harmonisation des largeurs de routes et réorganisation du tracé des
>> layers 1-5
>>
>>
>> Au delà de ces modifications visibles, il y a pas mal de nettoyage des
>> fichiers de la feuille de style pour faciliter sa mise à jour. Quelques
>> améliorations aussi sur les requêtes SQL (une bonne dizaine de requêtes de
>> moins par exemple sur le tracé des 5 niveaux de layer).
>>
>> Bref, beaucoup de changements (le détail est sur
>> https://github.com/cquest/osmfr-cartocss/commits/master) qui ont pu
>> casser ici ou là des choses que je n'ai pas pu voir, donc si il y a des
>> anomalies merci de les signaler avec l'URL sur cette carte umap (qui
>> contient le zoom et les coordonnées).
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Jérôme Seigneuret]

Bonjour,

Pour le moment j'ai l'impression que les tuiles ne sont pas générées à tous
les niveaux en cache.
Le serveur est en surcharge?. J'ai rien au delà du niveau 12.

Cordialement,
jérôme

Le 1 septembre 2016 à 09:14, Christian Quest  a
écrit :

> Pas mal de petites modifications sur le rendu FR sont en test.
>
> Vous pouvez voir où j'en suis sur http://umap.openstreetmap.fr/f
> r/map/test-rendu-osmfr_99740
>
> Quoi de neuf ?
>
> - de nouvelles icônes pour les commerces
>
> - des labels de taille et de couleur variant avec la taille du polygone
> qu'ils décrivent (texte en vert pour une forêt, plus gros si la forêt est
> grande, etc)
>
> - amélioration des frontières... les pointillés ne devraient plus se
> mélanger comme avant, les noms ne devraient plus être coupés en bord de
> metatile
>
> - harmonisation des largeurs de routes et réorganisation du tracé des
> layers 1-5
>
>
> Au delà de ces modifications visibles, il y a pas mal de nettoyage des
> fichiers de la feuille de style pour faciliter sa mise à jour. Quelques
> améliorations aussi sur les requêtes SQL (une bonne dizaine de requêtes de
> moins par exemple sur le tracé des 5 niveaux de layer).
>
> Bref, beaucoup de changements (le détail est sur
> https://github.com/cquest/osmfr-cartocss/commits/master) qui ont pu
> casser ici ou là des choses que je n'ai pas pu voir, donc si il y a des
> anomalies merci de les signaler avec l'URL sur cette carte umap (qui
> contient le zoom et les coordonnées).
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[Stéphane Péneau]

A priori c'était déjà présent sur la version précédente mais je reste 
parfois surpris par les localités qui ressortent sur les faibles niveau 
de zoom.
Exemple : 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#9/46.9306/-1.1687
On aperçoit Saint-Symphorien à l'ouest de Cholet alors que Montaigu, 
situé pas très loin n'apparait pas.


Montaigu est un bourg et une commune, et est la plus importante de cette 
zone du Nord-Vendé. Le node est donc admin_center de la relation 
admin_level=8. Il porte le tag place=village


Saint-Symphorien n'est qu'un gros hameau d'une commune voisine. Sa 
classification est un peu sur la ligne qui sépare hamlet de village, 
mais j'avais choisi "village" car il y a divers services qu'on ne trouve 
pas en général dans un "hamlet" (cimetière, école, etc..)




Stf




Le 01/09/2016 à 09:14, Christian Quest a écrit :

Pas mal de petites modifications sur le rendu FR sont en test.

Vous pouvez voir où j'en suis sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740


Quoi de neuf ?

- de nouvelles icônes pour les commerces

- des labels de taille et de couleur variant avec la taille du 
polygone qu'ils décrivent (texte en vert pour une forêt, plus gros si 
la forêt est grande, etc)


- amélioration des frontières... les pointillés ne devraient plus se 
mélanger comme avant, les noms ne devraient plus être coupés en bord 
de metatile


- harmonisation des largeurs de routes et réorganisation du tracé des 
layers 1-5



Au delà de ces modifications visibles, il y a pas mal de nettoyage des 
fichiers de la feuille de style pour faciliter sa mise à jour. 
Quelques améliorations aussi sur les requêtes SQL (une bonne dizaine 
de requêtes de moins par exemple sur le tracé des 5 niveaux de layer).


Bref, beaucoup de changements (le détail est sur 
https://github.com/cquest/osmfr-cartocss/commits/master) qui ont pu 
casser ici ou là des choses que je n'ai pas pu voir, donc si il y a 
des anomalies merci de les signaler avec l'URL sur cette carte umap 
(qui contient le zoom et les coordonnées).





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