<div dir="ltr">C'est là que je pense qu'il aurait mieux valu que les serveurs de tuiles sachent faire une combinaison des images acoolées, par un algo relativement simple de filtrage, superposant deux images orthorectifiées polygonales su un fond fond, en conservant le contraste maximum des deux images asemblées.<div><br></div><div>Là ça affiche un morceau d'une image ou un morceau de l'autre selon la position du point central qui varie quand on zoome, et même bouge quand on glisse la carte à l'écran... ce n'est franchement pas pratique.</div><div>La superposition aurait fait apparaitre des traits en double par endroit (sans conflation, mais on se serait arrangé pour faire une conflation visuelle).</div><div><br></div><div>En comparaison le cadastre espagnol lui fournit des images précombinées (sans tenir compte des limites des planches qui ne conicident pas avec les limites des tuiles) et n'a pas besoin qu'on fixe une commune particulière, et c'est nettement plus facile à utiliser</div><div><br></div><div>Et ça évite aussi qu'on traailel sur les données d'une seule commune sans tenir compte de la commune voisine quand la conflation n'a pas réellement eu lieu: visuellement là aussi une conflation manuelle suffit et les espagnols ne sont pas non plus tombés dans le piège des imports automatiques qui en France ont déjà produit des doublons un peu partout, ou donné lieu à des modifications incohérentes dans le sens d'une commune ou dans le sens de sa voisine...</div><div><br></div><div>...alors qu'en terme de précision réelle il n'y a pas de différence significative entre une planche ou l'autre et que la conflation manuelle permet aussi de s'accorder avec d'autres sources, et notamment une imagerie aérienne, afin d'obtenir une carte géométriquement cohérente avec les proportions relatives et orientations localement respectées:</div><div><br></div><div>Dans tous les cas on reste dans les marges d'erreurs de chacune des sources utilisées, et la comparaison des sources avec une conflation visuelle manuelle permet même d'obtenir des données en fin de compte plus précises que chacune des sources originales prises individuellement: ceci est un réel bonus que permet OSM, où justement on demande un travail de préparation et de fusion et non un import brut: toutes les sources qu'on utilise ont de toute façon des marges d'approximation et notre travail est justement de les apprécier car on s'appuie sur plus de données ainsi que sur l'expérience de terrain, où les sources officielles disponibles ne seront pas à jour avant longtemps.</div><div><br></div><div>Je ne critique pas ici les sources du fait de ce qu'ont y trouve pas, elles ont chacune leurs limites, elles sont utiles pour avoir cependant des vues assez détaillées et les plus exhaustives possibles, mais on doit tenir compte du fait que les imprécisions sont un état de fait, d'autant plus que la montée en précision ne se fait pas du jour au lendemain et reste un patient travail qui restera toujours à réviser plus tard. On a voulu un OSM précis au plan local pour y mettre des tas dedonénes que pleins de sources ne cherchent pas à codifier, c'est à nous de trouver de la cohérence, aucune source n'a une géométrie absolue (hormi les rares points de référence géodésiques, qui cependant eux aussi feront l'objet de révisions quelques 10 ou 20 ans plus tard, dans le cadre d'un nouveau schéma de triangulation et de nouvelles méthodes de calcul).</div><div><br></div><div>Je pense même qu'OSM peut aussi aider chacune des sources à trouver les points de désaccord car on fournit d'autres points identifiables qui peuvent servir à ces sources pour réviser leurs propres données. Elles ne sont pas obligées non plus de reprendre nos données à la lettre, cahcun apprécie en fonction des données qu'il a à gérer et de ses besoins (d'autant plus que nous non plus on n'a pas accès à tout ce que peuvent utiliser les collectivités en dehors de ce qui est dans le cadastre public: on ne voit pas des tas de plans récents liés au travaux de terrain des géomètres et aux plans de marchés publics on n'a pas le détail des permis de construire, pas les études d'architectes, pas non plus des tas d'études géologiques ni les relevés internes des exploitants de réseaux: chacun fait de son mieux avec les données qu'il a et tout le monde s'adapte progressivement)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 12 octobre 2016 à 16:43, Tyndare <span dir="ltr"><<a href="mailto:tyndare@wanadoo.fr" target="_blank">tyndare@wanadoo.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
iD et JOSM n'utilisent pas la même source de donnée pour déterminer la liste des images disponibles par défaut selon la région affichée mais j'ai l'impression que la définition pour les tuiles du cadastre utilisent pourtant bien le même serveur TMS:<br>
<a href="http://tms.cadastre.openstreetmap.fr/*/tout/%7Bzoom%7D/%7Bx%7D/%7By%7D.png" rel="noreferrer" target="_blank">http://tms.cadastre.openstreet<wbr>map.fr/*/tout/{zoom}/{x}/{y}.<wbr>png</a><br>
<br>
Comme expliqué à l'origine par Frédéric Rodrigo, pour éviter les problèmes de saut aux frontières, il est possible de n'afficher les tuiles que d'une seule commune en particulier en spécifiant dans l'éditeur un serveur personnalisé qui utilise l'URL précédant dans lequel on remplace le * par le code INSEE de la commune voulue:<br>
<br>
<a href="https://lists.openstreetmap.org/pipermail/talk-fr/2015-February/075223.html" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/pipermail/talk-fr/2015-Febru<wbr>ary/075223.html</a><br>
<br>
Je crois que la configuration par défaut pour JOSM est définie ici:<br>
<a href="https://josm.openstreetmap.de/wiki/Maps/France#Cadastre" rel="noreferrer" target="_blank">https://josm.openstreetmap.de/<wbr>wiki/Maps/France#Cadastre</a><br>
<br>
et que celle pour iD est définie ici:<br>
<a href="https://github.com/osmlab/editor-layer-index/blob/gh-pages/sources/europe/fr/FR-Cadastre.geojson" rel="noreferrer" target="_blank">https://github.com/osmlab/edit<wbr>or-layer-index/blob/gh-pages/<wbr>sources/europe/fr/FR-Cadastre.<wbr>geojson</a><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On 12/10/2016 12:01, David Marchal wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Bonjour à tous.<br>
<br>
Question idiote : pourquoi l'affichage du cadastre est-il aussi propre sur iD, alors que, sur jOSM, il est tout moche : noms tronqués, tracé de limites sautant sans arrêt… L'affichage d'iD n'est pas irréprochable, mais il me semble bien meilleur que celui de jOSM, alors pourquoi ne pas utiliser le même serveur de tuiles ?<br>
<br>
Dans l'attente de vos lumières,<br>
<br>
Cordialement.<br>
______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk-fr</a><br>
<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br></div>