Is CAD the right tool for the concept?

I've got hand drawn, paper diagrams showing the plan view of a
theatrical stage showing the geography, the scenery layout, and the
placement of theatrical lighting fixtures.

I've also got seperate documentation about each light fixture shown in
the diagram.

Human beings will enter data about the lights into a database (the easy
part) AND will also nned to "eyeball" the diagram to find where the
lights are, then using some tool must find an enclosing rectangle (with
coordintates of the rectangle's corners) for each such light and enter
all of that information ( the name or URL of the diagram, the unique ID
of the light and the coordinates defining the enclosing rectangle) into
the database.

I'm going to digitize the diagrams and generate a gif or jpeg to display
on a web site (thats how the paper diagram gets a "url" above).

For the first version, I'm going to create an HTML image_map over the
gif or jpeg to give me "clickable" regions, one for each lighting
fixture, which always take me to the same "service" which uses the
light fixture id (passed in as part of the linking URL) to display all
the data from the database about the selected light fixture.

The requirement to to have "clickable" areas, one for each lighting
fixture, which allows the end user viewing the WEB display to visually
"find" a lighting fixture, to click on it, and to see the lighting
fixture information displayed as a result of that select and click
operations.


1. I want to create the website (i.e. the HTML defining the image map
and links etc) using a program which extracts the needed data from the
database to create the (Text) HTML page.

2. I'm asking the following:
2.1 Are there any autocad or related tools that can help with this
low level approach (as perhaps in finding the enclosing rectangles and
getting the coordinate data back to the database)

2.1 Can I do better than a dumb old static image map with some sort
of CAD viewer to put the lighting fixtures onto layers and somhow get
data from the lighting layer (identifying the chosen lighting fixture)
into url links to web services
which "do something" such as fishing out the data about the lighting
fixtures and displaying same.

3.1 Is there some sort of system which can take the gif or jpeg as a
background "map" and then place icons onto the map at run time, being
driven by data specifying the coordinates and the icon image file,
perhaps in some form such as GML or something akin to that?

As you can see, what I'm hoping for is something that works a bit like
the "google world" interface but using local "indoor" coordinates
relative to the "map", not geo spacial latitude and longitude to put
icons over real world maps or sattelite images.


Any ideas?

Thanx in advance

 

OK, assuming I can understand what you're trying to describe.


The point is you want to

We're not using .net
and use

The whole user interface in vector graphics? Egad!
, e.g. a new era of CAD; then save the

Maybe I should find out some more about XAML, thats a new one for me.


I have to admit, I wasnt thinking in terms of representing the whole
application's user interface, including the part where the user sees a
diagram containing "clickable" images, in one overarching vector
graphics framework.

I dont see why I would want the whole interface in vector graphics.
Vector graphics, of course, have the advantage of being "zoom-able" in
or out to any degree with no loss of detail. I suppose being able to
zoom in and out of a diagram could have some use, but its not a
requirement for now.

Also, I'm starting with "analog", plain old paper that needs to be
scanned just to get a .gif or .jpg.

What sort of engine interprets the XAML and renders the picture?

The snippet seems to be saying "Lay down a jpg (url=assets/inages/B.jpg)
as a canvas, and then, place an icon (url=assets/media/C.wma") over it.

What sort of animal is a "wma" ? What whould make the image shown in
"assets/media/C.wma" clickable, and what controls where we link to
(the "anchor" or "Target") if we DO click on it?

Remember that one of my requirements is to generate the HTML (or source
code which at run time produces the HTML) from data we've previously
stored in the database.

A formal notation such as XAML (did I mention GML?) as a means of
communicated the data fetched out of the database to the engine that
does the screen rendering would be a "good thing".

The user interface of web

Focus. We're talking about a web application right now. But on the other
hand, there are other projects, still in the shadowy "dont know what,
dont know when" phase for which multi media will be a consideration, so
something I use now that we allow me to "extend" to multi media later
would also be "a good thing".

So what is the tool that "Reads" the XAML and renders pictures in my
browser?

Again, focus. We're talking about one small bit of "magic" (See a
diagram, click on one of many icons, see the data) which can be
implemented with a plain ordinary everyday HTML image map. The
interesting bit is not the effect per se, but the fact that I generate
the HTML (or code that in turn generates HTML) from data fetched out of
the database at "Extract" time to build the site in the first place.

By "Geography" I mean the size and shape of the stage and the
position/placement of physical and visual "obstacles" (such as stage
scenery") on the stage.

I'm not sure that a CAD drawing is the right way to fly because I'm
starting with raster images (Scanned from paper) not vector graphics.

But lets suppose I had a "revit" drawing using my raster image as a
background and with icons placed on the drawing. We'll also assume that
each icon has at least an identifying number associated with it.

What would it take to show that in a Web page? How does the web
application get to "know" what icon the user clicked on, and how does it
get the data assocaited with that icon so that it (The application, I
mean) can figure out what to do next ?



Get it?
I gather that there just might be some product which allows me to
specify a background jpg and a set of icons and locations to be placed
over the background where the specification is represented in an XML-ish
protocol named XAML.

WHat the name and price of the product is, I dont know, except that
Autodesk and Revit have gone by as possible names.

Is there a plug in to display properly constructed drawings in a web
site? Or a middleware component, or what? In order to create drawings
suitable for such display will I have to buy a multi thousand dollar
tool? How does user action and associated data get communicated back to
the web application?



This is called BIM (Building

Focus. These are wonderful things and I'm all for 'em; but I have a very
specific problem which I know I can solve "the old fashioned way" (image
maps) but what I want to know is whether I can do better.

So far, I'm only able to gather that there "might" be something that
will take an XAML descriptor and turn it into the sort of diagram I
want, but its not clear if the resulting diagram cam be make "viewable"
over the net, is "clickable" (i.e. capable of driving the state of the
web application depending on the end users actions) and if so, how to do
it, what it might cost and how much human data entry there would have to
be up front to get the data into the database in the first place.

Can you help fill in the mystery?

 

If I understand this problem correctly, you can do all of what you
want in AutoCad.

You want an image that can locate data about light fittings and be
displayable on a web page. That is DWF format, which AutoCad produces,
you can add URL's in AutoCad to specific objects or blocks, you can
even do this in 3D and still be web compliant.

AutoCad allows for Image attachment, which you can "send to back" to
use as an underlay.

Information extraction can be done in a number of ways, but the
simplest would be to apply hidden "attributed text" to each light
"block" and extract that thorugh a template.

I don't think you need to go to all the expense and hassle of a fully
programmed solution to this.

 

Sorry if I left the impression that your input was not helpful; it most
definitely is.

The idea of expressing aspects of the user interface in an XML-ish
dialect is one with which I can resonate; and I'm certainly tracking
down more info about XAML, which I would not have even heard of without
your pointing me to it.

Confucius (Kung Fu Tzu or "Master Kung") is supposed to have said "When
I show a student one corner of the subject, I expect him to find the
other corners by himself".

So I suppose I'ld be a washout at Master Kung's school, because I cant
see right off, despite you hints which would surely suffice for someone
with more going on upstairs, what tool it would be that would actually
draw the image and overlays on my web page, how I would communicate XAML
text to that tool, or how I would get the tool to link to the proper URL
upon user selection of an icon or interact with that tool to do ditto.

We can and do use proprietary tools, so thats not a deal breaker, but we
are under a certain amount of pressure to use more and more "open"
standards and open source tools.

I'll explain more about all that under separate cover responding to
another of your responses where you ask for confirmation about your
guess as to what this is all about.


When I got started in web

You're preaching to the choir ole chum.

I started thinking about CAD because even though it may be "overkill"
for the first problem (which can be solved with image maps) it cant go
where I think the project will be going, about which, more under
separate cover.

 

I suspected as much, but there are a few stumbling blocks:

1. I'm starting with paper documents which I'll digititze into .gif or
..jpg format

I suspect that getting .dwg from that will break the budget and also
require the use of to many "carbon units"

2. Its an absolute requirement that all the actual data used in creating
the information part of the web site (As distinct from layout and "user
experience) must be stored in our database (We have Oracle 10g).

We have an existing system which works something like this:
At "publishing time" (also known as "extraction" time), we spit out
100's of thousands of "Static" xml documents, one per displayable
object. The documents are indexed with a Information Retreival engin
(We're using Lucene).

At run time, the website takes queries from users, finds "documents"
(xml data blurbs) that match the query, and then displays data from the
documents including pictures whose url's are found in the documents.

The new system, showing the lighting plans, will work in pretty much the
same way. All the actual data is to be stored in the database. At
"publish/extract" time we turn the RDBMS data into a large number of XML
files, and index the xml docs with Lucene.

At run time, the web site code finds the data using user input and the
Lucene indexes, and then displays text and images "appropriately".

The twist for the first cut of our new web site is that we need to have
these "clickable" icons within the stage plan diagrams (Diagrams showing
light fixtures wrt stage and scenery are available as paper, which we'll
scan into .gif or .jpg)

Eventually we may find the 3D bit wonderful, but first things first. For
now its all 2D.

Ah! Thats the first gem today. Producing a real live .dwg vector graphic
to represent the stage and scenery etc would be coslty for us. Creating
a very simple .dwg with a complex image "Sent to back" sounds like
something more practical for this stage of the project.

In this case, the location of the light fixtures is part of the
background drawing. Thats given. We could use carbon units (I mean
people) to visually place "transparent" or unobtrusive icons onto the
drawing at those spots (or regions) of the background which correspond
to lighing fixtures, on another layer. The carbon units would have to
know the unique identifier for each light fixture and put that onto the
drawing associated with the icon. I suppose that would be an "attribute"
of an icon in Autocad language?

To prepare the .dwg I'ld need a copy of Autocad. Many thousands of dollars?

To display the .dwg dont I need some sort of plugin? Is that from
AUtocad, or a third party or what? ANd what about cost and license fees?

How do I get the data on the drawing to interact at run time (Web
display time) so that the code running the web site "knows" that a user
has clicked on an icon. The code would have to somehow get the
information from that icon (the unique lighing fixture number in this
case) and then link to somewhere which varies (if only by an input
parameter) depending on WHICH lighting fixture was chosen by the user.

What tools do I need and how do I use them? And how much do they cost?

I'm not sure I follow you here.
I'm going to need a carbon unit to visually find the location of the
lighting fixtures within the drawing.

I'm going to want that information "fed back" into the RDBMS so that
having once used the carbon unit for that task, we never have to do that
again.

We will also be using the carbon units to enter data about the lighting
fixtures and other things into the RDBMS, but thats a standard data
entry task which is outside of what I'm asking about.

If we use a CAD architecture as opposed to HTML image maps, we'll need
the carbon units to place icons and information on another layer
UNLESS there's a way to add that to ACAD programatically (given that we
already "know" where on the drawings each lighting fixture is located).

Using CAD we'ld probably use the carbon units differently, having them
just place the icons using the background diagram as a guide, and then
find a way to "read out" the data from the drawing they produce and feed
that back into the RDBMS.


Bottom line:
I'm wary about the cost, but tell me more about how I actually get all
that to work using Autocad and/or third party tools.

 

Close but no cigar. This is a pilot project to display Lighting Plans
for Scholars, Historians of the Theater, and perhaps for Lighting
designers looking for historical information/inspiration.

It is partly archival, so all the documents and "metadata" will be kept
"forever" in some suitable format.

But rather than being a "dark archive" stuffed away in "Stone Mountain"
somewhere, it will be "visible" as I've described.

We've got a general stratgy for such things which works sort of like so:

1. Structural, descriptive and some technical metadata are organized in
an RDBMS schema implemented in Oracle. Other technical metadata is
embedded in the digital files themselves, ususally by the cameras or
other digitization devices.

2. Archival pictorial (or other media) files are stored in "deep
storage" and various derivatives (gifs and jpegs suitable for diplay on
web sites) are also stored on line and are accessible via "presentation"
servers.

3. At "publishing" time (or "extraction" time), we "publish" the
descriptive and structural metdata in the form of one xml document per
structural item (which may represent a page in a book, or a painting, or
whatever)

4. The xml documents are indexed via an information retrieval engine (we
use LUCENE)

5. The xml static documents and the lucene indexes are available to the
web servers.

6. Code for each website is repsonsible for "look and feel", but always
derives uses the structural and descriptive metadata in standard form to
do that. PArt of the descriptive metadata are "pointers" to the names
and locations of graphic (or other media) files such as thumbnail
sketches reference pictures or "Wide" (i.e. full screen) images.


7. We want to preserve the same general architecture for the lighing
project, i.e. human beings prepare the raw materials, do curation, and
supply organazational and descriptive metadata which is entered into our
RDBMS.

8. At "publication/extraction" time, the metadata is rendored into
thousands of xml documents, one per structure item, indexed, and the lot
sent on to the web servers.

9. Code at the web servers "knows" what to do with the standard data to
acheive the use experience mandated for that web site.

 

OK, so we are dealing with a very large database of information and
graphical data and you are after the minimal carbon unit intrusion.

You can link AutoCad to Databases, that is no problem, you can also
olink specific parts of a drawing (Blocks or Icons as you call them)
to specific database components. To make the whhole thing web enabled,
you would have to publish in DWF format, this would keep all the Image
backgrounds, the database connectivity and you can use Hyperlinking to
fire off your database driven webpages.

BUT; this is a very time consuming way of doing this and AutoCad costs
£3900/copy (roughly), you would need the full version and not the
cheaper LT version to acheive what you are after.

Getting back to basics a bit, how many lighting rigs are you looking
at? If, for example, you have a library of 100 separate rigs, I would
create a single drawing for each rig, link the lights up to your
database and Hyperlink each one to a suitable webpage and publish to
DWF, then embed the DWF in a higher level webpage. This would be a
really neat solution, as you can attach as mucg data as you deem
suitable to the actual object in the DWF, feed extra data from your
database and format it using your webpage templates.

This may well be a complete departure from where you are now, but this
would be the CAD solution. If you went down a fully programmed
solution, I would not recommend CAD, but the dispalyed image on the
webpage would not be as good and you would not really have the
facility to move over to 3D in the future.

 

In the end, yes indeed; though this is only a pilot project so at first
there will be only a small finite number of lighting plans actually
present on the web site.

I suspect that if this goes well, there will be a desire to move toward
a fuller simulation or "animation" of the lighting plan so that an end
user can click on the icon representing the light fixture and see the
stage "light up" , or at least display an area on the plan which would
be illuminated in real life. But all of that is speculation. Today's
task is relatively simple. Click the icon, see the data. Not so bad.

As usual, there's more to the story. Our RDBMS is chock full of all
sorts of interesting "metadata" about the objects visible on the web
site and more. The RDBMS can be opened to scholars or groups of scholars
outside our institution, but mainly its for "in house" and
administrative use. A searchable base of "what we've got" is presented
via the website which is not directly attached to the database.

The website needs to be up and running 24 x 7. We get hits from all over
the planet, all day every day. We dont want the database to be a
critical part of web sites operational mechanism.

What we do, is we extract the data that will be shown on the website
after the underlying data has been declared "ready for prime time" by
our curatorial staff. THe web site thinks its working from static files
(plus a Lucene [inforation retrieval engine] index over the lot).

We COULD use a CAD system attached to the database for in-house use, but
then we would have the problem (not the end of the world, surely) of
exporting from both the database AND the CAD system, in order to build
the mechanism, whatever it turns out to be, for acheiving the effect of
an HTML image map on the web site.

We have champaign tastes and a beer pocket book. But its not completely
out of the question, assuming we can make a convincing enough pitch to
various funding "angels".

Its not individual lighting rigs, its lighing Plans. We have an
archivist who somehow wheedles those things from Broadway and off B'way
producers. I understand we have thousands and thousands of them.

ANd yes, we already know that "ingest", which includes preparation of
metadata is going to be a very expensive and "carbon unit intrusive"
sort of thing. No hope there.


If, for example, you have a library of 100 separate rigs, I would

If you went down a fully programmed

I'm afraid your losing me when you talk of "fully programmed solution".
Once the data is hand massaged into the database and/or CAD system, I'll
want to (need to) extract the data programatically and have the
"standard" xml documents describing the data (with possible extentions a
la GML or something) created for use by the active web presentation parts.