Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Florian LAINEZ]

 Salut,
Je vois que le thread original sur le rendu a dévié sur un débat concernant
les modèles de transport héhé.
C'est bien que l'on s'y penche, mais je ne rentrerai pas dans les multiples
débats lancés ...
Ma position est que l'on doit faciliter/accélérer la transition vers le
modèle v2 tout en garantissant la compatibilité v1 pour l'instant.

Allez combien de nouveaux contributeurs pour entrer des arrêts de bus ? Au
> SOTM on disait pourtant qu'il fallait abaisser le ticket d'entrée. Là c'est
> un bel exemple du contraire. J'attends un outil de la part des promoteurs
> de la V2 permettant à tout un chacun de contribuer.

Ouiii ! J'y travaille et espère vous présenter quelque chose de potable
au SotM-fr 2017.

Le 31 décembre 2016 à 13:31, Philippe Verdy  a écrit :

>
>
> Le 31 décembre 2016 à 13:05,  a écrit :
>
>> Le 30/12/2016 à 23:15, Philippe Verdy - verd...@wanadoo.fr a écrit :
>>
>> Le 30 décembre 2016 à 21:29,  a écrit :
>>
>>> Et 4 lignes 13 parce que la STAR n'indique pas un 13N et un 13S (ou
>>> autre variante de dénomination) pour distinguer 2 lignes en fourche.
>>>
>> Là tu te trompes sur toute la ligne, elle distingue bien chaque
>> itinéraire et sens de chaque ligne. Tu n'as pas regardé l'OpenData
>>
>> Visiblement tu as un problème de compréhension avec le français ou de
>> lecture.
>> Que peut dire l'OpenData hormis que la STAR/Keolis Rennes nomme deux
>> lignes ayant un tronçon commun "13" (et non plus lisiblement 13N et 13S par
>> exemple) ? Et confirme ainsi ce que j'ai écrit : "c'est le nommage qui est
>> en cause".
>>
>
> Encore une fois tu n'as pas regardé l'Open Data, il y a des références
> distinctes pour chaque itinéraire et chaque direction (non pas 13N/13S mais
> 0013-01-A, 0013-01-B, 013-02-A, 0013-02B...
> Quant aux bus eux-mêmes ils indiquent le nom de la variante en indiquant
> la destination et "via" en cas de besoin.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Philippe Verdy]

Le 31 décembre 2016 à 13:05,  a écrit :

> Le 30/12/2016 à 23:15, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Le 30 décembre 2016 à 21:29,  a écrit :
>
>> Et 4 lignes 13 parce que la STAR n'indique pas un 13N et un 13S (ou autre
>> variante de dénomination) pour distinguer 2 lignes en fourche.
>>
> Là tu te trompes sur toute la ligne, elle distingue bien chaque itinéraire
> et sens de chaque ligne. Tu n'as pas regardé l'OpenData
>
> Visiblement tu as un problème de compréhension avec le français ou de
> lecture.
> Que peut dire l'OpenData hormis que la STAR/Keolis Rennes nomme deux
> lignes ayant un tronçon commun "13" (et non plus lisiblement 13N et 13S par
> exemple) ? Et confirme ainsi ce que j'ai écrit : "c'est le nommage qui est
> en cause".
>

Encore une fois tu n'as pas regardé l'Open Data, il y a des références
distinctes pour chaque itinéraire et chaque direction (non pas 13N/13S mais
0013-01-A, 0013-01-B, 013-02-A, 0013-02B...
Quant aux bus eux-mêmes ils indiquent le nom de la variante en indiquant la
destination et "via" en cas de besoin.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[osm . sanspourriel]

Le 30/12/2016 à 23:15, Philippe Verdy - verd...@wanadoo.fr a écrit :

Le 30 décembre 2016 à 21:29, > a écrit :


Et 4 lignes 13 parce que la STAR n'indique pas un 13N et un 13S
(ou autre variante de dénomination) pour distinguer 2 lignes en
fourche.

Là tu te trompes sur toute la ligne, elle distingue bien chaque 
itinéraire et sens de chaque ligne. Tu n'as pas regardé l'OpenData
Visiblement tu as un problème de compréhension avec le français ou de 
lecture.
Que peut dire l'OpenData hormis que la STAR/Keolis Rennes nomme deux 
lignes ayant un tronçon commun "13" (et non plus lisiblement 13N et 13S 
par exemple) ? Et confirme ainsi ce que j'ai écrit : "c'est le nommage 
qui est en cause".


Le 30/12/2016 à 23:03, Philippe Verdy - verd...@wanadoo.fr a écrit :

Tu parles d'incompatibilité, sans en dé"montrer aucune.
Je pourrais rappeler l'existence même de la clé public_transport:version 
 qui 
si les schémas étaient compatibles et incrémentaux n'aurait aucun intérêt.


Je pourrais citer le message de Christian sur le problème de rendu avec 
Imposm, la disparition d'arrêts de bus si on applique le schéma V2 tel 
qu'indiqué dans le wiki.
Extrait du ticket JOSM 9545  
: /IMHO it is currently more or less required to tag both schemes, e.g. 
highway=bus_stop and public_transport=platform + bus=yes to get decent 
support in most applications.//
/Ce qui logiquement impliquerait que l'on écrive 
public_transport:version 
=1;2.


Si tu préfères un plus ancien :
Le 31/10/2016 à 12:21, Philippe Verdy - verd...@wanadoo.fr a écrit :
Ce serait moi je virerais même la compatibilité avec le non-schéma v1 
en ne gardant que le schéma v2 qui est clair, ce qui pousserait alors 
les outils à s'adapter pour gérer correctement la v2.
Maintenant si tu appelle compatibilité (ascendante en plus car tu parles 
de modification incrémentale) le fait de tagguer deux fois un même arrêt 
de bus...


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Philippe Verdy]

Le 30 décembre 2016 à 21:29,  a écrit :

> Et 4 lignes 13 parce que la STAR n'indique pas un 13N et un 13S (ou autre
> variante de dénomination) pour distinguer 2 lignes en fourche.
>
Là tu te trompes sur toute la ligne, elle distingue bien chaque itinéraire
et sens de chaque ligne. Tu n'as pas regardé l'OpenData
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Philippe Verdy]

Tu parles d'incompatibilité, sans en dé"montrer aucune.


Le 30 décembre 2016 à 21:29,  a écrit :

> Le 30/12/2016 à 12:24, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Il n'y a pas plus d'hypothèses, et non il y a moins de risques d'erreurs,
> et j'ai pu le voir à de nombreuses reprises
>
>
> Le 30/12/2016 à 12:24, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Franchement là c'est de la mauvaise foi!
>
> Parole d'expert, de la part de quelqu'un qui soutient que remplacer
> quelque chose par autre chose d'incompatible (notamment avec les rendus)
> est incrémental...
>
> Si tu associes le mauvais stop_position au platform, la vérification
> "validera" ton erreur.
> Si tu veux dire que JOSM montre assez facilement si l'ordre logique des
> ways est respecté, c'est vrai mais en général les plans de ligne sont
> disponibles. Normalement on sait de quel côté on prend le bus et donc on
> sait associer un arrêt et le sens pour les lignes.
> Si on ne sait pas, alors on fera la mauvaise association et la
> vérification "validera" l'erreur.
> Mais heureux de voir que le bordel créé par ce schéma incompatible en
> ravisse certains.
> Reste juste à espérer que leur motivation compensera celle de tous ceux
> qui ne voudront pas se plonger dedans.
> Ou même ceux qui voudront (comme Jérôme).
> "Le name se met sur les deux, là encore aucune incompatibilité"
> Heu, elle sert à quoi alors la relation stop_area ? Tant que tous les
> arrêts ont le même nom, inutile de l'indiquer X fois.
> http://www.openstreetmap.org/query?lat=48.0879=-1.6171
> 4 arrêts de bus et 4 arrêts *des*  bus. Par contre la relation stop_area
> (le seul gain pour monsieur tout le monde - quoique avec le même nom il
> doit avoir une petite idée) n'est pas affiché alors qu'Overpass-turbo
>  la trouve bien.
> Et 4 lignes 13 parce que la STAR n'indique pas un 13N et un 13S (ou autre
> variante de dénomination) pour distinguer 2 lignes en fourche.
> Mais là ni la V2 ni une V3 ne sont la solution, c'est le nommage qui est
> en cause. Et pourtant la renumérotation des lignes, la STAR en est
> spécialiste .../17/7/C1, 33/13... Car pour eux le numéro donne une idée de
> la priorité des lignes.
>
> À propos de précision métrique : la porte accessible handicapée est en
> général la porte du milieu alors que la porte normale de montée est la
> porte avant (pas systématique). Tu veux ajouter la position où doit
> attendre la personne en fauteuil ?
>
> Jean-Yvon
>
> ___
> 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, bientôt en version 2017 !

[osm . sanspourriel]

Le 30/12/2016 à 12:24, Philippe Verdy - verd...@wanadoo.fr a écrit :

Il n'y a pas plus d'hypothèses, et non il y a moins de risques 
d'erreurs, et j'ai pu le voir à de nombreuses reprises


Le 30/12/2016 à 12:24, Philippe Verdy - verd...@wanadoo.fr a écrit :

Franchement là c'est de la mauvaise foi!
Parole d'expert, de la part de quelqu'un qui soutient que remplacer 
quelque chose par autre chose d'incompatible (notamment avec les rendus) 
est incrémental...


Si tu associes le mauvais stop_position au platform, la vérification 
"validera" ton erreur.
Si tu veux dire que JOSM montre assez facilement si l'ordre logique des 
ways est respecté, c'est vrai mais en général les plans de ligne sont 
disponibles. Normalement on sait de quel côté on prend le bus et donc on 
sait associer un arrêt et le sens pour les lignes.
Si on ne sait pas, alors on fera la mauvaise association et la 
vérification "validera" l'erreur.
Mais heureux de voir que le bordel créé par ce schéma incompatible en 
ravisse certains.
Reste juste à espérer que leur motivation compensera celle de tous ceux 
qui ne voudront pas se plonger dedans.

Ou même ceux qui voudront (comme Jérôme).
"Le name se met sur les deux, là encore aucune incompatibilité"
Heu, elle sert à quoi alors la relation stop_area ? Tant que tous les 
arrêts ont le même nom, inutile de l'indiquer X fois.

http://www.openstreetmap.org/query?lat=48.0879=-1.6171
4 arrêts de bus et 4 arrêts /des/  bus. Par contre la relation stop_area 
(le seul gain pour monsieur tout le monde - quoique avec le même nom il 
doit avoir une petite idée) n'est pas affiché alors qu'Overpass-turbo 
 la trouve bien.
Et 4 lignes 13 parce que la STAR n'indique pas un 13N et un 13S (ou 
autre variante de dénomination) pour distinguer 2 lignes en fourche.
Mais là ni la V2 ni une V3 ne sont la solution, c'est le nommage qui est 
en cause. Et pourtant la renumérotation des lignes, la STAR en est 
spécialiste .../17/7/C1, 33/13... Car pour eux le numéro donne une idée 
de la priorité des lignes.


À propos de précision métrique : la porte accessible handicapée est en 
général la porte du milieu alors que la porte normale de montée est la 
porte avant (pas systématique). Tu veux ajouter la position où doit 
attendre la personne en fauteuil ?


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Philippe Verdy]

Le 30 décembre 2016 à 11:31,  a écrit :

> N. B. : pour la vérification fine tu fais l'hypothèse que le stop_position
> est associé au bon platform. Plus de vérifications avec plus d'hypothèses
> et plus de risques de faire des erreurs.
>
Franchement là c'est de la mauvaise foi! Il n'y a pas plus d'hypothèses, et
non il y a moins de risques d'erreurs, et j'ai pu le voir à de nombreuses
reprises
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[osm . sanspourriel]

Le 30/12/2016 à 09:10, Philippe Verdy - verd...@wanadoo.fr a écrit :


ou alors il faut mettre plusieurs noeuds "platform" sur le même quai...

Ça semble le B.A.-BA.
Si on n'attend pas le bus à l'endroit où s'arrête le bus, il y a comme 
un problème.


Comme tu l'as dit, stop_position n'est pas pour le rendu générique. Donc 
si tu veux que les gens aillent au bon endroit, tu dois l'indiquer.


N. B. : pour la vérification fine tu fais l'hypothèse que le 
stop_position est associé au bon platform. Plus de vérifications avec 
plus d'hypothèses et plus de risques de faire des erreurs.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Philippe Verdy]

"bus=yes" n'impacte pas non plus le rendu générique des platform
(d'ailleurs je trouve dommage que les plateformes, également codées
"bus_stop", ne puissent pas être multimodales, par exemple tram+bus+taxi).
Mais cela ne donne aucune incompatibilité. Je ne vois pas où cela pose
problème
Le name se met sur les deux, là encore aucune incompatibilité (certaines
plateformes non réduites à un seul nom mais un quai tout entier comportent
plusieurs arrêts et plusieurs abris alignés, avec des références
différentes dans les OpenData, et seul le stop_position permet de les
distinguer, ou alors il faut mettre plusieurs noeuds "platform" sur le même
quai...)

bref highway=bus_stop peut tout à fait fonctionner (en redondance) en plus
du platform v2 sur le même noeud. Le seul gros nettoyage à faire est de
s'assurer que ces bus_stop ne sont pas au milieu de la voie mais bien sur
le trottoir (du bon côté...) sur la "platfeform",

Ensuite cela permet de déterminer correctement le sens de l'arrêt, le côté
de montée (dans le bus en principe à droite en France à moins que ce soit
des bus anglais qui ne pourront pas utiliser tous les arrêts et utiliser
uniquement la montée et la descente à l'avant mais pas la porte centrale;
mais pas forcément le cas pour les trains qui ont des portes des deux cotés
selon la disposition des quais en gare et le nombre de voies ou parce que
les trains en terminus vont dans les deux sens sur la même voie sans
changer de quai, tandis que les bus vont d'abord faire un demi-tour pour
revenir à un autre arrêt de départ ou ont leur terminus sur une voie de
service unidirectionnelle destinée à leur permettre le demi-tour, ou vont
faire demi-tour à un giratoire à côté; certaines lignes n'ont qu'un seul
arrêt au terminus, le bus ne s'arrêtant qu'en dans un seul sens après avoir
fait déjà demi-tour, avec montée et descente au même point)

Le schéma v2 permet les vérifications fines d'itinéraires et de détecter
facilement les arrêts sélectionnés dans le mauvais sens (détection
impossible par simple recherche géométrique). JOSM le fait très bien !

Le 29 décembre 2016 à 21:51, Christian Quest  a
écrit :

> Le 29 décembre 2016 à 20:50, Jérôme Amagat  a
> écrit :
>
>> Avec cette version 2 et comme c'est prévu, c'est à dire que le seul
>> endroit où on fait la différence entre arrêt de bus et arrêt de tram par
>> exemple c'est le tag bus=yes avec le tag public_transport=stop_position,
>> c'est possible de placer sur le rendu un symbole de bus au niveau de la
>> platform? ou il faut d'autre tags comme highway=bus_stop ou bus=yes avec
>> public_transport=platform? ou il faut placer sur le rendu au niveau du
>> stop_position?
>>
>
> Justement, le problème c'est ce bus=yes... qui d'après la lecture du wiki
> se met sur le stop_position et pas le platform :(
>
> Et si il n'y avait que ça... le nom de l'arrêt est aussi sur le
> stop_position, le name est celui du quai (platform)...
>
> Du coup, côté rendu ça oblige à soit faire du préprocessing des données,
> soit à faire des requêtes complexes via la géométrie (y a-t-il un
> stop_position + bus=yes à proximité) ou en repassant par les relations, ce
> qu'on peut éventuellement faire sur une base osm2pgsql (mais pas simple)
> mais pas sur une base type imposm.
>
> On ne taggue pas pour le rendu, mais si les modèles sont trop complexes,
> et bien il ne faut pas s'étonner que les rendus ne permettent pas de
> visualiser le résultat et ne pas non plus s'étonner que les contributeurs.
>
> Si j'arrive à sortir quelque chose de correct, je le proposerai en PR sur
> le rendu international, mais ça m'étonnerai que ça passe vu le bricolage à
> faire au niveau SQL.
>
> Moralité... un bon vieux highway=bus_stop ne fait pas de mal !
>
>
> --
> 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, bientôt en version 2017 !

[Christian Quest]

Le 29 décembre 2016 à 20:50, Jérôme Amagat  a
écrit :

> Avec cette version 2 et comme c'est prévu, c'est à dire que le seul
> endroit où on fait la différence entre arrêt de bus et arrêt de tram par
> exemple c'est le tag bus=yes avec le tag public_transport=stop_position,
> c'est possible de placer sur le rendu un symbole de bus au niveau de la
> platform? ou il faut d'autre tags comme highway=bus_stop ou bus=yes avec
> public_transport=platform? ou il faut placer sur le rendu au niveau du
> stop_position?
>

Justement, le problème c'est ce bus=yes... qui d'après la lecture du wiki
se met sur le stop_position et pas le platform :(

Et si il n'y avait que ça... le nom de l'arrêt est aussi sur le
stop_position, le name est celui du quai (platform)...

Du coup, côté rendu ça oblige à soit faire du préprocessing des données,
soit à faire des requêtes complexes via la géométrie (y a-t-il un
stop_position + bus=yes à proximité) ou en repassant par les relations, ce
qu'on peut éventuellement faire sur une base osm2pgsql (mais pas simple)
mais pas sur une base type imposm.

On ne taggue pas pour le rendu, mais si les modèles sont trop complexes, et
bien il ne faut pas s'étonner que les rendus ne permettent pas de
visualiser le résultat et ne pas non plus s'étonner que les contributeurs.

Si j'arrive à sortir quelque chose de correct, je le proposerai en PR sur
le rendu international, mais ça m'étonnerai que ça passe vu le bricolage à
faire au niveau SQL.

Moralité... un bon vieux highway=bus_stop ne fait pas de mal !


-- 
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, bientôt en version 2017 !

[Jérôme Amagat]

Avec cette version 2 et comme c'est prévu, c'est à dire que le seul endroit
où on fait la différence entre arrêt de bus et arrêt de tram par exemple
c'est le tag bus=yes avec le tag public_transport=stop_position, c'est
possible de placer sur le rendu un symbole de bus au niveau de la platform?
ou il faut d'autre tags comme highway=bus_stop ou bus=yes avec
public_transport=platform? ou il faut placer sur le rendu au niveau du
stop_position?

Le 29 décembre 2016 à 20:35, Philippe Verdy  a écrit :

> Eh bien non, car le schéma ne supprime rien, c'est une évolution.
> Rappel bus_stop = platform
>
> Moi cette histoire je trouve que c'est pas claire du tout sur le wiki et
tant que la version 2 n'est pas sur le rendu le plus utilisé ça sera dur de
le faire utiliser par tous.


>
> Le 29 décembre 2016 à 19:13,  a écrit :
>
>> Le 29/12/2016 à 14:21, Philippe Verdy - verd...@wanadoo.fr a écrit :
>>
>> Rappelons que ce projet avance de façon incrémentale.
>>
>> Non justement, il faut tout reprendre à zéro (en s'aidant de l'existant)
>> car les schémas sont incompatibles.
>>
>> C'est bien là le problème. Si les stop_position s'ajoutaient sans rien
>> casser, je n'aurais rien contre. Mais quand j'entends les mêmes qui
>> trouvent ça super important dire qu'il suffit de le mettre au droit de la
>> plateforme sur la voie...
>>
>> L'incrément c'est quand on garde l'existant et qu'on construit dessus.
>> J'attends de voir des stop_position permettant à la personne handicapée
>> d'attendre devant le bon wagon ou même le bon train (cas des gares terminus
>> où deux rames partent ensemble mais se séparent plus tard).
>>
>> S'il est aveugle, à par demander de l'aide...
>>
>> Et pour 99% des bus, ils s'arrêtent devant... l'arrêt. Étonnant non ?
>> Savoir si le trottoir est rehaussé, savoir s'il y a une dalle podotactile
>> l'aidera plus que de savoir que le bus s'arrête devant l'arrêt.
>>
>> On peut aussi parler des trains, RER par exemple, de longueur variable.
>>
>> Allez combien de nouveaux contributeurs pour entrer des arrêts de bus ?
>> Au SOTM on disait pourtant qu'il fallait abaisser le ticket d'entrée. Là
>> c'est un bel exemple du contraire. J'attends un outil de la part des
>> promoteurs de la V2 permettant à tout un chacun de contribuer.
>>
>> Si ça permet de corriger 0,01 % de l'heuristique mais fait perdre 10 %
>> d'arrêts, on a amplifié le problème d'un facteur 1 000.
>>
>> Jean-Yvon
>>
>>
>>
>>
>>
>>
>> ___
>> 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] Rendu FR, bientôt en version 2017 !

[Philippe Verdy]

Eh bien non, car le schéma ne supprime rien, c'est une évolution.
Rappel bus_stop = platform


Le 29 décembre 2016 à 19:13,  a écrit :

> Le 29/12/2016 à 14:21, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Rappelons que ce projet avance de façon incrémentale.
>
> Non justement, il faut tout reprendre à zéro (en s'aidant de l'existant)
> car les schémas sont incompatibles.
>
> C'est bien là le problème. Si les stop_position s'ajoutaient sans rien
> casser, je n'aurais rien contre. Mais quand j'entends les mêmes qui
> trouvent ça super important dire qu'il suffit de le mettre au droit de la
> plateforme sur la voie...
>
> L'incrément c'est quand on garde l'existant et qu'on construit dessus.
> J'attends de voir des stop_position permettant à la personne handicapée
> d'attendre devant le bon wagon ou même le bon train (cas des gares terminus
> où deux rames partent ensemble mais se séparent plus tard).
>
> S'il est aveugle, à par demander de l'aide...
>
> Et pour 99% des bus, ils s'arrêtent devant... l'arrêt. Étonnant non ?
> Savoir si le trottoir est rehaussé, savoir s'il y a une dalle podotactile
> l'aidera plus que de savoir que le bus s'arrête devant l'arrêt.
>
> On peut aussi parler des trains, RER par exemple, de longueur variable.
>
> Allez combien de nouveaux contributeurs pour entrer des arrêts de bus ? Au
> SOTM on disait pourtant qu'il fallait abaisser le ticket d'entrée. Là c'est
> un bel exemple du contraire. J'attends un outil de la part des promoteurs
> de la V2 permettant à tout un chacun de contribuer.
>
> Si ça permet de corriger 0,01 % de l'heuristique mais fait perdre 10 %
> d'arrêts, on a amplifié le problème d'un facteur 1 000.
>
> Jean-Yvon
>
>
>
>
>
>
> ___
> 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, bientôt en version 2017 !

[osm . sanspourriel]

Le 29/12/2016 à 14:21, Philippe Verdy - verd...@wanadoo.fr a écrit :

Rappelons que ce projet avance de façon incrémentale.


Non justement, il faut tout reprendre à zéro (en s'aidant de l'existant) 
car les schémas sont incompatibles.


C'est bien là le problème. Si les stop_position s'ajoutaient sans rien 
casser, je n'aurais rien contre. Mais quand j'entends les mêmes qui 
trouvent ça super important dire qu'il suffit de le mettre au droit de 
la plateforme sur la voie...


L'incrément c'est quand on garde l'existant et qu'on construit dessus.

J'attends de voir des stop_position permettant à la personne handicapée 
d'attendre devant le bon wagon ou même le bon train (cas des gares 
terminus où deux rames partent ensemble mais se séparent plus tard).


S'il est aveugle, à par demander de l'aide...

Et pour 99% des bus, ils s'arrêtent devant... l'arrêt. Étonnant non ? 
Savoir si le trottoir est rehaussé, savoir s'il y a une dalle 
podotactile l'aidera plus que de savoir que le bus s'arrête devant l'arrêt.


On peut aussi parler des trains, RER par exemple, de longueur variable.

Allez combien de nouveaux contributeurs pour entrer des arrêts de bus ? 
Au SOTM on disait pourtant qu'il fallait abaisser le ticket d'entrée. Là 
c'est un bel exemple du contraire. J'attends un outil de la part des 
promoteurs de la V2 permettant à tout un chacun de contribuer.


Si ça permet de corriger 0,01 % de l'heuristique mais fait perdre 10 % 
d'arrêts, on a amplifié le problème d'un facteur 1 000.


Jean-Yvon





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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Philippe Verdy]

Zoom 8 c'est visible, zoom 9 ce sont les communes. Les noms d'îles
réapparaissent au niveau 12 quand il y a la place à nouveau à côté du reste.

Le 29 décembre 2016 à 11:16, lenny.libre  a écrit :

> Bonjour :
>
> Je n'habite pas au bord de la mer, je suis allé voir les îles et j'ai eu
> du mal à les connaitre : leur nom disparait au profit des villes aux niveau
> de zoom 9 à 11
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#9/46.8085/-2.3813 Je ne sais pas où est l'île d'Yeu ou Belle-Ile.
>
> Merci Christian
> Bonnes Fêtes à tous, passez un bon Réveillon et Bonne Année 2017
>
> Léni
>
> Le 28/12/2016 à 15:20, Christian Quest a écrit :
>
> Pour les contributeurs côtiers (ou pas)... j'ai ajouté le rendu des
> water=tidal avec surface=sand/gravel/mud/rocky
>
> Exemple: http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#
> 15/49.6783/-1.7095
>
> ça permettra de donner un coup de pouce au mapping plus détaillé des côtes
> ;)
>
>
> Les autres changements:
> - un paquet de nouvelles abréviations pour les libellés
> - des libellés moins gros pour la couche "area-text" qui vient remplir les
> polygones de grande taille
> - une trame variable pour les landuse=forest en fonction du type d'arbres
>
> Le reste est détaillé dans les commit: https://github.com/
> cquest/osmfr-cartocss/commits/master
>
> La dernière version de la feuille de style est en ligne, mais le rendu
> n'est pas à jour.
>
> --
> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Philippe Verdy]

Au contraire, les stop_position permettent de relever de nombreuses erreurs
sur des arrêts mal choisis (qui ne sont même pas sur le bon itinéraire. Et
puis ce n'est pas que pour les bus, trains et métros aussi... Il ne s'agit
pas tant de montrer un équipement physique (platform)  qu'une topologie de
réseau et d'interconnexion explicite (au lieu de choisir les arrêts
vraiment au hasard par "proximité" relative, me^me s'ils ne sont en fait
pas desservis du tout).

Cela ne signifie pas que les stop_position doivent être rendus sur la carte
généraliste. Ce sont plus des éléments techniques, mais qui peuvent servir
dans les diagrammes de transport (pas de vrais plans) ou pour les calculs
d'itinéraires, car ils simplifient énormément les choses.

Non ce que démontre ce test c'est la possibilité de regrouper pas seulement
les "stop_position" mais surtout les "platform" (en fait ce regroupement
est déjà explicitement dans le schéma v2 avec les "stop_area".

Il faut arrêter de penser que ce qui est inutile est juste ce dont on ne se
sert pas encore dans les rendus actuels (parce qu'ils utilisent encore des
**heuristiques** pour tenter de résoudre des problèmes, mais en commentant
des erreurs car les heuristiques sont et resteront toujours des
"devinettes"). Le schéma v2 est destiné à éliminer ces heuristiques
imprécises, pour justement aller plus loin et plus précisément dans les
réutilisations.

Ce n'est pas parce qu'on a commencé avec juste des "bus_stop" (convertis en
"platform") qu'on a résolu tous les problèmes. Rappelons que ce projet
avance de façon incrémentale. Les règles du v2 sont assez précises pour
éliminer les problèmes de rendus actuels. Et on peut avancer sur des choses
plus précises (notamment pour l'accessibilité il faut être plus précis pour
localiser précisément les arrêts et déterminer quelle plateforme utiliser
pour attendre un transport sans rater le bus qui s'est arrêté en fait 50
mètres plus loin et qu'on n'aura pas le temps de courir après quand il est
passé devant parce qu'on attendait au mauvais endroit, ou du mauvais côté
de la rue (c'est moins important pour la descente). Certes il y a des
panneaux, mais ils ne sont pas toujours très clairs et accessibles pour
tous. On veut une précision métrique au minimum (ce n'est pas le cas du
tout des "platform"/"buis_stop" et encore moins des "stop_area"). Et la
vériication de tout ça est très compliquée (voire impossible) par une
simple recherche géométrique à "proximité".

Note: la démo en lien ne concerne pas du tout les "stop_position"
puisqu'ils ne sont pas affichés du tout sur la carte. Cela ne concerne que
les platform/bus_stop !



Le 29 décembre 2016 à 10:33,  a écrit :

> Un autre indice : tend à montrer l'inutilité des stop_position :-D
>
> Le 29/12/2016 à 00:59, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Un petit test... jeu des X différences ;)
>
> https://framapic.org/53IJXyTgPMH6/rXMqxFrmDlW6.png
>
> Un indice... test de ST_Clusterwithin... ;)
>
>
>
> ___
> 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, bientôt en version 2017 !

[Éric Gillet]

Le 29 décembre 2016 à 10:33,  a écrit :

> Un autre indice : tend à montrer l'inutilité des stop_position :-D
>

Dans un rendu généraliste peut-être.

Le 29/12/2016 à 00:59, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Un petit test... jeu des X différences ;)
>
> https://framapic.org/53IJXyTgPMH6/rXMqxFrmDlW6.png
>
> Un indice... test de ST_Clusterwithin... ;)
>
>
Super idée, c'est bien propre comme ça !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[lenny.libre]

Bonjour :

Je n'habite pas au bord de la mer, je suis allé voir les îles et j'ai eu 
du mal à les connaitre : leur nom disparait au profit des villes aux 
niveau de zoom 9 à 11


http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#9/46.8085/-2.3813 
Je ne sais pas où est l'île d'Yeu ou Belle-Ile.


Merci Christian
Bonnes Fêtes à tous, passez un bon Réveillon et Bonne Année 2017

Léni


Le 28/12/2016 à 15:20, Christian Quest a écrit :
Pour les contributeurs côtiers (ou pas)... j'ai ajouté le rendu des 
water=tidal avec surface=sand/gravel/mud/rocky


Exemple: 
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#15/49.6783/-1.7095


ça permettra de donner un coup de pouce au mapping plus détaillé des 
côtes ;)



Les autres changements:
- un paquet de nouvelles abréviations pour les libellés
- des libellés moins gros pour la couche "area-text" qui vient remplir 
les polygones de grande taille

- une trame variable pour les landuse=forest en fonction du type d'arbres

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


La dernière version de la feuille de style est en ligne, mais le rendu 
n'est pas à jour.


--
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, bientôt en version 2017 !

[osm . sanspourriel]

Un autre indice : tend à montrer l'inutilité des stop_position :-D


Le 29/12/2016 à 00:59, Christian Quest - cqu...@openstreetmap.fr a écrit :

Un petit test... jeu des X différences ;)

https://framapic.org/53IJXyTgPMH6/rXMqxFrmDlW6.png

Un indice... test de ST_Clusterwithin... ;)



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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Philippe Verdy]

regroupement des arrêts de bus proches avec une icône bleue un peu plus
grosse

Le 29 décembre 2016 à 00:59, Christian Quest  a
écrit :

> Un petit test... jeu des X différences ;)
>
> https://framapic.org/53IJXyTgPMH6/rXMqxFrmDlW6.png
>
> Un indice... test de ST_Clusterwithin... ;)
>
>
> --
> 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, bientôt en version 2017 !

[Christian Quest]

Un petit test... jeu des X différences ;)

https://framapic.org/53IJXyTgPMH6/rXMqxFrmDlW6.png

Un indice... test de ST_Clusterwithin... ;)

--
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, bientôt en version 2017 !

[Jérôme Amagat]

Les amenity=social_facility ne sont pas rendu contrairement au rendu
international.

Le 28 décembre 2016 à 15:20, Christian Quest  a
écrit :

> Pour les contributeurs côtiers (ou pas)... j'ai ajouté le rendu des
> water=tidal avec surface=sand/gravel/mud/rocky
>
> Exemple: http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#
> 15/49.6783/-1.7095
>
> ça permettra de donner un coup de pouce au mapping plus détaillé des côtes
> ;)
>
>
> Les autres changements:
> - un paquet de nouvelles abréviations pour les libellés
> - des libellés moins gros pour la couche "area-text" qui vient remplir les
> polygones de grande taille
> - une trame variable pour les landuse=forest en fonction du type d'arbres
>
> Le reste est détaillé dans les commit: https://github.com/
> cquest/osmfr-cartocss/commits/master
>
> La dernière version de la feuille de style est en ligne, mais le rendu
> n'est pas à jour.
>
> --
> 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, bientôt en version 2017 !

[Christian Quest]

Pour les contributeurs côtiers (ou pas)... j'ai ajouté le rendu des
water=tidal avec surface=sand/gravel/mud/rocky

Exemple:
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#15/49.6783/-1.7095

ça permettra de donner un coup de pouce au mapping plus détaillé des côtes
;)


Les autres changements:
- un paquet de nouvelles abréviations pour les libellés
- des libellés moins gros pour la couche "area-text" qui vient remplir les
polygones de grande taille
- une trame variable pour les landuse=forest en fonction du type d'arbres

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

La dernière version de la feuille de style est en ligne, mais le rendu
n'est pas à jour.

-- 
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, bientôt en version 2017 !

[osm . sanspourriel]

La Saint Nicolas, ce n'est pas le 6 décembre ? ;-)

Merci Vincent et Laurent.
J'ai profité pour mettre à jour les villages de Plumergat.
Sur le cadastre est logiquement indiqué "X" pas "Village de X".
Or certains hameaux étaient déjà dans OSM.
L'algorithme ne fait pas le rapprochement ? Le hameau avait été ajouté 
entre temps dans OSM ?

"VGE DE " en général dans FANTOIR CANAL MAJUSCULES.

Jean-Yvon

Le 28/12/2016 à 00:14, Vincent de Château-Thierry - osm.v...@free.fr a 
écrit :

Bonsoir,

Le 22/12/2016 à 12:09, Nicolas Moyroud a écrit :


Le petit papa Vincent sera donc un peu en retard par rapport à son
homologue vêtu de rouge. Alors ce sera un cadeau de nouvelle année ! ;-)


Avec un coup de main de Laurent (merci à lui) la liste est désormais 5 
fois plus longue.


C'est toujours par ici : 
http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html


Joyeux Noël Nicolas :)

vincent

___
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, bientôt en version 2017 !

[Christian Quest]

Le 27 décembre 2016 à 18:39,  a écrit :

> Allez, pour peaufiner :
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99
> 740#16/47.7536/-3.4387
>
> La trame pour le dessin de la forêt soit ne commence pas en (0,0) de la
> tuile soit ne fait pas un sous-multiple de 256 au moins dans le sens
> vertical car on a des rangées de confères allongés :
>
>
Effectivement... je met ça à jour.

J'en ai profité pour laisser en aplat les forêts sans indication du type de
végétation (leaf_type non renseigné) et mettre le type d'arbre dans les
autres cas... ça sera dans la prochaine mise à jour.


-- 
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, bientôt en version 2017 !

[Vincent de Château-Thierry]

Bonsoir,

Le 22/12/2016 à 12:09, Nicolas Moyroud a écrit :


Le petit papa Vincent sera donc un peu en retard par rapport à son
homologue vêtu de rouge. Alors ce sera un cadeau de nouvelle année ! ;-)


Avec un coup de main de Laurent (merci à lui) la liste est désormais 5 
fois plus longue.


C'est toujours par ici : 
http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html


Joyeux Noël Nicolas :)

vincent

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[osm . sanspourriel]

Allez, pour peaufiner :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#16/47.7536/-3.4387

La trame pour le dessin de la forêt soit ne commence pas en (0,0) de la 
tuile soit ne fait pas un sous-multiple de 256 au moins dans le sens 
vertical car on a des rangées de confères allongés :


Apparentement terrible :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#16/47.7480/-3.3661

Jean-Yvon

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[osm . sanspourriel]

> Un petit point aurait plus de chance de trouver à se caser, mais pas 
bien sûr non plus !


C'est pour cela que je propose un affichage inconditionnel, il pourra 
être partiellement voir complètement recouvert par un texte.


Mais on peut aussi réserver la place lors d'une première passe. Si on 
n'arrive pas à placer le nom de la commune, tant pis, on ne tient pas 
compte de la réservation de place et le point sera partiellement ou 
complètement couvert.


Jean-Yvon

Le 25/12/2016 à 20:07, Christian Quest - cqu...@openstreetmap.fr a écrit :
Le 25 décembre 2016 à 18:00, > a écrit :


Icônes et textes :

priorité aux gares mal placées ? Oui c'est de la provoc alors que
Christian nous fait du bon boulot.


http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#12/47.8442/-3.5572



http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#15/47.8622/-3.5413



Je suppose que les noms des villes sont placés avant les icônes
des gares.
Du coup si la gare est proche de la mairie/centre de la commune,
elle n'apparaît pas rapidement sur la carte.
Par contre si la gare a été mise dans un champ de betterave elle
apparaît.

Ne pourrait-on en cas de manque de place mettre in simple rond noir ?
Pour faire simple :
- affichage des lignes ferroviaires avec des ronds au niveau des
arrêts.
- affichage des noms de communes
- s'il y a de la place, affichage des icônes SNCF.


Oui, pas simple sur les centre ville... c'est là où se concentrent les 
POI, c'est là qu'on met le place=*...


Un petit point aurait plus de chance de trouver à se caser, mais pas 
bien sûr non plus !



La densité de noms de commune me semble maintenant trop élevé au
niveau 9 :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#9/48.9234/6.1523


Jusqu'à il y a peu c'était mieux, à l'image du niveau 10.


Oups... le méchant effet collatéral !
J'ai rectifié ça...

Les nouveautés:
- rendu des marais, marécages... (wetland=*)
- correction sur les bases aériennes
- densité de noms de communes revu pour la couche de "remplissage" 
(comportement changé entre mapnik 2.X et 3.x à ce qu'il me semble)


Rendu en cours...

--
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, bientôt en version 2017 !

[Christian Quest]

Le 25 décembre 2016 à 18:00,  a écrit :

> Icônes et textes :
>
> priorité aux gares mal placées ? Oui c'est de la provoc alors que
> Christian nous fait du bon boulot.
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#12/47.8442/-3.5572
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#15/47.8622/-3.5413
>
> Je suppose que les noms des villes sont placés avant les icônes des gares.
> Du coup si la gare est proche de la mairie/centre de la commune, elle
> n'apparaît pas rapidement sur la carte.
> Par contre si la gare a été mise dans un champ de betterave elle apparaît.
>
> Ne pourrait-on en cas de manque de place mettre in simple rond noir ?
> Pour faire simple :
> - affichage des lignes ferroviaires avec des ronds au niveau des arrêts.
> - affichage des noms de communes
> - s'il y a de la place, affichage des icônes SNCF.
>
>
Oui, pas simple sur les centre ville... c'est là où se concentrent les POI,
c'est là qu'on met le place=*...

Un petit point aurait plus de chance de trouver à se caser, mais pas bien
sûr non plus !



> La densité de noms de commune me semble maintenant trop élevé au niveau 9 :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#9/48.9234/6.1523
> Jusqu'à il y a peu c'était mieux, à l'image du niveau 10.
>

Oups... le méchant effet collatéral !
J'ai rectifié ça...

Les nouveautés:
- rendu des marais, marécages... (wetland=*)
- correction sur les bases aériennes
- densité de noms de communes revu pour la couche de "remplissage"
(comportement changé entre mapnik 2.X et 3.x à ce qu'il me semble)

Rendu en cours...

-- 
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, bientôt en version 2017 !

[osm . sanspourriel]

Icônes et textes :

priorité aux gares mal placées ? Oui c'est de la provoc alors que 
Christian nous fait du bon boulot.


http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#12/47.8442/-3.5572

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#15/47.8622/-3.5413

Je suppose que les noms des villes sont placés avant les icônes des gares.
Du coup si la gare est proche de la mairie/centre de la commune, elle 
n'apparaît pas rapidement sur la carte.

Par contre si la gare a été mise dans un champ de betterave elle apparaît.

Ne pourrait-on en cas de manque de place mettre in simple rond noir ?
Pour faire simple :
- affichage des lignes ferroviaires avec des ronds au niveau des arrêts.
- affichage des noms de communes
- s'il y a de la place, affichage des icônes SNCF.

La densité de noms de commune me semble maintenant trop élevé au niveau 9 :
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#9/48.9234/6.1523
Jusqu'à il y a peu c'était mieux, à l'image du niveau 10.


Le 25/12/2016 à 17:25, osm.sanspourr...@spamgourmet.com a écrit :


Toujours sur les noms de commune :

Je ne sais si c'est un heureux hasard ou un meilleur calcul mais avant 
il arrivait qu'un hameau (100 habitants - Locmaria) d'une commune 
prenne le pas sur une commune (10 000 habitants - Guidel) :


http://layers.openstreetmap.fr/?zoom=10=47.82262=-3.52654=BFF

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#10/47.7894/-3.4915

Second cadeau de Noël : les jours rallongent, si, si !

Jean-Yvon


Le 24/12/2016 à 17:53, Christian Quest - cqu...@openstreetmap.fr a écrit :
Pas évident à traiter, car les autres noms proviennent de noeuds 
place=* et là le nom n'est porté que par la relation 
boundary=administrative.


J'ai quand même trouvé une solution car le problème est d'éviter un 
double rendu (centroid de la commune + noeud place=*). La requête 
vérifie maintenant si un noeud place=* porte le même nom à 
l'intérieur du polygone de la limite admin, avant elle vérifiait 
juste la présence d'un rôle admin_centre sur la relation.


J'ai aussi modifié le niveau de zoom à partir duquel ces noms issus 
des boundary apparaissent... ça commence au 12.


ça sera dans la prochaine livraison...



Le 23 décembre 2016 à 17:15, Stéphane Péneau 
> a 
écrit :


Je vois que le nom des communes fusionnées est visible, même s'il
n'y a pas de node place dans la relation. Super !
Par contre, on ne voit ce nom qu'à partir du zoom 14, bien après
les  "place" de la commune en question.
Est-ce qu'il ne serait pas mieux que ça soit visible avant ?

exemple : (il faut zoomer d'un cran pour voir "Montréverd")

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#13/46.8993/-1.4205



Stf



Le 23/12/2016 à 16:46, Tony EMERY a écrit :

N'oublies pas le rendu des terrains de motoball...

Le 23 déc. 2016 16:24, "Christian Quest"
> a écrit :

Les derniers changements:
- les entrance=* ne sont rendus si ce sont des entrées de
bâtiment ou si ce ne sont pas des entrées de pièce... avec
de la bidouille dans la requête pour retrouver cette info !

- les lignes des terrains de sport: plus de rendu si il ne
s'agit pas d'un leisure=pitch, et rendu possible de
plusieurs sports (mais un peu fouilli au final... à voir)

- les shop=* en souterrain sont estompés, prise en compte du
tag location=underground en plus de level<0

Et grosse refonte de fond du projet avec passage du format
json au yaml plus lisible (et maintenable)... qui ne devrait
pas avoir d'incidence sur le rendu sauf bug de conversion !

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



___ 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, bientôt en version 2017 !

[osm . sanspourriel]

Toujours sur les noms de commune :

Je ne sais si c'est un heureux hasard ou un meilleur calcul mais avant 
il arrivait qu'un hameau (100 habitants - Locmaria) d'une commune prenne 
le pas sur une commune (10 000 habitants - Guidel) :


http://layers.openstreetmap.fr/?zoom=10=47.82262=-3.52654=BFF

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#10/47.7894/-3.4915

Second cadeau de Noël : les jours rallongent, si, si !

Jean-Yvon


Le 24/12/2016 à 17:53, Christian Quest - cqu...@openstreetmap.fr a écrit :
Pas évident à traiter, car les autres noms proviennent de noeuds 
place=* et là le nom n'est porté que par la relation 
boundary=administrative.


J'ai quand même trouvé une solution car le problème est d'éviter un 
double rendu (centroid de la commune + noeud place=*). La requête 
vérifie maintenant si un noeud place=* porte le même nom à l'intérieur 
du polygone de la limite admin, avant elle vérifiait juste la présence 
d'un rôle admin_centre sur la relation.


J'ai aussi modifié le niveau de zoom à partir duquel ces noms issus 
des boundary apparaissent... ça commence au 12.


ça sera dans la prochaine livraison...



Le 23 décembre 2016 à 17:15, Stéphane Péneau 
> a écrit :


Je vois que le nom des communes fusionnées est visible, même s'il
n'y a pas de node place dans la relation. Super !
Par contre, on ne voit ce nom qu'à partir du zoom 14, bien après
les  "place" de la commune en question.
Est-ce qu'il ne serait pas mieux que ça soit visible avant ?

exemple : (il faut zoomer d'un cran pour voir "Montréverd")

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#13/46.8993/-1.4205



Stf



Le 23/12/2016 à 16:46, Tony EMERY a écrit :

N'oublies pas le rendu des terrains de motoball...

Le 23 déc. 2016 16:24, "Christian Quest" > a écrit :

Les derniers changements:
- les entrance=* ne sont rendus si ce sont des entrées de
bâtiment ou si ce ne sont pas des entrées de pièce... avec de
la bidouille dans la requête pour retrouver cette info !

- les lignes des terrains de sport: plus de rendu si il ne
s'agit pas d'un leisure=pitch, et rendu possible de plusieurs
sports (mais un peu fouilli au final... à voir)

- les shop=* en souterrain sont estompés, prise en compte du
tag location=underground en plus de level<0

Et grosse refonte de fond du projet avec passage du format
json au yaml plus lisible (et maintenable)... qui ne devrait
pas avoir d'incidence sur le rendu sauf bug de conversion !

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



___ 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, bientôt en version 2017 !

[Christian Quest]

Pas évident à traiter, car les autres noms proviennent de noeuds place=* et
là le nom n'est porté que par la relation boundary=administrative.

J'ai quand même trouvé une solution car le problème est d'éviter un double
rendu (centroid de la commune + noeud place=*). La requête vérifie
maintenant si un noeud place=* porte le même nom à l'intérieur du polygone
de la limite admin, avant elle vérifiait juste la présence d'un rôle
admin_centre sur la relation.

J'ai aussi modifié le niveau de zoom à partir duquel ces noms issus des
boundary apparaissent... ça commence au 12.

ça sera dans la prochaine livraison...



Le 23 décembre 2016 à 17:15, Stéphane Péneau  a
écrit :

> Je vois que le nom des communes fusionnées est visible, même s'il n'y a
> pas de node place dans la relation. Super !
> Par contre, on ne voit ce nom qu'à partir du zoom 14, bien après les
> "place" de la commune en question.
> Est-ce qu'il ne serait pas mieux que ça soit visible avant ?
>
> exemple : (il faut zoomer d'un cran pour voir "Montréverd")
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#13/46.8993/-1.4205
>
> Stf
>
>
>
> Le 23/12/2016 à 16:46, Tony EMERY a écrit :
>
> N'oublies pas le rendu des terrains de motoball...
>
> Le 23 déc. 2016 16:24, "Christian Quest"  a
> écrit :
>
>> Les derniers changements:
>> - les entrance=* ne sont rendus si ce sont des entrées de bâtiment ou si
>> ce ne sont pas des entrées de pièce... avec de la bidouille dans la requête
>> pour retrouver cette info !
>>
>> - les lignes des terrains de sport: plus de rendu si il ne s'agit pas
>> d'un leisure=pitch, et rendu possible de plusieurs sports (mais un peu
>> fouilli au final... à voir)
>>
>> - les shop=* en souterrain sont estompés, prise en compte du tag
>> location=underground en plus de level<0
>>
>> Et grosse refonte de fond du projet avec passage du format json au yaml
>> plus lisible (et maintenable)... qui ne devrait pas avoir d'incidence sur
>> le rendu sauf bug de conversion !
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> 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
>
>


-- 
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, bientôt en version 2017 !

[Gautier Pelloux-Prayer]

Serait-il possible d'ajouter le rendu des pistes de course : course 
équestre (leisure=horse_racing) ou piste d'athlétisme et de course à 
pied (sport=athletics et sport=running), etc. ?
Actuellement elles ne sont pas representées (par ex ici : 
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#19/45.17942/5.75833 
).



Le ven. 23 déc. 2016 à 20:23, Christian Quest 
 a écrit :
Pour les track/gradeX, j'ai repris les mêmes pointillés que sur le 
rendu international... dans la prochaine livraison...


Le 22 décembre 2016 à 15:40, JB  a écrit :

Salut Christian,
Sacré boulot que tu fais là !
Par contre, en zone rurale (mon dada), le rendu international a bien 
avancé, mais pas repris sur le rendu FR. Notamment l'avancée 
principale : la réorganisation des tirets selon le tracktype serait 
très bienvenue, la progression actuelle étant incohérente pour le 
tracktype=grade4. (Sinon, le boulot fait sur les path/footway est 
intéressant aussi)
Voilà voilà, n'hésite pas à différencier encore un peu plus les 
locality des autres lieu-dits (j'aurais mis un coup de font-stretch 
ou son équivalent s'il existe sur mapnik sur les locality, par 
exemple).

JB.

Le 21/12/2016 à 19:45, Christian Quest a écrit :

Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements: 
https://github.com/cquest/osmfr-cartocss/commits/master


Après avoir passé pas mal de temps sur les optimisations pour 
accélrer le rendu là où c'était le plus urgent, je suis de 
retour sur le côté graphique.


Une grosse nouveauté: l'estompage des objets "indoor" qui devrait 
alléger les abords de certaines gares ;) Pour ça, le rendu 
considère tout objet avec un level=* négatif comme indoor.


Les "shield" sur les routes sont mieux répartis. Pour cela, la 
requête SQL regroupe les différents tronçons ayant le même 
highway+ref car vu qu'on tronçonne de plus en plus il faut en 
passer par là !


Résultat visible sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186


Le pré-calcul des tuiles est en cours donc tout n'est pas encore 
dispo et peut nécessiter un délais de génération...



--
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, bientôt en version 2017 !

[Christian Quest]

Pour les track/gradeX, j'ai repris les mêmes pointillés que sur le rendu
international... dans la prochaine livraison...

Le 22 décembre 2016 à 15:40, JB  a écrit :

> Salut Christian,
> Sacré boulot que tu fais là !
> Par contre, en zone rurale (mon dada), le rendu international a bien
> avancé, mais pas repris sur le rendu FR. Notamment l'avancée principale :
> la réorganisation des tirets selon le tracktype serait très bienvenue, la
> progression actuelle étant incohérente pour le tracktype=grade4. (Sinon, le
> boulot fait sur les path/footway est intéressant aussi)
> Voilà voilà, n'hésite pas à différencier encore un peu plus les locality
> des autres lieu-dits (j'aurais mis un coup de font-stretch ou son
> équivalent s'il existe sur mapnik sur les locality, par exemple).
> JB.
>
> Le 21/12/2016 à 19:45, Christian Quest a écrit :
>
> Je profite des congés pour avancer sur le rendu FR...
>
> La liste des commit s'allonge et donne une idée des changements:
> https://github.com/cquest/osmfr-cartocss/commits/master
>
> Après avoir passé pas mal de temps sur les optimisations pour accélrer le
> rendu là où c'était le plus urgent, je suis de retour sur le côté graphique.
>
> Une grosse nouveauté: l'estompage des objets "indoor" qui devrait alléger
> les abords de certaines gares ;) Pour ça, le rendu considère tout objet
> avec un level=* négatif comme indoor.
>
> Les "shield" sur les routes sont mieux répartis. Pour cela, la requête SQL
> regroupe les différents tronçons ayant le même highway+ref car vu qu'on
> tronçonne de plus en plus il faut en passer par là !
>
> Résultat visible sur http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_
> 99740#6/47.376/2.186
>
> Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo et
> peut nécessiter un délais de génération...
>
>
> --
> 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, bientôt en version 2017 !

[Philippe Verdy]

Au même endroit si on dézoome, on tombe sur l'Hebergement, dont le
placement semble vraiment trop à l'ouest sans que ce soit justifié.

Pourquoi par défaut les libellés ne sont pas centrés sur la commune mais
affiché à l'ouest (alignement à gauche) ou à l'est alors même qu'il n'y a
aps de collision en le plaçant au centre ? Cela donne un emplacement
contre-intuitif. A moins qu'il y ait des collisions à éviter, le centrage
devrait être l'option par défaut, avec un décalage possible vers l'ouest ou
l'est (ou un peu vers le nord ou le sud) tout en gardant le rectangle
occupé par le libellé si-possible à une position contenant le point central.

Si le libellé est accompagne d'une icone en revanche (un cercle, un disque,
une étoile...) ce libellé devrait être aussi placé de préférence au nord ou
au sud de cette icone (pour éviter autant que possible de la couvrir, mais
ce n'est pas une obligation: si le placement à l'ouest ou à l'est de
l'icone provoque et décentrage trop distant, il est possible malgré tout de
recentrer le libellé même si cela recouvre l'icone, s'il faut faire de la
place pour un libellé voisin.

Un bon moyen serait de procéder en deux passes: dans une première passe les
libellés sont calculés avec une taille correspondant à leur version non
abrégée générant le rectangle le plus grand on enregistre ensuite son point
central préférentiel (qui pourra être ensuite décalé pour le maintenir dans
son rectangle de définition. Si un libellé ultérieur a besoin de place, il
peut décaler le centre des libellés voisins pour qu'il reste dans leur
rectangle de définition, puis ce rectangle de définition est réduit pour
qu'il n'aille plus recouvrir la place prise par un autre libellé voisin
(noter que les icônes sont placées en premier pour occuper leur place)
chaque libellé a donc un rectangle préférentiel de placement qui de proche
en proche va se réduire. Si on manque encore de place, un libellé peut
ensuite être converti en version abrégée, en utilisant les "short-name" si
disponibles, puis les abréviations courantes de termes connus comme
"Saint(e)", "Général", "Avenue", "Boulevard" si cela permet de réduire leur
taille (tout en faisant que ce libellé ne sorte pas de leur actuel
rectangle de définition, doinc en faisant attention à conserver des sauts
de lignes suffisants).

Le tracé des libellés ne se fait que dans une seconde passe après les avoir
tous placés (là où il n'y a pas de collisions possibles dans la tuile
courante ou dans une tuile limitrophe où ce libellé serait partiellement
tracé: la zone, de calcul de placement des libellés est donc plus large que
la tuile que l'on est en train de tracer, mais ce n'est pas nouveau et ne
concerne pas que les libellés mais aussi le tracé des routes du fait de
leur largeur, ou des icônes de tout type qui peuvent être elles aussi à
cheval sur des limites de tuiles: les requêtes à la base doivent inclure
une marge plus grande autour de la tuile à tracer pour être certain d'avoir
tous les objets, y compris ceux qui pourraient être décalés de leur
position centrale idéale, ce décalage étant plus grand pour les libellés
que pour les icônes ou routes qui ont un placement fixe).

Autre chose à voir: les libellés non horizontaux qui suivent les noms de
fleuves ou les frontières (voire les noms de chaines de montagne si on veut
les voir ou les noms de petites mers): leur placement dynamique (le long
d'un chemin) est nettement plus compliqué car il se fait dans un polygone
calculé par un buffer autour du chemin dont on doit trouver des zones non
occupées par d'autres libellés... pour les noms de chaines de montagnes (ou
glaciers, parcs naturels...) toutefois une solution est de les afficher en
grand caractères mais semi-transparents et gras, qui peuvent alors entrer
en superposition avec les autres zones de remplissage ou les libellés et
icônes tracés par dessus; le système pourrait servir aussi à libeller les
grandes régions ou les pays en fonction de leur superficie relativement à
celle de la tuile à l'échelle de rendu donnée). Ce système de libellés
semi-transparents (en arrière-plan des autres libellés pourrait autant
servir à placer des noms de quartiers sur des échelles montrant les rues
d'une ville. Mais la question de lisibilité de ces libellés
semi-transparents dépend des choix de couleurs et tailles et graisse de
police utilisées: si la police est trop grande de tels libellés ne doivent
plus être utilisés et au passe aux libellés tracés en petits caractères le
long des frontières ou le long du chemin central d'un cours d'eau.

Le placement des libellés est encore non optimal et devrait faire l'objet
de recherches avec de meilleurs heuristiques (sans compter que pour des
libellés jugés "importants", s'il n'est pas possible de les afficher à
cause de collisions, il reste la solution des libellés "fléchés" pour leur
trouver une autre place sortant de leur cadre de définition initia, exemple
pour placer Monaco à côté de Nice, Nice étant beaucoup plus gros, 

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Stéphane Péneau]

Petit détail supplémentaire, les communes fusionnées qui ont un node 
place virtuel, sont elles, visibles beaucoup plus tôt, comme la bien 
connue Chaume en Retz :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#11/47.0898/-1.8406
Mais je ne dirais rien sur les tags portés par le node...

Exemple plus simple, Montholon, est visible depuis le niveau de zoom 11 :
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#11/47.8883/3.3889

Mais peut-être que c'est lié au nombre d'éléments à afficher.

Stf

Le 23/12/2016 à 17:15, Stéphane Péneau a écrit :
Je vois que le nom des communes fusionnées est visible, même s'il n'y 
a pas de node place dans la relation. Super !
Par contre, on ne voit ce nom qu'à partir du zoom 14, bien après les  
"place" de la commune en question.

Est-ce qu'il ne serait pas mieux que ça soit visible avant ?

exemple : (il faut zoomer d'un cran pour voir "Montréverd")
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#13/46.8993/-1.4205

Stf


Le 23/12/2016 à 16:46, Tony EMERY a écrit :

N'oublies pas le rendu des terrains de motoball...

Le 23 déc. 2016 16:24, "Christian Quest" > a écrit :


Les derniers changements:
- les entrance=* ne sont rendus si ce sont des entrées de
bâtiment ou si ce ne sont pas des entrées de pièce... avec de la
bidouille dans la requête pour retrouver cette info !

- les lignes des terrains de sport: plus de rendu si il ne s'agit
pas d'un leisure=pitch, et rendu possible de plusieurs sports
(mais un peu fouilli au final... à voir)

- les shop=* en souterrain sont estompés, prise en compte du tag
location=underground en plus de level<0

Et grosse refonte de fond du projet avec passage du format json
au yaml plus lisible (et maintenable)... qui ne devrait pas avoir
d'incidence sur le rendu sauf bug de conversion !

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





___
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, bientôt en version 2017 !

[Stéphane Péneau]

Je vois que le nom des communes fusionnées est visible, même s'il n'y a 
pas de node place dans la relation. Super !
Par contre, on ne voit ce nom qu'à partir du zoom 14, bien après les  
"place" de la commune en question.

Est-ce qu'il ne serait pas mieux que ça soit visible avant ?

exemple : (il faut zoomer d'un cran pour voir "Montréverd")
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#13/46.8993/-1.4205

Stf


Le 23/12/2016 à 16:46, Tony EMERY a écrit :

N'oublies pas le rendu des terrains de motoball...

Le 23 déc. 2016 16:24, "Christian Quest" > a écrit :


Les derniers changements:
- les entrance=* ne sont rendus si ce sont des entrées de bâtiment
ou si ce ne sont pas des entrées de pièce... avec de la bidouille
dans la requête pour retrouver cette info !

- les lignes des terrains de sport: plus de rendu si il ne s'agit
pas d'un leisure=pitch, et rendu possible de plusieurs sports
(mais un peu fouilli au final... à voir)

- les shop=* en souterrain sont estompés, prise en compte du tag
location=underground en plus de level<0

Et grosse refonte de fond du projet avec passage du format json au
yaml plus lisible (et maintenable)... qui ne devrait pas avoir
d'incidence sur le rendu sauf bug de conversion !

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



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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Tony EMERY]

N'oublies pas le rendu des terrains de motoball...

Le 23 déc. 2016 16:24, "Christian Quest"  a écrit :

> Les derniers changements:
> - les entrance=* ne sont rendus si ce sont des entrées de bâtiment ou si
> ce ne sont pas des entrées de pièce... avec de la bidouille dans la requête
> pour retrouver cette info !
>
> - les lignes des terrains de sport: plus de rendu si il ne s'agit pas d'un
> leisure=pitch, et rendu possible de plusieurs sports (mais un peu fouilli
> au final... à voir)
>
> - les shop=* en souterrain sont estompés, prise en compte du tag
> location=underground en plus de level<0
>
> Et grosse refonte de fond du projet avec passage du format json au yaml
> plus lisible (et maintenable)... qui ne devrait pas avoir d'incidence sur
> le rendu sauf bug de conversion !
>
> --
> 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, bientôt en version 2017 !

[Christian Quest]

Les derniers changements:
- les entrance=* ne sont rendus si ce sont des entrées de bâtiment ou si ce
ne sont pas des entrées de pièce... avec de la bidouille dans la requête
pour retrouver cette info !

- les lignes des terrains de sport: plus de rendu si il ne s'agit pas d'un
leisure=pitch, et rendu possible de plusieurs sports (mais un peu fouilli
au final... à voir)

- les shop=* en souterrain sont estompés, prise en compte du tag
location=underground en plus de level<0

Et grosse refonte de fond du projet avec passage du format json au yaml
plus lisible (et maintenable)... qui ne devrait pas avoir d'incidence sur
le rendu sauf bug de conversion !

-- 
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, bientôt en version 2017 !

[PanierAvide]

C'est prévu dans la liste des améliorations de n'afficher que les 
niveaux qui ont un intérêt pour l'utilisateur final (dans la version de 
base) ;-)


Cordialement.


Le 22/12/2016 à 19:19, osm.sanspourr...@spamgourmet.com a écrit :

Et aussi pour l'exemple à ne pas imiter :
http://dev.openlevelup.net/?l=0#18/48.85987/2.33761
Plusieurs salles portent le même nom, il faudrait mieux définir un 
multipolygone avec un seul nom.


Au fait, Christian, c'est sympa pour les aveugles, tu as fait une 
carte en braille :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.85987/2.33761

Adrien, quand il y a plusieurs niveaux superposés on aimerait savoir 
s'il y a une information pertinente.
Par exemple à côté il y a l'Église Saint-Leu - Saint-Gilles 
http://www.openstreetmap.org/way/53933240 par exemple qui apparaît à 
plusieurs niveaux mais il n'y a aucune information spécifique.
Donc présenter les niveaux 3 et 4 qui sont identiques n'apporte guère 
d'info (3-4 suffirait).
LevelUp c'est super quand diverses couches se superposent. Si c'est 
juste l'épaisseur d'une couche, sauf à prendre une vue 3D (isométrique 
par exemple) ça n'a pas un intérêt fou pour l'utilisateur final (au 
plus un +/- sur les bâtiments pour savoir ceux qui continuent au 
dessus/en dessous???).
Oui, je me vois ici comme utilisateur, je laisse l'algorithmique de 
côté ;-).


Jean-Yvon



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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[osm . sanspourriel]

Et aussi pour l'exemple à ne pas imiter :
http://dev.openlevelup.net/?l=0#18/48.85987/2.33761
Plusieurs salles portent le même nom, il faudrait mieux définir un 
multipolygone avec un seul nom.


Au fait, Christian, c'est sympa pour les aveugles, tu as fait une carte 
en braille :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.85987/2.33761

Adrien, quand il y a plusieurs niveaux superposés on aimerait savoir 
s'il y a une information pertinente.
Par exemple à côté il y a l'Église Saint-Leu - Saint-Gilles 
http://www.openstreetmap.org/way/53933240 par exemple qui apparaît à 
plusieurs niveaux mais il n'y a aucune information spécifique.
Donc présenter les niveaux 3 et 4 qui sont identiques n'apporte guère 
d'info (3-4 suffirait).
LevelUp c'est super quand diverses couches se superposent. Si c'est 
juste l'épaisseur d'une couche, sauf à prendre une vue 3D (isométrique 
par exemple) ça n'a pas un intérêt fou pour l'utilisateur final (au plus 
un +/- sur les bâtiments pour savoir ceux qui continuent au dessus/en 
dessous???).
Oui, je me vois ici comme utilisateur, je laisse l'algorithmique de côté 
;-).


Jean-Yvon

Le 22/12/2016 à 18:02, PanierAvide - panierav...@riseup.net a écrit :

Le 22/12/2016 à 17:24, Christian Quest a écrit :
Tout le Musée du Louvre est hyper détaillé en indoor... chaque salle, 
entrée... ça me démange de rendre ça visible ;)


Genre comme ça :
http://dev.openlevelup.net/?l=1#19/48.86059/2.33575

#placement produit :-)

Cordialement,

PanierAvide.


___
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, bientôt en version 2017 !

[PanierAvide]

Le 22/12/2016 à 17:24, Christian Quest a écrit :
Tout le Musée du Louvre est hyper détaillé en indoor... chaque salle, 
entrée... ça me démange de rendre ça visible ;)


Genre comme ça :
http://dev.openlevelup.net/?l=1#19/48.86059/2.33575

#placement produit :-)

Cordialement,

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Christian Quest]

Le 22 décembre 2016 à 17:16, Christian Quest  a
écrit :

> Le 22 décembre 2016 à 15:19, Florian LAINEZ  a écrit :
>
>>
>> Autre remarque : afficher les entrance sans visualiser les espaces
>> intérieurs, ça donne ça sur Montparnasse : http://umap.openstreetmap.fr/f
>> r/map/preview-rendu-fr-2017_99740#18/48.84084/2.32062
>>
>> Tu remarqueras que je me plains sans apporter de solution !
>>
>>
> Effectivement, ça pique un peu, mais bon, c'est pas nouveau. :(
>


Humm... ça pique vraiment:
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#17/48.86067/2.33558

Tout le Musée du Louvre est hyper détaillé en indoor... chaque salle,
entrée... ça me démange de rendre ça visible ;)


-- 
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, bientôt en version 2017 !

[Christian Quest]

Le 22 décembre 2016 à 15:19, Florian LAINEZ  a écrit :

> Bon boulot Christian, ravi de voir que le rendu avance.
>
> Concernant le indoor tu dis que les objets en sous-sol ont disparus mais
> je vois toujours la gare sous-terraine de Magenta ;)
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99
> 740#17/48.88077/2.35857
> Les données sont pourtant bien tagguées avec un level négatif.
>
>

Les shop=* n'avaient pas droit à ce traitement, mais pour le reste j'ai
vérifié avec les données et ça estompe bien si level<0.




> Autre remarque : afficher les entrance sans visualiser les espaces
> intérieurs, ça donne ça sur Montparnasse : http://umap.openstreetmap.fr/f
> r/map/preview-rendu-fr-2017_99740#18/48.84084/2.32062
>
> Tu remarqueras que je me plains sans apporter de solution !
>
>
Effectivement, ça pique un peu, mais bon, c'est pas nouveau. :(



> sans discussion, ce sont les platform (=anciens bux_stop) qu'il faut
> afficher
>
> +1
>
>
On continue sur l'autre fil pour ça...


-- 
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, bientôt en version 2017 !

[Jean-Claude Repetto]

Le 22/12/2016 à 15:40, JB a écrit :
> Salut Christian,
> Sacré boulot que tu fais là !
> Par contre, en zone rurale (mon dada), le rendu international a bien
> avancé, mais pas repris sur le rendu FR. Notamment l'avancée principale
> : la réorganisation des tirets selon le tracktype serait très bienvenue,
> la progression actuelle étant incohérente pour le tracktype=grade4.
> JB.
> 

Bonjour,

En ce qui concerne les pistes(highway=track), je pense que la priorité
serait de leur donner une épaisseur, comme sur la carte
http://maps.refuges.info/ .
En effet, la représentation filaire actuelle est trompeuse et devrait
être réservée aux sentiers (highway=path).

Jean-Claude


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[JB]

Salut Christian,
Sacré boulot que tu fais là !
Par contre, en zone rurale (mon dada), le rendu international a bien 
avancé, mais pas repris sur le rendu FR. Notamment l'avancée principale 
: la réorganisation des tirets selon le tracktype serait très bienvenue, 
la progression actuelle étant incohérente pour le tracktype=grade4. 
(Sinon, le boulot fait sur les path/footway est intéressant aussi)
Voilà voilà, n'hésite pas à différencier encore un peu plus les locality 
des autres lieu-dits (j'aurais mis un coup de font-stretch ou son 
équivalent s'il existe sur mapnik sur les locality, par exemple).

JB.

Le 21/12/2016 à 19:45, Christian Quest a écrit :

Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements: 
https://github.com/cquest/osmfr-cartocss/commits/master


Après avoir passé pas mal de temps sur les optimisations pour accélrer 
le rendu là où c'était le plus urgent, je suis de retour sur le côté 
graphique.


Une grosse nouveauté: l'estompage des objets "indoor" qui devrait 
alléger les abords de certaines gares ;) Pour ça, le rendu considère 
tout objet avec un level=* négatif comme indoor.


Les "shield" sur les routes sont mieux répartis. Pour cela, la requête 
SQL regroupe les différents tronçons ayant le même highway+ref car vu 
qu'on tronçonne de plus en plus il faut en passer par là !


Résultat visible sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186


Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo 
et peut nécessiter un délais de génération...



--
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, bientôt en version 2017 !

[Florian LAINEZ]

Bon boulot Christian, ravi de voir que le rendu avance.

Concernant le indoor tu dis que les objets en sous-sol ont disparus mais je
vois toujours la gare sous-terraine de Magenta ;)
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#17/48.88077/2.35857
Les données sont pourtant bien tagguées avec un level négatif.

Autre remarque : afficher les entrance sans visualiser les espaces
intérieurs, ça donne ça sur Montparnasse :
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.84084/2.32062

Tu remarqueras que je me plains sans apporter de solution !

sans discussion, ce sont les platform (=anciens bux_stop) qu'il faut
afficher

+1

Le 22 décembre 2016 à 13:11,  a écrit :

> Le 22/12/2016 à 02:53, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Le 21 décembre 2016 à 23:56,  a écrit :
>
> Niveau 11
>> 
>> :
>>
>> et sans doute ailleurs : pas de repliement de ligne sue la BAN de
>> Lann-Bihoué mais sur Guidel-Plages.
>>
>
> ?? lien ??
>
> Voir ci-dessus !
> Tiens on pourrait ajouter B.A.N. en abréviation de Base d'aéronautique
> navale
>
>
>
>> Pourtant le nom déborde de la zone militaire.
>>
>
> ça , les noms peuvent déborder si la forme est très allongée. La taille du
> texte varie avec la surface du polygone, mais pas en prenant compte sa
> largeur et/ou hauteur.
>
> Sauf que pour Guidel-Plages il y a repliement de ligne et pas pour "Base
> d'aéronautique navale de Lann-Bihoué" qui est particulièrement long.
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99
>> 740#17/48.38764/-4.46565
>>
>
> Difficile avec les voies à chaussées séparées. Ce sont deux lignes
> distinctes et pas facile de les fusionner en une seule...
>
> Bah, on va bien trouver quelqu'un pour nous pondre un schéma highway V2
> incompatible avec le précédent ;-).
> Mais en dessous la Rue de Kiel n'est pas à chaussée-séparée.
>
>
> Aller dans le détail des intersections comme tu le suggère n'est pas
> simple non plus... j'imagine la complexité des requêtes pour obtenir ces
> infos !
>
> Ne nous abaissons pas à un simple problème d'algorithmique :-D
> Oui, pour que ça marche bien il faut laisser le client afficher au moins
> la partie textuelle par un tuilage vectoriel.
>
> > Un polygone englobant toute l'emprise du collège est bien sûr la
> solution parce qu'en plus un collège ce n'est pas qu'un bâtiment, c'est une
> cour, un parking, des terrains de sport, etc... j'ai corrigé.
> Merci.
>
>
>
>> Rendu ou données incorrectes ?
>> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99
>> 740#19/48.39896/-4.40997
>> http://www.openstreetmap.org/#map=19/48.39886/-4.40977
>>
>>
> Là je sèche...
>
> Beaucoup de considérations à celui ou celle qui trouvera !
>
> Au sud-ouest du rond-point : "Collège Priv. Diwan Penn ar Bed".
> Pourquoi cette abréviation qui ne fait guère gagner de place ? De plus la
> version "longue" tenait largement dans l'emplacement.
> Et en plus Diwan aurait bien aimé être public, mais c'est une autre
> histoire.
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[osm . sanspourriel]

Le 22/12/2016 à 02:53, Christian Quest - cqu...@openstreetmap.fr a écrit :

Le 21 décembre 2016 à 23:56, > a écrit :


Niveau 11


:

et sans doute ailleurs : pas de repliement de ligne sue la BAN de
Lann-Bihoué mais sur Guidel-Plages.


?? lien ??

Voir ci-dessus !
Tiens on pourrait ajouter B.A.N. en abréviation de Base d'aéronautique 
navale**



Pourtant le nom déborde de la zone militaire.


ça , les noms peuvent déborder si la forme est très allongée. La 
taille du texte varie avec la surface du polygone, mais pas en prenant 
compte sa largeur et/ou hauteur.
Sauf que pour Guidel-Plages il y a repliement de ligne et pas pour "Base 
d'aéronautique navale de Lann-Bihoué" qui est particulièrement long.




http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#17/48.38764/-4.46565




Difficile avec les voies à chaussées séparées. Ce sont deux lignes 
distinctes et pas facile de les fusionner en une seule...
Bah, on va bien trouver quelqu'un pour nous pondre un schéma highway V2 
incompatible avec le précédent ;-).

Mais en dessous la Rue de Kiel n'est pas à chaussée-séparée.


Aller dans le détail des intersections comme tu le suggère n'est pas 
simple non plus... j'imagine la complexité des requêtes pour obtenir 
ces infos !

Ne nous abaissons pas à un simple problème d'algorithmique :-D
Oui, pour que ça marche bien il faut laisser le client afficher au moins 
la partie textuelle par un tuilage vectoriel.


> Un polygone englobant toute l'emprise du collège est bien sûr la 
solution parce qu'en plus un collège ce n'est pas qu'un bâtiment, c'est 
une cour, un parking, des terrains de sport, etc... j'ai corrigé.

Merci.


Rendu ou données incorrectes ?

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#19/48.39896/-4.40997


http://www.openstreetmap.org/#map=19/48.39886/-4.40977



Là je sèche...

Beaucoup de considérations à celui ou celle qui trouvera !

Au sud-ouest du rond-point : "Collège Priv. Diwan Penn ar Bed".
Pourquoi cette abréviation qui ne fait guère gagner de place ? De plus 
la version "longue" tenait largement dans l'emplacement.
Et en plus Diwan aurait bien aimé être public, mais c'est une autre 
histoire.


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Nicolas Moyroud]

J'aurais aimé caser ça avant Noël, mais de façon plus réaliste ce sera 
pour la rentrée.
Le petit papa Vincent sera donc un peu en retard par rapport à son 
homologue vêtu de rouge. Alors ce sera un cadeau de nouvelle année ! ;-)

J'ai d'autres trucs pour m'occuper de toute façon...

Nicolas

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Jérôme Amagat]

Le 22 déc. 2016 03:03, "Christian Quest"  a écrit :

Le 22 décembre 2016 à 01:05, Jérôme Amagat  a
écrit :

> on parle beaucoup des transport public en ce moment, ça serait bien que
> les arrets de bus, tram metro ... soit rendu qu'avec des tag
> public_transport= et aussi si ce n'est pas un node mais un way ou
> multipolygon.
>

>

Je ne pense pas que ce soit une bonne idée de forcer ainsi la main pour
adopter un modèle bien complexe pour le contributeur lambda.


Oups, je me suis mal exprimé. Je voulais dire qu'il faudrait que les arrêts
qu'avec le nouveau schéma public transport soit rendu comme ceux avec les
plus anciens tags. Et oui garder le rendu pour les anciens tags.


Si on veut détecter les arrêts à mettre à jour, il faut le faire avec des
outils de QA comme osmose, pas avec un rendu assez généraliste.


Pour la prise en compte des polygones, je vais regarder ce qu'il est
possible de faire, mais mes souvenirs c'est qu'il est bien complexe de
prendre en compte le schéma public_transport au niveau du rendu.

On met quoi sur le rendu ? public_transport=stop_position ou
public_transport=platform ?

Si on a un highway=bus_stop comment on évite d'avoir un doublon ?

Heureusement que postgis a maintenant de quoi générer des cluster... ça va
peut être être la solution: on met tout ensemble et on fait un cluster ;)

-- 
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, bientôt en version 2017 !

[Vincent de Château-Thierry]

Salut Nicolas et tous,

Le 22/12/2016 à 10:31, Nicolas Moyroud a écrit :


Tant qu'à signaler un petit souci dans les outils d'aide à la
contribution, j'en profite aussi au passage pour demander une
amélioration concernant l'outil "voies récentes manquantes"
(http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html).
Dans la liste par département, ça affiche les 50 occurrences les plus
récentes, mais on ne peut malheureusement pas naviguer vers la suite. Le
problème c'est que maintenant dans l'Hérault je suis presque à la fin de
la liste parce qu'il y a plein de rues que je n'ai jamais réussi à
trouver (même en cherchant beaucoup) et donc que je ne peux pas faire.
Donc je vais bientôt être bloqué. Si c'était possible de prévoir un
bandeau de navigation "page suivante / page précédente" ce serait super !


J'aurais aimé caser ça avant Noël, mais de façon plus réaliste ce sera 
pour la rentrée.


vincent

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Nicolas Moyroud]

Salut,

Merci Christian pour ce travail de fou sur le rendu FR !

Une remarque qui n'est pas directement liée au rendu FR, mais plutôt à 
la couche "zones à mapper" sur tile fr. Il y a toujours des communes qui 
s'affichent avec le rond vert/bleu des bâtiments manquants alors qu'elle 
sont totalement renseignées en bati. Exemples :

http://tile.openstreetmap.fr/?zoom=15=43.73936=3.8602=B000TF
http://tile.openstreetmap.fr/?zoom=16=43.56325=3.28654=B000TF
http://tile.openstreetmap.fr/?zoom=15=43.62998=3.24387=B000TF
Le problème c'est que dans l'Hérault il ne reste plus beaucoup de 
communes à faire. Du coup, avec tout ce bruit la couche n'aide plus à 
savoir où il reste vraiment du travail...


Tant qu'à signaler un petit souci dans les outils d'aide à la 
contribution, j'en profite aussi au passage pour demander une 
amélioration concernant l'outil "voies récentes manquantes" 
(http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html).
Dans la liste par département, ça affiche les 50 occurrences les plus 
récentes, mais on ne peut malheureusement pas naviguer vers la suite. Le 
problème c'est que maintenant dans l'Hérault je suis presque à la fin de 
la liste parce qu'il y a plein de rues que je n'ai jamais réussi à 
trouver (même en cherchant beaucoup) et donc que je ne peux pas faire. 
Donc je vais bientôt être bloqué. Si c'était possible de prévoir un 
bandeau de navigation "page suivante / page précédente" ce serait super !


Nicolas


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Francescu GAROBY]

Je trouve moi aussi que c'est très bien, cette estompe pour les choses
"souterraines" !
1 remarque toutefois : le rendu d'une voie souterraine n'a pas la même
couleur, selon que le bâtiment en surface a des murs ou pas ! Cf. la voie
souterraine, à coté du texte "Communauté d'agglomération Caen-la-Mer"
.
Je me rends bien compte que cela doit être dû à la couleur de la zone sans
mur "qui est l'allée principale de la galerie commerciale), mais du coup,
ça fait ressortir un tronçon...

Autre remarque : les entrées (entrance=main) ont un rendu qui n'est pas
clair : un simple point noir.



Francescu

Le 22 décembre 2016 à 09:51, PanierAvide  a écrit :

> Youpi, le premier rendu à considérer un minimum les objets indoor est le
> rendu FR :-) C'est pas mal l'idée d'estomper, moins agressif que le binaire
> afficher/cacher, tout en cachant quand même un peu ces objets qui ne sont
> pas au niveau du sol.
>
> Ce serait également pertinent d'adapter le rendu pour les routes/chemins
> avec un level > 0 (à voir si c'est faisable), exemple du parking aérien sur
> 2 niveaux :
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#18/48.08312/-1.67948
>
> Cordialement,
>
> PanierAvide.
>
> Le 21/12/2016 à 19:45, Christian Quest a écrit :
>
> Je profite des congés pour avancer sur le rendu FR...
>
> La liste des commit s'allonge et donne une idée des changements:
> https://github.com/cquest/osmfr-cartocss/commits/master
>
> Après avoir passé pas mal de temps sur les optimisations pour accélrer le
> rendu là où c'était le plus urgent, je suis de retour sur le côté graphique.
>
> Une grosse nouveauté: l'estompage des objets "indoor" qui devrait alléger
> les abords de certaines gares ;) Pour ça, le rendu considère tout objet
> avec un level=* négatif comme indoor.
>
> Les "shield" sur les routes sont mieux répartis. Pour cela, la requête SQL
> regroupe les différents tronçons ayant le même highway+ref car vu qu'on
> tronçonne de plus en plus il faut en passer par là !
>
> Résultat visible sur http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_
> 99740#6/47.376/2.186
>
> Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo et
> peut nécessiter un délais de génération...
>
>
> --
> 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
>
>


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[PanierAvide]

Youpi, le premier rendu à considérer un minimum les objets indoor est le 
rendu FR :-) C'est pas mal l'idée d'estomper, moins agressif que le 
binaire afficher/cacher, tout en cachant quand même un peu ces objets 
qui ne sont pas au niveau du sol.


Ce serait également pertinent d'adapter le rendu pour les routes/chemins 
avec un level > 0 (à voir si c'est faisable), exemple du parking aérien 
sur 2 niveaux :


http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.08312/-1.67948

Cordialement,

PanierAvide.


Le 21/12/2016 à 19:45, Christian Quest a écrit :

Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements: 
https://github.com/cquest/osmfr-cartocss/commits/master


Après avoir passé pas mal de temps sur les optimisations pour accélrer 
le rendu là où c'était le plus urgent, je suis de retour sur le côté 
graphique.


Une grosse nouveauté: l'estompage des objets "indoor" qui devrait 
alléger les abords de certaines gares ;) Pour ça, le rendu considère 
tout objet avec un level=* négatif comme indoor.


Les "shield" sur les routes sont mieux répartis. Pour cela, la requête 
SQL regroupe les différents tronçons ayant le même highway+ref car vu 
qu'on tronçonne de plus en plus il faut en passer par là !


Résultat visible sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186


Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo 
et peut nécessiter un délais de génération...



--
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, bientôt en version 2017 !

[Philippe Verdy]

sans discussion, ce sont les platform (=anciens bux_stop) qu'il faut
afficher. les "stop_position" du nouveau schéma sont destinés aux
interconnexions et outils de vérification des lignes qui peuvent détecter
avec eux des arrêts non desservis par le chemin (soit parce que le chemin
est brisé, soit parce que c'est le "'stop_position" associé à la mauvaise
plateforme qui a été sélectionné).

Je ne vois pas trop l'intérêt dans le rendu **généraliste** d'afficher les
"stop_position" au milieu de la rue (pas même leur nom), mais peut-être que
ça peut être utile dans un rendu public transport, qui préférera les
utiliser au lieu des plateforme. Les stop position devraient être
particulièrement utiles pour les recherches d'itinéraires, et identifier le
nom et la localisation exacte des arrêts pour monter ou descendre sur un
itinéraire. Dans un tel cas, le rendu spécialisé pourra largement
simplifier ou même ne pas afficher du tout le reste de la carte et
présenter un plan plus schématique avec juste les chemins reliant les
"stop_position", et dont la géométrie peut être alors simplifiée.


Le 22 décembre 2016 à 03:02, Christian Quest  a
écrit :

> Le 22 décembre 2016 à 01:05, Jérôme Amagat  a
> écrit :
>
>> on parle beaucoup des transport public en ce moment, ça serait bien que
>> les arrets de bus, tram metro ... soit rendu qu'avec des tag
>> public_transport= et aussi si ce n'est pas un node mais un way ou
>> multipolygon.
>>
>
>>
>
> Je ne pense pas que ce soit une bonne idée de forcer ainsi la main pour
> adopter un modèle bien complexe pour le contributeur lambda.
>
> Si on veut détecter les arrêts à mettre à jour, il faut le faire avec des
> outils de QA comme osmose, pas avec un rendu assez généraliste.
>
>
> Pour la prise en compte des polygones, je vais regarder ce qu'il est
> possible de faire, mais mes souvenirs c'est qu'il est bien complexe de
> prendre en compte le schéma public_transport au niveau du rendu.
>
> On met quoi sur le rendu ? public_transport=stop_position ou
> public_transport=platform ?
>
> Si on a un highway=bus_stop comment on évite d'avoir un doublon ?
>
> Heureusement que postgis a maintenant de quoi générer des cluster... ça va
> peut être être la solution: on met tout ensemble et on fait un cluster ;)
>
> --
> 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, bientôt en version 2017 !

[Christian Quest]

Le 22 décembre 2016 à 01:05, Jérôme Amagat  a
écrit :

> on parle beaucoup des transport public en ce moment, ça serait bien que
> les arrets de bus, tram metro ... soit rendu qu'avec des tag
> public_transport= et aussi si ce n'est pas un node mais un way ou
> multipolygon.
>

>

Je ne pense pas que ce soit une bonne idée de forcer ainsi la main pour
adopter un modèle bien complexe pour le contributeur lambda.

Si on veut détecter les arrêts à mettre à jour, il faut le faire avec des
outils de QA comme osmose, pas avec un rendu assez généraliste.


Pour la prise en compte des polygones, je vais regarder ce qu'il est
possible de faire, mais mes souvenirs c'est qu'il est bien complexe de
prendre en compte le schéma public_transport au niveau du rendu.

On met quoi sur le rendu ? public_transport=stop_position ou
public_transport=platform ?

Si on a un highway=bus_stop comment on évite d'avoir un doublon ?

Heureusement que postgis a maintenant de quoi générer des cluster... ça va
peut être être la solution: on met tout ensemble et on fait un cluster ;)

-- 
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, bientôt en version 2017 !

[Christian Quest]

Le 21 décembre 2016 à 23:56,  a écrit :

> Niveau 10
> 
> :
>
> les zones militaires et zones protégées me semblent trop mises en avant.
>

La zone en elle même n'a pas changé, il n'y a que le texte qui a changé
(taille et couleur)... je vais l'assombrir un peu


> Niveau 11
> 
> :
>
> et sans doute ailleurs : pas de repliement de ligne sue la BAN de
> Lann-Bihoué mais sur Guidel-Plages.
>
>
?? lien ??


> Pourtant le nom déborde de la zone militaire.
>

ça , les noms peuvent déborder si la forme est très allongée. La taille du
texte varie avec la surface du polygone, mais pas en prenant compte sa
largeur et/ou hauteur.


> Ce rendu met bien en évidence les niveaux des routes, le Wiki ou les
> outils ne doivent pas être assez précis :
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#13/47.8569/-3.5315
> Pour les dédoublement de noms, soit les tuiles sont trop petites soit il y
> a encore des progrès à faire (appliquer l'algo des ref ?) :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#17/48.38764/-4.46565
>

Difficile avec les voies à chaussées séparées. Ce sont deux lignes
distinctes et pas facile de les fusionner en une seule...



>
> En regardant là :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#18/48.39598/-4.44701
> On se dit que c'est plus subtile : tant qu'il n'y a pas d'intersection
> inutile de répéter (sauf si très éloignés). Et si intersection alors si au
> début on met le nom, à la fin aussi, on en déduit qu'entre c'est le même
> nom.
> On peut aussi vouloir privilégier les tronçons ouest-est (rue
> Jouveau-Dubreuil : plutôt entre les numéros 52 et 29 qu'avant ou après).
> Oui ce n'est plus du peaufinage, c'est de l'art ;-).
>
>
C'est surtout un équilibre à trouver car si on ne répète pas du tout les
noms, comme on ne sait pas quelle partie de la care est visualisée sur une
petite surface (genre mobile ou petite carte en ligne), on peut très bien
ne pas avoir de nom visible pour une voie qui traverse la carte.

Aller dans le détail des intersections comme tu le suggère n'est pas simple
non plus... j'imagine la complexité des requêtes pour obtenir ces infos !



> Là aussi, mais c'est sans doute un pb côté données (une relation associant
> les différents bâtiments du collège) :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#19/48.39819/-4.45559
>
>
Oui, clairement un problème de données...

chaque polygone de bâti a son tag amenity=school et school:FR=collège... on
a donc 4 collèges !

Un polygone englobant toute l'emprise du collège est bien sûr la solution
parce qu'en plus un collège ce n'est pas qu'un bâtiment, c'est une cour, un
parking, des terrains de sport, etc... j'ai corrigé.



> Rendu ou données incorrectes ?
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#19/48.39896/-4.40997
> http://www.openstreetmap.org/#map=19/48.39886/-4.40977
>
>
Là je sèche...

-- 
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, bientôt en version 2017 !

[Jérôme Amagat]

on parle beaucoup des transport public en ce moment, ça serait bien que les
arrets de bus, tram metro ... soit rendu qu'avec des tag public_transport=
et aussi si ce n'est pas un node mais un way ou multipolygon.


Le 21 décembre 2016 à 23:56,  a écrit :

> Niveau 10
> 
> :
>
> les zones militaires et zones protégées me semblent trop mises en avant.
>
> Niveau 11
> 
> :
>
> et sans doute ailleurs : pas de repliement de ligne sue la BAN de
> Lann-Bihoué mais sur Guidel-Plages.
>
> Pourtant le nom déborde de la zone militaire.
>
> Ce rendu met bien en évidence les niveaux des routes, le Wiki ou les
> outils ne doivent pas être assez précis :
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#13/47.8569/-3.5315
> Pour les dédoublement de noms, soit les tuiles sont trop petites soit il y
> a encore des progrès à faire (appliquer l'algo des ref ?) :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#17/48.38764/-4.46565
> En regardant là :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#18/48.39598/-4.44701
> On se dit que c'est plus subtile : tant qu'il n'y a pas d'intersection
> inutile de répéter (sauf si très éloignés). Et si intersection alors si au
> début on met le nom, à la fin aussi, on en déduit qu'entre c'est le même
> nom.
> On peut aussi vouloir privilégier les tronçons ouest-est (rue
> Jouveau-Dubreuil : plutôt entre les numéros 52 et 29 qu'avant ou après).
> Oui ce n'est plus du peaufinage, c'est de l'art ;-).
>
> Là aussi, mais c'est sans doute un pb côté données (une relation associant
> les différents bâtiments du collège) :
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#19/48.39819/-4.45559
>
> Rendu ou données incorrectes ?
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#19/48.39896/-4.40997
> http://www.openstreetmap.org/#map=19/48.39886/-4.40977
>
>
> 
> Le 21/12/2016 à 19:45, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Je profite des congés pour avancer sur le rendu FR...
>
> La liste des commit s'allonge et donne une idée des changements:
> https://github.com/cquest/osmfr-cartocss/commits/master
>
> Après avoir passé pas mal de temps sur les optimisations pour accélrer le
> rendu là où c'était le plus urgent, je suis de retour sur le côté graphique.
>
> Une grosse nouveauté: l'estompage des objets "indoor" qui devrait alléger
> les abords de certaines gares ;) Pour ça, le rendu considère tout objet
> avec un level=* négatif comme indoor.
>
> Les "shield" sur les routes sont mieux répartis. Pour cela, la requête SQL
> regroupe les différents tronçons ayant le même highway+ref car vu qu'on
> tronçonne de plus en plus il faut en passer par là !
>
> Résultat visible sur http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_
> 99740#6/47.376/2.186
>
> Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo et
> peut nécessiter un délais de génération...
>
>
> --
> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[osm . sanspourriel]

Niveau 10 
 
:


les zones militaires et zones protégées me semblent trop mises en avant.

Niveau 11 
 
:


et sans doute ailleurs : pas de repliement de ligne sue la BAN de 
Lann-Bihoué mais sur Guidel-Plages.


Pourtant le nom déborde de la zone militaire.

Ce rendu met bien en évidence les niveaux des routes, le Wiki ou les 
outils ne doivent pas être assez précis :


http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#13/47.8569/-3.5315

Pour les dédoublement de noms, soit les tuiles sont trop petites soit il 
y a encore des progrès à faire (appliquer l'algo des ref ?) :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#17/48.38764/-4.46565
En regardant là :
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.39598/-4.44701
On se dit que c'est plus subtile : tant qu'il n'y a pas d'intersection 
inutile de répéter (sauf si très éloignés). Et si intersection alors si 
au début on met le nom, à la fin aussi, on en déduit qu'entre c'est le 
même nom.
On peut aussi vouloir privilégier les tronçons ouest-est (rue 
Jouveau-Dubreuil : plutôt entre les numéros 52 et 29 qu'avant ou après). 
Oui ce n'est plus du peaufinage, c'est de l'art ;-).


Là aussi, mais c'est sans doute un pb côté données (une relation 
associant les différents bâtiments du collège) :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#19/48.39819/-4.45559

Rendu ou données incorrectes ?
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#19/48.39896/-4.40997
http://www.openstreetmap.org/#map=19/48.39886/-4.40977

Le 21/12/2016 à 19:45, Christian Quest - cqu...@openstreetmap.fr a écrit :

Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements: 
https://github.com/cquest/osmfr-cartocss/commits/master


Après avoir passé pas mal de temps sur les optimisations pour accélrer 
le rendu là où c'était le plus urgent, je suis de retour sur le côté 
graphique.


Une grosse nouveauté: l'estompage des objets "indoor" qui devrait 
alléger les abords de certaines gares ;) Pour ça, le rendu considère 
tout objet avec un level=* négatif comme indoor.


Les "shield" sur les routes sont mieux répartis. Pour cela, la requête 
SQL regroupe les différents tronçons ayant le même highway+ref car vu 
qu'on tronçonne de plus en plus il faut en passer par là !


Résultat visible sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186


Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo 
et peut nécessiter un délais de génération...



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

[OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Christian Quest]

Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements:
https://github.com/cquest/osmfr-cartocss/commits/master

Après avoir passé pas mal de temps sur les optimisations pour accélrer le
rendu là où c'était le plus urgent, je suis de retour sur le côté graphique.

Une grosse nouveauté: l'estompage des objets "indoor" qui devrait alléger
les abords de certaines gares ;) Pour ça, le rendu considère tout objet
avec un level=* négatif comme indoor.

Les "shield" sur les routes sont mieux répartis. Pour cela, la requête SQL
regroupe les différents tronçons ayant le même highway+ref car vu qu'on
tronçonne de plus en plus il faut en passer par là !

Résultat visible sur
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186

Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo et
peut nécessiter un délais de génération...


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