At Safe we work hard keep on top of any developments in the wide world of spatial data formats, and this past week I noticed an interesting juxtaposition of discussions from two ends of the format complexity spectrum.
While the world of BIM is struggling with the complexity of Industry Foundation Classes (IFC), the inherent simplicity of GeoJSON seems to be enabling those in the GIS world to (live long and) prosper.
Speaking ‘Esperanto’ in the BIM World
In the BIM world, the IFC format is often held up as the Esperanto language (and format) for open, non-proprietary exchange and archive of Building Information Models. Not only does it define a format (well, two if you consider the raw ASCII and XML flavours different, which they are), but more importantly it defines a data model or vocabulary that all Building Information Models should be able to be expressed in.
Any format, which attempts to define a domain-wide complete set of primitives to express any data, faces at least two significant hurdles: (1) Is there agreement as to what the primitives mean so they can be used consistently, and (2) Are the primitives available able to satisfactorily express everything that a vendor product wants to express?
The linked articles make a strong argument that IFC alone, just like its counterparts from days gone by in the GIS world (i.e. DIGEST and SDTS) can’t quite do the job for every situation.
One way forward would be to spend more on the format, another would be to try our hand at inventing a new one (FFS? Seriously, I’m joking). But if our experience from the GIS world is to be any guide, the one true way to BIM data exchange and archive happiness is full, open, unfettered API access to the BIM applications (yes, Red Bolt, I agree with you). RealRVT anyone???
Speaking ‘Lingua Franca’ in the GIS World
At the other end of the format complexity spectrum this week Sean Gillies asked if GeoJSON had become a lingua franca for Python GIS development. We’ve long supported GeoJSON in FME and have frequently applauded the wonder of its simplicity. It has been gratifying to have seen its usage grow over the years, primarily as a live exchange format between geospatial web services.
Esperanto vs. Lingua Franca
To sum it up, IFC = Esperanto and GeoJSON = Lingua Franca. Looks like the BIM folks may have some lessons to learn from the GIS folks. (Perhaps we should introduce them to Sean Gillies?)
Where along this spectrum do your favorite (or not so favorite) spatial data formats fall? And what APIs do you think are missing (or already present), that hinder (or help) your format’s usefulness?
Canadian Governor General candidate and Esperanto-speaker William Shatner likes using IFC for his Building Information Modeling
You might also want to read:
Integrating Third-Party Tools with FME (No Coding Required)
Dale Lutz
Dale is the co-founder and VP of Development at Safe Software. After starting his career working spatial data (ranging from icebergs to forest stands) for many years, he and other co-founder, Don Murray, realized the need for a data integration platform like FME. His favourite TV show is Star Trek, which inspired the names for most of the meeting rooms and common areas in the Safe Software office. Dale is always looking to learn more about the data industry and FME users. Find him on Twitter to learn more about what his recent discoveries are!
The Incubus reference is awesome. Imagine it in a double feature with “Comanche Blanco”.
Thanks for the link. I’m actually disposed to appreciate complex ontologies and languages, but they shouldn’t exclude simpler ones. Let architects communicate with each other using IFC, let the window communicate with the wall using … JSON?
Hi Sean — YES, that double feature would be awesome. Afterwards viewers would be begging to read format specifications for a dose of tension and excitement.
I agree, there is a role at times for complexity — so long as it is not just for the sake of complexity. A friend of mine has said “Complex problems demand complex solutions”, not sure if I agree with that in general but sometimes it is necessary. But the goal should always be to look for the simplest solution that can solve the issue.
I would love to see json speaking to ifc (ifcxml).
or quering ifc via jsonquery from jsondatabase.
i think with autodesk homestyler or floorplanner the trend is going on to
edit your plans within Adobe AIR on your iphone or your huge touch-plasma-screen.
you could get better results working in the cloud with
client, partners, engineer, architects, draftsmen (i’m a studying draftsman) i guess.
presenting your results via xhtmlpostscript would be much easier.
but i’m still dreaming…
do you know anything about?
Hi Dominik,
Well, if my friend Martin is right, JSON is the CSV of the new millenium (http://lin-ear-th-inking.blogspot.com/2010/07/is-json-csv-of-21st-century.html) So perhaps that is the direction.
My grade 5 son got his class all using homestyler, so if they are the architects of the future, then perhaps your vision will come true. But it will be a few years yet I expect.
All the same, perhaps its time to dig into the 3D formats of HTML5…(this is a good read here http://www.3d-test.com/interviews/x3d_2.htm ).
Good discussion…
Dale