Now that Valentine’s Day is behind us, rather than “everything coming up roses,” it seems to me that everything is coming up 3D.  At least everywhere I turn.

Hot on the heels of a very informative URISA BC seminar titled “The New Dimension in GIS – 3D Analysis” (find a good summary of the day here), I’m on my way to Montreal and Quebec City to take part in a seminar series on BIM and 3D interoperability.  I’ll be presenting on a number of important BIM and 3D formats and how they relate to each other, and showing how Safe’s products FME Desktop and FME Server can play a role in greasing the wheels of data exchange between such formats.  In fact, I just today heard a story of a large project here in Vancouver, BC where two firms were involved at different stages during the design process, and the hand-off between them was to redraw the plans due to incompatibility between the design systems they used.  Now that is a squeaky wheel if ever I saw one.

But what really got me thinking today was Oleg Shilovitsky’s blog posting asking “can we create a 3D RSS?”  Such a mechanism would provide a standards-based way to communicate modest amounts of 3D information using the very successful RSS mechanisms.

To me, it seems like there are two ways this could go.  One could be to take advantage of the existing GML dialect available within GeoRSS and just embed a 3D payload inside of the GML.  While this could be done today without creating anything new, it seems this would impose a Geo-aspect to the 3D RSS, which may not always be desirable or necessary in the broader context.  For example, what if you’d subscribed to a 3D RSS feed of the latest automotive model announcements? – That 3D data certainly doesn’t have a spatial context to it.

The other way I could see would be for a group to just invent a new dialect of RSS, much as the Geofolks have done, and garner support for that.  It may be better to choose an existing XML specification for 3D data (again, GML might suffice, or X3D, or Collada, or …).  But if they decide to invent a new specification, then making a provision for a spatial reference point would be ideal so that the data could be located spatially if it made sense.

One way or another, I think that having an accepted way to syndicate 3D data is an idea which will have legs. It will be interesting to watch and see where it goes in the weeks and months ahead.

3D Interoperability Spatial Data Interoperability Uncategorized

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!


2 Responses to “Everything’s Coming Up 3D”

  1. Hello Dale,

    It’s interesting you came to similar position about 3D data syndication from GIS/BIM, where my position in the beginning was completely mechanical/supply chain. This is once again to re-confirm that today’s way to share 3D is almost irrelevant. I see people is still working on formats these days. Is there any format, you think, people can invent in addition to all stuff that already invented… ?


  2. Dale Lutz says:

    @Oleg — The ability to invent new formats appears to know no bounds as far as we can tell at Safe. We have a graph showing formats we support by year and it has gone up at a constant rate since 1997! I have a hunch though that in terms of embedding 3D in a lightweight Web 2.0 payload a very reasonable approach would be to use the constructs of an existing 3D XML specification (and there are several to choose from), and embed that into an RSS wrapper. I think it might be difficult to justify inventing a brand new XML format for 3D in RSS, but it may be that the requirements for this situation may warrant something more lightweight, for example, and so no existing format could be used directly. In any case, lets hope that only a single winner emerges — with GeoRSS there are 3 different flavors of geography being embedded which triples the work for implementers.

    Thanks for the comments.