Cela dit, pour le cas (strict des édifices du culte catholique romain) ça serait un projet très intéressant pour OSM de pouvoir distinguer les édifices du culte catholique orientés ou pas (en tous cas pour la France), à condition que l’histoire de l’édifice soit renseignée… > Le 25 avr. 2016 à 22:09, ades_...@orange.fr a écrit : > > Ce ne serait pas mal de ne pas utiliser le terme « orienter » à propos > d’église. Une église « orientée » possède strictement son choeur à l’est ! > Dans les autres cas, bin… elle n’est pas orientée… et pour la décrire, l’on > parle de façade avant au lieu de façade ouest, etc. > Donc avant de mettre (pas orienter ;-) ) un symbole sur un édifice religieux > dans un certain sens il faudrait savoir quel est l’axe de cet édifice, et ça… > je ne vois pas où OSM l’info peut-être mise dans OSM. Sauf à indiquer > précisément la position du choeur, et encore… Pour les mosquées et les > synagogues, je ne connais pas assez (il n’y en a que peu dans le patrimoine > fr), mais je crains que ce ne soit le même problème, quel est le gisement du > mihrab dans les mosquées ? peut-on le vérifier ? Quel angle donner au symbole > en fonction de la latitude ? Et ça vaut aussi pour les églises… combien > d’églises ne sont pas orientées ? Beaucoup ! Faudrait faire du > ‘micro-mapping’ et être capable pour chaque édifice religieux de lui donner > un axe, bonjour les querelles théologiques et surtout les erreurs de la part > des contributeurs, en général de bonne foi, mais bon … ;-) > Donc, le symbole dans le sens de lecture de la carte me va très bien. ;-) > > >> Le 25 avr. 2016 à 14:13, Philippe Verdy <verd...@wanadoo.fr >> <mailto:verd...@wanadoo.fr>> a écrit : >> >> Le 25 avril 2016 à 11:46, Jean-Marc Liotier <j...@liotier.org >> <mailto:j...@liotier.org>> a écrit : >> On 25/04/2016 00:46, Philippe Verdy wrote: >> Si on veut faire une carte ayant ces types d'ajustements spécifiques, il >> faut une base de données complémentaire, spécifique au rendu à faire, hors >> OSM (c'est ce que fait MapQuest pour placer plus judicieusement certains >> libellés importants ou les sélectionner selon des critères qu'ils >> considèrent plus pertinents, notamment pour les faibles niveaux de zoom, >> afin de les placer en priorité avant tout le reste issu d'OSM et qui sera >> placé de façon automatisée s'il reste de la place). >> >> Intéressante cette manière de maintenir les ajustements spécifiques... C'est >> mieux que le post-traitement manuel à chaque nouvelle publication - >> j'imagine une table avec des identifiants d'objets OSM et pour chacun >> d'entre eux une orientation et une position... Il y a de la documentation >> publique décrivant l'outillage de Mapquest ? >> >> Non ce n'est pas dopcumenté mais ces ajustements sont stables quand les >> données OSM bougent... jusqu'à ce qu'un objet soit supprimé et recréé (mais >> MapQuest semble maintenant détecter ça aussi en faisant des rapprochements >> quand l'ID a changé, ou alors il y a un adminsitrateur qui suit les objets >> modifiés manuellement par Mapquest et qui sont supprimés d'OSM pour voir >> s'il faut les garder encore ou reprendre un nouvel objet. >> Mapquest ne fait pas que ça car il arrive aussi à garder des versions >> anciennes d'objets quand ils sont supprimés ou cassés par erreur dans OSM. >> Je ne vois pas comment ils peuvent faire ça sans une base annexe contenant >> des tags supplémentaires bien à eux, dont certains spécifiques à chaque >> niveau de zoom pour leur rendu. Mais c'est efficace par exemple pour >> positionner les noms de baies, orienter les bras de mer, déplacer de façon >> plus appropriée des noms de pays; ils ajoutent aussi par endroit des >> libellés très décalés avec des filets pour désigner les zones. Ils ont aussi >> des noms d'objets bien à eux (différents de ceux d'OSM), et reconnaissent >> plus d'alias/synonymes que ceux trouvés dans OSM. >> Il semblerait aussi qu'ils soient capables aussi de dessiner des frontières >> politiques de pays selon le pays d'origine du visiteur (en cas de conflit >> territorial). ils se sont adaptés aux demandes de leurs clients payants. >> >> Je n'ai pas vu s'ils mettaient ce code de gestion de données spécifiques en >> open-source ni aucune doc concernant les crtères de rapprochement utilisés. >> >> Mais l'idée d'utiliser une base annexe n'est pas nouvelle, OSM le suggère >> lui-même dans ses propres docs. Tout n'a pas vocation à être dans OSM, à >> commencer par les tags pour le rendu, mais il n'empêche qu'il faut bien les >> stocker quelque part et qu'il n'est pas question que les employés de >> Mapquest passent leur temps à sans arrêt rééditer manuellement les mêmes >> ajustements pour fixer des priorités d'affichage, des orientations, des >> tailles de polices, des icônes alternatives, etc. ou pouvoir afficher des >> données statistiques liées à d'autres bases de données (plus à jour que les >> données dans OSM et à peu près cohérente en terme de date et de complétude). >> >> _______________________________________________ >> 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
