X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=3WqWt8lyEevqGVLHV1sLt+XHGTcPwuRL4olLI3226VU=;
	b=gd/OT+vF67TZeI9N+ZMI3IfJg0Yxwk6P1t96zZoCJRv0Xb/aoKOXCFp+efbTCYhC6z
	Ivunc6w7YgxP69H7cY7j4tnUfu+oJt8o5WWnFunHbPOgrPdzCgzjoVrSnBFwRCKiFMk3
	QWXIHMHAuTHk3eoWJeV1/f3j0ST5WPT7A/Cpm58Ba9UMoRMCB4cZN3weNw2aDO7sCIAh
	9LECsYZ8cKCigFD66bdR0o//hGm+BwRGB5qBTVU9HeQv3b2KMo/6l0NbTvAGk/V2Lwc8
	n9niaW9JETz/8O80NQxO/sobCA3Tv7mEdp1kFBk95hvEr4U0d3B+/AnL6JUAv8bWOvhu
	FS8Q==
MIME-Version:	1.0
X-Received:	by 10.28.11.74 with SMTP id 71mr56896629wml.101.1451248710980;
	Sun, 27 Dec 2015 12:38:30 -0800 (PST)
In-Reply-To:	<20151227113316.b2401441ec634de224120e8f@gmail.com>
References:	<CAC4O8c9zz3X9K-E4fAwjKEdLjNiSLo6FTObDo7vbCm+0yb6ipg AT mail DOT gmail DOT com>
	<20151226214713 DOT 61c9396af946d08bcdbac081 AT gmail DOT com>
	<CAC4O8c9hUX4tEYWyimDVtuTprTxDMKJStu7LgV+5PEw7tod5rw AT mail DOT gmail DOT com>
	<20151227113316 DOT b2401441ec634de224120e8f AT gmail DOT com>
Date:	Sun, 27 Dec 2015 11:38:30 -0900
Message-ID:	<CAC4O8c_OyKXOs4Y5Z1MhJ2AZ5DiLB0pavB5pAr4RXspLGJYYCA@mail.gmail.com>
Subject:	Re: [geda-user] using DRC for other clearance values -- probably a
	bad idea
From:	"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

--001a11443e88e61ec00527e72bf2
Content-Type: text/plain; charset=UTF-8

On Sun, Dec 27, 2015 at 1:33 AM, Nicklas Karlsson (
nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] <
geda-user AT delorie DOT com> wrote:

> > > > I previously said existing DRC could be used for this.
> Unfortunately I
> > > > guess that for cases where larger clearances are desired, it's often
> > > > because of electromagnetic considerations, which means that it's
> probably
> > > > really an inter-layer requirement, which means existing DRC code
> would
> > > not
> > > > be useful.  Sorry.
> > > >
> > > > Britton
> > >
> > > Are they allowed to come close to each other on different layers? Or
> not?
> > >
> >
> > There is no inter-layer bloat, everything is done in-plane (though
> > connection checks follow vias, of course).  So the existing DRC code has
> no
> > chance of enforcing emag clearance requirements, and your original idea
> of
> > simply examining features pairwise is more applicable.  However, that's
> > actually mostly a sub-case of a general keep-out mechanism which is
> > probably something pcb wants as well (or perhaps there are already ways
> of
> > doing this that I'm not aware of).
> >
> > Britton
>
> The hard problem I consider is:
>   1. Calculate which drawing primitives intersect, hardest problem.
>   2. Figure out which drawing primitives belong to the net probably need
> (1.).
>   3. To some extent shape of the grown object or bloat as you call it.
>
> There may be some problems to find the objects in the data but this is
> most probably only about good efficiency. I think code could be reused for
> the hardest problem the three points above.
>

The existing code can definitely tell you which components connect of
course.  Once you have all the primitives, you could go through and do
proximity tests with other nearby things.  Note that you may not be able to
use the existing rtree stuff as a course filter: I'm not sure it will tell
you about things on other layers.

Britton

--001a11443e88e61ec00527e72bf2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Dec 27, 2015 at 1:33 AM, Nicklas Karlsson (<a href=3D"mailto:ni=
cklas DOT karlsson17 AT gmail DOT com">nicklas DOT karlsson17 AT gmail DOT com</a>) [via <a href=
=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <span dir=3D"l=
tr">&lt;<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-use=
r AT delorie DOT com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; =
&gt; &gt; I previously said existing DRC could be used for this.=C2=A0 Unfo=
rtunately I<br>
&gt; &gt; &gt; guess that for cases where larger clearances are desired, it=
&#39;s often<br>
&gt; &gt; &gt; because of electromagnetic considerations, which means that =
it&#39;s probably<br>
&gt; &gt; &gt; really an inter-layer requirement, which means existing DRC =
code would<br>
&gt; &gt; not<br>
&gt; &gt; &gt; be useful.=C2=A0 Sorry.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Britton<br>
&gt; &gt;<br>
&gt; &gt; Are they allowed to come close to each other on different layers?=
 Or not?<br>
&gt; &gt;<br>
&gt;<br>
&gt; There is no inter-layer bloat, everything is done in-plane (though<br>
&gt; connection checks follow vias, of course).=C2=A0 So the existing DRC c=
ode has no<br>
&gt; chance of enforcing emag clearance requirements, and your original ide=
a of<br>
&gt; simply examining features pairwise is more applicable.=C2=A0 However, =
that&#39;s<br>
&gt; actually mostly a sub-case of a general keep-out mechanism which is<br=
>
&gt; probably something pcb wants as well (or perhaps there are already way=
s of<br>
&gt; doing this that I&#39;m not aware of).<br>
&gt;<br>
&gt; Britton<br>
<br>
The hard problem I consider is:<br>
=C2=A0 1. Calculate which drawing primitives intersect, hardest problem.<br=
>
=C2=A0 2. Figure out which drawing primitives belong to the net probably ne=
ed (1.).<br>
=C2=A0 3. To some extent shape of the grown object or bloat as you call it.=
<br>
<br>
There may be some problems to find the objects in the data but this is most=
 probably only about good efficiency. I think code could be reused for the =
hardest problem the three points above.<br></blockquote><div><br></div><div=
 style=3D"">The existing code can definitely tell you which components conn=
ect of course.=C2=A0 Once you have all the primitives, you could go through=
 and do proximity tests with other nearby things.=C2=A0 Note that you may n=
ot be able to use the existing rtree stuff as a course filter: I&#39;m not =
sure it will tell you about things on other layers.</div><div style=3D""><b=
r></div><div style=3D"">Britton=C2=A0</div><div><br></div></div></div></div=
>

--001a11443e88e61ec00527e72bf2--

- Raw text -