Re: [OSM-talk-fr] rendu osmfr

[Maël REBOUX]

On peut voter sur une issue si on s’accorde sur la façon de le faire, en 
détournant un peu le système.

Ne comptent que les votes exprimés par un pouce levé en réaction sur le post 
initial.
À la fin on comptabilise et on peut ajouter un label / une étiquette qui 
correspond au vote.

C’est très manuel mais ça permet de discriminer ce qui va être pointé 
communément comme important ou pas.
Exemple : https://github.com/sigrennesmetropole/visualiseur/issues/31 
 

Je te pousserai des PR si je m’ennuie sur la carte en langues minoritaires ou 
quand j’aurais résolu mon pb de relations-géométries.

kenavo

> Le 9 oct. 2018 à 08:42, Christian Quest  a écrit :
> 
> Si il y a des améliorations du rendu international que vous voudriez 
> retrouver dans la prochaine mise à jour du rendu FR (en général je m'y met en 
> fin d'année), c'est le moment de les lister.
> 
> Le mieux c'est de mettre ça en issues sur 
> https://github.com/cquest/osmfr-cartocss/issues 
> 
> Il manque presque un système de vote ;)
> 
> Le top c'est de proposer directement des PR, mais c'est un poil plus complexe.
> 
> Le lun. 8 oct. 2018 à 22:35, marc marc  > a écrit :
> > c'est quoi le "rendu fr" ? Il y a un 
> > rendu différent en fonction de la langue du navigateur web ?
> 
> techniquement ce serrait possible mais rare sont les sites qui le font.
> le rendu fr ou rendu osmfr est un fork (une copie adapté) du rendu 
> classique https://tile.openstreetmap.fr/ 
> la grande différence avec le rendu de https://www.openstreetmap.org 
> 
> c'est que le rendu fr utilise par défaut le nom en français (le tag 
> name:fr) lorsqu'il est présent tandis que le rendu osm.org  
> utilise
> le nom "local" (le tag name).
> il y avait à l'origine quelques spécificité au rendu osmfr tel que
> la baguette, le rendu des terrains de sport et le niveau de zoom 20
> mais avec le temps, les différences se creusent, le rendu osm.org 
>  
> évoluant + vite que celui osmfr
> comparaison https://mc.bbbike.org/mc/?num=2=mapnik=osmfr 
> 
> diff 448 commits présent sur osmfr mais pas osm.org , 2797 
> commits 
> présent sur osm.org  mais pas sur osmfr
> ___
> 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 osmfr

[Christian Quest]

Si il y a des améliorations du rendu international que vous voudriez
retrouver dans la prochaine mise à jour du rendu FR (en général je m'y met
en fin d'année), c'est le moment de les lister.

Le mieux c'est de mettre ça en issues sur
https://github.com/cquest/osmfr-cartocss/issues
Il manque presque un système de vote ;)

Le top c'est de proposer directement des PR, mais c'est un poil plus
complexe.

Le lun. 8 oct. 2018 à 22:35, marc marc  a écrit :

> > c'est quoi le "rendu fr" ? Il y a un
> > rendu différent en fonction de la langue du navigateur web ?
>
> techniquement ce serrait possible mais rare sont les sites qui le font.
> le rendu fr ou rendu osmfr est un fork (une copie adapté) du rendu
> classique https://tile.openstreetmap.fr/
> la grande différence avec le rendu de https://www.openstreetmap.org
> c'est que le rendu fr utilise par défaut le nom en français (le tag
> name:fr) lorsqu'il est présent tandis que le rendu osm.org utilise
> le nom "local" (le tag name).
> il y avait à l'origine quelques spécificité au rendu osmfr tel que
> la baguette, le rendu des terrains de sport et le niveau de zoom 20
> mais avec le temps, les différences se creusent, le rendu osm.org
> évoluant + vite que celui osmfr
> comparaison https://mc.bbbike.org/mc/?num=2=mapnik=osmfr
> diff 448 commits présent sur osmfr mais pas osm.org, 2797 commits
> présent sur osm.org mais pas sur osmfr
> ___
> 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

[OSM-talk-fr] rendu osmfr

[marc marc]

> c'est quoi le "rendu fr" ? Il y a un 
> rendu différent en fonction de la langue du navigateur web ?

techniquement ce serrait possible mais rare sont les sites qui le font.
le rendu fr ou rendu osmfr est un fork (une copie adapté) du rendu 
classique https://tile.openstreetmap.fr/
la grande différence avec le rendu de https://www.openstreetmap.org
c'est que le rendu fr utilise par défaut le nom en français (le tag 
name:fr) lorsqu'il est présent tandis que le rendu osm.org utilise
le nom "local" (le tag name).
il y avait à l'origine quelques spécificité au rendu osmfr tel que
la baguette, le rendu des terrains de sport et le niveau de zoom 20
mais avec le temps, les différences se creusent, le rendu osm.org 
évoluant + vite que celui osmfr
comparaison https://mc.bbbike.org/mc/?num=2=mapnik=osmfr
diff 448 commits présent sur osmfr mais pas osm.org, 2797 commits 
présent sur osm.org mais pas sur osmfr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu osmfr en retard > 24h

[marc marc]

Bonjour,

pour le rendu osm-fr
le lag de replication (le nombre de min de retard pour les diff)
http://munin.openstreetmap.fr/openstreetmap.fr/osm25.openstreetmap.fr/osm_replication_lag.html
pas d'anomalie générale.
mais on n'a pas de stat de la fille d'attente de maj des tuiles
J'imagine qu'on a le même soucis qu'avec le rendu hot càd en résumé : 
maj temps réel lente et file de maj trop petite ce qui fait qu'on sert
des vieilles tuiles parfois pendant des heures.

pour ceux que cela intéresse la comparaison détaillée pour le rendu hot
http://munin.openstreetmap.fr/munin-cgi/munin-cgi-graph/openstreetmap.fr/osm13.openstreetmap.fr/osm_replication_lag_osm2pgsql-day.png
de temos 4h de lag
http://munin.openstreetmap.fr/munin-cgi/munin-cgi-graph/openstreetmap.fr/osm13.openstreetmap.fr/renderd_queue-day.png
comme sur osm.org la file est trop petite donc une maj en journée
risque de ne pas provoquer de maj en temps réel ce qui implique
qu'on va essayer de faire la maj lors de la demande de la tuile
http://munin.openstreetmap.fr/munin-cgi/munin-cgi-graph/openstreetmap.fr/osm13.openstreetmap.fr/mod_tile_fresh-day.png
on voit que 3 tuiles/sec sont faite en temps réel
et que 7 tuiles/sec n'ont pas pu être maj en temps réel
et donc on a servit la tuile sans maj
on voit sur le graphe suivant qu'entre 9h et 21h on n'arrive pas non 
plus a traiter toutes les maj en différée
http://munin.openstreetmap.fr/static/dynazoom.html?plugin_name=openstreetmap.fr%2Fosm13.openstreetmap.fr%2Frenderd_processed_iso8601=2018-05-20T00%3A00%3A00%2B0200_iso8601=2018-05-21T00%3A00%3A00%2B0200_epoch=1526767200_epoch=1526853600_limit=0_limit=1_x=1200_y=600_graph=%2Fmunin-cgi%2Fmunin-cgi-graph

Je me propose de rajouter les moniteurs manquants pour le rendu osm-fr
et tweater quelque peu les serveurs pour gagner en perf
le détail https://github.com/osm-fr/infrastructure/issues/27

Cordialement,
Marc


Le 21. 05. 18 à 16:53, Christian Quest a écrit :
> Par endroit peut être... il y a des caches entre toi et le serveur de 
> rendu, mais je viens de regarder des modifs faites il y a moins de 24h, 
> et elles sont bien visibles :)
> 
> 2018-05-21 16:07 GMT+02:00 Cyrille37 OSM  >:
> 
> Hello
> 
> Avez-vous remarqué que le rendu osmfr sur
> http://tile.openstreetmap.fr a plus de 24h de retard ?
> 
> Merci
> Cyrille37.
> 
> 
> ___
> 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 osmfr en retard > 24h

[Christian Quest]

Par endroit peut être... il y a des caches entre toi et le serveur de
rendu, mais je viens de regarder des modifs faites il y a moins de 24h, et
elles sont bien visibles :)

2018-05-21 16:07 GMT+02:00 Cyrille37 OSM :

> Hello
>
> Avez-vous remarqué que le rendu osmfr sur http://tile.openstreetmap.fr a
> plus de 24h de retard ?
>
> Merci
> Cyrille37.
>
>
> ___
> 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

[OSM-talk-fr] Rendu osmfr en retard > 24h

[Cyrille37 OSM]

Hello

Avez-vous remarqué que le rendu osmfr sur http://tile.openstreetmap.fr a 
plus de 24h de retard ?


Merci
Cyrille37.


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

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Christian Quest]

Plutôt faute à pas de temps... mais je vais profiter des congés pour 
regarder ça.


C'est sûrement un bug dans l'ordre des couches sur les premiers zoom 
avec la landuse qui vient écraser le reste alors qu'il devrait être en 
dessous.



Le 31/07/2017 à 21:10, Adrien Grellier a écrit :


Bonjour,

En février j'avais pointé un problème dans le rendu OSM-FR, sur les 
noms de pays.


Aujourd'hui je constate que ça n'a pas changé, mais que les mises à 
jour des tuiles ne se font pas à partir d'un certain niveau, comme par 
ex. ici :


http://tile.openstreetmap.fr/?zoom=13=47.33279=-1.50283=B00FF

En zoomant d'un cran, certaines zones ajoutées il y a un moment 
apparaissent.



Est-ce un problème de serveur surchargé ? Un bug inextricable ? Ou 
simplement la faute à « pas le temps » ?


J'aime bien ce rendu, que j'utilise dans un cadre associatif, donc 
s'il y a quelque chose que je peux faire pour améliorer la situation…


Bonne soirée

Adrien




--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Adrien Grellier]

Bonjour,

En février j'avais pointé un problème dans le rendu OSM-FR, sur les noms
de pays.

Aujourd'hui je constate que ça n'a pas changé, mais que les mises à jour
des tuiles ne se font pas à partir d'un certain niveau, comme par ex. ici :

http://tile.openstreetmap.fr/?zoom=13=47.33279=-1.50283=B00FF

En zoomant d'un cran, certaines zones ajoutées il y a un moment
apparaissent.


Est-ce un problème de serveur surchargé ? Un bug inextricable ? Ou
simplement la faute à « pas le temps » ?

J'aime bien ce rendu, que j'utilise dans un cadre associatif, donc s'il
y a quelque chose que je peux faire pour améliorer la situation…

Bonne soirée

Adrien


On 13/02/2017 13:34, Adrien Grellier wrote:
> Bonjour,
>
> Le rendu OSM-FR n'affiche plus les noms de pays, à des niveaux de zoom
> haut. Par exemple si je regarde l'Afrique, les noms de pays ne
> s'affichent pas :
> http://tile.openstreetmap.fr/?zoom=4=6.43542=18.91818=B000FF
>
> Pourtant c'est une information qui peut être intéressante. Il me semble
> que sur le rendu précédent les noms de pays s'affichait bien.
>
> Si on zoome d'un cran, les capitales apparaissent, mais toujours pas les
> noms de pays :
> http://tile.openstreetmap.fr/?zoom=5=-3.7875=26.71848=B000FF
>
> Pensez-vous qu'il soit possible de faire afficher les noms de pays ?
>
> Perso ça me semble plus parlant que les capitales : je peux placer
> approximativement la Tanzanie ou le Sud-Soudan sur la carte, par contre
> Dodoma ou Djouba me sont complètement inconnu.
>
> Bonne journée
>
> Adrien
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Philippe Verdy]

Bref plus intéressant que l'article Wikipédia:

http://www.toponymiefrancophone.org/divfranco/

Là ça fait référence aux travaux du groupe de travail à l'ONU.

http://www.toponymiefrancophone.org/divfranco/genung.html

et les résolutions:

https://unstats.un.org/unsd/geoinfo/UNGEGN/docs/RES_UN_F%20updated_1-10%20CONF.pdf
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Philippe Verdy]

Note que l'article Wikipédia que tu cites ne donne même pas la référence à
cette norme internationale toponymique.

Le 26 mars 2017 à 23:03, Philippe Verdy  a écrit :

> Le 26 mars 2017 à 22:31,  a écrit :
>
>>
>> "Des" norme(s) ? En terme de normalisation internationale et dans le
>> domaine de la toponymie, il n'y en qu'une pour chaque couple d'écritures
>> (avec cependant des sections spéciales pour certains couples de langues).
>> Tous les couples d'écritures ne sont pas normalisés, la plupart du temps
>> c'est uniquement avec l'écriture latine.
>>
>> https://fr.wikipedia.org/wiki/Romanisation_(%C3%A9criture)
>> 
>> Par exemple pour la translittération du russe :
>> https://fr.wikipedia.org/wiki/Translitt%C3%A9ration_des_cara
>> ct%C3%A8res_cyrilliques_russes
>> (sans compter les fantaisies de l'administration russe lors de la
>> romanisation des prénoms ce qui pose problème car les réfugiés se
>> retrouvent avec un nom sur le passeport qui ne correspond pas à ce que
>> l'OFPRA obtient en transcrivant le nom original).
>>
>
> Et dans tout ça une seule norme *internationale* (avec plusieurs volets
> selon les couples de langues ou écritures) applicable à la *toponymie*.
>
> Les prénoms ou noms de personnes ou autres marques c'est hors sujet. On
> parlait ici uniquement de toponymie pour les noms de lieux dans OSM (non
> compris les noms de commerces et enseignes qui ne sont pas traductibles ni
> même transcriptibles à moins que ces alternatives aient été officialisées
> par leur titulaires légitimes qui ont pu même utiliser des noms très
> différents et en cumuler plusieurs visibles localement; tandisqu'ils ont pu
> aussi enregistrer des marques à usage national ou international dans un
> certain nombre d'autres pays pour leurs communications, et enregistrer dans
> leur pays plusieurs variantes dans les registres du commerce ou services
> officiels pour que ces noms fassent partie de leur identité officielle
> locale: noms d'entreprises et organisations, désignation officielle pour
> les services fiscaux)
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Philippe Verdy]

Le 26 mars 2017 à 22:31,  a écrit :

>
> "Des" norme(s) ? En terme de normalisation internationale et dans le
> domaine de la toponymie, il n'y en qu'une pour chaque couple d'écritures
> (avec cependant des sections spéciales pour certains couples de langues).
> Tous les couples d'écritures ne sont pas normalisés, la plupart du temps
> c'est uniquement avec l'écriture latine.
>
> https://fr.wikipedia.org/wiki/Romanisation_(%C3%A9criture)
> 
> Par exemple pour la translittération du russe :
> https://fr.wikipedia.org/wiki/Translitt%C3%A9ration_des_
> caract%C3%A8res_cyrilliques_russes
> (sans compter les fantaisies de l'administration russe lors de la
> romanisation des prénoms ce qui pose problème car les réfugiés se
> retrouvent avec un nom sur le passeport qui ne correspond pas à ce que
> l'OFPRA obtient en transcrivant le nom original).
>

Et dans tout ça une seule norme *internationale* (avec plusieurs volets
selon les couples de langues ou écritures) applicable à la *toponymie*.

Les prénoms ou noms de personnes ou autres marques c'est hors sujet. On
parlait ici uniquement de toponymie pour les noms de lieux dans OSM (non
compris les noms de commerces et enseignes qui ne sont pas traductibles ni
même transcriptibles à moins que ces alternatives aient été officialisées
par leur titulaires légitimes qui ont pu même utiliser des noms très
différents et en cumuler plusieurs visibles localement; tandisqu'ils ont pu
aussi enregistrer des marques à usage national ou international dans un
certain nombre d'autres pays pour leurs communications, et enregistrer dans
leur pays plusieurs variantes dans les registres du commerce ou services
officiels pour que ces noms fassent partie de leur identité officielle
locale: noms d'entreprises et organisations, désignation officielle pour
les services fiscaux)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Philippe Verdy]

Le 26 mars 2017 à 19:23, Jérôme Amagat  a écrit :

> Vous parlez de "noms officiels", c'est sur que chaque ville (ou pays ou
> île ou ...) n'ont pas officiellement un nom dans chaque langue du monde
> mais la romanisation des noms, l'histoire ... leurs a quand même donné un
> nom d'"usage" (parfois il y en a plusieurs qui coexistent). il me semble
> aussi que la "France" a comme nom officiel "République française" et
> pourtant dans osm son name est France.
>

France n'est pas qu'un nom d'usage, il est officialisé aussi, les normes
distinghant les formes longues et formes courtes.

>
> Pour le plugin wikipedia de josm (menu données puis ajout du nom depuis
> wikipedia), vous ne connaissez pas un moyen de tout désélectionner pour
> après ne sélectionner que les langues qui nous plaise?
>
>
>
>
>> Comme dit Philippe, bien des noms sont des transcriptions/romanisations,
>> pas des noms officiels.
>> Quel statut leur donner ? Ce sont des noms rarement sur le terrain mais
>> qu'on peut retrouver dans la littérature.
>>
>>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[osm . sanspourriel]

Le 26/03/2017 à 19:14, Philippe Verdy - verd...@wanadoo.fr a écrit :
Le 26 mars 2017 à 17:38, > a écrit :


Et si on romanise, il existe des normes. Oui des, pas une, même
pour un pays donné vers une langue donnée.


"Des" norme(s) ? En terme de normalisation internationale et dans le 
domaine de la toponymie, il n'y en qu'une pour chaque couple 
d'écritures (avec cependant des sections spéciales pour certains 
couples de langues). Tous les couples d'écritures ne sont pas 
normalisés, la plupart du temps c'est uniquement avec l'écriture latine.


https://fr.wikipedia.org/wiki/Romanisation_(%C3%A9criture) 


Par exemple pour la translittération du russe :
https://fr.wikipedia.org/wiki/Translitt%C3%A9ration_des_caract%C3%A8res_cyrilliques_russes
(sans compter les fantaisies de l'administration russe lors de la 
romanisation des prénoms ce qui pose problème car les réfugiés se 
retrouvent avec un nom sur le passeport qui ne correspond pas à ce que 
l'OFPRA obtient en transcrivant le nom original).


Qu'en japonais traduit en français on utilise en général le mot anglais 
(sh pas ch) ne change rien au fait que comme indiqué on écrive Shanghaï 
et non Shanghai, Tchernobyl et non Chernobyl.
En français le « ч » russe (en cyrillique) est transcrit en tch en 
français et non en ch, indépendamment de "la" norme qui aboutit à des 
noms "anglais" et non "français". La question de Jérôme porte sur des 
noms français pas des noms anglais.


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

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Jérôme Amagat]

Le 26 mars 2017 à 17:38,  a écrit :

> Le 26/03/2017 à 05:08, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Les name:fr dans les pays qui n'ont pas l'alphabet latin, j'ai des doutes
> pour pas mal d'entre eux,
>
> Pour les noms de pays, pas de soucis, ils sont normalisés dans les 6
> langues onusiennes, donc le français.
> Pour les autres effectivement, c'est potentiellement de la
> translittération/romanisation ou de la transcription.
> Partir de la romanisation anglaise pourquoi pas, mais ce n'est pas
> l'identité (ch en anglais, tch en français et tsch en allemand sont le même
> caractère cyrillique).
> Par exemple, la lettre russe « ч » se translittère « č » (ce qui
> n'éclaire pas forcément le francophone sur sa prononciation), mais se
> transcrit « tch » en français et « ch » en anglais (ce qui correspond bien
> au même son, malgré deux écritures différentes).
> 
>
> https://fr.wikipedia.org/wiki/Romanisation_(%C3%A9criture)
> 
>
> Je crois qu'il est convenu de ne pas romaniser en name:fr, il vaut mieux
> utiliser name:fr-Latn=.
> Quoique, à lire https://wiki.openstreetmap.org/wiki/Multilingual_names,
> le code langue serait le code de la langue initiale.
> Mais dans ce sas on aura Shanghai, pas Shanghaï, Chernobyl pas Tchernobyl.
> Et alors la logique voudrait que name:-Latn soit la transcription du nom
> local principal en anglais.
>
> Le 26 mars 2017 à 04:04, Jérôme Amagat  a écrit :
>
> pour ajouter ces noms ça pourrait être intéressant d'utiliser osmose qui
>> irait chercher les nom sur wikidata sur certains objets (ville, îles,
>> région, ...) qui ont un tag wikidata.
>> ( le faire de facon automatique avec un bot)
>>
> Ça ne marche pas en automatique, au mieux un outil d'intégration style
> Osmose.
> Car les pages wikipedia ont un nom unique, pas les nom de lieu. Pour les
> wikidata, c'est entre les deux : ni unicité ni homogénéité complète.
> Par exemple la ville de Munich s'appelle Monaco en italien mais l'article
> Wikipedia (et surtout le nom Wikidata) s'appelle Monaco di Baviera pour ne
> pas confondre avec une principauté bien connue. Monaco est pourtant le nom
> en italien pour les Italiens de Munich et il figure comme nom alternatif
> italien.
> Pour prendre un cas français : Brest (anciennement Brest-Litovsk) a pour
> article https://fr.wikipedia.org/wiki/Brest_(Bi%C3%A9lorussie
> ), Brest figure
> là bien comme nom en français, Brest-Litovsk étant bien l'ancien nom en
> français.
> Je crains que sur les villes homonymes avec d'autres importantes dans la
> communauté d'une langue particulière on retrouve ce genre de cas.
>
> Pour le cas de Brest, l'utilisation de wikidata plutôt que wikipedia règle
le problème (https://www.wikidata.org/wiki/Q140147) le libellé est bien
"Brest" en français par contre il le règle pour le francais mais pas pour
toute les langues vu qu'on a des choses comme :
cebuanoBrest (kapital sa voblast)
norvégien  Brest i Kviterussland

Vous parlez de "noms officiels", c'est sur que chaque ville (ou pays ou île
ou ...) n'ont pas officiellement un nom dans chaque langue du monde mais la
romanisation des noms, l'histoire ... leurs a quand même donné un nom
d'"usage" (parfois il y en a plusieurs qui coexistent). il me semble aussi
que la "France" a comme nom officiel "République française" et pourtant
dans osm son name est France.

Pour le plugin wikipedia de josm (menu données puis ajout du nom depuis
wikipedia), vous ne connaissez pas un moyen de tout désélectionner pour
après ne sélectionner que les langues qui nous plaise?




> Comme dit Philippe, bien des noms sont des transcriptions/romanisations,
> pas des noms officiels.
> Quel statut leur donner ? Ce sont des noms rarement sur le terrain mais
> qu'on peut retrouver dans la littérature.
>
> Et si on romanise, il existe des normes. Oui des, pas une, même pour un
> pays donné vers une langue donnée.
>
> Une pensée à ce camionneur polonais ayant demandé un billet pour Brest et
> ayant atterri (*) non à la frontière Bélarus-Pologne mais vous l'avez
> compris à la pointe bretonne.
>
> Jean-Yvon
> (*) façon de parler, il était en train.
>
>
> ___
> 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 OSMFR et nom de pays

[Philippe Verdy]

Le 26 mars 2017 à 17:38,  a écrit :

> Et si on romanise, il existe des normes. Oui des, pas une, même pour un
> pays donné vers une langue donnée.
>

"Des" norme(s) ? En terme de normalisation internationale et dans le
domaine de la toponymie, il n'y en qu'une pour chaque couple d'écritures
(avec cependant des sections spéciales pour certains couples de langues).
Tous les couples d'écritures ne sont pas normalisés, la plupart du temps
c'est uniquement avec l'écriture latine.

Qui vient en second après les noms officiellement adoptés par les
représentations diplomatiques officielles à l'ONU ou dans d'autres pays, où
cette graphie peut parfois varier pour ménager les susceptibilités locales,
en ajoutant des précisions ou reprenant les noms d'usage locaux adoptés
séparément dans ces pays, par exemple les listes de toponymes faites par en
France par les commissions nationales de toponymie), les autres sont des
normes nationales ou utilisées dans d'autres domaines (aviation, navigation
maritime, etc.) et pas forcément non plus des domaines officiels (noms
d'usage commercial ou publicitaire, contraints toutefois par le droit des
marques applicable localement).

Ne pas confondre avec les pseudo-normes concernant la transliteration de
textes quelconques (ou de noms propres: là chaque pays fait ce qu'il veut,
il peut normaliser ou pas, la Chine a son système de romanisation officiel,
le Pinyin, mais qui ne s'applique pas à d'autres langues que le mandarin ou
les langues chinoises régionales reconnues par la république populaire
comme le cantonais, mais le min nan a son propre système de romanisation
qui est devenu même sa norme moderne d'écriture à la place des anciens
caractères sinographiques; le taiwanais n'utilise pas le Pinyin, mais la
république populaire a établi une toponymie romanisée en Pinyin pour
Taiwan, non appliquée localement à Taïwan; le Pinyin a été adopté en
revanche par Singapour). Il y a d'autres romanisations du chinois,
notamment aux Etats-Unis, mais inapplicable pour les tonopymes américains
et pas plus aux toponymes à afficher pour des lieux en Chine ou à Taiwan.

En Chine du Sud, le Pinyin n'est pas très populaire, on lui préfère une
transcription non latine en bopomofo. Au Japon, la romanisation des kanjis
(le système "romaji") n'est pas populaire non plus ou lui préfère les
transcriptions en kanas, et la plupart des toponymes romanisés (utilisés
surtout en anglais) sont dérivés directement des transcriptions en kanas et
non des kanjis, il ne reste alors aux autres langues que quelques toponymes
connus dans leur langue échappant à la romanisation directe, comme Japon et
Tokyo en français, en abandonnant la notation des voyelles longues avec le
diacritique macron en chef, mais ces diacritiques sont de plus en plus
utilisés pour lever des cas d'homonymies, même sur des noms connus en
français comme Honshu). En aucun cas en français je n'ai vu des toponymes
japonais transcrits avec "tch", c'est toujours "ch" comme en anglais,
distingué du "sh" anglais utilisé aussi en français (donc "Honshu", pas
"Honchu"...)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[osm . sanspourriel]

Le 26/03/2017 à 05:08, Philippe Verdy - verd...@wanadoo.fr a écrit :
Les name:fr dans les pays qui n'ont pas l'alphabet latin, j'ai des 
doutes pour pas mal d'entre eux,
Pour les noms de pays, pas de soucis, ils sont normalisés dans les 6 
langues onusiennes, donc le français.
Pour les autres effectivement, c'est potentiellement de la 
translittération/romanisation ou de la transcription.
Partir de la romanisation anglaise pourquoi pas, mais ce n'est pas 
l'identité (ch en anglais, tch en français et tsch en allemand sont le 
même caractère cyrillique).
Par exemple, la lettre russe « ч » se translittère « č » (ce qui 
n'éclaire pas forcément le francophone sur sa prononciation), mais se 
transcrit « tch » en français et « ch » en anglais (ce qui correspond 
bien au même son, malgré deux écritures différentes). 



https://fr.wikipedia.org/wiki/Romanisation_(%C3%A9criture) 



Je crois qu'il est convenu de ne pas romaniser en name:fr, il vaut mieux 
utiliser name:fr-Latn=.
Quoique, à lire https://wiki.openstreetmap.org/wiki/Multilingual_names, 
le code langue serait le code de la langue initiale.

Mais dans ce sas on aura Shanghai, pas Shanghaï, Chernobyl pas Tchernobyl.
Et alors la logique voudrait que name:-Latn soit la transcription du nom 
local principal en anglais.


Le 26 mars 2017 à 04:04, Jérôme Amagat > a écrit :


pour ajouter ces noms ça pourrait être intéressant d'utiliser
osmose qui irait chercher les nom sur wikidata sur certains objets
(ville, îles, région, ...) qui ont un tag wikidata.
( le faire de facon automatique avec un bot)

Ça ne marche pas en automatique, au mieux un outil d'intégration style 
Osmose.
Car les pages wikipedia ont un nom unique, pas les nom de lieu. Pour les 
wikidata, c'est entre les deux : ni unicité ni homogénéité complète.
Par exemple la ville de Munich s'appelle Monaco en italien mais 
l'article Wikipedia (et surtout le nom Wikidata) s'appelle Monaco di 
Baviera pour ne pas confondre avec une principauté bien connue. Monaco 
est pourtant le nom en italien pour les Italiens de Munich et il figure 
comme nom alternatif italien.
Pour prendre un cas français : Brest (anciennement Brest-Litovsk) a pour 
article https://fr.wikipedia.org/wiki/Brest_(Bi%C3%A9lorussie 
), Brest figure 
là bien comme nom en français, Brest-Litovsk étant bien l'ancien nom en 
français.
Je crains que sur les villes homonymes avec d'autres importantes dans la 
communauté d'une langue particulière on retrouve ce genre de cas.


Comme dit Philippe, bien des noms sont des transcriptions/romanisations, 
pas des noms officiels.
Quel statut leur donner ? Ce sont des noms rarement sur le terrain mais 
qu'on peut retrouver dans la littérature.


Et si on romanise, il existe des normes. Oui des, pas une, même pour un 
pays donné vers une langue donnée.


Une pensée à ce camionneur polonais ayant demandé un billet pour Brest 
et ayant atterri (*) non à la frontière Bélarus-Pologne mais vous l'avez 
compris à la pointe bretonne.


Jean-Yvon
(*) façon de parler, il était en train.

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

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Christian Quest]

Cet absence de noms de pays n'est pas voulue, c'est clairement un bug à
corriger. Je suis bien etonné de ne pas l'avoir vu car cette nouvelle
version est en ligne depuis décembre.


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

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Philippe Verdy]

Les name:fr dans les pays qui n'ont pas l'alphabet latin, j'ai des doutes
pour pas mal d'entre eux, quand la plupart du temps ils se contentent juste
de formaliser leur romanisation, avec une orthographe simplifiée pour
l'anglais, donc en supprimant pas mal de diacritiques sauf ceuw qui sont
nécessaires aux distinctions phonétiques qu'ils considèrent importantes
pour leur langue (exemple: emploi ou pas des diacritiques de longueur ou
marques de ton).

Dans les faits ces noms ne sont pas non plus réellement en anglais hormis
les usages anciens attestés pour quelques toponymes bien connus (lors
d'époques coloniales passées ou parce que ces pays continuent à décrire
leur toponymie aussi dans d'autres langues dans des institutions
internationales ou des représentations diplomatiques).

Bref là où on attend quelquechose c'est d'abord des romanisations surtout
pour les écritures sinographiques, arabes et indiennes. Pour le cyrillique,
ou le grec les modèles de romanisation standards de la toponymie suffisent
la plupart du temps à combler les trous: ce serait pas mal pour la version
française de combler les trous avec ces systèmes standardisés de
romanisation en usage pour la toponymie.
Pour les noms sinographiques, là c'est difficile: il faudrait des sources
nationales pour les romaniser (par exemple le Pinyin en Chine). Les
standards de romanisation pour l'arabe ou les écritures indiennes marchent
mal, mais ces pays ont largemetn développé des romanisations pour l'usage
en anglais, qu'on devrait reprendre tel quel.

Cela veut dire qu'à défaut de traduction française (name=fr) on devrait
chercher les noms anglais (name:en=*) avant ensuite de tenter des
romanisations automatiques du nom par défaut (name=* en cyrillique et
arabe), puis seulement afficher un nom local (name=*).
Pour l'écriture Thaïe, il me semble que la plupart des toponymes ont des
romanisations utilisée en anglais.
Pour les écritures du sud-est asiatique, peut-être le système adopté pour
le vietnamien (et devenu son écriture standard) pourrait être appliqué au
khmer ou laotien;
Il reste encore quelques écritures "spéciales": éthiopienne, maldivienne,
où les romanisations sont très peu développées (l'arabisation pourrait
servir de base pour le maldivien), mais la romanisation du syllabaire
l'éthiopien pourrait se contenter des règles utilisées pour nommer ses
caractères dans les normes Unicode/ISO 10646.
Pour les tifinagh (noms berbères traditionnels au Maroc), mieux vaut se
baser sur les toponymes officialisés aussi en arabe si on n'a pas déjà des
noms francisés (ou plus récemment anglicisés s'il n'y a pas eu de
francisation connue, cas plutôt exceptionnel quand le Maroc est encore très
francophone même si l'arabe est officiel). Cas spécial aussi des noms au
Sahara occidental remplacés par des noms "marocains" en arabe assez
différents de leur ancien nom espagnol et de leur noms berbères/peuls
traditionnels en écriture arabe. Quand le Sahara était espagnol (en théorie
il n'est toujours sur le papier...) on employait en français les noms
espagnols.

.

Le 26 mars 2017 à 04:04, Jérôme Amagat  a écrit :

> Si je passe en revu ce que je vois d'affiché on a :
> zoom 3 : mer, foret, désert, glace
> zoom 4 : même chose + frontières de pays + points pour les capitales + île
> et archipel (si il y en a plusieurs au même endroit je sais pas si c'est
> les plus grand en surface affiché ou si les archipels passe en 1er)
> les grandes îles comme la corse ne sont pas afficher vu qu'elle n'existent
> pas en tant qu’île dans osm (il n'y a pas de multipolygon place=island
> name=Corse). pour osm la Corse c'est une région mais c'est pas une ile
> (pareil pour l'irlande et bien d'autres.)
> zoom 5 : même chose + frontières de régions (admin_level=4) + nom des
> capitales à la place des points et quelques autres villes (capitale de
> régions)
> zoom 6 : même chose + frontières maritime + plein de nom de villes
> ...
> les noms des petites îles et archipels c'est pas très intéressant au zoom
> 4 surtout que c'est les seules choses écrient.
> les noms des pays pourrait être affiché au zoom 4 et 5 et même au zoom 6
> pour les plus petits.
>
> les noms de régions ne sont jamais affichés. les affichés veux dire aussi
> caché pas mal de ville il faut faire un choix. pour le rendu international
> elles sont affiché aux zooms 5 6 7.
>
> Pour améliorer le rendu FR, un truc intéressent à faire, ce serait
> d'ajouter des name:fr=* un peut partout. (surtout dans les pays n'utilisant
> pas le même alphabet que nous).
> Pour ajouter des name:x=* il y a le plugin wikipedia dans josm mais je
> sais pas si on peut tout ajouter comme noms sans vérification. les noms
> viennent de wikipedia ou wikidata? parce que les noms d'articles dans
> wikipedia il y a des fois des truc du genre "machin (ville)" et donc ce
> n'est pas que le nom de la ville par exemple. Et c'est compliqué de tout
> décocher les name:x pour ne garder que ceux dont on est sur (comme le
> 

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Jérôme Amagat]

Si je passe en revu ce que je vois d'affiché on a :
zoom 3 : mer, foret, désert, glace
zoom 4 : même chose + frontières de pays + points pour les capitales + île
et archipel (si il y en a plusieurs au même endroit je sais pas si c'est
les plus grand en surface affiché ou si les archipels passe en 1er)
les grandes îles comme la corse ne sont pas afficher vu qu'elle n'existent
pas en tant qu’île dans osm (il n'y a pas de multipolygon place=island
name=Corse). pour osm la Corse c'est une région mais c'est pas une ile
(pareil pour l'irlande et bien d'autres.)
zoom 5 : même chose + frontières de régions (admin_level=4) + nom des
capitales à la place des points et quelques autres villes (capitale de
régions)
zoom 6 : même chose + frontières maritime + plein de nom de villes
...
les noms des petites îles et archipels c'est pas très intéressant au zoom 4
surtout que c'est les seules choses écrient.
les noms des pays pourrait être affiché au zoom 4 et 5 et même au zoom 6
pour les plus petits.

les noms de régions ne sont jamais affichés. les affichés veux dire aussi
caché pas mal de ville il faut faire un choix. pour le rendu international
elles sont affiché aux zooms 5 6 7.

Pour améliorer le rendu FR, un truc intéressent à faire, ce serait
d'ajouter des name:fr=* un peut partout. (surtout dans les pays n'utilisant
pas le même alphabet que nous).
Pour ajouter des name:x=* il y a le plugin wikipedia dans josm mais je sais
pas si on peut tout ajouter comme noms sans vérification. les noms viennent
de wikipedia ou wikidata? parce que les noms d'articles dans wikipedia il y
a des fois des truc du genre "machin (ville)" et donc ce n'est pas que le
nom de la ville par exemple. Et c'est compliqué de tout décocher les name:x
pour ne garder que ceux dont on est sur (comme le francais l'anglais ...).
Et est ce que c'est utile pour osm d'ajouter tout ces tags ça en fait
quelque fois beaucoup (un pour chaque langue et des langues il y en a
beaucoup)?

pour ajouter ces noms ça pourrait être intéressant d'utiliser osmose qui
irait chercher les nom sur wikidata sur certains objets (ville, îles,
région, ...) qui ont un tag wikidata.
( le faire de facon automatique avec un bot)



Le 25 mars 2017 à 20:22, Philippe Verdy  a écrit :

> C'est vrai que ne pas afficher du tout les régions (pas plus d'ailleurs
> que les Länder en Allemagne ou les Etats aux Etats-Unis, au Mexique, au
> Brésil, en Inde, ou les sujets fédéraux de la Russie)
>
> Mais en revanche afficher les noms des petites iles (Ile de Wight en
> Angleterre, Îles Baléares en Espagne, et même Ibiza dans les Baléares, et
> le petit archipel toscan en Italie, et la Sardaigne, mais pas la Corse!,
> l'Île d'Achill en Irlande, mais pas l'Irlande!, et diverses toutes petites
> îles écossaises et norvégiennes, ou encore l'île aux Ours entre la Norvège
> et Svalbard, mais pas Svalbard, l'île du Spitzberg, ou encore de touts
> petits îlots rocheux coincés par les glaces au milieu d'un fjord glacière
> au centre d'îles plus importantes dont on n'a pas le nom le long de la côte
> arctique russe)
>
> Il peut y avoirt plusieurs explications comme l"incohérence des tags pour
> les référencer (place=* sur un noeud ou sur une frontière terrestre).
>
> Je mets au défit quelqu'un qui n'a pas de bonnes connaissance de
> géographique de parvenir à placer correctement le Svalbard ou l'île Jean
> Mayen : deux îles sur des eaux territoriales séparées par des eaux
> internationales, mais du même pays et groupées sous le même code ISO, un
> peu comme les Îles mineures des Etats-Unis ou comme nos Îles Éparses
> maintenant partie des Terres australes et antarctiques françaises, mais pas
> du tout "antarctiques" (hormis les îles côtières de Terre-Adélie, cette
> terre étant contestée dans les frontières des TAAF comme sont contestées
> aussi nos îles Éparses, Mayotte, ou encore certaines îles volcaniques
> récentes au sud-est de la Nouvelle-Calédonie) ni "australes" (moins
> australes en fait que la Réunion ou Wallis-et-Futuna)
>
> Le 25 mars 2017 à 19:06, Adrien Grellier  a écrit :
>
>> Bonjour,
>>
>> Je me permet de relancer le sujet : les noms de régions ne s'affichent
>> pas également. Par exemple juste en zoomant, il est difficile de trouver la
>> région « Unity State » du Sud Soudan, alors que sur le rendu
>> openstreetmap.org, c'est nettement plus facile.
>> Autre exemple : le contour de la région Pays de la Loire s'affiche bien,
>> mais pas le nom, ce qui peut être gênant lorsqu'on le cherche.
>>
>> Pensez-vous que le problème puisse se corriger à moyen terme ?
>> Bonne journée
>>
>
> ___
> 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 OSMFR et nom de pays

[Philippe Verdy]

C'est vrai que ne pas afficher du tout les régions (pas plus d'ailleurs que
les Länder en Allemagne ou les Etats aux Etats-Unis, au Mexique, au Brésil,
en Inde, ou les sujets fédéraux de la Russie)

Mais en revanche afficher les noms des petites iles (Ile de Wight en
Angleterre, Îles Baléares en Espagne, et même Ibiza dans les Baléares, et
le petit archipel toscan en Italie, et la Sardaigne, mais pas la Corse!,
l'Île d'Achill en Irlande, mais pas l'Irlande!, et diverses toutes petites
îles écossaises et norvégiennes, ou encore l'île aux Ours entre la Norvège
et Svalbard, mais pas Svalbard, l'île du Spitzberg, ou encore de touts
petits îlots rocheux coincés par les glaces au milieu d'un fjord glacière
au centre d'îles plus importantes dont on n'a pas le nom le long de la côte
arctique russe)

Il peut y avoirt plusieurs explications comme l"incohérence des tags pour
les référencer (place=* sur un noeud ou sur une frontière terrestre).

Je mets au défit quelqu'un qui n'a pas de bonnes connaissance de
géographique de parvenir à placer correctement le Svalbard ou l'île Jean
Mayen : deux îles sur des eaux territoriales séparées par des eaux
internationales, mais du même pays et groupées sous le même code ISO, un
peu comme les Îles mineures des Etats-Unis ou comme nos Îles Éparses
maintenant partie des Terres australes et antarctiques françaises, mais pas
du tout "antarctiques" (hormis les îles côtières de Terre-Adélie, cette
terre étant contestée dans les frontières des TAAF comme sont contestées
aussi nos îles Éparses, Mayotte, ou encore certaines îles volcaniques
récentes au sud-est de la Nouvelle-Calédonie) ni "australes" (moins
australes en fait que la Réunion ou Wallis-et-Futuna)

Le 25 mars 2017 à 19:06, Adrien Grellier  a écrit :

> Bonjour,
>
> Je me permet de relancer le sujet : les noms de régions ne s'affichent pas
> également. Par exemple juste en zoomant, il est difficile de trouver la
> région « Unity State » du Sud Soudan, alors que sur le rendu
> openstreetmap.org, c'est nettement plus facile.
> Autre exemple : le contour de la région Pays de la Loire s'affiche bien,
> mais pas le nom, ce qui peut être gênant lorsqu'on le cherche.
>
> Pensez-vous que le problème puisse se corriger à moyen terme ?
> Bonne journée
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Adrien Grellier]

Bonjour,

Je me permet de relancer le sujet : les noms de régions ne s'affichent
pas également. Par exemple juste en zoomant, il est difficile de trouver
la région « Unity State » du Sud Soudan, alors que sur le rendu
openstreetmap.org, c'est nettement plus facile.
Autre exemple : le contour de la région Pays de la Loire s'affiche bien,
mais pas le nom, ce qui peut être gênant lorsqu'on le cherche.

Pensez-vous que le problème puisse se corriger à moyen terme ?

Bonne journée

Adrien

On 13/02/2017 14:03, Philippe Verdy wrote:
> Bonne remarque.à la place des noms de pays on voit maintenant le nom
> des petites îles (pas les grandes) ou petits archipels (certains), et
> des points pour les capitales (sans le nom).
> A mon avis ces points et petites îles sont plutôt pour des niveaux
> supérieurs, les noms de pays passent en priorité.
>
> Il doit y avoir eu un bogue dans une requête de sélection des pays ou
> dans le placement de leur libellés suite à un essai d'un nouvel
> algorithme de placement ou de mise en forme des libellés (normalement
> fait dans cet ordre : 1. "glyph shaping" pour écritures complexes, 2.
> insertion des sauts de ligne et/ou césures et équilibrage des
> longueurs de lignes, 3. réordonnancement BiDi des glyphes)
>
> Le 13 février 2017 à 13:34, Adrien Grellier  > a écrit :
>
> Bonjour,
>
> Le rendu OSM-FR n'affiche plus les noms de pays, à des niveaux de zoom
> haut. Par exemple si je regarde l'Afrique, les noms de pays ne
> s'affichent pas :
> 
> http://tile.openstreetmap.fr/?zoom=4=6.43542=18.91818=B000FF
> 
> 
>
> Pourtant c'est une information qui peut être intéressante. Il me
> semble
> que sur le rendu précédent les noms de pays s'affichait bien.
>
> Si on zoome d'un cran, les capitales apparaissent, mais toujours
> pas les
> noms de pays :
> 
> http://tile.openstreetmap.fr/?zoom=5=-3.7875=26.71848=B000FF
> 
> 
>
> Pensez-vous qu'il soit possible de faire afficher les noms de pays ?
>
> Perso ça me semble plus parlant que les capitales : je peux placer
> approximativement la Tanzanie ou le Sud-Soudan sur la carte, par
> contre
> Dodoma ou Djouba me sont complètement inconnu.
>
> Bonne journée
>
> Adrien
>
>
>
> ___
> 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



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rendu OSMFR et nom de pays

[Erwan Salomon]

au passage si vous voulez comparer l’ancien et le nouveau (héo héo … humour 
très local)
le rendu bzh est toujours basé sur l’ancien rendu FR
il ne semble pas de toute fraicheur (zoom ≤ 16 date de plus de 2 mois dans mon 
coin à partir de 17 ça va mieux)

erwan [GLYO]

> Le 13 févr. 2017 à 13:34, Adrien Grellier  a écrit :
> 
> […]
> 
> Pourtant c'est une information qui peut être intéressante. Il me semble
> que sur le rendu précédent les noms de pays s'affichait bien.
> 
> […]
> 
> Bonne journée
> 
> Adrien
> 
> 
> ___
> 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 OSMFR et nom de pays

[Philippe Verdy]

Bonne remarque.à la place des noms de pays on voit maintenant le nom des
petites îles (pas les grandes) ou petits archipels (certains), et des
points pour les capitales (sans le nom).
A mon avis ces points et petites îles sont plutôt pour des niveaux
supérieurs, les noms de pays passent en priorité.

Il doit y avoir eu un bogue dans une requête de sélection des pays ou dans
le placement de leur libellés suite à un essai d'un nouvel algorithme de
placement ou de mise en forme des libellés (normalement fait dans cet ordre
: 1. "glyph shaping" pour écritures complexes, 2. insertion des sauts de
ligne et/ou césures et équilibrage des longueurs de lignes, 3.
réordonnancement BiDi des glyphes)

Le 13 février 2017 à 13:34, Adrien Grellier  a écrit :

> Bonjour,
>
> Le rendu OSM-FR n'affiche plus les noms de pays, à des niveaux de zoom
> haut. Par exemple si je regarde l'Afrique, les noms de pays ne
> s'affichent pas :
> http://tile.openstreetmap.fr/?zoom=4=6.43542=18.
> 91818=B000FF
>
> Pourtant c'est une information qui peut être intéressante. Il me semble
> que sur le rendu précédent les noms de pays s'affichait bien.
>
> Si on zoome d'un cran, les capitales apparaissent, mais toujours pas les
> noms de pays :
> http://tile.openstreetmap.fr/?zoom=5=-3.7875=26.
> 71848=B000FF
>
> Pensez-vous qu'il soit possible de faire afficher les noms de pays ?
>
> Perso ça me semble plus parlant que les capitales : je peux placer
> approximativement la Tanzanie ou le Sud-Soudan sur la carte, par contre
> Dodoma ou Djouba me sont complètement inconnu.
>
> Bonne journée
>
> Adrien
>
>
>
> ___
> 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 OSMFR et nom de pays

[Adrien Grellier]

Bonjour,

Le rendu OSM-FR n'affiche plus les noms de pays, à des niveaux de zoom
haut. Par exemple si je regarde l'Afrique, les noms de pays ne
s'affichent pas :
http://tile.openstreetmap.fr/?zoom=4=6.43542=18.91818=B000FF

Pourtant c'est une information qui peut être intéressante. Il me semble
que sur le rendu précédent les noms de pays s'affichait bien.

Si on zoome d'un cran, les capitales apparaissent, mais toujours pas les
noms de pays :
http://tile.openstreetmap.fr/?zoom=5=-3.7875=26.71848=B000FF

Pensez-vous qu'il soit possible de faire afficher les noms de pays ?

Perso ça me semble plus parlant que les capitales : je peux placer
approximativement la Tanzanie ou le Sud-Soudan sur la carte, par contre
Dodoma ou Djouba me sont complètement inconnu.

Bonne journée

Adrien




signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu OSMFR - anciens cantons

[Hamlet]

2015-07-07 11:28 GMT+02:00 Jérôme Seigneuret jseigneuret-...@yahoo.fr:
 Inutile de mettre Ancien dans le name. Celui-ci reste à une date donnée le
 Canton de Mauron. Si l'on veut exploiter les informations avec un filtre
 temporel il ne faut pas avoir des ancien dans tous les noms (ou libellé) .
 Les préfixes historic et disused servent à ça.

J'avais juste mis un nom différent pour être sûr que le label venait
bien de la relation.

Ma question était plus liée au rendu du label, je suppose au centre du
polygone...
Je ne suis pas sûr que ce soit voulu, et si c'est le cas je ne vois
pas bien à quoi ça sert !

Sinon pour les tags, JOSM râle car la relation est de type=boundary,
mais qu'il n'y a pas de boundary= correspondant, ce qui est normal vu
qu'il est passé en disused:boundary=political.

-- 
Hamlet

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

Re: [OSM-talk-fr] Rendu OSMFR - anciens cantons

[Christian Quest]

Pour le rendu, effectivement c'est un erreur et le nom ne devrait pas
s'afficher.


Le 07/07/2015 17:49, Hamlet a écrit :
 2015-07-07 11:28 GMT+02:00 Jérôme Seigneuret jseigneuret-...@yahoo.fr:
 Inutile de mettre Ancien dans le name. Celui-ci reste à une date donnée le
 Canton de Mauron. Si l'on veut exploiter les informations avec un filtre
 temporel il ne faut pas avoir des ancien dans tous les noms (ou libellé) .
 Les préfixes historic et disused servent à ça.
 J'avais juste mis un nom différent pour être sûr que le label venait
 bien de la relation.

 Ma question était plus liée au rendu du label, je suppose au centre du
 polygone...
 Je ne suis pas sûr que ce soit voulu, et si c'est le cas je ne vois
 pas bien à quoi ça sert !

 Sinon pour les tags, JOSM râle car la relation est de type=boundary,
 mais qu'il n'y a pas de boundary= correspondant, ce qui est normal vu
 qu'il est passé en disused:boundary=political.


-- 
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Rendu OSMFR - anciens cantons

[Jérôme Seigneuret]

Bonjour,
Inutile de mettre *Ancien *dans le *name*. Celui-ci reste à une date donnée
le *Canton de Mauron*. Si l'on veut exploiter les informations avec un
filtre temporel il ne faut pas avoir des ancien dans tous les noms (ou
libellé) . Les préfixes *historic *et *disused *servent à ça.

Par contre il peut être intéressant d'ajouter:
*description=Modification de la limite des cantons par le décret Décret
2014-215 du 21 février 2014, article 14, Le canton de Mauron fait désormais
partie du canton n°13 Ploërmel*
*wikipedia=Canton_de_Mauron*
*collection=disused:boundary*
*start_date=1790-02-26 *   date du décret mais je connais pas la date
d'application :-/
*end_date=2014-02-26 * date de parution du  décret au JO

le* start_date* peut être différent en fonction des remaniements d'où
l'ajout d'un start_date et d'un end_date comme sur les nouveaux découpages.
le *end_date *correspond au jour de parution du décret au journal officiel
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT28655882categorieLien=id
vu que l'entrée en vigueur du nouveau découpage et à J+1 de la parution.
A voir au niveau locale la connaissance sur cette partie car il y a eu
plusieurs remaniements 1800 et 1801.

Pour les nouveaux découpages, je ne sais pas si ça a été fait mais l'ajout
de *start_date =2014-02-27* serait bien.



Le 7 juillet 2015 02:53, Hamlet h...@mlet.me a écrit :

 Bonsoir,
 j'ai trouvé, en me promenant sur le rendu FR, un label étrangement placé.

 Grâce à la recherche d'objets sur osm.org, j'ai découvert cette
 relation englobante :
 http://www.openstreetmap.org/relation/2500366#map=14/48.0762/-2.3603

 J'en ai changé le nom pour être sûr :

 http://tile.openstreetmap.fr/?zoom=20lat=48.06845lon=-2.31354layers=B000FFF

 Il y a donc un nom d'ancien canton qui se promène dans la nature
 (jusqu'au zoom 14 inclus).

 C'est un problème de tag (JOSM n'est pas trop d'accord) ou de rendu ?

 Cordialement.

 --
 Hamlet

 ___
 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 OSMFR - anciens cantons

[Francescu GAROBY]

À noter, comme l'indique l'article 23 du décret que tu indiques, que la
date d'application de ces décrets n'est pas celle de publication + 1 jour,
mais le jour du renouvellement de la nouvelle assemblée (appelée désormais
Conseil départemental), en mars 2015.

Francescu

Le 7 juillet 2015 11:28, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :

 Bonjour,
 Inutile de mettre *Ancien *dans le *name*. Celui-ci reste à une date
 donnée le *Canton de Mauron*. Si l'on veut exploiter les informations
 avec un filtre temporel il ne faut pas avoir des ancien dans tous les
 noms (ou libellé) . Les préfixes *historic *et *disused *servent à ça.

 Par contre il peut être intéressant d'ajouter:
 *description=Modification de la limite des cantons par le décret Décret
 2014-215 du 21 février 2014, article 14, Le canton de Mauron fait désormais
 partie du canton n°13 Ploërmel*
 *wikipedia=Canton_de_Mauron*
 *collection=disused:boundary*
 *start_date=1790-02-26 *   date du décret mais je connais pas la
 date d'application :-/
 *end_date=2014-02-26 * date de parution du  décret au JO

 le* start_date* peut être différent en fonction des remaniements d'où
 l'ajout d'un start_date et d'un end_date comme sur les nouveaux découpages.
 le *end_date *correspond au jour de parution du décret au journal officiel
 http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT28655882categorieLien=id
 vu que l'entrée en vigueur du nouveau découpage et à J+1 de la parution.
 A voir au niveau locale la connaissance sur cette partie car il y a eu
 plusieurs remaniements 1800 et 1801.

 Pour les nouveaux découpages, je ne sais pas si ça a été fait mais l'ajout
 de *start_date =2014-02-27* serait bien.



 Le 7 juillet 2015 02:53, Hamlet h...@mlet.me a écrit :

 Bonsoir,
 j'ai trouvé, en me promenant sur le rendu FR, un label étrangement placé.

 Grâce à la recherche d'objets sur osm.org, j'ai découvert cette
 relation englobante :
 http://www.openstreetmap.org/relation/2500366#map=14/48.0762/-2.3603

 J'en ai changé le nom pour être sûr :

 http://tile.openstreetmap.fr/?zoom=20lat=48.06845lon=-2.31354layers=B000FFF

 Il y a donc un nom d'ancien canton qui se promène dans la nature
 (jusqu'au zoom 14 inclus).

 C'est un problème de tag (JOSM n'est pas trop d'accord) ou de rendu ?

 Cordialement.

 --
 Hamlet

 ___
 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




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

Re: [OSM-talk-fr] Rendu OSMFR - anciens cantons

[Jérôme Seigneuret]

En effet autant pour moi ;-) Je viens juste de le lire...

Ducoup
*end_date=before 2014-03*
et pour le suivant
*start_date=2014-03*

Merci Francescu
Par contre on n'a pas de jour ?


Le 7 juillet 2015 12:03, Francescu GAROBY windu...@gmail.com a écrit :

 À noter, comme l'indique l'article 23 du décret que tu indiques, que la
 date d'application de ces décrets n'est pas celle de publication + 1 jour,
 mais le jour du renouvellement de la nouvelle assemblée (appelée désormais
 Conseil départemental), en mars 2015.

 Francescu

 Le 7 juillet 2015 11:28, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
 écrit :

 Bonjour,
 Inutile de mettre *Ancien *dans le *name*. Celui-ci reste à une date
 donnée le *Canton de Mauron*. Si l'on veut exploiter les informations
 avec un filtre temporel il ne faut pas avoir des ancien dans tous les
 noms (ou libellé) . Les préfixes *historic *et *disused *servent à ça.

 Par contre il peut être intéressant d'ajouter:
 *description=Modification de la limite des cantons par le décret Décret
 2014-215 du 21 février 2014, article 14, Le canton de Mauron fait désormais
 partie du canton n°13 Ploërmel*
 *wikipedia=Canton_de_Mauron*
 *collection=disused:boundary*
 *start_date=1790-02-26 *   date du décret mais je connais pas la
 date d'application :-/
 *end_date=2014-02-26 * date de parution du  décret au JO

 le* start_date* peut être différent en fonction des remaniements d'où
 l'ajout d'un start_date et d'un end_date comme sur les nouveaux découpages.
 le *end_date *correspond au jour de parution du décret au journal
 officiel
 http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT28655882categorieLien=id
 vu que l'entrée en vigueur du nouveau découpage et à J+1 de la parution.
 A voir au niveau locale la connaissance sur cette partie car il y a eu
 plusieurs remaniements 1800 et 1801.

 Pour les nouveaux découpages, je ne sais pas si ça a été fait mais
 l'ajout de *start_date =2014-02-27* serait bien.



 Le 7 juillet 2015 02:53, Hamlet h...@mlet.me a écrit :

 Bonsoir,
 j'ai trouvé, en me promenant sur le rendu FR, un label étrangement placé.

 Grâce à la recherche d'objets sur osm.org, j'ai découvert cette
 relation englobante :
 http://www.openstreetmap.org/relation/2500366#map=14/48.0762/-2.3603

 J'en ai changé le nom pour être sûr :

 http://tile.openstreetmap.fr/?zoom=20lat=48.06845lon=-2.31354layers=B000FFF

 Il y a donc un nom d'ancien canton qui se promène dans la nature
 (jusqu'au zoom 14 inclus).

 C'est un problème de tag (JOSM n'est pas trop d'accord) ou de rendu ?

 Cordialement.

 --
 Hamlet

 ___
 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




 --
 Francescu

 ___
 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 OSMFR - anciens cantons

[Hamlet]

Bonsoir,
j'ai trouvé, en me promenant sur le rendu FR, un label étrangement placé.

Grâce à la recherche d'objets sur osm.org, j'ai découvert cette
relation englobante :
http://www.openstreetmap.org/relation/2500366#map=14/48.0762/-2.3603

J'en ai changé le nom pour être sûr :
http://tile.openstreetmap.fr/?zoom=20lat=48.06845lon=-2.31354layers=B000FFF

Il y a donc un nom d'ancien canton qui se promène dans la nature
(jusqu'au zoom 14 inclus).

C'est un problème de tag (JOSM n'est pas trop d'accord) ou de rendu ?

Cordialement.

-- 
Hamlet

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

[OSM-talk-fr] rendu osmfr à l'échelle des continents

[Adrien Grellier]

Bonjour,

Comme mentionné sur IRC hier, le rendu OSM-fr à changé : lorsqu'on zoome à 
l'échelle d'un continent, la carte est vide : plus de désert, forêts, etc.

Est-ce normal ? Si oui, quelles sont les raisons du changement ?


Autre question, annexe : j'ai mis à jour la carte de l'île d'Amsterdam, dans 
l'océan Indien :

http://tile.openstreetmap.fr/?zoom=18lat=-37.79708lon=77.5726layers=B000FFF

J'ai notamment ajouté une piste d'hélicoptère (DZ). Cette piste apparaît 
bien dans OpenStreetMap, dans le rendu « hot » ou « osmfr-lowzoom-test » sur 
tile.openstreetmap.fr, mais pas sur le rendu osmfr !

Or d'habitude les DZ apparaissent bien dans le rendu « osmfr », comme en 
témoigne la base subantarctique de Crozet (qui au passage est très bien 
cartographiée, bravo !) : 

http://tile.openstreetmap.fr/?zoom=18lat=-46.43231lon=51.85849layers=B000FFF

Sauriez-vous d'où peut venir ce comportement bizarre ?

Amicalement,

Adrien


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

Re: [OSM-talk-fr] rendu osmfr à l'échelle des continents

[Christian Quest]

Le 5 décembre 2014 17:46, Adrien Grellier pe...@adrieng.fr a écrit :

 Bonjour,

 Comme mentionné sur IRC hier, le rendu OSM-fr à changé : lorsqu'on zoome à
 l'échelle d'un continent, la carte est vide : plus de désert, forêts, etc.

 Est-ce normal ? Si oui, quelles sont les raisons du changement ?



Non, pas normal, c'est une pétouille sur le gros raster précalculé.
Je suis en train de regarder la cause...




 Autre question, annexe : j'ai mis à jour la carte de l'île d'Amsterdam,
 dans
 l'océan Indien :


 http://tile.openstreetmap.fr/?zoom=18lat=-37.79708lon=77.5726layers=B000FFF

 J'ai notamment ajouté une piste d'hélicoptère (DZ). Cette piste apparaît
 bien dans OpenStreetMap, dans le rendu « hot » ou « osmfr-lowzoom-test »
 sur
 tile.openstreetmap.fr, mais pas sur le rendu osmfr !

 Or d'habitude les DZ apparaissent bien dans le rendu « osmfr », comme en
 témoigne la base subantarctique de Crozet (qui au passage est très bien
 cartographiée, bravo !) :


 http://tile.openstreetmap.fr/?zoom=18lat=-46.43231lon=51.85849layers=B000FFF

 Sauriez-vous d'où peut venir ce comportement bizarre ?

 Amicalement,

 Adrien



Je ne l'ai pas sur le rendu OSM...
http://www.openstreetmap.org/way/315221679


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

Re: [OSM-talk-fr] rendu osmfr à l'échelle des continents

[Adrien Grellier]

Encore un soucis :

J'ai modifié il y a quelques temps la base antarctique Dumont d'Urville : 


http://tile.openstreetmap.fr/?zoom=15lat=-66.6638lon=140.0064layers=B000FFF

Le contour de l'île notamment était mauvais.

Or les modifications n'ont pas été prise en compte dans le rendu « osmfr »… 
mais osmfr-lowzoom-test est à jour ! Je n'y comprend pas grand chose…


Adrien


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

Re: [OSM-talk-fr] rendu osmfr à l'échelle des continents

[Christian Quest]

Les limites terre/mer utilisées proviennent d'un fichier séparé et pas
directement des données OSM.

Ces limites n'avaient pas été remise à jour depuis pas mal de temps je l'ai
fait la semaine dernière, mais la mise jour des tuiles sur les côtes n'est
pas systématique... un coup de /dirty peut aider à remettre çà à jour...

Le 5 décembre 2014 17:57, Adrien Grellier pe...@adrieng.fr a écrit :

 Encore un soucis :

 J'ai modifié il y a quelques temps la base antarctique Dumont d'Urville :



 http://tile.openstreetmap.fr/?zoom=15lat=-66.6638lon=140.0064layers=B000FFF

 Le contour de l'île notamment était mauvais.

 Or les modifications n'ont pas été prise en compte dans le rendu  osmfr 
 ...
 mais osmfr-lowzoom-test est à jour ! Je n'y comprend pas grand chose...


 Adrien


 ___
 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 osmfr à l'échelle des continents

[Christian Quest]

Les tuiles des zoom 1 à 7 ont été recalculées avec les bonnes limites
terre/mer et l'occupation des sols (forêts, désert, hydrographie, etc).

Il peut être nécessaire de vider de cache de son navigateur si un
rechargement ne suffit pas.

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

Re: [OSM-talk-fr] Rendu osmfr

[JB]

J'ai un peu perdu le fil… Je parlais de parking payant/gratuit, ce qui 
me semble être intéressant, l'information de base pour le premier 
utilisateur venu… On en est arrivé à parler de disque, de durée limite, 
de parcmètre (on pourrait alors ajouter de gardiennage, de parking 
relais, de moyen de paiement, d'horaires d'entrée/de sortie), mais genre 
rendu généraliste, on n'y est plus vraiment. (Bon, Christian, j'espère 
que tu es toujours partant…).

JB.

Le 21/09/2014 23:58, Jean-Baptiste Holcroft a écrit :


Je ne suis pas sur que cela couvre le besoin, là ce ne sont que des 
attributs supplémentaires aux parkings qui seraient ajoutés (type, 
coût, accès, ...).


Le 21 sept. 2014 22:52, Muselaar musel...@ouvaton.org 
mailto:musel...@ouvaton.org a écrit :



Le 21/09/2014 21:02, Jean-Baptiste Holcroft a écrit :

Pour contourner la question du positionnement, peut on faire
une jonction de différents symboles en une seule image, quitte
à générer tous les cas possibles (pour trois symboles, ça fait
maximum 9 possibilités) ?

Alors là, je suis d'accord. Les bennes de recyclage et les cabines
de téléphone sont souvent en conflit avec les icônes d'arrêt de
bus, alors je suis pressé de voir les jolies images qui joindront
tout ça…

___
Talk-fr mailing list
Talk-fr@openstreetmap.org mailto: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

[OSM-talk-fr] Rendu osmfr

[JB]

Bonjour,
Avant de rentrer dans le vif du sujet, je n'ai pas trouvé à soumettre 
cette idée sur le github du projet 
(https://github.com/cquest/osmfr-cartocss), qui renvoie la problématique 
vers trac (https://trac.openstreetmap.fr) où je n'ai pas trouvé comment 
m'identifier ou si j'avais la possibilité de créer un compte (réservé 
aux admins ?). Finalement, je poste ici.
La question vient d'une néophyte, qui suit mes pérégrinations autour 
d'OSM, et qui me pose la question :
« Dans OSM, on peut indiquer si un parking est gratuit ou payant, non ? 
Alors, on voit où, les parkings gratuits ? ». Heu, la renvoyer vers 
openparkingmap (http://parking.openstreetmap.de/), c'est un peu vachard 
(niveau mise à jour et durée d'apparition des tuiles, voire même logique 
de la légende). Aller voir les « données de la carte », c'est pas 
vraiment mieux. Au fait, pourquoi on n'enrichit pas l'icone d'un parking 
pour indiquer s'il est payant ou gratuit, quand on a l'information 
(genre un euro barré ou non) ? L'étape suivante, c'est évidemment les 
toilettes publiques…

Voilà voilà,
JB.

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

Re: [OSM-talk-fr] Rendu osmfr

[Philippe Verdy]

La plupart des parkings sont gratuits sauf dans les hypercentres urbains où
les payants sont majoritaires (les périphéries ont des parkings gratuits y
co,pris résidentiels ou d'hypermarchés ou stations d'autoroutes).
Il semble donc que 'icône de parking gratuit soit celle du carré bleu avec
le blanc.

Le parking payant pourrait en revanche avoir le symbole du paiement: des
pièces plutôt qu'un symbole euro?

Aussi il y a des parkings gratuits mais limités dans le temps (zones
bleues; disque de stationnement obligatoire) : ajouter le symbole du
disque (comme sur les panneaux)?

L'ennui c'est que l'icône est petite et qu'il est difficile de la
surcharger pour que ce soit lisible. A oins de changer de couleur : rouge
pour les parkings payants (pas conforme aux panneaux bleus) ?

Autre choses :

- Parking non permanent, alterné à droite ou gauche selon les jours
(souvent par quinzaine dans le mois). Concerne en fait moins les parkings
que les files de stationnement le long des rues. Pas forcement besoin de
symbole (sinon il faudrait taguer tous les emplacements le long des rues;
ce ne sont pas à proprement parler des parkings.

- Parkings régulièrement fermés certains jours (jours de marché par
exemple); faut-il un symbole? le plus souvent ce sont des parkings gratuits
quand ils sont ouverts.

- Emplacements réservés aux handicapés ; le symbole fauteuil au lieu du P
sur le carré bleu (comme pour le marquage au sol) ? Taguer spécifiquement
les emplacements car ils sont inclus dans les parkings accessibles à tous;
les réserves étant limitées à 1 ou 2 places


Le 21 septembre 2014 15:51, JB jb...@mailoo.org a écrit :

 Bonjour,
 Avant de rentrer dans le vif du sujet, je n'ai pas trouvé à soumettre
 cette idée sur le github du projet (https://github.com/cquest/
 osmfr-cartocss), qui renvoie la problématique vers trac (
 https://trac.openstreetmap.fr) où je n'ai pas trouvé comment m'identifier
 ou si j'avais la possibilité de créer un compte (réservé aux admins ?).
 Finalement, je poste ici.
 La question vient d'une néophyte, qui suit mes pérégrinations autour
 d'OSM, et qui me pose la question :
 « Dans OSM, on peut indiquer si un parking est gratuit ou payant, non ?
 Alors, on voit où, les parkings gratuits ? ». Heu, la renvoyer vers
 openparkingmap (http://parking.openstreetmap.de/), c'est un peu vachard
 (niveau mise à jour et durée d'apparition des tuiles, voire même logique de
 la légende). Aller voir les « données de la carte », c'est pas vraiment
 mieux. Au fait, pourquoi on n'enrichit pas l'icone d'un parking pour
 indiquer s'il est payant ou gratuit, quand on a l'information (genre un
 euro barré ou non) ? L'étape suivante, c'est évidemment les toilettes
 publiques…
 Voilà voilà,
 JB.

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

[Christian Quest]

Bonne idée, surtout que le P bleu est relativement gros et que ça doit
pouvoir se caser. Il reste à voir si le petit EURO barré ou non sera assez
visible ce qui n'est pas évident.

Le 21 septembre 2014 15:51, JB jb...@mailoo.org a écrit :

 Bonjour,
 Avant de rentrer dans le vif du sujet, je n'ai pas trouvé à soumettre
 cette idée sur le github du projet (https://github.com/cquest/
 osmfr-cartocss), qui renvoie la problématique vers trac (
 https://trac.openstreetmap.fr) où je n'ai pas trouvé comment m'identifier
 ou si j'avais la possibilité de créer un compte (réservé aux admins ?).
 Finalement, je poste ici.
 La question vient d'une néophyte, qui suit mes pérégrinations autour
 d'OSM, et qui me pose la question :
  Dans OSM, on peut indiquer si un parking est gratuit ou payant, non ?
 Alors, on voit où, les parkings gratuits ? . Heu, la renvoyer vers
 openparkingmap (http://parking.openstreetmap.de/), c'est un peu vachard
 (niveau mise à jour et durée d'apparition des tuiles, voire même logique de
 la légende). Aller voir les  données de la carte , c'est pas vraiment
 mieux. Au fait, pourquoi on n'enrichit pas l'icone d'un parking pour
 indiquer s'il est payant ou gratuit, quand on a l'information (genre un
 euro barré ou non) ? L'étape suivante, c'est évidemment les toilettes
 publiques...
 Voilà voilà,
 JB.

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

[Greg]

Pourquoi ne pas prendre les symboles officiels de parking libre, avec
parcmètre, au disque… ?

2014-09-21 17:43 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:

 Bonne idée, surtout que le P bleu est relativement gros et que ça doit
 pouvoir se caser. Il reste à voir si le petit € barré ou non sera assez
 visible ce qui n'est pas évident.

 Le 21 septembre 2014 15:51, JB jb...@mailoo.org a écrit :

 Bonjour,
 Avant de rentrer dans le vif du sujet, je n'ai pas trouvé à soumettre
 cette idée sur le github du projet (https://github.com/cquest/
 osmfr-cartocss), qui renvoie la problématique vers trac (
 https://trac.openstreetmap.fr) où je n'ai pas trouvé comment
 m'identifier ou si j'avais la possibilité de créer un compte (réservé aux
 admins ?). Finalement, je poste ici.
 La question vient d'une néophyte, qui suit mes pérégrinations autour
 d'OSM, et qui me pose la question :
 « Dans OSM, on peut indiquer si un parking est gratuit ou payant, non ?
 Alors, on voit où, les parkings gratuits ? ». Heu, la renvoyer vers
 openparkingmap (http://parking.openstreetmap.de/), c'est un peu vachard
 (niveau mise à jour et durée d'apparition des tuiles, voire même logique de
 la légende). Aller voir les « données de la carte », c'est pas vraiment
 mieux. Au fait, pourquoi on n'enrichit pas l'icone d'un parking pour
 indiquer s'il est payant ou gratuit, quand on a l'information (genre un
 euro barré ou non) ? L'étape suivante, c'est évidemment les toilettes
 publiques…
 Voilà voilà,
 JB.

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

[Christian Quest]

En tout petit, ça risque d'être illisible...

Le 21 septembre 2014 18:52, Greg ewala...@gmail.com a écrit :

 Pourquoi ne pas prendre les symboles officiels de parking libre, avec
 parcmètre, au disque... ?

 2014-09-21 17:43 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:

 Bonne idée, surtout que le P bleu est relativement gros et que ça doit
 pouvoir se caser. Il reste à voir si le petit EURO barré ou non sera assez
 visible ce qui n'est pas évident.

 Le 21 septembre 2014 15:51, JB jb...@mailoo.org a écrit :

 Bonjour,
 Avant de rentrer dans le vif du sujet, je n'ai pas trouvé à soumettre
 cette idée sur le github du projet (https://github.com/cquest/
 osmfr-cartocss), qui renvoie la problématique vers trac (
 https://trac.openstreetmap.fr) où je n'ai pas trouvé comment
 m'identifier ou si j'avais la possibilité de créer un compte (réservé aux
 admins ?). Finalement, je poste ici.
 La question vient d'une néophyte, qui suit mes pérégrinations autour
 d'OSM, et qui me pose la question :
  Dans OSM, on peut indiquer si un parking est gratuit ou payant, non ?
 Alors, on voit où, les parkings gratuits ? . Heu, la renvoyer vers
 openparkingmap (http://parking.openstreetmap.de/), c'est un peu vachard
 (niveau mise à jour et durée d'apparition des tuiles, voire même logique de
 la légende). Aller voir les  données de la carte , c'est pas vraiment
 mieux. Au fait, pourquoi on n'enrichit pas l'icone d'un parking pour
 indiquer s'il est payant ou gratuit, quand on a l'information (genre un
 euro barré ou non) ? L'étape suivante, c'est évidemment les toilettes
 publiques...
 Voilà voilà,
 JB.

 ___
 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




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

Re: [OSM-talk-fr] Rendu osmfr

[Jean-Baptiste Holcroft]

Le fait de ne faire qu'enrichir le fond osm restreint un peu et complexifie
à mon sens, ne peut on pas envisager un calque qui affiche aux mêmes
endroits que sur le calque officiel quelques symboles accolés qui
donneraient plus d'informations ?
Ça répond à cet utilisateur et permettrait de faire une démonstration
d'autres types de données présentes, voir d'inspirer d'autres
réutilisations.
Pour contourner la question du positionnement, peut on faire une jonction
de différents symboles en une seule image, quitte à générer tous les cas
possibles (pour trois symboles, ça fait maximum 9 possibilités) ?
Le 21 sept. 2014 20:40, Christian Quest cqu...@openstreetmap.fr a écrit
:

 En tout petit, ça risque d'être illisible...

 Le 21 septembre 2014 18:52, Greg ewala...@gmail.com a écrit :

 Pourquoi ne pas prendre les symboles officiels de parking libre, avec
 parcmètre, au disque… ?

 2014-09-21 17:43 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:

 Bonne idée, surtout que le P bleu est relativement gros et que ça doit
 pouvoir se caser. Il reste à voir si le petit € barré ou non sera assez
 visible ce qui n'est pas évident.

 Le 21 septembre 2014 15:51, JB jb...@mailoo.org a écrit :

 Bonjour,
 Avant de rentrer dans le vif du sujet, je n'ai pas trouvé à soumettre
 cette idée sur le github du projet (https://github.com/cquest/
 osmfr-cartocss), qui renvoie la problématique vers trac (
 https://trac.openstreetmap.fr) où je n'ai pas trouvé comment
 m'identifier ou si j'avais la possibilité de créer un compte (réservé aux
 admins ?). Finalement, je poste ici.
 La question vient d'une néophyte, qui suit mes pérégrinations autour
 d'OSM, et qui me pose la question :
 « Dans OSM, on peut indiquer si un parking est gratuit ou payant, non ?
 Alors, on voit où, les parkings gratuits ? ». Heu, la renvoyer vers
 openparkingmap (http://parking.openstreetmap.de/), c'est un peu
 vachard (niveau mise à jour et durée d'apparition des tuiles, voire même
 logique de la légende). Aller voir les « données de la carte », c'est pas
 vraiment mieux. Au fait, pourquoi on n'enrichit pas l'icone d'un parking
 pour indiquer s'il est payant ou gratuit, quand on a l'information (genre
 un euro barré ou non) ? L'étape suivante, c'est évidemment les toilettes
 publiques…
 Voilà voilà,
 JB.

 ___
 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




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

[Muselaar]

Le 21/09/2014 21:02, Jean-Baptiste Holcroft a écrit :
Pour contourner la question du positionnement, peut on faire une 
jonction de différents symboles en une seule image, quitte à générer 
tous les cas possibles (pour trois symboles, ça fait maximum 9 
possibilités) ?
Alors là, je suis d'accord. Les bennes de recyclage et les cabines de 
téléphone sont souvent en conflit avec les icônes d'arrêt de bus, alors 
je suis pressé de voir les jolies images qui joindront tout ça…


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

Re: [OSM-talk-fr] Rendu osmfr

[Philippe Verdy]

Les cabines de téléphone n'existent presque plus depuis l'arrivée des
portables. Trop de vandalisme, coût d'entretien très supérieur à ce qu'ils
rapportent à l'utilisation. France Telecom les a démonté presque partout,
sauf une par commune quand la commune l'a demandé (et c'est elle qui gère
son entretien; ais le plus souvent i ne reste qu'un point-phone dans un
commerce ou un service public), ou dans les grandes gares ou dans les
aéroports (maintenance par la gare elle-même) mais je n'en vois plus jamais
nulle part aux arrêts de bus.

Les bennes de recyclage sont aussi mal placées à un arrêt de bus : on doit
pouvoir y stationner pour faire un dépot ou collecter la benne sans gêner
l'arrêt de bus. Mais il n'est pas permis de stationner sur les emplacements
des arrêts de bus. Ces bennes sont plutôt placées dans l'angle d'un
carrefour et ce n'est pas le bon emplacement pour un arrêt de bus (question
sécurité pour les piétons; et un bus n'a pas non plus à monter sur un
trottoir d'angle de carrefour...

Je vois donc mal combiner ces icônes: les arrêts de bus apparaissent à des
niveaux de zoom faibles (zoom 13 ou plus), les bennes et téléphones seront
pour la vue rapprochée (zoom 17 ou plus) où on les distingue clairement.


Le 21 septembre 2014 21:51, Muselaar musel...@ouvaton.org a écrit :


 Le 21/09/2014 21:02, Jean-Baptiste Holcroft a écrit :

 Pour contourner la question du positionnement, peut on faire une jonction
 de différents symboles en une seule image, quitte à générer tous les cas
 possibles (pour trois symboles, ça fait maximum 9 possibilités) ?

 Alors là, je suis d'accord. Les bennes de recyclage et les cabines de
 téléphone sont souvent en conflit avec les icônes d'arrêt de bus, alors je
 suis pressé de voir les jolies images qui joindront tout ça…


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

[Jean-Baptiste Holcroft]

Je ne suis pas sur que cela couvre le besoin, là ce ne sont que des
attributs supplémentaires aux parkings qui seraient ajoutés (type, coût,
accès, ...).
Le 21 sept. 2014 22:52, Muselaar musel...@ouvaton.org a écrit :


 Le 21/09/2014 21:02, Jean-Baptiste Holcroft a écrit :

 Pour contourner la question du positionnement, peut on faire une jonction
 de différents symboles en une seule image, quitte à générer tous les cas
 possibles (pour trois symboles, ça fait maximum 9 possibilités) ?

 Alors là, je suis d'accord. Les bennes de recyclage et les cabines de
 téléphone sont souvent en conflit avec les icônes d'arrêt de bus, alors je
 suis pressé de voir les jolies images qui joindront tout ça…

 ___
 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 osmfr et zoom level 7

[Emmanuel Lesouef]

Bonjour,

J'étais en train de regarder le rendu osmfr pour la Basse-Normandie et
je me rends compte que sont affichés des noms de villes qui, à priori,
ne devrait pas être pertinents à ce niveau d'échelle :

http://tile.openstreetmap.fr/?zoom=7lat=48.98197lon=0.34279layers=B00

On y voit en particulier Tourlaville alors que Cherbourg-Octeville
devrait être affichée, et Picauville (charmante bourgade du Cotentin
soit dit en passant).

N'y aurait-il pas un petit bug ?

-- 
Emmanuel Lesouef
gpg fingerprint : A9CA4A80409F0151695E4B42FDE295B76613EB6C
gpg keyid : 6613EB6C


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

Re: [OSM-talk-fr] Rendu osmfr et zoom level 7

[Christian Quest]

Toutes les difficultés du placement de texte...

Est-ce que population=* est correctement renseigné sur ces nœuds place=* ?

Les noms sont placés par population décroissante.


Le 7 octobre 2013 13:17, Emmanuel Lesouef eleso...@lorinand.org a écrit :

 Bonjour,

 J'étais en train de regarder le rendu osmfr pour la Basse-Normandie et
 je me rends compte que sont affichés des noms de villes qui, à priori,
 ne devrait pas être pertinents à ce niveau d'échelle :


 http://tile.openstreetmap.fr/?zoom=7lat=48.98197lon=0.34279layers=B00

 On y voit en particulier Tourlaville alors que Cherbourg-Octeville
 devrait être affichée, et Picauville (charmante bourgade du Cotentin
 soit dit en passant).

 N'y aurait-il pas un petit bug ?

 --
 Emmanuel Lesouef
 gpg fingerprint : A9CA4A80409F0151695E4B42FDE295B76613EB6C
 gpg keyid : 6613EB6C

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




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

Re: [OSM-talk-fr] Rendu osmfr et zoom level 7

[Emmanuel Lesouef]

Le Mon, 7 Oct 2013 14:15:58 +0200,
Christian Quest cqu...@openstreetmap.fr a écrit :

 Toutes les difficultés du placement de texte...
 
 Est-ce que population=* est correctement renseigné sur ces nœuds
 place=* ?
 
 Les noms sont placés par population décroissante.
 

Alors oui :

Picauville : place=village et population=1934
Tourlaville : place=town et population=15910

Curieux quand même que ces villes apparaissent.

-- 
Emmanuel Lesouef
gpg fingerprint : A9CA4A80409F0151695E4B42FDE295B76613EB6C
gpg keyid : 6613EB6C


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

Re: [OSM-talk-fr] Rendu osmfr et zoom level 7

[V de Chateau-Thierry]

Bonjour,

 De : Emmanuel Lesouef

Le placement de Cherbourg-Octeville est sûrement testé avant Tourlaville, 
mais vue la
latitude, il doit entrer en conflit avec Alderney, placé encore avant. Du coup 
il est
retoqué et laisse le champ libre à des noms de villes de moindre importance.

Plusieurs possibilités :
- déménager l'Île d'Alderney
- renommer Cherbourg-Octeville
- zoomer
:-)

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

Re: [OSM-talk-fr] Rendu osmfr et zoom level 7

[Francescu GAROBY]

Je complète la réponse d'Emmanuel :
* Cherbourg : place=suburb et population=38433 (donc bien supérieure à
Tourlaville)
Est-ce ce place='suburb' qui pose problème ?

Il est amusant de constater cependant qu'au niveau de zoom 8, c'est bien
Cherbourg-Octeville qui apparait, et plus Tourlaville.

Francescu


Le 7 octobre 2013 14:22, Emmanuel Lesouef eleso...@lorinand.org a écrit :

 Le Mon, 7 Oct 2013 14:15:58 +0200,
 Christian Quest cqu...@openstreetmap.fr a écrit :

  Toutes les difficultés du placement de texte...
 
  Est-ce que population=* est correctement renseigné sur ces nœuds
  place=* ?
 
  Les noms sont placés par population décroissante.
 

 Alors oui :

 Picauville : place=village et population=1934
 Tourlaville : place=town et population=15910

 Curieux quand même que ces villes apparaissent.

 --
 Emmanuel Lesouef
 gpg fingerprint : A9CA4A80409F0151695E4B42FDE295B76613EB6C
 gpg keyid : 6613EB6C

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




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

Re: [OSM-talk-fr] Rendu osmfr et zoom level 7

[Nolwenn]

Le lundi 7 octobre 2013 14:30:15 V de Chateau-Thierry a écrit :
 Bonjour,
 
  De : Emmanuel Lesouef
 
 Le placement de Cherbourg-Octeville est sûrement testé avant Tourlaville,
 mais vue la latitude, il doit entrer en conflit avec Alderney, placé encore
 avant. Du coup il est retoqué et laisse le champ libre à des noms de villes
 de moindre importance.
 
 Plusieurs possibilités :
 - déménager l'Île d'Alderney
 - renommer Cherbourg-Octeville
 - zoomer

Il y a un problème similaire pour Montevideo, la capitale de l'Uruguay, qui se 
fait éjecter par Buenos Aires, la capitale de l'Argentine, selon les niveaux 
de zoom 5 ou 6. D'ailleurs dans ce coin, la frontière entre le Chili et 
l'Argentine est bizarre, tout comme la frontière maritime du Chili en Terre de 
Feu.
http://tile.openstreetmap.fr/?zoom=6lat=-52.4493lon=-70.70828layers=B00

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

Re: [OSM-talk-fr] Rendu osmfr et zoom level 7

[Jérôme Amagat]

Cherbourg-Octeville c'est le nom de la commune. Est ce que c'est aussi une
town comme indiqué? Les town serai plutot Cherbourg et Octeville (plutot
que des quartiers) par contre pour la population de ces 2 villes il n'y a
que celle avant la fusion donc en 1999
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu osmfr et zoom level 7

[Christian Quest]

place=suburb n'aide sûrement pas...

En fait, les noms sont placé en fonction de place=* puis de population=* et
comme suburb est en principe une sous-partie d'un autre place=* plus grand,
il n'est rendu que très tardivement dans des zooms plus élevés.

Un nom long (Cherbourg-Octeville) est plus difficile à placer. La place est
déjà prise par Alderney qui bien qu'ayant une population moindre est une
découpage administratif plus important qu'une ville... pas simple, pas
simple !


Le 7 octobre 2013 14:35, Francescu GAROBY windu...@gmail.com a écrit :

 Je complète la réponse d'Emmanuel :
 * Cherbourg : place=suburb et population=38433 (donc bien supérieure à
 Tourlaville)
 Est-ce ce place='suburb' qui pose problème ?

 Il est amusant de constater cependant qu'au niveau de zoom 8, c'est bien
 Cherbourg-Octeville qui apparait, et plus Tourlaville.

 Francescu


 Le 7 octobre 2013 14:22, Emmanuel Lesouef eleso...@lorinand.org a écrit
 :

  Le Mon, 7 Oct 2013 14:15:58 +0200,
 Christian Quest cqu...@openstreetmap.fr a écrit :

  Toutes les difficultés du placement de texte...
 
  Est-ce que population=* est correctement renseigné sur ces nœuds
  place=* ?
 
  Les noms sont placés par population décroissante.
 

 Alors oui :

 Picauville : place=village et population=1934
 Tourlaville : place=town et population=15910

 Curieux quand même que ces villes apparaissent.

 --
 Emmanuel Lesouef
 gpg fingerprint : A9CA4A80409F0151695E4B42FDE295B76613EB6C
 gpg keyid : 6613EB6C

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




 --
 Cordialement,
 Francescu GAROBY

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




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

Re: [OSM-talk-fr] Rendu osmfr et zoom level 7

[Emmanuel Lesouef]

Le Mon, 7 Oct 2013 15:00:30 +0200,
Christian Quest cqu...@openstreetmap.fr a écrit :

 place=suburb n'aide sûrement pas...
 
 En fait, les noms sont placé en fonction de place=* puis de
 population=* et comme suburb est en principe une sous-partie d'un
 autre place=* plus grand, il n'est rendu que très tardivement dans
 des zooms plus élevés.
 
 Un nom long (Cherbourg-Octeville) est plus difficile à placer. La
 place est déjà prise par Alderney qui bien qu'ayant une population
 moindre est une découpage administratif plus important qu'une
 ville... pas simple, pas simple !

Le cas de Cherbourg-Octeville n'est pas simple en effet, sûrement à
cause de son placement.

Par contre, Picauville ? Carentan ou Valognes seraient plus
appropriées, non ?

Carentan : place=village  population=6063
Valognes : place=village  population=7190

-- 
Emmanuel Lesouef
gpg fingerprint : A9CA4A80409F0151695E4B42FDE295B76613EB6C
gpg keyid : 6613EB6C


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

Re: [OSM-talk-fr] Rendu osmfr et zoom level 7

[Francescu GAROBY]

Au passage, je remarque qu'aux niveau 8 et 9, Montebourg (commune de 2100
habitants, si j'en crois son node 'place') apparait, au détriment de
Carentan, puis disparait au niveau 10, alors que bien d'autres communes
apparaissent (dont Carentan), puis revient au niveau 11.

Francescu




Le 7 octobre 2013 15:12, Emmanuel Lesouef eleso...@lorinand.org a écrit :

 Le Mon, 7 Oct 2013 15:00:30 +0200,
 Christian Quest cqu...@openstreetmap.fr a écrit :

  place=suburb n'aide sûrement pas...
 
  En fait, les noms sont placé en fonction de place=* puis de
  population=* et comme suburb est en principe une sous-partie d'un
  autre place=* plus grand, il n'est rendu que très tardivement dans
  des zooms plus élevés.
 
  Un nom long (Cherbourg-Octeville) est plus difficile à placer. La
  place est déjà prise par Alderney qui bien qu'ayant une population
  moindre est une découpage administratif plus important qu'une
  ville... pas simple, pas simple !

 Le cas de Cherbourg-Octeville n'est pas simple en effet, sûrement à
 cause de son placement.

 Par contre, Picauville ? Carentan ou Valognes seraient plus
 appropriées, non ?

 Carentan : place=village  population=6063
 Valognes : place=village  population=7190

 --
 Emmanuel Lesouef
 gpg fingerprint : A9CA4A80409F0151695E4B42FDE295B76613EB6C
 gpg keyid : 6613EB6C

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




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

Re: [OSM-talk-fr] Rendu osmfr et zoom level 7

[Christian Quest]

Y'a peut être une mise à jour à faire sur ces zooms... ils ne sont pas
recalculés en live.


Le 7 octobre 2013 15:18, Francescu GAROBY windu...@gmail.com a écrit :

 Au passage, je remarque qu'aux niveau 8 et 9, Montebourg (commune de 2100
 habitants, si j'en crois son node 'place') apparait, au détriment de
 Carentan, puis disparait au niveau 10, alors que bien d'autres communes
 apparaissent (dont Carentan), puis revient au niveau 11.

 Francescu




 Le 7 octobre 2013 15:12, Emmanuel Lesouef eleso...@lorinand.org a écrit
 :

 Le Mon, 7 Oct 2013 15:00:30 +0200,
 Christian Quest cqu...@openstreetmap.fr a écrit :

  place=suburb n'aide sûrement pas...
 
  En fait, les noms sont placé en fonction de place=* puis de
  population=* et comme suburb est en principe une sous-partie d'un
  autre place=* plus grand, il n'est rendu que très tardivement dans
  des zooms plus élevés.
 
  Un nom long (Cherbourg-Octeville) est plus difficile à placer. La
  place est déjà prise par Alderney qui bien qu'ayant une population
  moindre est une découpage administratif plus important qu'une
  ville... pas simple, pas simple !

 Le cas de Cherbourg-Octeville n'est pas simple en effet, sûrement à
 cause de son placement.

 Par contre, Picauville ? Carentan ou Valognes seraient plus
 appropriées, non ?

 Carentan : place=village  population=6063
 Valognes : place=village  population=7190

 --
 Emmanuel Lesouef
 gpg fingerprint : A9CA4A80409F0151695E4B42FDE295B76613EB6C
 gpg keyid : 6613EB6C

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




 --
 Cordialement,
 Francescu GAROBY

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




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

Re: [OSM-talk-fr] Rendu osmfr et zoom level 7

[Philippe Verdy]

Même chose à la Rochelle au niveau 8 : on voit seulement Les Touches (en
fait c'est l'île de Ré visible qui est trop proche).

Ici il semble que l'affichage trop proche d'Alderney (prioritaire) bloque
celui de Cherbourg-Octeville, ensuite il reste de la place plus à l'est
pour Tourlaville.

Cela ne me semble pas une anomalie : les noms d'îles sont prioritaires sur
les villes, et il n'est pas facile de classer par population car les îles
n'ont pas de population définie.

Le choix est cornélien si on veut voir ces îles : à partir d'un niveau de
zoom donné, les îles de taille suffisante pour ce niveau apparaissent avant
les villes.


Le 7 octobre 2013 13:17, Emmanuel Lesouef eleso...@lorinand.org a écrit :

 Bonjour,

 J'étais en train de regarder le rendu osmfr pour la Basse-Normandie et
 je me rends compte que sont affichés des noms de villes qui, à priori,
 ne devrait pas être pertinents à ce niveau d'échelle :


 http://tile.openstreetmap.fr/?zoom=7lat=48.98197lon=0.34279layers=B00

 On y voit en particulier Tourlaville alors que Cherbourg-Octeville
 devrait être affichée, et Picauville (charmante bourgade du Cotentin
 soit dit en passant).

 N'y aurait-il pas un petit bug ?

 --
 Emmanuel Lesouef
 gpg fingerprint : A9CA4A80409F0151695E4B42FDE295B76613EB6C
 gpg keyid : 6613EB6C

 ___
 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 osmfr et zoom level 7

[Eric Marsden]

 fg == Francescu GAROBY windu...@gmail.com writes:

  fg Au passage, je remarque qu'aux niveau 8 et 9, Montebourg (commune de 2100
  fg habitants, si j'en crois son node 'place') apparait, au détriment de
  fg Carentan, puis disparait au niveau 10, alors que bien d'autres communes
  fg apparaissent (dont Carentan), puis revient au niveau 11.

  Faut-il faire un rapprochement avec les prouesses médiatiques du
  ministre de même nom?
  
-- 
Eric Marsden


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

Re: [OSM-talk-fr] rendu osmFr : forest

[Bruno Besson]

En fait, on a un peu les 2 situations : la limite d'un forêt peu être floue
quand elle se clairsème. Sur l'IGN par exemple, la bordure de la forêt peut
être rendue avec un trait fin, ou sans ce trait (
http://www.camptocamp.org/map?map_x=623175.37262275map_y=5635529.6058801map_zoom=16baselayer_ref=ign_mapspar
exemple).
Mais du coup, il faudrait déjà un tag pour spécifier ça. Et j'en vois
certains râler parce que tracer de la forêt avec des multipolygones
construits avec des segments, c'est pas forcément donné à tout le monde :o)


2013/9/2 Philippe Verdy verd...@wanadoo.fr

 Idem. En plus il y a souvent aussi des clôtures, ou un fossé, la
 séparation est nette et suit pratiquement toujours une limite de parcelle
 tirée au cordeau et matérialisée au minimum par un bornage cadastral.

 Certes au gré des coupes ou des chutes d'arbres ou des ratés de certaines
 plantation il peut manquer des arbres en bordure, mais à terme ils seront
 remplacés et la parcelle reste gérée comme une plantation forestière, c'est
 sa vocation, même si certaines coupes ou aménagements laissent apparaître
 un nouvel usage: s'il est permanent, ou cela fait l'objet d'un bail (pour
 installer un captage, ou faire passer une route ou un chemin d'accès, ou
 des pylones électriques, ou une tranchée pour un réseau enterré, il y a
 aura nouvelle délimitation de parcelle afin qu'on ne replante pas par
 dessus.

 Ce qui est flou c'est la couverture végétale saisonnière (selon le
 feuillage ou les émondages) mais cela ne rentre pas sur la carte, la
 vocation du terrain est inchangée.

 Ce qui est réellement plus flou, horizontalement, ce sont les limites de
 lits de rivières (sauf si elles sont canalisées avec des bordures
 surélevées clairement délimitées et stabilisées., particulièrement pour les
 ruisseaux de montagne qui serpentent sur un lit de roches plus ou moins
 instables. Au mieux on n'a qu'une zone moyenne ignorant les variations
 chaque année voir plusieurs fois par an (au gré des orages) selon les
 variations de débit. De même les limites côtières sur les plages selon les
 marées (et soit l'érosion des côtes, qui s'accélère malgré les
 réensablements artificiels ou travaux d'endiguement ou destinés à retenir
 le sable ou modifier le flux des marées).

 Ou même verticalement les limites de flancs de collines abruptes et même
 de falaises (parce qu'elles sont instables ou bien étagées de façon
 irrégulières, on ne sait pas définir la limite de pente à partir de
 laquelle on marque la frontière).



 Le 1 septembre 2013 21:31, Francescu GAROBY windu...@gmail.com a écrit :

 Bonsoir,
 Je ne suis pas d'accord sur le fait que la bordure d'une forêt est
 toujours floue : il n'est pas rare, au contraire, de voir des bordures bien
 nettes, tracées au cordeau, parce que les arbres de la parcelle d'à côté
 ont entièrement été coupés.

 Francescu
 Le 1 sept. 2013 20:54, Lord Awikatchikaen lord.awikatchik...@gmail.com
 a écrit :

  Bonjour,

 Petite réflexion : les abords des forêts ne sont jamais vraiment nets en
 réalité, est ce qu'il ne serait pas possible de dessiner les contours de
 ces landuses avec un flou ou un dégradé sur le rendu FR ?

 Awikatchikaen.

 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr


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



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


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

Re: [OSM-talk-fr] rendu osmFr : forest

[Marc SIBERT]

Non, juste raler parce que si ça c' est pas tagger pour le rendu...

--
Marc Sibert
m...@sibert.fr
Le 2 sept. 2013 09:41, Bruno Besson bruno.bes...@gmail.com a écrit :

 En fait, on a un peu les 2 situations : la limite d'un forêt peu être
 floue quand elle se clairsème. Sur l'IGN par exemple, la bordure de la
 forêt peut être rendue avec un trait fin, ou sans ce trait (
 http://www.camptocamp.org/map?map_x=623175.37262275map_y=5635529.6058801map_zoom=16baselayer_ref=ign_mapspar
  exemple).
 Mais du coup, il faudrait déjà un tag pour spécifier ça. Et j'en vois
 certains râler parce que tracer de la forêt avec des multipolygones
 construits avec des segments, c'est pas forcément donné à tout le monde :o)


 2013/9/2 Philippe Verdy verd...@wanadoo.fr

 Idem. En plus il y a souvent aussi des clôtures, ou un fossé, la
 séparation est nette et suit pratiquement toujours une limite de parcelle
 tirée au cordeau et matérialisée au minimum par un bornage cadastral.

 Certes au gré des coupes ou des chutes d'arbres ou des ratés de certaines
 plantation il peut manquer des arbres en bordure, mais à terme ils seront
 remplacés et la parcelle reste gérée comme une plantation forestière, c'est
 sa vocation, même si certaines coupes ou aménagements laissent apparaître
 un nouvel usage: s'il est permanent, ou cela fait l'objet d'un bail (pour
 installer un captage, ou faire passer une route ou un chemin d'accès, ou
 des pylones électriques, ou une tranchée pour un réseau enterré, il y a
 aura nouvelle délimitation de parcelle afin qu'on ne replante pas par
 dessus.

 Ce qui est flou c'est la couverture végétale saisonnière (selon le
 feuillage ou les émondages) mais cela ne rentre pas sur la carte, la
 vocation du terrain est inchangée.

 Ce qui est réellement plus flou, horizontalement, ce sont les limites de
 lits de rivières (sauf si elles sont canalisées avec des bordures
 surélevées clairement délimitées et stabilisées., particulièrement pour les
 ruisseaux de montagne qui serpentent sur un lit de roches plus ou moins
 instables. Au mieux on n'a qu'une zone moyenne ignorant les variations
 chaque année voir plusieurs fois par an (au gré des orages) selon les
 variations de débit. De même les limites côtières sur les plages selon les
 marées (et soit l'érosion des côtes, qui s'accélère malgré les
 réensablements artificiels ou travaux d'endiguement ou destinés à retenir
 le sable ou modifier le flux des marées).

 Ou même verticalement les limites de flancs de collines abruptes et même
 de falaises (parce qu'elles sont instables ou bien étagées de façon
 irrégulières, on ne sait pas définir la limite de pente à partir de
 laquelle on marque la frontière).



 Le 1 septembre 2013 21:31, Francescu GAROBY windu...@gmail.com a écrit
 :

 Bonsoir,
 Je ne suis pas d'accord sur le fait que la bordure d'une forêt est
 toujours floue : il n'est pas rare, au contraire, de voir des bordures bien
 nettes, tracées au cordeau, parce que les arbres de la parcelle d'à côté
 ont entièrement été coupés.

 Francescu
 Le 1 sept. 2013 20:54, Lord Awikatchikaen 
 lord.awikatchik...@gmail.com a écrit :

  Bonjour,

 Petite réflexion : les abords des forêts ne sont jamais vraiment nets
 en réalité, est ce qu'il ne serait pas possible de dessiner les contours de
 ces landuses avec un flou ou un dégradé sur le rendu FR ?

 Awikatchikaen.

 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr


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



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



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


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

[OSM-talk-fr] rendu osmFr : forest

[Lord Awikatchikaen]

Bonjour,

Petite réflexion : les abords des forêts ne sont jamais vraiment nets en 
réalité, est ce qu'il ne serait pas possible de dessiner les contours de 
ces landuses avec un flou ou un dégradé sur le rendu FR ?


Awikatchikaen.

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

Re: [OSM-talk-fr] rendu osmFr : forest

[Francescu GAROBY]

Bonsoir,
Je ne suis pas d'accord sur le fait que la bordure d'une forêt est toujours
floue : il n'est pas rare, au contraire, de voir des bordures bien nettes,
tracées au cordeau, parce que les arbres de la parcelle d'à côté ont
entièrement été coupés.

Francescu
Le 1 sept. 2013 20:54, Lord Awikatchikaen lord.awikatchik...@gmail.com
a écrit :

 Bonjour,

 Petite réflexion : les abords des forêts ne sont jamais vraiment nets en
 réalité, est ce qu'il ne serait pas possible de dessiner les contours de
 ces landuses avec un flou ou un dégradé sur le rendu FR ?

 Awikatchikaen.

 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] rendu osmFr : forest

[Philippe Verdy]

Idem. En plus il y a souvent aussi des clôtures, ou un fossé, la séparation
est nette et suit pratiquement toujours une limite de parcelle tirée au
cordeau et matérialisée au minimum par un bornage cadastral.

Certes au gré des coupes ou des chutes d'arbres ou des ratés de certaines
plantation il peut manquer des arbres en bordure, mais à terme ils seront
remplacés et la parcelle reste gérée comme une plantation forestière, c'est
sa vocation, même si certaines coupes ou aménagements laissent apparaître
un nouvel usage: s'il est permanent, ou cela fait l'objet d'un bail (pour
installer un captage, ou faire passer une route ou un chemin d'accès, ou
des pylones électriques, ou une tranchée pour un réseau enterré, il y a
aura nouvelle délimitation de parcelle afin qu'on ne replante pas par
dessus.

Ce qui est flou c'est la couverture végétale saisonnière (selon le
feuillage ou les émondages) mais cela ne rentre pas sur la carte, la
vocation du terrain est inchangée.

Ce qui est réellement plus flou, horizontalement, ce sont les limites de
lits de rivières (sauf si elles sont canalisées avec des bordures
surélevées clairement délimitées et stabilisées., particulièrement pour les
ruisseaux de montagne qui serpentent sur un lit de roches plus ou moins
instables. Au mieux on n'a qu'une zone moyenne ignorant les variations
chaque année voir plusieurs fois par an (au gré des orages) selon les
variations de débit. De même les limites côtières sur les plages selon les
marées (et soit l'érosion des côtes, qui s'accélère malgré les
réensablements artificiels ou travaux d'endiguement ou destinés à retenir
le sable ou modifier le flux des marées).

Ou même verticalement les limites de flancs de collines abruptes et même de
falaises (parce qu'elles sont instables ou bien étagées de façon
irrégulières, on ne sait pas définir la limite de pente à partir de
laquelle on marque la frontière).



Le 1 septembre 2013 21:31, Francescu GAROBY windu...@gmail.com a écrit :

 Bonsoir,
 Je ne suis pas d'accord sur le fait que la bordure d'une forêt est
 toujours floue : il n'est pas rare, au contraire, de voir des bordures bien
 nettes, tracées au cordeau, parce que les arbres de la parcelle d'à côté
 ont entièrement été coupés.

 Francescu
 Le 1 sept. 2013 20:54, Lord Awikatchikaen lord.awikatchik...@gmail.com
 a écrit :

  Bonjour,

 Petite réflexion : les abords des forêts ne sont jamais vraiment nets en
 réalité, est ce qu'il ne serait pas possible de dessiner les contours de
 ces landuses avec un flou ou un dégradé sur le rendu FR ?

 Awikatchikaen.

 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr


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


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

Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Teuxe]

Bonjour,

+1 pour prendre en compte le highway, une barrière sur un tertiary sera 
toujours plus important que sur un track ou un path. Reste la question du 
highway=service.

S'il n'y a pas de tag access=private d'un côté ou de l'autre, c'est important 
aussi, mais ça me semble secondaire.

Teuxe


Christian Quest cqu...@openstreetmap.fr a écrit :
Je voyais le cas où aux moyennes échelles on cherche visuellement par
où
passer. A ces échelles, le côté privé ou pas d'une voie n'est pas
visible
(peut être un truc à changer), et la présence d'un obstacle est un
renseignement qui me semblait important.

C'est peut être à ajuster en fonction du type de highway aussi...


Le 22 août 2013 14:53, Pieren pier...@gmail.com a écrit :

 2013/8/22 Christian Quest cqu...@openstreetmap.fr:
  J'ai aussi remarqué ces barrières un peu trop visibles ailleurs et
je me
  suis posé les mêmes questions.. les rendre moins visible, oui, mais
en
 zone
  rurale où il y a peu de chemins, une barrière devient un élément
 important à
  rendre visible.

 Pas sûr. Même en zone rurale, la présence d'une barrière sur une
route
 ou un chemin marque l'entrée dans une propriété privée. Le tag
 access prend alors tout son sens sur le highway lui-même. Le rendu
 habituel devrait suffire aux zooms plus faibles et l'affichage de la
 barrière elle-même devient secondaire.

 Pieren

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




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




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

-- 
Envoyé de mon téléphone avec Kaiten Mail. Excusez la brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Jean-Marc Liotier]

Voici la Rue de Visien à Courbevoie, au zoom 18:
http://tile.openstreetmap.fr/?zoom=18lat=48.89707lon=2.25256layers=B00FFF

Et la voici au zoom 15:
http://tile.openstreetmap.fr/?zoom=15lat=48.89621lon=2.25038layers=B00FFF

Les résidences bordant cette rues ont été garnies de barrier=fence 
coupés par des barrier=gate - grand bien en fasse au projet. Mais dans 
le contexte urbain dense de Courbevoie, il me semble que la 
représentation deces barrier=gate au zoom 15 est excessive et il me 
semblerait préférable de commencer à les montrer au zoom 17.


Ceci dit, cette observation n'est peut-être pas valable en zone ruraleet 
je n'ose pas imaginer une feuille de style qui tiendrait compte de la 
densité de population de la circonscription administrative pour moduler 
le rendu. Oups - je viens de le faire... Patches welcome et tout ça...


Une solution de compromis serait peut-être de distinguer entre les 
access=private et les autres: d'une manière générale j'ai souvent 
l'impression que les objets marqués access=private devraient apparaître 
un voire deux niveaux de zoom après leurs homologues d'accès libre. Les 
objets access=private sont le plus souvent d'un intérêt plus local et 
les utilisateurs ne souffriraient donc pas de leur moindre 
représentation aux niveaux de zoom faiblestandis que la lisibilité 
s'améliorerait.


Les barrier=fence qui m'ont fait remarquer ce problème ne sont pas 
enaccess=private mais devraient l'être - mais c'est un autre sujet.


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

Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Christian Quest]

J'ai aussi remarqué ces barrières un peu trop visibles ailleurs et je me
suis posé les mêmes questions.. les rendre moins visible, oui, mais en zone
rurale où il y a peu de chemins, une barrière devient un élément important
à rendre visible.

J'avais envisagé de les remplacer par un symbole moins imposant (petit rond
gris foncé), pour tout les barrier=* qui empêchent d'une façon ou d'une
autre de passer.

Les pistes possibles:
- prendre en compte le tag access qui se trouve sur le way où se trouve le
barrier=* (requête moyennement complexe en exécution, mais facile à écrire)
- prendre en compte si on est dans un landuse=residential ou pas...

Adapter le style au landuse est peut être un nouveau domaine à explorer
plus généralement pour améliorer l'adaptabilité du rendu.
Exemple: les cartouches de référence de routes primary/secondary/tertiary
sont ils utiles vraiment en zone urbaine ?

Zut, je crois que cette idée va m'occuper quelques temps ;)



Le 22 août 2013 11:36, Jean-Marc Liotier j...@liotier.org a écrit :

  Voici la Rue de Visien à Courbevoie, au zoom 18:

 http://tile.openstreetmap.fr/?zoom=18lat=48.89707lon=2.25256layers=B00FFF

 Et la voici au zoom 15:

 http://tile.openstreetmap.fr/?zoom=15lat=48.89621lon=2.25038layers=B00FFF

 Les résidences bordant cette rues ont été garnies de barrier=fence coupés
 par des barrier=gate - grand bien en fasse au projet. Mais dans le
 contexte urbain dense de Courbevoie, il me semble que la représentation deces 
 barrier=gate
 au zoom 15 est excessive et il me semblerait préférable de commencer à
 les montrer au zoom 17.

 Ceci dit, cette observation n'est peut-être pas valable en zone rurale et
 je n'ose pas imaginer une feuille de style qui tiendrait compte de la
 densité de population de la circonscription administrative pour moduler le
 rendu. Oups - je viens de le faire... Patches welcome et tout ça...

 Une solution de compromis serait peut-être de distinguer entre les
 access=private et les autres: d'une manière générale j'ai souvent
 l'impression que les objets marqués access=private devraient apparaître
 un voire deux niveaux de zoom après leurs homologues d'accès libre. Les
 objets access=private sont le plus souvent d'un intérêt plus local et les
 utilisateurs ne souffriraient donc pas de leur moindre représentation aux
 niveaux de zoom faibles tandis que la lisibilité s'améliorerait.

 Les barrier=fence qui m'ont fait remarquer ce problème ne sont pas en 
 access=private
 mais devraient l'être - mais c'est un autre sujet.




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

Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Pieren]

2013/8/22 Christian Quest cqu...@openstreetmap.fr:
 J'ai aussi remarqué ces barrières un peu trop visibles ailleurs et je me
 suis posé les mêmes questions.. les rendre moins visible, oui, mais en zone
 rurale où il y a peu de chemins, une barrière devient un élément important à
 rendre visible.

Pas sûr. Même en zone rurale, la présence d'une barrière sur une route
ou un chemin marque l'entrée dans une propriété privée. Le tag
access prend alors tout son sens sur le highway lui-même. Le rendu
habituel devrait suffire aux zooms plus faibles et l'affichage de la
barrière elle-même devient secondaire.

Pieren

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

Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Christian Quest]

Je voyais le cas où aux moyennes échelles on cherche visuellement par où
passer. A ces échelles, le côté privé ou pas d'une voie n'est pas visible
(peut être un truc à changer), et la présence d'un obstacle est un
renseignement qui me semblait important.

C'est peut être à ajuster en fonction du type de highway aussi...


Le 22 août 2013 14:53, Pieren pier...@gmail.com a écrit :

 2013/8/22 Christian Quest cqu...@openstreetmap.fr:
  J'ai aussi remarqué ces barrières un peu trop visibles ailleurs et je me
  suis posé les mêmes questions.. les rendre moins visible, oui, mais en
 zone
  rurale où il y a peu de chemins, une barrière devient un élément
 important à
  rendre visible.

 Pas sûr. Même en zone rurale, la présence d'une barrière sur une route
 ou un chemin marque l'entrée dans une propriété privée. Le tag
 access prend alors tout son sens sur le highway lui-même. Le rendu
 habituel devrait suffire aux zooms plus faibles et l'affichage de la
 barrière elle-même devient secondaire.

 Pieren

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




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

Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Paul Mallet]

Complètement d'accord pour les barrier=gate (on pourrait aussi ajouter les
=lift, =entrance etc.)

Par contre concernant les access=private, ne soit on pas plutôt les placer
sur gate et non sur fence ? Parce que j'ai un peu de mal à visualiser des
barrières publiques ^^
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Christophe Merlet]

Le 22/08/2013 14:53, Pieren a écrit :

2013/8/22 Christian Quest cqu...@openstreetmap.fr:

J'ai aussi remarqué ces barrières un peu trop visibles ailleurs et je me
suis posé les mêmes questions.. les rendre moins visible, oui, mais en zone
rurale où il y a peu de chemins, une barrière devient un élément important à
rendre visible.


Pas sûr. Même en zone rurale, la présence d'une barrière sur une route
ou un chemin marque l'entrée dans une propriété privée.


Pas obligatoirement. Des fois les barrières existent juste pour empêcher 
des animaux de sortir de leurs zones de pâturages. La route reste 
publique. Mais ce ne sont pas les roues les plus fréquentées.


 Le tag

access prend alors tout son sens sur le highway lui-même. Le rendu
habituel devrait suffire aux zooms plus faibles et l'affichage de la
barrière elle-même devient secondaire.




Librement,
--
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Pieren]

2013/8/22 Christophe Merlet red...@redfoxcenter.org:

 Pas obligatoirement. Des fois les barrières existent juste pour empêcher des
 animaux de sortir de leurs zones de pâturages. La route reste publique. Mais
 ce ne sont pas les roues les plus fréquentées.

A moins d'être soi-même une vache, le rendu de la barrière sur les
zooms faibles n'a alors pas beaucoup d'importance puisqu'on peut quand
même passer ;-)

Soit la barrière marque l'arrêt de la circulation du public et
l'entrée dans une zone privée, un simple point noir sur la carte est
insuffisant. Il faut soit ne plus afficher les routes privées, soit
les afficher avec une couleur spécifique (comme dans les zooms plus
élevés).
Soit la barrière ne restreint pas le trafic du public et son absence
sur la carte n'est alors pas très grave puisque sans impact
significatif.

Toutes les barrières que je connais sur les chemins publics concernent
l'interdiction de rouler sur des chemins forestiers (sauf
exploitants). On peut quand même y circuler à pied ou vélo.

Ce que je veux dire, c'est que le rendu du tag access sur le highway
est beaucoup plus important que celui de la barrière elle-même.
D'ailleurs, la plupart des accès limités ou interdits en zone rurale
n'ont pas de barrière mais un simple panneau (on hésite à installer
des portiques télécommandables comme en ville ;-)

Pieren

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

Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Jean-Marc Liotier]

On 22/08/2013 14:43, Christian Quest wrote:
J'avais envisagé de les remplacer par un symbole moins imposant (petit 
rond gris foncé), pour tout les barrier=* qui empêchent d'une façon ou 
d'une autre de passer.


Les pistes possibles:
- prendre en compte le tag access qui se trouve sur le way où se 
trouve le barrier=*


Je crois que c'est une bonne idée parce que le barrier=* sur une voie 
access=private est le plus souvent largement redondant : il montre le 
point précis à partir duquel l'accès privé est physiquement imposé mais 
l'essentiel de l'information est dans le fait que la voie est privée.


On peut aussi prendre en compte le cas où le barrier=* est sur un 
obstacle linéaire mais non relié au réseau routier... Il modélise alors 
paradoxalement un point d'accès et non un obstacle - l'icône pourrait 
être une porte discrète et plutôt ouverte que fermée.


Ces deux cas devraient bien dégager les zones urbaines.

Exemple: les cartouches de référence de routes 
primary/secondary/tertiary sont ils utiles vraiment en zone urbaine ?


Ca dépends probablement des usages: l'utilisateur qui planifie un trajet 
régional à grande échelle souhaitera les voir alors que celui qui 
navigue dans son quartier le trouvera superflu par rapport au nom de la 
rue - sauf si le nom de larue n'est pas renseigné, auquel cas mieux vaut 
la référence que rien du tout. J'ignore à quel niveau de zoom se trouve 
la limite entre ces usages, voire même si le niveau de zoom est le bon 
indicateur pour les discriminer.


Il nous faudra prendre garde à ne pas tenter de tirer du contexte zonal 
des informations qui devraient plutôt être dans les attributs des 
objets. Ca n'est pas le cas pour la questions des références de highway 
en zone urbaine, mais on peut facilement imaginer des cas où le rendu 
sera amélioré par ce contexte au prix d'une augmentation de la 
complexité des règle très supérieure à l'effort que représenterai 
l'étiquetage correct des objets concernés pour qu'ils soient bien pris 
en compte par les règles existantes. D'un autre côté, le contexte zonal 
peut être une source de simplification: si on se trouve sur le 
territoire de la France métropolitaine et que highway=residential on 
peut considérer par défaut que surface=asphalt. Encore un équilibre à 
trouver...



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

Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Pieren]

2013/8/22 Jean-Marc Liotier j...@liotier.org:

 Je crois que c'est une bonne idée parce que le barrier=* sur une voie
 access=private est le plus souvent largement redondant : il montre le point
 précis à partir duquel l'accès privé est physiquement imposé mais
 l'essentiel de l'information est dans le fait que la voie est privée.

Bien du courage alors. Parce que si c'est fait correctement, le noeud
barrier se trouve à la jonction du way public ET du way private.
Il faut donc chercher tous les ways auquel le noeud appartient et
jongler avec tous les tags access en choisissant le plus restrictif du
lot. Ou alors, le plus simple est de considérer que le tag access doit
aussi se trouver sur la barrière elle-même.

Pieren

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

Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Jean-Marc Liotier]

On 22/08/2013 17:44, Pieren wrote:
si c'est fait correctement, le noeud barrier se trouve à la jonction 
du way public ET du way private.


C'est vrai qu'il y a sûrement une forte proportion de tels cas, mais ce 
n'est pas le seul modèle légitime : pour une allée comportant d'une 
barrière de parking, l'ensemble est privé mais la barrière n'est pas 
forcément à sa frontière.



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

Re: [OSM-talk-fr] Rendu osmfr : barrier=gate visible à un niveau de zoom trop faible ?

[Jérôme Amagat]

moi je verrais plutôt, un point quand le nœud n'appartient pas a un highway.
Même chose a zoom faible quand il appartient a un way avec private. ( ça
intéresse très peu de gens) et a zoom elevé laisser le truc existant car il
y a la place et ça peut être un repère.
Et inchangé le reste du temps.(sur route non privée)
(Ce n'est qu'un avis j'ai peut être oubliés des cas et je sais pas si c'est
fesable).


Le 22 août 2013 17:56, Jean-Marc Liotier j...@liotier.org a écrit :

 On 22/08/2013 17:44, Pieren wrote:

 si c'est fait correctement, le noeud barrier se trouve à la jonction du
 way public ET du way private.


 C'est vrai qu'il y a sûrement une forte proportion de tels cas, mais ce
 n'est pas le seul modèle légitime : pour une allée comportant d'une
 barrière de parking, l'ensemble est privé mais la barrière n'est pas
 forcément à sa frontière.



 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr

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