#1 Fri 04 September 2009 12:58
[APIC] Traduction bloc DXF
Je ne connais pas bien l'interface DXF sous APIC, (étant simple utilisateur), aussi je pose la question pour des personnes qui semblent plus expérimentées que moi : Est-il possible de récupérer des fichiers DXF structurés de telle manière que chaque objet (par ex exemple une parcelle à trou) est constituée par un bloc DXF (constitué par ex dans le cas de la parcelle à trou de deux polylignes, d'une écriture -le n°- et d'éventuels attributs comme la contenance).
Je pose la question car apparemment ce format semble être plus facile à intégrer dans certains SIG.
Merci pour vos éclaircissements.
Dernière modification par christian (Fri 04 September 2009 13:00)
Hors ligne
#2 Fri 04 September 2009 15:52
- JEJE33
- Participant actif
- Lieu: Bordeaux
- Date d'inscription: 29 May 2007
- Messages: 121
Re: [APIC] Traduction bloc DXF
Bonjour
Je ne suis pas sur de comprendre la question, mais une chose est certaine APIC n'accepte comme format d'échange soit le format ASC, soit le DXF.
Or si une parcelle contient des trous, dans un format SIG classique, comme ArcView par exemple, alors sa conversion au format DXF ne permet pas de récupérer les trous naturellement.
En effet, les trous devenant une parcelle, pour APIC.
La seule solution, bien que jamais testé par mes soins est de passer par un traducteur de type FME afin de convertir directement les parcelles à trous au format ASC, contenant elle-mêmes les trous.
Dans ce cas le format ASC peu même contenir des données attributaires.
Je ne sais pas si je suis assez clair.
Jérôme
Hors ligne
#3 Fri 04 September 2009 17:23
Re: [APIC] Traduction bloc DXF
bonjour jérome,
je m'explique un peu plus :
dire "j'échange en DXF" est aussi vague que de dire j'envoie un fichier SIG, je veux dire qu'il peut y avoir tout une série de formats DXF plus ou moins structurés et fonction de leurs structuration plus ou moins riches. On peut même produire un DXF beaucoupl plus riche que beaucoup de formats SIG (par ex SHP et MIF/MID).
Je n'ai jamais fait la chose moi même mais je sais que certaines personnes récupèrent des DXF trés structurés de manière à l'intégrer dans un SIG de manière automatique et sans reconstitutions parfois hasardeuses comme cela peut être le cas.
Je ne veux pas dire que le code ci dessus est inefficace, je le trouve au contraire trés intelligent, mais à cause des données d'origine, il peut y avoir des couacs : un exemple pour justifier mon propos :
prenons le cas de deux objets à trous (non identifiables) dont les trous se supperposent parce que les objets ne sont pas topologique (par ex deux cours d'eau sur deux subdivisions cadastrales disctinctes qui se chevauchent) : bien malin le code qui arrivera alors à savoir si le trou appartient à tel ou tel autre objet dans le cas d'un DXF non structuré en objets.
Si par contre chaque objet est transmis sous forme de bloc DXF, le bloc contient alors tous les éléments nécessaires à sa reconstitution sans ambiguité.
Pour le DXF PCI le problème se pose pour tous les objets non identifiables. Pour les objets identifiables comme les parcelles, celui ci transmet sous forme de XData l'identifiant de la parcelle (pour la polyligne contour et pour les polylignes trous si ma mémoire ne me fait pas défaut), donc moyennant un peu plus de code que ci dessus, la parcelle devrait pouvoir retrouver ses petits si l'interface DXF-APIC permet de récupérer l'XData (ce que je crois)
La question reste donc ouverte de savoir si APIC est capable (paramétrage ou que sais-je...) de récupérer des blocs DXF.
c'était juste une question à des personnes qui semblent beaucoup plus compétentes que moi dans le langage ASL, par curiosité (car des fois en étant curieux, on découvre des choses insoupçonnées)
cordialement
Dernière modification par christian (Fri 04 September 2009 17:27)
Hors ligne
#4 Fri 04 September 2009 21:22
- JC
- Membre
- Lieu: Les Clayes sous Bois
- Date d'inscription: 31 Jul 2007
- Messages: 332
Re: [APIC] Traduction bloc DXF
Je pose la question car apparemment ce format semble être plus facile à intégrer dans certains SIG.
Premier gros doute pour ce qui me concerne... D'expérience, certains SIG sont beaucoup plus tolérants avec le DXF que d'autres. APIC et Mapinfo le sont plutôt (DXF, DXF + XDATA...). ArcGIS l'est moins ! Bref, le DXF est tout sauf un moyen universel de véhiculer de la donnée SIG.
On peut même produire un DXF beaucoupl plus riche que beaucoup de formats SIG (par ex SHP et MIF/MID).
Plus riche ? Graphiquement, peut-être... Pour le reste, j'ai un second gros doute. Pour ma part, FME (en import) et GDAL (en export) ont sérieusement fait chuter le recours au DXF, qui était quasi systématique avant leur découverte. Le DXF se justifie encore pour les imports de données simples, essentiellement graphiques et peu porteuses de données attributaires.
Je n'ai jamais fait la chose moi même mais je sais que certaines personnes récupèrent des DXF trés structurés de manière à l'intégrer dans un SIG de manière automatique et sans reconstitutions parfois hasardeuses comme cela peut être le cas.
Deux solutions, avec APIC, pour récupérer à partir d'un DXF des géométries ET leur associer des attributs :
- le DXF + XDATA, que j'adorais jusqu'à ce que je réalise que bien peu de gens étaient capables de les produire et même de les lire ;
- le DXF, à grand renfort de blocs. C'est facile à récupérer pour APIC... Apparemment moins à produire pour les fournisseurs de données !
Si par contre chaque objet est transmis sous forme de bloc DXF, le bloc contient alors tous les éléments nécessaires à sa reconstitution sans ambiguité.
Le traducteur DXF d'APIC sait décomposer les blocs... Dans une certaine limite. Je ne suis pas certain qu'il sache décomposer un bloc en contenant d'autres. Pour un bloc composé de LINE, POLYLINE, CERCLE, etc... c'est bel et bien prévu. Ceci dit, le résultat dans APIC sera bien peu structuré et plutôt de l'ordre du "plat de spaghetti". Sauf post-traitements en ASL. Le principal avantage du bloc à mes yeux n'est pas d'agréger des géométries mais de permettre d'associer des données attributaires à une géométrie.
la parcelle devrait pouvoir retrouver ses petits si l'interface DXF-APIC permet de récupérer l'XData (ce que je crois)
Elle le permet...
La question reste donc ouverte de savoir si APIC est capable (paramétrage ou que sais-je...) de récupérer des blocs DXF.
La réponse à cette question est "Oui". Le problème reste que c'est une gageure pour le prestataire à qui il sera demandé de le produire. C'est tout du moins ce que j'ai pu constater d'expérience.
par curiosité (car des fois en étant curieux, on découvre des choses insoupçonnées)
JC... qui aime bien les gens curieux ! ;o)
Association GeoRezo.net
Hors ligne
#5 Sun 06 September 2009 19:07
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3191
- Site web
Re: [APIC] Traduction bloc DXF
Bonjour,
(pour la polyligne contour et pour les polylignes trous si ma mémoire ne me fait pas défaut)
Christian si tu as des exemples de parcelles à trous dont le trou est autre chose qu'une autre parcelle je suis preneur, de même si ta mémoire pouvait devenir une certitude, idem ! Je ne me suis pas plongé depuis longtemps dans le DXF-PCI mais il va falloir que je m'y remette sous peu, donc le suivi m'intéresse.
Le problème reste que c'est une gageure pour le prestataire à qui il sera demandé de le produire.
Il se pourrait que le "prestataire" soit celui qui pose la question ... (?) 
A+
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#6 Mon 07 September 2009 21:25
Re: [APIC] Traduction bloc DXF
Bonjour,
Christian si tu as des exemples de parcelles à trous dont le trou est autre chose qu'une autre parcelle je suis preneur, de même si ta mémoire pouvait devenir une certitude, idem ! Je ne me suis pas plongé depuis longtemps dans le DXF-PCI mais il va falloir que je m'y remette sous peu, donc le suivi m'intéresse.
je ne suis pas sur de comprendre ce que tu demandes...
Pour les trous de parcelles qui ne sont pas des parcelles : assez fréquemment traité dans ma zone d'intervention : des subdivisions de section (ou devrais-je dire parties de subd de sect). Mais j'ai vu, comble du comble : du domaine public (partie ayant été passée au DP et autre partie n'ayant pu être iincorporé pour X raison juridique, ou gros morcellement de zone d'activité avec régularisations en cours...etc). Bref autant dire qu'il est difficile quelquefois de comprendre le plan cadastral.
Pour les autres objets "à trou" courants (je ne suis pas sur que ce soit ce que tu demandes) : fleuves, rivières, batiments, voies privées...
JC a écrit:Le problème reste que c'est une gageure pour le prestataire à qui il sera demandé de le produire.
Il se pourrait que le "prestataire" soit celui qui pose la question ... (?)
Je comprend ce que veux dire JC : sauf à avoir une appli particulière, il est assez galère sous Acad de créer les blocs les uns après les autres avec les outils "standard" par contre le format DXF peut fort bien se préter ou fournir des données largement aussi complètes que les SIG (je maintiens ) mais c'est sûr pas avec un Acad de base ...
Hors ligne
#7 Sun 13 September 2009 13:00
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3191
- Site web
Re: [APIC] Traduction bloc DXF
Bonjour
En fait j'ai souvent dans ma zone des parcelles "enclavées" de type bâtiments formant parcelle à l'intérieur d'une autre. Après réflexion il existe aussi des pieces d'eau (DP parfois) à l'intérieur d'une parcelle.
Mon interrogation outre les exemples porte sur le fait suivant:
En DXF-PCI avons nous une polyligne de contour extérieur avec "fil à la patte" vers une polyligne décrivant le trou, ou une polyligne comportant uniquement le contour extérieur, ou deux polyligne (extérieur et contour du trou ?
A+
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#8 Sun 13 September 2009 18:27
Re: [APIC] Traduction bloc DXF
bonjour christophe,
le DXF PCI que j'ai eu l'occasion de voir était constitué d'autant de polylignes distinctes que de contours (contours externes, contours internes, ...), à ma connaissance les polylignes consituées avec "fil à la patte" étaient utilisées pour les objets archipels car cela était le seul moyen de les décrire (ce qui il y a plusieurs années alors que je m'y était penché dessus posait quelques problèmes d'intégration).
Les contours externes et internes étaient distingués par des couches de nom distinct (ex: 1PARCELLE et 1TROUPARCELLE), avec des cas si ma mémoire ne me fait pas défaut insolubles car non prévus par la norme d'alors (c'était le cas me semble t-il des trous de batiments ou de rivières...) qui étaient donc coutournés par les "fils à la patte".
Je n'ai personnellement jamais utilisés ces artifices tant ils étaient "tordus".
La norme edigeo par rapport à APIC apporte de ce point de vue beaucoup de satisfaction même si l'interface avec APIC pose ecore quelques problèmes notamment pour les parcelles dont la forme se joint par un point (banane dont les points extrémités se touchent) : mais je ne t'apprends surement rien !
Je ne pense pas que le DXF-PCI ait évolué depuis ni l'interface Edigeo-APIC, DXF-APIC mais je ne suis pas ca de trés près.
Hors ligne
