Re: [OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

2020-02-03 Par sujet Philippe Verdy 
La mise à jour dit seulement que (pour les ways fermés ou relations de ways
fermées) l'option par défaut n'est plus area=yes, mais area=no). Mais si on
apris la peine d'indiquer area=yes, cela devrait encore être traité comme
une surface et non en linéaire.

Le rendu actuel a bien un bogue puisqu'il ignore maintenant l'indication
*explicite* de l'attribut "area=yes". Le changement de valeur par défaut
aurait dû être comme pour les man_made=pier (pour les digues) ou encore
pour les barrages (linéaires par défaut et sans "épaisseur" indiqué, sauf
si justement on a mis area=yes pour délimiter non pas une ligne centrale
mais un contour)

Que ce soit tagué comme un contour de surface ou comme linéaire, cela reste
une barrière pour le routing qui se limitera au contour de toute façon.

C'est donc une anomalie du rendu, pas des tags utilisés qui sont corrects.
Il n'y a aucun mélange de 2 types de données, on a deux géométries
possibles (linéaire central moyen, ou contour de surface) et clairement
distinguées par l'attribut explicite area=yes/no (maintenant on a "area=no"
par défaut et non plus "area=yes").



Le lun. 3 févr. 2020 à 07:46, Stéphane Péneau 
a écrit :

> Le 02/02/2020 à 20:48, François Lacombe a écrit :
>
>
> Le dim. 2 févr. 2020 à 18:41, pepilepi...@ovh.fr  a
> écrit :
>
>> Le 02/02/2020 à 14:50, Stéphane Péneau a écrit :
>>
>> Ça m'a tout cassé mes jolies haies  :-(((
>>
>> https://www.openstreetmap.org/#map=19/47.09460/-1.35571
>>
>> Natural=scrub est-il incompatible ici ? (si tu veux retrouver tes jolies
>> haies...)
>>
>
> C'est plutôt pour la broussaille basse, les haies peuvent être composées
> d'arbres à part entière.
> Et le rendu vert kaki reflète peu la broussaille qu'on trouve ici je trouve
>
> De plus, les haies sont des barrières, ça n'a pas la même implication pour
> le routing.
> Il y a une partie des haies que j'ai tracées à l'époque, qui devraient
> être moins larges qu'elles ne le sont. Les images sont meilleures
> maintenant.
>
>
> Bon, je ne vais pas en faire tout un foin, c'est juste le rendu, et je
> crois que je n'ai pas tout compris aux discussions sur le ticket. De mon
> point de vue, un landuse=meadow + barrier=hedge, c'est mélanger 2 types de
> données.
>
> https://github.com/gravitystorm/openstreetmap-carto/pull/3844
>
>
> Stf
> ___
> 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] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

2020-02-02 Par sujet Stéphane Péneau 

Le 02/02/2020 à 20:48, François Lacombe a écrit :


Le dim. 2 févr. 2020 à 18:41, pepilepi...@ovh.fr 
 > a écrit :


Le 02/02/2020 à 14:50, Stéphane Péneau a écrit :


Ça m'a tout cassé mes jolies haies  :-(((

https://www.openstreetmap.org/#map=19/47.09460/-1.35571


Natural=scrub est-il incompatible ici ? (si tu veux retrouver tes
jolies haies...)


C'est plutôt pour la broussaille basse, les haies peuvent être 
composées d'arbres à part entière.
Et le rendu vert kaki reflète peu la broussaille qu'on trouve ici je 
trouve


De plus, les haies sont des barrières, ça n'a pas la même implication 
pour le routing.


Il y a une partie des haies que j'ai tracées à l'époque, qui devraient 
être moins larges qu'elles ne le sont. Les images sont meilleures 
maintenant.



Bon, je ne vais pas en faire tout un foin, c'est juste le rendu, et je 
crois que je n'ai pas tout compris aux discussions sur le ticket. De mon 
point de vue, un landuse=meadow + barrier=hedge, c'est mélanger 2 types 
de données.


https://github.com/gravitystorm/openstreetmap-carto/pull/3844


Stf

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

Re: [OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

2020-02-02 Par sujet François Lacombe 
Le dim. 2 févr. 2020 à 18:41, pepilepi...@ovh.fr  a
écrit :

> Le 02/02/2020 à 14:50, Stéphane Péneau a écrit :
>
> Ça m'a tout cassé mes jolies haies  :-(((
>
> https://www.openstreetmap.org/#map=19/47.09460/-1.35571
>
> Natural=scrub est-il incompatible ici ? (si tu veux retrouver tes jolies
> haies...)
>

C'est plutôt pour la broussaille basse, les haies peuvent être composées
d'arbres à part entière.
Et le rendu vert kaki reflète peu la broussaille qu'on trouve ici je trouve

Le dim. 2 févr. 2020 à 19:34,  a écrit :

> Sauf que Stéphane a bien mis area=yes.
>
> https://www.openstreetmap.org/way/458961507
>
> Stéphane, je crois que tu vas pouvoir ouvrir un ticket sur le sujet.
>
Le parti pris est bien de ne plus supporter area=yes sur barrier=hedge
(sans me prononcer si c'est bien ou mal)
https://github.com/gravitystorm/openstreetmap-carto/pull/3844

Bonne soirée

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

Re: [OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

2020-02-02 Par sujet Philippe Verdy 
C'est bien ce que je disais... Le area=yes n'est plus pris en compte. Je ne
me suis pas trompé en disant ça.

Le dim. 2 févr. 2020 à 19:34,  a écrit :

> Sauf que Stéphane a bien mis area=yes.
>
> https://www.openstreetmap.org/way/458961507
>
> Stéphane, je crois que tu vas pouvoir ouvrir un ticket sur le sujet.
>
> Jean-Yvon
> Le 02/02/2020 à 16:54, Philippe Verdy - ver...@gmail.com a écrit :
>
> effectivement, le tag area=yes n'est plus rendu sur les barrier=* qui
> redeviennent linéaires (qui n'est que leur valeur area=no par défaut...)
>
> Le dim. 2 févr. 2020 à 14:50, Stéphane Péneau 
> a écrit :
>
>> Le 01/02/2020 à 11:18, marc marc a écrit :
>> > * Supprimer le rendu de remplissage des polygones pour les zones de
>> > barrier=hedge (#3844)
>> >   Cela rend le rendu cohérent entre les murs et les haies en tant
>> que
>> > zones
>>
>> Ça m'a tout cassé mes jolies haies  :-(((
>>
>> https://www.openstreetmap.org/#map=19/47.09460/-1.35571
>>
>> Stf
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

2020-02-02 Par sujet osm . sanspourriel 

Sauf que Stéphane a bien mis area=yes.

https://www.openstreetmap.org/way/458961507

Stéphane, je crois que tu vas pouvoir ouvrir un ticket sur le sujet.

Jean-Yvon

Le 02/02/2020 à 16:54, Philippe Verdy - ver...@gmail.com a écrit :

effectivement, le tag area=yes n'est plus rendu sur les barrier=* qui
redeviennent linéaires (qui n'est que leur valeur area=no par défaut...)

Le dim. 2 févr. 2020 à 14:50, Stéphane Péneau
mailto:stephane.pen...@wanadoo.fr>> a écrit :

Le 01/02/2020 à 11:18, marc marc a écrit :
> * Supprimer le rendu de remplissage des polygones pour les zones de
> barrier=hedge (#3844)
>       Cela rend le rendu cohérent entre les murs et les haies en
tant que
> zones

Ça m'a tout cassé mes jolies haies  :-(((

https://www.openstreetmap.org/#map=19/47.09460/-1.35571

Stf

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

Re: [OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

2020-02-02 Par sujet pepilepi...@ovh.fr 
Le 02/02/2020 à 14:50, Stéphane Péneau a écrit :
> Le 01/02/2020 à 11:18, marc marc a écrit :
>> * Supprimer le rendu de remplissage des polygones pour les zones de
>> barrier=hedge (#3844)
>>   Cela rend le rendu cohérent entre les murs et les haies en tant
>> que
>> zones
>
> Ça m'a tout cassé mes jolies haies  :-(((
>
> https://www.openstreetmap.org/#map=19/47.09460/-1.35571

Natural=scrub est-il incompatible ici ? (si tu veux retrouver tes jolies
haies...)

Bonne soirée,

JP

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


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

Re: [OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

2020-02-02 Par sujet Philippe Verdy 
effectivement, le tag area=yes n'est plus rendu sur les barrier=* qui
redeviennent linéaires (qui n'est que leur valeur area=no par défaut...)

Le dim. 2 févr. 2020 à 14:50, Stéphane Péneau 
a écrit :

> Le 01/02/2020 à 11:18, marc marc a écrit :
> > * Supprimer le rendu de remplissage des polygones pour les zones de
> > barrier=hedge (#3844)
> >   Cela rend le rendu cohérent entre les murs et les haies en tant que
> > zones
>
> Ça m'a tout cassé mes jolies haies  :-(((
>
> https://www.openstreetmap.org/#map=19/47.09460/-1.35571
>
> Stf
>
> ___
> 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] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

2020-02-02 Par sujet Stéphane Péneau 

Le 01/02/2020 à 11:18, marc marc a écrit :

* Supprimer le rendu de remplissage des polygones pour les zones de
barrier=hedge (#3844)
  Cela rend le rendu cohérent entre les murs et les haies en tant que
zones


Ça m'a tout cassé mes jolies haies  :-(((

https://www.openstreetmap.org/#map=19/47.09460/-1.35571

Stf

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

Re: [OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

2020-02-01 Par sujet Philippe Verdy 
Le sam. 1 févr. 2020 à 11:18, marc marc  a
écrit :

> * Supprimer le rendu de barrier=kerb (#3969)
>  Cette caractéristique n'est pas similaire aux barrières courantes
> (clôtures et murs)
>

On ne verra plus les trottoirs fort bien tracés précisément à Dunkerque
(Malo-les-Bains) par un contributeur visiblement patient et chevronné, et
dont le rendu était impeccable et marqués avec "kerb" (les bordures de
trottoirs, utiles pour le parcours des personnes à mobilité réduite en
fauteuil, mais il faut aussi des tags pour les bordures surbaissées si ce
n'est pas autour d'un passage piéton marqué, dont on n'a pas de chemin pour
la traversée mais juste un nœud central sur la chaussée).

Ceci dit, pour nos périphéries urbaines peu denses (lotissements), le tracé
des seules maisons et des rues ainsi que les points d'adresse ne suffit pas
au repérage: on ne sait toujours pas comment accéder à ces adresses et par
quelle rue précisément, ni où chercher les allées d'accès.

C'est aussi utile dans des villages anciens aux rues et ruelles compliquées
et aux bâtiments peu réguliers et diversement placés et orientés voire
partiellement imbriqués les uns dans les autres, dont les accès ne sont pas
évidents avec le seul point d'adresse. De même les points d'adresse y sont
peu corrélés aux tracés des voies publiques (du FANTOIR).

Il faudrait donc investir dans les allées d'accès, mais aussi les clôtures,
haies et et murs de séparation mitoyenne, qui offrent un excellent moyen de
repérage (même avant de parler des arbres qui sont aussi un repérage une
fois sur le terrain, surtout dans les zones résidentielles peu denses qui
n'ont pas beaucoup de différences marquées sur la carte). Les emplacements
de panneaux publicitaires sont utiles aussi mais moins dans ces zones où il
y en a peu, du fait du trafic faible hors des voies principales.

Cela rend les adresses nettement plus claires, et le guidage  plus facile
dans ces zones résidentielles peu denses, avec des jardins et allées
privées (dont il faudrait aussi marquer les portails et tracer le chemin
derrière qui peut être assez long et entre plusieurs propriétés, pas
toujours cernées de clotures/haies/murs).

Les "expériences" menées ça et là dans plusieurs villes et ébauchées dans
certains secteurs sont assez convaincantes, je trouve, même sans aller au
tracé précis des bordures de trottoirs dans les zones denses. Pour ça
l'imagerie BDOrtho peut permettre d'aller assez vite (même si par endroit
on peut avoir des ambiguïtés (à lever et corriger plus tard si on a un
relevé terrestre) entre clôture bordées de plantations arborescentes et
véritables haies, ou bien des arbres d'un côté ou l'autre peuvent cacher si
c'est une haie, une clôture ou un mur/muet.

Mais c'est assez fidèle à ce qu'on voit (la précision centimétrique des
clôtures n'est pas strictement nécessaire, on peut avoir des petits écarts
de géométrie quand il y a de la végétation, notamment avec les haies et
autres plantations humaines (ou naturelles dans les recoins). Si on veut
affiner il reste encore le cadastre mais ce n'est pas toujours facile à
lire avec son découpage parcellaire historique dont les limites ne
correspondent plus à rien du fait des assemblages de parcelles aujourd'hui
utilisées en un seul tenant.

Enfin il manque encore pas mal de chemins piétons/cyclistes publics entre
les rues et passant entre les propriétés ou derrière. C'est utile pour la
circulation à pied ou vélo, y compris le cheminement des enfants vers leur
école.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

2020-02-01 Par sujet marc marc 
Bonjour,

maj du rendu par défaut d'osm.org
Il n'est pas encore déployé et quand il le sera,
cela prendre comme d'habitude un peu de temps
pour tout mettre à jour.

J'ai retenu ci-dessous les points les plus important :

* Suppression du rendu de barrier=embankment (#4010)
Les remblais sont désormais communément étiquetés avec
man_made=embankment ou man_made=dyke

* Supprimer le rendu de barrier=kerb (#3969)
 Cette caractéristique n'est pas similaire aux barrières courantes
(clôtures et murs)

* Suppression de la couleur de remplissage boundary=protected_area à bas
niveau de zoom (#3887)

* Supprimer le rendu de remplissage des polygones pour les zones de
barrier=hedge (#3844)
 Cela rend le rendu cohérent entre les murs et les haies en tant que
zones

* Enlever l'étiquette de texte de l'opérateur pour la plupart des
amenity=vending_machine (#3965)
L'étiquette Operator= est toujours affichée pour les tickets de
transport public vending=public_transport

* Ajouter l'icône svg pour parking=multi-storey +
amenity=parking_entrance (#3599)


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