Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Hélène PETIT 

Le 03/02/2012 07:27, Pierre-Alain Dorange a écrit :

Guillaume Allegre

Expliquer que le village et la commune, ce sont deux choses différentes,
ça peut être très facile à expliquer, surtout en zone rurale ;-)
Et du coup, on fait de la pédagogie grâce à OSM.


Mouais... Sauf que visuellement le rendu des 2 noms ne permet pas de
faire la différence et que dans la majorité des cas c'est 2 fois le même
nom exactement... L'intérêt est très amoindri même pédagogiquement,
AMHA...



Pour faire descendre dans le réel l'aimable et très théorique assemblée 
ici réunie, j'ai effectivement essayé la méthode pédagogique ; hier, ça 
a donné ça :


Moi : tiens, regarde, ton patelin est là. C'est bien fait, hein ? t'as 
vu tous les détails ?

Lui : Ah, ouais ! pas mal ! heu,... Pourquoi c'est écrit deux fois, le nom ?
Moi : c'est écrit une fois pour le contour de la commune, et une autre 
fois pour le chef-lieu.
Lui, gros éclat de rire occitan : Eh, bé, il est con, lui ! il a pas vu 
que c'est du pareil au même ?
Moi : Oui, je leur ai déjà dit que ça faisait bizarre, mais en fait ils 
trouvent que c'est plus logique de mettre les deux.

Lui : Eh, bé, dis-donc, (il désigne l'écran) son esquerrenc aquí dedins !
Moi : je leur dirais demain, t'inquiètes.

Mission accommplie,
Hélène





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

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Pierre-Alain Dorange 
Pieren  wrote:

> > On ne parle pas du rôle "admin_center"
> 
> Merci d'écrire "admin_centre" et non "admin_center". Les clés de tags
> sont de préférence rédigés en anglais et non en américain.

Merci, je fais la "faute" a chaque fois, heureusement JOSM me corrige...

-- 
Pierre-Alain Dorange
OSM experiences : 


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

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Philippe Verdy 
Le 3 février 2012 12:01, Ab_fab  a écrit :
> Et j'ajouterai "avec des schémas clairs et si possible en couleurs" pour
> mettre en valeur les intérêts d'une approche alternative
>
> Toutes ces pages et ces pages d'argumentations sur des concepts pas encore
> présentés de manière synthétique n'aboutissent qu'à une seule chose chez moi
> : l'envie de répondre "TL;DR"
>
> http://en.wikipedia.org/wiki/Wikipedia:Too_long;_didn't_read

Tant pis pour toi, avant j'avais essayé de faire court, la réponse a
été encore plus lapidaire, et plus moyen d'argumenter. Puisque les
points de vue restent cantonnés sur un apriori...

On reçoit un non tout de suite, par ceux qui n'ont pas compris, et qui
en plus ne veulent pas lire autre chose, car ils ont compris de
travers dès le début (et pas la peine d'essayer de leur expliquer en
changeant les termes, ou en reformulant, c'est la flemme de lire et
pas envie de faire autrement que ce qui a été fait dont il ne mesure
pas les limites et inconvénients).

D'autres auront le courage de chercher à comprendre, mais si tu n'as
pas envie, je ne t'oblige pas. Les autres chercheront à avancer et
finalement tu te contenteras de faire ce qu'on te dit de faire et pas
autrement, même si c'est mieux et plus facile à gérer et que ça permet
d'autres façons d'avancer sur la carte de façon plus rapide et plus
sure.

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

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet clansco 
On Fri, 03 Feb 2012 11:38:07 +0100
Vincent de Chateau-Thierry  wrote:

> 
> > De : "Philippe Verdy" 
> > Le 3 février 2012 09:37, Pieren 
> a écrit :
> > >
> > > Inutile de revenir ici sur les avantages du "subarea".
> > 
> > Inutile, parce que vous ne voulez pas en discuter ???
> > (...)
> > 
> > Mais où le discuter le mieux que justement sur une liste de discussion
> > faite pour ça ?
> > 
> 
> Par exemple sur la page de discussion d'une page du wiki ou tu exposerais de 
> façon
> synthétique, pédagogique, argumentée (cocher toutes les cases ?) ce que tu 
> proposes, et
> que tu proposais à l'identique... la semaine dernière.
> Il arrive un moment où la forme de la liste de discussion n'est plus du tout 
> adaptée,
> tant tes plaidoyers sont difficiles à assimiler, par leur longueur et les 
> digressions
> que tu y introduis. Une page de wiki (une nouvelle page si celle que 
> j'indiquais tout à
> l'heure ne te convient pas) servirait mieux ton propos, je trouve. Et ça 
> n'est pas un
> artifice pour botter en touche.
> 
> merci
> 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
> http://lists.openstreetmap.org/listinfo/talk-fr
> 

monsanto

http://a5.sphotos.ak.fbcdn.net/hphotos-ak-ash4/s720x720/423954_10150586078219040_43435139039_8959837_1744826979_n.jpg


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

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Ab_fab 
Et j'ajouterai "avec des schémas clairs et si possible en couleurs" pour
mettre en valeur les intérêts d'une approche alternative

Toutes ces pages et ces pages d'argumentations sur des concepts pas encore
présentés de manière synthétique n'aboutissent qu'à une seule chose chez
moi : l'envie de répondre "TL;DR"

http://en.wikipedia.org/wiki/Wikipedia:Too_long;_didn't_read

Le 3 février 2012 11:38, Vincent de Chateau-Thierry  a
écrit :

>
> > De : "Philippe Verdy"
> > Le 3 février 2012 09:37, Pieren
> a écrit :
> > >
> > > Inutile de revenir ici sur les avantages du "subarea".
> >
> > Inutile, parce que vous ne voulez pas en discuter ???
> > (...)
> >
> > Mais où le discuter le mieux que justement sur une liste de discussion
> > faite pour ça ?
> >
>
> Par exemple sur la page de discussion d'une page du wiki ou tu exposerais
> de façon
> synthétique, pédagogique, argumentée (cocher toutes les cases ?) ce que tu
> proposes, et
> que tu proposais à l'identique... la semaine dernière.
> Il arrive un moment où la forme de la liste de discussion n'est plus du
> tout adaptée,
> tant tes plaidoyers sont difficiles à assimiler, par leur longueur et les
> digressions
> que tu y introduis. Une page de wiki (une nouvelle page si celle que
> j'indiquais tout à
> l'heure ne te convient pas) servirait mieux ton propos, je trouve. Et ça
> n'est pas un
> artifice pour botter en touche.
>
> merci
> 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
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
ab_fab 
"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Vincent de Chateau-Thierry 

> De : "Philippe Verdy" 
> Le 3 février 2012 09:37, Pieren 
a écrit :
> >
> > Inutile de revenir ici sur les avantages du "subarea".
> 
> Inutile, parce que vous ne voulez pas en discuter ???
> (...)
> 
> Mais où le discuter le mieux que justement sur une liste de discussion
> faite pour ça ?
> 

Par exemple sur la page de discussion d'une page du wiki ou tu exposerais de 
façon
synthétique, pédagogique, argumentée (cocher toutes les cases ?) ce que tu 
proposes, et
que tu proposais à l'identique... la semaine dernière.
Il arrive un moment où la forme de la liste de discussion n'est plus du tout 
adaptée,
tant tes plaidoyers sont difficiles à assimiler, par leur longueur et les 
digressions
que tu y introduis. Une page de wiki (une nouvelle page si celle que 
j'indiquais tout à
l'heure ne te convient pas) servirait mieux ton propos, je trouve. Et ça n'est 
pas un
artifice pour botter en touche.

merci
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
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Philippe Verdy 
Le 3 février 2012 10:14, Pieren  a écrit :
> 2012/2/3 Vincent de Chateau-Thierry :
>
>> Pour rappel la page ouverte par Sly tout fraîchement :
>> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Mod%C3%A8le
>> _somme_de_surface_ou_mod%C3%A8le_fronti%C3%A8re
>> suite au débat "subarea". Elle aborde la modélisation par surfaces, autant 
>> développer
>> à cette adresse les arguments.
>
> Ah, je savais bien qu'il y avait déjà une page comme ça. J'y ai ajouté
> certains mots-clé pour que mes recherches futures la retrouvent plus
> facilement.

Sauf que je n'ai JAMAIS prétendu ici défendre la modélisation par surfaces.

C'est hors sujet car moi aussi je retiens la modélisation par
frontières, qui toutefois devra être affinée en commençant à traiter
les frontières partagées dans un objet autonome sans duplication (un
travail à faire quand on aura le support intégral des
boundary_segments, qu'on devrait toutefois pouvoir commencer à
renseigner de façon séparée, en indiquant aux moteurs de rendus qu'ils
ne pourront les utiliser à la place des listes de chemins QUE si les
boundary_segments sont complets, tous listés dans la relation, et
qu'il ne reste plus aucun chemin "inner"/"outer" dans la relation,
cette condition permettant ensuite le nettoyage; cependant il faudrait
que JOSM améliore leur prise en compte pour faire correctement les
vérifications de fermeture).

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

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Philippe Verdy 
Le 3 février 2012 09:37, Pieren  a écrit :
> 2012/2/3 Philippe Verdy :
>
>> Le tag place sert à autre chose: il indique l'importance relative d'un
>> lieu par rapport aux autres. Il sert surtout à fixer des priorités
>> d'affichage et à éliminer (par exemple dans le rendu d'une carte à
>> échelle grossière) des noms en excès qu'on ne peut pas tous afficher
>> en même temps sans rendre la carte totalement illisible, pour ne faire
>> apparaître que les éléments importants (par exemple les chef-lieux de
>> région mais pas tous ceux de départements, les capitales de pays mais
>> pas les autres villes du pays, les villes de plus de 100 000 habitants
>> mais pas les villes de plus de 10 000 ou les villages).
>
> Le tag "place" est souvent basé sur un critère de taille (population).
> Mais la taille n'est pas forcément l' "importance". Le role de
> "chef-lieu" est justement modélisé par le role "admin_centre" de la
> relation boundary.
>
> Inutile de revenir ici sur les avantages du "subarea".

Inutile, parce que vous ne voulez pas en discuter ???

Surtout parce que ceux qui s'y opposent veulent absolument que cela
modélise la géométrie, d'une zone, alors que ce n'est pas le but.

Ou disent que cela empêche de modéliser niveau par niveau ce qui est
là encore totalement faux, ou que cela rendrait le système non
homogène, ce qui est faux aussi (les problèmes d'homogénéité existent
déjà avec les frontières seules, et il n'y a aucun outil pour vérifier
leur cohérence de toute façon, ou de faciliter les corrections et
fixer les oublis).

Les "subarea:*" tels que je les décrit ne servent pas à définir la
géométrie des zones elles-mêmes (pluriel, car ils peuvent être de
différents rôles pour des découpages de nature différente) , et n'ont
pas nécessairement non plus à en faire une partition complète.

Voyez les comme des métadonnées essentielles, faciles à maintenir de
façon séparée, et qui facilitent énormément les recherches et la
classification des données, ainsi que (ensuite seulement) les
éventuels contrôles de cohérence permettant de faciliter les
corrections de frontières qu'il ne s'agit pas de supprimer.

Quant à la page que tu proposes, elle ne concerne que les EPCI. Le
rapport avec les subarea ne serait que pour l'énumération des communes
qui en sont membres, mais ce n'est même pas évoqué, ou pour le
découpage des zones de service de l'EPCI (pôles de proximité par
exemple), deux rôles différents.

Mais le problème est bien plus général, et tous les découpages d'un
type donné ne sont pas non plus nécessairement une partition complète
(il peut y avoir des parties incluses qui débordent de la zone mère,
et c'est le cas des EPCI dont bon nombre sont à cheval sur plusieurs
départements ou régions, même si ce n'est pas le cas concernant les
arrondissements dans les départements, les départements dans les
régions, et les régions du pays si on admet la Corse comme une région
malgré son statut particulier, un statut qui pourrait être explicité
avec un tag remplaçant le statut par défaut).

Pensez alors aux découpages cantonaux, et aux données de nature
géo-démographique ou pour l'aménagement territorial comme les
agglomérations et aires urbaines de l'Insee : il ne s'agit pas de
retracer les frontières, juste d'énumérer des listes de membres pour
permettre de produire ensuite des cartes dérivées (et pas seulement
des cartes routières ou de navigation). Pensez aux autres découpages
de nature économique, judiciaire, hospitalière/santé publique,
fiscale, chambres de commerces, syndicats agricoles...

Si c'est le nom du rôle "subarea:*" qui vous fait peur, on peut en
changer pour "member:*", ou autre, ça peut se discuter. De même
j'avais évoqué la possibilité d'un tag "partition=" dont la (ou les
valeurs valeurs séparées par un point-virgule) permettent donner le
nom du rôle "member:*" ou "subarea:*" ou autre qui sont sensées former
une partition de la zone et dont on liste tous les membres ayant ce
même rôle (avec ce tag, il devient aussi possible de naviguer entre
plusieurs types de découpage, pas seulement sur une carte, mais dans
des tables statistiques dont on peut ainsi produire des agrégats
statistiques sur des axes différents).

De même, au lieu de proposer de créer des relations séparées (ce que
je trouve complètement stupide quand cela crée des objets désignant
les mêmes zones à découper), on peut aussi voir ces données comme une
couche séparée qui pourrait être stockée dans une base séparée, sans
absolument AUCUNE définition géométrique (pas de noeuds, pas de
chemins), hors des relations, qui reprendraient exactement les mêmes
ID's que OSM (dans ce cas on pourrait choisir de les charger ou ne pas
les charger, dans un calque de données distinct). Un peu ce que fait
Nominatim (avec beaucoup de mal car il se trompe très souvent en
faisant les recherches par géométrie pour tenter de renseigner sa
propre base de recherche).

Car on met beaucoup trop de choses dans la base OSM (des tas
d'attributs difficiles à mainteni

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Pieren 
2012/2/3 Vincent de Chateau-Thierry :

> Pour rappel la page ouverte par Sly tout fraîchement :
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Mod%C3%A8le
> _somme_de_surface_ou_mod%C3%A8le_fronti%C3%A8re
> suite au débat "subarea". Elle aborde la modélisation par surfaces, autant 
> développer
> à cette adresse les arguments.

Ah, je savais bien qu'il y avait déjà une page comme ça. J'y ai ajouté
certains mots-clé pour que mes recherches futures la retrouvent plus
facilement.

Pieren

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

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Ab_fab 
Pour mémoire, le travail intéressant présenté par Damouns en mai 2010 qui
met en rapport la population des communes et leurs positions respectives.

http://www.openstreetmap.org/user/Damouns/diary/10789

Le 3 février 2012 09:37, Pieren  a écrit :

> 2012/2/3 Philippe Verdy :
>
> > Le tag place sert à autre chose: il indique l'importance relative d'un
> > lieu par rapport aux autres. Il sert surtout à fixer des priorités
> > d'affichage et à éliminer (par exemple dans le rendu d'une carte à
> > échelle grossière) des noms en excès qu'on ne peut pas tous afficher
> > en même temps sans rendre la carte totalement illisible, pour ne faire
> > apparaître que les éléments importants (par exemple les chef-lieux de
> > région mais pas tous ceux de départements, les capitales de pays mais
> > pas les autres villes du pays, les villes de plus de 100 000 habitants
> > mais pas les villes de plus de 10 000 ou les villages).
>
> Le tag "place" est souvent basé sur un critère de taille (population).
> Mais la taille n'est pas forcément l' "importance". Le role de
> "chef-lieu" est justement modélisé par le role "admin_centre" de la
> relation boundary.
>
> Inutile de revenir ici sur les avantages du "subarea". Ce que tu
> devrais plutôt faire, c'est rédiger une page spéciale sur le wiki avec
> des exemples concrets. Chacun pourrait y mettre les avantages et
> inconvénients de chaque modèle et se faire une idée. Une ébauche
> existe déjà sur la page des EPCI
> (
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives/Mise_au_point_du_modele_des_EPCI
> )
> mais il faudrait généraliser.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
ab_fab 
"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Vincent de Chateau-Thierry 
Bonjour,

> De : "Pieren" 

> 
> Inutile de revenir ici sur les avantages du "subarea". Ce que tu
> devrais plutôt faire, c'est rédiger une page spéciale sur le wiki avec
> des exemples concrets. Chacun pourrait y mettre les avantages et
> inconvénients de chaque modèle et se faire une idée. Une ébauche
> existe déjà sur la page des EPCI
> 
(http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives
/Mise_au_point_du_modele_des_EPCI)
> mais il faudrait généraliser.
> 

La modélisation des EPCIs a été depuis choisie, on est bien face à une page 
d'archive.
Pour rappel la page ouverte par Sly tout fraîchement :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Mod%C3%A8le
_somme_de_surface_ou_mod%C3%A8le_fronti%C3%A8re
suite au débat "subarea". Elle aborde la modélisation par surfaces, autant 
développer
à cette adresse les arguments.

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
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Pieren 
2012/2/3 Philippe Verdy :

> Le tag place sert à autre chose: il indique l'importance relative d'un
> lieu par rapport aux autres. Il sert surtout à fixer des priorités
> d'affichage et à éliminer (par exemple dans le rendu d'une carte à
> échelle grossière) des noms en excès qu'on ne peut pas tous afficher
> en même temps sans rendre la carte totalement illisible, pour ne faire
> apparaître que les éléments importants (par exemple les chef-lieux de
> région mais pas tous ceux de départements, les capitales de pays mais
> pas les autres villes du pays, les villes de plus de 100 000 habitants
> mais pas les villes de plus de 10 000 ou les villages).

Le tag "place" est souvent basé sur un critère de taille (population).
Mais la taille n'est pas forcément l' "importance". Le role de
"chef-lieu" est justement modélisé par le role "admin_centre" de la
relation boundary.

Inutile de revenir ici sur les avantages du "subarea". Ce que tu
devrais plutôt faire, c'est rédiger une page spéciale sur le wiki avec
des exemples concrets. Chacun pourrait y mettre les avantages et
inconvénients de chaque modèle et se faire une idée. Une ébauche
existe déjà sur la page des EPCI
(http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives/Mise_au_point_du_modele_des_EPCI)
mais il faudrait généraliser.

Pieren

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

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Pieren 
2012/2/3 Philippe Verdy :
> On ne parle pas du rôle "admin_center"

Merci d'écrire "admin_centre" et non "admin_center". Les clés de tags
sont de préférence rédigés en anglais et non en américain.

Pieren

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

Re: [OSM-talk-fr] role=label

2012-02-03 Par sujet Philippe Verdy 
Le 3 février 2012 07:27, Pierre-Alain Dorange  a écrit :
> sly (sylvain letuffe) 
> wrote:
>
>> Il y a la proposition du role admin_centre qui a pour but de "faire remonter
>> dans la relation"
>>
>> Mais la question du double nom entre la relation administrative et le tag
>> place est pour moi un faux problème.
>
> C'est faux problème qui a un impact réel tout de même, on voit sur la
> carte 2 fois le même nom dans la majorité des cas et sans aucune
> véritable raison.

Le tag place sert à autre chose: il indique l'importance relative d'un
lieu par rapport aux autres. Il sert surtout à fixer des priorités
d'affichage et à éliminer (par exemple dans le rendu d'une carte à
échelle grossière) des noms en excès qu'on ne peut pas tous afficher
en même temps sans rendre la carte totalement illisible, pour ne faire
apparaître que les éléments importants (par exemple les chef-lieux de
région mais pas tous ceux de départements, les capitales de pays mais
pas les autres villes du pays, les villes de plus de 100 000 habitants
mais pas les villes de plus de 10 000 ou les villages).

C'est un critère finalement subjectif qui présuppose une utilisation
dans un type de carte et présuppose l'importance d'un lieu à afficher
(label et/ou symbole centré sur un point "central" désigné ou calculé)
selon un critère unique et finalement arbitraire (town=city,
town=village, town=hamlet...) alors que cette sélection devrait se
baser sur des critères plus explicitement tagués (par exemple les
rôles admin_center pour désigner les chef-lieux de chaque niveau
administratif, ou la population chiffrée).

Noter que le critère d'importance donné par le tag place est fortement
lié au niveau de zoom: les critères de sous-sélection changent, mais
pas la valeur du tag place, ce qui finalement ne permet plus de faire
de meilleures sélections plus pertinentes.

Ce tag "place" ne devrait contenir que l'indication du statut ou type
officiel de lieu (par exemple pour indiquer que c'est un chef-lieu de
région ou une capitale de pays, ou bien une "ville libre" si on les
distingue d'une "cité' selon la classification administrative
officielle d'un pays et le statut de fonctionnement, ou bien pour
indiquer que le niveau 2 désigne une collectivité territoriale unique
avec les attributions à la fois d'un département et d'une région, et
pas seulement un département.

Mais cela remettrait en cause trop de données actuellement. Un
meilleur système de classification c'est le "boundary_type"
(administrative, maritime...) ou, pour la France, le tag permettant de
désigner et séparer les différents types d'EPCI à fiscalité propre
(métropole, CA, CC, SAN) ou non (SIVU, SIVOM...), et leurs éventuelles
subdivisions (par exemples les "pôles de proximité" actuellement
cartographiés dans Nantes Métropole et auxquels on vient de supprimer
l'admin_level=9 car ce ne sont pas des quartiers de la commune, même
si ce sont bien des subdivisions administratives):

Ce dernier exemple est un cas qui soulève le problème actuel de
l'impossibilité de créer plusieurs hiérarchies indépendantes de zones
administratives, des hiérarchies superposées, que "l'admin_level"
actuel ne permet pas de gérer au delà d'une seule hiérarchie
"principale" définie de façon uniforme pour tout le pays et même le
monde entier). Un cas qui montrait encore l'utilité des membres de
type "subarea:*" qui ont été fortement critiqués à cause de prétendus
problèmes de rendus inexistants, alors que cela permettait de taguer
très proprement (et de façon non arbitraire) les différents types de
subdivision ou de partitionnement qui peuvent exister dans une zone
donnée, et qu'on distinguerait par leur rôle "subarea:*" sans même
créer aucune relation supplémentaire ni aucun noms ou traductions
supplémentaires dans les relations (certains y ont vu une tentative de
passer à la modélisation par surface, alors que ce n'était clairement
pas équivalent, même mathématiquement au sens topologique;
malheureusement, vous ne l'avez pas compris du tout quand je vous ai
dit que cela ne remettait pas du tout en cause la modélisation
géométrique par frontières et non par surfaces, et que cela ne faisait
absolument PAS "doublon").

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

Re: [OSM-talk-fr] role=label

2012-02-02 Par sujet Philippe Verdy 
Le 3 février 2012 07:27, Pierre-Alain Dorange  a écrit :
> sly (sylvain letuffe) 
> wrote:
>
>> Il y a la proposition du role admin_centre qui a pour but de "faire remonter
>> dans la relation"
>>
>> Mais la question du double nom entre la relation administrative et le tag
>> place est pour moi un faux problème.
>
> C'est faux problème qui a un impact réel tout de même, on voit sur la
> carte 2 fois le même nom dans la majorité des cas et sans aucune
> véritable raison.
>
>> [...]
>> Je continue de dire qu'il s'agit de deux noms pour deux choses différentes,
>> donc normal. Coïncidence, en France, les communes portent souvent le nom de
>> leur chef lieu (mais ce n'est pas tout le temps le cas)

On ne parle pas du rôle "admin_center", indication de la position et
du nom du chef-lieu/capitale/siège de la zone concernée (laquelle peut
être une commune, un département, une région, un pays, un EPCI, etc.
et pourrait ne pas être retreinte géomatriquement à un seul nœud mais
pourrait être une zone entière, avec aussi un nom affichable,
l'utilisation d'une zone offrant un avantage car elle indique aussi
une tolérance de placement du label de ce chef-lieu/capitale/siège au
sein de la zone qui le désigne avec le rôle "admin_center").

On parle du rôle "label" qui n'a pas d'autre fonction que de préciser
une position plus fine de placement du label pour 1 seule zone
concernée. Le label indique aussi le nom de cette zone. Il n'est pas
nécessairement placé à l'emplacement de l'admin_center. Son rôle
pricipal est d'améliorer le placement du label pour aider les outils
de rendu, mais au delà de ça, les noms qui y sont ceux bien ceux de la
relation (une et une seule) qui référence cet objet avec le rôle
"label".

Que l'objet référencé comme "label" ait lui-même une géométrie, cette
géométrie est arbitraire (mais devrait être DANS la géométrie de la
relation. Cette géométrie est actuellement uniquement un nœud, mais
cela n'indique aucune zone de tolérance pour le placement du label.
Alors que cela pourrait indiquer un chemin (permettant d'orienter le
label en diagonale ou sur une courbe) ou une zone fermée entière (à
charge pour le monteur de rendu de trouver une place libre dans cette
zone sur la carte pour éviter les collisions ou l'élimination du label
qu'on préfère faire apparaître.

Un label pourrait aussi avoir d'autres propriétés, telles que
l'indication de son importance relative par rapport à d'autres labels
de zones différentes voisines, afin de permettre de faire un choix en
cas de collisions. Mais il n'y a aucune raison pour que l'objet de
rôle label ait un nom affiché différent de celui de la relation qui le
désigne avec ce rôle. Le label désigne bien la même zone géographique
que la relation qui l'utilise avec ce rôle.

Un objet créé pour être désigné comme membre de rôle 'label" d'une
relation, ne peut être membre que d'1 et 1 seule relation. Il ne doit
pas exister sans être membre d'une relation, et ne peut pas être
partagé. De même une relation ne peut avoir plus d'1 objet label par
zone connexe, mais éventuellement pourrait avoir 1 membre label pour
chaque zone connexe (la zone "principale" et chacune de ses exclaves).

Cependant, dans le cas de zones comme les archipels, la relation mère
a une géométrie souvent trop compliquée avec de nombreuses exclaves,
et mettre un label sur chaque partie est illisible, alors qu'on peut
aussi désigner comme zone pour le label un polygone large connexe
renfermant toutes les îles et îlots ou rocs, même si ce polygone
inclut des zones de mer qui ne sont pas formellement partie de la
relation mère (ce n'est normalement pas un problème s'il n'y a rien à
labeller de façon significative pour les interstices. Bref là encore,
l'objet label permet de remplacer la géométrie de la relation qui le
désigne comme label,par une géométrie plus simple et mieux adaptée à
la représentation graphique de la carte.

Le label n'est donc qu'une information destinée au rendu de la carte,
mais pas fondamental pour la géométrie logique et la cohérence de la
base de données. Disons que c'est une annotation, une métadonnée
optionnelle (qui pourrait ne pas être stocké dans la base OSM
elle-même, mais dans une base annexe, comme une couche séparée. Les
noms qu'on met dans les labels font donc effectivement doublons.

La donnée essentielle, qui doit faire foi, est l'indication du nom (et
ses traductions et noms alternatifs utiles aux recherches, ou noms
longs formels et officiels utiles pour certains états statistiques ou
pour une carte "diplomatique", ou noms non officiels "common_name:*"
utilisés par les habitants locaux ou dans d'autres pays, y compris des
translitérations approximatives et souvent encore plus ambigus
qu'utilisent pourant couramment les russophones) par la relation mère
elle-même.

Les noms présents dans les labels ne devraient pas être utilisés du
tout par un moteur de rendu sur une carte, sauf si ces objets "label"
sont ajoutés par eux dans leur propre base de toponymes modifiés

Re: [OSM-talk-fr] role=label

2012-02-02 Par sujet Pierre-Alain Dorange 
Guillaume Allegre 
wrote:

> > Je crois que nous avons intérêt à accélérer la solution de ce petit
> > bug, qui se voit comme le nez au milieu de la figure pour le grand
> > public (les techs s'en fichent complètement, je l'ai vérifié).
> 
> Ben ça dépend où. 
> Expliquer que le village et la commune, ce sont deux choses différentes,
> ça peut être très facile à expliquer, surtout en zone rurale ;-)
> 
> Et du coup, on fait de la pédagogie grâce à OSM.

Mouais... Sauf que visuellement le rendu des 2 noms ne permet pas de
faire la différence et que dans la majorité des cas c'est 2 fois le même
nom exactement... L'intérêt est très amoindri même pédagogiquement,
AMHA...

-- 
Pierre-Alain Dorange
OSM experiences : 


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

Re: [OSM-talk-fr] role=label

2012-02-02 Par sujet Pierre-Alain Dorange 
sly (sylvain letuffe) 
wrote:

> Il y a la proposition du role admin_centre qui a pour but de "faire remonter
> dans la relation"
> 
> Mais la question du double nom entre la relation administrative et le tag
> place est pour moi un faux problème.

C'est faux problème qui a un impact réel tout de même, on voit sur la
carte 2 fois le même nom dans la majorité des cas et sans aucune
véritable raison.

> [...]
> Je continue de dire qu'il s'agit de deux noms pour deux choses différentes,
> donc normal. Coïncidence, en France, les communes portent souvent le nom de
> leur chef lieu (mais ce n'est pas tout le temps le cas)

Les non-cas sont assez réduit vis à vis du cas général tout de même...
Si le moteur de rendu pouvait ommettre le nom de la relation quand il y
a un admin_centre qui porte le même nom ça serait un peu plus clair au
niveau de la lisibilité tout de même...
Mais bon.

-- 
Pierre-Alain Dorange
OSM experiences : 


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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Pieren 
2012/1/31 Guillaume Allegre :

> Merci de ce signalement. Je ne connaissais pas fuzzy.
> Je ne sais pas si la proposition est idéale, mais elle répond à coup sûr
> à un vrai besoin. Je suis étonné de ne pas l'avoir rencontré avant.
> Est-ce qu'un moteur de rendu actuel est capable de la prendre en compte ?

Usage du tag dans la base actuelle : 19
http://taginfo.openstreetmap.org/keys/fuzzy#overview

Moi, j'en proposerais bien un autre mais il y en a 0 actuellement :
http://taginfo.openstreetmap.org/search?q=doigt_mouill%C3%A9

Pieren

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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Guillaume Allegre 
Le mar. 31 janv. 2012 à 17:29 +0100, Ab_fab a ecrit :
> Une piste ici, pour les zones "diffuses"
> http://wiki.openstreetmap.org/wiki/Proposed_features/Fuzzy
> 
> Pour ce qui est de l'intérêt de l'attribut "label", désolé, mais j'ai rien
> compris

Merci de ce signalement. Je ne connaissais pas fuzzy. 
Je ne sais pas si la proposition est idéale, mais elle répond à coup sûr
à un vrai besoin. Je suis étonné de ne pas l'avoir rencontré avant. 
Est-ce qu'un moteur de rendu actuel est capable de la prendre en compte ?


-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Guillaume Allegre 
Le mar. 31 janv. 2012 à 12:45 +0100, Hélène PETIT a ecrit :

> Je suis revenue sur cette question du double affichage, un peu aussi
> pour des raisons de com :
> Quand je présente OSM à des gens qui le découvrent, la première
> chose qu'ils demandent, c'est à voir leur patelin ; et la deuxième
> chose qu'ils disent c'est "pourquoi c'est écrit eux fois ?"
> Bon, avec peu d'astuce, hop, on ne reste pas là-dessus ; quand même,
> ça laisse une petite trace.
> 
> Je crois que nous avons intérêt à accélérer la solution de ce petit
> bug, qui se voit comme le nez au milieu de la figure pour le grand
> public (les techs s'en fichent complètement, je l'ai vérifié).

Ben ça dépend où. 
Expliquer que le village et la commune, ce sont deux choses différentes, 
ça peut être très facile à expliquer, surtout en zone rurale ;-)

Et du coup, on fait de la pédagogie grâce à OSM.


-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Philippe Verdy 
Le 31 janvier 2012 17:48, Vincent de Chateau-Thierry
 a écrit :
>
>> De : "Philippe Verdy"
>>
>> Entièrement d'accord. Y compris sur le "name" (et ses traductions) qui
>> doit alors remplacer celui de la relation quand les deux sont
>> présents.
>> (...)
>>
>> Juste une idée "comme ça" :
>>
>> (...)
>>
>> Une règle supplémentaire devrait être que cet objet de "type=label"
>> ...
>>
>> Un label objet de "type=label" ne devrait pas exister seul, sinon
>> c'est qu'il doit être d'un autre type plus descriptif (dans ce cas on
>> enlève son attribut "type=label" mais il faut indiquer le genre
>> d'objet qu'il désigne, avec d'autres attributs géographiques).
>>
>
> Avoir des lignes de placement pour du texte relève à 100 % du domaine de la 
> cartographie,
> autrement dit de la représentation des données, le fameux "rendu".
> OSM n'est pas une carte mais une base de données, a fortiori une base dont la 
> vocation
> est bien plus large que la représentation cartographique. Ça serait à mon 
> sens une dérive
> que de stocker ce type d'info dans la base, tout ça pour palier à une absence 
> de finesse
> dans les algos de placement des moteurs de rendu. Sans parler de la 
> multiplicité des
> lignes pour un même texte, tout ça pour anticiper les représentations à 
> différentes
> échelles (on y revient toujours :-) ).
>
> En revanche, modéliser, peut-être avec le fuzzy souligné par Ab_fab, les 
> limites floues,
> ça me paraît une vraie question pour la base de données. Aux moteurs de rendu 
> ensuite
> de s'en emparer, chacun son boulot.

Dans ce cas, on ne labelle plus rien d'autre que les surfaces (qui par
elles-même indiquent les tolérances de placement). Pourtant, les
labels ont une direction préférée. Sans aucune indication dans la
base, on ne peut que les centrer sur un point et pas les dimensionner
du tout.

L'idée des limites floues (fuzzy) est bonne: on continue à modéliser
une surface, donc une géométrie, même avec un tracé imprécis et une
résolution faible. Mentionner ces limites comme floues évite de les
dessiner explicitement dans le moteur de rendu, mais suffit à indiquer
la zone dans laquelle on suggère de placer le label (qui devrait
"recouvrir" proportionellement toute cette zone, quitte à espacer les
lettres et agrandir les polices utilisées).

Mais comment indiquer sa direction, par exemple pour les massifs
montagneux, les caps et pointes de terres, les presqu'îles, les baies
maritimes (souvent contenant des "sous-baies" ; l'idéal serait
d'indiquer la ligne centrale d'approche dans la baie), ou des
désignations locales (culturelles mais non administratives) ? Sans
aucune direction, tous nos labels sont horizontaux, rien ne les
distingue vraiment, et un moteur ne sait pas du tout comment faire.

Si on n'indique que la surface avec une limite floue, le contour fermé
n'a plus de direction (le contour n'est pas nécessairement fortement
convexe, il peut être même ramifié, comme les rivières, sans pour
autant qu'on ait a désigner toutes les petites ramifications, ce qui
justifie d'afficher alors plusieurs fois le label sur une carte, sur
les ramifications principales) ; alors qu'un trait de placement (le
"noyau" squelettique de la surface désignée par ce label) suffit à
régler le problème, comme on le fait sur les rivières (en indiquant le
cours central, en plus des rives; quand les rives sont représentables,
le moteur les dessine et les remplit, mais ne dessine plus le trait du
cours central, mais l'utilise pour positionner correctement le nom du
cours d'eau, et aussi pour indiquer son sens d'écoulement d'amont en
aval, bien qu'il suffirait seulement de mentionner le point source et
celui d'embouchure ou de confluent).

Il existe des algorithmes pour calculer le noyau squelettique d'une
surface connexe définie par son contour polygonal (le noyau est un
ensemble de courbes interconnectées, inclues totalement dans la
surface ferlée par le contour), mais avec toutes les irrégularités des
surfaces complexes (comme les côtes par exemple, mais aussi les
rivières, on obtiendrait un squelette contenant de très nombreuses
ramifications de longueurs très différentes et pas de réelle utilité à
labelliser toutes ces irrégularités quand la ramification principale
suffit largement, étant donnée le lettrage employé le long de cette
ramification).

Noter aussi que la délimitation entre un cours d'eau et son affluent
est une limite floue alors que les rives ne le sont pas. En pratique
ça veut dire créer un segment "flou" (à masquer, donc marqué comme
"fuzzy") et l'inclure comme membre du multipolygone définissant les
rives de chaque cours ou affluent.

Comme alors chaque cours est entièrement défini par une courbe fermée,
il est possible d'en calculer automatiquement un squelette (à
condition de savoir éliminer les fausses ramifications créées
simplement par des variations de largeur ou de petites criques), ce
qui alors rendrait caduque l'indication du cours "central" avec les
"main_stream" et "side_stream" (des ligne

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Vincent de Chateau-Thierry 

> De : "Philippe Verdy" 
> 
> Entièrement d'accord. Y compris sur le "name" (et ses traductions) qui
> doit alors remplacer celui de la relation quand les deux sont
> présents.
> (...)
> 
> Juste une idée "comme ça" :
> 
> (...)
> 
> Une règle supplémentaire devrait être que cet objet de "type=label"
> ...
> 
> Un label objet de "type=label" ne devrait pas exister seul, sinon
> c'est qu'il doit être d'un autre type plus descriptif (dans ce cas on
> enlève son attribut "type=label" mais il faut indiquer le genre
> d'objet qu'il désigne, avec d'autres attributs géographiques).
> 

Avoir des lignes de placement pour du texte relève à 100 % du domaine de la 
cartographie,
autrement dit de la représentation des données, le fameux "rendu".
OSM n'est pas une carte mais une base de données, a fortiori une base dont la 
vocation
est bien plus large que la représentation cartographique. Ça serait à mon sens 
une dérive
que de stocker ce type d'info dans la base, tout ça pour palier à une absence 
de finesse 
dans les algos de placement des moteurs de rendu. Sans parler de la 
multiplicité des
lignes pour un même texte, tout ça pour anticiper les représentations à 
différentes
échelles (on y revient toujours :-) ).

En revanche, modéliser, peut-être avec le fuzzy souligné par Ab_fab, les 
limites floues,
ça me paraît une vraie question pour la base de données. Aux moteurs de rendu 
ensuite
de s'en emparer, chacun son boulot.

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
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Ab_fab 
Une piste ici, pour les zones "diffuses"
http://wiki.openstreetmap.org/wiki/Proposed_features/Fuzzy

Pour ce qui est de l'intérêt de l'attribut "label", désolé, mais j'ai rien
compris

Le 31 janvier 2012 17:10, Philippe Verdy  a écrit :

> Le 31 janvier 2012 14:25, Christian Quest  a
> écrit :
> > "label" ne devrait-il pas définir que la position à utiliser de
> > préférence par le moteur de rendu et pas le nom (le libellé) en lui
> > même sauf si il devait être différent du "name" qui se trouve dans la
> > relation parente ?
> >
> > Ca ne vous semble pas plus logique vu comme ça ?
>
> Entièrement d'accord. Y compris sur le "name" (et ses traductions) qui
> doit alors remplacer celui de la relation quand les deux sont
> présents.
>
> Si on va plus loin les "labels" ne devraient pas être limités à un
> seul nœud: ce pourrait être un segment ou une courbe, utile pour
> positionner correctement les noms de massifs montagneux par exemple,
> ou le nom des côtes ("Côte de granit rose" par exemple), surtout quand
> ils ne sont pas associés à une zone fermée précisément géolocalisée
> (massifs montagneux, côtes et baies, plages...) :
>
> Le trait indique alors que le label devrait être écrit tout le long de
> cette courbe, et pas seulement centré sur un seul point, à une taille
> trop petite par rapport à ce qu'ils décrivent réellement.
>
> Le label pourrait aussi indiquer qune indication éventuelle de la
> tolérance admissible pour le déplacement (en cas de collision entre
> labels distincts, si le rendu ne rend pas certains labels
> transparents), cependant ce n'est pas forcément nécessaire car alors
> cette tolérance doit pouvoir correspondre à une surface fermée (même
> avec des contours sommaires de faible résolution).
>
> OSM a encore du boulot pour définir des règles permettant d'aider les
> logiciels de rendu à placer (et aussi dimensionner) correctement tous
> les labels, indépendamment des styles qu'on leur applique (couleurs,
> transparence, police utilisée, effets de style comme des glyphes
> détourés), tous ces styles étant propres aux moteurs de rendus (qui
> peuvent ignorer le placement amélioré cependant en utilisant qu'un
> point central).
>
>
> Juste une idée "comme ça" :
>
> Si on place dans la base un objet pour le label, il doit avoir une
> géométrie (nœud, chemin, voire surface pour les tolérances de
> placement même si ce n'est pas utile si le label est associé à une
> relation de surface). Cette géométrie elle-même peut ne pas être
> visible sur la carte (aucun trait ou point visible, seul le texte du
> label apparaît au placement indiqué) ; c'est donc un objet séparé.
>
> Si cet objet ne correspond pas à un objet réel possédant d'autres
> attributs à visualiser, il devrait être marqué comme étant de
> "type=label" afin d'indiquer justement de ne pas dessiner cette
> géométrie (pas de trait, pas de remplissage de la zone de tolérance,
> pas de hachurage, pas de symbole centré sur le nœud désigné comme
> géométrie...) mais seulement le texte associé.
>
> Une règle supplémentaire devrait être que cet objet de "type=label"
> doit être associé au maximum à un et un seul autre objet de type
> géométrique différent (un label de géométrie surface/multipolygone
> peut être associé à un noeud ou un chemin, mais pas à une autre
> surface/multipolygone; un label de géométrie nœud peut être associé à
> un chemin ou une surface mais pas un nœud). Sinon ses attributs sont
> redondants et doivent être remontés directement dans l'objet réel qui
> le référence (sauf le "type=label").
>
> Un label objet de "type=label" ne devrait pas exister seul, sinon
> c'est qu'il doit être d'un autre type plus descriptif (dans ce cas on
> enlève son attribut "type=label" mais il faut indiquer le genre
> d'objet qu'il désigne, avec d'autres attributs géographiques).
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
ab_fab 
"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Philippe Verdy 
Le 31 janvier 2012 14:25, Christian Quest  a écrit :
> "label" ne devrait-il pas définir que la position à utiliser de
> préférence par le moteur de rendu et pas le nom (le libellé) en lui
> même sauf si il devait être différent du "name" qui se trouve dans la
> relation parente ?
>
> Ca ne vous semble pas plus logique vu comme ça ?

Entièrement d'accord. Y compris sur le "name" (et ses traductions) qui
doit alors remplacer celui de la relation quand les deux sont
présents.

Si on va plus loin les "labels" ne devraient pas être limités à un
seul nœud: ce pourrait être un segment ou une courbe, utile pour
positionner correctement les noms de massifs montagneux par exemple,
ou le nom des côtes ("Côte de granit rose" par exemple), surtout quand
ils ne sont pas associés à une zone fermée précisément géolocalisée
(massifs montagneux, côtes et baies, plages...) :

Le trait indique alors que le label devrait être écrit tout le long de
cette courbe, et pas seulement centré sur un seul point, à une taille
trop petite par rapport à ce qu'ils décrivent réellement.

Le label pourrait aussi indiquer qune indication éventuelle de la
tolérance admissible pour le déplacement (en cas de collision entre
labels distincts, si le rendu ne rend pas certains labels
transparents), cependant ce n'est pas forcément nécessaire car alors
cette tolérance doit pouvoir correspondre à une surface fermée (même
avec des contours sommaires de faible résolution).

OSM a encore du boulot pour définir des règles permettant d'aider les
logiciels de rendu à placer (et aussi dimensionner) correctement tous
les labels, indépendamment des styles qu'on leur applique (couleurs,
transparence, police utilisée, effets de style comme des glyphes
détourés), tous ces styles étant propres aux moteurs de rendus (qui
peuvent ignorer le placement amélioré cependant en utilisant qu'un
point central).


Juste une idée "comme ça" :

Si on place dans la base un objet pour le label, il doit avoir une
géométrie (nœud, chemin, voire surface pour les tolérances de
placement même si ce n'est pas utile si le label est associé à une
relation de surface). Cette géométrie elle-même peut ne pas être
visible sur la carte (aucun trait ou point visible, seul le texte du
label apparaît au placement indiqué) ; c'est donc un objet séparé.

Si cet objet ne correspond pas à un objet réel possédant d'autres
attributs à visualiser, il devrait être marqué comme étant de
"type=label" afin d'indiquer justement de ne pas dessiner cette
géométrie (pas de trait, pas de remplissage de la zone de tolérance,
pas de hachurage, pas de symbole centré sur le nœud désigné comme
géométrie...) mais seulement le texte associé.

Une règle supplémentaire devrait être que cet objet de "type=label"
doit être associé au maximum à un et un seul autre objet de type
géométrique différent (un label de géométrie surface/multipolygone
peut être associé à un noeud ou un chemin, mais pas à une autre
surface/multipolygone; un label de géométrie nœud peut être associé à
un chemin ou une surface mais pas un nœud). Sinon ses attributs sont
redondants et doivent être remontés directement dans l'objet réel qui
le référence (sauf le "type=label").

Un label objet de "type=label" ne devrait pas exister seul, sinon
c'est qu'il doit être d'un autre type plus descriptif (dans ce cas on
enlève son attribut "type=label" mais il faut indiquer le genre
d'objet qu'il désigne, avec d'autres attributs géographiques).

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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Hélène PETIT 

Le 31/01/2012 13:37, Matthias Dietrich a écrit :

Les sous-entendus passent très mal par email et je n'ai pas compris ce
que tu as voulu dire.


dont acte.

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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Christian Quest 
"label" ne devrait-il pas définir que la position à utiliser de
préférence par le moteur de rendu et pas le nom (le libellé) en lui
même sauf si il devait être différent du "name" qui se trouve dans la
relation parente ?

Ca ne vous semble pas plus logique vu comme ça ?

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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Philippe Verdy 
Le 31 janvier 2012 13:37, Matthias Dietrich  a écrit :
> Pour clore ce hors-sujet, ce n'était pas là la question. J'ai compris
> dans ta tournure de phrase  que Mapnik n'était pas configurable ou que
> sa configuration était figée, non modifiable. Il n'était pas question
> de "qui développe un  logiciel", mais des possibilités de
> configuration de celui-ci et du fait qu'à partir du même moteur de
> rendu on peut obtenir des résultats différents.

En la matière je trouve que MapQuest s'en tire beaucoup mieux que
Mapnik pour produire des tuiles lisibles à partir des mêmes données
OSM (cependant il n'est pas impossible que MapQuest contienne aussi un
jeu de règles propre à lui (y compris pays par pays, et selon le
niveau de zoom/échelle) et ses propres données complémentaires pour
optimiser le placement des labels, en plus de ses règles de sélection
de données.

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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Matthias Dietrich 
Le 31 janvier 2012 13:06, Hélène PETIT  a écrit :

> Inutile de le prendre sur ce ton.
> Il te suffit de prendre en compte que absolument tout le monde sur cette
> liste sait que les logiciels sont écrit par des gens.
> Et que donc les tournures de phrases qui ont l'air de personnaliser ces
> logiciels ne peuvent pas relever d'autre chose que du sens figuré
> humoristique.
> Quand même.

Pour clore ce hors-sujet, ce n'était pas là la question. J'ai compris
dans ta tournure de phrase  que Mapnik n'était pas configurable ou que
sa configuration était figée, non modifiable. Il n'était pas question
de "qui développe un  logiciel", mais des possibilités de
configuration de celui-ci et du fait qu'à partir du même moteur de
rendu on peut obtenir des résultats différents.
Les sous-entendus passent très mal par email et je n'ai pas compris ce
que tu as voulu dire.

Matthias

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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Philippe Verdy 
amenity=townhall désigne un bâtiment. Il peut y en avoir plusieurs
dans une même ville (mairies annexes par exemple, mairies
d'arrondissement). C'est plus l'indication du service rendu dans ce
lieu.

admin_center sert à positionner (et nommer) le chef-lieu/la capitale
(le nom d'une ville pour tous les niveaux administratifs plus grands
que la commune/ville), et diffère donc aussi du nom du ou des niveaux
qui référence cet admin_center (souvent partagé par plusieurs niveaux
différents).

On pourrait admettre que l'admin_center seul suffit, et le label reste
optionnel, mais la position de l'admin_center (la ville
chef-lieu/capitale) se prête mal à positionner aussi le label du
niveau supérieur. Hors si on souhaite afficher les deux (les noms des
niveaux administratifs et de la ville), un moteur de rendu n'aurait
plus d'autre choix que de déterminer une autre position pour les
niveaux administratifs contenant la ville; s'il utilise un centroïde
calculé, il risque souvent de la placer hors de la partie interne de
la zone, quand celle-ci est fortement concave ou contient plusieurs
parties exclavées ou des enclaves à exclure.

Le label ne doit donc servir que dans ces cas-là: zones plus grandes
que la ville) fortement concaves ou ayant plusieurs exclaves ou
enclaves (plus d'un contourfermé pour sa frontière). Maintenant c'est
vrai que la question se pose où renseigner le/les noms. Comme le label
est exceptionnel, le pense qu'il vaut mieux renseigner (et traduire)
la zone plutôt que le label qui sert surtout à régler des problèmes de
placement. Mais dans le doûte (selon les moteurs) on se retrouve à
renseigner les deux car on ne sait pas où le nom sera pris: il semble
que si le noeud label est reconnu et utilisé, c'est son nom (ou sa
traduction) et non celui de la relation de frontière qui sera utilisé.

Mais ce n'est pas inutile qu'il place et nomme l'admin_center, et
affiche en plus les autres nœuds avec amenity=townhall (nœuds qui
peuvent sembler à priori inutiles si on a déjà un admin_center au même
endroit dont le nom donne le nom de la ville, mais pas explicitement
le nom "Hôtel de Ville" (ou une autre désignation locale comme "Mairie
annexe", différente du nom de la ville elle-même donné dans le nœud
admin_center; sachant que ces différences de noms justifient alors
qu'on ne puisse pas utiliser un noeud amenity_townhall comme
admin_center de la ville ou de tout autre zone administrative mère
contenant la ville).

Personnellement je trouve dommage qu'un moteur affiche les deux: le
nom de la relation et celui du label.

Il peut toujours utiliser le nom de la relation en revanche sur la
frontière, faute de mieux (mais là aussi je trouve dommage que les
segments de chemins le long de la frontière soient nommés en reprenant
toutes les relations qui les utilise: il serait plus utile de
n'afficher que le nom du segment de chemin, indépendamment des
relations, pratiquement toujours multiples, qui référencent ce même
chemin).


Le 31 janvier 2012 11:30, Jean-Guilhem Cailton  a écrit :
> Le 31/01/2012 11:05, Christian Quest a écrit :
>
> Le 31 janvier 2012 10:44, sly (sylvain letuffe)  a écrit
> :
>>
>> Le mardi 31 janvier 2012 10:24:36, Hélène PETIT a écrit :
>> > Donc, dans une relation "frontière administrative" y a-t-il une astuce
>> > pour gérer à la fois le rôle "label" et le rôle "admin-centre" ?
>> > Et le point "amenity=townhall" ? il fait pas triplette ?
>>
>> Je me pose régulièrement la question en ces termes :
>> Le rôle "label" est-il utile, son apparente bonne intention est elle
>> louable,
>> est-ce utilisé quelque part et ne pourrait-on faire autrement ?
>>
>> Autant le dire tout de suite, je n'ai pas la réponse !
>
>
>
> Si j'ai bien compris, ce "label" sert (ou pas) au moteur de rendu pour
> positionner le nom, mais à ma connaissance il n'affiche pas un nom en plus.
> Il y a:
> - un nom affiché pour le multipolygone "type=boundary"
> - un nom affiché pour le "place=*"
>
> A part faire remonter le "place" dans la relation (idée bizarre, j'avoue),
> je ne vois pas comment éviter d'avoir 2 noms... sauf à revoir bien sûr les
> moteurs de rendu.
>
> Moi aussi ça m'embête ces deux noms...
> --
>
>
> Bonjour,
>
> Il me semble justement que c'était l'intention de la proposition
> (
> https://wiki.openstreetmap.org/wiki/Relations/Proposed/add_admin_centre_in_Relation:boundary
> )
> de permettre au moteur de rendu de faire le lien entre la frontière et le
> centre, pour éviter d'afficher deux fois le nom, et même de permettre un
> placement souple pour la cartographie grâce au label (dans les cas de
> configuration particulière, j'imagine).
>
> Si on peut bientôt avoir des styles de rendu plus accessibles et flexibles,
> ce sera sans doute une des choses qu'il sera intéressant de prendre en
> compte.
>
> Cordialement,
>
> Jean-Guilhem
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Hélène PETIT 

Le 31/01/2012 12:49, Matthias Dietrich a écrit :

Je ne remets pas en cause tes connaissances, pour la bonne et simple
raison que je n'en ai aucune idée.
Les abonnés à cette liste n'ont pas en tête les CV de tous les participants.


Inutile de le prendre sur ce ton.
Il te suffit de prendre en compte que absolument tout le monde sur cette 
liste sait que les logiciels sont écrit par des gens.
Et que donc les tournures de phrases qui ont l'air de personnaliser ces 
logiciels ne peuvent pas relever d'autre chose que du sens figuré 
humoristique.

Quand même.



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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Matthias Dietrich 
Le 31 janvier 2012 12:09, Hélène PETIT  a écrit :
> Le 31/01/2012 11:12, Matthias Dietrich a écrit :
>
>> Pas complètement quand même, et heureusement ;-) Le moteur de rendu
>> fait ce qu'on lui dit de faire.
>
> Remplacer la responsabilité du "moteur-de-rendu" par la responsabilité de
> "on" est assez savoureux, et je te remercie de l'avoir fait.
>
>
>> Il se trouve que la feuille de style utilisée sur openstreetmap.org
>> demande l'affichage des deux.
>
> La feuille de style "fait ce qu'on lui dit de faire", non ?
>
>
>> Ce n'est pas une obligation.
>
> Pour cette feuille de style-là, en suivant ta logique, j'aurai tendance à
> dire que si ...
>
> Nous vivons une époque moderne,
> et j'ai un lourd passé de développeur, bien placée donc pour savoir que les
> programmes ne naissent pas dans les choux.
>

Inutile de le prendre sur ce ton. Ta réponse laissait supposer qu'il
n'y avait aucun contrôle sur le moteur de rendu ("le moteur de rendu
fait ce qu'il veut"). Le "on", c'est justement pour signaler que
chacun est libre de configurer Mapnik pour lui faire afficher ce qu'il
souhaite.
Et concernant la feuille de style utilisée sur openstreetmap.org, il
n'est pas interdit de demander des modifications.

Je ne remets pas en cause tes connaissances, pour la bonne et simple
raison que je n'en ai aucune idée.
Les abonnés à cette liste n'ont pas en tête les CV de tous les participants.


Matthias

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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Hélène PETIT 

Le 31/01/2012 11:47, Pieren a écrit :

Le problème du double affichage n'est pas particulier à la France (un
pour le node place, un pour la relation boundary=administrative).


Je suis revenue sur cette question du double affichage, un peu aussi 
pour des raisons de com :
Quand je présente OSM à des gens qui le découvrent, la première chose 
qu'ils demandent, c'est à voir leur patelin ; et la deuxième chose 
qu'ils disent c'est "pourquoi c'est écrit eux fois ?"
Bon, avec peu d'astuce, hop, on ne reste pas là-dessus ; quand même, ça 
laisse une petite trace.


Je crois que nous avons intérêt à accélérer la solution de ce petit bug, 
qui se voit comme le nez au milieu de la figure pour le grand public 
(les techs s'en fichent complètement, je l'ai vérifié).


Hélène




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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Hélène PETIT 

Le 31/01/2012 11:12, Matthias Dietrich a écrit :

Pas complètement quand même, et heureusement ;-) Le moteur de rendu
fait ce qu'on lui dit de faire.
Remplacer la responsabilité du "moteur-de-rendu" par la responsabilité 
de "on" est assez savoureux, et je te remercie de l'avoir fait.



Il se trouve que la feuille de style utilisée sur openstreetmap.org
demande l'affichage des deux.

La feuille de style "fait ce qu'on lui dit de faire", non ?


Ce n'est pas une obligation.
Pour cette feuille de style-là, en suivant ta logique, j'aurai tendance 
à dire que si ...


Nous vivons une époque moderne,
et j'ai un lourd passé de développeur, bien placée donc pour savoir que 
les programmes ne naissent pas dans les choux.



Sans rancune,
Hélène




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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Pieren 
2012/1/31 Jean-Guilhem Cailton :

> Il me semble justement que c'était l'intention de la proposition
> (
> https://wiki.openstreetmap.org/wiki/Relations/Proposed/add_admin_centre_in_Relation:boundary
> )
> de permettre au moteur de rendu de faire le lien entre la frontière et le
> centre, pour éviter d'afficher deux fois le nom, et même de permettre un
> placement souple pour la cartographie grâce au label (dans les cas de
> configuration particulière, j'imagine).

Hehe, ça ne nous rajeunit pas. L'idée, c'était surtout de définir le
lien entre une limite administrative et son entité représentative,
quel que soit le niveau. Ca permet aussi de supprimer le tag
"capital".
Bien sûr, on pourrait optimiser Mapnik pour n'afficher qu'une seule
fois le nom si le node "place" et l' "admin_centre" sont identiques.
Y'a plus ka.
Le problème du double affichage n'est pas particulier à la France (un
pour le node place, un pour la relation boundary=administrative). On
peut le résoudre plus facilement avec le role admin_centre mais je ne
sais pas si ce rôle est très utilisé à l'étranger (aucune stat
n'existe sur les roles de relations).
Le role 'label' a été ajouté durant la phase de discussion publique.
Mais à ma connaissance, aucun de ces 2 roles n'est exploité par un
logiciel actuellement (ni vérifié).

Pieren

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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Jean-Guilhem Cailton 
Le 31/01/2012 11:05, Christian Quest a écrit :
> Le 31 janvier 2012 10:44, sly (sylvain letuffe)  > a écrit :
>
> Le mardi 31 janvier 2012 10:24:36, Hélène PETIT a écrit :
> > Donc, dans une relation "frontière administrative" y a-t-il une
> astuce
> > pour gérer à la fois le rôle "label" et le rôle "admin-centre" ?
> > Et le point "amenity=townhall" ? il fait pas triplette ?
>
> Je me pose régulièrement la question en ces termes :
> Le rôle "label" est-il utile, son apparente bonne intention est
> elle louable,
> est-ce utilisé quelque part et ne pourrait-on faire autrement ?
>
> Autant le dire tout de suite, je n'ai pas la réponse !
>
>
>
> Si j'ai bien compris, ce "label" sert (ou pas) au moteur de rendu pour
> positionner le nom, mais à ma connaissance il n'affiche pas un nom en
> plus.
> Il y a:
> - un nom affiché pour le multipolygone "type=boundary"
> - un nom affiché pour le "place=*"
>
> A part faire remonter le "place" dans la relation (idée bizarre,
> j'avoue), je ne vois pas comment éviter d'avoir 2 noms... sauf à
> revoir bien sûr les moteurs de rendu.
>
> Moi aussi ça m'embête ces deux noms...
> -- 

Bonjour,

Il me semble justement que c'était l'intention de la proposition
(
https://wiki.openstreetmap.org/wiki/Relations/Proposed/add_admin_centre_in_Relation:boundary
)
de permettre au moteur de rendu de faire le lien entre la frontière et
le centre, pour éviter d'afficher deux fois le nom, et même de permettre
un placement souple pour la cartographie grâce au label (dans les cas de
configuration particulière, j'imagine).

Si on peut bientôt avoir des styles de rendu plus accessibles et
flexibles, ce sera sans doute une des choses qu'il sera intéressant de
prendre en compte.

Cordialement,

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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet sly (sylvain letuffe) 
Le mardi 31 janvier 2012 11:05:49, Christian Quest a écrit :
> Si j'ai bien compris, ce "label" sert (ou pas) au moteur de rendu 

Pour l'instant, c'est "ou pas" il me semble, mais peut-être que des rendus non 
connus l'utilise

> pour
> positionner le nom, mais à ma connaissance il n'affiche pas un nom en plus.
> Il y a:
> - un nom affiché pour le multipolygone "type=boundary"
> - un nom affiché pour le "place=*"
> 
> A part faire remonter le "place" dans la relation (idée bizarre, j'avoue),
> je ne vois pas comment éviter d'avoir 2 noms... sauf à revoir bien sûr les
> moteurs de rendu.

Il y a la proposition du role admin_centre qui a pour but de "faire remonter 
dans la relation"

Mais la question du double nom entre la relation administrative et le tag 
place est pour moi un faux problème.

Je continue de dire qu'il s'agit de deux noms pour deux choses différentes, 
donc normal. Coïncidence, en France, les communes portent souvent le nom de 
leur chef lieu (mais ce n'est pas tout le temps le cas)

Mon questionnement a moi se situe plutôt au niveau du role=label et de son 
utilité.

Option 1) : ça ne mange pas de pain, autant le mettre, s'en serviront ceux qui 
le veulent
Option 2) : ne pas le mettre et laisser ce qui le veulent se creuser la tête 
pour le déterminer automatiquement


-- 
sly (sylvain letuffe)

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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Matthias Dietrich 
Le 31 janvier 2012 10:24, Hélène PETIT  a écrit :
> mais on a aussi un admin-centre ; c'est un place=* qui est affiché aussi ;
> tout le monde se demande pourquoi le nom des communes est écrit deux fois à
> certains zooms, et une fois à d'autre, et la réponse est : le moteur de
> rendu fait ce qu'il veut, comme il veut, et il écrit une fois le nom de la
> relation, et l'autre fois le nom du point place=*

Pas complètement quand même, et heureusement ;-) Le moteur de rendu
fait ce qu'on lui dit de faire.
Il se trouve que la feuille de style utilisée sur openstreetmap.org
demande l'affichage des deux.
Ce n'est pas une obligation.

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

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet Christian Quest 
Le 31 janvier 2012 10:44, sly (sylvain letuffe)  a écrit
:

> Le mardi 31 janvier 2012 10:24:36, Hélène PETIT a écrit :
> > Donc, dans une relation "frontière administrative" y a-t-il une astuce
> > pour gérer à la fois le rôle "label" et le rôle "admin-centre" ?
> > Et le point "amenity=townhall" ? il fait pas triplette ?
>
> Je me pose régulièrement la question en ces termes :
> Le rôle "label" est-il utile, son apparente bonne intention est elle
> louable,
> est-ce utilisé quelque part et ne pourrait-on faire autrement ?
>
> Autant le dire tout de suite, je n'ai pas la réponse !



Si j'ai bien compris, ce "label" sert (ou pas) au moteur de rendu pour
positionner le nom, mais à ma connaissance il n'affiche pas un nom en plus.
Il y a:
- un nom affiché pour le multipolygone "type=boundary"
- un nom affiché pour le "place=*"

A part faire remonter le "place" dans la relation (idée bizarre, j'avoue),
je ne vois pas comment éviter d'avoir 2 noms... sauf à revoir bien sûr les
moteurs de rendu.

Moi aussi ça m'embête ces deux noms...
-- 
Christian Quest - OpenStreetMap France -
http://openstreetmap.fr/u/cquest
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] role=label

2012-01-31 Par sujet sly (sylvain letuffe) 
Le mardi 31 janvier 2012 10:24:36, Hélène PETIT a écrit :
> Donc, dans une relation "frontière administrative" y a-t-il une astuce
> pour gérer à la fois le rôle "label" et le rôle "admin-centre" ?
> Et le point "amenity=townhall" ? il fait pas triplette ?

Je me pose régulièrement la question en ces termes :
Le rôle "label" est-il utile, son apparente bonne intention est elle louable, 
est-ce utilisé quelque part et ne pourrait-on faire autrement ?

Autant le dire tout de suite, je n'ai pas la réponse !


-- 
sly (sylvain letuffe)

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