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.