Décalage de polyligne - 2 valeurs différentes

[bonuscad]

Peut être avec une impression DXB ou un export WMF...

 

C'est sûr! mais cela complique alors les choses.

 

Pour en revenir au code de zebulon, je trouve que sa 1ere solution était meilleurs que le pas de résolution introduit par la suite.

 

Il n'y a qu'a voir le résultat avec les largeurs en mode arc avec REMPLIR inactif.

On voit que la résolution c'est faite par la division d'arc et non par une résolution par longueur de segment. Cette dernière peut être excessive pour des arc avec grand rayon et insuffisante pour des arc à petit rayon.

 

1/36 de pi/2 semble être une bonne valeur par défaut au lieu d'en demander une à l'utilisateur.

 

Exemple:

((lambda ( / p1 p2 ll pt_m px1 px2 key p3 px3 px4 pt_cen rad inc ang nm lst_pt pa1 pa2)
 (initget 9)
 (setq p1 (getpoint "\nFirst point: "))
 (initget 9)
 (setq p2 (getpoint p1 "\nNext point: "))
 (setq
   ll (list p1 p2)
   pt_m
   (mapcar
     '/
     (list
       (apply '+ (mapcar 'car ll))
       (apply '+ (mapcar 'cadr ll))
       (apply '+ (mapcar 'caddr ll))
     )
     '(2.0 2.0 2.0)
   )
   px1 (polar pt_m (+ (angle p1 p2) (* pi 0.5)) (distance p1 p2))
   px2 (polar pt_m (- (angle p1 p2) (* pi 0.5)) (distance p1 p2))
 )
 (princ "\nLast point: ")
 (while (and (setq key (grread T 4 0)) (/= (car key) 3))
   (cond
     ((eq (car key) 5)
       (redraw)
       (setq
         p3 (cadr key)
         ll (list p1 p3)
         pt_m
         (mapcar
           '/
           (list
             (apply '+ (mapcar 'car ll))
             (apply '+ (mapcar 'cadr ll))
             (apply '+ (mapcar 'caddr ll))
           )
           '(2.0 2.0 2.0)
         )
         px3 (polar pt_m (+ (angle p1 p3) (* pi 0.5)) (distance p1 p3))
         px4 (polar pt_m (- (angle p1 p3) (* pi 0.5)) (distance p1 p3))
         pt_cen (inters px1 px2 px3 px4 nil)
       )
       (cond
         (pt_cen
           (setq 
             rad (distance pt_cen p3)
             inc (angle pt_cen p1)
             ang (+ (* 2.0 pi) (angle pt_cen p3))
             nm (fix (/ (rem (- ang inc) (* 2.0 pi)) (/ (* pi 2.0) 36.0)))
             lst_pt '()
           )
           (if (zerop nm) (setq nm 1))
           (repeat nm
             (setq
               pa1 (polar pt_cen inc rad)
               inc (+ inc (/ (* pi 2.0) 36.0))
               pa2 (polar pt_cen inc rad)
               lst_pt (append lst_pt (list pa1 pa2))
             )
           )
           (setq lst_pt (append lst_pt (list pa2 p3)))
           (grvecs lst_pt)
         )
       )
     )
   )
 )
 (prin1)
))

[VDH-Bruno]

C'est sûr! mais cela complique alors les choses.

Oui oui c'était juste pour mener au bout l'idée suggéré par le travail avec l'épaisseur.

 

 

Sinon pour la remarque suivante..

Pour en revenir au code de zebulon, je trouve que sa 1ere solution était meilleurs que le pas de résolution introduit par la suite.

Je trouve également meilleur la première solution proposé par zebulon.

 

A+

[La Lozère]

La première solution, selon moi, n'est pas top.

Exemple. Si ma polyligne contient 2 arcs. Le premier d'une longueur de 500ml et le second de 20ml.

Si on entre un nombre de "segmentation" pour que le résultat sur le grand arc soit raisonnable, exemple 1000, soit 1 sommet tout les 50cm. On va se retrouver avec également 1000 sommets pour le petit arc, soit 1 sommet tout les 2cm, et là c'est beaucoup trop.

 

Alors que si on entre un pas de 0.50cm, on retrouve les 1000 sommets pour l'arc de 500ml mais du coup, on a que 40 sommets pour l'arc de 20ml. ce qui est plutôt raisonnable, surtout si par la suite la polyligne sert à autre chose.

[zebulon_]

Disons que la première solution divisait chaque segment courbe en n parties. n étant toujours le même quelle que soit la longueur développée du segment d'arc. Ce qui entraine que les segments d'arc de petite longueur développée sont définis avec plus de précision que les segments à grande longueur développée.

 

La deuxième solution induit une précision du même ordre quelle que soit la longueur développée du segment courbe.

 

Je pense que cette solution doit être plus pratique (et plus compréhensible) pour l'utilisateur, en gardant en mémoire que ça ne fonctionne que pour du tracé routier où on a des rayons très grands et des segments tangents les uns après les autres.

 

On peut aussi progresser tous les 1/36 2pi.

 

Amicalement

Vincent

[zebulon_]

Bonjour,

 

On voit que la résolution s'est faite par la division d'arc et non par une résolution par longueur de segment. Cette dernière peut être excessive pour des arc avec grand rayon et insuffisante pour des arc à petit rayon.

 

l'idée est donc de déterminer la longueur du segment comme une proportion de la valeur du rayon ? Je ne suis pas un spécialiste du tracé routier, mais j'imagine que les rayons utilisés sont tous du même ordre de grandeur. Alors est-ce que c'est utile de paramétrer en fonction du rayon, compte tenu que les valeurs de rayons restent, je pense, voisines ? Si oui, la question qu'on pourrait se poser c'est :

- pour un arc de R=500m, je veux un segment de quelle longueur ?

- pour un arc de R=5000m ?

 

Si on prend comme valeur une longueur de segment de 0.0002xR cela vous semblerait raisonnable, dans le but de densifier les arcs de petit rayon et alléger les arcs de grand rayon ?

 

Amicalement

Vincent

[Olivier Eckmann]

Bonjour,

 

En fait en tracé routier, les rayons sont très variable car définis selon la vitesse de circulation sur la voie concernée. Plus on roule vite, plus les rayons sont importants. Sur une rocade à 90 km/h on va avoir de grand rayon, mais si on arrive sur un giratoire on aura des rayons de 10 ou 15 m pour rentrer et sortir du carrefour.

En règle générale, on travaille par flèche maxi de discrétisation, c'est à dire par écart maximal autorisé entre la corde et l'arc (mesuré au milieu du segment). C'est cette flèche d'approximation qui va conditionner le pas de découpage des arcs.

 

Olivier

[Aleck_Ultimate]

Salut.

 

Dites moi si je pousse le vice un peut loin : et si on recréés une SPligne passant par les points de la plyligne obtenue puis de supprimer cette dernière ?

 

La question du nombre de segment se poserait encore pour les petits rayons, question de poids, mais serait bien moins important pour les grands rayons.

 

Et puis, si un ensemble de trais droit peut suffire, une belle ligne courbe c'est quand-même mieux, non ? Ça rendrait aussi le code plus polyvalent.

 

Cordialy.

[zebulon_]

Bonjour,

 

En fait en tracé routier, les rayons sont très variable car définis selon la vitesse de circulation sur la voie concernée. Plus on roule vite, plus les rayons sont importants. Sur une rocade à 90 km/h on va avoir de grand rayon, mais si on arrive sur un giratoire on aura des rayons de 10 ou 15 m pour rentrer et sortir du carrefour.

En règle générale, on travaille par flèche maxi de discrétisation, c'est à dire par écart maximal autorisé entre la corde et l'arc (mesuré au milieu du segment). C'est cette flèche d'approximation qui va conditionner le pas de découpage des arcs.

 

Olivier

 

et pour un tracé de ligne TGV, on a des rayons encore plus grands, j'imagine !

 

Très bonne idée de prendre la valeur de la flèche pour conditionner le découpage des arcs. J'ai approximé quelque chose en simplifiant, car comme la flèche est petite, le carré de la flèche est négligeable.

 

(defun PTaDroiteObj (obj pt / PTN PM fder PT1DERIV)
 (if (= (type Obj) 'ENAME)
   (setq Obj (vlax-ename->vla-object Obj))
 )
 (setq PTN (vlax-curve-GetClosestPointTo obj PT))
 (setq PM (vlax-curve-GetParamAtPoint obj PTN))
 (setq fder (vlax-curve-getfirstderiv obj PM))
 (setq PT1DERIV (mapcar '+ PTN fder))
 (< (sin (- (angle PTN PT) (angle PTN PT1DERIV))) -1e-14)
)

(defun getpolySegs (ent / PTL I PTB SEG LSEG)
 (if (= (type ent) 'ENAME)
   (setq ent (vlax-ename->vla-object ent))
 )
 ;; collecter la liste des point sous la forme (x1 y1 x2 y2 ... xn yn)
 (setq PTL (vlax-safearray->list (vlax-variant-value (vla-get-Coordinates ENT))))
 ;; collecter la liste des bulges
 (setq I 0) 
 (repeat (/ (length PTL) 2)
   (setq PTB (cons (vla-GetBulge ent I) PTB))
   (setq I (1+ I))
 )
 (setq PTB (reverse PTB))
 ;; polyligne fermée -> rajouter le premier point à la liste de points
 (if (= (vla-get-closed ent) :vlax-true)
   (setq PTL (append PTL (list (car PTL) (cadr PTL))))
 )
 ;; transformer en liste de segments
 (setq I 0)
 (repeat (- (/ (length PTL) 2) 1)
   (setq SEG
     (list
       (list (nth I PTL) (nth (+ I 1) PTL))
       (nth (/ I 2) PTB)
       (list (nth (+ I 2) PTL) (nth (+ I 3) PTL))
     )
   )
   (setq LSEG (cons SEG LSEG))
   (setq I (+ I 2))
 )
 (reverse LSEG)
)

(defun getArcInfo (segment / a p1 bulge p2 c p3 p4 p r s result)
 ;; assigner variables avec les valeurs de l'argument
 (mapcar 'set '(p1 bulge p2) segment)
 (if (not (zerop bulge))
   (progn
     ;; trouver la corde
     (setq c (distance p1 p2))
     ;; trouver la flèche
     (setq s (* (/ c 2.0) (abs bulge)))
     ;; trouver le rayon par Pythagore
     (setq r (/ (+ (expt s 2.0) (expt (/ c 2.0) 2.0)) (* 2.0 s)))
     ;; distance au centre
     (setq a (- r s))
     ;; coordonnées du milieu de p1 et P2
     (setq P4 (polar P1 (angle P1 P2) (/ c 2.0)))
     ;; coordonnées du centre
     (setq p
       (if (>= bulge 0)
         (polar p4 (+ (angle p1 p2) (/ pi 2.0)) a)
         (polar p4 (- (angle p1 p2) (/ pi 2.0)) a)
       )  
     )
     ;; coordonnées de P3
     (setq p3
       (if (>= bulge 0)
         (polar p4 (- (angle p1 p2) (/ pi 2.0)) s)
         (polar p4 (+ (angle p1 p2) (/ pi 2.0)) s)
       )  
     )
     (setq result (list p r))
   )
   (setq result nil)
 )
 result
)

(defun getptsegd (SEG PT)
   (mapcar 'set '(P1 BULGE P2) SEG)
   (if adroite 
      (setq ANG (* 3 (/ pi 2)))
      (setq ANG (/ pi 2))
   )
   (polar PT (+ (angle P1 P2) ANG) (+ decd (* (- decf decd) (/ (vlax-curve-getDistAtpoint obj PT) LongObj))))
)

(defun getptsegc (SEG PT)
   (mapcar 'set '(P1 BULGE P2) SEG)
   (setq PTC (car (getarcinfo SEG)))
   (if adroite 
      (setq ANG pi)
      (setq ANG 0)
   )
   (if (> BULGE 0)
     (setq ANG (+ (angle PT PTC) ANG))
     (setq ANG (+ (angle PTC PT) ANG))
   )
   (polar PT ANG (+ decd (* (- decf decd) (/ (vlax-curve-getDistAtpoint obj PT) LongObj))))
)


(defun c:decvar ()

 ;; valeur de décalage au départ
 (if (not decd) (setq decd 0.20))
 (setq tmp (getdist (strcat "\nSpécifier la distance de décalage à l'origine  <" (rtos decd) "> : ")))
 (if tmp (setq decd tmp))

 ;; valeur de décalage à la fin
 (if (not decf) (setq decf 0.50))
 (setq tmp (getdist (strcat "\nSpécifier la distance de décalage à la fin  <" (rtos decf) "> : " )))
 (if tmp (setq decf tmp))

 (setq e (car (entsel "\nSélectionner la polyligne à décaler : ")))
 (setq pt (getpoint "\n Spécifiez un point sur le côté à décaler : "))

 ;; précision des parties courbes
 (if (not PREC_COURBE) (setq PREC_COURBE 0.1))
 (setq tmp (getdist (strcat "\nValeur approximative de la flèche de polygonisation des parties courbes  <" (rtos PREC_COURBE) "> : ")))
 (if tmp (setq PREC_COURBE tmp))
 
 (setq obj (vlax-ename->vla-object e))
 (setq LongObj (vla-get-length obj))

 (setq adroite (PTaDroiteObj obj (trans PT 1 0)))

 (setq Lsegs (getPolySegs obj))
 ;; le premier point
 (setq SEG (car Lsegs))
 (mapcar 'set '(P1 BULGE P2) SEG)
 (if (zerop BULGE)
   (setq LPT (list (getptsegd SEG (vlax-curve-getPointAtDist obj 0.0)))) ;; c'est un segment droit
   (setq LPT (list (getptsegc SEG (vlax-curve-getPointAtDist obj 0.0)))) ;; c'est un segment courbe
 )
 ;; les points suivants
 (while Lsegs
   (setq SEG (car Lsegs))
   (setq lsegs (cdr Lsegs))
   (mapcar 'set '(P1 BULGE P2) SEG)
   (if (zerop BULGE) ;; c'est un segment droit
     (progn
       (setq PT (getptsegd SEG P2))
       (setq LPT (cons  PT LPT))
     )
     (progn  ;; c'est un segment courbe
       (setq PKdebut (vlax-curve-GetDistAtPoint obj P1))
       (setq PKfin (vlax-curve-GetDistAtPoint obj P2))
       (setq Larc (- PKfin PKdebut))
       (setq R (cadr (getarcinfo SEG)))
       (setq X (* 2 (sqrt (* 2 R PREC_COURBE)))) ;; estimation corde
       (setq NBPAS (fix (/ Larc X)))
       (setq PAS (/ Larc NBPAS))  ;; je coupe les courbes en NBPAS segments droits de longueur environ X
       (setq PKcourant (+ PKdebut PAS))
       (repeat NBPAS
         (setq LPT (cons (getptsegc SEG (vlax-curve-GetPointAtDist obj PKcourant)) LPT))  ;; un point à chaque pas
         (setq PKcourant (+ PKcourant PAS))
       ) ;; repeat
     ) ;; progn
   ) ;; if
 ) ;; while       
 (setq LPT (reverse LPT))

 (command "_pline")
 (while LPT
   (setq PT (car LPT))
   (setq LPT (cdr LPT))
   (command "_non" (trans PT 0 1))
 )
 (command "")

 (princ)
)

 

à voir si à l'usage c'est mieux.

 

Amicalement

Vincent

Modifié le 28 septembre 2017 par zebulon_

[zebulon_]

Bonsoir à tous,

 

alors, qu'est ce que cette façon de procéder vous inspire ?

 

Merci pour le retour

 

Amicalement

Vincent

[lili2006]

Bonsoir à toutes et tous,

 

Salut Vincent,

Je viens de tester rapidement, c'est tout simplement génial,...

[lili2006]

Re,

 

Si je veux descendre en dessous de 0.10 pour la discrétisation de la flèche, j'ai ce message =>

 

http://zupimages.net/up/17/39/5jhk.png

 

C'est normal Doc ?

[Olivier Eckmann]

Salut,

 

dans la ligne

  (setq tmp (getint (strcat "\nValeur approximative de la flèche de polygonisation des parties courbes  <" (rtos PREC_COURBE) "> : ")))

 

tu remplaces getint par getreal

  (setq tmp (getreal (strcat "\nValeur approximative de la flèche de polygonisation des parties courbes  <" (rtos PREC_COURBE) "> : ")))

 

 

Olivier

[zebulon_]

oui j'ai oublié de changer la fonction : la première mouture demandait un nombre entier de divisions. Le getint est resté par erreur. Et comme pour le test j'ai tapé sur entrée pour prendre la valeur par défaut, je ne me suis pas rendu compte.

 

Il faut donc changer la fonction comme l'indique très justement Olivier, au bémol près que je préfère utiliser getdist au lieu de getreal.

 

J'ai corrigé le code ci-dessus et le code précédent aussi, car il présentait la même erreur.

 

Amicalement

Vincent

[La Lozère]

Hello,

Je vois que ma "petite" ;) demande captive les foules... tant mieux.

 

Effectivement, la notion de corde, avec mes notions sur Covadis/Autopiste est quelque chose qui me parle plus. C'est parfait.

 

Merci Vincent.

[zebulon_]

Hello,

Je vois que ma "petite" ;) demande captive les foules... tant mieux.

 

Effectivement, la notion de corde, avec mes notions sur Covadis/Autopiste est quelque chose qui me parle plus. C'est parfait.

 

Merci Vincent.

Bonjour,

 

Si ça captive, c'est que ça doit être utile !

 

A charge de revanche !

 

A ce sujet, je profite de cette tribune pour adresser une demande à l'ensemble des traceurs de routes :

- évitez de mettre une clothoïde au droit d'un pont ;

- quand vous concevez un rétablissement, mettez de préférence un arc centré sur la pile centrale de l'ouvrage. Cela n'a l'air de rien, mais ça donne des ouvrages symétriques avec 2 culées strictement identiques ;

- quand vous pouvez, prévoyez les rétablissements à 100gr, sinon évitez autant que possible les biais inférieurs à 70gr.

 

En gros, considérez que les ouvrages d'art sont une grosse contrainte supplémentaire dans votre projet, pas seulement en matière de gabarit, qui est le minimum syndical. Combien de fois on se complique la tâche en aval parce qu'on se l'est simplifiée en amont. Genre, on a le point haut du profil en long à 50cm (voire moins...) de l'axe de la pile et, de ce fait, deux culées différentes pour 5mm de nivellement. Ou une cloth qui commence à 5m avant la fin du viaduc. Ou des biais de 50gr etc.

 

Mon expérience prouve qu'il arrive souvent que ces points soient négligés en avant projet et qu'on traine le boulet jusqu'en exécution.

 

Merci

Amicalement

Vincent

[thierry.garré]

Remarques très intéressanttes et constructives. Merci.

 

Petite question

 

Modélise tu tes ouvrages en 3D ? et si oui sur quel logiciel ?

[dilack]

Bonjour,

de mémoire les 70gr est une norme (rff/sncf/Setra.... Je ne sais plus) des rétablissement des PRA.

Ça fait longtemps que j'ai pas fait de ferroviaire !

Cordialement

[Olivier Eckmann]

@Zebulon : personnellement, je préfère le getreal au getdist pour 2 raisons:

- comme on est en vue de dessus, mais avec des objets en Z (points topo, lignes caract...) on risque d'accrocher des points 3D => une distance 3D relativement longue alors que la valeur est utilisée en 2D uniquement

- la valeur de discrétisation n'est généralement pas donnée par une distance graphique à l'écran, mais par une valeur d'approx liée à l'échelle du plan ou au type d'étude.

Le seul intérêt de getdist c'est que la valeur retournée ne peut pas être négative, mais comme elle peut être nulle et qu'il faudra(it) tester cette valeur, autant tester que c'est >0 après le getreal (voir supérieure à 1cm peut-être).

Je sais que l'on peut répondre une valeur numérique directement à un getdist sans saisir de point, mais je trouve plus sûr d'utiliser le getreal.

 

Après tout se discute!

 

Olivier

[zebulon_]

Bonjour,

de mémoire les 70gr est une norme (rff/sncf/Setra.... Je ne sais plus) des rétablissement des PRA.

Ça fait longtemps que j'ai pas fait de ferroviaire !

Cordialement

 

En dessous de 70gr, ça devient des ouvrages qualifiés de "très biais" qui demandent des modélisations de calcul différentes. De plus, on imagine bien qu'un tablier qui a la forme d'un parallélogramme très "aplati" peut poser des problèmes de différents ordres : décollement des appuis en élastomère fretté, fragilité de l'angle aigu, ferraillage plus complexe (on ne peut plus ferrailler biais, il faut ferrailler droit et gérer les zones de variation dans les coins), culées, piles, joints de chaussée très longs etc.

 

Remarques très intéressantes et constructives. Merci.

Petite question

Modélise tu tes ouvrages en 3D ? et si oui sur quel logiciel ?

 

ça m'arrive. Quand je le fais c'est avec Autocad. En fait, quand je réalise des plans de coffrage des appuis, je rajoute presque toujours une isométrie sur le plan, afin que le maçon comprenne plus rapidement ce qu'on attend de lui. Du coup, une fois que les appuis sont modélisés, c'est facile de les rassembler dans un fichier et de rajouter le tablier.

Par exemple ici ou là

 

Amicalement

Vincent

[zebulon_]

@Zebulon : personnellement, je préfère le getreal au getdist pour 2 raisons:

- comme on est en vue de dessus, mais avec des objets en Z (points topo, lignes caract...) on risque d'accrocher des points 3D => une distance 3D relativement longue alors que la valeur est utilisée en 2D uniquement

- la valeur de discrétisation n'est généralement pas donnée par une distance graphique à l'écran, mais par une valeur d'approx liée à l'échelle du plan ou au type d'étude.

Le seul intérêt de getdist c'est que la valeur retournée ne peut pas être négative, mais comme elle peut être nulle et qu'il faudra(it) tester cette valeur, autant tester que c'est >0 après le getreal (voir supérieure à 1cm peut-être).

Je sais que l'on peut répondre une valeur numérique directement à un getdist sans saisir de point, mais je trouve plus sûr d'utiliser le getreal.

 

Après tout se discute!

 

Olivier

 

c'est vrai que je préfère getdist uniquement parce qu'on peut saisir deux points et que le résultat est toujours positif (ou nul !). Quoique, si on tape un négatif à l'invite de getdist, getdist renvoie le négatif.

Commande: (getdist)

-5.241

-5.241

 

Si ce n'est pas une distance mesurable graphiquement autant prendre getreal.

 

Le programme est assez brut de décoffrage : il n'y a aucun test de validité :

- est-ce que l'utilisateur saisit une polyligne, oui ou non ?

- est-ce que l'utilisateur saisit des valeurs non nulles et positives ?

- que se passe-t-il si le décalage est plus grand que le rayon du cercle, lorsqu'on se décale vers le centrre ?

ce genre de choses

 

Amicalement

Vincent

[lili2006]

Bonsoir à toutes et tous,

 

En effet, Merci Vincent pour ces rappels constructifs non négligeables,...

[didier]

Coucou

 

Je me suis intéressé à ce message mais sans pouvoir trouver et donc proposer une réponse

Le manque de temps vous savez ce que c'est surtout dans mes conditions exotiques.

Par contre, ayant regardé ce qui a été proposé je ne trouve pas le résultat juste dans la réponse #33

Je constate néanmoins que La Lozère est content quant à lui mais je persiste à dire que le décalage est incorrect

Le travail fourni est conséquent et je ne manque de respect à personne, je vais essayer de trouver du temps pour proposer quelque chose.

Chez vous ne constatez-vous pas des dysfonctionnements dans le résultat du décalage ?

Si c'est moi qui suit dans le faux je ferai un mea culpa mais j'ai bien vérifié avant de prendre la parole.

 

Amicalement

[lecrabe]

Hello Didier - Grand Maitre Sablonneux & Caillouteux & Desertique & Montagnard

 

Je suppose que tu as une belle polyligne avec son Decalage incorrect !?

 

Est il possible que tu partages avec nous ton tresor ?

 

Bonne Soiree, Bye, lecrabe

[didier]

Coucou

Bien sûr que si je trouve quelque chose à partager je le ferai

Pour l'instant je suis dans l'incapacité d'écrire du lisp mais ce que j'ai vu ne me convient pas ou du moins ce qui est créé par la routine n'est pas ce que je nomme un "décalage"

Je vous tiens au courant mais pour l'instant je me pose encore la question de savoir si je suis dans le vrai en disant que ça fonctionne certes mais que le décalage obtenu n'est pas satisfaisant, en dehors des courbes, ce sont les sommets que je critique

Toujours dans le positif et le constructif bien sûr.

 

Amicalement

[zebulon_]

Bonjour,

 

la critique constructive est toujours la bienvenue. Je n'ai aucune prétention dans le domaine du tracé routier, autre que celle d'en être un utilisateur. En effet, c'est conseillé de mettre le pont à l'intersection de deux routes. Je n'utilise donc qu'un produit fini pensé par un autre et n'ai jamais conçu un projet routier.

 

Je suis d'accord avec lecrabe qui demandait, non pas de réécrire un lisp, mais de fournir un dwg avec un exemple de décalage incorrect. En expliquant où et pourquoi c'est faux, je pourrai certainement corriger le lisp.

 

En quelques mots le principe du lisp (qui est peut être critiquable aussi) : pour chaque sommet, je crée un nouveau sommet obtenu par décalage perpendiculairement à l'original. La valeur du décalage est linéaire en fonction du pk de l'original. A chaque sommet, je ne prends en compte que le segment précédent pour faire la perpendiculaire. De ce fait, si les segments ne sont pas tangents, le résultat sera incohérent.

 

Amicalement

Vincent