Better handling of unplated vias

[dkogan55]

The attached patch adds checks in the geometry intersection functions to no longer treat unplated vias (mounting holes) as conducting. The implementation in the patch will act as if the unplated via doesn't intersect with metal objects at all, which is possibly not what is desired. Should the conductivity check happen on a higher level from the geometry intersection routines? A case that would require this is not obvious to me.

[Russ Dill (russ-dill)]

I think a better fix would be to make a no-go net, and cause the mounting holes to conduct that net. Any connection to the no-go net would cause a DRC failure as well as anything being too close to the no-go net.

[DJ Delorie (djdelorie)]

We already have "too close to hole" warnings, I think forcing holes to *never* touch active nets is too restrictive. But, we can rediscuss that issue if/when we rewrite DRC :-)

[gpleda.org commit robot (gpleda-launchpad-robot)]

Bug was fixed by a commit
git master commit c8a5c4266d99f345c241e41ee15df9bf808a92f3
http://git.gpleda.org/?p=pcb.git;a=commit;h=c8a5c4266d99f345c241e41ee15df9bf808a92f3

commit c8a5c4266d99f345c241e41ee15df9bf808a92f3
Author: Dima Kogan <email address hidden>
Commit: DJ Delorie <email address hidden>

    Better handling of unplated vias

    The attached patch adds checks in the geometry intersection functions to
    no longer treat unplated vias (mounting holes) as conducting. The
    implementation in the patch will act as if the unplated via doesn't
    intersect with metal objects at all, which is possibly not what is
    desired. Should the conductivity check happen on a higher level from the
    geometry intersection routines? A case that would require this is not
    obvious to me.

    Closes-bug: lp-699499