Microstation J question
Bob Lewis
in the 4th quarter of 1999. Is this true?
Allan Seidel
>
> Rumor has it that the file structure as used in Microstation J will change
> in the 4th quarter of 1999. Is this true?
This is what they said at a Microstation J demo I went to this past
week. It appears to me that the current file structure will remain as
is, but will be subset piece of the new file structure. The new "file"
features will be stored in different files with one master file pointing
to all the peices, which could include old type file structures.
AKS
Einar Braaten
Bob Lewis wrote:
> Rumor has it that the file structure as used in Microstation J will change
> in the 4th quarter of 1999. Is this true?
And if it is true, does that mean "i the clear" that drawings produced by
MStation/J can't be handled by MStation SE/95?
This is nice to know of before upgrading to the "J" for some of us I presume.
It would be too dumb, to have to convert to dxf or dwg to send something to
other Bentley users.
Please assure us unenlightened someone resonsible at the Firm.
Thank You
Einar Braaten
Waldo van Dungen
In fact the file structure will not change as far as I knows. However,
Bentley has introduced (and it will become available around Q2 1999) the so
called "Project Bank".
All your files can be stored in this central sorage bank. In that bank each
design files will be decomposed into smaller parts according to a predfined
schema, the DGN-schema.
When you open a "file" that is stored in the projectbank, the projectbank
will gather the original pieces back into a DGN-file (the same you created
before, before storing it into the bank) and yo work on your data just the
way you are used to.
Somewhat later a DWG-schema will become available, wich decomposes a
DWG-file into smaller pieces according to a -guess what- DWG-schema. You can
then edit this "file" in MicroStation without the need for any translation.
This is just the beginning of bentley's ultimate goal: working with
Enterprise Engineering Models. By that time indeed files do not longer
exist.
For more info, please check out Bentley's web-pages.
Regards,
Walter Oostdam
Bob Lewis heeft geschreven in bericht ...
Rob Brown
Einar Braaten <bra...@trondheim.online.no> wrote in message
news:364DECA4...@trondheim.online.no...
>
>
>Bob Lewis wrote:
>
>> Rumor has it that the file structure as used in Microstation J will
change
>> in the 4th quarter of 1999. Is this true?
>
>MStation/J can't be handled by MStation SE/95?
>This is nice to know of before upgrading to the "J" for some of us I
presume.
>It would be too dumb, to have to convert to dxf or dwg to send something to
>other Bentley users.
>Please assure us unenlightened someone resonsible at the Firm.
>
By my understanding, you will still have the option to work on dgn files as
before, but you will also be able to work in a new format which does not
have dgn limitations. And you will also be able to work directly in dwg. I
would assume that if you are working in the newer better format ("native"
MSJ), you would be able to "save to dgn"....hopefully with some smarts so
you can map levels to reference files, etc.
I'm sure Keith et al are well aware of the need for the transition from dgn
to be as smooth as possible. Most people will only use the newer format for
brand new projects, I'd imagine.
Then again, I don't really know what I'm talking about. :-)
-rob
>Thank You
>
>Einar Braaten
>
>
Keischar.Seah
I've read the White Paper and understand that for the first release of
ProjectBank, you will only be able to manipulate the dumbed down dgn version
of the new format. I suppose manipulation of new format elements will
require too much rewriting of Ustn code. Ustn will get Briefcase managers to
communicate with ProjectBank. It isn't spelled out but bypassing dgn
limitations will probably have to wait to the next EEM rung :-'ECM'.
Imagine that you are working on a 100 storey Skyscraper and you want to push
the facade line out 5cm. Could you expect to pack your briefcase with all
those levels so that one fence strech/move will take care of business ? If
Ustn will have manipulate existing dgns with its 63 lvl limitation, you need
at least 2 dgns and 2 manipulations. Better would be if Ustn finally got to
write to multiple Ref-files. Whatever little bit extra that was holding the
old code back gets solved at the ProjectBank/app-server level. Even if I
didn't have to accept the 63 lvl. limitation post ECM, I would still try to
keep the 63/4 lvl chunk as a organisational unit.
Or am I talking in old paradigm? Having read about Geographics' feature mode
and Plantspace's Objects, levels seem to be on the way out and the Database
way of filtering stuff the new wave. Anyone seen a level scheme killer CAD
package out there ? Like to know.
Anyway here's my humble pipe-dream for ProjectBank/Briefcase Manager :-
Ver 1.0 Briefcase Mode Ref -Dialog. Tree based display of Refs in BC
Ref-dialog, where the user can select/multi select ala Explorer what Refs at
any level to load. ProjectBank based so that Ustn does'nt have to snoop the
refs to read what Refs are ref'd. Eventually, files get replaced by
component groupings. Ref Info gets updated to database on file-closing.
Groups of files that can be defined as a group-file object. For example, a
plan group would consist of a main file, grid, fassade, stair, interiors
etc files. When I need to edit / index a section against a floorplan, all I
need to do is pull the latest combination of Refs that make up the floor I
need. When I need to blank out the floor, I display off the Group by
clicking on a single node in the Ref-Tree. My plot/export-files always pull
the actual combination of Refs by looking up the ProjectBank database.
ProjectBank would also hold the plot specific Info for each Plot-file (lvl
mask, Pen table, symbology, plotcfg, colour.tbl, level.lvl etc.) as part of
an databased sheet View. To work in sheet View, user saves his session info
as a user View and loads the sheet View. User/tasked-based reference
selections / attachments may be independently saved. Each user maintains his
particular selection of Refs and levelmasks etc for each dgn he works on. On
loading, Ustn loads his last filedesign'd settings. In effect no user has do
inherit another user's settings. Saved Views from all Refs would also be
available from any file . All ProjectBank Settings should also be fully
object oriented and open to macros.
Ver1.5 Exchange File tool that carries over the View, Ref attach, level mask
info from the previous file. Should be easy. The overriden session info gets
saved to database for recall the next time the file loads. Maybe with
ProjectBank all file-based Ref Info should be synchronized from the
Database. Level symbology settings would also be saved to the database.
Allows mulltiple symbology settings for the same Ref. e.g. user gets to
toggle between symbology where the different floors have a predefined colour
and the Services are red and whenever he editing elements on the border
between 2 files, having the all refs (uneditable) grayed while the active
file has no overides.
Ver2.0 Mixing of raster/step/dwg/Hpgl2/eps Schemas. Unlimited Refs. Raster
Refs that work in 3d space like decals. BCManager Ref Dialog allows the
user to take the Ref clips (hopefully visible and editable by now) or
rotation/scaling or Symbology from one file and apply them to another.
Accudraw supported manipulation of Refs/Clips etc. Attach a selection of
Refs to other Refs from BCManager Ref Dialog. SF=, FF=, merge ref1 into ref2
and copy/move to Ref from Ref Dialog. Move, copy, delete rename etc. from
the Ref-Tree. Edit Ref levels /attachment Info w/o loading the file.
Database updates the info with the file gets subsequently loaded. If the
user wants to temporarily exclude / displace certain levels to another file,
user gets to define if the new file will be remerged into the originating
group of files.
Ver2.5 Ref<-> Cell Dynamic Links. Database enhancement of the cells.
Cell-libraries residing in ProjectBank. All placed cells (later Components)
to have database links. Cells that have Plantspace-style daemons. Cells have
associated Views, ACSs, Refs, whatever stored externally in ProjectBank.
Cell Array infomation. Temporarily replace cells with refs that contain the
cell elements dropped. For example, a auto bumper is defined as a cell, to
edit the cell, Ustn pushes the cell to its own file, refs the temporary cell
file into context, makes the file writeable, drops the cell while preserving
its cel-origin etc, lets the user edit the cell in context and updates the
cell defintion when the user pops back to the previous file.
Ver3.0 Procedural Macro based merge, sorting referencing. Sort of like a pen
table for Refs. Ref this but only levels so and so, then ref that with nest
depth1, replace cells a, d from cell-library X, scale text with this colour
on level X from ref Y but not those with textheight 2 and 1.5 etc. Clip
(with new Fence Clip mode) ref Z with the Complex shape from ref W. At
scale 1 :50 scale cells factor 2, Search out tagged polygons (Lenses ) and
use them to generate fence shapes that subsequently change the symbology
from predefined refs elements. Changes applied only to the version loaded.
Of course integrated into Ref-Tree view as node.
This would facillitate a I think woild be future killer function :- Smart
Text and dimensions that adjust and move rotate scale themselves so that
they never overlap other text info and Certain defined graphic elements.
Room based intelligence. Remembers the last manipulation so that it only
needs to check for collisions rather than going thru the whole chain
reaction/algorithm again. Certain Elements will leave a leader when moved .
e.g. Room Tags when they are moved out of the room extents and Height qoutes
and stuff that already have leaders. This makes a draw once (single data
sourse) plot at every scale a little closer. Also Interactive option :-
toggle Kinematics lock on and move text node and any other text or
dimensions get bumped out of the way.
Ver.3.5 Constraint Model ?, Top down , ERP/PDM connection ? <- Your
suggestion here
Estimate of cost to implement ? 1 mil ? Schedule ?
Estimate of productivity gains ? Ah don't need it ? Been there, done that ?
Chris Zakrewsky
Think about Project Bank as a migration tool.
(BSI marketing will be probably focused around collaborative
projects in mixed environments etc., but we in the trenches know --
it will be migration tool after all -- aka 'missing link' in transition
from DGN to
the new file format).
Best!
/Chris Zakrewsky
Waldo van Dungen <wal...@euronet.nl> wrote in article
<72krnu$o...@news.euro.net>...
Wrestl PSU
become extremely complicated !!
why ?
it works just fine now !!!!!!!!!!
Graeme Cockram
One statement you used there "Missing Link" is what worries me with all of this
concept. We all know some of the problems caused by ref file links, What sort
of problems can be expected from fragmented files when you are trying to ship
different parts back to clients at different times, or if you have a
multi-client shipping for a single project?
Graeme Cockram
(snip)
> -- aka 'missing link' in transition
> from DGN to
> the new file format).
>
> Best!
> /Chris Zakrewsky
>
> (snip)
bill...@my-dejanews.com
Infosnap.
Now did you want to talk about football?
Bill (M)
In article <19981116191552...@ng73.aol.com>,
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Chris Zakrewsky
going to
> become extremely complicated !!
Hi,
Actually it is VERY easy to comprehend, once you learned the vocabulary.
The best cross-reference I know follows ;-)
"Humour: Enterprise for the Ear Canal
++
Bentley Strategic Affiliates -- Third-party developers that we like better
than our other third-party developers.
Briefcase Manager -- Wasn't this something Cyco Software invented?
Component Bank -- Perhaps Autodesk could have the Component Savings & Loan
(in the USA), or the Component Credit Union (in Canada).
Engineering Component Modeling -- Done with toothpicks and small pieces of
Styrofoam.
Engineering Components -- The toothpicks and Styrofoam themselves.
Enterprise Engineering Modeling -- The boss gets to choose the color of the
Styrofoam pieces.
Enterprise-wide IT -- Don't know what "it" is but "it" must be important
because "it" gets to have capital letters.
Global 9 -- News at 10:00.
Internet/intranet/extranet-based products -- Better cover all bases, just
in cases the Internet falls out of favor, like set-top boxes.
JMDL -- A manufacturer of farm equipment.
MDL -- A manufacturer of farm equipment after bankruptcy reorganization.
MicroStation 95 -- Riding the coattails of Microsoft marketing.
MicroStation SE -- Getting off the coattails of Microsoft marketing.
MicroStation/J -- Riding the coattails of Sun marketing.
MicroStation(R) TriForma(R), MicroStation GeoGraphics(R), MicroStation(R)
GeoOutlook(R), and MicroStation Modeler(R) -- Versions of MicroStation
localized for Scotland.
Model Server Continnum -- Sounds like a washing machine that continues to
break down.
Model Server Imager -- Keeps a record of Internet pictures you've
downloaded on company time.
ModelServer -- A computer precisely modeled in HO scale.
ModelServer Discovery -- A computer that was later found stashed in the
coat closet.
ModelServer Teammate -- An employee who goes along with the boss's desires.
Plant Continuum Solutions -- Replacing annuals with perennials.
Premier Life-cycle Solutions Provider -- Your family doctor.
Project Bank -- To make your organization look as stable as a bank.
ProjectWise -- An employee who knows what's going on.
QuickVision GL -- Eyeglasses with built-in Mission: Impossible cameras.
Schema -- What Republicans are doing to Bill Clinton.
SELECT ModelServer -- Pick a server, any server.
SmartSolid -- Those chucks of vegetable in soup that avoid your fork.
Teammate -- The clip you put on your tie so it doesn't get into the chunky
vegetable soup.
True Field-to-field Solution -- Solves the puzzle: why does grass look
greener on the other side?
The Bentley Continuum -- The continuing outpouring of Very Important
Verbiage from Bentley marketing.
"
PS: (above is from from upFront.eZine.
To Subscribe: Send the message 'subscribe upfront' to
mailto:ral...@xyzpress.com
upFront.eZine is a shareware newsletter. English back issues
available at http://users.uniserve.com/~ralphg/ )
/Chris
Wrestl PSU <wres...@aol.com> wrote in article
<19981116191552...@ng73.aol.com>...
Keith Bentley
love can remain UNCHANGED entirely, and indefinitely if you like.
ProjectBank is the mechanism for you to manage your project information
created by MicroStation (and other formats as well). Just to be clear,
ProjectBank does not require a new file format for MicroStation, nor does it
require different drawing creation/editing tools.
However, when you've finished edting them with MicroStation, instead of
copying your .dgn files to a server, or using a "document" management system
that is basically oblivious to what's in your files, you "check in" your
files to a ProjectBank. The check-in process looks at what you changed (on a
individual element basis) and then stores only that list of changes rather
than the entire file. It saves a "journal" of what happened when and by
whom. That way, you can tell what's happened throughout the project, and you
can look at previous "versions" of your design information. But, we're just
talking about .dgn files and MicroStation here, nothing about that should be
a cause for concern to existing MicroStation users.
But, of course there's lots more. One of the big problems people have today
with MicroStation is that sometimes more than one person wants to edit the
same file. If you decide that you want to allow that (ProjectBank doesn't
require you permit this, but I can't believe anyone wouldn't want to), then
ProjectBank will automatically "merge" the changes made on two sessions
without either user having to worry about the other -- nothing more
complicated there, they're both just "using MicroStation". Now, one slight
"complication" can be the scenario where they both somehow modify the same
information. In that case there's a process for resolving conflicts. If you
think that's too complicated, then you can just disable simultaneous edits,
but frankly, I think that's a short-sighted view of this great tool for
radically improving collaboration.
ProjectBank gets really interesting when you understand that it's not 'just'
.dgn's that it can handle. There are other formats, including .dwg's and
application level formats too, and even on the same project. What really
makes ProjectBank exciting is that all this information is (internal to
ProjectBank) equivalent - as they used to say "parts is parts". Think of
what that means for inter-discipline applications, and for migrating from
one format to another.
On the whole, our goal is to make the whole process a lot SIMPLER than
today's MicroStation, not the other way 'round. ProjectBank is a major,
major step in that process and a key to solving many existing problems in
MicroStation multi-user workflows. Stay tuned.
Keith
Wrestl PSU wrote in message <19981116191552...@ng73.aol.com>...
Keith Bentley
illustrates the very essence of the need for ProjectBank. I'll use it to
jump on my bandwagon, if you don't mind.
The very possibility of a "missing link" (and btw, I think Chris was
referring to a missing link in the explanation of how to
get-there-from-here, not a missing link in project information, but I'm glad
you brought this up anyway), comes from the concept of a "weak reference"
from one piece of information to another (a weak reference is one that is
unkown to the the system as a whole and unenforced.) Reference file
attachments in MicroStation are one example of a weak reference, as are cell
libraries, font resources, etc. URL's in the www context are another
example, and the reason you sometimes get "URL not found" error messages
from your browser.
But, the big problem with most existing MicroStation applications is that
there's not enough references between related information, particularly
inter-file references (think of the simple example of dimensions to elements
in a reference file). Today MicroStation doesn't allow that at all, and the
reason is that a weak reference to an element in a "reference file" would be
unreliable at best, and your dimensions would be unreliable as well. So, the
solution has to be some form of supervisory level controller for project
information that spans files and even file types (schemas in PB
terminology). That's the job of ProjectBank.
So, to use your example of a trying to ship a portion of a large distributed
project to a client, every reference between one portion of the project to
another would be known to the ProjectBank. When you package up your delivery
to them, it can be in the form of a "briefcase" in which every link can be
followed and (according to security rules you establish) be included or not.
In that case, there's not a series of disjoint files that may or may not
have all they need, there's a cohesive set of consistent information without
the chance of unexpected "holes". Of course this requires you decide on the
boundaries between what you want to send and what you don't (or otherwise
you can just send the entire ProjectBank). An alternative, that I expect
will become the norm over (probably an extended period of) time, is to allow
protected access to a shared server and allow clients to extract their own
subsets of the project, and not have "delivery sets" at all. Of course
there's security concerns there, but no worse than just sending them a blind
set of design files because you don't know what they're going to need.
Of course, all of this is what keeps us at Bentley up at night, so I think
you're on the right track thinking about it now.
Keith
Graeme Cockram wrote in message <3650CF3C...@cmontage.com.au>...
Chris Zakrewsky
> The very possibility of a "missing link" (and btw, I think Chris was
> referring to a missing link in the explanation of how to
> get-there-from-here, not a missing link in project information,
Of course it was the case ;-)
> a "weak reference"
> from one piece of information to another (a weak reference is one that is
> unkown to the the system as a whole and unenforced.) Reference file
> attachments in MicroStation are one example of a weak reference, as are
cell
> libraries, font resources, etc. URL's in the www context are another
> example,
Dear Keith, haven't you forgoten the next most important weak reference,
namely Database? (ENTITY/MSLINK)
It will remain weak in the future of Project Bank after all... or a Shema
can
be created to take a snap-shot of attached DB data and store it in Project
Bank?
I hope it can...
Best Regards (very best indeed),
/Chris Z.
Keith Bentley <keith....@bentley.com> wrote in article
<72up1t$kpq$1...@news.bentley.com>...
(lots of useful stuff)
Russell Kauffman
vendor having a forum where frankness and openness are valued and expected.
I heard Keith's presentation live and in person in Philly and the same
thought came to mind that this thread is reviving.
All of the discussion seems to deal with the "CADness" of uSta. and very
little has been said about how Project Bank is going to fit into the
Geoengineering segment of the Continuum. The issue in GIS and Enterprise
use of geospatial data is not how to manage AutoCad DWG etc, but rather ESRI
export files and that most prevalent format for free and public data .SHP
Keith's explanation of the "audit trail" aspects of Project Bank may also be
a way out of the swamp of FGDC compliant metadata, which many state
environmental regulators are requiring as part of their digital data
submission criteria..
Thanks to all who have made this an enlightening discussion, but if we can
start to address the needs of the GeoEngineer in a strategic way with these
tools I think we may yet see an emerging GIS presence that will count for
something with a Made in Exton label
Russell S. Kauffman, PLS
Principal GIS Engineer
Public Service Electric & Gas Co.
Newark, NJ
Work: RKau...@pseg.com
Home:gun...@adelphia.net
Keith Bentley wrote in message <72um76$jq3$1...@news.bentley.com>...
Graeme Cockram
Firstly thank you for taking the time as a Bentley Exec to get involved in these
discussions. We are fortunate in this news group to have total vendor - user
interaction and it does give Bentley the opportunity to hear uncencored comments
and worries from the real users i.e. those that like to get involved.
Secondly, what you have mentioned in your E-mails on the J question is this info
available anywhere or will the answers only come up as the questions are asked ?
Graeme Cockram
(One more sleep and I'm out of the VAR system and back on the boards)
Keith Bentley wrote:
> Ah Graeme, you've hit the nail smack on the head with this question and it
> illustrates the very essence of the need for ProjectBank. I'll use it to
> jump on my bandwagon, if you don't mind.
>
> The very possibility of a "missing link" comes from the concept of a "weak
> reference" from one piece of information to another (a weak reference is one
> that is
> unkown to the the system as a whole and unenforced.) Reference file
> attachments in MicroStation are one example of a weak reference, as are cell
> libraries, font resources, etc. URL's in the www context are another
> example, and the reason you sometimes get "URL not found" error messages
> from your browser.
> (snip)
>
> So, to use your example of a trying to ship a portion of a large distributed
> project to a client, every reference between one portion of the project to
> another would be known to the ProjectBank. When you package up your delivery
> to them, it can be in the form of a "briefcase" in which every link can be
> followed and (according to security rules you establish) be included or not.
> In that case, there's not a series of disjoint files that may or may not
> have all they need, there's a cohesive set of consistent information without
> the chance of unexpected "holes".
> (snip)
Chris Zakrewsky
Not talking on behalf Keith, but this is actually how Bentley success story
started
in the first place (nice, friendly, understanding and DIRECT dialogue).
I am extremely happy that we are in the same atmosphere once again.
The big organization insulated regular users from core Bentley for a while,
but I see this being back to the good old fashion at the moment.
(One more sleep and I'm out of the programming system and back to -- yup,
programming ;- )
--
Remaining With Our Very Best Regards,
/Chris Zakrewsky
+------------------------------------------------------+
| ch...@cadperf.se ICQ:11607244 http://www.ustation.se |
+------------------------------------------------------+
| CAD Perfect Development Lab Co. |
| Torpangsvagen 9, S-187 63 TABY, SWEDEN |
| Int'l. tel/fax +46 8 756 1353 |
+------------------------------------------------------+
| Bentley Sales Center, Independent Software Developer |
+------------------------------------------------------+
Graeme Cockram <gcoc...@cmontage.com.au> wrote in article <36536B36...@cmontage.com.au>...
Bob Lewis
So, even though ProjectBank doesn't "require" file changes, we have been
told in the Microstation J intro's that the file format WILL change. Is this
going to be documented, or will we be pleasantly surprised?
Chad Berreau
The big thing demonstrated was Parasolids. This I would imagine is the big new
addition to the DGN.
As with new entities in the past, raster references, ole links, etc. There will
be some issues about backward compatability. But I have yet to see the dgn not
open on an older version of the application. It may not have full capabilities
to effect all of the element types. This I think is the case with the Triforma
entities and MicroStation prior to J.
Regarding Bank, from what I understand Bank is a new construct to hold and
gather information, it isn't a DGN or DWG. It is more of a database/server kind
of thing.
It is recoginized that the database itself will not be coherent to previous
versions, but that Bentley see's the answer for this sort of collaboration in
the form of publishing. That is the Bank data would be published in either dgn
or dwg form for other to utilize.
My question would be, how is the Publishing going to be accomplished.?
Will it be as simple as Batch Plotting?
Or will it be more akin to translating?
Chad
Bruce E. Irving
> ...
>Regarding Bank, from what I understand Bank is a new construct to hold and
>gather information, it isn't a DGN or DWG. It is more of a database/server
kind
>of thing.
>It is recoginized that the database itself will not be coherent to previous
>versions, but that Bentley see's the answer for this sort of collaboration
in
>the form of publishing. That is the Bank data would be published in either
dgn
>or dwg form for other to utilize.
>
>My question would be, how is the Publishing going to be accomplished.?
>Will it be as simple as Batch Plotting?
>Or will it be more akin to translating?
OK I'll add my two cents with the expectation that if I'm completely
off-base someone from Bentley will set it right.
The ProjectBank holds components (objects). In the initial release these
will be exact 1:1 mappings to .DGN elements (and later .DWG entities). In
other words, the data is not stored directly in those formats, but it is
exactly the same data content. So getting data in an out involves a lossless
transformation, not a lossy translation.
Later releases will store any objects for which a definition (schema) is
available. The exact format of the stored data should not be an issue, and
in fact will vary depending on who developed the schema. Later versions of
MS/J (or Select additions to MS/J) would implement the ability to load in a
schema from the ProjectBank and to be able to manipulate the associated
data.
Add on applications (in JMDL) could define new object types (classes) and
manipulate those objects in any way that makes sense for the application. In
addition, they would store enough of the schema with the data so that MS/J
could do at least fundamental manipulations on those objects (display, plot,
delete, etc).
I would expect that at least in the near term, that these new classes might
include reasonable mappings into .DGN and/or .DWG, STEP, or other formats.
That way at least the graphics could be manipulated by 'legacy' applications
(with probably loss of data intelligence).
Now, before I've completely fooled myself into thinking I know what the hell
I'm talking about, I'll quit babbling.
-- Bruce
Chris Zakrewsky
> I'm talking about, I'll quit babbling.
Howdy,
Your explanation is just about identical to mine understanding of this.
In another words, it seems 100% right ;-)
Tom Schraeder
project bank. We are consultants with many clients. How do I sync updates from
our changes into their project bank? How do I keep the St. Paul Corps of
Engineers data separate from the St. Louis Corps projects while maintaining a
single read-only copy of the "standard" Corps of Engineers cell library? How
can I prevent one client's updates to the standard cell lib from being
synchronized back to mine? How do I work with our own regional offices who run
on a different NOS?
One important question is: Is this project bank a dumb file or a server? If it
is a dumb file and all the functionality for modification is in MicrostationJ
then I have to buy another license for my managment seat (which now manages by
setting NOS accesses). If it is a server, then I assume I have to buy NT server
to run it.
Zakrewsky was correct in saying the most important question before us is
non-graphic database integrity. Until you can guarantee clean database
references, clients are reluctant to use them. A set of "standard" column
names for reverse linkage data in the database tables would go a long way to
allowing this.
I'm genuninely impressed by what Microstation can do and the advances it has
made. The problems are not in the concepts, but the implementations. I'm sure
most of the project bank stuff will work when it comes out, but it will work
without me. Why? Well, we can't move the users out of ms95 until SE can plot the
same line weights on a Calcomp plotter. Yes, we're paying 12k a year for
select (in this little part of the company alone). God (and a lot of customers)
is in the details.
Keith Bentley wrote:
> Well, the whole idea for ProjectBank is that the MicroStation you know and
> love can remain UNCHANGED entirely, and indefinitely if you like.
> ProjectBank is the mechanism for you to manage your project information
> ...
Simon Wurster
I saw Project Bank in Philly as well. My impression: we won't see this at my office
(or company) until our clients request it. Now most of our clients in the NYC area
are still running UNIX or CLIX or Windows 95--some have Windows NT. Some are still
running (though not really officially) MicroStation 5.0. A client recently asked for
the functionality of ModelServer Publisher, but is happy with MicroStation Archive
and Adobe Acrobat files that we posted for about $200 (Adobe Acrobat)--much less
than MS Server. To most of our clients, installing Project Bank means new servers,
new PCs, Windows NT, T-1 lines and assorted communication hardware--items that may
have to be budgeted today for installation in the year 2000. It's pretty much the
same situation in the consultant side of the equation, but if the client asks for it
and will pay us to get it and use it, then we'll have it installed "yesterday." I
think Bentley should focus on our clients first if they want the rich consultants to
buy into ProjectBank. After all, that's what Intergraph did 20 years ago.
As far as native access to AutoCAD files (for editing and use as reference files),
there seems to be no way to plot these hybrid files accurately, since we (like most
of the world) plot by weight, and the AutoCAD file will need to be plotted by color.
And don't even mention the AutoCAD fonts and line type files which will also need to
be synched among all the PCs connected to the ProjectBank.
I thought the edit log was lame since anyone can type whatever they want (including
leaving the field blank). And the thread last month about "who saves first" and
"getting commitment to save" really helped exposed the advantages and disadvantages
of Project Bank. I'm still not sure who has a use for this, since the last 2000+
file project I worked on required about 20 design files to be dynamically
shared--and e-mail worked just fine.
Just my $0.02,
Simon
Keith Bentley
I'm Sorry, but I really think you've missed something either in the demo or
the explanation of ProjectBank to come to the “conclusions” you have below.
That definitely means we haven’t done a good enough job in explaining this.
So, as the self-proclaimed evangelist for PB, I’m going to keep trying.
Understanding PB, and recognizing it as the key to solving huge problems
that exist today (in MicroStation and in engineering workflows in general)
is essential to understanding how things can get much better for you. I feel
like we’ve shown you tomorrow’s newspaper, only to have you say “I don’t
like the font you used on the headlines, what was wrong with yesterday’s
newspaper”.
*** my replies to your comments interspersed below.
Keith
Simon Wurster<SWURSTE...@WORLDNET.ATT.NET wrote in message
<3655E76B...@worldnet.att.net>...>Hi All,
>I saw Project Bank in Philly as well. My impression: we won't see this at
my office
>(or company) until our clients request it. Now most of our clients in the
NYC area
>are still running UNIX or CLIX or Windows 95--some have Windows NT. Some
are still
>running (though not really officially) MicroStation 5.0. A client recently
asked for
>the functionality of ModelServer Publisher, but is happy with MicroStation
Archive
>and Adobe Acrobat files that we posted for about $200 (Adobe Acrobat)--much
less
>than MS Server. To most of our clients, installing Project Bank means new
servers,
>new PCs, Windows NT, T-1 lines and assorted communication hardware--items
that may
>have to be budgeted today for installation in the year 2000.
*** Well, as to hardware requirements, if you’re using a file server today,
then I think you’ve already got everything you describe above (with the
exception of T1 lines) and certainly everything you need for PB. I don’t
know why you think PB requires a T1 line, except if you expect your clients
to connect directly to your servers, which I said I think will ultimately
become the norm, but is certainly not necessary to get started.
> It's pretty much the same situation in the consultant side of the
equation, but if the client
> asks for it and will pay us to get it and use it, then we'll have it
installed "yesterday." I
>think Bentley should focus on our clients first if they want the rich
consultants to
>buy into ProjectBank. After all, that's what Intergraph did 20 years ago.
*** PB is intended to coordinate the efforts of a workgroup, just like you’
re doing with your shared file servers today. That really has nothing to do
with how you interact with your clients, nor is it really something they
need to ask you for. It’s mainly about making your life easier; particularly
when there’s more than one of you on the same project. Sharing the results
of that effort with others can be done using a hierarchical network of PB’s
(Keith’s long term vision, maybe what you’re implying needs to be sold to
clients), or by exchanging files as is done today. There’s no additional
hardware required for PB (OK, I’ll confess, I think it’s going to work
better if you have more memory and more disk space on your client
computers – true of any new software version). And for goodness sake, the
software is included with MicroStation, so why does any of this involve
anyone “paying” you to use it? If you think PB is something you won’t use
until you’re required to by clients, then either we’ve implemented it poorly
(maybe what you’re worried about, I think this is Tom Schraeder’s point), or
you’re definitely going to be at a disadvantage to your competition.
*** I don’t remember 20 years ago, I wasn’t in this business then. But I do
remember 14-15 years ago when we started this company. At that time I told
people, “PC’s will solve your scalability problems and MicroStation (which
didn’t then exist) is the answer.” I remember there were those who said at
the time, “Think of the problems PC’s add versus these nice comfortable VAX’
es we’re using. No way I’ll ever allow them in this company.” How many VAXes
are still in use today?
>
>As far as native access to AutoCAD files (for editing and use as reference
files),
>there seems to be no way to plot these hybrid files accurately, since we
(like most
>of the world) plot by weight, and the AutoCAD file will need to be plotted
by color.
>And don't even mention the AutoCAD fonts and line type files which will
also need to
>be synched among all the PCs connected to the ProjectBank.
>
*** But the very essence of ProjectBank is that there’s a DWG schema that
displays DWG files without translation. Therefore, plotting CAN BE by color
in DWG and by weight for DGN’s, even when they’re attached as reference
files to one another. Now, in this case we’re talking about using ECM
editors, not the current DGN one, but ProjectBank is a prerequisite to any
of that. Fonts and other resource files (AutoCAD and MicroStation) are
imported into your ProjectBank and become just one of the parts of your
project. They’re automatically synched among the connected clients (sorry,
you said not to mention it, but I couldn’t help myself) of ProjectBank.
>I thought the edit log was lame since anyone can type whatever they want
(including
>leaving the field blank).
*** That’s kind of like saying that videotapes are “lame” because anyone can
write anything they want on the outside label. The comments a user enters
when he commits a change are just so someone else can figure out what he/she
did. You’re right, if they choose to they can enter incorrect or misleading
information, or they can enter nothing at all. In that case the log itself
won’t really be useful and you’ve missed a great opportunity to help
yourself. But, the important point is that the journal has in it EXACTLY
what they really did – which elements he changed, added or deleted. If you
want to figure out what happened when and by whom at some later point, then
the journal will tell you exactly who did what, and what they said the
reason was (the log entry). There’s no way to enter changes without them
being journaled, so there’s no way around circumvent the system. Also, if
you want to go back to a previous revision of a drawing, that’s always
possible. I submit that what’s “lame” is today’s process that ignores and
loses this invaluable information every day. And, I think it will be very
useful even for projects WITH ONLY ONE USER (for example, when did I change
that? What else did I change when I decided that should be 5m long?)
> And the thread last month about "who saves first" and
>"getting commitment to save" really helped exposed the advantages and
disadvantages
>of Project Bank.
*** I maintain it only illustrates the advantages of ProjectBank. If you don
’t want to allow simultaneous edits of the same design file because your
worried about the merging process (and I think that’s the 1998 equivalent of
saying you’ll never allow PC’s in your company), then you can simply disable
that by enforcing exclusive locking. However, I can assure you, there’s no
way to get beyond today’s sub-optimal workflow coordination techniques
without a good change merging scheme. ProjectBank is the only technology I
know of that even begins to address that issue.
> I'm still not sure who has a use for this, since the last 2000+
>file project I worked on required about 20 design files to be dynamically
>shared--and e-mail worked just fine.
>
>Just my $0.02,
>Simon
>
*** And people used to get around in horses and buggies just fine :).
Seriously, I’m not accusing you of being a Luddite, and you’re right to be
skeptical of something before you’ve used it, but I’m convinced that this IS
the future, and it’s my strong belief that EVERYONE has a use for this stuff
(could you tell?).
Anyway, that's my $.02, but I’ll admit that I’m biased. So now the world has
$.04 available here on this topic.
Keith
Simon Wurster
Did I hit a nerve or what! ;-) I do have some thoughts that you should consider
to better understand my arguments and observations:
Our industry is years way culturally from the workflow proposed by ProjectBank.
We don’t have 100% engineering use of MicroStation, which seems to be
requirement for effective use of ProjectBank. We still, for the large part, rely
upon the engineer–>drafter–>engineer workflow model that’s been in place for the
last 50 years. And the kicker is: this is the workflow our clients expect us to
use, since this is the workflow model _they_ use. I know what you’re thinking:
ProjectBank can be useful even in this "primitive" workflow model. That may be
true, but that wouldn’t be utilizing ProjectBank to its fullest, and the current
method of storing and retrieving files works just fine. My point is until we’re
at the level (culturally) to utilize ProjectBank fully, why install it? Why get
involved with the hassle of installing and training users to use it (and
training subs and joint venture partners to use it) when we as an industry are
not ready for the cultural leap? There are plenty of bell-and-whistle software
packages out there: Intergraph’s I Plot, Axiom’s FileFixer, etc. And all these
vendors tout that MicroStation life without these products would be miserable if
not impossible without their product–yet thousands of users survive just fine
with BatchPlot and EdG. If it ain’t broken, don’t fix it–and ProjectBank looks
like a solution in search of a problem.
Keith Bentley wrote:
The purported idea behind ProjectBank is expanded connectivity to improve
workflow communication. And invariably, this will mean external communication,
via the Internet--thus the T-1 lines. My office doesn't "need" another
software application to improve communication internally via ProjectBank--we, as
is probably the case with other firms, hardly use the tools we already have to
communicate effectively on projects. Internally, using ProjectBank would be like
using cell phones within the office to make sure everyone communicates
effectively--in a word: overkill.
> > It's pretty much the same situation in the consultant side of the
> equation, but if the client
> > asks for it and will pay us to get it and use it, then we'll have it
> installed "yesterday." I
> >think Bentley should focus on our clients first if they want the rich
> consultants to
> >buy into ProjectBank. After all, that's what Intergraph did 20 years ago.
>
> *** PB is intended to coordinate the efforts of a workgroup, just like you’
> re doing with your shared file servers today. That really has nothing to do
> with how you interact with your clients, nor is it really something they
> need to ask you for. It’s mainly about making your life easier; particularly
> when there’s more than one of you on the same project. Sharing the results
> of that effort with others can be done using a hierarchical network of PB’s
> (Keith’s long term vision, maybe what you’re implying needs to be sold to
> clients), or by exchanging files as is done today. There’s no additional
> hardware required for PB (OK, I’ll confess, I think it’s going to work
> better if you have more memory and more disk space on your client
> computers – true of any new software version). And for goodness sake, the
> software is included with MicroStation, so why does any of this involve
> anyone “paying” you to use it? If you think PB is something you won’t use
> until you’re required to by clients, then either we’ve implemented it poorly
> (maybe what you’re worried about, I think this is Tom Schraeder’s point), or
> you’re definitely going to be at a disadvantage to your competition.
So ProjectBank is free? This, if true, was the most murkiest of points at Philly
Forum. But what about the enterprise database? Is that included with
MicroStation as well? And will we need to shoehorn that database onto an
existing server? I simply imagine the installation headaches of ProjectBank. And
what about file size? After editing a 300kb file and storing the changes, will
the file remain 300kb? What if both (or more) users choose to save both the
original version and their new version: the file size will triple, right?
ProjectBank may be free, but I see we'll pay in other areas. And the hierarchal
arrangement of ProjectBanks implies all users (other firms, subconsultants,
etc.) will need to use ProjectBank, right? Kind of like ActiveX: "everyone can
use it, isn't it great, oh, by the way, it only runs on Microsoft Explorer." And
let me guess: you can't link ProjectBanks unless you also have ProjectWise.
> *** I don’t remember 20 years ago, I wasn’t in this business then. But I do
> remember 14-15 years ago when we started this company. At that time I told
> people, “PC’s will solve your scalability problems and MicroStation (which
> didn’t then exist) is the answer.” I remember there were those who said at
> the time, “Think of the problems PC’s add versus these nice comfortable VAX’
> es we’re using. No way I’ll ever allow them in this company.” How many VAXes
> are still in use today?
The demise of the VAX has weak parallels with the demise of the file server (and
use of ProjectBank). Many MicroStation users used the VAX as an effective file
server for MicroStation using DEC's Pathworks for years. That solution at that
time wasn't a lead by a "down with PC's!" mantra, but was rather an intelligent
way of squeezing life out of capable computer. Those that don't embrace
ProjectBank immediately will not go out of business, will not suffer financially
or technically--just as did those users that continued to use VAX equipment
several years ago. (BTW, we have at least half a dozen VAX's in use at my
company today.)
> >
> >As far as native access to AutoCAD files (for editing and use as reference
> files),
> >there seems to be no way to plot these hybrid files accurately, since we
> (like most
> >of the world) plot by weight, and the AutoCAD file will need to be plotted
> by color.
> >And don't even mention the AutoCAD fonts and line type files which will
> also need to
> >be synched among all the PCs connected to the ProjectBank.
> >
>
> *** But the very essence of ProjectBank is that there’s a DWG schema that
> displays DWG files without translation. Therefore, plotting CAN BE by color
> in DWG and by weight for DGN’s, even when they’re attached as reference
> files to one another. Now, in this case we’re talking about using ECM
> editors, not the current DGN one, but ProjectBank is a prerequisite to any
> of that. Fonts and other resource files (AutoCAD and MicroStation) are
> imported into your ProjectBank and become just one of the parts of your
> project. They’re automatically synched among the connected clients (sorry,
> you said not to mention it, but I couldn’t help myself) of ProjectBank.
Viewing an AutoCAD file is not good enough--we need to plot it as well. This
very question mystified the Bentley crew at the booth in Philly--I guess they
were unaware the ECM editor will (be required and) allow this. The fact that
AutoCAD fonts and line types (even fancy R13/14 ones) will be synched among all
clients should be the first point mentioned when this ProjectBank feature is
demo'd-- after all, these two items always rear their ugly head during
translations today. But the handling of AutoCAD's model space vs. paper space
remains a mystery of ProjectBank: I still think we’ll need to manage our
AutoCAD-toting subconsultants much the same way, if we choose to use
ProjectBank.
> >I thought the edit log was lame since anyone can type whatever they want
> (including
> >leaving the field blank).
>
> *** That’s kind of like saying that videotapes are “lame” because anyone can
> write anything they want on the outside label. The comments a user enters
> when he commits a change are just so someone else can figure out what he/she
> did. You’re right, if they choose to they can enter incorrect or misleading
> information, or they can enter nothing at all. In that case the log itself
> won’t really be useful and you’ve missed a great opportunity to help
> yourself. But, the important point is that the journal has in it EXACTLY
> what they really did – which elements he changed, added or deleted. If you
> want to figure out what happened when and by whom at some later point, then
> the journal will tell you exactly who did what, and what they said the
> reason was (the log entry). There’s no way to enter changes without them
> being journaled, so there’s no way around circumvent the system. Also, if
> you want to go back to a previous revision of a drawing, that’s always
> possible. I submit that what’s “lame” is today’s process that ignores and
> loses this invaluable information every day. And, I think it will be very
> useful even for projects WITH ONLY ONE USER (for example, when did I change
> that? What else did I change when I decided that should be 5m long?)
So how much disk space does that journal take up? And how easy is it to use? And
isn’t having a log and a journal paradoxical? If the log can be wrong and
incorrect, then who will use it (and not use the journal instead)? What if the
name of the design file changes? Will the journals carry over and remain intact?
Hmmm...
> > And the thread last month about "who saves first" and
> >"getting commitment to save" really helped exposed the advantages and
> disadvantages
> >of Project Bank.
>
> *** I maintain it only illustrates the advantages of ProjectBank. If you don
> ’t want to allow simultaneous edits of the same design file because your
> worried about the merging process (and I think that’s the 1998 equivalent of
> saying you’ll never allow PC’s in your company), then you can simply disable
> that by enforcing exclusive locking. However, I can assure you, there’s no
> way to get beyond today’s sub-optimal workflow coordination techniques
> without a good change merging scheme. ProjectBank is the only technology I
> know of that even begins to address that issue.
The work flow problem isn't two people not being able to work in the same file.
It's not even merging two disparate changes made on opposite ends of the country
(or world). Allowing two designers to make the changes you demo'd in Philly
(working in the same file, merging their changes, etc.) is simply indicative of
a higher-level coordination problem. In other words, if I have two designers
moving wall (or pier or abutment or pile) locations, then I have a bigger
problem, which I’m not looking for a software package to "solve" (since it
permits this action, albeit optionally). I may look at my assignment schedule or
responsibility matrix and see what on earth led to simultaneous changes
occurring on a project. After all, I wouldn't unintentionally allow two
contractors to pour concrete in exactly the same spot at the same time. Given
the freedom to do this will actually lead to more work, as some poor soul (me)
has to sift through the journal and then call each designer, to resolve the
state of the file. This is what went through my head during the demo (I was the
one in the 12th row grinning and shaking his head). I stick by my position:
ProjectBank is a solution in search of a problem.
>
>
> > I'm still not sure who has a use for this, since the last 2000+
> >file project I worked on required about 20 design files to be dynamically
> >shared--and e-mail worked just fine.
> >
> >Just my $0.02,
> >Simon
> >
>
> *** And people used to get around in horses and buggies just fine :).
> Seriously, I’m not accusing you of being a Luddite,
You’re right - you did already ;-)
> and you’re right to be
> skeptical of something before you’ve used it, but I’m convinced that this IS
> the future, and it’s my strong belief that EVERYONE has a use for this stuff
> (could you tell?).
>
> Anyway, that's my $.02, but I’ll admit that I’m biased. So now the world has
> $.04 available here on this topic.
>
> Keith
Undoubtedly, ProjectBank will improve the coordination on some projects, for
some clients, in some situations, which can be an advantage in cost or time. And
as was the case in the past, every single cost or time advantage eventually
becomes the norm. No design firm in the country would consider using
sticky-backs and mylar to prepare their plans in favor of CAD. The basic
advantage of CAD itself was eaten up by required shorter design schedules some
years ago. So even if ProjectBank is an advantage next year for some firms,
clients will eventually assume that anyone that has it will be able to produce a
better product more quickly, so they’ll require it—just the way dozens of DOT’s
require MicroStation today.
It’s my job to make software break before it’s put in the hands of our users. I
can’t just call up our MVAR and say “go ahead, here’s our server, here’s our
workstations, fire away!” I have to consider all costs, all impacts. As a
result, I’ve become immune to razzle-dazzle demos. To put this in perspective, I
have yet to see a real-life demo of ProjectWise via an Internet T-1 connection.
I’ve attended two demos of ProjectWise, and both got a bit ugly as the users
(not me) started to ask questions about realities: hardware costs, sharing work
space files, downloading large reference files, updating cell libraries, etc.--
items which ProjectWise handles weakly or not at all. Please keep in mind,
Keith, that sharing files isn’t the same as sharing information, and ProjectBank
seems like ProjectWise on steriods.
ProjectBank forces a work flow that is alien (albeit on the right track) to most
engineers (don’t know about architects, but my guess they’re the same). The
writing on the wall is clear, though: our engineers had better start glueing
themselves in front of the PC and using MicroStation and we better start
retraining our “CAD Operators” in order to use ProjectBank. After all, if the
non-engineers are moving pier locations and accepting/rejecting others’ changes,
we could be in for even longer design schedules.
Simon
Mark Hamstra
> Hi Keith,
> Did I hit a nerve or what! ;-) I do have some thoughts that you should consider
> to better understand my arguments and observations:
>
> Our industry is years way culturally from the workflow proposed by ProjectBank.
> We don't have 100% engineering use of MicroStation, which seems to be
> requirement for effective use of ProjectBank.
I'm not sure I'm understanding your point; but from what I am understanding of
it, I'm inclined not to agree with it.
[...]
> If it ain't broken, don't fix it --and ProjectBank looks
> like a solution in search of a problem.
Of course, you are entitled to your opinion, and if Keith won't lay claim to
calling you a Luddite, then I won't either --although you are making that
more difficult with each post ;-) You are probably correct that the diff-
iculties you are having in seeing the advantages of using ProjectBank are
work-cultural related. However, just because an industry or a particular
firm has a long tradition of doing things a certain way, that does not imply
that that way of doing business is the best or that any transition to an
alternative way is necessarily excrutiatingly difficult.
By way of example, the software industry has long used revision control and
work flow management tools to coordinate the process of coding, building,
certifying, and supporting its products. As a result, software developers in
general have a pretty good knowledge of how such tools work and what are the
advantages of using them. In particular, Bentley knows what it is like to
rebuild such a system, having recently converted our internal source code
control mechanism over to a system that is very similar to ProjectBank in many
respects. In other words, as close as is possible given the differing nature
of our customers' engineering endeavors and our own, we already use the Proj-
ectBank model --and we wouldn't dream of doing without it. In fact, there is
a telling saying among those software developers who understand the value of
such revision control systems... Q: What do you call software developers who
don't use revision control? A: Amateurs.
Certainly you are correct that your industry doesn't currently have that
level of appreciation for the value of a ProjectBank-like system. It will
--and probably a good deal sooner than you expect.
> Keith Bentley wrote:
[...]
> > *** my replies to your comments interspersed below.
[...]
> > *** Well, as to hardware requirements, if you’re using a file server today,
> > then I think you’ve already got everything you describe above (with the
> > exception of T1 lines) and certainly everything you need for PB. I don’t
> > know why you think PB requires a T1 line, except if you expect your clients
> > to connect directly to your servers, which I said I think will ultimately
> > become the norm, but is certainly not necessary to get started.
>
> The purported idea behind ProjectBank is expanded connectivity to improve
> workflow communication. And invariably, this will mean external communication,
> via the Internet--thus the T-1 lines.
Nope, that's not correct. ProjectBank can greatly improve engineering in-
formation management and coordination even in a purely local, "under one roof"
implementation. Certainly wide area interconnectivity using private or public
networks (although in the case of public networks like the Internet, I'd
strongly suggest the use of Virtual Private Networks) and high-speed,
dedicated circuits allows ProjectBank users to accomplish much that couldn't
realistically even be considered previously, but it is not true that all of
these elements are necessary components of a successful ProjectBank implemen-
tation. It is certainly possible to make effect use of ProjectBank with no
external information interconnects, or with limited interconnectivity --such
as dial-up or other low-speed internetwork connections, or even "sneaker net"
style physical transportation of removable media. In such applications, you
would be looking at offline synchronization tasks and/or hierarchical
ProjectBank servers, so the model would be somewhat different than the fully
interconnected one, but ProjectBank gives you the needed flexibility to
handle these alternative implementation models.
> My office doesn't "need" another
> software application to improve communication internally via ProjectBank--we, as
> is probably the case with other firms, hardly use the tools we already have to
> communicate effectively on projects.
Of course, that begs the question as to *why* those tools aren't being used....
> Internally, using ProjectBank would be like
> using cell phones within the office to make sure everyone communicates
> effectively--in a word: overkill.
That's hardly an appropriate analogy: cell phones would effectively only
duplicate existing communication means --whether traditional desktop phones,
intercomm system, or just shouting at the guy three cubicles down. In con-
trast, ProjectBank provides the means to communicate and coordinate in ways
that were either wholly impossible or only crudely approximated before.
A couple of analogies that would seem more appropriate would be: a time-
shared, mult-iuser computer system vs. a batch-mode, single user mainframe;
a recorded or transcripted deposition vs. relying strictly upon personal
recollection or brief notes and jottings. It's a little bit difficult to
recall the full impact of the transition from single user mainframes to
multi-user time-sharing systems (especially for those of us too young to
have first hand knowledge of it ;-), but the ability to share a resource
(the computer's CPU cycles) in a more efficient and coordinated way that
was almost entirely transparent to the end user has many similarities to
ProjectBank's more efficient sharing and coordination of engineering
information. Just as multi-user, multi-tasking systems didn't immediately
require one to fundamentally change workflows or programming style, but
eventually made such things as the Internet possible (which would have
been entirely impossible under the old paradigm), so too the ProjectBank
transition with its more efficient sharing and coordination of engineering
information resources need not be traumatic, and will pay off handsomely
as it is more fully exploited. Similarly, transcripted and recorded dep-
ositions are taken for granted in legal proceedings, and are seen as in-
dispensable to professionally performing the job --no Lawyer would even
consider relying upon memory or personal notes exclusively. Expect the
same level of requirement, reliance, and dependency from the information
management facilities available in ProjectBank.
[...]
> So ProjectBank is free? This, if true, was the most murkiest of points at Philly
> Forum.
Yes, as has been clearly stated from Keith's initial public introduction
of ProjectBank at the Proactive Engineering Symposium, ProjectBank is
free and will ship as part of MS/J when ProjectBank is completed.
> But what about the enterprise database? Is that included with
> MicroStation as well? And will we need to shoehorn that database onto an
> existing server?
What enterprise database? While ProjectBank will allow for coordination
with enterprise datastores (e.g., relational databases), an external database
is certainly not a prerequisite for using ProjectBank. ProjectBank is self-
contained.
> I simply imagine the installation headaches of ProjectBank.
Sorry, but that is pure speculation, and there is no fundamental reason why
ProjectBank itself or engineering information controlled by ProjectBank needs
be difficult to install.
> And what about file size? After editing a 300kb file and storing the changes, will
> the file remain 300kb?
The file itself doesn't exist within ProjectBank, as it has been subdivided
into its constituent compenents within the ProjectBank store, so your question
is kind of nonsensical. I wouldn't expect the overall size of a ProjectBank
project composed of the components from a single revision of a single file to
be hugely greater than the original file, though.
> What if both (or more) users choose to save both the
> original version and their new version: the file size will triple, right?
Wrong. Upon retrieval, the exported file would remain the same size as
always. Within the ProjectBank store, the current state of the project
would occupy roughly as much storage space as the original file. If the
components of the original file were copied over into a new file context,
then, yeah, you'd have a new set of components in ProjectBank --but that
is no different than making multiple copies of a file on a current, dumb
shared filesystem, and conceptually similar to copying a file into one's
workspace instead of using a reference file. In any case, the revision
history of the components could occupy considerably more space, but it
is fully under the users' control how much of that history needs to be
saved --although, once purged from ProjectBank's history, old revisions
cannot be recalled.
> ProjectBank may be free, but I see we'll pay in other areas.
Huh? Sure there are some transition, training, and administrative costs
to deal with, but the software itself is free with MS/J, and the hardware
requirements are roughly on a par with current fileservers.
> And the hierarchal
> arrangement of ProjectBanks implies all users (other firms, subconsultants,
> etc.) will need to use ProjectBank, right?
Nope. If you wanted to, you could use ProjectBank exclusively internally,
and handle file extraction/re-importation/conflict-resolution at the
boundary between your firm and other firms, consultants, etc. That's not
a very efficient leveraging of everything that ProjectBank has to offer,
but it wouldn't be more difficult than a similar current workflow; i.e.,
I copy this file from our fileserver, get it to the consultant somehow,
he works on it for a while then returns it to me, then I need to resolve
any conflicts between his work and any changes we've made in the meantime
before copying the file back to our fileserver. If anything, ProjectBank
would make that process easier through its automated conflict detection
and graphically assisted conflict resolution, as well as through any
annotations your internal people have made documenting the intent of
their changes.
> Kind of like ActiveX: "everyone can
> use it, isn't it great, oh, by the way, it only runs on Microsoft Explorer." And
> let me guess: you can't link ProjectBanks unless you also have ProjectWise.
I don't understand the ActiveX reference at all, but ProjectBank does not
require ProjectWise.
[...]
> > >I thought the edit log was lame since anyone can type whatever they want
> > (including
> > >leaving the field blank).
> >
> > *** That’s kind of like saying that videotapes are “lame” because anyone can
> > write anything they want on the outside label. The comments a user enters
> > when he commits a change are just so someone else can figure out what he/she
> > did. You’re right, if they choose to they can enter incorrect or misleading
> > information, or they can enter nothing at all. In that case the log itself
> > won’t really be useful and you’ve missed a great opportunity to help
> > yourself. But, the important point is that the journal has in it EXACTLY
> > what they really did – which elements he changed, added or deleted. If you
> > want to figure out what happened when and by whom at some later point, then
> > the journal will tell you exactly who did what, and what they said the
> > reason was (the log entry). There’s no way to enter changes without them
> > being journaled, so there’s no way around circumvent the system. Also, if
> > you want to go back to a previous revision of a drawing, that’s always
> > possible. I submit that what’s “lame” is today’s process that ignores and
> > loses this invaluable information every day. And, I think it will be very
> > useful even for projects WITH ONLY ONE USER (for example, when did I change
> > that? What else did I change when I decided that should be 5m long?)
>
> So how much disk space does that journal take up?
Depends on how much work you've done and how much of the revision history
you choose to retain. With disk storage at roughly $0.10/megabyte and
falling, I can't honestly say that I see the size requirements for the
journal being a problem.
> And how easy is it to use?
Trivial; it's transparent during the normal fetch/edit/save workflow and
very easy to query when you need to.
> And isn’t having a log and a journal paradoxical? If the log can be wrong and
> incorrect, then who will use it (and not use the journal instead)?
The journal isn't human readable, nor does it server as a summary of a set
of changes. In other words, if you were to dump out the contents of a
journal entry, you'd have something like raw DGN data --not at all useful
until you actually open it up within MicroStation. Only after you actually
did open up and display the data could you tell what it was, and then you
would still need to examine and analyze the graphical representation before
you could understand what is was. You still might not know *why* the
change was made, so you'd need to consult whoever made the changes (how you
go about finding that out without yelling down the hall, "Who moved the
plumbing chase in the 3rd floor men's room?", I don't know...) and ask
him or her why the change was made.
If you additionally have the log comment "Moved 3rd floor men's room plumbing
chase to make room for HVAC duct," then you know immediately the nature of
the changes made, whether this is a set of changes that you are interested
in, who made the changes, and when [there are timestamps and user identifi-
cation information in the log messages]. You accomplish all of that without
even needing to open the "file" in MicroStation's graphical environment.
Furthermore, dumping out the contents of the log for a file or whole project
(either in its entirety or between certain dates) immediately gives a
manager a succint, verbal summary of what has been done on the project, when,
and by whom.
Of course, it is entirely possible for whoever checked in the changes to
not enter a log comment or to make a false or incomplete entry, just like it
is possible for no one to answer your shout down the hall or to answer it
incorrectly. In any of these cases, the solution is identical: you kick the
offending person in the butt and tell him not to do that again. This is a
human relations problem, not a technical one --so perhaps my suggested
remedy for it is not necessarily the best ;-)
> What if the name of the design file changes? Will the journals carry over
> and remain intact?
> Hmmm...
That's the same issue we face in software development when a source code
file name changes, and there is no single, guaranteed correct answer.
Sometimes you don't want to bring all the revision history and log comments
along; you'd rather consider the current revision of the file to be a clean,
new baseline from which all changes should be re-rooted. Other times you
would like to bring some or all of the revsion history and log entries
along. Any decent source code revision system allows any competent, author-
ized personel to do just that; I don't know the details of how ProjectBank
will handle this issue, but I'd expect a similar statement to be true.
[...]
> The work flow problem isn't two people not being able to work in the same file.
> It's not even merging two disparate changes made on opposite ends of the country
> (or world). Allowing two designers to make the changes you demo'd in Philly
> (working in the same file, merging their changes, etc.) is simply indicative of
> a higher-level coordination problem. In other words, if I have two designers
> moving wall (or pier or abutment or pile) locations, then I have a bigger
> problem, which I’m not looking for a software package to "solve" (since it
> permits this action, albeit optionally). I may look at my assignment schedule or
> responsibility matrix and see what on earth led to simultaneous changes
> occurring on a project. After all, I wouldn't unintentionally allow two
> contractors to pour concrete in exactly the same spot at the same time. Given
> the freedom to do this will actually lead to more work, as some poor soul (me)
> has to sift through the journal and then call each designer, to resolve the
> state of the file. This is what went through my head during the demo (I was the
> one in the 12th row grinning and shaking his head). I stick by my position:
> ProjectBank is a solution in search of a problem.
So let me get this straight: you never have people make conflicting changes to
your design data, you never have people waiting to make changes to a file
until someone else has saved their changes (perhaps to a portion of the design
data that can't possibly conflict with the waiting person's pending changes
--the elements needing modification just happpen to reside in the same file),
you always know exactly what changes were made when and by whom, so that in
the impossibility that there actually was a conflict or inaccuracy in your
design files, you would know exactly whose fault it was and what they were
thinking to reach this erroneous state; and to top it all off, you never
have any difficulties working with ACAD or other file translations and you
couldn't possibly work any more effectively in the future with more intell-
igent design data instead of today's dumb lines and circles.
Now you've got me shaking my head: that is an amazing organization that you
are running.
[...]
> It’s my job to make software break before it’s put in the hands of our users. I
> can’t just call up our MVAR and say “go ahead, here’s our server, here’s our
> workstations, fire away!” I have to consider all costs, all impacts. As a
> result, I’ve become immune to razzle-dazzle demos. To put this in perspective, I
> have yet to see a real-life demo of ProjectWise via an Internet T-1 connection.
> I’ve attended two demos of ProjectWise, and both got a bit ugly as the users
> (not me) started to ask questions about realities: hardware costs, sharing work
> space files, downloading large reference files, updating cell libraries, etc.--
> items which ProjectWise handles weakly or not at all. Please keep in mind,
> Keith, that sharing files isn’t the same as sharing information, and ProjectBank
> seems like ProjectWise on steriods.
Actually, hammering on the weaknesses of ProjectWise only serves to strengthen
the case for ProjectBank: in some sense, ProjectWise is trying to stretch the
old file-based paradigm to its limits, while ProjectBank is built on a whole
new component-based paradigm and is offering a bridge back to file-based
MicroStation. It is only through this new paradigm that the full scope of
the Bentley Continuum can be realized. However, it is only fair to note that
ProjectWise is not trying to remake the world, but it seeking to make most
effective use of technologies that are currently available. As such, it is
a continuously evolving offering that will be seeing significant changes with
the advent of ProjectBank.
> ProjectBank forces a work flow that is alien (albeit on the right track) to most
> engineers (don’t know about architects, but my guess they’re the same).
This I don't see at all. ProjectBank can allow you to use exactly the same
workflow that you currently use: checkout a file from a fileserver, edit it,
check it back in. Just because it offers you a good deal more information and
assistance in coordinating design changes, and just because it *can* support
some workflows that were not really possible before, that doesn't mean that
it imeediately forces you into some new, alien, or untenable workflow.
> The writing on the wall is clear, though: our engineers had better start glueing
> themselves in front of the PC and using MicroStation and we better start
> retraining our “CAD Operators” in order to use ProjectBank. After all, if the
> non-engineers are moving pier locations and accepting/rejecting others’ changes,
> we could be in for even longer design schedules.
Huh? If you're in a strict "I'm an engineer, I don't do drafting; I'm a
draftsman, I don't do anything without an engineer's approval" mode of
working, then ProjectBank doesn't require that you change that. Just like
before, the engineer can hand a set of change requests to the draftsman,
who will then --just like before-- checkout the design file, make the
changes, and check the file back in. However, --not like before-- the
draftsman or engineer won't need to determine whether someone else is
working on an unrelated part of the same file before beginning the changes.
Also not like before, in the event that someone makes a mistake and tries
to check in a set of changes that would overwrite someone else's, then the
bells and whistles will instantly and automatically go off, the problem
will be immediately and graphically apparent, as will be the names of
those involved and the reasons for their making the changes. At that
point, the draftsman would need to call in the engineer to resolve any
questions --just like before.
Under the old shared filesystem approach, the conflict would likely have
gone undetected ["Of course I should save my changes and overwrite the
fileserver's copy: I'm the only one who's supposed to be working on this
file, so I must be up to date." If you ever have two people thinking
that at the same time, you'll find yourself searching for the backup
tape.] --at least until much later in the game-- and determining just
went wrong and what the correct solution is would be considerably more
difficult than with the aid of ProjectBank.
ProjectBank doesn't fundamentally change your job or responsibilities,
it just lets you responsibly do that job better.
--
Mark Hamstra
Bentley Systems, Inc.
Simon Wurster
Thanks for your clarifications of ProjectBank. But still some issues remain:
> [snip] (Bentley uses a ProjectBank-like package to manage their in-house source code)
> >
> > The purported idea behind ProjectBank is expanded connectivity to improve
> > workflow communication. And invariably, this will mean external communication,
> > via the Internet--thus the T-1 lines.
>
> Nope, that's not correct. ProjectBank can greatly improve engineering in-
> formation management and coordination even in a purely local, "under one roof"
> implementation.
[snip]
>
[snip] (ProjectBank doesn't require external users of MicroStation to run ProjectBank).
> > What if both (or more) users choose to save both the
> > original version and their new version: the file size will triple, right?
>
> Wrong. Upon retrieval, the exported file would remain the same size as
> always. Within the ProjectBank store, the current state of the project
> would occupy roughly as much storage space as the original file. If the
> components of the original file were copied over into a new file context,
> then, yeah, you'd have a new set of components in ProjectBank --but that
> is no different than making multiple copies of a file on a current, dumb
> shared filesystem, and conceptually similar to copying a file into one's
> workspace instead of using a reference file. In any case, the revision
> history of the components could occupy considerably more space, but it
> is fully under the users' control how much of that history needs to be
> saved --although, once purged from ProjectBank's history, old revisions
> cannot be recalled.
So, unless the ProjectBank is purged, file size will be an issue. That's my point.
> >
[snip] (ProjectBank is free.)
> If you wanted to, you could use ProjectBank exclusively internally,
> and handle file extraction/re-importation/conflict-resolution at the
> boundary between your firm and other firms, consultants, etc. That's not
> a very efficient leveraging of everything that ProjectBank has to offer,
> but it wouldn't be more difficult than a similar current workflow; i.e.,
> I copy this file from our fileserver, get it to the consultant somehow,
> he works on it for a while then returns it to me, then I need to resolve
> any conflicts between his work and any changes we've made in the meantime
> before copying the file back to our fileserver. If anything, ProjectBank
> would make that process easier through its automated conflict detection
> and graphically assisted conflict resolution, as well as through any
> annotations your internal people have made documenting the intent of
> their changes.
As long as the file name remains the same(?)...
[snip] (ProjectBank doesn't require ProjectWise).
[snip] (Journals are small, based on revision history).
[snip] (ProjectBank is as easy to use as as the normal fetch/edit/save workflow.
> > And isn’t having a log and a journal paradoxical? If the log can be wrong and
> > incorrect, then who will use it (and not use the journal instead)?
>
> The journal isn't human readable, nor does it server as a summary of a set
> of changes. In other words, if you were to dump out the contents of a
> journal entry, you'd have something like raw DGN data --not at all useful
> until you actually open it up within MicroStation. Only after you actually
> did open up and display the data could you tell what it was, and then you
> would still need to examine and analyze the graphical representation before
> you could understand what is was. You still might not know *why* the
> change was made, so you'd need to consult whoever made the changes (how you
> go about finding that out without yelling down the hall, "Who moved the
> plumbing chase in the 3rd floor men's room?", I don't know...) and ask
> him or her why the change was made.
>
So journal data is about the same as locating that person that did the edit and asking
them. Okay...
[snip] (asking, journaling, and logging all have their limitations and won't help the
workflow explicitly, only implicitly.)
> > What if the name of the design file changes? Will the journals carry over
> > and remain intact?
> > Hmmm...
[snip] (Answer: yes, but must be done manually.)
> [...]
>
> > The work flow problem isn't two people not being able to work in the same file.
> > It's not even merging two disparate changes made on opposite ends of the country
> > (or world). Allowing two designers to make the changes you demo'd in Philly
> > (working in the same file, merging their changes, etc.) is simply indicative of
> > a higher-level coordination problem. In other words, if I have two designers
> > moving wall (or pier or abutment or pile) locations, then I have a bigger
> > problem, which I’m not looking for a software package to "solve" (since it
> > permits this action, albeit optionally). I may look at my assignment schedule or
> > responsibility matrix and see what on earth led to simultaneous changes
> > occurring on a project. After all, I wouldn't unintentionally allow two
> > contractors to pour concrete in exactly the same spot at the same time. Given
> > the freedom to do this will actually lead to more work, as some poor soul (me)
> > has to sift through the journal and then call each designer, to resolve the
> > state of the file. This is what went through my head during the demo (I was the
> > one in the 12th row grinning and shaking his head). I stick by my position:
> > ProjectBank is a solution in search of a problem.
>
> So let me get this straight: you never have people make conflicting changes to
> your design data, you never have people waiting to make changes to a file
> until someone else has saved their changes (perhaps to a portion of the design
> data that can't possibly conflict with the waiting person's pending changes
> --the elements needing modification just happpen to reside in the same file),
That's a big "Yes." It's possible, and we do it everyday, even working with other firms
and subconsultants. We make sure there are no conflicts via judicious use of file
naming, reference files, project scheduling, and design responsibility.
> you always know exactly what changes were made when and by whom, so that in
> the impossibility that there actually was a conflict or inaccuracy in your
> design files, you would know exactly whose fault it was and what they were
> thinking to reach this erroneous state;
Everyone knows where a file came from, and who (which office) is responsible for it.
That's not good software, that's good business.
> and to top it all off, you never
> have any difficulties working with ACAD or other file translations and you
> couldn't possibly work any more effectively in the future with more intell-
> igent design data instead of today's dumb lines and circles.
We usually talk jv partners and subs into using MicroStation on
MicroStation-deliverable projects. They buy the software and training, and we provide
the work space (seed files, macros, menus, MDLs, cell libs, etc.) and project-specific
training. And with those subs that refuse, we "cripple" their use of AutoCAD to enable
smooth translations. And what good is AutoCAD data in ProjectBank if the client requires
good ol' fashioned MicroStation .DGN files delivered at the end of the project?
> Now you've got me shaking my head: that is an amazing organization that you
> are running.
Thank you!
> [...]
>
> [snip] (ProjectWise and ProjectBank are unrelated. ProjectBank will supersede
> ProjectWise since it's not file-based.)
>
> > ProjectBank forces a work flow that is alien (albeit on the right track) to most
> > engineers (don’t know about architects, but my guess they’re the same).
>
> This I don't see at all. ProjectBank can allow you to use exactly the same
> workflow that you currently use: checkout a file from a fileserver, edit it,
> check it back in. Just because it offers you a good deal more information and
> assistance in coordinating design changes, and just because it *can* support
> some workflows that were not really possible before, that doesn't mean that
> it imeediately forces you into some new, alien, or untenable workflow.
Most firms (and most projects in those firms) and our clients still use the
engineer->drafter->engineer drawing creation workflow model. The non-CAD engineer makes
a markup, the CAD user makes the changes and makes a hardcopy plot, the non-CAD engineer
reviews, etc. At which point in this workflow model does the "coordination in design
changes" via ProjectBank occur? It _never_ does, because the engineer is _used_ to
paper, not logs, journals, or MicroStation. How is this and advantage especially since
it "allows you to use the same workflow"?
So where are all these firms that are editing MicroStation files with write-lock
protection? I thought that went away when people stopped using Pathworks. And I still
have no idea why two people need to edit the same file at the same time and reconcile
their (and others') changes. I thought that disappeared when people stared using Netware
LANs (and reference files). We have not had these problems in five years. I suspect
other firms have solved these problems as well using careful, up-front project
organization.
If the log/journal etc. is supposed to tie into ISO 9000 QA/QC compliance (where each
revision can be tracked and traced), sorry: the audit trail must be done manually with
colored markups (of drawings). [Just repeating what our QA officer said.]
> ProjectBank doesn't fundamentally change your job or responsibilities,
> it just lets you responsibly do that job better.
>
> --
> Mark Hamstra
> Bentley Systems, Inc.
I hope this discourse has been informative to others, and I hope Keith can use this to
clarify the many issues I and others have raised in the NG about ProjectBank (and
ProjectWise). Like the move to Windows, market momentum (and the perception that there's
a market advantage) may cause many firms to move to ProjectBank (especially since it's
free ;-) ). My experience with the many flavors of Windows has taught me learn the
limitations and liabilities of any new software product (like ProjectBank) before I
install it.
I wish you and Keith (and the rest of Bentley) good luck with ProjectBank.
Simon
Mark Hamstra
> Hi Mark,
> Thanks for your clarifications of ProjectBank. But still some issues remain:
[...]
> > > What if both (or more) users choose to save both the
> > > original version and their new version: the file size will triple, right?
> >
> > Wrong. Upon retrieval, the exported file would remain the same size as
> > always. Within the ProjectBank store, the current state of the project
> > would occupy roughly as much storage space as the original file. If the
> > components of the original file were copied over into a new file context,
> > then, yeah, you'd have a new set of components in ProjectBank --but that
> > is no different than making multiple copies of a file on a current, dumb
> > shared filesystem, and conceptually similar to copying a file into one's
> > workspace instead of using a reference file. In any case, the revision
> > history of the components could occupy considerably more space, but it
> > is fully under the users' control how much of that history needs to be
> > saved --although, once purged from ProjectBank's history, old revisions
> > cannot be recalled.
>
> So, unless the ProjectBank is purged, file size will be an issue. That's my point.
File size won't be an issue, the size of the ProjectBank store will be.
How much of an issue is another matter. What you are looking at is
something like the difference in fileserver data storage taken up by
all your files if they had never been compressed vs. if they are always
compressed on save. Yes, the uncompressed files will be a good deal
larger. Yes, retaining a complete ProjectBank history will make your
ProjectBank store a good deal larger. But we're not talking about
overwhelming torrents of bits spilling out all over the floor,
particularly not when you can buy enormous vats to store them in for
very little money.
Just as an exercise, do a quick inventory on your current active design
files, tally up how much disk space they currently use, be exceedingly
generous and multiply that number by 10. Now pull out your latest
mailer from Bob's Discount Computer Parts and look up how much it will
cost you to buy that much hard drive space. Not much.
So to answer your point: Yes, datastorage usage will be an issue, but
no, datastorage usage won't be an issue worth worrying about.
> > If you wanted to, you could use ProjectBank exclusively internally,
> > and handle file extraction/re-importation/conflict-resolution at the
> > boundary between your firm and other firms, consultants, etc. That's not
> > a very efficient leveraging of everything that ProjectBank has to offer,
> > but it wouldn't be more difficult than a similar current workflow; i.e.,
> > I copy this file from our fileserver, get it to the consultant somehow,
> > he works on it for a while then returns it to me, then I need to resolve
> > any conflicts between his work and any changes we've made in the meantime
> > before copying the file back to our fileserver. If anything, ProjectBank
> > would make that process easier through its automated conflict detection
> > and graphically assisted conflict resolution, as well as through any
> > annotations your internal people have made documenting the intent of
> > their changes.
>
> As long as the file name remains the same(?)...
It's the same as now: If one of your outside agents is changing file
names on you, you tell them to stop doing that, open up the mislabeled
file that you just got back from them, figure out what filename it really
should have before putting it back in your archives, rename the file and
check it in. Same process with a renamed file in the ProjectBank
scenario we are describing, but you have the additional information and
conflict detection associated with any concurrent internal work.
[...]
> So journal data is about the same as locating that person that did the edit and asking
> them. Okay...
Well, no... in the nomenclature we've adopted in this thread, the "log"
entries are like asking someone what they did; the "journal" entries are
more similar to the contents of your Undo buffer: a precise record of
MicroStation data operations stored as MicroStation data, and thus not
particularly good at summarizing or explaining itself or its creator's
intentions even when it is displayed graphically. Of course, the
ProjectBank journal is much more flexible and useful than is an indiv-
idual MicroStation user's Undo buffer.
[...]
> That's a big "Yes." It's possible, and we do it everyday, even working with other firms
> and subconsultants. We make sure there are no conflicts via judicious use of file
> naming, reference files, project scheduling, and design responsibility.
[...]
> Everyone knows where a file came from, and who (which office) is responsible for it.
> That's not good software, that's good business.
[...]
> We usually talk jv partners and subs into using MicroStation on
> MicroStation-deliverable projects. They buy the software and training, and we provide
> the work space (seed files, macros, menus, MDLs, cell libs, etc.) and project-specific
> training. And with those subs that refuse, we "cripple" their use of AutoCAD to enable
> smooth translations. And what good is AutoCAD data in ProjectBank if the client requires
> good ol' fashioned MicroStation .DGN files delivered at the end of the project?
[...]
> Most firms (and most projects in those firms) and our clients still use the
> engineer->drafter->engineer drawing creation workflow model. The non-CAD engineer makes
> a markup, the CAD user makes the changes and makes a hardcopy plot, the non-CAD engineer
> reviews, etc. At which point in this workflow model does the "coordination in design
> changes" via ProjectBank occur? It _never_ does, because the engineer is _used_ to
> paper, not logs, journals, or MicroStation. How is this and advantage especially since
> it "allows you to use the same workflow"?
The manual coordination process you are describing certainly does work
adequately (else why would many firms use something similar), but it
is definitely also not based upon current technology (you noted yourself
that it is essentially a 50+ year old workflow.) While it may have been
necessary to use such a methodology before the current state of the art
in information processing was reached, in the context of that art, such
a workflow is exceptionally labor, resource, and time intensive, is
inflexible, maladaptive, and rigidly mechanistic, and provides little in
the way of automated checks and safeguards.
In other words, you are using people to execute the tedious details re-
quired to properly manage your business. Instead, you could be supple-
menting that management or replacing that tedium with technology that
doesn't get bored or tired and is much more accurate. Beyond merely
duplicating or augmenting your current workflow, ProjectBank and other
Bentley Continuum technologies will allow you to leverage their capabil-
ities to develop and explore newer, faster, more effecient, more flex-
ible and more adaptive workflows without giving up the accountability
you need.
As I told you before, simply duplicating your current workflow while
replacing your current fileserver with a ProjectBank server doesn't
come close to leveraging the capabilities that ProjectBank offers. It
is certainly possible to do so, so the complaint that "ProjectBank will
make us change our existing workflow" doesn't hold water. However, you
are not being forced to use ProjectBank; so if you are content to follow
others' lead, you can continue with the same old same old. Others can
and do see the advantages that are available to them through ProjectBank
--many of them see these advantages because they have tried to adopt the
more productive workflows that have been hinted at by previous technology,
found many of the problems in doing so, and recognize that ProjectBank
provides an elegant and flexible solution to these problems. As a result,
many are mostly or entirely convinced that the flexibility of incremental
implementation offered by ProjectBank and other Bentley Continuum offer-
ings means that they can begin to profit from implementing these tech-
nologies at first opportunity.
An aside on "what good is AutoCAD data in ProjectBank if the client
requires good ol' fashioned MicroStation .DGN files delivered at the end
of the project?": The DWG/DXF translation facilities in MicroStation don't
suddenly disappear just because you start using ProjectBank, so it is
certainly still possible to translate and export just DGN data for such a
client --though it would be much simpler and more convenient if the client
were also using ProjectBank, making such a translation unnecessary.
[...]
> So where are all these firms that are editing MicroStation files with write-lock
> protection? I thought that went away when people stopped using Pathworks. And I still
> have no idea why two people need to edit the same file at the same time and reconcile
> their (and others') changes. I thought that disappeared when people stared using Netware
> LANs (and reference files). We have not had these problems in five years. I suspect
> other firms have solved these problems as well using careful, up-front project
> organization.
There is nothing inherent in the use of a shared filesystem (like Novell,
SMB, NFS, AFS, Coda, or whatever) that guarantees freedom from conflict or
the need for simultaneous edits of a file. If anything, such filesystems
are typically maintained without any kind of file locking, so they actually
encourage inadvertant data overwrites and unaccountability. Without the
addition of a revision control system, the only way to address these problems
is through rigorous, unrelenting, and error-free manual control over who has
write permissions to each and every file. Furthermore, unless you go to
the ridiculous extreme of placing only single elements in each design file,
you are write-controlling more data than is necessary with each file-level
atom (i.e., edits are performed on elements/components and files contain
multiple elements/components, so any file-level lock necessarily locks more
elements than is strictly necessary for any particular edit.)
Unless you have developed a scheme whereby you can a priori place elements
within files in such a manner that it is guaranteed that concurrent design
change requirements will never occur within the same file partition through-
out the lifetime of the project, and have guaranteed mechanisms by which such
a scheme will always and infallibly be enforced, then it is a matter of prob-
ability whether simultaneous edits of a file will be necessary and/or inad-
vertant data overwrites will occur. Yes, you can significantly reduce the
probability of the need for such simultaneous edits by attempting such a file
division schema, but I'll posit that it is impossible to guarantee elimination
of such a need. Furthermore, the creation and enforcement of such a scheme
requires considerable human effort. All of that effort and rigidity can be
eliminated through the use of ProjectBank.
> If the log/journal etc. is supposed to tie into ISO 9000 QA/QC compliance (where each
> revision can be tracked and traced), sorry: the audit trail must be done manually with
> colored markups (of drawings). [Just repeating what our QA officer said.]
I don't know the details of the ISO 9000 spec, so I can't really comment
as to whether this is correct or not. However, if that is really what
ISO 9000 requires, then it is a fundamentally broken specification. The
level of detail, accuracy, and accountability offered through ProjectBank
and such techniques as digitally signed electronic documents is far beyond
what is possible using paper audit trails. Digitally signed documents are
increasingly being legally accepted, revision control histories are part
and parcel of many software development related litigations, and I would
expect the same thing to become true of design data versioning systems
like ProjectBank.
[...]
> I hope this discourse has been informative to others, and I hope Keith can use this to
> clarify the many issues I and others have raised in the NG about ProjectBank (and
> ProjectWise). Like the move to Windows, market momentum (and the perception that there's
> a market advantage) may cause many firms to move to ProjectBank (especially since it's
> free ;-) ). My experience with the many flavors of Windows has taught me learn the
> limitations and liabilities of any new software product (like ProjectBank) before I
> install it.
>
> I wish you and Keith (and the rest of Bentley) good luck with ProjectBank.
Well, thanks; and I'll try to ignore the guilt by association with Windows
comment ;-).
Chris Zakrewsky
> Just as an exercise, do a quick inventory on your current active design
> files, tally up how much disk space they currently use, be exceedingly
> generous and multiply that number by 10.
... and transmit it thru 33K dial-up connection during peak time.... good night.
"Connection terminated by the host."
"Timed out."
Got nuts.
Again...
Explorer exitting with the exception 0x000005
> I don't know the details of the ISO 9000 spec, so I can't really comment
> as to whether this is correct or not.
... lots, LOTS of paperwork + the proper fonts for each and one heading.
Then, it is traceable down to the individual who applied the wrong font.
In the nutshell -- it's it.
PS: Sorry for butchering 230+ lined of wisdom down to triviality like this.
Can't help. It's a Saturday...
--
Best Regards,
/Chris "all those comments" Zakrewsky
Mark Hamstra
> Late Saturday's mumbling:
>
> > Just as an exercise, do a quick inventory on your current active design
> > files, tally up how much disk space they currently use, be exceedingly
> > generous and multiply that number by 10.
>
> ... and transmit it thru 33K dial-up connection during peak time.... good night.
> "Connection terminated by the host."
> "Timed out."
> Got nuts.
> Again...
> Explorer exitting with the exception 0x000005
Huh? Who said anything about needing to transmit that amount of
data across a PSTN connection? In the ProjectBank context under
discussion, the only reason you would need to move that much data
is if you wanted to completely duplicate an entire ProjectBank
store in another location ...in which case you are right: doing
that across a 33.6K anolog modem would be a pretty stupid and
fruitless endeavour.
> > I don't know the details of the ISO 9000 spec, so I can't really comment
> > as to whether this is correct or not.
>
> ... lots, LOTS of paperwork + the proper fonts for each and one heading.
> Then, it is traceable down to the individual who applied the wrong font.
> In the nutshell -- it's it.
Sheesh! I'm glad I don't have to deal directly with that level
of stupidity!
> PS: Sorry for butchering 230+ lined of wisdom down to triviality like this.
> Can't help. It's a Saturday...
As long as you're kind enough to call them "wisdom," I'll look
the other way while you butcher them :-).
Keischar.Seah
from what I've heard here, I can't wait to get my hands on ProjectBank.
Eventhough, I haven't anyone to collaborate with at the moment. :-) It
sounds almost tailor made for architects.
What bugs me is the idea that the user still has to work with '100 % dgn '
files.
DGNs probably smoke as far as file formats go, but they are out of the box
very problematic as far as heirachies go. I still can't edit/replace cells
at different nest depths after donkeys years. Editing Groups, cells etc.
always involves some very tedious dropping and rebuilding. The whole
Reference file stuff is crippled by a very rudimentary Interface. It's
claimed that Ustn has up to 16,000 levels but try using using them. In most
cases the AutoCrap way is alot more straight forward and as such more
readily put into practice.
I don't know why SE was touted as a necessary transition release. The
average user could have gone from 95 to J (95+3) without blinking. It seems
to me that ProjectBank is the real Hump here. Going from J to ECM will
really be the eye opener. J+3 ? Bentley should really consider use
ProjectBank to emeliorate some of the current file format's shortcomings.
Please see my pet pipe dream on November 13th Re: Microstation J Question
thread for a better idea of what I mean (Also please comment!). I'm sure
that most of it is really doable in the current framework and can be
perverted positively in whatever new paradigm that comes to visit with ECM.
TIA
Keith Bentley
Sorry, I'm not going to "debate" ProjectBank vs. no-ProjectBank with you if
your argument amounts to "that's not how we've always done things".
Especially when the amount of change required to start using ProjectBank is
minimal and the benefits are immediate. Maybe its just a knee-jerk negative
reaction to any change, but I tend to think that you've just formed some
misconceptions about what it is and how it works(understandable since you’ve
never really seen or used it). Nonetheless, your opinions, while I believe
ill conceived or maybe just shortsighted, are welcome and nobody is going to
force you to use anything you don’t want to. After you’ve had a chance to
use ProjectBank, I’m sure we can have a more fruitful discussion about its
relative merits.
You do raise a few questions that may have confused others and I would like
to therefore address:
You ask about an enterprise database, and whether that is included in
ProjectBank. Just to be clear, THERE IS NO DATABASE (enterprise or
otherwise) in ProjectBank. ProjectBank is a server-resident program, a
license for which is included with MicroStation. There are no other
prerequisites for ProjectBank.
You ask about file size, implying that when three users save changes to a
file that the file size will triple. This question illustrates a basic lack
of understanding of ProjectBank. When you save a modified file to a
ProjectBank, ONLY THE CHANGES are saved, not the whole file. Therefore, the
amount of disk space (on the server, the only place where this discussion
has any relevance – file size on the client is unchanged) required for a
file is in proportion to the number of changes to a file, regardless of how
many users make changes to it. Certainly ProjectBank will require FAR LESS
disk space than requiring everyone to save a full copy of every version of a
file as is often the case today (see below).
Let me (re-)explain the journalling concept. Whenever you make a change to a
file and decide to “check it in”, you connect to your ProjectBank.
ProjectBank automatically detects everything youve done in your session and
saves those changes in its journal. You can then type in a short note about
what you did to “label” the journal entry. That label is what’s shown in the
tabular log of the journal entries and you can use it for whatever you
like – just like you use the labels on the outside of a videotape.
You assert that ProjectBank is a solution looking for a problem. I make my
living and happen to have spent a great deal of my time thinking about the
problems of workflow coordination and information interchange in engineering
projects and, respectfully, I disagree. But as an example of how ProjectBank
would be invaluable, this was posted to this very newsgroup only last month:
junk...@gc.com wrote:
Hi,
> I have 2 large design files that are almost identical,
> one just being a more recent copy of the other. The more recent
> will have perhaps a few hundred lines more than the older and these
> lines could be scattered throughout the design.
> Is there a utility or a method of outputting to a third
> file only the elements that are NOT in common with both files.
> (in other words "what new lines have been added to the newer
> design file”).
> Thanks in advance to anyone who may have a suggestion.
To which a very wise man (OK, it was you) replied:
>Hi Junkyard,
>There are some third party applications that do this, but the
>poor-person's (used to be poor-man's) way would be to reference one file
>to the other, turn the color of the reference file to something bright
>(using level symbology), turn the active file's colors dark (using a
>color table or level symbology), and additions in the reference file
>that aren't in the active file will appear brightly colored. Caution:
>this will only show additions/deletions--it won't show modification of
>text or changes in symbology.
>HTH,
>Simon
Now, why do you suppose “junkyard” was asking for this? And why was it that
you had a ready-made, albeit admittedly incomplete, cumbersome, yet
unreliable solution for him (fwiw, I don't know why you singled out
modifications to text, any modification to an existing element is going to
look like a delete and an add. Also, unless you reverse the symbology and do
this twice I don't see how you proport to detect additions)?
Could it be because you and he both had a need to tell what happened between
two versions of a drawing? Thank goodness both you and he had enough
forethought to save every version of every file you ever cared about (but
think of all the disk space wasted for that). And when you find out what was
changed, how are you going to find out who changed it, and why? And maybe
some of the changes were due to information being moved from one drawing to
another, but how would you know where to even look for those other drawings?
Are you starting to see where ProjectBank can make your life easier?
Keith
vis...@calgary.daxxes.com
readers perhaps) about ProjectBank. It explained more than what white paper
by Mr. Keith has to describe. I fully appreciate the red flags raised by Mr.
Simon and one has to consider all the aspects before accepting any new
technology. ( when money is at stake ) One big concern is how well people
using MicroStation ( I mean "Cad Operator" class ) adapts to new technology.
Though PB is free with MS/J, the training and experimentation cost might be
killing. As far use of version control software among the Software Developers
goes, I have seen developers struggling with it ( not necessarily Amateurs).
And when software developers struggle to adapt to this kind of comp
technology, one can project the same with CAD users. I have not seen the demo
of ProjectBank/Wise, but sounds promising enough if used and exploited
CORRECTLY. Afterall component level sharing of CAD information is definitley
superior to traditional file-sharing. But I Hope Bentley does not enforce use
of it with future versions of MS and MS/J. Thanks for updating, Cheers, - Viv
In article <xzogpso...@sullivan.bentley.com>, Mark Hamstra
<mark.h...@bentley.com> wrote:
-----------== Posted via Deja News, The Discussion Network ==----------
Stefan Jager [Bentley]
Mark Hamstra wrote:
> [snip]
> > > I don't know the details of the ISO 9000 spec, so I can't really comment
> > > as to whether this is correct or not.
> >
> > ... lots, LOTS of paperwork + the proper fonts for each and one heading.
> > Then, it is traceable down to the individual who applied the wrong font.
> > In the nutshell -- it's it.
>
> Sheesh! I'm glad I don't have to deal directly with that level
> of stupidity!
Be very glad Mark. I have had to, and it's really no fun ...... but Project Bank would
be ideal for the purpose.
>
> [snip]
But I would like to say to Simon that I really really wish I had had Project Bank some
five years ago, when I was still working at a major engineering company .......
And also that from my experience, I have a really hard time believing Simon when he
says that they (almost?) never have problems.
Off course, one might (probably rightfully so) say that I'm biased :-)
Stefan Jager
=================== Engineering the Future Together ====================
Bentley Systems Europe select....@bentley.nl
Wegalaan 2, 2132 JC Hoofddorp General Telephone: +31 23 5560 560
P.O. Box 2045, 2130 GE Hoofddorp Support Telephone: +31 23 5560 555
The Netherlands Support Fax: +31 23 5560 556
====== Visit our European Web pages at http://www.bentley.com/ema ======
Odd Hallstein Ystanes
<keith....@bentley.com> wrote:
>Let me (re-)explain the journalling concept. Whenever you make a change to a
>file and decide to “check it in”, you connect to your ProjectBank.
>ProjectBank automatically detects everything youve done in your session and
>saves those changes in its journal. You can then type in a short note about
>what you did to “label” the journal entry. That label is what’s shown in the
>tabular log of the journal entries and you can use it for whatever you
>like – just like you use the labels on the outside of a videotape.
Short stupid question: Will ProjectBank be able to journal/detect
changes in files from outside clients? (.DWG files mostly)
If so and it works reliable it will be very useful!
To all those who does not see the idea in ProjectBank.
I suppose You've all suffered from a UNDO buffer overrun
when moving a big cell ... You name it. ProjectBank may
be the escape from such disasters in the future...
Regards, O.H.Ystanes
Mark Hamstra
> On Sun, 29 Nov 1998 11:23:04 -0500, "Keith Bentley"
> <keith....@bentley.com> wrote:
>
> >Let me (re-)explain the journalling concept. Whenever you make a change to a
> >file and decide to “check it in”, you connect to your ProjectBank.
> >ProjectBank automatically detects everything youve done in your session and
> >saves those changes in its journal. You can then type in a short note about
> >what you did to “label” the journal entry. That label is what’s shown in the
> >tabular log of the journal entries and you can use it for whatever you
> >like – just like you use the labels on the outside of a videotape.
>
> Short stupid question: Will ProjectBank be able to journal/detect
> changes in files from outside clients? (.DWG files mostly)
>
> If so and it works reliable it will be very useful!
If I understand your question correctly, the answer is yes. For example,
if I check out a file [DGN or DWG or any other filetype that has a
corresponding schema to support it within ProjectBank] from ProjectBank,
send it to an outside user (consultant, subcontractor, whatever) who
then makes changes to that file and returns it to me, then when I
take that returned file and go to check it back into ProjectBank, it will
be exactly as if I had made all the changes on a local workstation. In
other words, on check in, ProjectBank will automatically detect any
changes that have been made to the file by the outside agent and add
those changes to the ProjectBank journal. It will also prompt me for a
log message to associate with those changes. Furthermore, if any other
(internal or external) users' changes to the file have been checked into
ProjectBank since the time the file was originally checked out and sent
to the outside agent, then ProjectBank will highlight those changes and
graphically assist me in deciding how they should be properly merged with
the changes made by the outside agent. That merge must be done before
the outside agent's changes may be checked in and added to the journal.
Of course it will work reliably; it's pretty much useless if it doesn't.
> To all those who does not see the idea in ProjectBank.
> I suppose You've all suffered from a UNDO buffer overrun
> when moving a big cell ... You name it. ProjectBank may
> be the escape from such disasters in the future...
You do need to be clear as to whether those changes have made it into
ProjectBank, however. If I have checked out a file from ProjectBank, then
made a large number of changes that have overflowed the undo buffer, but I
never checked any of the changes that I have made back into ProjectBank,
then those changes that have spilled out of the undo buffer are still un-
recoverable. However, if I have checked several interim revisions of the
file into ProjectBank, then it is a simple matter to revert the state of
my working file to any one of those interim revisions. Of course, it is
also simple to return to the revision that I initially started working on,
or any other checked in revision.
To have a local, "on the fly" change control system that doesn't require
a conscious break in one's workflow to check a file back into ProjectBank
and that doesn't suffer from many of the limitations of the current
MicroStation undo buffer, you'll have to wait for the transaction manage-
ment facilities that are an integral part of Engineering Component Model-
ing (ECM-mode) editing within MicroStation/J.
Odd Hallstein Ystanes
>> Short stupid question: Will ProjectBank be able to journal/detect
>> changes in files from outside clients? (.DWG files mostly)
>Mark Hamstra <mark.h...@bentley.com> wrote:
>If I understand your question correctly, the answer is yes. For example,
>if I check out a file [DGN or DWG or any other filetype that has a
>corresponding schema to support it within ProjectBank] from ProjectBank,
>send it to an outside user (consultant, subcontractor, whatever) who
>then makes changes to that file and returns it to me, then when I
>take that returned file and go to check it back into ProjectBank, it will
Just to make it a bit more clear. I was thinking of files created by
somebody (company A) without ProjectBank (file X). Who send this file
X to someone with ProjectBank (Company B). Then file X is revised by
company A and sent again to company B. Company A forgot to mark some
of the revisions made in X. Is then company B able to automaticly
detect all the revisions made both the marked ones and the unmarked
ones in file X?
>>th...@online.no (Odd Hallstein Ystanes) writes:
>> If so and it works reliable it will be very useful!
>Mark Hamstra <mark.h...@bentley.com> wrote:
>Of course it will work reliably; it's pretty much useless if it doesn't.
uh, recently (a few hours ago) I read an article about QA/QC in the
software business. I've directly translated some of it from Norwegian:
"... examination shows that Quality Assurance & Controll is almost
non existing in the software industry ..."
BTW:
If I've not got something wrong Linux is one of Your favorites
We use Windows NT 4.0 but I think if MicroStation was supported
on the Linux platform (commercial version) we might switch to gain
back performance. We've renamed Windows NT to Windows "vente"
Then Norwegian word "vente" can be translated to "wait" in English.
Regards, O.H.Ystanes
--
My statements may be interpreted as hints but is not supposed to be
offences . . and it's my thoughts and not my employers view.
Keith Bentley
>Just to make it a bit more clear. I was thinking of files created by
>somebody (company A) without ProjectBank (file X). Who send this file
>X to someone with ProjectBank (Company B). Then file X is revised by
>company A and sent again to company B. Company A forgot to mark some
>of the revisions made in X. Is then company B able to automaticly
>detect all the revisions made both the marked ones and the unmarked
>ones in file X?
>
detect what has been changed between two revisions of a file.
There are several modes for showing what's changed and the user interface
has toggle buttons to show, overlaid, the before and after versions of the
file (or files, if reference files are also involved). Unchanged elements
are dimmed, and new/changed/deleted elements hilited.
I expect this sort of workflow and usage of ProjectBank to be very common.
However, let me just clarify the way file X would be exchanged between
company A and company B. Company A (without ProjectBank) would create your
new file X and, after internally signing off on it, send it to company B.
Company B would then "check in" file X with an initial revision number and
probably a brief comment to the effect that it was submitted by Company A
(obviously internal procedures will differ, but I'm making the point
that someone from Company B had to consciously decide to accept the drawing
from Company A).
If Company A subsequently wishes to make additional changes to file X, then
someone at Company B has to "begin a transaction" for them. This involves
creating a briefcase with the relevant files in them and then sending the
extracted DGN or DWG files back to Company A (it should be apparent that
many such transactions can be simultaneously active with multiple
subcontractors, even with the same drawing files in them). When the file
comes back from Company A to Company B, the changes are put back into the
briefcase synchronized with the then-current master in ProjectBank and
changes (made by Company A, and by others since Company A started editing
the files) can be compared. The changes can be “checked in”, and the process
can then restart.
On the surface of it, it may seem like this back-and-forth exchange of files
from A -> B -> A may seem like a waste, particularly for the original
revision, since it may seem like a new file couldn’t possibly have any
conflicts with other changes. But that’s not quite true, and understanding
why reveals one of the great advantages of ProjectBank. With ProjectBank, it
will be possible to have “global” consistency checks on project data. For
example, suppose you have a corporate numbering scheme for parts (or
line-numbers, or doors, or whatever) that requires uniqueness (or maybe a
more complicated assignment algorithm based on company standards) across the
entire project. Alternatively, imagine an automatic
level/symbology/standards checker that verifies files for internal and
intra-file consistency rules. The synchronization process at check-in
enforces those rules, so it is possible that the file you attempt to check
in can either be rejected for some reason or may be automatically updated.
It is therefore necessary to “check out” a file, even if you just checked it
in.
Furthermore, consider security concerns. Suppose company B has workflow
rules that preclude subcontractor A from changing certain parts of a drawing
after an initial design review. The briefcase created for Company A’s use
would contain the permission restrictions on those elements (or levels, or
files, etc.) and any changes to those elements would be rejected
automatically during the check-in. [N.B. ProjectBank enforces security
restrictions, they are established with TeamMate.] Even rules like “no new
elements on level 10” are possible, so you see this can’t be enforced during
the MicroStation or AutoCAD session. Anyway, I hope you can see the
necessity to do a check-out after every check-in and why A will have to
start editing the verified version of file X, not the “raw” pre-checked-in
version.
But, I’ll admit that this approach does require some additional coordination
and potentially additional file exchanges than what you may be doing today.
That’s why I advocate considering a “shared server” running ProjectBank and
accessed over the Internet approach. The server can either be on a computer
owned by Company A, or Company B, or some third party. This is a new game,
and I’m sure we’re going to see lots of innovation in this area.
Keith