banniere

Le portail francophone de la géomatique


Toujours pas inscrit ? Mot de passe oublié ?
Nom d'utilisateur    Mot de passe              Toujours pas inscrit ?   Mot de passe oublié ?

Annonce

Rencontres QGIS 2025

L'appel à participation est ouvert jusqu'au 19 janvier 2025!

#1 Wed 25 August 2010 17:17

Philippe Lézé
Participant occasionnel
Lieu: Mairie de Boulogne-Billancourt
Date d'inscription: 22 Sep 2005
Messages: 32
Site web

Lambert 1 et Lambert 93...

m'emmènent en galère : je viens de recevoir le cadastre en lambert 93, et toute ma base SDE est en 1 Nord. donc, il faut que je reprojette mes données. pas de soucis de ce côté. le problème est que j'ai aussi des .shp, dispersés dans tout un tas de dossiers différents. et je ne vous parle pas des .mxd !!!
bref, y-a-t-il une méthode miracle (mais j'y crois pas trop) ou autre pour que mes données et mes mxd puissent se retrouver (assez) rapidement en Lambert 93 ???
il se trouve que j'ai aussi des utilisateurs que je ne souhaite pas indisposer trop longtemps avec ce genre de soucis...
merci d'avance

Hors ligne

 

#2 Mon 30 August 2010 16:25

gilles_martinoty
Participant actif
Date d'inscription: 4 Mar 2008
Messages: 56

Re: Lambert 1 et Lambert 93...

Bonjour,

IGNMap peut peut-être vous aider, puisqu'une fonctionnalité intéressante d'IGNMap est de permettre de reprojeter l'ensemble d'une arborescence, i.e. par exemple tous les .shp dans des sous-répertoires. Il suffit de sélectionner le répertoire racine de vos données (mais faites tout de même une sauvegarde avant !).
Il ne gère en revanche pas les .mxd.

http://lambert93.ign.fr/index.php?id=34

Cordialement,
Gilles Martinoty

Hors ligne

 

#3 Tue 31 August 2010 09:45

Robin
GeoRezo forever
Lieu: France
Date d'inscription: 31 Aug 2005
Messages: 13614
Site web

Re: Lambert 1 et Lambert 93...

Hello,

En théorie, pas de souci, vu qu'arcgis est capable de reprojeter à la volée, peu importe que le cadastre soit en WGS84 ou en Projection du Swaziland, du moment que la projection est cohérente avec les données, Arcgis va projeter tout dans la projection du bloc de donnée.
Quant au mxd, il n'a pas de projection en soit, vu c'est le bloc de donnée qui contient ces infos.

Mais j'aurai besoin de plus de détail pour vous donner un diagnostic plus précis... Je ne comprend pas le problème des shapes, notamment, vus pourriez donner un exemple précis ?

Hors ligne

 

#4 Tue 31 August 2010 10:29

Philippe Lézé
Participant occasionnel
Lieu: Mairie de Boulogne-Billancourt
Date d'inscription: 22 Sep 2005
Messages: 32
Site web

Re: Lambert 1 et Lambert 93...

en fait, lorsque je récupère mon cadastre en Lambert 93 (avec Arcopole), et que j'ouvre un mxd existant, dont les couches sont en Lambert 1 nord, je constate un décalage de +- 53 m, car je n'ai pas appliqué la transformation.
Il me faudra donc reprojeter toutes mes données en Lambert 93, pour avoir une base cohérente.
La difficulté vient du fait que je travaille pour beaucoup de gens différents, avec des besoins différents.
J'ai donc, par souci d'organisation, créé autant de dossiers et de sous-dossiers  que nécessaire. Ce qui implique, après quelques années de travail, quelques dossiers...
donc, si je reprojette mes données sous ArcSDE, c'est facile, elles sont toutes ensembles, au même niveau. par contre, pour les couches "non pérennes" (stockées sous Windows), la difficulté vient de l'éclatement...
Une piste pourrait donc être de reprojeter les shp au fur et à mesure, mais c'est relativement peu satisfaisant, et une autre de traiter le problème avec un script Python, par exemple...
En attendant, je pense que je vais me contenter de reprojeter mes quelques données en Lambert 93 en Lambert 1 Nord......
Cordialement,

Hors ligne

 

#5 Tue 31 August 2010 11:30

Philippe Lézé
Participant occasionnel
Lieu: Mairie de Boulogne-Billancourt
Date d'inscription: 22 Sep 2005
Messages: 32
Site web

Re: Lambert 1 et Lambert 93...

gilles_martinoty a écrit:

Bonjour,

IGNMap peut peut-être vous aider, puisqu'une fonctionnalité intéressante d'IGNMap est de permettre de reprojeter l'ensemble d'une arborescence, i.e. par exemple tous les .shp dans des sous-répertoires. Il suffit de sélectionner le répertoire racine de vos données (mais faites tout de même une sauvegarde avant !).
Il ne gère en revanche pas les .mxd.


Bonjour,
je teste votre solution, qui me semble assez prometteuse, mais je suis rapidement tombé sur un hic : la mémoire !
en effet, IGN Map refuse de traiter le job car je ne possède pas assez de mémoire. donc, essai avec moins de données : idem, puis 3ème essai avec 1 seul dossier : toujours pareil, avec seulement 2 shp ?????
une idée, une piste ?
merci d'avance

Hors ligne

 

#6 Tue 31 August 2010 13:43

Robin
GeoRezo forever
Lieu: France
Date d'inscription: 31 Aug 2005
Messages: 13614
Site web

Re: Lambert 1 et Lambert 93...

en fait, lorsque je récupère mon cadastre en Lambert 93 (avec Arcopole), et que j'ouvre un mxd existant, dont les couches sont en Lambert 1 nord, je constate un décalage de +- 53 m, car je n'ai pas appliqué la transformation.


Dans ce cas, il suffit d'aller dans les propriétés du bloc de donnée pour "appliquer" la grille de transformation "RGF_1993_to_NTF_NTv2", non ?

Je sais que ça implique d'ouvrir tous les mxd où ce souci apparaît, mais ça ne viendrait pas d'un souci de reprojection dans ce cas (=pas besoin de projeter physiquement toutes les couches, à priori)

Hors ligne

 

#7 Tue 31 August 2010 14:14

Philippe Lézé
Participant occasionnel
Lieu: Mairie de Boulogne-Billancourt
Date d'inscription: 22 Sep 2005
Messages: 32
Site web

Re: Lambert 1 et Lambert 93...

oui, bien sûr....mais le vrai souci est que le Lambert 93 est devenu incontournable, et que je préfère avoir une base cohérente.
en outre, cela m'éviterait de tout mélanger. Enfin, il doit y avoir quelques centaines de mxd dans ma base de travail.
la reprojection des couches me semblait donc la solution la + "propre"...
En attendant, je vais me contenter de reprojeter mes données en L93 en L1, et de rester dans une semi-illégalité..... smile

Hors ligne

 

#8 Tue 31 August 2010 15:25

fbecir
Participant assidu
Lieu: Saint-Mandé
Date d'inscription: 16 Sep 2008
Messages: 519

Re: Lambert 1 et Lambert 93...

Philippe Lézé a écrit:

je teste votre solution, qui me semble assez prometteuse, mais je suis rapidement tombé sur un hic : la mémoire !
en effet, IGN Map refuse de traiter le job car je ne possède pas assez de mémoire. donc, essai avec moins de données : idem, puis 3ème essai avec 1 seul dossier : toujours pareil, avec seulement 2 shp ?????
une idée, une piste ?
merci d'avance


Bonjour

Je suis un peu surpris par ce problème de mémoire, IGNMap m'ayant déjà permis de reprojeter de gros jeux de données. Quelle est la taille de vos fichiers Shapefile ???

Cordialement

Hors ligne

 

#9 Tue 31 August 2010 15:52

Philippe Lézé
Participant occasionnel
Lieu: Mairie de Boulogne-Billancourt
Date d'inscription: 22 Sep 2005
Messages: 32
Site web

Re: Lambert 1 et Lambert 93...

eh bien, pour tout vous dire, moi aussi : les fichiers représentent quand même au total le poids de 17 Ko !!!!
peut-être est-ce dû aux chemins réseaux, à Seven 32b ?
je relance en local, pour voir...

Hors ligne

 

#10 Tue 31 August 2010 15:56

Philippe Lézé
Participant occasionnel
Lieu: Mairie de Boulogne-Billancourt
Date d'inscription: 22 Sep 2005
Messages: 32
Site web

Re: Lambert 1 et Lambert 93...

je viens de relancer : IGN Map la,nce très rapidement et atteint 50%, puis le processus utilise la mémoire dispo (3 Go) et... s'arrête, pour manque de mémoire...
assez incompréhensible...

Hors ligne

 

#11 Tue 31 August 2010 17:57

Laurent DUPONT
Participant occasionnel
Lieu: Brest métropole océane
Date d'inscription: 17 Oct 2005
Messages: 27
Site web

Re: Lambert 1 et Lambert 93...

Bonjour

A Brest nous avons migré L1 vers L93 avant l'été.

Le pb s'est donc posé de la même façon : convertir une multitude de couches shp dispersées dans une foule de dossiers (nous ne sommes pas encore en sde, le sig de la collectivité est bien maitrisé, mais il y a des données utilisateur dans tous les coins, et on allait pas les laisser se débrouiller, ça nous serait retombé dessus d'une façon ou d'une autre).

Nous avons donc mis en place une routine développée en Python qui traite le pb.
Elle prend une arborescence quelconque et la réplique à l'identique en changeant la projection des shape au passage.
Le sig a été traité en 2 jours et les utilisateurs ont a leur disposition une "machine à convertir" qu'ils utilisent à leur rythme en déposant leurs dossiers pleins de shape (et autres fichiers) dans la journée, et en les récupérant le lendemain.

Je précise que la conversion est basée sur les librairies Proj4/Fwtools, préconisées par l'IGN sur leur site, et support d'IGNMap je crois. Aucun recours à ArcGis donc (si quand même, pour les fichiers .prj qui doit être dans la bonne forme).

Pour les .mxd, sortez vos mouchoirs smile Aucun moyen connu à ce jour pour les migrer. Ca n'est pourtant pas faute d'avoir cherché, y compris du coté d'Esri dont la réponse a été qu'il n'existait pas d'outil automatisable disponible dans leur boite, qu'ils n'étaient pas juridiquement obligés de nous en mettre un à disposition, mais qu'ils nous proposaient une prestation de 4 jours pour résoudre notre problème sad

La solution manuelle est pourtant on ne peut plus simple : dans le mxd, Propriété de chaque bloc de données (pour autant qu'il y en ait plusieurs), Système de coordonnées, Lambert 93, enregistrer, c'est fait, mxd suivant.
La pudeur m'oblige à ne pas révéler le nombre de mxd que nous avons inventoriés chez nous, mais croyez-moi, nous en avons pour un moment. Sans parler des risques d'incohérence : shape dans une projection, mxd dans une autre (vu le raté ArcMap dans la projection à la volée NTF/RGF avec/sans grille IGN).

Bref, si vous souhaitez, je peux vous fournir notre routine Python. Il y aura un peu de paramétrage pour tenir compte de votre contexte, mais ça doit pouvoir aider.

Dites-moi si vous êtes intéressé.

Cordialement

Laurent DUPONT   
Brest métropole océane / Atelier des données et études urbaines
Service de l'Information Géographique (SIG)

Hors ligne

 

#12 Tue 31 August 2010 20:05

Jeirhome
Membre
Lieu: Liverion
Date d'inscription: 22 Aug 2006
Messages: 4298
Site web

Re: Lambert 1 et Lambert 93...

Pour les mxd, la solution simple, si la norme interne de nommage des fichiers le permet : Nommer les fichiers convertis en Lambert 93 exactement de la même façon que lorsqu'ils étaient en NTF. Alors seule la métadonnée "système de coordonnées" change, ArcMap n'y voit que du feu, et on économise 4 jours de presta de chez ESRI.


Ca n'est pourtant pas faute d'avoir cherché, y compris du coté d'Esri dont la réponse a été qu'il n'existait pas d'outil automatisable disponible dans leur boite, qu'ils n'étaient pas juridiquement obligés de nous en mettre un à disposition, mais qu'ils nous proposaient une prestation de 4 jours pour résoudre notre problème sad


Ayant pratiqué il y a quelques temps la programmation ArcObjects, on parle de :
- parcourir à travers une arborescence de tous les fichiers .mxd,
- ouvrir chacun des mxd,
- parcourir pour chaque carte du document mxd chaque couche
- éditer la propriété DataSource de chaque jeux de données.

Il y a peut-être quelques cas tordus et ça peut prendre un peu plus qu'une demi-journée de travail. En tout cas, ça m'étonne qu'on parle de l'inexistence d'un tel outil.


[...]

[Recherche Google]

[...]


Je trouve http://arcscripts.esri.com/details.asp?dbid=14456 qui m'a l'air d'être dans les cordes du besoin exprimé ici. Est-ce bien cela ?


@Laurent Dupont : S'il n'y pas de problème de droit, ce script Python pourrait se retrouver dans la rubrique Ressources de GeoRezo, non ? (Il suffit de joindre le fichier dans un message, après traitement par le modérateur, il apparaitra sur http://georezo.net/forum/download.php?fid=4


Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !

Hors ligne

 

#13 Fri 03 September 2010 09:45

Philippe Lézé
Participant occasionnel
Lieu: Mairie de Boulogne-Billancourt
Date d'inscription: 22 Sep 2005
Messages: 32
Site web

Re: Lambert 1 et Lambert 93...

Pour Laurent Dupont :
désolé de na pas avoir posté + tôt, mais j'ai été absent...
pour le fonds : je suis bien content de me rendre compte que je ne suis pas le seul, qu'il s'agit là d'un problème qui est (va devenir) récurrent. par conséquent, votre proposition de transmission de routine Python est plus que sympathique... et je l'accepte bien volontiers, si, comme l'a souligné Jeirhome, il n'y a pas d'obstacle juridique, bien sûr.
j'ai par ailleurs été contacté par fbecir, à propos d'IGNMap.
cette solution a "foiré", non pas à cause du soft, mais à cause des données. il semble que certaines couches, et je n'en connais pas précisément la cause, ne respectent pas aveuglément la norme shp. sinon, ce soft me semblait assez prometteur...
en tous cas, merci de votre mobilisation...

Hors ligne

 

#14 Fri 03 September 2010 14:27

Laurent DUPONT
Participant occasionnel
Lieu: Brest métropole océane
Date d'inscription: 17 Oct 2005
Messages: 27
Site web

Re: Lambert 1 et Lambert 93...

Bonjour

Ci-joint la routine Python.

En ce qui me concerne, aucun pb de droit. Par contre, le code est un peu "brut de fonderie", adapté à notre contexte (chemin windows en dur, pas d'interface graphique, ...). Sa réutilisation nécessitera un peu de reprise (pas trop quand même), et je n'ai malheureusement pas le temps de m'y coller. Donc, je vous le laisse en l'état.

En gros, la routine prend en charge une arborescence complète, admettons D:RGF93, avec par ex. des dossiers doss1, doss2, ... dossn (pas de limite dans le nb de dossiers, de fichiers, de niveaux)

En sortie, les dossiers d'origine restent inchangés. Des dossiers doss1_Lambert93, doss2_Lambert93, ... dossn_Lambert93 seront créés. Ils contiendront l'équivalent du contenu des dossiers d'origine, mais les couches Shape et les projets ArcView V3 (.apr) seront convertis de Lambert 1 en Lambert 93. Les autres fichiers seront recopiés à l'identique. Les shape qui ne seraient pas accompagnés d'un .prj sont considérés comme étant du Lambert 1 par défaut. Pour les shape accompagnés d'un .prj, seules 2 projections d'origine sont prises en charge : Lambert 1 et Lambert 2 étendu (examen du .prj avant projection).

Des fichiers "rapport d'exécution" sont créés. Un par dossier. Ils indiquent l'heure et le résultat de la conversion de chaque fichier (.shp ou .apr), avec un certain nombre de cas d'erreur traités (projection d'origine inconnue, entités erronées, ...).

Attention, le traitement des .apr est très long si le projet est gros (étiquettes, graphiques, ...). On peut le désactiver au besoin en mettant des commentaires devant les lignes concernées du script.

Les bibliothèques Fwtools sont a installer préalablement. Modifier au besoin le chemin d'installation et les variables d'environnement dans les premières lignes du script.

Voilà, bon courage aux utilisateurs, et tant mieux si ça peut dépanner.

Laurent DUPONT
Brest métropole océane / Atelier des données et études urbaines
Service de l'Information Géographique (SIG)

insertion de la pièce jointe reçue par mail...

Dernière modification par Jeirhome (Fri 03 September 2010 14:29)


Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

Hors ligne

 

#15 Fri 03 September 2010 14:36

Jeirhome
Membre
Lieu: Liverion
Date d'inscription: 22 Aug 2006
Messages: 4298
Site web

Re: Lambert 1 et Lambert 93...

J'ai résumé les caractéristiques pour une description rapide http://georezo.net/forum/download.php?fid=4 le lien vers ce sujet étant naturellement toujours disponible.


Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !

Hors ligne

 

#16 Fri 03 September 2010 22:09

Franck B
Membre
Lieu: PACA
Date d'inscription: 6 Sep 2005
Messages: 1382
Site web

Re: Lambert 1 et Lambert 93...

Bonjour,

Laurent DUPONT a écrit:

vu le raté ArcMap dans la projection à la volée NTF/RGF avec/sans grille IGN


Votre remarque m'intrigue. Pouvez-vous nous donner des détails ?

Il me semblait que le moteur de changement de système géodésique NTF vers RGF93 d'ArcGIS 9.3 avait été labélisé par l'IGN : http://lambert93.ign.fr/index.php?id=37 (Comme FWTools 2.2.8 d'ailleurs)

A bientôt

Franck

Hors ligne

 

#17 Fri 03 September 2010 23:29

Jeirhome
Membre
Lieu: Liverion
Date d'inscription: 22 Aug 2006
Messages: 4298
Site web

Re: Lambert 1 et Lambert 93...

Seul la conversion de fichiers est labellisé, pas la reprojection à la volée.

Pour l'ensemble des logiciels, seules les reprojections des fichiers ont été testées. Les reprojections à la volée n'ont pas fait l'objet d'une évaluation.


Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !

Hors ligne

 

#18 Sat 04 September 2010 15:30

Franck B
Membre
Lieu: PACA
Date d'inscription: 6 Sep 2005
Messages: 1382
Site web

Re: Lambert 1 et Lambert 93...

Jeirhome a écrit:

Seul la conversion de fichiers est labellisé, pas la reprojection à la volée.


Et tu crois que ce n'est pas le moteur de conversion qui est utilisé pour le transformation à la volée et pour la transformation de fichier ?
ESRI France, lors de la sortie de cette labélisation, a fait le raccourci  :


C'est pour cela que le retour d'expérience de Laurent m'intéresse.

A+

Franck

Pour info : Le document de synthèse de l'IGN pour la labélisation du logiciel ArcGIS 9.3

Hors ligne

 

#19 Sat 04 September 2010 18:02

Jeirhome
Membre
Lieu: Liverion
Date d'inscription: 22 Aug 2006
Messages: 4298
Site web

Re: Lambert 1 et Lambert 93...

Il y a de grandes chances que le moteur de conversion reste le même, mais cela n'a rien d'évident, les ArcToolBox sont des boites noires. Il y a de bonnes chances qu'il n'y ait pas de duplication de moteur de conversion.

Pour moi s'il y a un problème dans la projection à la volée, c'est plus un problème d'ergonomie. Toutes les formules liées aux projections cartographiques sont publiées depuis quelques temps, qualifier le codage d'un algorithme est une bonne chose, mais ce n'est suffisant que si on élimine les opérateurs ! smile On ne peut utiliser de manière durable la projection à la volée avec ArcGIS.


Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !

Hors ligne

 

#20 Mon 06 September 2010 10:37

Laurent DUPONT
Participant occasionnel
Lieu: Brest métropole océane
Date d'inscription: 17 Oct 2005
Messages: 27
Site web

Re: Lambert 1 et Lambert 93...

Bonjour

Petite précision sur ce que je voulais dire par :"vu le raté ArcMap dans la projection à la volée NTF/RGF avec/sans grille IGN".

Lorsque l'on charge dans un projet Lambert I des données Lambert 93, ArcMap signale l'incohérence et propose une projection à la volée. Pour cette projection il utilise malheureusement par défaut la transformation NTF_to_RGF_1993_1. Si j'ai bien compris, cette transformation n'utilise pas la grille IGN, c'est l'autre qui l'utilise (RGF_1993_To_NTF_NTv2). Résultat, les données projetées se retrouvent avec 70 m  de décalage dans l'Ouest (pour la région brestoise).

Ce pb est valable dans les 2 sens bien sûr NTF->RGF93 et RGF93->NTF, mais également NTFWGS84, si vous êtes amenés à manipuler des coordonnées géographiques.

Pour éviter cela, penser à sélectionner vous-même manuellement la bonne transformation au moment ou ArcMap propose le changement de projection.

Autre solution, modifier dans les paramètres d'environnement>paramètres généraux, la valeur du champ "Transformation géographique". Mais ceci est à faire pour chaque projet.

Ces manip, qui peuvent sembler simples pour quelqu'un de bien informé, sont en fait quasi inutilisables dans un contexte d'utilisation d'ArcMap par un grand nombre de non-spécialistes. Le risque est alors très élevé d'incohérence dans l'utilisation et la saisie de données si l'on reste avec des jeux de données dans les 2 systèmes de coordonnées.

Esri alerté sur ce problème n'a pas fourni de solution adaptée, à ma connaissance. J'entends par solution adaptée, soit ne garder que la transformation qui marche (IGNMap ne propose pas 2 transformations par exemple), soit par un mécanisme de paramétrage d'ArcMap, faire en sorte que la bonne transformation soit utilisée par défaut.

Bonne journée.

Laurent DUPONT
Brest métropole océane / Atelier des données et études urbaines
Service de l'Information Géographique (SIG)

Hors ligne

 

#21 Mon 06 September 2010 10:42

Jeirhome
Membre
Lieu: Liverion
Date d'inscription: 22 Aug 2006
Messages: 4298
Site web

Re: Lambert 1 et Lambert 93...

Lorsque l'on charge dans un projet Lambert I des données Lambert 93, ArcMap signale l'incohérence et propose une projection à la volée. Pour cette projection il utilise malheureusement par défaut la transformation NTF_to_RGF_1993_1. Si j'ai bien compris, cette transformation n'utilise pas la grille IGN, c'est l'autre qui l'utilise (RGF_1993_To_NTF_NTv2). Résultat, les données projetées se retrouvent avec 70 m  de décalage dans l'Ouest (pour la région brestoise).


Non, c'est pire que ça ! Par défaut, ArcGIS utilise la transformation "identité", ou simplement ne transforme pas ! La transformation la plus basique qui existe pour passer de la NTF au RGF93, celle avec 3 paramètres de translations, transforme les données avec un biais maximal de 5-6 m.

Tous ceux qui se retrouvent avec plusieurs dizaines de mètres ne font aucune transformation sad Du coup on comprend que la résolution du problème est un peu plus compliqué que simplement garder qu'une seule transformation...


Jérôme Cuinet
L'avantage de la Chine, c'est que le soleil se couche plus tard !

Hors ligne

 

#22 Wed 14 December 2011 14:51

mathi
Participant occasionnel
Lieu: Normandie
Date d'inscription: 13 Jun 2007
Messages: 10

Re: Lambert 1 et Lambert 93...

Bonjour,
Pourriez vous me dire où charger la transformation RGF_1993_To_NTF_NTv2 car je ne l'ai pas par défaut dans Arcgis (version 10):
Merci d'avance pour vos réponses


Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

Hors ligne

 

Pied de page des forums

Powered by FluxBB