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=date:from:to:subject:message-id:in-reply-to:references:mime-version
	:content-type:content-transfer-encoding;
	bh=A1hwRGlLpHXpT33jVP5vKJCbUs3rkR6gw3uEKzHiUmg=;
	b=BDgUywYW1AL3XRcu13HzlYPdxHAHsO6f5fKefXJdTTkx0tyDUUul22iWt2pfftaDS6
	H1t45t4Zqbi2KC1eYjrsCLue7kbMP8ryaLpQZdPdnZYwVVpFn1zV0LDT3m4bQD7Dwdr2
	94MmeuEgjipoApJCr4UgudJnAlTKckI87rj0/W9bP/quFZrq9us3yUgUeETCpX8tTPE9
	ZhXJxAYO03tdr64ccTP88fvEl7/+6q97OZyw1UsHZTxF76KUD9HpTzF4iXIySBDLo41H
	q7Qz/qarLBHCLLhAK2LwWYI+9HUQjt7KH5pBTy6iWe8qhyP1IXaIhtvJwCx4cWvMSRaB
	zY1w==
X-Received:	by 10.152.44.196 with SMTP id g4mr24203456lam.56.1440481077630;
	Mon, 24 Aug 2015 22:37:57 -0700 (PDT)
Date:	Tue, 25 Aug 2015 07:37:46 +0200
From:	"Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] pcb file format (functions to walk thru by
	different properties)
Message-Id:	<20150825073746.ed8c2694bf0f0798782c8afb@gmail.com>
In-Reply-To:	<20150824223846.0ba61ba7@jive.levalinux.org>
References:	<20150824223846 DOT 0ba61ba7 AT jive DOT levalinux DOT org>
X-Mailer:	Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version:	1.0
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

I also thought about this.

Sometimes it is useful to walk thru the footprints in refdes order but for other cases it is useful to walk thru the footprints in type order. There may also be cases there it is useful to walk thru the nets and for each net walk thru the connected footprints.

I came to the conclusion it is more important to have these functions to search the footprints in different orders than which file format is used.


Regards Nicklas Karlsson



On Mon, 24 Aug 2015 22:38:46 +0200
"Lev (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> wrote:

> I started to write a script that generates an sqlite database from pcb
> footprint objects to be able to easily generate pick and place data, and
> other useful information.
> 
> So I started to write the scheme of the database, then I found myself in
> defining a complete database structure for PCB data.
> 
> Here I propose the file format of the next generation of PCB. The file is an
> sqlite database. This is not uncommon in EDA; Zucken's CR5000 product has its
> file format as a database.
> 
> Take a look at tree.txt. You can define primitive object, that is oval,
> rectangle, etc, and you can define pcb, and component objects. There is
> one table that lets you attach (many to many relation) objects to each
> other. There are relations, that doesn't make any sense, i.e. attaching
> a pcb object to a primitive object.
> 
> However, you can attach pcb to a pcb. Footprint in this sense is a
> sub-pcb. There is a 'component' object, but this can be omitted, or
> just simply a placeholder for refdes, and other data.
> 
> Coordinates are relative to parent object's 0 point.
> 
> With this data format, one can define arbitrary footprints. No restrictions
> like "no silkscreen polygons".
> 
> Lot of things are missing, like texts. This is just a sketch.
> 
> Okay. I'm not a database architect, and you can now start throwing eggs,
> potatoes, tomatoes. Please be gentle. I know, it is hard to diff (but you
> can make a nice difftool for this). I know that sqlite is yet another
> dependency, but makes it very easy to work with PCB data.
> 
> Attached is scheme.sql and the tree.txt.
> 
> 
> Lev
> 
> -- 
> 73 de HA5OGL
> Op.: Levente

- Raw text -