Coordonnées d'un point via (entget)

[Elun]

Bonjour,

 

J'ai remarqué à plusieurs reprises que sur certains DWG (notamment lorsqu'on travaille sur des fichiers géo-référencés) les coordonnées des points que l'on récupère via la fonction (entget) sont notées en notation scientifique (voir les codes DXF 10) :

Choix de l'objet: ((-1 . <Nom d'entité: 4c0410f0>) (0 . "LWPOLYLINE") (5 . "2FAE77") (102 . "{ACAD_REACTORS") (330 . <Nom d'entité: 4c0411d0>) (330 . <Nom d'entité: 4c041200>) (102 . "}") (330 . <Nom d'entité: 37f4a9f0>) (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "0") (62 . 82) (100 . "AcDbPolyline") (90 . 53) (70 . 1) (43 . 0.3) (38 . 0.0) (39 . 0.0) (10 1.45964e+06 6.20274e+06) (40 . 0.3) (41 . 0.3) (42 . 0.0) (91 . 0) (10 1.45964e+06 6.20273e+06) (40 . 0.3) (41 . 0.3) (42 . 0.0) (91 . 0) (10 1.45963e+06 6.20271e+06) (40 . 0.3) (41 . 0.3) (42 . 0.0) (91 . 0) (10 1.45963e+06 6.20271e+06) (40 . 0.3) (41 . 0.3) (42 . 0.0) (91 . 0) (10 1.45963e+06 6.20271e+06) (40 . 0.3) (41 . 0.3) (42 . 0.0) (91 . 0) (40 . 0.3) (41 . 0.3) (42 . 0.0) (91 . 0) (10 1.45982e+06 6.2026

5e+06) (40 . 0.3) (41 . 0.3) (42 . 0.0) (91 . 0) (210 0.0 0.0 1.0))

 

Je travaille pourtant en unités métriques et non en notation scientifique. Or si je récupère les coordonnées telles quelles et que je les utilise ailleurs (un (ssget) par exemple), AutoCAD me retourne une erreur ou ne sélectionne rien.

 

Malheureusement je ne vois pas comment contourner cette simplification d'écriture de la part d'AutoCAD.

Si vous avez une idée, je suis preneur ;p

 

PS : Je préfère éviter de passer par du Visual LISP pour le moment si possible.

[bonuscad]

lorsqu'on travaille sur des fichiers géo-référencés) les coordonnées des points que l'on récupère via la fonction (entget) sont notées en notation scientifique

Bonjour,En effet c'est l'inconvénient des coordonnées géo-référencées, (entget) les restitue en coordonnées scientifique, cependant ton nombre est toujours en métrique.

Pour t'en assurer tu peux faire un (rtos (cadr code_dxf_10) 2 16), la valeur retournée sera bien métrique.

 

Or si je récupère les coordonnées telles quelles et que je les utilise ailleurs (un (ssget) par exemple), AutoCAD me retourne une erreur ou ne sélectionne rien.

 

L'utilisation de grande coordonnées fais perdre de la précision dans la partie décimale et malheureusement (ssget) échoue souvent: même des commandes standard comme RACCORD, AJUSTER, CERCLE (option TTR) etc... n'arrivent pas à terme. Il y a eu déjà plusieurs discussions la dessus.

 

Dans les réponses évoquées, déplacer temporairement le dessin près de l'origine pour faire ces opérations. Cela peut être vite fastidieux.

 

Suivant ce que tu veux faire d'autres solutions sont possibles, pour ma part pour un (ssget) j'utilise le mode capture. par exemple:

(ssget "_C" (mapcar '- dxf_10 '(0.05 0.05 0.0)) (mapcar '+ dxf_10 '(0.05 0.05 0.0)))

Ici c'est une boite de 5 cm pour faire la sélection, mais tu peux agrandir ou rétrécir cette boite suivant le besoin.

Cette méthode peut avoir des inconvénients, tu peux récupérer des entités parasite (non voulue) dans ta sélection; dans certain cas...

 

Pour éventuellement fiabilisé une procédure, il faudrait savoir ce que tu veux faire exactement.

 

[Elun]

Merci pour ta réponse,

 

J'avoue n'avoir pas vraiment d'exemple très précis sur ce que je veux faire. C'est notamment pour des bouts de code lorsque je travaille.

 

Par exemple j'ai une fonction qui me récupère la liste des coordonnées de chaque points d'une polyligne sélectionnée. Et si je souhaite utiliser cette polyligne comme tracé de capture pour un (ssget), la sélection est vide.

 

Dans les réponses évoquées, déplacer temporairement le dessin près de l'origine pour faire ces opérations. Cela peut être vite fastidieux.

 

Le soucis dans cette démarche c'est que déplacer un dessin géo-référencé, c'est tendancieusement long.

 

Après ce n'est qu'un exemple parmi tant d'autres, j'utilise assez souvent ces sélections via les polylignes ou par exemple si je souhaite évaluer lorsqu'un point appartient à une polyligne.

[bonuscad]

j'utilise assez souvent ces sélections via les polylignes ou par exemple si je souhaite évaluer lorsqu'un point appartient à une polyligne.

 

Pour information je construit souvent des lisp à la volée pour construire ma base AutocadMap, je suis souvent confronté à ce problème d'évaluation de coordonnées.

 

Cela oblige à faire des codes avec des analyses plus poussées, par exemple avec ton problème utiliser la fonction (equal élément1 élément2 fuzz) fuzz étant une tolérance que tu vas appliquer pour tester si ton point appartient à la polyligne.

 

Pour (ssget) faire attention, car toute les options, hormis (ssget "_X") demande à ce que tous les entités soit contenues dans la vue graphique pour bien fonctionner.

J'utilise souvent un "._zoom" "_object" dans mes routines pour être sur dur retour d'un (ssget "_W") ou (ssget "_C") par exemple.

 

Cela alourdi considérablement le temps d'exécution mais fiabilise les retours des (ssget).

La perte de précision avec les grandes coordonnées reste un problème récurent avec Autocad, il faut faire avec.

 

 

 

[Elun]

Ok, merci pour ces réponses en un temps record !

 

Donc si je comprend bien, la seule méthode que l'on ait à ce jour c'est de prendre les coordonnées "arrondies", et non "exactes" (via (equal+fuzz) ou (atoi (rtos)) par exemple) ?

 

Autrement, en passant par la méthode

(rtos (cadr code_dxf_10) 2 16)

, AutoCAD serait-il capable de l'associer au point de la polyligne ?

 

Pour ma part, j'évite à tout prix les commandes de zoom dans mes lisp en raison du temps d'exécution, j'ai tendance à favoriser les (sssetfirst) pour la visibilité des jeu de sélection filtrés.

 

En tout cas merci beaucoup, je vais travailler là-dessus en espérant trouver une solution viable ;p

[bonuscad]

J'ai peur que l'on ne se soit pas compris complétement.

Je n'aime pas le terme d'arrondies car ce n'est pas le cas, mais imprécision oui, car autocad travaillera toujours avec les coordonnées exactes et pas arrondies.

 

Pour illustrer cette perte de précision

Je fais un point dans un dessin proche de 0,0

Sachant qu'autocad stocke au maximum 16 décimale après la virgule j'obtiens ceci:

(rtos (cadr (assoc 10 (entget (car (entsel))))) 2 16) "149.9572679451084" pour le X

(rtos (caddr (assoc 10 (entget (car (entsel))))) 2 16) "146.4773062445747" pour le Y

 

Je fais un copier avec un point de base à 0,0

Je colle vers les coordonnées d'origine ce même point dans un nouveau dessin.

Je le déplace de 0,0 vers 800000,6500000 pour des coordonnées cartographiques.

Je refais les interrogations précédentes pour avoir les retours:

(rtos (cadr (assoc 10 (entget (car (entsel))))) 2 16) "800149.9572679453"

(rtos (caddr (assoc 10 (entget (car (entsel))))) 2 16) "6500146.477306246"

 

Bien que je demande une précision de 16 chiffres, on peut voir qu'il arrive a ne me fournir que 10 chiffre et que l'imprécision se fait à partir de 9 chiffres.Donc quand tu vas procéder à des calculs cette imprécision retourné par (assoc) : rtos n'est la que pour illustrer cette imprécision car la notation scientifique n'influe en rien la précision ni le calcul, tu vas généré aussi des imprécisions, donc 1E-9 en fuzz pour (equal) pourra valider ton point en coordonnées cartographique, alors que dans le premier dessin un (equal) SANS fuzz aurait très bien fonctionné.

 

En données cartographique la mantisse (chiffre avant la virgule) est au détriment de la partie décimales

Peut être que quand le calcul se fera sur 128 bits au lieu de 64 bits actuel, ce problème disparaitra ou se reportera sur des coordonnée cosmologique

 

[lecrabe]

Hello Bruno

Quand on travaillera en Mode 128 bits, je crains que "cosmologiquement parlant"

nous ne serons plus de ce monde !?

Encore MERCI pour ton aide, Bye, lecrabe "triste"

[Aleck_Ultimate]

Salut.

 

Y'a un truc qui m'échappe vraiment : pourquoi est-ce qu'il n'y a tout simplement pas une variable qui détermine si AutoCAD ne fait qu'un seul calcule avec des imprécisions ou s'il fait plusieurs calculs à la suite pour garder la précision demandée au risque de grand ralentissement ? Ce serait vraiment si compliqué que ça ? Parce que je crois qu'un certains nombre de personne préféreraient ramer de temps en temps que de devoir gérer ses imprécisions, surtout pour ceux qui bossent en géoréférencement.

 

Cordialy.

[(gile)]

Salut,

 

Quand j'ai été confronté à ce genre de problème (par exemple pour trouver des intersections de lignes et de polylignes dans un programme de simulation de sortie de piste) j'ai dû déplacer tout le dessin vers l'origine pour dessiner les lignes et faire les calculs, puis tout replacer à la position initiale. Ces déplacements étaient quasi instantannés (mais ce n'était pas du LISP).

[Elun]

Merci à vous tous,

 

Je vais essayer de creuser un peu plus pour trouver une méthode qui puisse gérer les imprécisions sans trop de problème.

A ce stade, la version avec (equal) me semble pas mal mais pas forcément applicable à toutes les sauces ;p

 

Il reste encore du boulot en effet de ce côté là mais à tout problème existe une solution ,)

 

Encore merci à vous !