Je note aussi qu'à cet endroit la conflation des frontières communales entre les sources cadastrales n'a pas eu lieu: une frontière indiquée par une seule des communes a été utilisée arbitrairement, au lieu de prendre un chemin moyen "estimé".
L'estimation moyenne est meilleure qu'un choix arbitraire selon une seule commune, à défaut d'une conflation "réglementaire" dans une mise à jour cadastrale tenant compte des ajustements et négos intercommunales pour revoir leur triangulation géodésique et mettre d'accord les éventuels occupants du terrain et le régime fiscal applicable (qui peuvent le contester devant un tribunal administratif qui aura le dernier mot si les communes ne s'accordent pas et le préfet local n'a pas pris un arrêté pour leur imposer le règlement du litige frontalier). Cette remarque vaut pour beaucoup de communes au moment où on a tracé leurs frontières, certains n'ont pas pris la peine de charger les planches cadastrales des communes voisines pour voir les désaccords (et la couche cadastre du WMS fait les assemblages de carreaux de façon instable, en prenant un peu au pif les carreaux d'une des communes au lieu de les superposer, on ne voit pas la même chose selon le niveau de zoom, de plus selon le nivbeau de zoom utilisé la précision géométrique varie avec plus ou moins de points de référence! Il faut donc tracer au niveau de zoom le plus élevé pour avoir plus de points, puis regarder et comparer les zones de conflit en variant le zoom, ou bien charger séparément les deux planches de chaque commune quand l'assemblage ne se fait pas bien). Si on compare à d'autres pays voisins, la couche cadastrale française aurait mieux fait de faire des superpositions pour montrer ces zones sans conflation "officielle" et non choisir des carreaux de façon arbitraire d'une commune à l'autre selon un point de référence unique dans le carreau. Et ne pas oublier qu'en fin de compte c'est le terrain qui prime, même si la triangulation sur les planches cadastrales montre des défaut: il y a des éléments physiques communs aux deux planches, on peut les repérer sur l'imagerie pour réaligner le tout. C'est bien dommage que les communes à l'occasion de leur vectorisation n'aient pas opté pour rétablir la précision de leurs planches selon les repères géodésiques en place et les limites réelles de propriétés ou de routes mesurées sur le terrain quand elles sont observables avec précision. On peut comprendre qu'elles ne l'ont pas fait au temps des planches dessinées à la main par les géomètres, puis numérisées en l'état en bitmap. Revoir une triangulation et redessiner ces planches demandait trop de travail, un travail plus facile à faire avec précision avec un format numérique vectorisé, et que l'IGN peut leur faire de façon exacte sans tout déformer et changer les proportions, angles et surfaces mesurées avec trop d'écarts. Aujourd'hui il y a des outils automatiques qui peuvent orthorectifier à très bas coût leurs anciennes planches (même celles en bitmap si cela conserve la lisibilité des libellés et symboles quand la numérisation en bitmap est faite avec une résolution suffisante), mais ils ne peuvent pas mettre d'accord des communes qui ont mis dans leurs planches des éléments contestés par la commune voisine, ni les occupants qui depuis longtemps se croyait dans une commune (ce genre de conflit devrait être limité maintenant avec les récentes modifications de la fiscalité locale, mais de telles erreurs historiques devraient être signalées et enregistrées dans des annexes aux documents officiels de propriété ou consignés dans des arrêtés municipaux ou préfectoraux) et les remettre aux normes de triangulation actuelles et plus précises, avec un référentiel géodésique commun (bien qu'on ait encore des écarts, dus au changement de référentiel réglementaire, aux limites départementales des zones du vieux RGF sur le continent métropolitain, où l'IGN aurait du produire un effort pour les régler). Le jeu. 23 janv. 2020 à 19:19, Philippe Verdy <ver...@gmail.com> a écrit : > Bref ne surtout pas changer la frontière communale (vérifier le cadastre > pour détecter un éventuel déplacement indésiarable de frontière) et ignorer > le signalement > > Eventuellement, ajouter une note=* au noeud repère expliquant que ce n'est > pas une erreur, mais il vaut mieux créer une relation de site pour grouper > ce noeud avec les autres dans la "bonne" commune, comme ça l'outil de > vérification pourra vérifier lui-même que "l'anomalie" est normale tant que > les autres repères du site sont dans la "bonne" commune... à moins qu'ils > soient tous "hors commune" pour les "grands" sites de triangulation ou > d'alignement, mais que leur "centre" géographique au moins est bien sur la > commune indiquée par leur code) > > > Le jeu. 23 janv. 2020 à 18:51, leni <l...@ntymail.com> a écrit : > >> >> Le 23/01/2020 à 17:06, Frédéric Rodrigo a écrit : >> > Le 23/01/2020 à 16:59, marc marc a écrit : >> >> Le 23.01.20 à 16:44, leni a écrit : >> >>> Faudrait-il mieux déplacer la frontière dans osm ? >> >> elle a été déplacée par import_fr en 2013 sans aucune source >> renseignée, >> >> sans lien ou descriptif permettant de rafraichir la mémoire sur >> >> l'opération. la version précédente était proche du cadastre >> >> >> >> si tu la déplaces pour la mettre à l'endroit du cadastre, >> >> le repère reste du mauvais côté... du coup pourquoi pas... >> >> mais cela ne résoud pas le soucis. >> >> si l'ign a elle aussi le soucis, alors faut leur écrire.. >> Merci Marc >> > >> > >> > Des repères peuvent être du mauvais coté c'est normal. >> > >> > La commune est associé au site géodésique. La site à plusieurs >> > repères, certain peuvent être de l'autre coté. >> Merci Frédéric >> > >> > >> > >> > _______________________________________________ >> > 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
