Arf, je corrige dès demain effectivement. Je pensais que l'avoir mis en
proposal suffisait. Hum l'objectif était de mettre les propositions de normage
pour les éléments dans la discussion et dans des sous parties de la propale. Je
delete du coup.
Le Dimanche 3 mai 2015 23h10, François Lacombe <[email protected]>
a écrit :
Bonsoir Pierre,
Il y a en effet encore quelques points qui n'ont pas encore de réponse, mais
nous pourrons surement les trouver collectivement.
Ce fil doit continuer à vivre.
Pour l'instant et tel qu'indiqué, ce que je propose ne solutionne pas la
question des multiples antennes sur un même point.
Il faut encore du temps pour y réfléchir.
Nous ne pouvons pas le voter en l'état, tout n'est pas complet, il y a encore
plein de cas à croiser.
Il faut en premier lieu faire des photos et donner des cas pratiques en fin de
document.
Ensuite, tout traduire en anglais, pour le diffuser au plus grand nombre (je
peux m'en charger sur une bonne partie, pour peu qu'on soit d'accord sur la
version française). Là encore, au fur et à mesure.
La page Key:antenna part surement d'un bon sentiment mais est mal nommée.
Ce genre de page sert à la documentation d'un tag, une fois acceptée ou bien
lorsque celui-ci est déjà largement utilisé (> 100k dans tag info).
Pour ce qui nous concerne, il faut aller dans la catégorie Proposed_features
avec une page comme celle-ci :
https://wiki.openstreetmap.org/wiki/Proposed_features/Antennas_cartography
C'est plutôt important, il y a des personnes qui sont plutôt directes sur
@tagging
Pour donner une idée, voici une proposition que je m’apprête à présenter au
vote, sa rédaction a demandé 1 an et demi (même si le RFC a démarré début
janvier, le document d'origine est apparu en 2013)
https://wiki.openstreetmap.org/wiki/Proposed_features/Power_supports_refinement
Dans notre cas, ce sera beaucoup plus court, ok, mais on doit encore prendre le
temps de la réflexion pour proposer quelque chose de complet.
Bonne soirée
François
François Lacombe
fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux
Le 3 mai 2015 22:50, dHuy Pierre <[email protected]> a écrit :
@Verdy: Je vois que ta maitrise de la langue française est presqu'aussi
impressionnante que tes connaissances en général aussi je t'invite à consulter
toute une série de sites pour ce qui est de la définition des différents mots
que j'utilise ou pourrais être amener à utiliser. Pour quelqu'un qui a une
réputation particulièrement mauvaise dans le monde des wikis et de la culture
libre, je trouve que tu as beaucoup de mal à maitriser les principes de base de
la dialectique.Autrement, je parlais de la formulation de ton "idée" (le terme
te parait suffisamment clair?), peux tu donner un exemple concret de ta
formulation json sur le wiki et ou sur le pad? Merci.
@Lacombe, j'ai mis sur le wiki entre temps, je t'invite à écrire desus. Je ne
comprends toujours pas comment tu comptes modéliser quand plusieurs antennes
occupe le même point exactement? Après je trouve que ça fait beaucoup d'info
mais ça sera aux utilisateurs d'osm de voter :)
@all: merci beaucoup à tous, la page wiki est ici:
https://wiki.openstreetmap.org/wiki/Key:antenna. Je n'aurais jamais réussi à
mettre ça sur pied sans vous. Je mets ça en proposition officielle cette
semaine et j'espère vous voir voter quand le vote officiel commencera! (je
reviendrai spammer la ML don't worry :) ) Merci encore à tous de votre aide et
bonne semaine! (Et remerciement particulier à Eric qui m'a permis de peaufiner
certains point sur le pad en live et à Lacombe pour ses idées que j'attends de
voir au vote :p )
@cquest: Merci isolé pour travailler à la libération des données ;)
Librement,
Le Dimanche 3 mai 2015 21h59, Philippe Verdy <[email protected]> a écrit :
Le 3 mai 2015 13:17, dHuy Pierre <[email protected]> a écrit :
@Verdy: N'ayant pas vocation d'un débat de sémantique, je te laisse débattre
sur le sexe des anges.
Je n'arrête pas de te répondre que je n'ai pas parlé de ça et encore moins des
anges.Tu as une conception étrange de la sémantique, qui consiste à l'inventer
pour lui faire tout dire.Arrête s'il te plait tes inventions et ne reprends que
ce que j'ai posté réellement, pas ce que tu crois avoir lu en le rapportant
ensuite aux autres, merci.J'ai été assez clair pour limiter la portée de ce que
j'ai dit et préciser mes intentions.
D'ailleurs mon message initial avait eu une réponse similaire d'un autre
utilisateur concernant l'usage des ; et des | et de leur interprétation ou
prétendue "standardisation" qui n'existe pas et est trompeuse. Si tu revien à
ce que j'ai écrit, j'ai précisé où était le problème dans la proposition
initiale de Jérome: le fait qu'il utilisation deux tags séparés en imposant un
ordre des valeurs dans un tag où d'évidence ce n'est quy'une liste non
ordonnée, pour l'aligner avec l'ordre des éléments dans un second tag séparé
(qui lui non plus n'a pas d'ordre, mais aligne ses éléments avec ceux du
premier tag).En terme de description des données c'est un problème puisque dans
OSM les tags ont vocation à être mainbtenus tous séparément.une première
solution était de rassembler dans le même tag les valeurs qui doivent rester
ensemble, mais alors ces valeurs ont un ordre intrinèque pour préciser quel
champ correspond à quielquechose.
On se retrouvait donc à mettre dans un même tag: le nom d'un opérateur, et la
liste (elle-même non ordonnée) des réseaux utilisés, et créer donc autant de
tags que d'opérateurs: compment les distinguer ? il faut une clé pour chaque
tag mais il n'y a rien d'évident autre qu'un suffixe numérique (mais qui a le
défaut d'imposer un ordre apparent par la valeur des indices numériques (qui
sont ici arbitraires), cependant c'est un soucis relativement mineur.Reste à
savoir comment représenter dans un même tag des champs de nature différente:
nom de l'opérateur et ses réseaux.Et là on n'a pas grand chose de stadnardisé
non plus dans OSM, et c'est à nous de l'inventer, sous une forme qui soit
cependant lisible et compacte. Ce qui est à représenter est un type de données
structuré (contenant plusieurs champs de nature différente).
Le seul usage significatif correspondant à ce cas est celui des "lanes" mais il
est très peu lisible. et malgré tout ce n'est pas encore une "norme" en tant
que tel.Si on parle de normes en usage pour les types structurés, il y en a
deux évidentes: XML et JSON; j'excluais tout de suite XML dont la syntaxe
verbeuses est trop lourde pour être utilisée dans la valeur d'un tag, il
restait donc seulement JSON mais qui a aussi une syntaxe un peu lourde, qu'on
peut alléger car on n'a pas besoin de distinguer les types (numérique, chaine)
des atomes et il est souhaitable alors de pouvoir s'abstenir des séparateurs de
chaines.
Mais je ne voulais pas, avant de proposer un autre système, en fait un truc
spécifique pour un seul tag, car des types structurés, demandant un parseur
spécifique pour les analyser, ajoute à la maintenance. µBref je ne me suis pas
contenté de proposer quelquechose concernant les seules antennes, mais pour en
parler de façon plus générale.C'était donc non pas une proposition formelle
mais une analyse d'un problème plus général de modélisation et codification des
données dans un domaine où il n'y a pour l'instant strictemetn rien de
standardisé.
Alors toi tu prends ça pour le sexe des anges si tu veux, mais ce n'est pas mon
propos et pas le sujet. C'est plus sérieux.
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
