As I have a vested interest in storing AutoCad stuff in PostgreSQL, I
searched for something like this a while ago and I ran across this..
I haven't really had a chance to play with it yet
I'm personally interested in the idea of versioning for a drawing.
Instead of storing the entire drawing for each version, one could
theoretically just store the vector additions/changes/deletions that
happen from one revision to the next.
On Oct 30, 2007, at 11:34 AM, Bob Pawley wrote:
> If your holy grail is the ability of using infomation to drive
> drawings I have to ask if you have any idea what that could lead too?
> - Design productivity would increase by factors of hundreds -
> perhaps thousands.
> - Information would be infinitly adaptable.
> - Structure that information properly and knowedge will result.
> - We would begin to realize the full potential of computing power.
> Is that what you were saying??
> ----- Original Message ----- From: "Richard Broersma Jr"
> To: <pgsql-general(at)postgresql(dot)org>; "Andy" <nospam(at)noplace(dot)com>
> Sent: Monday, October 29, 2007 9:13 PM
> Subject: Re: [GENERAL] PostgreSQL and AutoCad
>> --- On Thu, 10/25/07, Andy <nospam(at)noplace(dot)com> wrote:
>>> >> Is there any way of converting text from an
>>> AutoCad (.dwg ot .dxf) file into
>>> >> a PostgreSQL Database??
>>> Do you want AutoCad to edit the drawings right out of the
>>> database? How
>>> would you want to put them in/get them out, of the
>> I think the more traditional problem is to extract information
>> embedded (within blocks) in a drawing to produce a bill of
>> material. As long as the text is stored in a block it is a
>> trivial task. On the other hand, if the text is free floating in
>> the drawing, finding it is a little more difficult but still
>> possible using lisp or vba.
>> Auto cad has prebuilt tools to extract/link data from blocks to
>> any ODBC compliant database. Of course, the holy grail would be
>> to eliminate auto cad altogether and then render drawings from the
>> data stored in the database. :-)
>> Richard Broersma Jr.
>> ---------------------------(end of
>> TIP 6: explain analyze is your friend
> ---------------------------(end of
> TIP 5: don't forget to increase your free space map settings
"Implicit code is inherently evil, and here's the reason why:"
In response to
pgsql-general by date
|Next:||From: Brian Wipf||Date: 2007-10-30 22:18:01|
|Subject: Re: Base Backups from PITR Standby|
|Previous:||From: Oisin Glynn||Date: 2007-10-30 21:45:05|
|Subject: Re: PG windows service issues|