[RÉSOLU] Coordonnées trop grandes d' InsertionPoint sur référence de blocs

[IncZ170]

Bonjour à tous et à toute,

Tout d'abord merci pour ce forum et merci pour les tutos qui m'ont largement aidé à rendre ma vie plus belle au travail <3

 

J'ai appris le lisp grâce à "Introduction à AutoLISP par Gilles " et aussi plus récemment le site da-code, merci à vous aussi.

 

J'ai fais quelques petits programmes qui m'ont tous fais bien galérer, mais bref

 

Aujourd'hui j'attaque les blocs ! Pas facile mais on lâche rien!

 

Alors voilà j'ai des référence de blocs avec des Z à 0 et je veux sortir un .txt avec les coordonnées xyz

 

Je commence a faire mon petit lisp tranquillou et la le gars veux pas me sortir les bonnes coordonnées des points d'insertion (j'ai envie de le tuer) alors je me suis dis qu'il y aurait peut-être la solution ici. Voici les deux petit test :

 

Un en lisp et l'autre en Vlisp (c'est du test pour comprendre hein on vas pas chercher la petite bête pour le moment) :

 

(defun c:EXPORT2 (/ sel selname block n)

(setq sel (ssget '((0 . "INSERT"))))

(setq n 0)

(repeat (sslength sel)

(setq selname (ssname sel n))

(setq block (entget selname))

(princ block)

(princ "\n")

(setq n (+ 1 n))

)

(princ "\nSortie\n")

(princ)

)

 

 

(defun c:EXPORT1 (/ sel ent lst lignes elem f)

(vl-load-com)

 

(setq jeu (ssget '((0 . "INSERT"))))

 

(setq n 0)

(repeat (sslength jeu)

(setq entvla (vlax-ename->vla-object (ssname jeu n)))

(vlax-dump-object entvla)

(setq prop (vlax-get entvla 'InsertionPoint))

(princ "\n")

(princ prop)

(princ "\n")

(setq n (+ 1 n))

)

(princ "\nSortie\n")

(princ)

)

 

Les coordonnées de mon objet sont normalement x= 846695.373 y= 6527244.47 z= 0 mais ici dans les deux cas il me sort

846695.0 6.52724e+006 0.0

 

Mon instinct me dit qu'ici le problème vient peut-être de coordonnées trop grande mais j'ai besoin des valeurs après la virgule alors je suis un peu perdu.

 

Si quelqu'un a une idée de comment récupérer les bonnes coordonnées je suis preneur !!

 

Encore merci !

[Elun]

Salut !

 

Je me permet de répondre à ton post étant donné que j'ai le même problème que toi. Le souci vient en effet des nombres trop élevés. AutoCAD utilise donc la notation scientifique pour le transfert des données car les calculs se font en 64bits.

 

Je te met le lien vers les réponses qu'on pu m'apporter bonuscad et (gile) sur mon post : http://cadxp.com/topic/48425-coordonnees-dun-point-via-entget/

 

En espérant que ça puisse t'aider un peu ^^

[didier]

coucou

 

Je ne suis pas certain de comprendre mais avec un RTOS tu règles ton "souci"

(rtos 6.52724e+006 2 3)

Renvoie "6527240.000"

 

Amicalement

 

[Elun]

Oui le rtos te renvoie une valeur en notation décimale, mais impossible d'utiliser des fonctions mathématiques avec un string.

Si l'on fais (atof (rtos 6.52724e+006 2 3)), il renvoie 6.52724e+006 et non 6527240.000.

 

Je n'ai pas vraiment eu le temps de voir une méthode depuis mon dernier message sur ce post mais je pense que la seule solution à ce jour reste la fonction (equal fuzz). Je n'ai pas eu d'erreur de lecture de coordonnées en rentrant ça.

 

Après pour en revenir à ton problème Inc, si tu souhaites uniquement écrire un fichier texte avec ces coordonnées (sans manipulations) le (rtos) sera bon en effet mais si tu as besoin d'effectuer des opérations sur tes exports, ça risque d'être plus délicat.

 

Elun

[didier]

Coucou

 

C'est parce qu'il est question de fichier TXT que j'ai répondu ça

Si on doit "travailler" avec ces nombres ça fonctionne sans rien changer quel que soit l'affichage

 

Amicalement

 

[IncZ170]

Merci de vos réponses :)

 

J'ai parcouru le post que tu m'as transféré Elun, merci !

C'est super intéressant, je vais tester tous ça!

Mon problème c'est surtout d'avoir la valeur avant la virgule (entière) et après la virgule au cm minimum.

Ce qui n'est pas le cas pour le moment, la notation scientifique ne me gène pas (ou plus avec vos info :) ), c'est plutôt la perte de précision.

J'ai vue les différentes méthodes pour avoir des coordonnées moins grande, il faut que je test.

 

En tous cas merci beaucoup pour vos réponses je vous tiens informée des résultats !

 

Pour info :

 

Mon but est de faire une extraction de référence de bloc .txt style :

 

Ename x y z

 

Pour toutes les références de bloc de mon dessin.

 

Rechercher ma valeurs de Z sur des rasters contenant des infos de Z issu de nuages de points (avec OSGEO et du python)

J'ai besoin d'un minimum de précision pour être sur d'être dans le bon pixel de mon raster.

Ainsi pouvoir modifié ce .txt pour mettre les valeurs de Z.

Ensuite :

"Importer" le .txt dans Autocad pour retrouvé les blocs de mon dessin grâce à leurs ename et venir modifier la valeurs de Z de ces blocs!

Je n'aurai à mon avis pas de problème de grandes coordonnées avec le Z.

 

Possible? Je ne sais pas encore! Seul l'avenir nous le dira!

[didier]

Coucou

 

Dans la première partie tu parles de perte de précision, ce n'est aucunement le cas, l'affichage tronqué n'est qu'une "paresse" de l'ordi.

 

Ensuite tu parles d'ENAME mais je me permets de te conseiller les HANDLE car l'ENAME change à chaque session d'AutoCAD le HANDLE est persistant quant à lui, donc si tu fermes ton fichier et que tu relances ta routine ça marchera toujours, pas avec le ENAME.

 

Amicalement

 

[IncZ170]

Merci Didier,

 

J'ai bien la bonne valeur qui est écrit dans mon fichier texte !!

 

Ma fonction ressemble donc a ca :)

 

(defun c:EXPORT1 (/ jeu n x f)
(vl-load-com)
(setq jeu (ssget '((0 . "INSERT"))))
(setq n 0)
(repeat (sslength jeu)
(setq x (rtos (car (vlax-get (vlax-ename->vla-object (ssname jeu n)) 'InsertionPoint)) 2 4))
(setq f (open (getfiled "Exporter les blocs" "" "txt" 1) "w"))
(write-line x f)
(setq n (+ 1 n))
)
(close f)
(princ "\nSortie\n")
(princ)
)

 

Merci pour votre aide :)