Bien. On va essayer déjà de faire ça en français et faire une propos ensuite sur le wiki comme discussion en anglais mais on est déjà à un premier niveau de réflexion sur la liste.
A voir donc : - les besoins et les propositions possibles. - les équivalences - quel schéma est : - plus flexible et permet de traiter le plus de cas, - plus simple pour les contributeurs ou un outil permettant d'avoir quelque chose de semi-auto dixit opening_hours - comment éviter les concurrences Le 9 novembre 2015 18:16, Philippe Verdy <[email protected]> a écrit : > On commence par en discuter en cherchant les différentes solutions et > difficultés. Tout cela devrait être sur le wiki en vue d'une révision des > schémas de clé. > Mais comme d'habitude, les clés sont introduites expérimentalement par > quelques uns, et ensuite on discute de la façon de fusionner les > différentes idées. Après vient la question du nettoyage car on ne peut pas > tout garder dans les applis. > En attendant les clés non discutées, trop nombreuses, insuffisamment > réfléchies, polluent la base et n'ont d'intérêt qu'e de façon informative à > condition de chercher comment les interpréter humainement, on est loin de > pouvoir automatiser les traitements, mais là en plus on ne peuyt même pas > dire qu'il s'agit d'erreurs. Tout cela n'est qu'expérimental mais > malheureusement sans discussion ouverte. > Note: cette liste francophone ne suffit pas. D'une façon ou d'une autre il > faut rendre ça visible sur le wiki et tenter des traductions anglaises même > maladroites pour pouvoir en débattre au plan international. > Mais la difficulté se corse quand dans un pays donné il y a eu des imports > massifs avec des nouvelles clés ou codifications de valeurs choisies > indépendamment de tout ce qui se fait ailleurs et sans même chercher à > s'appuyer sur des normes connues (comme ici l'ISO 8601 ou les convetions > CLDR ou des nomenclatures internationales existantes, ou quand les clés > sont choisies de façon très paresseuse et entrent en conflit avec d'autres > parce qu'aucune recherche n'a été faite avant de les utiliser pour autre > chose) > > Le 9 novembre 2015 17:10, Jérôme Seigneuret <[email protected]> a > écrit : > >> >> >> Le 9 novembre 2015 16:58, Philippe Verdy <[email protected]> a écrit : >> >>> Le 9 novembre 2015 16:12, Jérôme Seigneuret <[email protected]> >>> a écrit : >>> >>>> C'est implémenté dans les langages. C'est le principe de passage forcé >>>> d'un centenaire avec deux caractères vers 4 caractères YYtoYYYY >>>> >>>> Donc C11 renvoi vers 1100-1199 (équivalent OSM 1100..1199) >>>> >>> >>> Ce qui est le **12e** siècle et pas le 11e ! Piège courant (aussi bien >>> en anglais qu'en français d'ailleurs). On est aujourd'hui au 21e siècle, >>> pas au 20e même si les deux premiers chiffres de l'année commencent par 20, >>> les siècles sont comptés à partir de 1, il n'y a pas de siècle zéro ! >>> >> >> En effet donc dans mon cas c'est C10 >> >>> >>> mais on peut aussi faire C1150 qui renvoi 1150-1249 >>>> (équivalent OSM 1150..1249) >>>> >>> >>> Encore plus "merdique", car C11 désigne un siècle (lequel??) mais C1150 >>> désigne une année de départ, quid alors du siècle débutant en année 11, il >>> faut l'écrire alors C0011 ? >>> >> >> Exact en tous cas c'est comme ça que le code le prévois >> >> >>> >>> Pour les préfixes c'est interne à OSM comme ~ et autres. Ca mérite à >>>> être simplifié ou à proposer des correspondances d'écritures >>>> >>>> Le but étant de gérer uniformément l'incertitude >>>> >>> >>> Oui pour que ce soit uniforme, mais alors réfléchir à quelquechose de >>> cohérent. Le message de départ donnait le 11è siècle, mais là tu as répondu >>> avec le 12è ! >>> >> Je suis d'accord merci pour cette correction >> >> >>> >>> Bref comme d'habitude, les tags sous OSM sont créés à la volée, on en >>> discute après et ensuite on essaye d'uniformiser et on sse rend compte que >>> tout le monde ne comprend pas le même langage. Le minimum serait de >>> documenter même les essais sur le wiki afin de pouvoir les critiquer et >>> ensuite trouver des solutions d'uniformisation et de migration, puis >>> réparer tout ça dans la base car à la longue ces tags multiples compliquent >>> les applications de tout le monde. >>> >>> Je ne dis pas le contraire. Mais mieux vaut le faire maintenant que >> quand ce sera déjà utilisé par 50000 contributeurs avec des méthodes >> différentes >> >> >>> Quitte à faire simple et non ambigu, il serait préférable de mentionner >>> un intervalle entre deux dates au format ISO8601 (année, année-mois, ou >>> année-mois-jour) et ne pas avoir à se soucier des unités. La première >>> réponse était plus simplet et au moins non ambigue le 11e siècle était >>> historic:century=11 >>> >> >> Oui mais finalement on sort du schéma pour créer une nouvelle clé... >> >> >>> Note, on a aussi besoin d'intervalles pour des périodes de construction >>> avec pour les deux bornes des intertitudes. L'usage pour les intervalles >>> c'est d'utiliser le signe " - " encadré d'espaces pour ne pas entrer en >>> conflit avec le "-" accollé sans espace entre les éléménts d'une date ISO >>> 8601. Il donc faut un autre séparateur pour les marges d'intertitude. >>> >>> Si on voulait préciser une construction s'étalant du 11e siècle au 15e, >>> cela donnerait "1001..1099 - 1401..1499". Si on peut dater plus précisément >>> une date, par exemple février 1492 pour la seconde borne au lieu du simple >>> 15e siècle, cela donnerait "1001..1099 - 1492-02" >>> >>> Je trouve ça plutôt intéressant >> >> >>> Mais si la construction s'est achevée encore plus précisément le 12 ou >>> le 13 février, cela donnerait "1001..1099 - 1492-02-12..1492-02-13" (les 4 >>> dates mentionnée sont toutes en format compatible ISO 8601 (lequel format >>> n'inclut aucune espace ni aucun point... mais admet qu'on puisse supprimer >>> les séparateurs "-" entre les composants année-mois-jour à condition de >>> mettre les années sur 4 chiffres minimum, donc autoriserait aussi qu'on >>> utilise pour nos intervalles: ""1001..1099 - 14920212..14920213"). >>> >> Moi ça me va >> >>> >>> Autre difficulté: les siècles avant Jesus-Christ (important pour dater >>> le patrimoine historique). Par convention on suit la date de "BC" en >>> anglais, toujours en fin de date donc après l'indication éventuelle du mois >>> et du jour, pas entre l'année et le mois. Mais là aussi on n'a alors pas >>> d'année "zéro" dans les calendriers, l'année qui précède l'année 0001 est >>> alors l'année 0001BC mais en notation astronomique cette année est désignée >>> "0000" et les années précédentes sont décalées de 1 par rapport aux année >>> calendaires, en utilisant un signe "-" avant l'année, donc "-0001" désigne >>> "0002BC". Les années après Jesus-Christ sont dans l'ère "AD" masi il n'est >>> pas utile de l'indiquer si on veut garder la compatibilité ISO 8601 des >>> dates d'aujourd'hui où aucun suffixe d'ère n'est nécessaire pour l'actuel >>> calendrier grégorien. >>> >> >> Bref, il y a du taf. On commence par quoi? >> >> > >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
