Landscape BIM Product Data Templates

I've been asked (well actually I asked) to help review the PDTs for Landscape at the Landscape Institute, and having had a preliminary inspection I am inspired to make the case for them.

One of the big BIM benefits has to be persistent and consistent data. We come across persistent data every day of our lives, we expect individual ATMs to be able to access our bank accounts and produce money regardless of who we bank with (well we do in the UK). We also expect to be able to log in to our email on our phones, at home or on the move. There's a lot of underpinning work that supports all of these things. Now let's compare with a landscape specification.

Assuming that the specification is complete, works done and handed over, but remedial work needs to be done. You're a temp working for the company doing the remedial work and it's your job to find out what plants it is you need to replace some recently deceased one. You will need to find out who holds the landscape design documentation, not generally, not usually, but actually, who holds it, for this project, right now. Then you will need to go to them or have them sent to you, you might need permission to access their physical files and you might then be required to physically go to the archive and dig out the document. Of course, back then we didn't have a filing system so it's in one of those boxes... you get the picture. Things get lost very easily and it gets chaotic.

In a perfect BIM world. You could find out who holds the specification, get a link to the document, get a log in for their extranet site. Download the file and open it in excel or equivalent software.

So that's clear. Now, what if, following these remedial works the specification needs to change? I think you can see the difference.

Product Data Templates are the first step to  creating a consistent and persistent store for your project's specifications and other data. These PDTs indicate what can be stored and how. Once these have been complete, the job will be to create databases that hold this information for people to easily create, view and edit specifications in a fraction of the amount of time it currently takes.

For more information on PDTs check out.
http://bimtalk.co.uk/

Landscape BIM & Revit now 900% more efficient (in places)

I often come into contact with consultants who work in the external sphere: Geomatics Engineers, Landscape Architects, Civil Engineers and the like who have been told they need to start using Revit. There is a lot of reticence surrounding this idea, particularly because the software is in no way designed for external design, in fact, designing assets for the external sphere has been explicitly ruled out by the powers that be on the Revit wishlist.


And working with Landscape Reviteers I know first hand a lot of the problems that can arise when implementing this software. Revit is, out of the box and after basic training next to useless for the total novice who works outside of the building envelope.

Furthermore, Revit is not BIM and anyone who says that it is has missed at least half of the message of BIM in the UK.

However, and it is a big however, there are ways to make Revit work for the external sphere. And using some programming skills, I have just managed to make a 900% efficiency gain on some Landscape Architecture workflows within Revit. This wouldn't be possible without the experience of Revit at Colour Urban Design Ltd.,  nor would it be possible without being able to program. I guess I'm showing off really, but who can blame me!

So I'm still not going to tell you that Revit is the perfect software for external works, (but neither does that perfect software exist), but if you do decide to take the plunge (because, after all, there are still a lot of benefits to Revit), then I suggest factoring in a more complex set of requirements than an Architect would need to. Software vendors will always tell you that implementing new software is more than just buying the stuff, and they're right, but many companies muddle through with trial and error. That just won't work with Revit.

OGC's new Urban Planning group releases draft charter

I have just submitted a comment on the following key issue for interoperability.

OGC's new Urban Planning group releases draft charter

Data structures are simultaneously very deep and very wide. There are more professions, professionals, sectors and requirements than a single body can hope to create a set of super specifications for.

Therefore, to fulfil the group’s goal of:

3.       Avoid placing artificial technical barriers on use of Urban Planning data.

I propose that all software companies should commit to opening their data structures transparently and completely, as this artificial barrier of opacity is the single biggest barrier to interoperation within the various sectors that these companies encompass. 

when to BIM? a Level of Definition question

BIM in this blog means 'use Revit'. (Hey, it's shorthand) If you don't like that, imagine that instead of saying 'when to Revit', I said 'when to begin cumbersome, intensive, information rich modelling and specifying'.

Now where do I put it

The question of when to go into high level modelling software is a tricky one. But it needs to at least be asked and marginally answered simply to manage costs within your organisation.

I have spoken with MEP Engineers who have modeled their entire work before they have even been awarded the contract, and occassionally, as you might expect, they don't win the contract. That would upset me and it upsets them, but with the combination of human nature and the software to hand it is tempting to try and 'get it right' first time. Of course, when it comes time to make amendments, it can be more work to undo what has already been done to a higher level of detail than if it was done at a lower level of detail in the first place.

The problem has to be the detail. It's easy to imagine that a low level of detail is less work than a high level of detail. So for example, an illuminated bollard would be less work if it was just a blob called 'illuminated bollard' than if said bollard were finished to a high level of detail including fantastic geometry, textures, scheduling and manufacturer's information. However, that isn't even the problem because designers and engineers may have only one copy of a model for a given object, so they just sling 'it' in. The implication is that this is bad LoD practice, because you need to clearly communicate to what level of resolution a given design has been taken. That obviously means more work initially creating more models of the same thing at different levels of physical detail (never mind the information). However, what that would produce is a much clearer design that a project manager could examine and understand where more work needs to be done or perhaps conversely, less work needs to be done, because the project isn't at the degree of resolution that the designer has supposed.

Just to turn that on its head. When bidding for work visualisations need to look as good as possible. This invariably means in the minds of designers that the model should be in as high a level of detail as possible. So what do you get? You use the same models that you've previously prepared and drop them in, with all the high level of detail joys that they bring (or don't, depending on the model object). This is sowing a minefield for future design of that project. Leaving in legacy, highly detailed objects at conception phases could lead to all sorts of problems founded on the assumption that the model is already at a high level of completion, or perhaps the object is just 'lost' and inadvertantly gets priced. There really are so many things that can go wrong that I won't go into it in any great depth, mainly because we'll need to start handing round the brown paper bags to breathe into when we collectively hyperventilate. Needless to say, we've intentionally introduced a false assumption into the model and that can lead to problems.

There are of course answers to these problems, and it isn't the answer that I'm looking at here, but the problem. Your answer needs to fit your company based on profession, company structure, project team, client and culture. Ultimately giving more strings to the bow of project leaders is my aim, I don't subscribe to the belief that there is one 'ideal' way of going about BIM. Each project is different, each project team is different, and the power to adapt quickly is the most vital.

BIM clarity. How to spot a BIMbo

I strive to be honest and clear when talking about BIM. The BIMbos who, flouting British cultural rules of humility, flaunt their BIM wares and totter about on a sense of superiority appearing much taller than they really are used to have me mesmerised and a little afraid. What was it, I would wonder, that they know that I don't know...
No longer! Now I see through the equivalent of the fake tan and the impossibly high heels.

First caveat: Not every BIM expert is a a BIMbo, there are still many experts whose opinion you can trust. You just need to know the difference between a BIMbo and a real BIMmer.

How to spot a BIMbo:

What they'll say: "We're level 3" that was easy. The most unambiguous load of tripe, the technology isn't there so how can you do it? Answer, you've been BIMbo'd.
"We have BIM software" ignore the functionality, there's a much quicker way to tell, simply ask " how well does it interoperate with other software packages" then, if they don't come clean say, "okay, show me". If at this point they start to sweat profusely from every pore. You've got a BIMbo.
"ROI of xxx%" Simply ask, "how was this calculated?". If they haven't recorded the differences in costs between a serious quantity of BIM projects and non BIM projects, or if they haven't accounted for training or ongoing software costs. You've got a BIMbo.
What a BIMbo will and won't say: They won't say, but will strongly imply that BIM is software. They'll talk about BIM, a BIM, the BIM, but never consider the process. I'll let you off if you're not in the UK BIM industry, but only just. Processes are vital to achieving the cost benefits of BIM.
I'm sure the BIMbo will raise its ugly (sic beautiful, but hollow) head sooner or later, and then I'll be back!
Now I have some hard manual labour to do for my weekend. Dig dig dig.

Second caveat... actual bimbos I quite like.

Landscape Infrastructure

Pierre Bélanger's PhD Thesis on another name for Landscape Architecture (the more the merrier huh). Landscape Infrastructure Excellently crafted, well penned. Does what PhDs seem to do a lot and meanders between topics a fair amount, but I can forgive that, because it is accessible and interesting to read.

Revit for Landscape - Training

If you're thinking of going BIM, you might have thought about Revit, because it's BIMmmy. I will warn you now, whatever software you're using, you might have a couple of workarounds right?! That's nothing compared to using Revit for Landscape Design. You have been warned... question is, how attractive is the BIM prize. Oh, and don't bother with landscape plugins for Revit, they're essentially window dressing. Revit for Landscape Training from our friends in Norway