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.

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.
La superposition aurait fait apparaitre des traits en double par endroit
(sans conflation, mais on se serait arrangé pour faire une conflation
visuelle).

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

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...

...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:

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.

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).

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)


Le 12 octobre 2016 à 16:43, Tyndare <tynd...@wanadoo.fr> a écrit :

>
> 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:
> http://tms.cadastre.openstreetmap.fr/*/tout/{zoom}/{x}/{y}.png
>
> 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:
>
> https://lists.openstreetmap.org/pipermail/talk-fr/2015-Febru
> ary/075223.html
>
> Je crois que la configuration par défaut pour JOSM est définie ici:
> https://josm.openstreetmap.de/wiki/Maps/France#Cadastre
>
> et que celle pour iD est définie ici:
> https://github.com/osmlab/editor-layer-index/blob/gh-pages/
> sources/europe/fr/FR-Cadastre.geojson
>
>
>
>
> On 12/10/2016 12:01, David Marchal wrote:
>
>> Bonjour à tous.
>>
>> 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 ?
>>
>> Dans l'attente de vos lumières,
>>
>> Cordialement.
>> _______________________________________________
>> Talk-fr mailing list
>> 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
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Répondre à