MajiCad, le Rétablissement, et le Calcul en bloc:
Par MajiCad le mardi, avril 17 2012, 13:56 - Lien permanent
Comme vous l'avez peut-être constaté, MajiCad est équipé d'une palette d'outils dite de Calcul en bloc.
Elle sert à piloter de façon interactive le module de calcul PCB2D qui permet, le géoréférencement d'un ensemble de feuilles de plan à partir de quelques points d'appuis et de liaisons de feuille à feuille.
Tour d'abord, une remarque sur ce type de calcul issu de la photogrammétrie:
La méthode de calcul consiste à rendre minimum la somme des carrés des écarts résiduels sur les appuis. Les paramètres ainsi obtenus correspondent à des transformations conformes ou dites de Helmert.
Dans un milieu précis comme la photogrammétrie tout écart sortant des tolérances correspond généralement à une faute. On isole le point faux et tout va bien.
En matière de Lambertisation les écarts résiduels sont plus représentatifs de la qualité locale du plan que de fautes d'observation, c'est à dire à de distorsions issues de fautes de levé, de report ou de calcul, sans compter celles qui sont issues de la reconduction des mailles napoléoniennes.
Alors quelques questions surviennent: améliore-t-on le géoréférencement de la feuille en isolant les forts écarts, ou le dégrade-t-on? Doit-on générer de forts écarts dans une zone parce qu'elle est supposée à priori discordante ou doit-on au contraire conserver les appuis de telles zones pour éviter d'y apporter des compensations aberrantes en cas de traitement local du problème?
Oui, à un moment donné on fini par se demander comment traiter les problèmes de discordances du plan avec le terrain, plutôt que d'essayer de fignoler les paramètres d'une transformation conforme qui, en aucun cas ne pourra correspondre à l'ensemble d'une feuille, surtout s'il s'agit d'une feuille rénovée par voie de mise à jour.
Le remaniement est une solution de luxe qui ne répond pas à l'urgence du problème.
Une autre solution pourrait consister à exploiter les écarts résiduels constatés lors de la Lambertisation. Chaque écart sur les appuis correspond en effet à une correction à apporter au parcellaire voisin pour le faire coïncider avec le terrain. Mais jusqu'où propager les compensations? Chaque angle du parcellaire devrait recevoir une compensation qui est fonction de la distance à un point d'appui et de l'écart résiduel de celui-ci.
Des universitaires ont étudié le problème, et l'un d'entre eux, Patrice Langlois, a écrit une théorie intéressante sur la pondération proportionnelle à l'inverse du carré des distances . C'est cette méthode qu'utilise MajiCad à travers HEDEPAG.
La compensation locale diminue très vite quand on s'éloigne d'un appui, mais elle reste cependant relativement homogène. Or, selon l'origine de l'erreur locale, il peut exister des endroits ou il serait souhaitable de créer une rupture dans la propagation des compensations.
Pour répondre à ces besoins, le système de compensation de MajiCad propose un outil supplémentaire: la "polyligne-faille". Par exemple, si on constate, par superposition à une ortho ou à un semis de points GPS, des phénomènes de cisaillement, (cas des bords de ruisseaux/routes issus de levés distincts), on peut poser une polyligne-faille qui indique au logiciel de n'utiliser que les appuis qui sont d'un même côté de la faille.
Autre difficulté: la méthode de calcul des points de liaisons. Ils sont traditionnellement obtenus par moyenne des déterminations individuelles dans leurs feuilles respectives. Cette façon de faire génère une discordance avec les appuis qui sont directement issus du calcul en bloc. Prenons par exemple le cas extrême ou un point de liaison est superposé à un appui sans être déclaré appui (liaison No 1001 et appui No2). L'appui n'aura pas le même jeu de coordonnées que le point de liaison moyen! Seule la détermination individuelle du point de liaison dans la feuille de l'appui aura le même jeu de coordonnées. Ce problème, insignifiant rappelons le pour le calcul de transformations conformes, prends évidement une assez grande importance si on considère le principe de départ de la compensation gravitaire, à savoir la représentativité des écarts résiduels.
Le module de calcul en bloc a donc été modifié de façon à pouvoir tenir compte, d'une part de la qualité de chaque feuille de l'assemblage, et d'autre part de la proximité des appuis pour pondérer la moyenne des points de liaisons.
C'est tout pour les moteurs de calcul. Voyons maintenant l'interface:
Mise en place du contexte:
Créer un Nouveau fichier et appeler en référence l'ensemble des feuilles à géoréférencer et les feuilles voisines pouvant servir de feuilles d'appuis.
Déclarer les feuilles à géoréférencer comme appartenant au bloc et affectez leur éventuellement un poids dépendant de leur qualité/échelle.
Cochez "Tours de feuilles" et "appuyez sur Mappe et Source", faire une vue d'ensemble et sauver.
Pour un calcul en bloc, il faut déclarer l'appartenance des appuis/liaisons à une feuille du bloc. Le bouton "feuille" permet de pointer un objet quelconque de la feuille de plan pour indiquer que le point suivant va lui appartenir. Cette appartenance fait partie du numéro de point.
Pose des appuis: 1er pointé = position relative à la feuille, 2eme pointé = position absolue du point.
Utilisation des orthophotos:
Les orthos sont un excellent garde fou contre toute faute de transformation des plans. Le but à atteindre est la supperposabilité au terrain, et les orthos sont sensées en être une image fidèle et géoréférencée. Il faudra, bien entendu, se forger une opinion par quelques mesures GPS, mais en général, c'est le cas. Donc, après contrôle, les orthos peuvent fort bien servir de référentiel pour le rétablissement du plan.
Le RETABLISSEMENT ? tiens!, un nouveau concept pour le plan cadastral? Ben oui, si on considère que la volonté initiale est une représentation fidèle au terrain, La mise en conformité avec le terrain dont on parle, ne fait que rétablir le plan dans ce qu'il a toujours représenté aux yeux des usagers. Fermons la parenthèse.
Quand on utilise une ortho comme appui dans MajiCad, on dispose d'une petite fonction, finalement très intéressante: le glissement du plan sur l'ortho.
Un petit glissement par approches successives, permet en effet de superposer une petite zone du plan et de l'ortho. Pour poser un appui, il suffira de cliquer au même endroit pour la position initiale et finale du point. C'est le décalage en cours qui permet au logiciel de connaitre la position absolue de l'appui. Cette façon de faire est aussi de nature à éviter la pose d'appui sur un sommet de parcelle qui s'avèrerait discordant avec son voisinage immédiat. La qualité de l'adaptation n'en sera que meilleure.
N'hésitez pas à lancer des calculs fréquents pour voir les résultats, car, encore une fois, ce ne sont que les écarts visuels du plan avec le terrain qui sont à considérer, à l'exclusion de toute interprétation abusive des EMQ.
Faites évidement des calculs conformes, mais, par curiosité, appuyez une fois sur « calcul définitif adaptatif ». Le risque est nul puisque ce sont des fichiers spéciaux qui sont créés à chaque fois. Comparez Avant/Après à l'aide des fonctions "Voir fichiers du bloc" et "Voir fichiers transformés"...
M'en parler...
Michel MARTIN
Commentaires
Toujours plus de fonctionnalités, félicitations. Je n'ai pas encore eu le temps de les tester mais les possibilités de pondérer les points moyens et d'intégrer une transfo pondérée sont surement bonnes à essayer en tout cas.
Les paramètres de transfo d'Helmert de chaque feuille sont ils calculés en tenant compte de ces pondérations ou est-ce une aide à l'analyse des écarts entre points de liaisons puis la possibilité de les utiliser ensuite pour la transfo pondérée ?
Je suppose que dans tous les cas PCB2D calcule toujours d'abords des paramètres conformes pour chaque feuille puis HEDEPAG utilise les coo transformées et les points moyens pondérés pour le calcul définitif ?
HEDEPAG travaille t-il à la feuille ou sur l'ensemble du bloc ?
Je n'ai pas compris le principe de la polyligne pour éviter les failles ... faut voir à l'utilisation.
merci encore et bon courage.
PCB2D calcule toujours les paramètres de similitudes directes (Helmert). Seules les positions moyennes des points de liaisons sont pondérées.
HEDEPAG prends ensuite le relais à partir de ces paramètres de transformations conformes pour transformer le plan à la feuille. Il n'applique le modèle de compensation gravitaire que sur demande.
Si, dans le fichier à transformer, il existe une polyligne posée dans une couche particulière "FAILLE_HDE", elle interromp la propagation des compensations. C'est cette notion de "faille" que j'évoque.
Extrait de l'article référencé dans le billet:
Déformation élastique du plan par composition d'une similitude optimale et d'une interpolation vectorielle de type gravitaire:
L'emploi préalable d'une similitude optimale permet de minimiser les altérations géométriques.
En effet, apres une similitude optimale, le centre de gravite des points sources a pour image le centre de gravite des points destination. L'interpolation vectorielle a donc pour plan asymptotique un vecteur nul, ce qui montre que la déformation élastique est, dans ce cas, une déformation purement locale. En d'autres termes, pour un point P suffisamment éloigne des pôles, la correction est pratiquement nulle, et la transformation est pratiquement une similitude.
Application en Géomatique: Recalage géométrique de cartes, a partir de points de calage.
C'est le domaine d'application naturel de cette méthode. Il suffit de connaitre la liste des points de calage dans le repère source de la carte et dans le repère destination. Ce dernier peut être le repère d'une autre carte dans laquelle la première doit se recaler. Par exemple, pour recaler une carte par ilots dans les limites d'une commune numérisée par ailleurs (ex BD Carto), il faut donner les points de bordure de la commune sur lesquels les ilots doivent se recoller. Si l'emboitement est parfait, la transformation calculera la similitude exacte pour que les deux morceaux s'adaptent. Sinon la déformation de limites d'ilots sera sensible au voisinage des points de bordure de la commune et diminuera très vite en s'éloignant de celle-ci, ce qui répond aux objectifs d'une telle opération.
Bonjour
la transformation par attraction gravitaire ne marche que sur des données " vecteur", ou également sur un plan sous format image?
La technique de transformation élastique par attraction gravitaire est applicable aussi bien aux plans vecteurs que rasteurs.
Dans le logiciel MajiCad, seule la version "vecteurs" a été implémentée.
A ce jour, si on suit les notes officielles (ainsi depuis plus de 10 ans), interdiction de raccorder les feuilles dont les écarts sont hors tolérance ...en dehors du remaniement ou transfo Helmert éventuellement.
Donc, transfo élastique ou locale sont prohibées ... et comme par hasard dans le cadre du RCPU, ce type de transfo revient en odeur de sainteté? "Majicad" a-t-il réussi à influencer la DGFIP?
Bonsoir Mesdames, bonsoir Messieurs et bonsoir Michel,
Lorsque HEDEPAG est utilisé en ligne de commande avec des fichiers .THF, la version qui était disponible à l'adresse http://michel.martin34.free.fr/MMpr... ne permettait pas de passer un paramètre "FAILLE_HDE".
Existe t'il une autre version, (> 1.2.6.17, 9999 points d'appuis), qui le permette ?
Je peux obtenir l'arrêt de la propagation en donnant la même position géographique aux points hors zone dans les fichiers cible et source, mais la solution "FAILLE_HDE" serait beaucoup plus élégante et plus légère en nombre de points.
Dans le texte du premier billet de cette page, tu parles de "la polyligne-faille", faut-il comprendre qu'une seule polyligne à la fois peut être utilisée lors d'une transformation ?
la "polyligne-faille" peut-elle avoir la forme d'une patate à l'extérieur de laquelle la transformation est sans effet ?
utiliser de multiples "polyligne-faille" (imbriquées ou non) est-il possible ?
Combinées à du remplacement de coordonnées et à l'option /EG100 de HEDEPAG, les patates multiples anti-propagation dans le paramètre "FAILLE_HDE" me seraient d'une grande utilité pour injecter des milliers de coordonnées réelles dans les plans digitalisés que je monte en charge sans me soucier de dépasser la limite actuelle des 9999 points d'appuis.
Quand le volume des données à injecter est plus faible, quelques centaines de points (canevas et DA récents), ça fonctionne très bien en l'état.
Merci pour cet outil et pour continuer à le développer.
Bonjour ReadWrite,
J'ai évoqué "la polyligne-faille" en temps que notion. On peut bien entendu en poser plusieurs, mais je n'ai pas testé les configurations particulières que tu évoques...
HEDEPAG en temps que module indépendant ne tient pas compte de cette notion. Elle est seulement accessible via MajiCad qui passe commande à HDE, une version améliorée sans interface. Il faut donc un environnement qui permette le contrôle, et c'est MajiCad.
L'inconvénient est qu'on ne peut plus appliquer les "paramètres" directement à un lot Edigéo, mais puisque tu me parles de cadastre, tu devrais pouvoir t'arranger à disposer d'un DXF, sachant en plus que l'utilisation de l'ASCODE en bout de chaine est complètement équivalente à de l'Edigéo.
Je m'interroge toutefois sur ton soucis à ne pas dépasser une limite de points d'appuis qui est énorme. Mis à part la gestion de la similitude non déformante qui exige une répartion de points homogène et un minimum de 5, les appuis complémentaires doivent être représentatifs de zones qui présentent une déformation locale, protégés par d'autres qui empèchent la propagation de la compensation à l'entour. L'un dans l'autre j'ai rarement eu besoin de dépasser une centaine d'appuis. Il semblerait que tu utilises HEDEPAG pour faire de la substitution de coordonnées sur certaines zones et pas sur d'autres?
Si tu juges utile de nous en parler, ton objectif pourrait nous intéresser...
bonjour à toutes et à tous et bonjour Michel,
je vais tenter de décrire le contexte dans lequel j'aimerais pouvoir utiliser des patates multiples anti-propagation avec une version améliorée sans interface de HEDEPAG et pourquoi 9999 points sont parfois insuffisants.
######################
1. Le géoréférencement
La base sur laquelle s'effectuent tous les travaux de numérisation est le plan cadastral géoréférencé. La méthode préconisée est l'utilisation des fichiers fournis par l'IGN. Ils étaient de piètre qualité, avec des écarts de plusieurs mètres pour des feuilles régulières récentes. Après signalement, une autre version a été fournie par l'IGN, mais sans que l'amélioration soit satisfaisante.
Forts du constat de la forte dépendance de la qualité du géoréférencement sur la suite des travaux, nos efforts ont porté là-dessus. Je cite un collègue : "pourquoi perdre du temps à essayer de poser le papier peint si les fondations de la maison sont mauvaises, il y aura toujours des fissures".
Cette observation se retrouve également au niveau des tolérances dans les instructions : la précision requise du pointé pour un point de calage est plus importante que celle requise pour la vérification de précision. Elle prend même des valeurs très larges lorsque l'on passe aux tolérances d'assemblage. Au point que des fautes de géoréférencement peuvent être absorbées par l'assemblage.
Tout n'a pas pu être réalisé en interne faute de temps, mais une bonne partie des feuilles a été géoréférencée à partir des coordonnées réelles en tenant compte des différents systèmes de projection utilisés selon les époques lors de la confection des feuilles (Sausheim, NTF 56, NTF 76) (voir aussi http://www.georepository.com/datum_... ) avant de reprojecter les TIF en Lambert 93 CC pour les livrer au prestataire.
Les méthodes utilisées ont eu pour but de positionner à l'endroit réel (c'est à dire observé sur le terrain) le pixel qui représente sur le TIF cette réalité.
Pour obtenir les fichiers d'appui, nous avons pu utiliser les imprimantes multifonctions pour scanner et passer à la reconnaissance optique de caractères (OCR) des listings de points et de calculs de surface. Sans ce matériel, ça aurait été plus difficile, j'adresse un grand merci aux services qui ont permis l'acquisition de ce matériel.
L'association pixel - point d'appui est manuelle pour les 2 premiers points, puis zoom assisté pour les suivants. C'est un travail long et répétitif qui demande du soin et de la concentration.
On passe ensuite à l'analyse des écarts individuels pour détecter et éliminer les fautes d'OCR et de pointé. On détecte alors les fautes sur le TIF. Au final on obtient quelque chose qui s'approche assez bien d'une réalité observée sur le terrain.
Il y a beaucoup de variétés de fautes sur les TIF. On a estimé qu'au delà d'un écart de 3 à 3.5 pixels, on est à la faute. Les opérations d'envergure nationale de changement de support ou de projection ( demi au grand aigle, papier au polyester, Saussheim au Lambert 56, PMC au TIF), bien qu'encadrées par des instructions qui ont limité les dégats, n'ont souvent pas permis de préserver le pré-existant. Je n'en fais pas l'inventaire ici, mais leur évocation est nécessaire pour aborder les limites d'un géoréférencement par une transformation Helmert de feuilles de plan qui n'ont pas les spécifications attendues.
Les méthodes non helmert que nous avons utilisées sont les transformations affines, polynomiales et affines par partie. L'affine par partie ressemble un peu à HEDEPAG /EG100, on fabrique une triangulation de Delaunay sur tous les couples pixel-appui et pour chaque triangle, on applique une transformation affine ; le résultat est un écart nul aux points d'appui et lissé dans les zones internes. Le logiciel utilisé a été Global Mapper v.9 à v.11 ( http://www.globalmapperforum.com ). C'est un excellent produit, qui était à à ses débuts un convertisseur universel de données géographiques. Sa conception et son support sont assurés par une seule personne, Michael Childs. C'est une personne qui corrige les bugs signalés sur le forum ( http://www.globalmapperforum.com/fo... ) dans la journée voire dans l'heure selon le décalage horaire, et ajoute au même rythme les nouvelles fonctionnalités demandées par les utilisateurs.
Il y a beaucoup à dire sur les variantes et les dosages à utiliser lors de l'emploi de méthodes non helmert, ce qui a guidé les opérateurs géoréférenceurs a été de donner à chaque pixel non entaché d'une faute une position observée sur le terrain pour les feuilles régulières. Pour les feuilles napoléoniennes ou refaites par voie de mises à jour, les points d'appui sont rares à l'intérieur des feuilles, mais il est souvent possible de les assembler entre elles jusqu'à parvenir à rejoindre des feuilles régulières avec des points d'appui. C'est de loin le travail de géoréférencement le plus difficile.
Il est également possible par ces méthodes non helmert de diminuer les imprécisions du plan pour les écarts inférieurs aux 3.5 pixels cités plus haut. Le travail de numérisation et d'assemblage du prestataire ainsi que que les travaux de vérification sont alors facilités par une lecture plus facile des TIF car les discordances entre les feuilles sont clairement identifiables comme des fautes ( de délimitation, de report ou d'absence de report, etc...).
Fin de la première partie. Les TIF sont numérisés, les travaux sont vérifiés et corrigés jusqu'à l'obtention du label "Cadastre".
###################################
2. Les travaux de montée en charge.
" de l'utilisation d'HEDEPAG pour faire de la substitution de coordonnées sur certaines zones et pas sur d'autres "
Au même titre que le géoréférencement pour la numérisation, les coordonnées réelles de points de référence sont les fondations d'une mise à jour plus facile du plan vectorisé.
La numérisation a produit des fichiers vecteur positionnés géographiquement comme l'étaient, aux tolérances de précision et d'assemblage près, les TIF géoréférencés livrés.
Ils sont la copie des TIF, à l'aune de la qualité de la vérification d'exhaustivité.
// digression
// fin
Par rapport aux points d'appui utilisés lors du géoréférencement, il reste un espace que le remplacement de coordonnées et HEDEPAG peuvent contribuer à résorber voire à combler. L'utilisation de PCI Vecteur pour ce type de travaux est possible mais irréalisable à l'échelle d'une carrière de géomètre compte tenu des multiples opérations que ce logiciel impose.
En vecteur, on a des facilités pour traiter de l'information.
La recherche des couples point numérisé - point réel peut être assistée par un logiciel.
ANN, A Library for Approximate Nearest Neighbor Searching (1998 - 2010) ( http://www.cs.umd.edu/~mount/ANN ), et FLANN, Fast Library for Approximate Nearest Neighbors ( 2008 - 2013) ( https://www.cs.ubc.ca/~mariusm/inde... ) sont particulièrement bien adaptés et utilisables dans de nombreux langages.
L'usage que j'en fait est la confection de fichiers de liaisons point numérisé -> point réel ( http://www.tg35.com/PPV/ANN.exe ).
Quelques options sont disponibles pour fignoler.
ann -qf QueryF -df DataF [-d dim -max m -nn k -r rad -e eps -p prec -gm 0/1 -sm 0/1 -ro 0/1
where options are:
Results are sent to the standard output.
ANN: Approximate Nearest Neighbors v1.1.2. compiled with ANN_ALLOW_SELF_MATCH set to ANNtrue, allowing self matches.
'ann.cpp', cpp source code is included in resource binary.
You can use 'Resource Hacker' to get it, see http://www.angusj.com/resourcehacke...
Lorsque le géoréférencement est bon, le nombre de faux positifs n'est pas excessif. Sinon, il faut d'abord recaler grossièrement en helmert les fichiers vecteur grace à l'excellent HEDEPAG.
Pour certaines zones, le remplacement de coordonnées est plus adapté que l'utilisation d'HEDEPAG avec /EG0 ou /EG100 et parfois c'est l'inverse.
exemple 1 :
- Le point d'appui est à l'extérieur de la feuille 1, il est bien représenté sur le TIF, il a servi au géoréférencement.
- Le même point d'appui est à l'intérieur de la feuille 2, limitrophe de la feuille 1, il est entaché d'une faute de report, il n'a pas servi au géoréférencement de la feuille 2.
- Ce point n'est présent dans le fichier vecteur que pour la feuille 2, la méthode à utiliser est le remplacement de coordonnées.
exemple 2:
- Les coordonnées d'un DA de lotissement sont presque toutes disponibles en points d'appui. Ce DA a été appliqué sur le plan avec un décalage d'un mètre. Des constructions nouvelles ont été levées et reportées mais les listing de coordonnées ne sont pas disponibles (bien que calculables au prix d'un temps précieux).
- à défault de patate, blinder de points l'extérieur du lotissement pour arrêter la propagation et utiliser HEDEPAG pour déplacer le lotissement en conservant les angles et les alignements.
Au final, pour une commune, le même fichier de liaisons est utilisé pour faire du remplacement de coordonnées et du recalage. Le but est de mettre à disposition dans les fichiers vecteur les données des levers qui ne sont disponibles dans les services que sous la forme de listings.
Le nombre des points peut être très important. Sur la dernière commune, qui comprend 4 feuilles remembrées, 1 feuille refaite, 3 feuilles rénovées par voie de mise à jour, j'avais 5951 points pour les limites de parcelles avec quelques bâtis et détails topo.
Pour limiter la propagation avec HEDEPAG, je dois ajouter à la liste des points cible et d'appui, ceux que je remplace et ceux dont je ne fais rien.
Il est vrai qu'en utilisant un fichier de liaisons par feuille, la limitation à 9999 points d'appui d'HEDEPAG n'en est plus une.
J'ai pris l'habitude de travailler à la commune mais trier les liaisons en fonction de la feuille afin de réaliser un post-traitement par feuille est actuellement pour moi la seule alternative pour utiliser HEDEPAG dans toutes les circonstances.
###################################
3. Et enfin ...
C'est pourquoi, lorsque j'ai lu ton billet et l'évocation de "la polyligne-faille", j'ai été délicieusement boulversé. Je me suis dit, il l'a fait et je n'en savais rien, je vais lui demander si je peux aussi jouer avec.
Tel un haruspice ( http://fr.wikipedia.org/wiki/Harusp... ), voire moins noblement, le devin Prolix dans Astérix ( http://fr.wikipedia.org/wiki/Le_Dev... ), j'ai examiné les entrailles fumantes d'une copie de HDE.exe. En vain.
Elles restent muettes, qui saura prédire qu'« après la pluie viendra le beau temps » ?
Donc, si j'ai bien compris, il y a eu:
1) un levé de points sur le terrain
2) géoréférencement déformant du rasteur
3) fourniture de points ou de paramètres aux entreprises qui ont digitalisé
4) traitement des fichiers avant montée en charge
Je ne peux pas m'empêcher de dire qu'à mon humble avis, la phase de géoréférencement déformant du rasteur est, non seulement inutile, mais sans doute illusoire sur la précision finale. Car si j'ai bien compris, une partie du traitement final consiste à redonner des coordonnées issues des pixels déformés aux points digitalisés?? (doute)
(
Pour obtenir un résultat sans prise de tête ni moyens onéreux, il eu fallu: faire digitaliser les feuilles brutes dans un système indépendant simplement mis à l'échelle pour les besoins de la vérification de copie conforme. Ou même en utilisant le géoréférencement IGN comme calcul approché. Et, après obtention du label, faire le véritable géoréférencement en régie sur les vecteurs, avec des moyens conformes ou non, et ceci par feuille, ce qui enlève la contrainte du nombre d'appuis.
L'inconvénient du système indépendant est qu'on ne peut pas sous traiter les rapprochements de feuilles à l'entreprise qui vectorise, mais je peux dire, après des années d'expérience, que les rapprochements de feuilles, hormis plans réguliers, se révèlent être une énorme gêne au traitement automatique des discontinuités du plan. Chaque rapprochement manuel, même complètement dans le domaine public, introduit une rupture supplémentaire dans la propagation de compensations, quelle que soit la méthode. C'est donc préférable de ne sous traiter aucun rapprochement de feuille sur des plans mis à jour.
)
Dans ton organigramme, je comprends ton mode d'utilisation de HEDEPAG avant montée en charge, qui te permet deux opérations en une, et la limite du nombre d'appuis est effectivement gênante pour l'opération de substitution de coordonnées. Mais cette substitution est elle bien du ressort d'un logiciel de transformation? Il faut quand même savoir que pour chaque point du plan, toutes les distances aux appuis sont calculées et exploitées dans les compensations. Pour 9999 appuis ça commence à faire un sacré nombre d'opérations et je m'inquiète un peu pour la rapidité des calculs. L'idéal serait d'intégrer à HEDEPAG une phase de substitution distincte des calculs.
En attendant, je pense qu'il serait judicieux d'utiliser une moulinette externe pour faire la simple substitution de coordonnées, et de n'avoir plus pour soucis que la préservation des coordonnées des points extérieurs aux zones à traiter.
Dans tous les cas, y compris s'il ne s'agit que de préserver des points, la notion de faille ne pourra pas te rendre service car elle n'influe que sur la propagation des compensations et pas sur l'application de l'Helmert préalable. Les coordonnées "hors patates" seraient donc changées malgré tout. (Exit HDE)
Dans MajiCad, il existe plusieurs possibilités de traitement qui préservent les coordonnées hors-zone
- La transformation locale ou ta seule contrainte serait de protéger la périphérie de la zone par des appuis "sur place". L'inconvénient étant alors d'appliquer une transfo par zone discordante.
- Oubien: de transférer les zones discordantes dans un fichier séparé (sauver contenu de zone suivi par une suppression de zone). De fusionner les zones discordantes dans un même fichier et d'y appliquer une transformation unique ou la seule contrainte serait de ne pas modifier les sommets non concernés en les considérant comme des appuis "sur place" (beaucoup moins nombreux que la limite de HEDEPAG)
La "faille" n'était pas si profonde, on pouvait encore y voir un bout de ciel, et comme de nombreuses choses, elle mêne à tout, à condition d'en sortir...
Donc, si j'ai bien compris, il y a eu:
1) un levé de points sur le terrain
les plans réguliers et les levés sont faits comme ça2) géoréférencement déformant du rasteur
parfois l'helmert n'est pas la meilleure solution
Contractuellement, les livraisons ne pouvaient être que des GEOTIFF ou des TIF + geo_.txt3) fourniture de points ou de paramètres aux entreprises qui ont digitalisé4)traitement des fichiers avant montée en charge
Avant, pendant, après, pas du toutCar si j'ai bien compris, une partie du traitement final consiste à redonner des coordonnées issues des pixels déformés aux points digitalisés?? (doute)
Une partie de la montée en charge peut consister à "injecter" dans les fichiers vecteur digitalisés les données des levers qui ne sont disponibles dans les services que sous la forme de listings, par remplacement ou par helmert selon la configuration du PMC.Pour obtenir un résultat sans prise de tête ni moyens onéreux, il eu fallu: ... système indépendant ... ou ... géoréférencement IGN... Et, après ... faire le véritable géoréférencement en régie sur les vecteurs ...
Une numérisation à un niveau départemental dont le bailleur de fonds est une collectivité territoriale est régie par un contrat qui spécifie des délais. Ces délais ont été la contrainte la plus forte. C'est pourquoi nos efforts ont porté sur la qualité du géoréférencement tant ils conditionnent la suite des travaux.Ainsi, lorsque le PMC ne comporte pas de fautes, et lorsque la vérification d'exhaustivité a permis de faire corriger les erreurs d'interprétation du TIF, les coordonnées du PMC vectorisé sont dans la tolérance de la vérification de précision, 30 cm au 1/1000, 60 au 1/2000 etc..., et par voie de conséquence à un écart semblable des coordonnées réelles observées sur le terrain.
cette substitution est elle bien du ressort d'un logiciel de transformation?
Le remplacement de coordonnées n'est pas réalisé par HEDEPAG. Transformation et remplacement sont réalisés l'un derrière l'autre. Mais alors que le remplacement n'a pas d'influence sur la transformation, la transformation sans arrêt de sa propagation altère les coordonnées à remplacer.je m'inquiète un peu pour la rapidité des calculs.
HEDEPAG traite les données d'une commune en quelques secondes, c'est vraiment bien, on ne ressent pas l'attente.Un filtre basé sur l'appartenance à une patate ralentirait le traitement surtout si elle comporte beaucoup de points. Mais ce serait un moindre mal.
Voilà comment j'ai cru que ça pourrait fonctionner :
intégrer à HEDEPAG une phase de substitution distincte des calculs.
pourquoi pas. J'utilise MiniTrue, a Search / Replace Utility, http://adoxa.3eeweb.com/minitrue/La "faille" n'était pas si profonde, on pouvait encore y voir un bout de ciel, et comme de nombreuses choses, elle mêne à tout, à condition d'en sortir...
En adepte des cheminements dans les profils souterrains, tu connais le sentiment que procure la sortie à l'air libre.Des patates et du GNoU , quel banquet !
Assurancetourix.
Je viens de relire l'aide de HEDEPAG. Que ne l'eus-je fait plus tôt !
La transformation peut être appliquée à un fichier EDIGEO, DXF ou ASCII(NXY).
Il y a dans l'expression "ASCII(NXY)" tout ce dont j'ai besoin.Donner à HEDEPAG un fichier de points initiaux, un fichier de points cible et un fichier ASCII pour obtenir un fichier ASCII transformé avec lequel il suffira de faire des remplacements dans les fichiers vecteur.
Merci beaucoup Michel. Tu avais déjà tout prévu.
Bonjour, ReadWrite
Tel M. Jourdain qui faisait de la prose sans le savoir, j'avais déjà tout prévu sans le savoir... Ce qui n'empêche, mon cher Assurancetourix que je n'avais rien compris à ton objectif.
Mais après avoir écouté ton chant mélodieux, et relu ton exposé dans le cadre du Cadastre d'Alsace/Moselle, j'ai compris qu'il s’agissait du recyclage de la richesse de la documentation cadastrale locale.
Je m'imaginais des appuis issus d'un levé spécial-géoréférencement d'ou l'incompréhension sur le nombre, et la confusion sur les listings/pixels.
Je confirme quand même mon impression d'inutilité du géoréférencement déformant du rasteur, dans la mesure ou il se cumule avec le même type de traitement fait après vectorisation.
En fait, ton handicap vient principalement de ta volonté de travailler par commune et non par unité de vectorisation. Et la encore, au risque de me prendre un revers, je vais faire part de mon avis.
Pour moi, l'intérêt principal d'un fichier unique est de pouvoir agir sur les limites de feuilles, tout en conservant leurs positions relatives. En général, sur des plans Mis A Jour, il vaut mieux considérer les positions relatives comme mauvaises et faire du géoréférencement "re-formant" à la feuille. C'est la raison pour laquelle j'évoquais la gêne ajoutée par les rapprochements manuels.
Sur les plans réguliers ou issus de la vectorisation de rasteurs remis en forme, comme dans ton cas, on pourrait considérer que les positions des limites de feuilles sont bonnes, surtout si elles sont forcées à des coordonnées "terrain".
Alors peut-être que je raisonne trop dans le cadre des possibilités de MajiCad, (notamment les fichiers en référence), mais dans les deux cas on peut envisager un travail à la feuille et s'affranchir de la fameuse limite de points de HEDEPAG; que du coup on pourrait baisser
Blague à part: Je peux monter à 30000 appuis sans changer la gestion de la mémoire. Pour plus, faut reprogrammer...
Je confirme quand même mon impression d'inutilité du géoréférencement déformant du rasteur, dans la mesure ou il se cumule avec le même type de traitement fait après vectorisation.
Pour de multiples raisons, le traitement après vectorisation n'est pas toujours réalisé lors de la montée en charge. Le géoréférencement a permis dans certaines limites de rester pas trop loin du terrain....un travail à la feuille...
depuis ta dernière réponse, j'y ai songé, mais ce que je gagnerai en nombre de points pour HEDEPAG, je le perdrai en nombre de fichiers à gérer, puisqu'ils seront par lot Edigéo au lieu de par commune. Il faut encore que je regarde ça de plus près, mais je pense pouvoir aboutir à quelque chose qui me permette de rester à l'échelle de la commune sans ajouter d'opérations manuelles supplémentaires.Je suis preneur d'une version à 30,000 points (ça peut toujours servir). Dans la même veine, une version sans aucune interface graphique, juste en ligne de commande avec un STDERR, me plairait aussi. Actuellement, je ne peux pas faire fonctionner HEDEPAG en "Hidden", la ligne de commande provoque des petits flash. Rien de bien gênant, ça anime le temps d'attente et on voit qu'il se passe quelque chose, ce qui n'est pas forcément mauvais. Mais, s'il te prend l'envie de le faire, je l'utiliserai.
Pour les adeptes de la ligne de commande
Un exemple d'utilisation de MiniTrue, http://adoxa.3eeweb.com/minitrue/ cité un peu plus haut : PTSEDI.bat..Décompresser le fichier PTSEDI.zip ( http://tg35.com/PPV/PTSEDI.zip ) dans un dossier qui contient des lots edigéo non compressés.
Un double clic sur le fichier PTSEDI.bat aura pour effet d'extraire la liste des coordonnées uniques de tous les noeuds de tous les lots Edigéo du dossier dans un fichier texte nommé EDIpts.txt.